On Thu, Feb 18, 2021 at 12:11 PM Tommy Pauly <tpauly= 40apple....@dmarc.ietf.org> 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
