Re: [DNSOP] SVCB proposals

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 <bemasc=40google.com@dmarc.ietf.org> 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
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop