DNS Terminology
draft-ietf-dnsop-terminology-bis-14

[Ballot comment]
Thank you for this document!

I was also confused by many of comments raised by Ekr. So I think some minor changes/clarifications would be useful.

[Ballot comment]

Thanks for the time and effort that went into this document. I agree with other
reviewers that this document is well-presented and informative.

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

General:

The document seems to omit a definition for the term "class," although it is
used in many places an clearly has a very precise meaning in DNS parlance. It
would be nice to see one added, as I got a bit confused when I hit the
definition for "Class independent" in section 5 and realized that I'd been
conflating "RR type" with "Class" -- and couldn't find guidance in this document
to clarify the difference.

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

§2:

>  Multicast DNS:  "Multicast DNS (mDNS) provides the ability to perform
>    DNS-like operations on the local link in the absence of any
>    conventional Unicast DNS server.

This definition seems to be a little oversimplified in light of the mechanisms
described by draft-ietf-dnssd-hybrid and draft-ietf-dnssd-mdns-relay.

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

§5:

>  Master file:  "Master files are text files that contain RRs in text
>    form.  Since the contents of a zone can be expressed in the form
>    of a list of RRs a master file is most often used to define

Nit: "...list of RRs, a master..."
                    ^

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

§5:
>  Owner:  The domain name where a RR is found ([RFC1034], Section 3.6).

Nit: "...an RR..." (see RFC 7322 §1, CMOS 10.9)

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

§6:

>    The idea of a primary master is only used by [RFC2136],
>    and is considered archaic in other parts of the DNS.
>
>    The idea of a primary master is only used in [RFC1996] and
>    [RFC2136].

These sentences seem redundant and partially contradictory. I suspect the first
one should be removed.

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

§6:

>  Privacy-enabling DNS server:  "A DNS server that implements DNS over
>    TLS [RFC7858] and may optionally implement DNS over DTLS
>    [RFC8094]."  (Quoted from [RFC8310], Section 2)

This definition seems incomplete in light of the mechanism defined in
draft-ietf-doh-dns-over-https.

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

Acknowledgements:

>  The following is the Acknowledgements for RFC 7719.  Additional
>  acknowledgements may be added as this draft is worked on.

This feels out of date. Consider removing.

[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3131



IMPORTANT
S 6.
>        [RFC5358]
> 
>      Split DNS:  The terms "split DNS" and "split-horizon DNS" have long
>        been used in the DNS community without formal definition.  In
>        general, they refer to situations in which DNS servers that are
>        authoritative for a particular set of domains provide partly or

What about ones that aren't authoritative. Apparently this exists in
VPN settings.

COMMENTS
S 2.
>      learn the DNS by reading this document.
> 
>  2.  Names
> 
>      Naming system:  A naming system associates names with data.  Naming
>        systems have many significant facets that help differentiate them.

From each other? Or from other systems that aren't naming systems?


S 2.
>        The need for the term "fully qualified domain name" comes from the
>        existence of partially qualified domain names, which are names
>        where one or more of the earliest labels in the ordered list are
>        omitted (for example, a name of "www" derived from
>        "www.example.net").  Such relative names are understood only by
>        context.

I think we agree here but I had to read it several times, because
"earliest" in the list is not earliest in the presentation format.
Perhaps you should say "less specific" or "closest to the root" are
omitted  instead.


S 2.
>      Subdomain:  "A domain is a subdomain of another domain if it is
>        contained within that domain.  This relationship can be tested by
>        seeing if the subdomain's name ends with the containing domain's
>        name."  (Quoted from [RFC1034], Section 3.1).  For example, in the
>        host name "nnn.mmm.example.com", both "mmm.example.com" and
>        "nnn.mmm.example.com" are subdomains of "example.com".

It might be worth noting that whole component matches are required
here.


S 2.
> 
>      Canonical name:  A CNAME resource record "identifies its owner name
>        as an alias, and specifies the corresponding canonical name in the
>        RDATA section of the RR."  (Quoted from [RFC1034], Section 3.6.2)
>        This usage of the word "canonical" is related to the mathematical
>        concept of "canonical form".

This paragraph didn't seem very clear. Perhaps an explanatory sentence
or two about what a CNAME is for woudl help.


S 4.
>            the name originally queried, or a name received in a CNAME
>            chain response.
> 
>        *  QNAME (final): The name actually resolved, which is either the
>            name actually queried or else the last name in a CNAME chain
>            response.

So to be clear, the QNAME (final) is always one of the QNAME
(effective) sets?


S 6.
>        name server side (which is what answers the query) and a resolver
>        side (which performs the resolution function).  Systems operating
>        in this mode are commonly called "recursive servers".  Sometimes
>        they are called "recursive resolvers".  While strictly the
>        difference between these is that one of them sends queries to
>        another recursive server and the other does not, in practice it is

Which one does which?


S 6.
>        general, a recursive resolver is expected to cache the answers it
>        receives (which would make it a full-service resolver), but some
>        recursive resolvers might not cache.
> 
>        [RFC4697] tried to differentiate between a recursive resolver and
>        an iterative resolver.

Did it fail?


S 6.
>        client to another server and lets the client pursue the query
>        there.  (See Section 2.3 of [RFC1034].)
> 
>        In iterative resolution, the client repeatedly makes non-recursive
>        queries and follows referrals and/or aliases.  The iterative
>        resolution algorithm is described in Section 5.3.3 of [RFC1034].

This may just be my confusion, but it seems like this is still a bit
hard to follow.

Say that I send a query to a server X with the recursive bit set, and
that server in fact decides to give me a full answer (as opposed to
failing). At that point it could either:

(1) send the query to another server with the recursive bit set
(2) resolve the query entirely itself using iterative queries

Am I right so far?

Are both of these termed "recursive resolvers"?




S 6.
>        Internet; it is not listed in the NS RRset."  (Quoted from
>        [RFC6781], Section 3.4.3).  An earlier RFC, [RFC4641], said that
>        the hidden master's name "appears in the SOA RRs MNAME field",
>        although in some setups, the name does not appear at all in the
>        public DNS.  A hidden master can also be a secondary server for
>        the zone itself.

