Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-nsec3-guidance-08: No Objection
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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** I support Paul Wouter’s DISCUSS position. Like Alvaro and Francesca also commented, this document appears to be changing the behavior of RFC5155. It should formally update it in the meta data. Specifically: -- The language in Section 3.2. appears to “weaken” the guidance in Section 10.3 of RFC5155 -- Section 3.2 also seems to explicitly say it is updating RFC5155 with “[n]ote that this specification updates [RFC5155] …” ** Section 2. The following sections describe recommendations for setting parameters for NSEC3 and NSEC3PARAM. I don’t believe this is accurate. There are few tangible recommendations about iterations or salts in this section. That’s in Section 3. ** Section 2.2. In general, NSEC3 with the Opt-Out flag enabled should only be used in large, highly dynamic zones with a small percentage of signed delegations. Operationally, this allows for fewer signature creations when new delegations are inserted into a zone. This is typically only necessary for extremely large registration points providing zone updates faster than real-time signing allows or when using memory-constrained hardware Qualitative scales such as “large … dynamic zones” and “extremely large registration points” used. Can the operational experience informing these statements be cited to suggest the scale? ** Section 3.1. Operators are encouraged to forgo using a salt entirely by using a zero-length salt value instead (represented as a "-" in the presentation format). Section 2.4 seemed to take a stronger position on the lack of utility of the salt. Is there a reason normative language isn’t being used? _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
