The completed sections of draft looks good to me, with one exception. I think we might need to allow for more than one NSEC5 key and chain, during a transition. Otherwise it might be impossible to later create a reasonable transition process. This might require us to tag the NSEC5 records with an id, so that the chains and matching keys can be distinguished. Better to do this now than to try to retrofit later.
A few minor corrections or suggestions: section 1.1 "Rationale" "As side-effect, however, the NSEC chain existence allows for the enumeration of the zone's contents by querying for names immediately individual RRs in the chain;" -- Seems to be missing a word between "immediately" and "individual" section 1.1 "Rationale" "The NSEC5 is not intended to replace NSEC or NSEC3. It is designed as an alternative mechanisms for authenticated denial of existence." -- I think "mechanisms" should be "mechanism" (singular, not plural). section 4 "NSEC5 Algorithms" "The algorithms used for NSEC5 authenticated denial are independent on the algorithms used for DNSSEC signing." -- Change "independent on" to "independent of" ? -- Bob Harold hostmaster, UMnet, ITcom Information and Technology Services (ITS) rharo...@umich.edu 734-647-6524 desk On Mon, Mar 23, 2015 at 11:15 AM, Jan Včelák <jan.vce...@nic.cz> wrote: > Hi, > > I just submitted an updated NSEC5 draft into the data tracker. The most > significant change is fixing the NSEC5 key rollover mechanism; the rest > are just typo fixes and small clarifications in terminology. > > http://datatracker.ietf.org/doc/draft-vcelak-nsec5/ > > Also, I will have a 10 minute talk about the draft on the Security Area > Open Meeting on Thursday. You are welcome to come. > > Regards, > > Jan > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
