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