ietf
[Top] [All Lists]

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

2015-08-10 21:10: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