All, I have read it and I like it. Still there are I think some things that need to be addressed:
- On enabling DNSSEC via CDS/CDNSKEY: most of the policies assume some sort of communication channel between the child zone operator and parent zone operator, while in fact RFC 7344 registers new resource records because we assume there is no such channel. CDS/CDNSKEY records are put in the child zone to signal the desired DS RRset in the parent. The child can only hope that the parent will pick it up and the only way to get confirmation is to query the parent zone. So how would the parent "send a notification requesting a confirmation" (section 3.2) or "instruct the requestor to insert some record into the child domain" (section 3.4)? It could use the same CDS approach and put it in some new resource records in the parent zone (just stick it in the DNS ;)). Anyway, if we assume there is no other communication channel, the document should provide more details on where to put this notification or challenge such that the child can pick it up. If we say there is a different communication channel, there needs to be more details about how that channel looks. Or we should just keep saying it is a hard problem and leave it out of scope (and solve it in yet another document). - On using 0 as the DNSSEC Delete Algorithm in CDS and CDNSKEY records, I think that is fine and is a cleaner approach then using a non-zero algorithm number. The document could perhaps make it explicit it is meant only to be used in CDS and CDNSKEY records, not DS/DNSKEY. - The document suggests that when disabling DNSSEC, only the fixed fields should appear in the records. Do you mean fixed length fields? - Leaving out the Digest/Public Key field changes the definition of the CDS and CDNSKEY records: No longer are their formats identical to the DS/DNSKEY records. So at minimal this updates RFC 7344. Existing versions of DNS server that support RFC 7344 will likely not be able to load a CDS record as described in section 4 and consider it malformed. Finally, two nits: - Nit: The abstract gives the reader the feeling that initial trust is a very hard problem, but then section 1.2 says it can be easily solved with some simplifying assumptions :) Perhaps you meant to say that it is hard to solve technically unless some reasonable policies can be assumed. - Nit: The first use mentioned in section 2 is just KSK Rollover. What does explaining the different operations add to the document? Best regards, Matthijs On 04/04/2016 05:25 AM, Ólafur Guðmundsson wrote: > > Dear colleagues, > a new version of the document has been posted that fixes few minor > grammatical and spelling errors. > > this is version 02 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-dnsop-maintain-ds-02.txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/ > Htmlized: https://tools.ietf.org/html/draft-ietf-dnsop-maintain-ds-02 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintain-ds-02 > > Olafur > > On Sun, Apr 3, 2016 at 6:29 PM, Tim Wicinski <tjw.i...@gmail.com > <mailto:tjw.i...@gmail.com>> wrote: > > This starts a Working Group Last Call for draft-ietf-dnsop-maintain-ds > > Current versions of the draft is available here: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/ > > Please review the draft and offer relevant comments. Also, if > someone feels the document is *not* ready for publication, please > speak out with your reasons. > > Feel free to show up at DNSOP's Wednesday session and voice your > approval or disapproval. > > This starts a two week Working Group Last Call process, and ends on > 17 April 2016 > > thanks > tim > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org <mailto:DNSOP@ietf.org> > https://www.ietf.org/mailman/listinfo/dnsop > > > > > _______________________________________________ > 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
