Peter,
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.
Best regards,
Matthijs
On 09-02-2021 22:06, Peter van Dijk wrote:
Hello dnsop,
thank you to all who responded in the WGLC thread. After the discussion
I felt I had nothing to ask or add, so instead, here is a draft
revision that I feel addresses everything that was said.
(Matthijs, this revision changes the requirements back to MUST as that
feels like it more closely matches the majority opinion voiced, but I
added a section allowing for the incremental signer situation - please
let me know if this is workable for you.)
My understanding of the discussion is that the document failed to
address various assorted vagueness, and separations between developer
and operator concerns, and role differences between signers,
authoritatives and resolvers/validators, in the original documents.
Paul Hoffman provided a bunch of text clarifying 'what goes where' so
that this document can improve that situation, thanks Paul!
Changes in this version, as listed in the Document History section:
* document now updates resolver behaviour in 8198
* lots of extra text to clarify what behaviour goes where (thanks Paul
Hoffman)
* replace 'any' with 'each' (thanks Duane)
* upgraded requirement level to MUST, plus a note on incremental
signers
Your comments are, again, very much welcome.
On Tue, 2021-02-09 at 12:17 -0800, [email protected] wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.
Title : NSEC and NSEC3 TTLs and NSEC Aggressive Use
Author : Peter van Dijk
Filename : draft-ietf-dnsop-nsec-ttl-03.txt
Pages : 9
Date : 2021-02-09
Abstract:
Due to a combination of unfortunate wording in earlier documents,
aggressive use of NSEC and NSEC3 records may deny names far beyond
the intended lifetime of a denial. This document changes the
definition of the NSEC and NSEC3 TTL to correct that situation. This
document updates RFC 4034, RFC 4035, RFC 5155, and RFC 8198.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-nsec-ttl-03.html
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nsec-ttl-03
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Kind regards,
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
