Cryptographic Algorithm Identifier Allocation for DNSSEC
RFC 6014

[Ballot comment]
It is my understanding that the IANA intends to make the .xml files canonical and to deprecate the .xhtml files, so the pointer to "http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml" probably needs to change to "http://www.iana.org/assignments/dns-sec-alg-numbers/" (the latter URI currently redirects to the .xml file).

I assume that the IANA signed off on the need to add the current standards status of each referenced RFC to the registry, and presumably to update the registry if and when a referenced RFC is obsoleted (or, possibly, updated) by a new RFC.

[Ballot comment]
It is my understanding that the IANA intends to make the .xml files canonical and to deprecate the .xhtml files, so the pointer to "http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml" probably needs to change to "http://www.iana.org/assignments/dns-sec-alg-numbers/"

Has the IANA signed off on the need to add the current standards status of each referenced RFC to the registry, and presumably to update the registry if and when the standards status changes, a referenced RFC is obsoleted by a new RFC, etc.?

[Ballot discuss]
IANA Considerations - 'IANA is requested to mark values 123 through 250 as "Reserved".'

As the 'Resrved lable is applied only in order to trigger a review of the policy of administration of this registry in case entries are consumed at a higher rate than expected, I think that a comment should be made that the reservation is made per RFC XXXX (where XXXX is the number of this RFC when approved) so then when this event happens future IANA and users generation will have an easy pointer to where this came from.

[Ballot discuss]
DISCUSS DISCUSS. I'd like to ask the AD to have a look at Sam Weilers, comments from Jan 9 and resulting threads. My read of the list is that there was consensus that non Standards Track RFC could not specify a MANDATORY algorithm and I'd like to understand if I misreading the consensus here. If there is consensus for this, the I think this draft needs to reflect that consensus and would agree with Sam Weiler's email of March 2 that was sent to IESG and secdir list.

[Ballot comment]
INTRODUCTION, paragraph 2:
> Updates: 2535, 3755, 4034 (if approved)

  It's a bit odd to update RFCs that have already been obsoleted (2535,
  3755).

[Ballot comment]
INTRODUCTION, paragraph 2:
> Updates: 2535, 3755, 4034 (if approved)

  It's a bit odd to update RFCs that have already been obsoleted (2535,
  3755).

[Ballot discuss]
In section 2, the document says:
  >
  > ..., the IETF SHOULD re-evaluate the requirements for entry into
  > this registry when approximately 120 of the registry entries have
  > been assigned.
  >
  RFC 2119 does not apply to this statement: s/SHOULD/should/
  If it did, then a reference to RFC 2119 would be needed.

  Section 4 reserves values 123 through 250 in the IANA registry:
  http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
  It should reserve through 251.

IANA comments:

Upon approval of this document, IANA will make the following changes
in the "DNS Security Algorithm Numbers" registry at
http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml

NOTE: Any future document that makes one of these references historic
should ask us to update the registry accordingly. This should be
mentioned in the IANA Considerations section. We don't have a process
for marking newly historic references obsolete.

OLD:
Reference: [RFC4034][RFC3755]
Registration Procedures: IETF Standards Action

NEW:
Reference: [RFC4034][RFC3755][RFC-dnsext-dnssec-alg-allocation-02]
Registration Procedures: RFC Required

NEW:
Number Description ... Reference
123-250 Reserved [RFC-dnsext-dnssec-alg-allocation-02]

NEW:
A new informational word is added to each reference to reflect the
current status(Proposed, Draft, Standard, Informational, Experimental,
...) of the referenced RFC.

(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. I have reviewed the document, and I believe it is
ready for forwarding.

(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 document has been adequately reviewed in my opinion.

(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?

No.

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

No.

(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?

The reviews were uniformly positive, and suggested changes from WGLC
were incorporated.

(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?

There is an RFC 2119-style SHOULD that will be fixed to be lower case
after IETF last call. The document currently uses 12 Sept 2009
boilerplate. It includes a disclaimer for for pre-RFC537 that is
appropriate, I believe, because there may have been discussions of
this approach when the current (standards track) requirement for
algorithm assignment happened.

(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 split appropriately. Some Normative references are
to obsolete RFCs, but they need to be because of the way the IANA
registry is defined.

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

(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 document alters the requirements for DNSSEC algorithm
identifiers from "standards action" to "RFC required".

Working Group Summary

The DNS Extensions Working Group reviewed the document. There
was considerable discussion at the time of adoption, but
almost exclusively support at the time of WGLC. Some LC
comments resulted in a substantive change, which was to
reserve a portion of the registry so as to avoid exhaustion.

Document Quality

The change suggested during WGLC ensures that the IANA
registry will not be exhausted because nobody thought to
revisit these procedures if the assumption about infrequent
addition of algorithms turns out to be false.