Re: [dnsext] Publication request: draft-ietf-dnsext-dnssec-registry-fixes-07

[Andrew Sullivan <[e-mail]>]

Hi Thomas,

On Wed, Apr 13, 2011 at 09:55:04PM -0400, Thomas Narten wrote:
> 
> There are lots of things that, strictly speaking, there are no
> procedural problems with doing. But that does not mean we should do
> them.

That is true.  But there are reasons of improved interoperability to
do this.  See below.
 
> I don't see that. I gather (reading between the lines) that the column
> is expected to use RFC 2119 keywords and that those keywords are
> supposed to be in the document that updates the registry.

I'm not sure what you are seeing between the lines, but I don't
believe that's what the document actually says in the text.

The document is, I believe, quite clear.  It completely replaces the
existing registry.  That replacement includes a column with rules for
compliance to the document.  If someone later wants to put something
into that column, then they must obsolete this document.  If someone
wants to add an entry to the registry without anything in that column,
then it can do so without affecting the status of this document
(because there is no entry in the column, so it doesn't affect the
conformance claims one way or the other).

Moreover,
 
> But I didn't see text in the document itself that says that is what is
> required. Just examples...

the text you seek is, "This document cannot be updated, only made
obsolete and replaced by a successor document."  Some future document
could make new rules.  This document can't constrain those, of course,
but it can constrain what its own status is allowed to be.  So from a
process point of view, all the document can say is what it does and
how it may be treated in future.

> I think the proper way to document what is recommended in terms of
> algorithms is simply to write a document that says that, make it a
> BCP, and publish it. That is what we do all throughout the IETF.

That may be what people usually do in the IETF, but for our purposes
it hasn't worked.

The IETF is supposed to be about interoperability.  Why do we have
IANA publish registries?  Because it improves interoperability:
implementers know where to go to look up the algorithm numbers.

The WG adopted a low-barrier algorithm code point assignment process.
That means it is very easy to get algorithm numbers assigned.  When we
did that, there was advice from the security area that it would
improve interoperability if we had some way of stating, "Here are the
algorithms everyone needs to implement for maximal interop, here are
the algorithms we expect everyone will need soon, and here are the
ones we think you shouldn't support any more.  Everything else is
optional."

Now, as you say, one way to do that is to have a document that comes
out from time to time with that information in it.  But if there is a
large number of algorithms in the registry, how is an implementer to
find this document?  Because it turns out that we have this problem
all over the DNS: people just cannot (or cannot be bothered to) find
all the documents they need to find, so they make their best guesses.
The result reduces the chances that two systems from different people
will work together well.  And we see this in the deployed DNS, where
half-witted implementations in middleboxes and supporting applications
do all manner of wondrous things to DNS packets, interfere with EDNS0,
impede our ability to deploy new features, and so on.

The expedient of noting these "mandatory", "mandatory soon", and
"don't support" algorithms in the registry is so that a random coder
told to add DNSSEC to some random middlebox in the next 48 hours is
able to find, at a glance in one place, all the stuff that he or she
really needs to know to get started.  Moreover, because there is
always one place with the "current rules" about what's mandatory and
not, contract writers can go to the registry, find the RFC reference,
and include that reference in their contracts.  This is also helpful
for interoperability.

This innovation does no harm, and it offers the above benefits for
interoperability. 

Finally,

> Just write a document, say what the requirements are, and publish it.

Who will do that?  If we need this information, and need it to be kept
up to date, we need a forcing function.  Otherwise, we will end up
back where we were: a mess of algorithm documents each of which
attempts to specify whether it is "required" or not.  You are arguing
that the place for that is a different RFC.  But I don't know who will
do that work.  

With respect, your review at this point in the process is a good
example of the problem: we've had this document on the WG docket for
some time, and it's been through WGLC, but only a very narrow segment
of the WG participants did any work on it.  This is broadly true of
documents from this WG, and I see no evidence that such is likely to
get better when it comes to these wonky kinds of drafts.

Therefore, for the purposes of interoperability, it is better to use
the registry as a gating mechanism in much the way we use it to
prevent conflicting algorithm assignments.

Best,

Andrew

-- 
Andrew Sullivan
[e-mail]
Shinkuro, Inc.