I'm not understanding this last sentence. Can you elaborate?


S 7.
>        if the name server's name is 'below' the cut, and are only used as
>        part of a referral response."  Without glue "we could be faced
>        with the situation where the NS RRs tell us that in order to learn
>        a name server's address, we should contact the server using the
>        address we wish to learn."  (Definition from [RFC1034],
>        Section 4.2.1)

An example might help here.


S 10.
>        Policy (if such exists), and it states how the management of a
>        given zone implements procedures and controls at a high level."
>        (Quoted from [RFC6841], Section 2)
> 
>      Hardware security module (HSM):  A specialized piece of hardware that
>        is used to create keys for signatures and to sign messages.  In

It's probably worth mentioning that the idea here is that it doesn't
disclose the keys, as opposed to just creating them.

[Ballot comment]
Many thanks to the authors for making what I expected to be a dry terminology document into an adventure of discovery.

I agree with Mirja's assessment about whether this really updates 2308. I also agree with Alvaro's wish to rethink the BCP status (including his disinclination to stand in the way of publication this far into the process.)

§2"
- Definition of "Domain Name": I don't profess to be a naming expert, but this definition doesn't seem very satisfying.  It potentially defines things that I wouldn't consider domain names. Is there no representation, intent, or other context that distinguishes an ordered list of labels that is a domain name from your garden variety ordered lists of labels? (or is the point of this that they cannot be distinguished?)

- Definition of IDN: 'The current standard, normally called "IDNA2008"...'
That may not age well. I suggest  something to the effect of "The current standard at the time of this writing, ..."

[Ballot comment]
Thanks for writing! Agree with the suggested tweaks, Spencer's, clarifying "update" and Ben's comments.

On Informational vs. BCP, I'm leaning towards BCP. As noted in the Shepherd writeup, this is based on practice and improving interoperability, to me, it is a different "type" of terminology document than others which are labeled informational.

[Ballot comment]
This is definitively a labor of love. Thanks for doing the work!

I have some musings. Do the right thing, of course.

Thank you for producing this valuable doc.

In this text,

2.  Names

...

      The common display format is used in applications and free text.
      It is the same as the presentation format, but showing the root
      label and the "." before it is optional and is rarely done.  For
      example, in common display format, a fully-qualified domain name
      with two non-root labels is usually shown as "example.tld" instead
      of "example.tld.".  Names in the common display format are
      normally written such that the directionality of the writing
      system presents labels by decreasing distance from the root (so,
      in both English and C the root or TLD label in the ordered list is
      right-most; but in Arabic it may be left-most, depending on local
      conventions).

I bet I know what you mean by "C", but I'm guessing. Perhaps it's worth providing a reference, for all the Javascript and Python programmers who skipped over C?

I'm looking at

    Administration of names -- Administration is specified by
      delegation (see the definition of "delegation" in Section 7).
      Policies for administration of the root zone in the global DNS are
      determined by the names operational community, which convenes
      itself in the Internet Corporation for Assigned Names and Numbers
      (ICANN).  The names operational community selects the IANA
      Functions Operator for the global DNS root zone.  At the time this
      document is published, that operator is Public Technical
      Identifiers (PTI).  (See  for more
      information about PTI operating the IANA Functions.)  The name
      servers that serve the root zone are provided by independent root
      operators.  Other zones in the global DNS have their own policies
      for administration.

and wondering what the stability of an ICANN URL that refers to the name of the current IANA Functions Operator will be in 5-10 years. I'm not sure what else you can do to make that more useful if a different operator is selected, but if you can do something, maybe that would be useful.

I'm looking at this text:

  Passive DNS:  A mechanism to collect DNS data by storing DNS
      responses from name servers.  Some of these systems also collect
      the DNS queries associated with the responses, although doing so
      raises some privacy concerns. 

and thinking that the problem isn't collecting DNS queries associated with responses, it's that it's possible to collect DNS queries associated with responses (so, if one of these systems stops collecting DNS queries, you still have an exposure; it's just not happening now). Is that wrong?

I'm looking at this text:

  Privacy-enabling DNS server:  "A DNS server that implements DNS over
      TLS [RFC7858] and may optionally implement DNS over DTLS
      [RFC8094]."  (Quoted from [RFC8310], Section 2)

and seeing a race condition with https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ (which isn't news to the authors who contributed to both specifications). Is it worth a mention here, given that the DOH draft is already in the RFC Editor queue?

I may be misreading this text:

  Parent:  "The domain in which the Child is registered."  (Quoted from
      [RFC7344], Section 1.1) Earlier, "parent name server" was defined
      in [RFC0882] as "the name server that has authority over the place
      in the domain name space that will hold the new domain".  (Note
      that [RFC0882] was obsoleted by [RFC1034] and [RFC1035].)
      [RFC0819] also has some description of the relationship between
      parents and children.

but I'm reading it as "the definition in RFC 882 was obsoleted by RFC 1034-5 in 1987, and there was no definition until RFC 7344 in 2014". If that's what's intended, great, but if that's not your point, perhaps we should talk …

"Ostensive" is a perfectly good word according to https://www.merriam-webster.com/dictionary/ostensive, but I didn't know what it meant without Googling it. You guys know your intended audience, of course …

In this text,

  Closest provable encloser:  "The longest ancestor of a name that can
      be proven to exist.  Note that this is only different from the
      closest encloser in an Opt-Out zone."  (Quoted from [RFC5155],
      Section 1.3)

"Opt-Out zone" wasn't familiar to me, but it's defined later in the document. Perhaps adding a pointer to Section 10 would be helpful to readers who lack clue as I do.

[Ballot comment]
This is definitively a labor of love. Thanks for doing the work!

I have some musings. Do the right thing, of course.

Thank you for producing this valuable doc.

In this text,

2.  Names

...

      The common display format is used in applications and free text.
      It is the same as the presentation format, but showing the root
      label and the "." before it is optional and is rarely done.  For
      example, in common display format, a fully-qualified domain name
      with two non-root labels is usually shown as "example.tld" instead
      of "example.tld.".  Names in the common display format are
      normally written such that the directionality of the writing
      system presents labels by decreasing distance from the root (so,
      in both English and C the root or TLD label in the ordered list is
      right-most; but in Arabic it may be left-most, depending on local
      conventions).

I bet I know what you mean by "C", but I'm guessing. Perhaps it's worth providing a reference, for all the Javascript and Python programmers who skipped over C?

I'm looking at

    Administration of names -- Administration is specified by
      delegation (see the definition of "delegation" in Section 7).
      Policies for administration of the root zone in the global DNS are
      determined by the names operational community, which convenes
      itself in the Internet Corporation for Assigned Names and Numbers
      (ICANN).  The names operational community selects the IANA
      Functions Operator for the global DNS root zone.  At the time this
      document is published, that operator is Public Technical
      Identifiers (PTI).  (See  for more
      information about PTI operating the IANA Functions.)  The name
      servers that serve the root zone are provided by independent root
      operators.  Other zones in the global DNS have their own policies
      for administration.

and wondering what the stability of an ICANN URL that refers to the name of the current IANA Functions Operator will be in 5-10 years. I'm not sure what else you can do to make that more useful if a different operator is selected, but if you can do something, maybe that would be useful.
I'm looking at this text:

  Passive DNS:  A mechanism to collect DNS data by storing DNS
      responses from name servers.  Some of these systems also collect
      the DNS queries associated with the responses, although doing so
      raises some privacy concerns. 

and thinking that the problem isn't collecting DNS queries associated with responses, it's that it's possible to collect DNS queries associated with responses (so, if one of these systems stops collecting DNS queries, you still have an exposure; it's just not happening now). Is that wrong?

I'm looking at this text:

  Privacy-enabling DNS server:  "A DNS server that implements DNS over
      TLS [RFC7858] and may optionally implement DNS over DTLS
      [RFC8094]."  (Quoted from [RFC8310], Section 2)

and seeing a race condition with https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ (which isn't news to the authors who contributed to both specifications). Is it worth a mention here, given that the DOH draft is already in the RFC Editor queue?

I may be misreading this text:

  Parent:  "The domain in which the Child is registered."  (Quoted from
      [RFC7344], Section 1.1) Earlier, "parent name server" was defined
      in [RFC0882] as "the name server that has authority over the place
      in the domain name space that will hold the new domain".  (Note
      that [RFC0882] was obsoleted by [RFC1034] and [RFC1035].)
      [RFC0819] also has some description of the relationship between
      parents and children.

but I'm reading it as "the definition in RFC 882 was obsoleted by RFC 1034-5 in 1987, and there was no definition until RFC 7344 in 2014". If that's what's intended, great, but if that's not your point, perhaps we should talk …

"Ostensive" is a perfectly good word according to https://www.merriam-webster.com/dictionary/ostensive, but I didn't know what it meant without Googling it. You guys know your intended audience, of course …

In this text,

  Closest provable encloser:  "The longest ancestor of a name that can
      be proven to exist.  Note that this is only different from the
      closest encloser in an Opt-Out zone."  (Quoted from [RFC5155],
      Section 1.3)

"Opt-Out zone" wasn't familiar to me, but it's defined later in the document. Perhaps adding a pointer to Section 10 would be helpful to readers who lack clue as I do.

[Ballot comment]
First off, thank you all for the effort that went into this document -- it's quite helpful to
have a central resource to refer to.

I agree with Mirja about further clarity for the 2308 updates being nice, and about the "primary master"
definition's clarification.  (The latter seems like it would meet a DISCUSS criterion, as internal inconsistency
makes it difficult to have a clear specification.  But it would be absurd to apply it here when the fix is clear.)

I appreciate that "privacy of names" and "privacy of data associated with names" are called out as potential
facets of a naming system to consider, but I would like to understand better why they are not given more treatment
in this document.  The surrounding text seems to imply that they are not needed to describe the DNS and that
a pure lexicon need not explore the privacy considerations of the terms being defined; is this correct, and was
there much discussion on this question?

In a similar vein, it was a little surprising to only see the facets be expounded upon for the global DNS and not
the other related naming systems, though it's unclear that there would be much non-overlap for the other systems
considered.

In Section 6:

I'm a little confused about the interaction between "stealth server"
and "hidden master" -- if a hidden master is a stealth server, it is "like
a slave" and would thus be expected to get its configuration from yet
another master?  But this doesn't jibe with being listed as the MNAME.
I accept that DNS terminology is a complicated area and there may not
be a right answer, of course.

The "privacy-enabling DNS server" definition seems too narrowly scoped to
particular existing technologies as opposed to describing the properties
provided (or mentioning the possibility for future protocols to be
included).  Is a DNS-over-HTTP server "privacy-enabling"?  How about DNS-over-QUIC?

Section 8

Interesting to see the term "Opt-Out zone" used but not defined in this
document.  (No action needed, and I do see the definition of "Opt-Out".)


Finally, I am somewhat sympathetic to the indications that this document may
(also) be appropriate as Informational; I look forward to seeing how that discussion
unfolds.

[Ballot comment]
I agree with Mirja on her point about this document not seeming to Update rfc2308.

Both the IETF Last Call thread [1] and the Shepherd's writeup point at having this document not be Informational so it can Update rfc2308.  Putting that point aside, I don't think this document needs to be published as a BCP to reflect the current evolution of the DNS vocabulary.  I would prefer it if the status was reconsidered.

Given that we're already past IETF LC, I won't stand in the way as I am probably in the rough.  I am then balloting "No Objection" because I think this is a clear and important document.

[1] https://mailarchive.ietf.org/arch/msg/dnsop/9KsgYjBAxz5kzdeFLbht0IWjPkM

