DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names
draft-ietf-dnsop-attrleaf-fix-07

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

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

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

      "Per" [Attrleaf] "please add the following entry to the DNS
      Underscore Global Scoped Entry Registry:"

Do you have a really strong sense that this shouldn't be

  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:

      "Per" [Attrleaf] "please add the following entry to the DNS
      Underscore Global Scoped Entry Registry:"

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

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

One other comment, in  Section 3.1:

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

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

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

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

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

---------------------------------------------------------------------------

§1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].

Minor nit: please consider using the boilerplate from RFC 8174.

---------------------------------------------------------------------------

§§2.1 and 2.2:

>  An effort has been made to locate existing drafts that
>  do this, register the global underscored names, and list them in this
>  document.

I think this text ("list them in this document") is left over from before this
document was split from draft-ietf-dnsop-attrleaf.

---------------------------------------------------------------------------

§2.3:

This ties back to my discuss on draft-ietf-dnsop-attrleaf, and needs to be
changed in a way that is consistent with however that issue is resolved. The
current list of entries added by draft-ietf-dnsop-attrleaf strongly implies that
the contents of https://www.iana.org/assignments/enum-services were
automatically imported into the namespace created by the Underscore Global
Registry by the simple existence of RFC 7553. If that's the case, it seems that
the 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 exist
into the future, it seems that the trigger is addition of new Enumservice
entries, rather than the explicit specification of a new URI RRset.

---------------------------------------------------------------------------

§3.1:

>  The specification for a domain name under, which an SRV [RFC2782]
>  resource record appears, provides a template for use of underscored

Nit: "...a domain name, under which..."

---------------------------------------------------------------------------

§3.2:

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

---------------------------------------------------------------------------

§3.3:

>  consumes all names beginning with the string "_ta-", when using the
>  NUL RR in the query.

Nit: I believe the record type is called "NULL" rather than "NUL".

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-dnsop-attrleaf-fix-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-09-25):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, Benno Overeinder , dnsop@ietf.org, draft-ietf-dnsop-attrleaf-fix@ietf.org, benno@NLnetLabs.nl, warren@kumari.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (DNS Attrleaf Changes: Fixing Specifications with Underscored Node Name Use) to Best Current Practice


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'DNS Attrleaf Changes: Fixing
Specifications with Underscored Node Name
  Use'
  as Best Current Practice

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


The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-09-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the 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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc3887: Message Tracking Query Protocol (Proposed Standard - IETF stream)
    rfc5415: Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification (Proposed Standard - IETF stream)
    rfc4976: Relay Extensions for the Message Sessions Relay Protocol (MSRP) (Proposed Standard - IETF stream)
    rfc5518: Vouch By Reference (Proposed Standard - IETF stream)
    rfc3861: Address Resolution for Instant Messaging and Presence (Proposed Standard - IETF stream)
    rfc4387: Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP (Proposed Standard - IETF stream)
    rfc4386: Internet X.509 Public Key Infrastructure Repository Locator Service (Experimental - IETF stream)
    rfc6011: Session Initiation Protocol (SIP) User Agent Configuration (Informational - IETF stream)
    rfc4120: The Kerberos Network Authentication Service (V5) (Proposed Standard - IETF stream)
    rfc5679: Locating IEEE 802.21 Mobility Services Using DNS (Proposed Standard - IETF stream)
    rfc5928: Traversal Using Relays around NAT (TURN) Resolution Mechanism (Proposed Standard - IETF stream)
    rfc8145: Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) (Proposed Standard - IETF stream)
    rfc5864: DNS SRV Resource Records for AFS (Proposed Standard - IETF stream)
    rfc7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (Informational - Independent Submission Editor stream)
    rfc2782: A DNS RR for specifying the location of services (DNS SRV) (Proposed Standard - IETF stream)
    rfc5766: Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) (Proposed Standard - IETF stream)
    rfc6117: IANA Registration of Enumservices: Guide, Template, and IANA Considerations (Proposed Standard - IETF stream)
    rfc3263: Session Initiation Protocol (SIP): Locating SIP Servers (Proposed Standard - IETF stream)
    rfc3529: Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP) (Experimental - Independent Submission Editor stream)
    rfc7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 (Proposed Standard - IETF stream)
    rfc6733: Diameter Base Protocol (Proposed Standard - IETF stream)
    rfc5780: NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN) (Experimental - IETF stream)
    rfc6186: Use of SRV Records for Locating Email Submission/Access Services (Proposed Standard - IETF stream)
    rfc3832: Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV (Experimental - IETF stream)
    rfc5509: Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP) (Proposed Standard - IETF stream)
    rfc3958: Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS) (Proposed Standard - IETF stream)
    rfc3620: The TUNNEL Profile (Proposed Standard - IETF stream)
    rfc5026: Mobile IPv6 Bootstrapping in Split Scenario (Proposed Standard - IETF stream)
    rfc6120: Extensible Messaging and Presence Protocol (XMPP): Core (Proposed Standard - IETF stream)
    rfc5389: Session Traversal Utilities for NAT (STUN) (Proposed Standard - IETF stream)
    rfc7553: The Uniform Resource Identifier (URI) DNS Resource Record (Informational - IETF stream)
    rfc4227: Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP) (Proposed Standard - IETF stream)
    rfc5617: DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) (Historic - IETF stream)
    rfc3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence (Proposed Standard - IETF stream)
    rfc5555: Mobile IPv6 Support for Dual Stack Hosts and Routers (Proposed Standard - IETF stream)
    rfc3404: Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) (Proposed Standard - IETF stream)
    rfc5328: A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB) (Informational - IETF stream)
    rfc5804: A Protocol for Remotely Managing Sieve Scripts (Proposed Standard - IETF stream)
    rfc7671: The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance (Proposed Standard - IETF stream)

Summary

Review of draft-ietf-dnsop-attrleaf, combined with
draft-ietf-dnsop-attrleaf-fix.


1)
Document Type:
  BCP


2)
Technical Summary:

  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 its
Working Group Last Call.  Tim Wicinski (DNSNOP chair) was involved in
the earlier version of the document, and advised on the split-up of
the original draft-ietf-dnsop-attrleaf into two documents
draft-ietf-dnsop-attrleaf and draft-ietf-dnsop-attrleaf-fix for scope
and 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 of
the reviews.


5)
The companion document, draft-ietf-dnsop-attrleaf-fix, updates a large
number of existing RFCs.  This document and the companion should be
published simultaneously.  The specified updates will need review for
adequacy and could cause significant delay in publication. It will be
useful to find a way to expedite and coordinate these additional
reviews.


6)
There are not other specific concerns or issues.


7)
The author has confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79
have 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 has
been reviewed by a fair group of individuals (almost twenty) over the
past period.  Constructive comments were made on the mailing list and
feedback was incorporated in the document or comments were settled on
the 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 concern
might 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 this
draft-ietf-dnsop-attrleaf.  Both documents are send together in a
bundle to the AD.


15)
There or no downward normative references references (see RFC 3967).


16)
draft-ietf-dnsop-attrleaf does not alter any existing documents.

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 withthe
body 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 processed
through the IETF's ID Nits engine, and txt files were produced from
the XML by the IETF's Internet Drafts submission process.