Shepherd writeup
rfc8499-14

As required by RFC 4858, this is the current template for the Document 
Shepherd Write-Up.

(1) What type of RFC is being requested?
BCP

Why is this the proper type of RFC?  
It's an effort to collect a large number of terms from a large number of sources, primarily RFCs but also common usage by practitioners. As such, it aims to improve interoperability among implementations and operational configuration of the DNS by giving implementers and practitioners a common reference vocabulary. Clearly the more people use it, the more useful it will be, so BCP seems right.

In addition, from the process perspective, the document's status is BCP because it updates RFC 2308, which is a Proposed Standard.

Is this type of RFC indicated in the title page header?
Yes.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. 

Technical Summary

 The domain name system (DNS) is defined in literally dozens of
   different RFCs.  The terminology used by implementers and developers
   of DNS protocols, and by operators of DNS systems, has sometimes
   changed in the decades since the DNS was first defined.  This
   document gives current definitions for many of the terms used in the
   DNS in a single document, in the interests of improving interoperability among
  implementations, operational configuration conventions, and other code or documents
  based on the DNS protocol.

Working Group Summary

  This document has proceeded through the WG remarkably smoothly. The editors have done an enormous amount of work, as have the 
  reviewers. The editors were open with the WG in taking input and mostly incorporating it. A terminology document for a 30yo protocol
  covered by dozens of existing documents and used by millions of hosts and billions of users every day is a particularly thankless task 
  and it's been done very well. It was written expressly to obsolete 7719, which was Informational and tackled only those definitions that
  were unambiguous; this document extends them in an attempt to resolve some such ambiguities to recommend "best practice".

Document Quality

  Are there existing implementations of the protocol? 
The document attempts to describe both the standard and practice for a protocol that's been in use for 30 years and dozens of
inplementations.  Attention in the WG came from both operators and implementers.

Personnel

  Who is the Document Shepherd? Suzanne Woolf
  Who is the Responsible Area Director?  Warren Kumari

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd was a co-chair of the DNSOP WG for both this document and RFC 7719. The shepherd has read it several times, and
reviewed the document and the WG discussion on it for the writeup. Some nits remain but it's ready to go.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. It's a large complex document but a great deal of expertise has been applied to it, and much of the effort in RFC 7719 has 
carried over.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? 

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? 

No. It has a straightforward purpose and has been carefully written for that purpose. 

(7) Has each author 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. If not, explain why.

We don't believe there's any applicable disclosure to make. The document uses extensive quotes from other documents, but 
all are RFCs or other references whose terms allow this quoting without further process required. Authors have confirmed that to
their knowledge, there's no IPR disclosure required.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it 
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?   

DNSOP is a very large, active WG so "a few individuals" can still be pretty broad engagement. We had a good 
diversity of contributors to discussion, including some who don't normally participate much on the list.

(10) Has anyone threatened an appeal or otherwise indicated extreme 
discontent? 

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

There are a number of idnits errors on normative downrefs and references to obsolete RFCs. These are deliberate and occur because the document is citing the original
definitions of the terms it's discussing, even when those appeared in Informational documents or documents that are now obsolete. Those references should stand as 
normative, since they are for this document.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in 
the Last Call procedure. 

idnits identifies:

  ** Downref: Normative reference to an Informational RFC: RFC 1912
  ** Downref: Normative reference to an Informational RFC: RFC 6561
  ** Downref: Normative reference to an Informational RFC: RFC 6781
  ** Downref: Normative reference to an Informational RFC: RFC 6841
  ** Downref: Normative reference to an Informational RFC: RFC 7719

As noted above, these aren't downrefs in the usual sense, but legitimate references to documents that define terms used normatively while not being standards track.

The editors, and the WG chairs, feel these references are correct as they stand.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

The status changes are properly reflected in the headers and the abstract. They're not discussed
specifically in the introduction, but are inherent in the general nature of the document as described
there. As a terminology document for a protocol that spans dozens of RFCs, the document flags which RFCs it's
quoting, and providing commentary for (including updating RFC 2308), in the appropriate locations throughout
the text.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. 

This document contains no IANA Considerations.

(18) List any new IANA registries that require Expert Review for future
allocations. 

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A
Back