[Ballot comment]
I'm actually not sure if this doc really updates RFC2308 because the two definitions (Forwarder and QNAME) only say someting like "it is used differently today" but seem not really to actually update the existing definitions. I would recommend to either not use the "update" tag or clarify these definitions. 

Thanks for the clarification added based on the TSV-ART review (and thanks Allison!).

(Potential) nits:
1) OLD:
A set of resource records with the same label, class and
      type, but with different data.  (Definition from [RFC2181])
MAYBE use quotes here at least for the last part of the sentence:
A set of resource records "with the same label, class and
      type, but with different data."  (Definition from [RFC2181])

2) s/Section 4.3.1 of of [RFC1034] /Section 4.3.1 of [RFC1034]/

3) Probably the first sentence should be removed:
"The idea of a primary master is only used by [RFC2136],
      and is considered archaic in other parts of the DNS.

      The idea of a primary master is only used in [RFC1996] and
      [RFC2136]. "

4) Why is there (a) and (b) for the definition of Origin?

[Ballot comment]
I'm actually not sure if this doc really updates RFC2308 because the two definitions (Forwarder and QNAME) only say someting like "it is used different today" but seem not really to actually update the existing definition. I would recommend to either not use the "update" tag or clarify these definitions. 

Thanks for the clarification added based on the TSV-ART review (and thanks Allison!).

(Potential) nits:
1) OLD:
A set of resource records with the same label, class and
      type, but with different data.  (Definition from [RFC2181])
MAYBE use quotes here at least for the last part of the sentence:
A set of resource records "with the same label, class and
      type, but with different data."  (Definition from [RFC2181])

2) s/Section 4.3.1 of of [RFC1034] /Section 4.3.1 of [RFC1034]/

3) Probably the first sentence should be removed:
"The idea of a primary master is only used by [RFC2136],
      and is considered archaic in other parts of the DNS.

      The idea of a primary master is only used in [RFC1996] and
      [RFC2136]. "

4) Why is there (a) and (b) for the definition of Origin?

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

The IANA Functions Operator has reviewed draft-ietf-dnsop-terminology-bis-11, 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-08-13):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, dnsop@ietf.org, suzworldwide@gmail.com, Suzanne Woolf , warren@kumari.net, draft-ietf-dnsop-terminology-bis@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (DNS Terminology) to Best Current Practice


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'DNS Terminology'
  as Best Current Practice

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-08-13. 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


  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.

  This document will be the successor to RFC 7719, and thus will
  obsolete RFC 7719.  It will also update RFC 2308.




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/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:
    rfc2308: Negative Caching of DNS Queries (DNS NCACHE) (Proposed Standard - IETF stream)
    rfc2181: Clarifications to the DNS Specification (Proposed Standard - IETF stream)
    rfc1996: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) (Proposed Standard - IETF stream)
    rfc1912: Common DNS Operational and Configuration Errors (Informational - Legacy stream)
    rfc882: Domain names: Concepts and facilities (Unknown - Legacy stream)
    rfc6561: Recommendations for the Remediation of Bots in ISP Networks (Informational - IETF stream)
    rfc6781: DNSSEC Operational Practices, Version 2 (Informational - IETF stream)
    rfc4592: The Role of Wildcards in the Domain Name System (Proposed Standard - IETF stream)
    rfc6840: Clarifications and Implementation Notes for DNS Security (DNSSEC) (Proposed Standard - IETF stream)
    rfc3731: Extensible Provisioning Protocol (EPP) Domain Name Mapping (Proposed Standard - IETF stream)
    rfc7719: DNS Terminology (Informational - IETF stream)
    rfc2136: Dynamic Updates in the Domain Name System (DNS UPDATE) (Proposed Standard - IETF stream)
    rfc5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence (Proposed Standard - IETF stream)
    rfc7344: Automating DNSSEC Delegation Trust Maintenance (Proposed Standard - IETF stream)
    rfc4035: Protocol Modifications for the DNS Security Extensions (Proposed Standard - IETF stream)
    rfc4034: Resource Records for the DNS Security Extensions (Proposed Standard - IETF stream)
    rfc8310: Usage Profiles for DNS over TLS and DNS over DTLS (Proposed Standard - IETF stream)
    rfc4033: DNS Security Introduction and Requirements (Proposed Standard - IETF stream)
    rfc6841: A Framework for DNSSEC Policies and DNSSEC Practice Statements (Informational - IETF stream)
    rfc5936: DNS Zone Transfer Protocol (AXFR) (Proposed Standard - IETF stream)

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

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.

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