Re: [DNSOP] Alissa Cooper's Discuss on draft-ietf-dnsop-attrleaf-fix-04: (with DISCUSS and COMMENT)

Alissa Cooper <> Wed, 10 October 2018 18:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D37F1274D0; Wed, 10 Oct 2018 11:48:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=cHo21F+r; dkim=pass (2048-bit key) header.b=hgAoT/WX
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vEKB46WZHHaB; Wed, 10 Oct 2018 11:48:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2888C126F72; Wed, 10 Oct 2018 11:48:40 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 2F44922268; Wed, 10 Oct 2018 14:48:39 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute7.internal (MEProxy); Wed, 10 Oct 2018 14:48:39 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=u hv9SPnoVKNirgv5XdPHN7WGYanip//t4vWqXgZoI/M=; b=cHo21F+r6WscaxD89 ontjcvDNl3T22kIyqvZjlOnyLRxBtEv8RvFoFNF4XYafJbBA6C4LxmowAtel+sgp F32h++BvjKTV6WvsXAEHksd9aH6rYoqUCFgHJgOPthZgOz+ZBqxbkMGTa7NCIB+B iPYE7nEUoeMC98nbePjr3H2ZlpHPoNcoglTtH3Q4Dl9e6a8SZvzHK/nAgDMmQ55n O2lS4xHLofFqIN30oI6nnmx4WBsSrsC/9nDPgZ4WxHDBxaWeLT2euMpwWryy0GzS uTpjmIrGUzcPSH9a1KJG7j0D2UYFNHbcYIRbMZfJZfPfjR2pat7VAHB8NR4wRLxB E62VQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=uhv9SPnoVKNirgv5XdPHN7WGYanip//t4vWqXgZoI /M=; b=hgAoT/WXiN7lnvgBTvqAwZ0WGcOoKlMYRI7xUcwjROp4vnqYQ9Rb4ZQwB qiTgcsHa8Wynyz3VkZzXPGbopIHYc8Vt5r5JP3xE3DahLtfLlRmf0BrohZhhWTPY 3BBAqvppb8c60OyMsWV2Kezt6EUW+uBKyzAA2ssYg9ScIskuCUhaOyyLbCmjqrmw 3zP+3N2K6yNVzPYjgJHKxbTgEe8ofsaAEph5CqNeWHdjLJhnz6U/C2jyjxxxAWdc qvil3icJrjPSVXfRcDMlndDgnQDK+TCzNCEsZ7n72TSJp1Vw23MSTNwwqjJ6f39n JgIu5QcnswUUpv3cVn5HwlJaHJMSQ==
X-ME-Sender: <xms:hkm-W-7T2hfJU2JC1QkRk-fIm_CFoqapCXHHeG5y2uTkba5QyZ44kg>
X-ME-Proxy: <xmx:hkm-WwBZEB3BB7SSY6ytVDIZGq2h5NcZYEo4lgSWUo9fOKT-hyJQNg> <xmx:hkm-W5ilGn_Vai_RLZencb2PEAUyoIkhvlU4vLTqNieJTWCFDg4KEg> <xmx:hkm-W4kfKfXcd8v0jX2hwO-8mpxo5_cQCTkHxVGcSgmQp8EXDiNzXQ> <xmx:hkm-W1qRQw4GO-OkTZfvPmCAA0hkEH1BzvWMeLh6kHpbNooebc-eCQ> <xmx:hkm-WxH1lH-i3GMCd14SKUBqW882ocG4FN4MztmpBUpJpiE669Jlgg> <xmx:h0m-W8cbpAMg2HMIYe3k2pHo_j-_X5FO03exNHrCSSzeEEig5EKoZw>
Received: from ( []) by (Postfix) with ESMTPA id DEB86E4428; Wed, 10 Oct 2018 14:48:37 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <>
In-Reply-To: <>
Date: Wed, 10 Oct 2018 14:48:36 -0400
Cc: IESG <>,, Benno Overeinder <>,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Dave Crocker <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [DNSOP] Alissa Cooper's Discuss on draft-ietf-dnsop-attrleaf-fix-04: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Oct 2018 18:48:43 -0000

Hi Dave,

> On Oct 10, 2018, at 2:32 PM, Dave Crocker <> wrote:
> On 10/10/2018 10:52 AM, Alissa Cooper wrote:
>> I think this document needs to state explicitly which updates apply to which
>> existing RFCs. That is, I would expect to see in sections 2.1,  2.2, and 2.3
>> the list of which documents are updated by each section. I realize this can be
>> intuited, but typically for avoidance of doubt authors specify precisely which
>> updates apply to which documents. This will also clear up the unused references
>> that idnits is pointing out.
> What is the downside of using the existing text, as compared against the effort (and delay -- quite possibly infinite) caused by requiring development of the considerable detail that you are calling for?

I think the downsides are (1) people reading the documents updated by this document are confused about which parts of the update apply, and (2) it sets a precedent that one RFC can update another without being specific about what is being updated. 

I’m not asking for considerable detail, I’m asking for each of 2.1, 2.2, and 2.3 to specify which documents out of the list in the Updates header they update.

> My question is not about the difference in cleanliness but about serious, practical risk.
>> I would also like to  understand why this is going for BCP. There is
>> effectively no shepherd write-up for this draft (it's just a copy of the
>> write-up for draft-ietf-dnsop-attrleaf and talks about this document as the
>> "companion" document) so there is no explanation there. One effect of this
>> being BCP is that it adds a huge number of documents to the downref registry.
>> It's not clear to me that the upside of that is bigger than the downside.
> I've no comment about status choice.
> Concerning the shepherd writeup, I'm not understanding what problem(s) it is causing.

Typically the shepherd write-up explains why a particular document status was chosen. Since this document doesn’t have a write-up, it doesn’t have that explanation.

> I gather that your main point is that making this Proposed would be better?

I think so.


>> Sections 2.1, 2.2, 2.3: I don't understand why the paragraphs "If a public
>> specification that defines ... MUST be entered into this registry, if it is not
>> already registered" are needed, since the same normative requirement is
>> generically stated in draft-ietf-dnsop-attrleaf.
> Good point.  I've changed those 3 bits of text to a commentary form:
>     <t>Note that a public specification, which defines use of an RRset and calls for the use of an underscore-prefixed domain name, its global underscored name -- the one closest to the root -- is required to be entered into this registry, if it is not already registered. <xref target="Attrleaf"></xref>.</t>
> -- 
> Dave Crocker
> Brandenburg InternetWorking