Paul Wouters has entered the following ballot position for draft-ietf-dnsop-nsec3-guidance-08: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec3-guidance/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- #1: This document updates RFC 5155 but has no Updates: clause and no reference of this in the Abstract. In case this would not be seen as an Update:able offense, then the text "Note that this specification updates [RFC5155]" should be changed :) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Good document, nice to see operations feedback back into the IETF via a new BCP. comments: The algorithm field is not discussed by this document. Maybe add a reference pointer to RFC 8624 where algorithms for DNSSEC are discussed? The NSEC3PARAM flags field currently contains no flags, but individual NSEC3 records contain the "Opt-Out" flag This reads a little odd. Because the IANA NSEC3param registry lists 1 flat, the opt-out flag: https://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml#dnssec-nsec3-parameters-1 Maybe a sentence more clearly stating there is currently only one flag defined and that is opt-out and then discuss it. are encouraged to use a flags value of 0 (zero) And rewrite this to say "are encouraged to not use the opt-out flag" so if in the future we define another flag, we don't have to errata or Update: this document for this one line mentioning 0. The first hash is typically sufficient to discourage zone enumeration performed by "zone walking" an NSEC or NSEC3 chain. NSEC uses no hashing, so this sentence reads a little odd. Perhaps: The first hash with NSEC3 is typically sufficient to discourage zone enumeration performed by "zone walking" an unhashed NSEC chain. If NSEC3 must be used, then an iterations count of 0 MUST be used to alleviate computational burdens. I think we need a sentence here (or in the section 2.4 above) that explains the iterations count of 0 means 1 hashing operation is done. Eg it is an "extra iteration count". I'd like to prevent implementors from thinking nsec3 can be unhashed completely. Appendix D needs a note to the RFC Editor to remove itself. Appendix E lists a bunch of implementations. Normally, this would be placed in an Implementation Status section, that is removed before publication. Should this section really be contained within this document? nits: "within the Internet" ? I'd probably use "on the Internet" :) "tamper-resistance proof" -> "tamper-resistant proof" ? "repeating that hashing algorithm" -> "repeating that hashing using the same algorithm" Remove "ftp" from the example list in Section 2.3 as we deprecated it? The less credit we give it, the better :) in deploying both RFC4470 or NSEC3 This read awkward. Perhaps "in deploying either RFC4470 or NSEC3" "and the zone resigned." -> "and the full zone needs to be resigned." "and lower their default acceptable limits over time." -> "but lower their default acceptable limits over time." There is a weird rendering of {RFC8914} instead of [RFC8914] I think Petr Špaček would like to see his last name fixed :) _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop