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. 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? > > Registry entries 13-251 remains Unassigned. > > That would be a surprise, since the current registry at This is my fault; I missed it in my own review. The draft will be updated to reflect the changes to the registry made by RFC 6014 (which reserves 123-251). Thanks for catching this. A (as document shepherd) -- Andrew Sullivan ajs@xxxxxxxxxxxxxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf