Paul, Thanks for the prompt and comprehensive response. One quick follow-up: > > [B] 2. Names - p.4 > > > > Label: The identifier of an individual node in the sequence of nodes > > that comprise a fully-qualified domain name. > > > > Unless I've missed something fundamental, please change: > > "sequence of nodes" -> "sequence of identifiers" > > You may have missed something fundamental, or just parsed the sentence > wrong. The individual node is truly in a sequence of nodes. Ok, but the defined term is "label" not "node". In other words, I would have expected the fully-qualified domain name to be a sequence of labels, each of which is an identifier that identifies a node, making a fully qualified domain name a "sequence of identifiers", not a "sequence of nodes". Of course the "sequence of identifiers" in an FQDN identifies a "sequence of nodes". Everything else in the response looks reasonable to me. Thanks, --David > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@xxxxxxxx] > Sent: Monday, August 10, 2015 9:51 PM > To: Black, David > Cc: General Area Review Team (gen-art@xxxxxxxx); ops-dir@xxxxxxxx; > dnsop@xxxxxxxx; ietf@xxxxxxxx > Subject: Re: Gen-ART and OPS-Dir review of draft-ietf-dnsop-dns-terminology-03 > > Thank you for the careful review! Comments below, in an shortened form. > > On 10 Aug 2015, at 17:09, Black, David wrote: > > > Major Issues: > > > > [BCP] Is BCP status appropriate for this draft? > > Based on earlier comments, we have chosen to change this to > Informational for the next draft. > > > [DownRef] idnits 2.13.02 found a number of obsolete references and > > downrefs. > > > > These are all probably ok, given the historical retrospective nature > > of this > > draft, but the authors should double-check them: > > > > ** Obsolete normative reference: RFC 882 (Obsoleted by RFC 1034, RFC > > 1035) > > > > ** Obsolete normative reference: RFC 1206 (Obsoleted by RFC 1325) > > > > ** 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 7344 > > > > I've tagged this as a major issue solely because I believe that > > Downrefs are > > supposed to be explicitly noted in the IETF Last Call announcement, > > and that > > does not appear to have occurred in this case. > > We did look carefully at all of these. When we do a -bis of this > document (which is intended to be BCP), maybe the chairs and AD will > remember the explicit notice in the IETF Last Call announcement. Or > maybe there will be a tool that looks for this before IETF Last Call > announcements can be made... > > > Minor Issues: > > > > [A] Introduction - p.3 > > > > In this document, where the consensus definition is the same as the > > one in an RFC, that RFC is quoted. Where the consensus definition > > has changed somewhat, the RFC is mentioned but the new stand-alone > > definition is given. > > > > Should any RFCs be formally Updated when the latter sentence applies, > > or > > are any such actions being deliberately deferred to the revision of > > this > > document promised in the fourth paragraph of its Introduction? If the > > latter, please add a sentence to say so. > > As we said earlier, we intend to have this be Informational, with the > -bis document being BCP and updating older RFCs as appropriate. That > will be much harder than the current work. > > > > > [B] 2. Names - p.4 > > > > Label: The identifier of an individual node in the sequence of nodes > > that comprise a fully-qualified domain name. > > > > Unless I've missed something fundamental, please change: > > "sequence of nodes" -> "sequence of identifiers" > > You may have missed something fundamental, or just parsed the sentence > wrong. The individual node is truly in a sequence of nodes. > > > > > [C] 2. Names - p.5, end of Public suffix definition: > > > > One example of the difficulty of calling a domain a > > public suffix is that designation can change over time as the > > registration policy for the zone changes, such as the case of the > > .uk zone around the time this document is published. > > > > That calls for either an explanation or citation of a reference where > > further info can be found on this situation. This seems editorial, > > but > > RFCs are archival documents, and this sentence is likely to be lost on > > readers in some future decade. > > We are adding more in the next draft, as well as changing the example. > > > > > [D] 8. General DNSSEC - p.16 > > > > DNSSEC-aware and DNSSEC-unaware: Section 2 of [RFC4033] defines many > > types of resolvers and validators, including "non-validating > > security-aware stub resolver", "non-validating stub resolver", > > "security-aware name server", "security-aware recursive name > > 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 those > > documents, is nevertheless not defined in that section.) > > > > That doesn't seem to actually define anything. > > What do those two terms mean? > > Those terms are defined in RFC 4033, and that definition is not repeated > here because it happens over a few sections. > > > Nits/editorial comments: > > > > Introduction - p.3 > > > > Note that there is no single consistent definition of "the DNS". It > > can be considered to be some combination of the following: a > > commonly-used naming scheme for objects on the Internet; a database > > representing the names and certain properties of these objects; an > > architecture providing distributed maintenance, resilience, and loose > > coherency for this database; and a simple query-response protocol (as > > mentioned below) implementing this architecture. > > > > "a database representing" -> "a distributed database representing" > > Good, yes. > > > > > 2. Names - p.5 > > > > Public suffix: A domain under which subdomains can be registered, > > and on which HTTP cookies ([RFC6265]) should not be set. There is > > no indication in a domain name whether or not it is a public > > suffix; that can only be determined by outside means. The IETF > > DBOUND Working Group [DBOUND] deals with issues with public > > suffixes. > > > > RFCs are archival documents - please rephrase so that this text does > > not assert the perpetual existence of the DBOUND WG - inserting > > "At the time of publication of this document" before the start of > > the final sentence above and "deals" -> "was dealing" should suffice. > > Good catch, yes. > > > 3. DNS Header and Response Codes - p.5 > > > > Many of the fields > > and flags in the header diagram in section 4.1.1 of [RFC1035] are > > referred to by their names in that diagram. For example, the > > response codes are called "RCODEs", the data for a record is called > > the "RDATA", and the authoritative answer bit is often called "the AA > > flag" or "the AA bit". > > > > This reference is actually to the diagrams in sections 4.1.1-4.1.3, > > e.g., > > "RDATA" is in section 4.1.3 . > > Yep. > > > > > 4. Resource Records - p.6 > > > > RR: A short form for resource record. > > > > Please add "(acronym)" after "short form" to make it clear that the > > term is shorter, not the record. > > Sure. > > > > > 5. DNS Servers - p.8 > > > > This section defines the terms used for the systems that act as DNS > > clients, DNS servers, or both. > > > > Should this section be titled "DNS Servers and Clients"? > > It started out as just "Servers", but then transmorgified. Fixed. > > > > > p.9: > > > > Authoritative-only server: A name server which only serves > > > > "which" -> "that" > > Indeed. > > > > > p.10: > > > > Zone transfer: The act of a client requesting a copy of a zone and > > an authoritative server sending the needed information. > > > > Please add a forward reference to Section 6 for the definition of > > "zone". > > Sure. > > > > > 6. Zones - p.14 > > > > Authoritative data: All of the RRs attached to all of the nodes from > > the top node of the zone down to leaf nodes or nodes above cuts > > around the bottom edge of the zone. > > > > "top node" -> "apex" > > Nope, not gonna change the direct quote from RFC 1034. > > > > > 8. General DNSSEC - p.17 > > > > NSEC3: Like the NSEC record, the NSEC3 record also provides > > authenticated denial of existence; however, NSEC3 records > > mitigates against zone enumeration and support Opt-Out. > > > > "mitigates" -> "mitigate" > > Yes > > > > > idnits 2.13.02 thinks RFC 2119 boilerplate needs to be added: > > > > ** The document seems to lack a both a reference to RFC 2119 and the > > recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 > > keywords. > > > > RFC 2119 keyword, line 774: '... the resolver SHOULD treat the > > chil...' > > > > Adding that boilerplate is probably a good idea, even though the > > "SHOULD" > > is in text quoted from RFC 4035. > > Disagree. The excepted quotes require you to read the referenced RFCs, > which call in 2119 as appropriate. > > > --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- > > > > RFC 5706 Appendix A is generally inapplicable to this draft, as this > > draft > > is primarily a set of definitions that have no operational impact on > > their > > own, let alone a need for management protocol support. > > > > Clarity of terms improves the foundation for operation of the > > Internet, > > and in that regard, this is a generally worthy document that should be > > published. > > We sure hope so. > > Thanks again for the review! You will see the above changes in the next > draft. > > --Paul Hoffman