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

From: Alissa Cooper <[email-masked]>
Date: Wed, 10 Oct 2018 07:52:53 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-dnsop-attrleaf-fix-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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.

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.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Oct 2018 14:32:41 -0400

> 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.

> 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?

> 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
bbiw.net

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 10 Oct 2018 14:48:36 -0400

Hi Dave,

> On Oct 10, 2018, at 2:32 PM, Dave Crocker <[email-masked]> wrote:
> 
> 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.
> 
> 
> 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.

Thanks,
Alissa

>     <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

---

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Oct 2018 15:16:24 -0400

Alissa,

> 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.

So by my count, that requires going over roughly 35 documents (again) to 
audit and document this additional detail.

My guess is that the burden on someone updating one of those documents, 
seeing the reference to -fix, and being able to properly determine 
whether their document revision needs to attend to the section on TXT 
RRset usage and/or SRV RRset usage and/or URI RRset usage is minimal, 
and the risk of their getting it wrong is zero.

d/