Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry
draft-ietf-dnsext-dnssec-registry-fixes-08

I think that keeping compliance information in an IANA registry is a bad idea. A solution on the lines of what Robert proposes in his DISCUSS would solve the issue and I support it. I am entering however a DISCUSS and not a COMMENT with the purpose of turning it into an ABSTAIN if the decision is to go ahead on the current path, or clearing if some variant of Robert's proposal is accepted. 

I think the mechanism specified for registry update in section 2.3 is so far out of the norm that it should be reconsidered. In particular, the idea of rewriting the entire registry every time a change to a single entry in the registry occurs seems inappropriate. I fear that, for example, if an entry moves from RECOMMENDED TO IMPLEMENT to MUST IMPLEMENT, the history of how it got to that state will be lost. Futher, I think the RFC that made the algorithm RECOMMENDED TO IMPLEMENT, or MUST IMPLEMENT, or MUST NOT IMPLEMENT should be in the Reference column of the registry. Finally, I think referring to "Compliance" in the registry is wildly outside of IETF norms. Suggested changes:

a) Define the registry such that "Standards Action" (or maybe "IETF Review", i.e., IESG or WG document) is required for changes to the registry.

b) The "Reference" column in the registry must be to a document that defines the requirements level for DNSSec (MUST IMPLEMENT, MUST NOT IMPLEMENT, etc.) in addition to a definition of the algorithm. (They can be the same document, or more than one.)

c) Change the "Compliance to RFC TBD1" column to "Requirements level", which should reflect the contents of the document pointed to in (b).

Then all of this nonsense about rewriting the registry every time can be removed.

I concur with the concerns raised by Pete Resnick and consider the solution proposed by Robert Sparks to be a reasonable path forward. I would go farther and suggest that there is no need at all for an IANA registry, simply an RFC that lists the most up-to-date recommendations. Obsolete it when the recommendations change and it will be clear to those who implement and deploy DNSSEC which algorithms are appropriate at any given time.

Would the following approach achieve the goals the working group desires with this document?

Instead of keeping the Compliance information in the IANA registry as a new column, keep it entirely within this RFC. Add a sentence to the registry that says "See RFCXXXX for the IETF Consensus on which subset of these algorithms are required or recommended to implement or avoid." 

The RFC could then say that any changes to the RFC affecting that column should be done through obsoleting the RFC, replacing it with a new one.  That way, you would have a single document to refer to for conformance purposes, and a clear history of what changes were made. This would avoid Pete's concerns with the potential unintended consequences of the new proposed mechanics for maintaining the registry. It would also avoid an issue I have with the sentence that tries to constrain any updates to this RFC to _only_ use the obsoletes mechanism. It allows the working group to maintain any changes by only using a series of obsoletes, and guides future maintainers should the working group go away.  As long as the consensus was to only use obsoletes, that's exactly what will happen. If IETF consensus changes in the future, it would override any attempt to constrain the document maintenance anyway.

If a path like this was considered and rejected, documenting what it wouldn't achieve would help motivate the current proposal.

  The Gen-ART Review by Alexey Melnikov on 5-June-2011 raised some
  points that deserve a response.  I have not seen a response yet.

  Feel free to respond to all of the points raised by Alexey.  I have
  constructed these questions based on Alexey's review:

  (1) Looking at the difference between this document and the IANA
      registry <http://www.iana.org/assignments/dns-sec-alg-numbers/
      dns-sec-alg-numbers.xml>, I can see that they have different
      list of RFC numbers in the right column. Is this intentional?
      Is the list in this document correct?

  (2) As somebody else already pointed out during the IETF Last Call
      the range 123-251 is Reserved by RFC 6014, but this reservation
      is not mentioned in this document.  Why not?

  (3) Section 2.3 requires the replacement of the whole table.  It seems
      like overkill to replace the whole table every time a change to a
      single algorithm implementation status is needed.  This practice
      could result in mistakes and lead to exactly the kind of trouble
      that this document demonstrates.  Why is this the best approach for
      this IANA table?