On Thu, May 13, 2021 at 3:56 AM libor.peltan <libor.pel...@nic.cz> wrote:
> Hi all, > > just my comment: > > Perhaps complexity is subjective. The important thing is that the > standard be reasonably implementable. I hope that the list of published > implementations [3] will serve as convincing evidence that the current > draft is sufficient in that regard. > > --Ben > > I agree that complexity is subjective. I have no problem implementing > complex procedures. But more complexity means more probability for bugs > (and even security issues). > > Currently, the authoritative server (while transforming presentation to > wire format), MUST: > > - sort the SvcParams by key > - verify their uniqueness > - deal with list of fields nested in other fields (this includes the > discussed comma escaping) > > and the client MUST: > > - verify that SvcParams are sorted and unique > - deal with list of fields nested in other fields (at least that various > "lengths" match) > > In the concurrent proposal, the sorting and deduplication will be "for > free", because DNS ensures this, > DNS only ensures that each entire record appears only once, which is different from the current draft's requirement that each key appear only once (to form a map). > and each RData would consist on just one list of values, much easier to > handle. > I'm not sure I understand. Are you proposing that each record contains a single value, or each record contains multiple values? If the former, note that you have a "set" of values, not a "list"; order is not preserved. Any value type that is actually an ordered list will have to complicate its value format in order to express the ordering. If you mean for each record to contain multiple values, then you either have multiple layers of redundant multiplicity (sets of lists), or you require that clients validate the RRSet to ensure there are no duplicate keys. Either way, you have to consider who is responsible for preventing multiple values for single-valued parameters, whereas in the current draft, this is essentially inexpressible. > On the other hand, the client would have to group several RData (already > sorted) to get all info, and believe they're all there (as Brian pointed > out, it has to anyway). And it would cost more bandwith due to DNS overhead > -- repeated TTLs etc (thanks Ben and Vladimir for the lesson). > > Have I summarized the pros/cons of both approaches well enough? > I would also add the considerations for humans who are reading or writing zone files. Can they see bindings as a unit, with confidence? Is the syntax familiar and self-explanatory? Is it excessively verbose? Are typos likely to be caught early, with helpful error messages?
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
