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

From: Andrew Sullivan <[email-masked]>
Date: Wed, 13 Apr 2011 11:19:35 -0400

Dear Ralph,

This message is a request to publish
draft-ietf-dnsext-dnssec-registry-fixes-07 on the Standards Track.
The draft represents the rough consensus of the DNS Extensions Working
Group.

As required by RFC 4858, below is the completed current template for
the Document Shepherd Write-Up.

DRAFT FILENAME: 
    draft-ietf-dnsext-dnssec-registry-fixes-07
TITLE: 
    Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm
    IANA Registry

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the 
        document and, in particular, does he or she believe this 
        version is ready for forwarding to the IESG for publication? 

Andrew Sullivan.  Yes, I believe it is ready.

  (1.b) Has the document had adequate review both from key WG members 
        and from key non-WG members? Does the Document Shepherd have 
        any concerns about the depth or breadth of the reviews that 
        have been performed?

The WG has been talking about this draft for some time.  I believe it
has had adequate review, but it is a strange document.  It is
basically a process document, and I therefore suspect that the only
time it will get the sort of attention it needs on that front is
during IETF-wide review.  It should also be reviewed by IANA.
  
  (1.c) Does the Document Shepherd have concerns that the document 
        needs more review from a particular or broader perspective, 
        e.g., security, operational complexity, someone familiar with 
        AAA, internationalization or XML? 

The draft uses a novel procedural trick to put something into a
registry that usually isn't in a registry, so I think this will
require careful review by IETF process wonks.

  (1.d) Does the Document Shepherd have any specific concerns or 
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he 
        or she is uncomfortable with certain parts of the document, or 
        has concerns whether there really is a need for it. In any 
        event, if the WG has discussed those issues and has indicated 
        that it still wishes to advance the document, detail those 
        concerns here. Has an IPR disclosure related to this document 
        been filed? If so, please include a reference to the 
        disclosure and summarize the WG discussion and conclusion on 
        this issue. 

There are those who have argued that what the document is doing --
putting "implementation levels" into a registry -- is a bad idea.
This appears to have been a minority position.

  (1.e) How solid is the WG consensus behind this document? Does it 
        represent the strong concurrence of a few individuals, with 
        others being silent, or does the WG as a whole understand and 
        agree with it?   

There have been many WG participants who have been mute on this
document, which might suggest indifference.  The documents on which it
is based, however, all had reasonably strong WG consensus, so there is
no concern that there is technical disagreement here.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme 
        discontent? If so, please summarise the areas of conflict in 
        separate email messages to the Responsible Area Director. (It 
        should be in a separate email because this questionnaire is 
        entered into the ID Tracker.) 

No.

  (1.g) Has the Document Shepherd personally verified that the 
        document satisfies all ID nits? (See the Internet-Drafts Checklist 
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are 
        not enough; this check needs to be thorough. Has the document 
        met all formal review criteria it needs to, such as the MIB 
        Doctor, media type and URI type reviews? 

The abstract does not mention the RFCs that the draft updates, and it
should do.  We presume there will be updates as a result of IETF last
call, and this oversight can be fixed then.  There is an obsolete
normative reference, but that is intentional because of the way the
registry is being respecified.

  (1.h) Has the document split its references into normative and 
        informative? Are there normative references to documents that 
        are not ready for advancement or are otherwise in an unclear 
        state? If such normative references exist, what is the 
        strategy for their completion? Are there normative references 
        that are downward references, as described in [RFC3967]? If 
        so, list these downward references to support the Area 
        Director in the Last Call procedure for them [RFC3967]. 

The references are correct.

  (1.i) Has the Document Shepherd verified that the document IANA 
        consideration section exists and is consistent with the body 
        of the document? If the document specifies protocol 
        extensions, are reservations requested in appropriate IANA 
        registries? Are the IANA registries clearly identified? If 
        the document creates a new registry, does it define the 
        proposed initial contents of the registry and an allocation 
        procedure for future registrations? Does it suggest a 
        reasonable name for the new registry? See [RFC5226]. If the 
        document describes an Expert Review process has Shepherd 
        conferred with the Responsible Area Director so that the IESG 
        can appoint the needed Expert during the IESG Evaluation? 

Yes.  The document replaces a registry; that is all it does.  In some
ways, the entire document is an IANA consideration.

  (1.j) Has the Document Shepherd verified that sections of the 
        document that are written in a formal language, such as XML 
        code, BNF rules, MIB definitions, etc., validate correctly in 
        an automated checker? 

N/A

  (1.k) The IESG approval announcement includes a Document 
        Announcement Write-Up. Please provide such a Document 
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval 
        announcement contains the following sections: 

     Technical Summary 

        This memo completely replaces the Domain Name System Security
        (DNSSEC) Algorithm Numbers registry.  The new registry
        includes a field to indicate requirements for compliance to
        this memo.  At the same time, the registry is adjusted to
        include some reservations of values that have been observed
        as being in use on the Internet.

     Working Group Summary 
        
        The Working Group believes that the DNSSEC Algorithm Numbers
        registry needs maintenance.  This memo is intended to do that.
        The memo includes a novel mechanism for specifying whether an
        algorithm is "required".  The registry includes a field that
        indicates whether an algorithm is required, recommended, or
        forbidden by this memo, and the memo includes a constraint
        that it cannot be updated, only obsoleted.  Not everyone
        thinks the additional field is a good idea.

     Document Quality 

        This is a process-only document intended to present a clean
        and usable registry for IANA; there is no protocol to
        implement.

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 13 Apr 2011 19:44:43 -0400

> during IETF-wide review.  It should also be reviewed by IANA.

I went and and reviewed the document (for the first time).

> require careful review by IETF process wonks.

I'm wondering if I fully understand the purpose of this document.
>From the document's introduction:

    The original list of algorithm status is found in [RFC4034].  Other
    DNSSEC documents have added new algorithms or changed the status of
    algorithms in the registry.  However, currently implementers must
    read through all the documents in order to discover which algorithms
    are considered wise to implement, which are not, and which algorithms
    may become widely used in the future.
 
    This compliance status indication is only to be considered for
    implementation, not deployment or operations.  Operators are free to
    deploy any digital signature algorithm available in implementations
    or algorithms chosen by local security policies.  This status is to
    measure compliance to this RFC only.

Is the purpose of this document simply to add a column to the existing
registry indicating what the IETF status of all the registered
algorithms?

Well, actually, not even that. E.g., what the IETF position currently
is w.r.t. whether it should be implemented.

a) This SHOULD/MUST be implemented, or
b) something other than that?

If so, I find that an odd thing to put in the registry. I don't know
of other IANA registries that do that. Do we have examples?

> This appears to have been a minority position.

Well, one issue is that it's not clear that you can capture the proper
information in a single column. What is the range of things that can
go into this registry status? (The document seems to leave this pretty
open, actually.)

Let me ask the key question: by what action is the compliance column
for a given entry changed/updated?

Apparently (from the document):

   Adding a newly specified algorithm to the registry with a compliance
   status SHALL entail obsolescing this document and replacing the
   registry table (with the new algorithm entry).  Altering the status
   column value of any existing algorithm in the registry SHALL entail
   obsolescing this document and replacing the registry table.

   This document cannot be updated, only made obsolete and replaced by a
   successor document.

So, to change the status of any entry in the registry, you have to
essentially reissue this document with a change?

If so, then I don't get it. 

If you want to be clear about which algorithms the IETF recommends, it
seems to me the best way is to issue a short document that says "here
are the currently recommended algorithms". E.g., something like RFC
4307. Such a document can have sufficient context to give real
guidance. E.g., "this algorithm is being phased out, but you probably
still need to implement it for now", etc.

And, if there were such a single (clear) document for DNSSEC, I don't
immediately see the need for a new column in the IANA registry. Folk
should just review the relevant BCP document.

Sorry if this has all been discussed before, but I read the document
for the first time and didn't pay attention to any of the discussion
that led to it. 

Thomas

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 Apr 2011 17:27:19 -0700

> registry indicating what the IETF status of all the registered

No. The "IETF status" would be "on standards track" and "not on standards track", and that is irrelevant to the current document. The purpose it to list the mandatory-to-implement status. In order to do that, the registry has to point to a specific RFC, because that is where the mandatory-to-implement status is defined.

> is w.r.t. whether it should be implemented.

And there is no such "IETF position", of course.

> b) something other than that?

Pretty much that.

> of other IANA registries that do that. Do we have examples?

I, too, didn't like this idea, but the WG really did. To turn around your question: is there a procedural problem if this is the first registry to do what is proposed here?

> go into this registry status? (The document seems to leave this pretty

We disagree: the document gets quite specific here. The column lists compliance to an RFC, namely this one.

> essentially reissue this document with a change?

Correct. RFCs don't change.

> for the first time and didn't pay attention to any of the discussion

It has been discussed before, and you are voicing a view that some us voiced.

--Paul Hoffman

---

From: Thomas Narten <[email-masked]>
Date: Wed, 13 Apr 2011 21:55:04 -0400

Paul Hoffman <[email-masked]> writes:

> I, too, didn't like this idea, but the WG really did. To turn around
>  your question: is there a procedural problem if this is the first
>  registry to do what is proposed here?

There are lots of things that, strictly speaking, there are no
procedural problems with doing. But that does not mean we should do
them.

>  compliance to an RFC, namely this one.

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.

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

> It has been discussed before, and you are voicing a view that some us voiced.

OK. Then I think I'm in the camp that is pretty strongly opposed to
this.

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. This
stuff does not need to go into the registry. I am not convinced that
putting this info in a registry will make it more likely to be found
by an implementer than just having the recommendation in a BCP. 

What this is doing is creating a "profile" document, and putting that
profile information into the registry. That is not the primary purpose
for registries and I do not see compelling value in putting such
information in a registry. Indeed, I see this as additional compexity
and process for questionable value.

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

Thomas

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 14 Apr 2011 08:55:28 -0400

Hi Thomas,

> procedural problems with doing. But that does not mean we should do

That is true.  But there are reasons of improved interoperability to
do this.  See below.
 
> 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,
 
> 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.

> 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
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 14 Apr 2011 06:39:20 -0700

The philosophical / operational tussle here is whether the definitive list of crypto algorithms and their implementation requirements should be kept in:

a) an IANA registry for the growing list of algorithms, and a single RFC for the implementation requirements

b) an IANA registry for the growing list of algorithms, and a set of loosely coupled RFCs for the implementation requirements

c) an IANA registry for a growing list of algorithms that is tied to a single RFC for the implementation requirements

Some WGs have gone with (a), and some with with (b). The current draft proposes (c) for this protocol. It is a modification of the idea in (a), and it gives the implementer less chance of getting it wrong because they will find the exact same set of implementation requirements in "the" RFC and the IANA registry.

To me, this is different and a bit weird, but could make sense for getting better interoperability because of better understanding on the part of developers. It seems worth a try and, if it turns out to be more confusing than (a) or (b), the WG can drop back to one of them.

--Paul Hoffman

---

From: Thomas Narten <[email-masked]>
Date: Thu, 14 Apr 2011 09:54:57 -0400

Thanks Paul. I agree with they way you have layed out the basic
issues.

> The philosophical / operational tussle here is whether the
>  definitive list of crypto algorithms and their implementation
>  requirements should be kept in:

>  RFC for the implementation requirements

That is (IMO) the normal way the IETF have done things.

> b) an IANA registry for the growing list of algorithms, and a set of
>  loosely coupled RFCs for the implementation requirements

Actually, IETF does this too, but I agree it's not great. Making
people hunt through many RFCs to find things tends to not help. Choice
a) would be better, though we often don't bother.

> c) an IANA registry for a growing list of algorithms that is tied to
>  a single RFC for the implementation requirements

And I have to wonder why we even need a registry, when the contents of
the registry are effectively kept in a single RFC, with some types of
updates to the registry effectively requiring reissuing the RFC and
replacing the entire IANA registry.

> Some WGs have gone with (a), and some with with (b). The current
>  draft proposes (c) for this protocol. It is a modification of the
>  idea in (a), and it gives the implementer less chance of getting it
>  wrong because they will find the exact same set of implementation
>  requirements in "the" RFC and the IANA registry.

I think we are deceiving ourselves if we think putting the compliance
info into the IANA registry will make any difference at all.

The important thing is to have the requirements in one place, where
they are easily findable by anyone who has even a small amount of
clue. If implementors won't find them in a BCP IETF document, I
suspect there is very little we can do to make things easier for them.

And implementors will implement what is in RFPs and the like, and they
will point to the RFC stating the requirements, not the IANA registry.

> To me, this is different and a bit weird, but could make sense for
>  getting better interoperability because of better understanding on
>  the part of developers. It seems worth a try and, if it turns out
>  to be more confusing than (a) or (b), the WG can drop back to one
>  of them.

To me, the work to be done is the same: layout the implementation
recommendations in a BCP RFC. I don't see much value in putting that
info into the IANA registry itself, and I very much dislike the idea
of trying to have the IANA registry be where implementation
recommendations are captured. It seems like the wrong mechanism to
bring about a particular result.

Thomas

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 14 Apr 2011 07:09:47 -0700

> replacing the entire IANA registry.

Because we have trained a large subset of developers to go to the IANA registry. We have trained only a very small number of developers to be able to correctly find the *one* *current* RFC that has the implementation requirements (where both "one" and "current" are difficult for typical developers). This proposes an expedient that has a chance for higher success.

> will point to the RFC stating the requirements, not the IANA registry.

We should be able to evaluate the success of this idea within a few years to see if you are right.

> bring about a particular result.

I can see both arguments, and have made both on this list in the past. :-)

--Paul Hoffman

---

From: Joe Abley <[email-masked]>
Date: Thu, 14 Apr 2011 10:27:56 -0400

> replacing the entire IANA registry.

I don't understand this point -- why would a subsequent document not be able to update the registry on its own merits, e.g. for the purposes of documenting implementation requirements for new algorithms?

Why would the registry need to be replaced in the case where we're just adding rows to it?

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 14 Apr 2011 10:44:37 -0400

> Why would the registry need to be replaced in the case where we're just adding rows to it?

It doesn't.  Anything that just adds a row to the registry, without
adding anything to the column indicating rules about this document,
can just work as it ever did.

If, however, you wanted to create an entry that said, "The document
_x_ says that this algorithm is mandatory to implement," then you'd
have to replace the registry with a new one.  That's because the
column is a place to state non-optional requirements for conformance
with _this_ document.  The document can't be changed after it is
published.  So you'd need a new document, with a new and different
column.  That would be standards action, and I'd expect the WG to say
"replace the registry" rather than "add yet another column".

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 18 Apr 2011 09:35:41 -0400

>replacing the entire IANA registry.

I'd rather have a registry that points to documents than have a 
document be the source of *what* is defined.  Documents are there for 
*how* something is defined.

The reason is that the registry is a single, fixed location (perhaps 
at a URL) dynamically updated where I can actively access it to see 
the current state of the protocol parameters.  RFCs are never 
changed, updating the contents mean issuing a new one.  Essentially 
this is a moving location that has fixed contents.  I prefer one 
location than having to hunt for the latest.

If in my head I know RFC 2929 is the "IANA considerations for DNS", I 
might not know about RFC 5395.  Yes, the RFC-Editor keeps track of 
what obsoletes what, but, it's not always reliable and it is yet 
another web site to consult.  Especially if I've downloaded RFC 2929 
and only refer to what is in a local file repository.

>>   a single RFC for the implementation requirements

I would agree if this is what is meant: a single RFC for each 
algorithm's implementation requirements.

That is, like we have for the RRtypes registry, each type lists the 
RFC or other document where the type is defined.  (As opposed to one 
gigantic RFC listing all the definitions.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
Son: "Waah!"