Change:
…st label', and remove dbound. Fix affiliation. I suggest these before publication. This addresses issue 18.
Yep, these all seem great.

Discussion:
Composition of names -- A name in the global DNS has one or more labels.  The length of each label is between 0 and 63 octets <del> inclusive.  In a fully-qualified domain name, the first label is 0 octets long; it is the only label whose length may be 0 octets, and it is called the "root" or "root label".  A domain name in the global DNS has a maximum total length of 255 octets in the wire format; the root represents one octet for this calculation. </del> <ins> inclusive.  In a fully-qualified domain name, the first label (logically speaking) is 0 octets long; it is the only label whose length may be 0 octets, and it is called the "root" or "root label".  A domain name in the global DNS has a maximum total length of 255 octets in the wire format; the root represents one octet for this calculation. </ins> Format of names -- Names in the global DNS are domain names. There are three formats: wire format, presentation format, and

cookies (RFC6265) should not be set.  There is no indication in a domain name whether it is a public suffix; that can only be determined by outside means.  In fact, both a domain and a <del> subdomain of that domain can be public suffixes.  At the time this document is published, the IETF DBOUND Working Group DBOUND is dealing with issues concerning public suffixes. </del> <ins> subdomain of that domain can be public suffixes. </ins> There is nothing inherent in a domain name to indicate whether it is a public suffix.  One resource for identifying public suffixes

community for many reasons, and may be significantly changed in the future.  One example of the difficulty of calling a domain a public suffix is that designation can change over time as the <del> registration policy for the zone changes, such as the case of the "uk" TLD around the time this document is published. </del> <ins> registration policy for the zone changes, such as was the case with the "uk" TLD in 2014. </ins> 3.

This section defines the terms used for the systems that act as DNS clients, DNS servers, or both. <del> For teminology specific to the public DNS root server system, see </del> <ins> For terminology specific to the public DNS root server system, see </ins> RSSAC026.  That document defines terms such as "root server", "root server operator", and terms that are specific to the way that the root zone of the public DNS is served.

server", "security-aware resolver", "security-aware stub resolver", and "security-oblivious 'anything'".  (Note that the term "validating resolver", which is used in some places in <del> DNSSEC-related documents, is also not defined.) </del> <ins> DNSSEC-related documents, is also not defined in those RFCs, but is defined below.) </ins> "A zone whose RRsets are signed and that contains properly constructed DNSKEY, Resource Record Signature (RRSIG), Next Secure

The term "verification", when used, is usually synonym for "validation". <ins> A security-aware recursive name server, security-aware resolver, or security-aware stub resolver that is applying at least one of the definitions of validation (above), as appropriate to the resolution context.  For the same reason that the generic term "resolver" is sometimes ambiguous and needs to be evaluated in context (see dns-servers-and-clients), "validating resolver" is a context-sensitive term. </ins> DNSSEC keys that "only sign the apex DNSKEY RRset in a zone."(Quoted from RFC6781, Section 3.1)