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(_at_)anvilwalrusden(_dot_)com
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf