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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]