ietf
[Top] [All Lists]

RE: Gen-ART and OPS-Dir review of draft-ietf-dnsop-dns-terminology-04

2015-09-11 15:46:42
The -04 version of this draft addresses most of the concerns noted in the
Gen-ART and OPS-Dir review of the -03 version.  In particular, both of
the major process-related issues have been addressed by retargeting the
draft to be an Informational RFC instead of a Best Current Practice RFC.

The following two minor issues still merit attention:

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

".uk zone" is changed to ".uk TLD" in -04.   Additional info should be
provided to explain "the case of the .uk TLD around the time this document
is published."  What is going on with .uk ?


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

The -04 version adds the following text before the parenthetical note:

        However, "DNSSEC-
      aware" and "DNSSEC-unaware" are used in later RFCs, but never
      formally defined.  

The resulting modified definition still doesn't define anything :-).

Is it trying to say that these two terms are undefined and should not be
used, with use of the more specific terms in RFC 4033 being preferable?
If so, that's not clear.

Thanks,
--David

-----Original Message-----
From: Black, David
Sent: Monday, August 10, 2015 8:09 PM
To: Paul Hoffman; asullivan(_at_)dyn(_dot_)com; 
fujiwara(_at_)jprs(_dot_)co(_dot_)jp; General Area Review
Team (gen-art(_at_)ietf(_dot_)org); ops-dir(_at_)ietf(_dot_)org
Cc: ietf(_at_)ietf(_dot_)org; dnsop(_at_)ietf(_dot_)org; Black, David; Tim 
Wicinski
Subject: Gen-ART and OPS-Dir review of draft-ietf-dnsop-dns-terminology-03

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
david(_dot_)black(_at_)emc(_dot_)com        Mobile: +1 (978) 394-7754
----------------------------------------------------



<Prev in Thread] Current Thread [Next in Thread>