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

["Black, David" <[e-mail]>]

Paul,

Thanks for the prompt and comprehensive response.  One quick follow-up:

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

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