Re: [Add] questions about the Examples section of svcb-dns-02

[Ben Schwartz <[e-mail]>]

OK, I've clarified (and corrected, oops) the explanation of the examples,
and added another one to highlight the default-DoT behavior:
https://github.com/bemasc/svcb-dns/commit/e59c995fa976a19b5baf1770afb231d3dcb729e1

We can certainly remove the default ALPN, but personally I like having
empty SvcParams correspond to a common default.  The size savings (~8
bytes) are probably not important, although MTU could become relevant in
the context of SVCB delegation responses as envisioned
by draft-rescorla-dprive-adox.

On Thu, Apr 8, 2021 at 10:07 AM David <[e-mail]> wrote:

> On 2021-04-08 1:38 a.m., Peter van Dijk wrote:
> > Hi Ben,
> >
> > thanks for that. Sadly, I still needed help from two other people to
> > understand how DoT over 853 came out of this set. (One of them
> > commented on your commit too.)
> >
> > (For those reading along still confused, it's this bit:
> >
> >          SVCB 1 @ alpn=h2,h3 dohpath=/dns-query{?dns}
> >
> > Because it does not say 'no-default-alpn', it actually means
> > 'alpn=dot,h2,h3' where the dot bit ignores the dohpath.)
>
> As one of these people I will also echo this seems confusing and
> surprising. A casual observer of these records would need to carefully
> read and understand the draft to realize what it actually does, and
> apparently it took some of us a while to get to that. Having it be
> explicitly required or perhaps iterated more in examples would be good.
>
> I will also point out this would also have DoT clients sending an alpn
> of 'dot' where I believe they do not today. Peter did some testing and
> sounds like that wouldn't really be an issue - but I haven't been
> following closely so not sure if this was brought up before.
>
> >
> > I think this could be even more explicit in the draft (I'm happy to
> > think about some words for that) but I really wonder if the space
> > savings are worth the confusion at all.
> >
> > On Wed, 2021-04-07 at 20:36 -0400, Ben Schwartz wrote:
> >> Thanks for the questions!  I've adjusted the text [1] to make the
> examples clearer.
> >>
> >> DoT is the "default ALPN" in this draft, so unless it is explicitly
> removed (by no-default-alpn), it is present, and uses port 853 unless
> "port-..." is specified.  This is good for compactness but can be
> surprising, which is why I used that example.
> >>
> >> I removed the "echconfig" from the examples, as that is not the focus
> of this draft (and isn't even mentioned in the text).
> >>
> >> [1]
> https://github.com/bemasc/svcb-dns/commit/f61c70ed02b550613fdbb37d3171ab1e6d359e2c
> >>
> >> On Wed, Apr 7, 2021 at 4:32 PM Peter van Dijk <
> [e-mail]> wrote:
> >>> Hello Ben, and rest of WG,
> >>>
> >>> https://tools.ietf.org/html/draft-schwartz-svcb-dns-02#section-8 has
> an
> >>> example RRset for a resolver, containing 3 SVCB RRs. This example is
> >>> very useful!
> >>>
> >>> However, I have a few questions/comments about it:
> >>>
> >>> (1) Can you reorder the bullet list to match the order in the RRset?
> >>> (i.e. put the TLS one second)
> >>>
> >>> (2) I see one SVCB record (with priority 2) advertising a DoT server
> >>> (by leaving out the ALPN). It has port=8530. Yet, the text above says
> >>> there's DoT on 853 and 8530. Where does 853 come into play, if the
> >>> prio=2 SVCB record says port=8530?
> >>>
> >>> (3) All three example RRs have an echconfig parameter. While I
> >>> understand it makes sense for an operator to be consistent in doing ECH
> >>> over all their offerings, it somewhat looks like everybody is expected
> >>> to do echconfig - perhaps it would be clearer to not have echconfig on
> >>> all three? Then, maybe clarify that it would in fact be better to have
> >>> it always, but say that the svcb-dns protocol does not demand it.
> >>>
> >>>
> >>> For (2) it's entirely possible I'm missing something - please let me
> >>> know. Thanks!
> >>>
> >
> > Kind regards,
> >
>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>