Subject: [DNSOP] AD Review of: draft-ietf-dnsop-nsec3-guidance

From: Warren Kumari <[email-masked]>
Date: Wed, 13 Apr 2022 09:37:35 -0700

Hi there, authors (and WG),

Thank you for this document, I found it clear, useful, and an easy read.

I do have a few comments/nits; addressing these now should help the IETF LC
and IESG evaluation go more smoothly.

Please SHOUT loudly once you've had a chance to address these, and I'll
start IETF LC.

Comments / questions:
------------------------------------
Abstract:
"NSEC3 is a DNSSEC mechanism providing proof of non-existence by promising
there are no names that exist between two domainnames within a zone."

The "promising" in this feels a little odd to me — RFC4033 Sec 12 says that
"NSEC RRs **assert** which names do not exist..". RFC5155 talks about
"showing" that names don't exist — perhaps "by asserting that there are…"
would be better?

I'm (of course) happy to be told that "promising" was chosen for a reason
and that it's the right term.

Nits:
----------
Global:
The document uses the term 'domainname' - RFC8499 uses 'domain name'.
Looking through published RFCs, there are ~6200 instances of 'domain name',
~400 of 'domain-name' and <50 domainname (and many are in things like
ABNF). I'd suggest s/domainname/domain name/g.

Section 1 - Introduction
Use of the opt-out feature allow large registries to only sign as many NSEC3
[O] allow
[P] allows

 records as there are signed DS or other RRsets in the zone - with opt-out,
unsigned delegations don't require additional NSEC3 records.

[O] zone - with
[P] zone; with
[R] readability/grammar

Section 2.4 - Salt
This is true both when resigning the entire zone at once, or when
incrementally signing it in the background where the  new salt is only
activated once every name in the chain has been completed.
[O]: or
[P]: and
[C]: When using 'both' as a conjunction, it is 'both … and', not 'both …
or'; if this doesn't work, perhaps 'either … or'.

-----

Thank you again; I know that making edits to address nits can be annoying,
but we are expecting many people to read and review the document, and so
having it polished is important and polite (also, once people start
commenting on nits, they seem to continue :-) )
W

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 13 Apr 2022 14:04:05 -0400

Thanks, I think "asserting" is better.

> Nits:

Thanks.  No objections.

> Use of the opt-out feature allow large registries to only sign as many NSEC3

Yep.

> unsigned delegations don't require additional NSEC3 records.

Yep.

> or'; if this doesn't work, perhaps 'either … or'.

Yep.

> commenting on nits, they seem to continue :-) )

Much appreciated.

-- 
    Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 13 Apr 2022 14:04:05 -0400

Thanks.  No objections.

Yep.

Yep.

Yep.

Much appreciated.

-- 
    Viktor.

---

From: Wes Hardaker <[email-masked]>
Date: Sat, 16 Apr 2022 11:07:00 -0700

Warren Kumari <[email-masked]> writes:

> Please SHOUT loudly once you've had a chance to address these, and
> I'll start IETF LC.

Hi Warren,

Thanks for the comments and suggestions.  Looks good to us and I've made
the changes and published -08.
-- 
Wes Hardaker
USC/ISI