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

Dave Crocker <> Wed, 10 October 2018 18:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C47912785F; Wed, 10 Oct 2018 11:32:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2GWAu4K4gZqu; Wed, 10 Oct 2018 11:32:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 107A31277C8; Wed, 10 Oct 2018 11:32:40 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w9AIWwHU031496 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Oct 2018 11:32:59 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1539196380; bh=x2AEune8YPlxMvzbOzUNEwEBuD6c/dyXHInoM7CNQSk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=MBoYya861Zyglf4oy/mET2VXF9AXd130Au8FxjLGJa7SiZWxHp+4x1DaDJm1Dr9Kv 4/8RJqr4Xn9EF80hvElT1urcBPgJ0vgfEN5XwYe9Uf4YUC1RZC1rAcXb//1oWXVLvl B+q1YnOM0sssv09O3I410mLy8T+UyBF8td8bFH5I=
To: Alissa Cooper <>, The IESG <>
Cc:, Benno Overeinder <>,,
References: <>
From: Dave Crocker <>
Message-ID: <>
Date: Wed, 10 Oct 2018 14:32:41 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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:32:41 -0000

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?

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.

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

> 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 

Dave Crocker
Brandenburg InternetWorking