Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Ben Schwartz <[e-mail]>]

On Thu, May 13, 2021 at 3:56 AM libor.peltan <[e-mail]> 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?