On Wed, Jun 01, 2011 at 01:18:11PM -0400, Scott Rose wrote: > > The title is > > # Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA > > # Registry > > > > Is this title meant to tell me that this is defining or redefining the > > DNSKEY Algorithm Registry run by IANA? The "Applicability" part is a little > > confusing. > > > > Technically redefining if you want to split hairs. We could remove the "Applicability Statement" in the title, if that would help. Ed? > Our main reason for replacing the registry table with a doc containing a new > table was that not all implementors may be good at sorting through the IETF > archives looking for every DNSSEC related RFC and BCP. Have a simple table > at a well known repository will hopefully reduce that document hunt. I think this is the key point, and I want to make it more strongly than Scott does: we already tried that. We have some documents that say which algorithms are mandatory to implement. Other RFCs have defined algorithms but were silent on whether something needed to be implemented -- quite correctly, since it is meaningless for a document to define what MUST be done for anything other than conformance with it. Finally, the DNS world has a long history of requirements littered throughout various RFCs, but without a codex that would allow you to find all the RFCs you need to read to understand what you ought to do for your particular implementation. We received feedback at a meeting (in Maastricht, I think, and from Steve Kent, I think) that the DNSEXT WG should pick some algorithms and make it clear that those are the ones everyone ought to be able to use, if they want to be interoperable with everyone else. We were also advised to make clear the one(s) we believe to be "up next", on the grounds that implementers and deployers can be ready. So, the goal here is threefold: (1) to collect all those MUSTs and MUST NOTs into one RFC: anything not defined in that RFC as required is completely optional; (2) to provide a single place where implementers can find out where that advice is located; (3) to make sure that we don't somehow end up with conflicting advice. The list of requirements in this draft satisfies (1). One conforms to an RFC, and if it is published as an RFC then this document is the one to which one should refer in RFPs and so on, assuming one wants this sort of general-purpose conformance. (If you only wanted GOST, for instance, you wouldn't require conformance to this document. That's just a different decision.) Now, of course, (2) could be solved in more than one way. We could put up http://tools.ietf.org/wg/dnsext/guide-to-the-perplexed and include a link to this document (if it becomes an RFC). But that would not solve (3). (3) is the real reason to use the registry for this. Registries are not just there to have a single convenient place to look everything up. They also exist because they prevent collisions and so on. Only one entry can be in the registry for code point _n_. The "conformance to RFC TBD1" column is yet anothe such condition: only RFC TBD1 is allowed to add things to that column. So if anything comes along and tries to add things to that column, we know we have a failure, and the registry entry doesn't get created until the problem is solved. In this way, the draft is using the registry exactly as it was intended: it is a control point that makes sure a given assignment happens in a co-ordinated way. In this case, the assignment is "DNS community current best advice about what will be maximally interoperable." It's not a blessing; it's just another entry that ensures co-ordination on the Internet in a way that ensures interoperability is maximized. Best, A (document shepherd) -- Andrew Sullivan ajs@xxxxxxxxxxxxxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf