> > Colleagues, Shortly before the cutt-off I submitted version 3. In this mail I want to raise a number of points that are up for discussion in Maastricht (or on the list). For the Maastricht meeting I plan to use _no_ slides but go through the points one by one and discuss/hum etc. The document can be found at: http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-03 And the diffs between this and the previous version are highlighted here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc4641bis-03.txt Based on the feedback during last IETF I've tried to differ the tone of the document. The general approach is that the document gives the considerations and motivations for different operational choices and has weakened some of its earlier recommendations. Specifically the arguments for splitting key and zone signing key or using a 'single type signing scheme' have had some attention. One general comment, when you review please do not review for style/typos quite yet. I've received a set of corrections that I've already applied on the trunk[*]. Please review for content now and wait for typos and other editorial nits review till version 4 appeared. - Point 1: Is the set of arguments presented for major operational choices (e.g. single versus ksk-zsk split, and key effectivity period) complete and are the arguments fairly represented? Addressing all these arguments and considerations has created a fairly long document. In fact the choice has been to make the document comprehensive in presenting the considerations while not giving strong recommendations one way or another. This causes the document to be rather long and raises the question of the target audience. Also see: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/KSK-ZSK-Split - Point 2: Should this document try to give strong recommendations or should a separate document (set) be made that gives recommendations for certain operational environments (e.g. BCP for root, BCP for TLD, BCP for enterprise)? I am looking for specific guidance but as a straw man for consensus: This document should not give strong recommendations but provide comprehensive arguments (like it does now); development of recommendations is left for later, either in a follow up (RFC4641bis-bis) or as a set of separate documents) -Point 3: There have also been some questions about what audience the document is trying to address. The document is targeted to the 'the authoritative side of the DNS equation'. Is that indeed what the WG wants? If so is that clear enough from the document. (Please send concrete suggestions to improve if not). If there is consensus that the document talks to the authoritative side then the chairs may want to ask the question as to whether there a need for separate guidance for resolver operators, and maybe even ask for volunteers ;-) The following points are more detailed. -Point 4: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration Version 3 of the document has tried to address these issues (pending a conclusion of point 3 above) but in order to close this issue I would like to know whether "the document [is] in any way restrictive on not using 5011, or is its consideration for advising RFC5011 to strong?" Silence on this point will be taken as finding the right balance. -Point 5: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Signature_validity Text added in 4.4.2, is this text satisfactory http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-03#section-4.4.2 The paragraph talks about a Maximum signature validity and Minimum validity period in fairly broad terms. It also provides motivations for differentiating Signature Validity periods for different RRsets in a zone, those motivations are few and week. Again, is this section complete in providing arguments and are the arguments fair? If not, what are concrete recommendations for improvement. - Point 6 Is Appendix B useful? Or drop it? - Point 7 Any objections on closing the following: - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Key_algorithm_roll - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ZSK-roll-frequency (take a look at 3.1.1. Motivations for the KSK and ZSK Separation, the last paragraphs) - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/differentiation_trustanchor_parent During the authoring of versions 2 and 3 of the document the first issues have been addressed. The differentiation between trustanchor-parent situation has been taken into account but not as drastically as Paul suggested. I believe this issue can be closed after review of version 3 of the document. - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/discussion_of_timescales - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/non-cooperative-registrars - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/rollover_assumptions - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_and_parent_keys I think this issue has become obsolete. Since some of these issues are hard to relate to version 3 of the draft I would like to take the following approach for version 4 of the I-D: mark all above issues as completed, unless I receive further clarification on why I shouldn't (possibly with suggested text), open new issues relative to version 3 of the draft, address those in version 4. My target is to have version 4 of the document last call ready. That is all major issues out of the way, and only nit-fixing. I am aware of a number of editorial nits[*] --Olaf [*] See http://www.secret-wg.org/draft-ietf-dnsop-rfc4641bis.txt for a snapshot of the living document and http://tiny.cc/6sllt for the difference between the living document and the draft version 3 as it lives in the repository. ________________________________________________________ Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
