search

NLnetLabs / draft-toorop-dnsop-dns-catalog-zones

Work on catalog zones
3 stars 11 forks source link

V06 review suggestions #48

Closed mind04 closed 2 years ago

mind04 commented 2 years ago

My review for #45

  1. NS records are sometime useful for the implementation. Ignore them completely is not possible.
  2. Be more clear that a catalog consumer should ignore ALL Records it does not understand
  3. Try to improve the wording about coo
  4. Group properties are agreed between the consumer and producer operator. There is no need to be this restrictive about the exact format in the draft. This pull is also adding multiple groups per zone. This will make it possible to send the same catalog to multiple operators with different group requirement. This will simplify management of catalog zones greatly since it no longer necessary to create a catalog per operator (and keep those in sync).
mind04 commented 2 years ago

The fourth commit extending the group property needs discussion with @libor-peltan-cznic . I can see one thing which needs to be addressed already: What should a consumer do that sees more than one property it does understand? Apply one, apply all of them or apply none of them.

It is not up to us to determine what to do with multiple group properties. This is something operators of consumers and producers should agree on. With the proper agreements (send only one group property) all current implementations of group are still fully compatible with this modification. While this modification is adding new possibilities for new implementations.

libor-peltan-cznic commented 2 years ago

While it seems reasonable and useful to extend the number of possible groups per member from one to more, I feel a bit concerned about their total amount.

Even if we lift the requirements in the way that it's up to the consumer what he does when he does recognize some subset of them...

Might it be harmful if there are somehow too many of them? Shall we somehow consider it?

Habbie commented 2 years ago

While it seems reasonable and useful to extend the number of possible groups per member from one to more, I feel a bit concerned about their total amount.

Given that the semantics of group are entirely up to individual vendors and operators, I don't think the draft should be limiting the number.