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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
