Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2019-03-15
07 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2019-03-01
07 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2019-03-01
07 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2019-01-15
07 (System) RFC Editor state changed to EDIT from IESG
2019-01-10
07 (System) RFC Editor state changed to IESG from EDIT
2018-12-20
07 (System) RFC Editor state changed to EDIT from MISSREF
2018-11-29
07 Tero Kivinen Closed request for Last Call review by SECDIR with state 'No Response'
2018-11-26
07 (System) IANA Action state changed to No IANA Actions from In Progress
2018-11-26
07 (System) RFC Editor state changed to MISSREF
2018-11-26
07 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-11-26
07 (System) Announcement was received by RFC Editor
2018-11-26
07 (System) IANA Action state changed to In Progress
2018-11-26
07 Amy Vezza IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2018-11-26
07 Amy Vezza IESG has approved the document
2018-11-26
07 Amy Vezza Closed "Approve" ballot
2018-11-26
07 Amy Vezza Ballot approval text was generated
2018-11-26
07 Amy Vezza Ballot writeup was changed
2018-11-21
07 Alissa Cooper [Ballot comment]
Thank you for addressing my DISCUSS and COMMENT.
2018-11-21
07 Alissa Cooper [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss
2018-11-20
07 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-fix-07.txt
2018-11-20
07 (System) New version approved
2018-11-20
07 (System) Request for posting confirmation emailed to previous authors: Dave Crocker
2018-11-20
07 Dave Crocker Uploaded new revision
2018-11-03
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-11-03
06 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2018-11-03
06 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-fix-06.txt
2018-11-03
06 (System) New version approved
2018-11-03
06 (System) Request for posting confirmation emailed to previous authors: Dave Crocker
2018-11-03
06 Dave Crocker Uploaded new revision
2018-10-11
05 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2018-10-11
05 Michelle Cotton IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2018-10-11
05 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2018-10-10
05 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-10-10
05 Suresh Krishnan Ballot comment text updated for Suresh Krishnan
2018-10-10
05 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2018-10-10
05 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-fix-05.txt
2018-10-10
05 (System) New version approved
2018-10-10
05 (System) Request for posting confirmation emailed to previous authors: Dave Crocker
2018-10-10
05 Dave Crocker Uploaded new revision
2018-10-10
04 Suresh Krishnan
[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:

      "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 ;-)
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 document
would be fine as Proposed Standard).

One other comment, in  …
[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?
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 into this registry, …
[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 does …
[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 this
document needs to also include RFC 6763 and RFC 4386; and …
[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".
2018-10-08
04 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2018-10-08
04 Warren Kumari Doh. I started the ballot, but forgot change the datatracker state.
2018-10-08
04 Warren Kumari IESG state changed to IESG Evaluation from Waiting for Writeup
2018-10-08
04 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-10-07
04 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2018-10-02
04 Cindy Morgan Placed on agenda for telechat - 2018-10-11
2018-10-02
04 Warren Kumari Ballot has been issued
2018-10-02
04 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2018-10-02
04 Warren Kumari Created "Approve" ballot
2018-10-02
04 Warren Kumari Ballot writeup was changed
2018-09-25
04 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-09-24
04 Francesca Palombini Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Francesca Palombini. Sent review to list.
2018-09-21
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joel Jaeggli
2018-09-21
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joel Jaeggli
2018-09-21
04 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2018-09-21
04 Sabrina Tanamal
(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 …
(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
2018-09-13
04 Jean Mahoney Request for Last Call review by GENART is assigned to Francesca Palombini
2018-09-13
04 Jean Mahoney Request for Last Call review by GENART is assigned to Francesca Palombini
2018-09-12
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to John Bradley
2018-09-12
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to John Bradley
2018-09-11
04 Cindy Morgan IANA Review state changed to IANA - Review Needed
2018-09-11
04 Cindy Morgan
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, …
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)



2018-09-11
04 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2018-09-11
04 Warren Kumari Last call was requested
2018-09-11
04 Warren Kumari Ballot approval text was generated
2018-09-11
04 Warren Kumari Ballot writeup was generated
2018-09-11
04 Warren Kumari IESG state changed to Last Call Requested from AD Evaluation
2018-09-11
04 Warren Kumari Last call announcement was changed
2018-08-23
04 Warren Kumari IESG state changed to AD Evaluation from AD is watching
2018-08-21
04 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-fix-04.txt
2018-08-21
04 (System) New version approved
2018-08-21
04 (System) Request for posting confirmation emailed to previous authors: Dave Crocker
2018-08-21
04 Dave Crocker Uploaded new revision
2018-08-13
03 Warren Kumari As discussed (Mon, Aug 6) -- revised ID needed for the _ta-XXXX case, author is busy at the moment, will resubmit once done.
2018-08-13
03 Warren Kumari IESG state changed to AD is watching from Publication Requested
2018-07-21
03 Benno Overeinder
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 …
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.
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
2018-07-21
03 Benno Overeinder IESG state changed to Publication Requested
2018-07-21
03 Benno Overeinder IESG process started in state Publication Requested
2018-07-21
03 Benno Overeinder Changed document writeup
2018-07-21
03 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-fix-03.txt
2018-07-21
03 (System) New version approved
2018-07-21
03 (System) Request for posting confirmation emailed to previous authors: Dave Crocker
2018-07-21
03 Dave Crocker Uploaded new revision
2018-07-17
02 Benno Overeinder IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2018-07-15
02 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-fix-02.txt
2018-07-15
02 (System) New version approved
2018-07-15
02 (System) Request for posting confirmation emailed to previous authors: Dave Crocker
2018-07-15
02 Dave Crocker Uploaded new revision
2018-06-27
01 Benno Overeinder Notification list changed to Benno Overeinder <benno@NLnetLabs.nl>
2018-06-27
01 Benno Overeinder Document shepherd changed to Benno Overeinder
2018-06-27
01 Benno Overeinder IETF WG state changed to In WG Last Call from WG Document
2018-06-25
01 Benno Overeinder Changed consensus to Yes from Unknown
2018-06-25
01 Benno Overeinder Intended Status changed to Best Current Practice from None
2018-05-22
01 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-fix-01.txt
2018-05-22
01 (System) New version approved
2018-05-22
01 (System) Request for posting confirmation emailed to previous authors: Dave Crocker
2018-05-22
01 Dave Crocker Uploaded new revision
2018-05-11
00 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-fix-00.txt
2018-05-11
00 (System) WG -00 approved
2018-05-03
00 Dave Crocker Set submitter to "Dave Crocker ", replaces to (none) and sent approval email to group chairs: dnsop-chairs@ietf.org
2018-05-03
00 Dave Crocker Uploaded new revision