On Wed, Apr 13, 2022 at 09:37:35AM -0700, Warren Kumari wrote:
> ------------------------------------
> 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.
Thanks, I think "asserting" is better.
> 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.
Thanks. No objections.
> Section 1 - Introduction
> Use of the opt-out feature allow large registries to only sign as many NSEC3
> [O] allow
> [P] allows
Yep.
> 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
Yep.
> 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'.
Yep.
> 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 :-) )
Much appreciated.
--
Viktor.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
