[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

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?