Hi Ben, Thanks for the work on the SVCB draft! It’s in really good shape, in my opinion. I’ve commented on these three PRs, but I’ll share my thoughts here as well.
> On Feb 18, 2021, at 7:36 AM, Ben Schwartz > <[email protected]> wrote: > > The SVCB/HTTPS RR draft is nearing completion, but there are a few remaining > topics on which the authors would appreciate feedback from the working group. > Personally, I've written up three proposed changes that would benefit from > broader input. Please share your thoughts. > > 1. Change IANA policy to Specification Required > (https://github.com/MikeBishop/dns-alt-svc/pull/262/files > <https://github.com/MikeBishop/dns-alt-svc/pull/262/files>) > > The current proposed IANA policy for SvcParamKeys has allocatable ranges > under three different policies ("Standards Action", "Expert Review", and > "First Come First Served"). This is very flexible and enables > experimentation, but creates compatibility risk: a FCFS SvcParamKey could be > allocated without a clear specification of its zone file syntax, leading to > zone file portability issues. > > This proposal would replace all these ranges with a uniform Specification > Required policy. The required documentation is minimal: it is only required > to describe the zone file format. I disagree with the rationale behind this change. I totally agree that we should have a clear zone file syntax, but based on RFC 8126 that defines the various buckets, FCFS registrations can have requirements for well-formatted entries with registry-specific requirements. We can mandate that the registration have a clear zone file syntax, without needing to be Specification Required. Specification Required requires expert review and is a heavier-weight process than what we necessarily need for an experimental range. The documentation that’s needed is minimal: the value, the name, and the zone file format. These can be entries directly in the registry, and will make the registry a more useful resource. > > 2. Skip the default port prefix > (https://github.com/MikeBishop/dns-alt-svc/pull/230/files > <https://github.com/MikeBishop/dns-alt-svc/pull/230/files>) > > Using SVCB with a new protocol requires the initial QNAME to end with > _(scheme).$HOSTNAME. The current text suggests (non-normatively) to add > _$PORT for endpoints that are identified by a port number. This turns out to > be inelegant for protocols that almost always use the default port. For > example, in the DNS mapping (draft-schwartz-svcb-dns), this would correspond > to names like "_53._dns.resolver.example". > > This proposal would change the guidance to skip the port prefix when starting > with the default port (like "_dns.resolver.example"). This is a good change. Ship it! > > 3. Add a SHOULD-level chain length limit for zone owners > https://github.com/MikeBishop/dns-alt-svc/pull/294/files > <https://github.com/MikeBishop/dns-alt-svc/pull/294/files> > > Constructing huge chains of CNAME and AliasMode records is clearly a bad > idea, but how huge is too huge? This change suggests not to use more than 8. > This doesn't change the requirements for resolvers (which are free to impose > any limit greater than zero) but it might help us to converge on common > behavior. This seems like a sensible change. I think the recommendation could be less that 8, but it shouldn’t be more. Leaving this at 8 seems fine. Best, Tommy > > --Ben Schwartz > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
