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

["libor.peltan" <[e-mail]>]

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