Received changes through RFC Editor sync (created alias RFC 8553, changed title to 'DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names', changed abstract to 'Using an underscore for a prefix creates a space for constrained interoperation of resource records. Original uses of an underscore character as a domain node name prefix were specified without the benefit of an IANA registry. This produced an entirely uncoordinated set of name-creation activities, all drawing from the same namespace. A registry for these names has now been defined by RFC 8552. However, the existing specifications that use underscored naming need to be modified in order to be in line with the new registry. This document specifies those changes. The changes preserve existing software and operational practice, while adapting the specifications for those practices to the newer underscore registry model.', changed pages to 15, changed standardization level to Best Current Practice, changed state to RFC, added RFC published event at 2019-03-20, changed IESG state to RFC Published, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 2782, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 3263, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 3529, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 3620, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 3832, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 3887, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 3958, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 4120, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 4227, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 4386, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 4387, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 4976, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 5026, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 5328, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 5389, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 5415, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 5518, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 5555, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 5617, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 5679, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 5766, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 5780, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 5804, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 5864, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 5928, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 6120, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 6186, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 6376, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 6733, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 6763, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 7208, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 7489, created updates relation between draft-ietf-dnsop-attrleaf-fix and RFC 8145)

[Ballot comment]I was wavering on whether this should be a DISCUSS or not but I decided to go with a No Objection position but ...

[Ballot comment]I was wavering on whether this should be a DISCUSS or not but I decided to go with a No Objection position but I would *really, really* like to get the reference to RFC5026 and the associated "Updates:" removed. I don't think there was any intent in RFC5026 to reserve "_ipv6" and it is used purely as an example with no normative intent and no further description of usage.

2018-10-10

04

Suresh Krishnan

[Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan

2018-10-10

04

Ben Campbell

[Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell

2018-10-10

04

Spencer Dawkins

[Ballot comment]My previous position was a "plea for clue Discuss" about three MUSTs that appeared in the document, and Dave pointed out to me ...

[Ballot comment]My previous position was a "plea for clue Discuss" about three MUSTs that appeared in the document, and Dave pointed out to me that those MUSTs will be removed in the next version of this document, because there is already a MUST in the underlying specification that this one is providing usage guidance for.

Thank you for the speedy feedback!

2018-10-10

04

Spencer Dawkins

[Ballot Position Update] Position for Spencer Dawkins has been changed to No Objection from Discuss

2018-10-10

04

Spencer Dawkins

[Ballot discuss]This is absolutely a "plea for clue Discuss", after which I will immediately clear because the right thing will happen.

There are three ...

[Ballot discuss]This is absolutely a "plea for clue Discuss", after which I will immediately clear because the right thing will happen.

There are three text blocks that follow this form:

If a public specification that defines use of a "TXT" calls for the use of an underscore-prefixed domain name, the global underscored name -- the one closest to the root -- MUST be entered into this registry, if it is not already registered.

->Here is a template of suggested text for this to appear in the IANA->Considerations section of the specification:

If a public specification that defines use of a "TXT" calls for the use of an underscore-prefixed domain name, the global underscored name -- the one closest to the root -- MUST be entered into this registry, if it is not already registered, by adding this text to the IANA Considerations section of the specification:

I may be overreacting to "MUST do something like this", which is roughly what I'm reading into "template of suggested text", and if I am, I'm almost sure someone will tell me that ... but I'm not seeing an obvious reason to REQUIRE one of an unbounded set of flowers to bloom ;-)

2018-10-10

04

Spencer Dawkins

[Ballot Position Update] New position, Discuss, has been recorded for Spencer Dawkins

2018-10-10

04

Deborah Brungard

[Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard

2018-10-10

04

Benjamin Kaduk

[Ballot comment]I support Alissa's Discuss points (and in particular would think that this documentwould be fine as Proposed Standard).

One other comment ...

[Ballot comment]I support Alissa's Discuss points (and in particular would think that this documentwould be fine as Proposed Standard).

One other comment, in Section 3.1:

Why is the new text only placing a "SHOULD be registered" requirement, asopposed to MUST?

2018-10-10

04

Benjamin Kaduk

[Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk

2018-10-10

04

Alissa Cooper

[Ballot discuss]I think this document needs to state explicitly which updates apply to which existing RFCs. That is, I would expect to see in ...

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

2018-10-10

04

Alissa Cooper

[Ballot comment]Sections 2.1, 2.2, 2.3: I don't understand why the paragraphs "If a public specification that defines ... MUST be entered ...

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

2018-10-10

04

Alissa Cooper

[Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper

2018-10-10

04

Mirja Kühlewind

[Ballot comment]I don't quite understand why it was seen as beneficial by the group that this doc has been split up, however, BCP ...

[Ballot comment]I don't quite understand why it was seen as beneficial by the group that this doc has been split up, however, BCP does not seems adequate for this part of the doc anymore (maybe PS instead as it updates some PS docs?).

Also, I think that the OLD/NEW style is not really necessary in most cases as simply a sentence/reference to the registry is added.

2018-10-10

04

Mirja Kühlewind

[Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind

2018-10-09

04

Eric Rescorla

[Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla

2018-10-08

04

Adam Roach

[Ballot comment]Echoing comments from my review of draft-ietf-dnsop-attrleaf: I believe thisdocument needs to also include RFC 6763 and RFC 4386; and that it ...

[Ballot comment]Echoing comments from my review of draft-ietf-dnsop-attrleaf: I believe thisdocument needs to also include RFC 6763 and RFC 4386; and that it should notinclude RFC 6733. Please see that review for details.

This ties back to my discuss on draft-ietf-dnsop-attrleaf, and needs to bechanged in a way that is consistent with however that issue is resolved. Thecurrent list of entries added by draft-ietf-dnsop-attrleaf strongly implies thatthe contents of https://www.iana.org/assignments/enum-services wereautomatically imported into the namespace created by the Underscore GlobalRegistry by the simple existence of RFC 7553. If that's the case, it seems thatthe following text in this document...

> For any document that specifies the use of a "URI" RRset

...doesn't capture the real process here. As RFC 7553 will continue to existinto the future, it seems that the trigger is addition of new Enumserviceentries, rather than the explicit specification of a new URI RRset.

As a very minor nit, the cited original text for RFC 6117 §4.1 kind of blends inwith the text of this document. I would propose indenting it as was done withthe rest of the quoted content in this section.

The IESG has received a request from the Domain Name System Operations WG(dnsop) to consider the following document: - 'DNS Attrleaf Changes: FixingSpecifications with Underscored Node Name Use' <draft-ietf-dnsop-attrleaf-fix-04.txt> as Best Current Practice

PLEASE NOTE: The draft-ietf-dnsop-attrleaf-fix and draft-ietf-dnsop-attrleaf documents are very closely related. Pleaseread **both** of them when commenting.

The IESG plans to make a decision in the next few weeks, and solicits finalcomments on this action. Please send substantive comments to theietf@ietf.org mailing lists by 2018-09-25. Exceptionally, comments may besent to iesg@ietf.org instead. In either case, please retain the beginning ofthe Subject line to allow automated sorting.

Abstract

Original uses of an underscore character as a domain node name prefix, which creates a space for constrained interpretation of resource records, were specified without the benefit of an IANA registry. This produced an entirely uncoordinated set of name- creation activities, all drawing from the same namespace. A registry now has been defined. However the existing specifications that use underscore naming need to be modified, to be in line with the new registry. This document specifies those changes. The changes preserve existing software and operational practice, while adapting the specifications for those practices to the newer underscore registry model.

Original uses of an underscore character as a domain node name prefix, which creates a space for constrained interpretation of resource records, were specified without the benefit of an IANA registry. This produced an entirely uncoordinated set of name- creation activities, all drawing from the same namespace. A registry now has been defined. However the existing specifications that use underscore naming need to be modified, to be in line with the new registry. This document specifies those changes. The changes preserve existing software and operational practice, while adapting the specifications for those practices to the newer underscore registry model.

Working Group Summary:

This document has a very long history, with multiple, extended periods of hiatus. It's recent activity received substantial working group participant commentary that produced substantial changes to the design of the proposed registry. The latest rounds comments were primarily about minor editorial points or clarification of implications, rather than changes to the design. Multiple participants have commented on the work, over time and recently. They are cited in the document Acknowledgements section.

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

WG criticism of the design approach produced at least two major revisions to the design.

Document Quality:

This work is explicitly designed to require no software or operational changes. Changes is necessiates are restricted to the relevant IETF documents, to use standard registry processes.

There are no other reviewers that merit special mentioning.

Personnel:

Document shepherd: Benno Overeinder Area Director: Warren Kumari

3)

The shepherd was involved at the final stages of the draft and itsWorking Group Last Call. Tim Wicinski (DNSNOP chair) was involved inthe earlier version of the document, and advised on the split-up ofthe original draft-ietf-dnsop-attrleaf into two documentsdraft-ietf-dnsop-attrleaf and draft-ietf-dnsop-attrleaf-fix for scopeand clarity.

We did talk with application area to have good reviews from them.

4)The document shepherd has no any concerns about the depth or breadt ofthe reviews.

5) The companion document, draft-ietf-dnsop-attrleaf-fix, updates a largenumber of existing RFCs. This document and the companion should bepublished simultaneously. The specified updates will need review foradequacy and could cause significant delay in publication. It will beuseful to find a way to expedite and coordinate these additionalreviews.

6)There are not other specific concerns or issues.

7)The author has confirmed that any and all appropriate IPR disclosuresrequired for full conformance with the provisions of BCP 78 and BCP 79have already been filed.

8)There has no IPR disclosure been filed that references this document.

9)There is a solid WG consensus behind the document. The document hasbeen reviewed by a fair group of individuals (almost twenty) over thepast period. Constructive comments were made on the mailing list andfeedback was incorporated in the document or comments were settled onthe mailing list.

10)There has been no indications of discontent with respect to the document.

11)No nits.

12)For the documnet no formal review criteria are needed. One concernmight be conformance to IANA requirements for creating a registry.IANA's documented guidance for this has been followed.

13)All references within this document been identified as either normative or informative.

14)The accompanying document draft-ietf-dnsop-attrleaf-fix depends thisdraft-ietf-dnsop-attrleaf. Both documents are send together in abundle to the AD.

draft-ietf-dnsop-attrleaf-fix updates a large number of existing RFCs;they are listed in the Updates document header.

17)The IANA considerations section is adequate; it is consistent withthebody of the document.

18)DNS Underscore Global Scoped Entry Registry

Guidance for expert review is in Section 5 of draft-ietf-dnsop-attrleaf. Expert review concerns basic matters of form and small amounts of registry detail. It does not require deep knowledge of technical aspects of what the larger topic for which a registry entry is needed, not deep knowledge of DNS technology.

19)The documents were produced with an XML editor and were processedthrough the IETF's ID Nits engine, and txt files were produced fromthe XML by the IETF's Internet Drafts submission process.

2018-07-21

03

Benno Overeinder

Responsible AD changed to Warren Kumari

2018-07-21

03

Benno Overeinder

IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up