draft-ietf-dnsext-dnssec-alg-allocation-02.txt   draft-ietf-dnsext-dnssec-alg-allocation-03.txt 
Network Working Group P. Hoffman Network Working Group P. Hoffman
Internet-Draft VPN Consortium Internet-Draft VPN Consortium
Updates: 2535, 3755, 4034 January 25, 2010 Updates: 2535, 3755, 4034 March 22, 2010
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: July 29, 2010 Expires: September 23, 2010
Cryptographic Algorithm Identifier Allocation for DNSSEC Cryptographic Algorithm Identifier Allocation for DNSSEC
draft-ietf-dnsext-dnssec-alg-allocation-02 draft-ietf-dnsext-dnssec-alg-allocation-03
Abstract Abstract
This document specifies how DNSSEC cryptographic algorithm This document specifies how DNSSEC cryptographic algorithm
identifiers in the IANA registries are allocated. It changes the identifiers in the IANA registries are allocated. It changes the
requirement from "standard required" to "RFC required". It does not requirement from "standard required" to "RFC required". It does not
change the list of algorithms that are recommended or required for change the list of algorithms that are recommended or required for
DNSSEC implementations. DNSSEC implementations.
Status of this Memo Status of this Memo
skipping to change at page 1, line 42 skipping to change at line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 29, 2010. This Internet-Draft will expire on September 23, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 18 skipping to change at line 109
o Although the size of the registry is restricted (about 250 o Although the size of the registry is restricted (about 250
entries), new algorithms are proposed infrequently. It could entries), new algorithms are proposed infrequently. It could
easily be many decades before there is any reason to consider easily be many decades before there is any reason to consider
restricting the registry again. restricting the registry again.
Some developers will care about the standards level of the RFCs that Some developers will care about the standards level of the RFCs that
are in the registry. The registry should be updated to reflect the are in the registry. The registry should be updated to reflect the
current standards level of each algorithm listed. current standards level of each algorithm listed.
To address concerns about the registry eventually filling up, the To address concerns about the registry eventually filling up, the
IETF SHOULD re-evaluate the requirements for entry into this registry IETF should re-evaluate the requirements for entry into this registry
when approximately 120 of the registry entries have been assigned. when approximately 120 of the registry entries have been assigned.
That evaluation may lead to tighter restrictions or a new mechanism That evaluation may lead to tighter restrictions or a new mechanism
for extending the size of the registry. In order to make this for extending the size of the registry. In order to make this
evaluation more likely, IANA is requested to mark about half of the evaluation more likely, IANA is requested to mark about half of the
currently-available entries as "Reserved" in order to make the timing currently-available entries as "Reserved" in order to make the timing
for that re-evaluation more apparent. for that re-evaluation more apparent.
The private-use values, 253 and 254, are still useful for developers The private-use values, 253 and 254, are still useful for developers
who want to test, in private, algorithms for which there is no RFC. who want to test, in private, algorithms for which there is no RFC.
This document does not change the semantics of those two values. This document does not change the semantics of those two values.
skipping to change at page 4, line 16 skipping to change at line 154
4. IANA Considerations 4. IANA Considerations
This document updates allocation requirements for unassigned values This document updates allocation requirements for unassigned values
in the "Domain Name System Security (DNSSEC) Algorithm Numbers" in the "Domain Name System Security (DNSSEC) Algorithm Numbers"
registry located at http://www.iana.org/assignments/ registry located at http://www.iana.org/assignments/
dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml, in the sub-registry dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml, in the sub-registry
titled "DNS Security Algorithm Numbers". The registration procedure titled "DNS Security Algorithm Numbers". The registration procedure
for values that are assigned after this document is published is "RFC for values that are assigned after this document is published is "RFC
Required". Required".
IANA is requested to mark values 123 through 250 as "Reserved". IANA is requested to mark values 123 through 251 as "Reserved". The
registry should note that this reservation is made in [[ THIS RFC ]]]
so that when most of the unreserved values are taken, the future IANA
and users will have an easy pointer to where the reservation
originated and its purpose.
IANA is requested to add a textual notation to the "References" IANA is requested to add a textual notation to the "References"
column in the registry that gives the current standards status for column in the registry that gives the current standards status for
each RFC that is listed in the registry. each RFC that is listed in the registry.
5. Security Considerations 5. Security Considerations
An algorithm described in an RFC that is not on the Standards Track An algorithm described in an RFC that is not on the Standards Track
may have weaker security than one that is on the Standards Track; in may have weaker security than one that is on the Standards Track; in
fact, that may be the reason that the algorithm was not allowed on fact, that may be the reason that the algorithm was not allowed on
skipping to change at page 6, line 26 skipping to change at line 258
In the expectations for implementers, added "This document does not In the expectations for implementers, added "This document does not
change the requirements for when an algorithm because mandatory to change the requirements for when an algorithm because mandatory to
implement. Such requirements should come in a separate, focused implement. Such requirements should come in a separate, focused
document." document."
B.4. Differences between draft-ietf-dnsext-dnssec-alg-allocation-01 and B.4. Differences between draft-ietf-dnsext-dnssec-alg-allocation-01 and
draft-ietf-dnsext-dnssec-alg-allocation-02 draft-ietf-dnsext-dnssec-alg-allocation-02
Reworded the first bullet in Section 2 to remove "government". Reworded the first bullet in Section 2 to remove "government".
B.5. Differences between draft-ietf-dnsext-dnssec-alg-allocation-02 and
draft-ietf-dnsext-dnssec-alg-allocation-03
Changed "SHOULD" to "should" in section 2.
In section 4, changed the range of "resevered" codes from "123
through 250" to "123 through 251".
Added to the IANA Considerations: "The registry should note that this
reservation is made in [[ THIS RFC ]]] so that when most of the
unreserved values are taken, the future IANA and users will have an
easy pointer to where the reservation originated and its purpose."
Author's Address Author's Address
Paul Hoffman Paul Hoffman
VPN Consortium VPN Consortium
Email: paul.hoffman@vpnc.org Email: paul.hoffman@vpnc.org
 End of changes. 7 change blocks. 
6 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/