Subject: [dnsext] Summary of WGLC on draft-registry-fixes

From: "Rose, Scott W." <[email-masked]>
Date: Thu, 21 Jan 2010 13:21:05 -0500

Proposed resolution to LC comments for
draft-ietf-dnsext-dnssec-registry-fixes

1.    Wording Change:  ³implementation status² not correct. (Brian
Wellington)

Fixed.  Text now uses the term ³requirement status² and ³implementation
requirement² as necessary.

2.    Default status for newly specified algorithms based on document track
(Sam W)

Fixed.  Text now reads:
  ³The requirement status for all new algorithms will be DISCRETIONARY
   unless a Standards Track document changes that (possibly including
   the Standards Track document defining the algorithm).  Only a
   Standards Track document may make an algorithm ENCOURAGED or
   MANDATORY or remove the MANDATORY or ENCOURAGED designation (to
   DISCOURAGED or OBSOLETE for example).²

This is also dependent on the new keywords draft.
 
3.    Text on how current status levels were set (Sam W)

Possibly fixed.  Text indicates most of the status levels were obtained from
RFC 4034. Status of RSA/SHA-256 was set to ENCOURAGED as it is believed it
may become MANDATORY at some time.  The original status of RSA/MD5 is murky,
but OBSOLETE is the best term I guess:
 
  ³There are additional fixes to entries that are described in sub-
   section 2.1. The overall new registry table is in sub-section 2.2.
   The values for the status were obtained from [RFC4034] with updates
   for algorithms specified after the original DNSSEC specification.
   The status of algorithms marked OPTIONAL in [RFC4034] are changed to
   DISCRETIONARY as defined in
   [I-D.ogud-iana-protocol-maintenance-words].  The status of algorithms
   marked NOT RECOMMENDED in [RFC4034] are changed to OBSOLETE as
   defined in [I-D.ogud-iana-protocol-maintenance-words].²
 
4.  Not from a comment but:  References in the table were updated to remove
obsolete RFC¹s.  Mainly because idnits was complaining.  The ones removed
were RFC 3110, RFC 3755, and RFC 3537.

Did I forget anything?  There is the alg-allocation comment about reserving
some space, possibly requiring updating this doc to reflect that.

Scott
===================================
Scott Rose
NIST
[email-masked]
ph: +1 301-975-8439
Google Voice: +1-571-249-3671

http://www.dnsops.gov/
===================================