ietf
[Top] [All Lists]

Re: [dnsext] Last Call: <draft-ietf-dnsext-dnssec-registry-fixes-08.txt> (Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry) to Proposed Standard

2011-05-31 09:46:34

On May 31, 2011, at 4:12 AM, Andrew Sullivan wrote:

On Mon, May 30, 2011 at 06:53:38PM -0500, Pete Resnick wrote:

2.1.  Updates and Additions

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

 The description for assignment number 4 is changed to "Reserved until
 2020".

 The description for assignment number 9 is changed to "Reserved until
 2020".

 The description for assignment number 11 is changed to "Reserved
 until 2020".

OK, I give up....What happens in the year 2020? The end of the Mayan
calendar? Another prediction of the coming apocalypse? Oprah will
return?

Without the jokes: I find "due dates" in standards completely
ridiculous, without any purpose, and object strongly to them. I
cannot see what the dates add to the reservation of these code
points, and there is no explanation of dates (let alone these
*particular* dates) in the draft. These either need to be explained
in excruciating detail or removed.

These are all typecodes that have "leaked". 

In the case of 4, it was "reserved for elliptic curve" but it is clear
that there may be more than one elliptic curve algorithm and we can't
be sure which curve might be being tested with this.

In the case of 9 and 11, it was due to a keen implementer of SHA2.
The SHA2 specification originally left WGLC with two numbers for each
of SHA256 and SHA512.  This was to "alias" NSEC vs. NSEC3 (see how
SHA1 is handled).  After WGLC, some WG participants objected
vociferously, and it became clear that WG consensus was against such
aliasing.  But one implementation had already shipped with the four
assignments in place.

We picked 2020 as a time by which we figured any software using any of
this would have to have been updated.  My personal preference would
have been to specify that the four code points were all reserved until
all other code points were used, but that seemed too complicated a
rule so we picked 2020.

It sounds like Pete is saying "picking 2020 is complicated", so maybe the 
original idea ("until all other code points are used") is better.

Why do you think this all needs to be outlined in the draft?  Why do
such rules (which are, after all, just destined for a registry) need
to be given a rationale?  

So that someone evaluating the document can understand the rationale for the 
decision points in the document. Switching to "until all other code points are 
used" is self-explaining.

--Paul Hoffman

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf