Re: Gen-ART and OPS-Dir review of draft-ietf-dnsop-dns-terminology-03

["Paul Hoffman" <[e-mail]>]

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