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

Viktor Dukhovni <viktor@dukhovni.org> Wed, 13 April 2022 18:04 UTC

Return-Path: <viktor@dukhovni.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CA53A1D9D; Wed, 13 Apr 2022 11:04:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9Mk1r9d-1W2; Wed, 13 Apr 2022 11:04:07 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F05D83A1D9A; Wed, 13 Apr 2022 11:04:06 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 15FA0E6713; Wed, 13 Apr 2022 14:04:05 -0400 (EDT)
Date: Wed, 13 Apr 2022 14:04:05 -0400
From: Viktor Dukhovni <viktor@dukhovni.org>
To: Warren Kumari <warren@kumari.net>
Cc: draft-ietf-dnsop-nsec3-guidance@ietf.org, dnsop <dnsop@ietf.org>
Message-ID: <YlcQlfa5N9dpyfng@straasha.imrryr.org>
References: <CAHw9_i++SupWXyLsyksO3CYa5r9ukJbs1=Of9VmnSDXycNRWYA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAHw9_i++SupWXyLsyksO3CYa5r9ukJbs1=Of9VmnSDXycNRWYA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/JIF94bkkbd8Ig6skYAN1xut_PsU>
Subject: Re: [DNSOP] AD Review of: draft-ietf-dnsop-nsec3-guidance
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2022 18:04:09 -0000

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.