Subject: [dnsext] draft-ietf-dnsext-dnssec-registry-fixes-03

From: Alfred Hönes <[email-masked]>
Date: Fri, 16 Apr 2010 11:00:11 +0200 (MESZ)

Hello,
I have revisited the DNSSEC Registry Fixes draft
that you have updated this week.

Below are a couple of editorial notes that hopefully will help to
improve the memo further.

(1)  running page headers

I suggest to make the "short title" of the document more specific:

     s/IANA-Registry-Fix/DNSSEC Registry Fixes/

(2)  section structure

According to the authoring guidelines valid since several years,
"Requirements Language" shall be a numbered section, but not
the first one of a document.
I suggest to move it from the boilerplate part of the draft into
a new section 1.1.

(3)  Copyright Notice

IMO, the draft does not borrow substantially from pre-5378 material
(IANA registry content does not fall under the pre-5378 regime, and
all of {author, contributors/reviewers} operate under RFC 5378 rules).
So I suggest to get rid of the pre-5378 exceptional clause
(3rd paragraph of the Copyright Notice) -- its use should remain an
exceptional case that needs evidence to justify, according to the TLP.

(4)  Outline of section 2 and acronym expansion

According to the RFC Editor material, "DNS" is not one of the
"very well known" acronyms that do not need expansion on first use.

Therefore, I suggest to expand "DNS" in the first sentence of section 1:

|  The Domain Name System (DNS) Security Extensions (DNSSEC, [RFC4033],
|  [RFC4034], and [RFC4034]) uses ...

Then, "DNS" can be used freely in the text.

In particular, the (sub)section headlines of section 2 should be
spell-corrected, shortened, and made more specific.
I propose to change the outline:
                                             v
|  2.  DNS Security Algorithm Number Subregisitry Fixes
|    2.1.  Individual Domain Name System Security (DNSSEC)
|          Algorithm Number Registry Entry Fixes
|    2.2.  Domain Name System Security (DNSSEC) Algorithm Number
|          Registry

to:

|  2.  DNS Security Algorithm Number Subregistry Fixes
|    2.1.  Individual Fixes
|    2.2.  Updated Registry Snapshot

(5)  Section 2.1

The adaption to the updated registry content has introduced confusing
text.  Since code point 11 now is split off the range 13-251 anyway,
no change is needed for it and it should not be listed as a change
any more; the previous entry for 11-251, that could be counted for the
"three entries" being changed does not exist any more.

Further, "allocation" for IANA regularly means sub-delegation of an
entire range of code points to another entity; "assignment" is the
precise term for a single code point being handed out for some purpose.
Therefore, the term "allocation" should be replaced by "assignment".

Therefore, I suggest to revise the content of section 2.1 as follows:

   This document changes three entries in the Domain Name System
   Security (DNSSEC) Algorithm Registry.  They are:

|  The description for allocation number 4 is changed to "Reserved until
|  2020".
|
|  The description for allocation number 9 is changed to "Reserved until
|  2020".
|
|  The description for numbers 11, 13-251 are changed from Unassigned to
|  the following:
|
|  *  Allocation number 11 is changed to "Reserved until 2020".
|
|  *  Allocations 13-251 remains Unassigned.

   The status of RSASHA1-NSEC3-SHA1 and DSA-NSEC3-SHA1 are both set to
   DISCRETIONARY.  The status of RSA/SHA-256 and RSA/SHA-512 are set to
   ENCOURAGED as it is believed that these algorithms will replace older
   algorithms (e.g.  RSA/SHA-1) that have a perceived weakness in their
   hash algorithm (SHA-1).
---
   This document changes three entries in the Domain Name System
   Security (DNSSEC) Algorithm Registry.  They are:

|  o  The description for assignment number 4 is changed to
|     "Reserved until 2020".
|
|  o  The description for assignment number 9 is changed to
|     "Reserved until 2020".
|
|  o  The description for assignment number 11 is changed to
|     "Reserved until 2020".

   The status of RSASHA1-NSEC3-SHA1 and DSA-NSEC3-SHA1 are both set to
   DISCRETIONARY.  The status of RSA/SHA-256 and RSA/SHA-512 are set to
   ENCOURAGED as it is believed that these algorithms will replace older
   algorithms (e.g.  RSA/SHA-1) that have a perceived weakness in their
   hash algorithm (SHA-1).

(6)  Section 3

Similar restructuring and clarification is needed for section 3.

I suggest to modify the first part of the section as follows:

   This document consists entirely of DNS IANA Considerations and
   includes the following changes detailed in Section 2.1:

|  The description of allocation 4 is changed from "Reserved for ECC" to
|  "Reserved until 2020".
|
|  The description of allocation 9 is changed from "Unassigned" to
|  "Reserved until 2020".
|
|  The description for numbers 11, 13-251 are changed from Unassigned to
|  the following:
|
|  *  Allocation number 11 is changed to "Reserved until 2020".
|
|  *  Allocations 13-251 remains Unassigned.
---
   This document consists entirely of DNS IANA Considerations and
   includes the following changes detailed in Section 2.1:

|  o  The description of assignment 4 is changed from "Reserved for ECC"
|     to "Reserved until 2020".
|
|  o  The description of assignment 9 is changed from "Unassigned" to
|     "Reserved until 2020".
|
|  o  The description of assignment 11 is changed from "Unassigned" to
|     "Reserved until 2020".

The second-to-last paragraph of section 3 somehow misrepresents the
FIPS updates it refers to.  Both FIPS 180 and FIPS 186 have been
_amended_ -- so it is not correct to state that their "main content"
has not changed; what counts for the current context is that the
"_relevant_ content" has not changed.

Therefore, I suggest to change:

   The references to FIPS 180 and FIPS 186 have been updated (to FIPS
   180-3 and FIPS 186-3 respectively) to reflect the latest versions.
|  These revisions are maintenance updates and the main content of the
   FIPS documents have not changed.
---
   The references to FIPS 180 and FIPS 186 have been updated (to FIPS
   180-3 and FIPS 186-3 respectively) to reflect the latest versions.
|  These revisions are maintenance updates and the relevant content of
   the FIPS documents have not changed.

(7)  Section 5.2

The registry snapshot in Setcion 2.2 contains a pointer to the
GOST DNSSEC memo as "[RFCTBD]".
In order to not forget the pending update, a corresponding
Informative Reference  entry should be added to section 5.2.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+