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@xxxxxxx; fujiwara@xxxxxxxxxx; General Area Review
> Team (gen-art@xxxxxxxx); ops-dir@xxxxxxxx
> Cc: ietf@xxxxxxxx; dnsop@xxxxxxxx; 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.black@xxxxxxx Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>