Change:
Agree with the first one, although I don't care which way it comes out from the RFC Editor. For the second one, I have changed the wording to 'An authoritative server is named in the NS ("name server") record in a zone.' We don't need to stray into which zone has authoritative data; the double use of "authoritative" will confuse the reader without helping with the terminology.
l 179, s/octets which/octets that. This has been changed to violate the that/which conventions of the RFC Editor. l844 (new) the authoritative name server is named in the parent zone but is not authoritative data there (NS is authoritative in the child). This is discussed elsewhere in the document, and I find this addition confusing. I won't hold up pver either of these. The rest looks ok.

Discussion:
"and are, or will be, resolvable in the global DNS" or "but only using the presentation format". <del> An ordered list of zero or more octets and which makes up a portion of a domain name.  Using graph theory, a label identifies one node in a portion of the graph of all possible domain names. </del> <ins> An ordered list of zero or more octets that makes up a portion of a domain name.  Using graph theory, a label identifies one node in a portion of the graph of all possible domain names. </ins> Using the short set of facets listed in "Naming system", the global DNS can be defined as follows.  Most of the rules here come

(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 <del> Identifiers (PTI).  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. </del> <ins> Identifiers (PTI).  (See <https://pti.icann.org/> 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. </ins> Types of data that can be associated with names -- A name can have zero or more resource records associated with it.  There are

DNS documents, including the definitions here, often refer to the fields in the RDATA of an SOA resource record by field name. <del> Those fields are defined in Section 3.3.13 of RFC1035.  The names (in the order they appear in the SOA RDATA) are MNAME, RNAME, SERIAL, REFRESH, RETRY, EXPIRE, and MINIMUM.  Note that the meaning of MINIMUM field is updated in Section 4 of RFC2308; the new definition is that the MINIMUM field is only "the TTL to be used for negative responses".  This document tends to use field names instead of terms that describe the fields. </del> <ins> "SOA" stands for "start of a zone of authority".  Those fields are defined in Section 3.3.13 of RFC1035.  The names (in the order they appear in the SOA RDATA) are MNAME, RNAME, SERIAL, REFRESH, RETRY, EXPIRE, and MINIMUM.  Note that the meaning of MINIMUM field is updated in Section 4 of RFC2308; the new definition is that the MINIMUM field is only "the TTL to be used for negative responses".  This document tends to use field names instead of terms that describe the fields. </ins> The maximum "time to live" of a resource record.  "A TTL value is an unsigned number, with a minimum value of 0, and a maximum value

"A server that knows the content of a DNS zone from local knowledge, and thus can answer queries about that zone without needing to query other servers."  (Quoted from RFC2182, <del> Section 2.)  It is a system that responds to DNS queries with information about zones for which it has been configured to answer with the AA flag in the response header set to 1.  It is a server that has authority over one or more DNS zones.  Note that it is possible for an authoritative server to respond to a query without the parent zone delegating authority to that server. Authoritative servers also provide "referrals", usually to child zones delegated from them; these referrals have the AA bit set to 0 and come with referral data in the Authority and (if needed) the Additional sections. </del> <ins> Section 2.)  An authoritative server is named in the NS ("name server") record in a zone.  It is a system that responds to DNS queries with information about zones for which it has been configured to answer with the AA flag in the response header set to 1.  It is a server that has authority over one or more DNS zones.  Note that it is possible for an authoritative server to respond to a query without the parent zone delegating authority to that server.  Authoritative servers also provide "referrals", usually to child zones delegated from them; these referrals have the AA bit set to 0 and come with referral data in the Authority and (if needed) the Additional sections. </ins> A name server that only serves authoritative data and ignores requests for recursion.  It will "not normally generate any

zone that have changed (described in RFC1995).  Many systems use non-standard methods for zone transfer outside the DNS protocol. <ins> See "Secondary server". </ins> "An authoritative server which uses zone transfer to retrieve the zone" (Quoted from RFC1996, Section 2.1).  Secondary servers are also discussed in RFC1034.  RFC2182 describes secondary servers in

this as a "slave", the current common usage has shifted to calling it a "secondary". <del> See secondary server. </del> <ins> See "Primary server". </ins> "Any authoritative server configured to be the source of zone transfer for one or more [secondary] servers" (Quoted from

RFC1996 referred to this as a "master", the current common usage has shifted to "primary". <del> See primary server. </del> "The primary master is named in the zone's SOA MNAME field and optionally by an NS RR".  (Quoted from RFC1996, Section 2.1). RFC2136 defines "primary master" as "Master server at the root of

NODATA NOERROR NOTIMP <ins> NS </ins> NSEC NSEC3 NXDOMAIN

S SERVFAIL <ins> SOA </ins> SOA field names Secondary server Secure Entry Point (SEP)