Re: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-dnsop-dns-terminology-04

[Jari Arkko <[e-mail]>]

Thanks for your in-depth review, David. And thank you authors for addressing the major concerns.

Jari

On 11 Sep 2015, at 13:45, Black, David <[e-mail]> wrote:

> 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; [e-mail]; [e-mail]; General Area Review
>> Team ([e-mail]) [e-mail]
>> Cc: [e-mail]; [e-mail]; 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
>> [phone]             FAX: [phone]
>> [e-mail]        Mobile: [phone]
>> ----------------------------------------------------
>> 
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art