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

[Wes Hardaker <[e-mail]>]

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

> ** 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:

As discussed in other threads, the next version will be marked as
updating RFC5115.

> ** 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.

How's this instead:

    The following sections describes the background of the parameters for
    the NSEC3 and NSEC3PARAM resource record types.


> ** 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?

That's both a fair point but hard to fix.  In early versions of this
document, we used more strict wording in places (but not for this
case).  But in the end we're trying to address a sliding problem, and
there is no perfect line to be drawn.

How about if we end the paragraph with this:

    Operators considering the use of NSEC3 are advised to fully test
    their zones deployment architectures and authoritative servers under
    both regular operational loads to determine the tradeoffs using
    NSEC3 instead of NSEC.

> ** 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?

Good point.  I've changed it to this:

    Operators SHOULD NOT use a salt by indicating a zero-length salt value
    instead (represented as a "-" in the presentation format).

-- 
Wes Hardaker
USC/ISI