[DNSOP] AD Review of: draft-ietf-dnsop-nsec3-guidance
Warren Kumari <warren@kumari.net> Wed, 13 April 2022 16:37 UTC
Return-Path: <warren@kumari.net>
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 3B0473A17DC for <dnsop@ietfa.amsl.com>; Wed, 13 Apr 2022 09:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.net
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 s_Oa7GyDmlJ1 for <dnsop@ietfa.amsl.com>; Wed, 13 Apr 2022 09:37:40 -0700 (PDT)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 876AC3A17DB for <dnsop@ietf.org>; Wed, 13 Apr 2022 09:37:40 -0700 (PDT)
Received: by mail-ej1-x633.google.com with SMTP id lc2so5057044ejb.12 for <dnsop@ietf.org>; Wed, 13 Apr 2022 09:37:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=56WmDZUEh1oTqb3AYmNgnkig/jOdtr8zUBuOXILCysM=; b=cd1q8QbN7XjQcnR98QjcurDoQHqGWhb5qvLdH5vMURNHLOx8n/a+ePttQz4BISzbpz ojBGilgnZUoKBaMcLPikOX4CyorYolAypqZGYTsRWsoJ5k9QO6rw1Tfug7PNk/ym0cdX mxTKNtDTLrvs5umIMunfNNLb6nqqy4zAPLZIPVz1GxPncAKrA7NbM/tyw70teEnyHguh zbONiOnSJ13pApXbMulyzvTnq0QGzRRVzqPA4rjQ5O9ghmWz6wuWUOZoQvbHHnQVWX2k 00vmCWbnR32ORsuK/clkA2n7lhJLBDvrCkuSfWTsNDybW2rzI5ZJtZwcKkh0j3si/q5Q /f4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=56WmDZUEh1oTqb3AYmNgnkig/jOdtr8zUBuOXILCysM=; b=jMEbwUwsfuppHX6gECfJy9PSwD9lT81M+hs/Ci5Cy+GIwGt0tP3fUXVNitxY9zoBdy tlkHNEP/6PJkNB1bXnWIWuFAxHlhK+6TH00P3V7UzSgS4GcORGvrhtPzVPxZ4jdpEaiX MjpfbOXVlikdgXJcDnh8+RkVHk82lOmjR107otVLsgMdLOLaXsB9TMQ8oa8SqKvMrazM DnRkF9TQXISlYHD7nA8SIVslneOuCbFuo4ctBLjl1uKnvsJcph2v4ZZiuHftgJovNoNJ /xbZC6oYi87mr8r8dlhTedRJB4VgGJ2ehMsuak8rqAkK7KHDAQmm1fhPLbxfS15Mdczn 2Nlw==
X-Gm-Message-State: AOAM531si/wnZRHyNFfL1Fbf/XcedheuawalJBaGJcpeE53oO7HERU1/ VeScey9QGSvZ9pAVOck10oBgVs5lVcvyvxRTyG4C+A==
X-Google-Smtp-Source: ABdhPJzDL0hsIO+Rb/S6sYF1c++7qtmopUVxbvxnzBzhUZdOwCGAgCMk//n+hRcsxUdh8gbmgUYzv47qcq9yvMnxVys=
X-Received: by 2002:a17:907:7b92:b0:6db:71f1:fc20 with SMTP id ne18-20020a1709077b9200b006db71f1fc20mr38443294ejc.343.1649867857086; Wed, 13 Apr 2022 09:37:37 -0700 (PDT)
Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Wed, 13 Apr 2022 09:37:35 -0700
Mime-Version: 1.0
X-Superhuman-ID: l1xspkgk.fea655e2-c3d0-4485-bca9-6e4ef0b6d877
X-Superhuman-Draft-ID: draft009dd8d3b63c8c55
X-Superhuman-Thread-ID: draft00e683a07df3c2ee
X-Mailer: Superhuman Desktop (2022-04-12T22:06:10Z)
From: Warren Kumari <warren@kumari.net>
Date: Wed, 13 Apr 2022 09:37:35 -0700
Message-ID: <CAHw9_i++SupWXyLsyksO3CYa5r9ukJbs1=Of9VmnSDXycNRWYA@mail.gmail.com>
To: draft-ietf-dnsop-nsec3-guidance@ietf.org, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008c650905dc8bcbb6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/MpW5sqXC8FJarh8KwDoG8P94pRs>
Subject: [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 16:37:45 -0000
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] AD Review of: draft-ietf-dnsop-nsec3-guid… Warren Kumari
- Re: [DNSOP] AD Review of: draft-ietf-dnsop-nsec3-… Viktor Dukhovni
- Re: [DNSOP] AD Review of: draft-ietf-dnsop-nsec3-… Wes Hardaker