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

From: "Black, David" <[email-masked]>
Date: Tue, 11 Aug 2015 00:09:00 +0000

This is a combined Gen-ART and OPS-Dir review.  Boilerplate for both follows ...

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at:

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These comments
were written primarily for the benefit of the operational area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.

Document: draft-ietf-dnsop-dns-terminology-03
Reviewer: David Black
Review Date: August 10, 2015
IETF LC End Date: August 11, 2015

Summary:  This draft is on the right track, but has open issues
 		described in the review.

This draft is a very useful compendium of DNS-related definitions, and the
authors have done the community yeoman service by compiling this information,
including pointing out inconsistencies in existing RFCs and places where
term usage has changed over time.  The draft is generally well written
and an easy read - this reviewer is not a DNS expert, but I had no
difficulty in understanding the draft.

I found a couple of potentially major process issues, as well as a few
minor content issues that should be easy to address.

Major Issues:

[BCP] Is BCP status appropriate for this draft?

As I read RFC 2026, Section 5, a BCP should be:

	- "a statement of principle"; or
	- "what is believed to be the best way to perform some
		operations or IETF process function".

The set of definitions in this document, while very useful, don't appear
to fall into either of those categories.  WRT the latter category, see the
nearly-blank OPS-Dir review below.

[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.

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.

[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"

[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.

[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?

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"

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.

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 .

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.

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"?

p.9:

   Authoritative-only server:  A name server which only serves

"which" -> "that"

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".

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"

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"

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.

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

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 10 Aug 2015 18:50:41 -0700

Thank you for the careful review! Comments below, in an shortened form.

> [BCP] Is BCP status appropriate for this draft?

Based on earlier comments, we have chosen to change this to 
Informational for the next draft.

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

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

> 	 "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.

> readers in some future decade.

We are adding more in the next draft, as well as changing the example.

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

> "a database representing" -> "a distributed database representing"

Good, yes.

> the final sentence above and "deals" -> "was dealing" should suffice.

Good catch, yes.

> "RDATA" is in section 4.1.3 .

Yep.

> term is shorter, not the record.

Sure.

> Should this section be titled "DNS Servers and Clients"?

It started out as just "Servers", but then transmorgified. Fixed.

> Authoritative-only server:  A name server which only serves

Indeed.

> Please add a forward reference to Section 6 for the definition of 

Sure.

>    around the bottom edge of the zone.

Nope, not gonna change the direct quote from RFC 1034.

> "mitigates" -> "mitigate"

Yes

> is in text quoted from RFC 4035.

Disagree. The excepted quotes require you to read the referenced RFCs, 
which call in 2119 as appropriate.

> and in that regard, this is a generally worthy document that should be

We sure hope so.

Thanks again for the review! You will see the above changes in the next 
draft.

--Paul Hoffman

---

From: "Black, David" <[email-masked]>
Date: Tue, 11 Aug 2015 13:28:11 +0000

Paul,

> 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:[email-masked]]
> Sent: Monday, August 10, 2015 9:51 PM
> To: Black, David
> Cc: General Area Review Team ([email-masked]); [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Gen-ART and OPS-Dir review of draft-ietf-dnsop-dns-terminology-03
>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 11 Aug 2015 12:03:06 -0400

Hi,

> an FQDN identifies a "sequence of nodes".

Hmm.  What if this changed to "The identifier of an individual node in
the sequence of nodes identifier by a fully-qualified domain name"?  I
think that would get rid of the quibble you have and still emphasise
that it's one node in a sequence.  

The point is that the label is an identifier of a node, not the node
itself.  The discussion of this in RFC 1034 is quite long and never
actually offers the definition as such.  So we want to note that the
label identifies one node in the sequence of nodes.

Does that work?

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Black, David" <[email-masked]>
Date: Tue, 11 Aug 2015 16:34:44 +0000

> label identifies one node in the sequence of nodes.

Yes, that works with a minor typo fix:

	"sequence of nodes identifier" -> "sequence of nodes identified"

And we agree on the primary point of my original comment.

Thanks,
--David

> From: Andrew Sullivan [mailto:[email-masked]]
> Sent: Tuesday, August 11, 2015 12:03 PM
> To: Black, David
> Cc: Paul Hoffman; [email-masked]; General Area Review Team ([email-masked]);
> [email-masked]; [email-masked]
> Subject: Re: [DNSOP] Gen-ART and OPS-Dir review of draft-ietf-dnsop-dns-
> terminology-03
> 
> Hi,
>