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, and each RData would consist on just
one list of values, much easier to handle.
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?
Libor
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
