Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-nsec-ttl-03.txt

[Paul Hoffman <[e-mail]>]

On Feb 10, 2021, at 12:03 AM, Matthijs Mekking <[e-mail]> wrote:
> 
> Personally I still think we shouldn't change these SHOULDs to MUSTs. Quoting from RFC 2119:
> 
> 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
>   definition is an absolute requirement of the specification.
> 
> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>   may exist valid reasons in particular circumstances to ignore a
>   particular item, but the full implications must be understood and
>   carefully weighed before choosing a different course.
> 
> I think the text you provided on incremental signers is such a valid reason why we should use SHOULD here instead of MUST.
> 
> If the WG consensus is that this does need to change to a MUST then I would like to request the following adaptations to the draft.
> 
> - The text should update the updates to include the exception. For
>  example:
> 
>   |  The TTL of the NSEC RR that is returned MUST be the lesser of the
>   |  MINIMUM field of the SOA record and the TTL of the SOA itself.
>   |  This matches the definition of the TTL for negative responses in
>   |  [RFC2308]. A signer MAY cause the TTL of the NSEC RR to have a
>   |  deviating value after the SOA record has been updated, to allow
>   |  for an incremental update of the NSEC chain.
> 
> - There should be a reason provided in the document why these SHOULD
>  keywords are changed to a MUST.

The new wording in each of the SHOULD-to-MUST change seems fine, even if repetitive. It is good to put clarifying text near the source.

The SHOULD was changed to MUST for interoperability. That is, a resolver would not know whether this auth server was following the wiggly part of the spec without evaluating every response. The fact that the earlier documents used SHOULD without any qualification was a mistake, and we don't have to rub those authors' noses in it.

--Paul Hoffman