Re: [DNSOP] SVCB proposals

[Ben Schwartz]

On Thu, Feb 18, 2021 at 12:11 PM Tommy Pauly  wrote:

> 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@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)
>
> 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.
>

To be precise, the specification must explain how to convert from zone file
format to wire format.  In some cases, this could be very simple, but I
wonder if even trivial cases are compact enough to encode _inside_ an IANA
registry entry.  Do you know of any registry that is structured this way
today?

Also, using a registration policy of First Come First Served, where one of
the required attributes is a specification, seems like an end-run around
IANA's standard procedures for no clear reason.

I would appreciate input from anyone with more IANA experience on how this
ought to work.  I think we largely have agreement on the intended policy
here, and are looking for the right way to encode it as an IANA
instruction.  In particular, I think we should make it very easy to define
new SvcParamKeys that reuse the presentation format of an existing
SvcParamKey.

I note that there are several older registries (e.g. [1],[2]) whose policy
is given as "First Come First Served with specification" or similar,
despite no such option being listed in RFC 8126 or its predecessors.
(Notably, many of the entries in [1] appear to lack such a specification,
despite the registry's documented policy.)

[1]
https://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml#aaa-parameters-47
[2]
https://www.iana.org/assignments/ldap-parameters/ldap-parameters.xhtml#ldap-parameters-8


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SVCB proposals

[Tommy Pauly]

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 
>  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 
> )
> 
> 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 
> )
> 
> 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 
> 
> 
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop