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

[Thomas Narten <[e-mail]>]

Based on the writeup, and this in particular:

> 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.

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

> 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.

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?

> 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.

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