Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed;
 boundary="Apple-Mail=_1F201A33-4BC3-46D0-AAB2-C95DC7481C60";
 protocol="application/pgp-signature"; micalg=pgp-sha512
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <CE03DB3D7B45C245BCA0D24327794936140B4DE9@MX104CL02.corp.emc.com>
Date: Thu, 17 Sep 2015 06:45:18 -0700
Message-Id: <67AF503A-FAFF-4476-993F-E8EA00FA2740@piuha.net>
References: <CE03DB3D7B45C245BCA0D24327794936140B4DE9@MX104CL02.corp.emc.com>
To: "Black, David" <david.black@emc.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/8kx16AMy9FhbXvHBQmfU7BB8hUs>
Cc: Tim Wicinski <tjw.ietf@gmail.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>, 
 "asullivan@dyn.com" <asullivan@dyn.com>,
 "fujiwara@jprs.co.jp" <fujiwara@jprs.co.jp>,
 "General Area Review Team \(gen-art@ietf.org\)" <gen-art@ietf.org>,
 Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [Gen-art] Gen-ART and OPS-Dir review of
 draft-ietf-dnsop-dns-terminology-04
Precedence: list


--Apple-Mail=_1F201A33-4BC3-46D0-AAB2-C95DC7481C60
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

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 <david.black@emc.com> 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.
>=20
> The following two minor issues still merit attention:
>=20
>> [C] 2. Names - p.5, end of Public suffix definition:
>>=20
>>      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.
>>=20
>> 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.
>=20
> ".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 ?
>=20
>>=20
>> [D] 8. General DNSSEC - p.16
>>=20
>>   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.)
>>=20
>> That doesn't seem to actually define anything.
>> What do those two terms mean?
>=20
> The -04 version adds the following text before the parenthetical note:
>=20
> 	However, "DNSSEC-
>      aware" and "DNSSEC-unaware" are used in later RFCs, but never
>      formally defined.
>=20
> The resulting modified definition still doesn't define anything :-).
>=20
> 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.
>=20
> Thanks,
> --David
>=20
>> -----Original Message-----
>> From: Black, David
>> Sent: Monday, August 10, 2015 8:09 PM
>> To: Paul Hoffman; asullivan@dyn.com; fujiwara@jprs.co.jp; General =
Area Review
>> Team (gen-art@ietf.org); ops-dir@ietf.org
>> Cc: ietf@ietf.org; dnsop@ietf.org; Black, David; Tim Wicinski
>> Subject: Gen-ART and OPS-Dir review of =
draft-ietf-dnsop-dns-terminology-03
>>=20
>> This is a combined Gen-ART and OPS-Dir review.  Boilerplate for both =
follows
>> ...
>>=20
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at:
>>=20
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>=20
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>>=20
>> 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.
>>=20
>> Document: draft-ietf-dnsop-dns-terminology-03
>> Reviewer: David Black
>> Review Date: August 10, 2015
>> IETF LC End Date: August 11, 2015
>>=20
>> Summary:  This draft is on the right track, but has open issues
>> 		described in the review.
>>=20
>> 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.
>>=20
>> I found a couple of potentially major process issues, as well as a =
few
>> minor content issues that should be easy to address.
>>=20
>> Major Issues:
>>=20
>> [BCP] Is BCP status appropriate for this draft?
>>=20
>> As I read RFC 2026, Section 5, a BCP should be:
>>=20
>> 	- "a statement of principle"; or
>> 	- "what is believed to be the best way to perform some
>> 		operations or IETF process function".
>>=20
>> 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.
>>=20
>> [DownRef] idnits 2.13.02 found a number of obsolete references and =
downrefs.
>>=20
>> These are all probably ok, given the historical retrospective nature =
of this
>> draft, but the authors should double-check them:
>>=20
>>  ** Obsolete normative reference: RFC  882 (Obsoleted by RFC 1034, =
RFC 1035)
>>=20
>>  ** Obsolete normative reference: RFC 1206 (Obsoleted by RFC 1325)
>>=20
>>  ** Downref: Normative reference to an Informational RFC: RFC 6561
>>=20
>>  ** Downref: Normative reference to an Informational RFC: RFC 6781
>>=20
>>  ** Downref: Normative reference to an Informational RFC: RFC 6841
>>=20
>>  ** Downref: Normative reference to an Informational RFC: RFC 7344
>>=20
>> 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.
>>=20
>> Minor Issues:
>>=20
>> [A] Introduction - p.3
>>=20
>>   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.
>>=20
>> 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.
>>=20
>> [B] 2. Names - p.4
>>=20
>>   Label:  The identifier of an individual node in the sequence of =
nodes
>>      that comprise a fully-qualified domain name.
>>=20
>> Unless I've missed something fundamental, please change:
>> 	 "sequence of nodes" -> "sequence of identifiers"
>>=20
>> [C] 2. Names - p.5, end of Public suffix definition:
>>=20
>>      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.
>>=20
>> 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.
>>=20
>> [D] 8. General DNSSEC - p.16
>>=20
>>   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.)
>>=20
>> That doesn't seem to actually define anything.
>> What do those two terms mean?
>>=20
>> Nits/editorial comments:
>>=20
>> Introduction - p.3
>>=20
>>   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.
>>=20
>> "a database representing" -> "a distributed database representing"
>>=20
>> 2. Names - p.5
>>=20
>>   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.
>>=20
>> 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.
>>=20
>> 3. DNS Header and Response Codes - p.5
>>=20
>>   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".
>>=20
>> This reference is actually to the diagrams in sections 4.1.1-4.1.3, =
e.g.,
>> "RDATA" is in section 4.1.3 .
>>=20
>> 4.  Resource Records - p.6
>>=20
>>   RR:  A short form for resource record.
>>=20
>> Please add "(acronym)" after "short form" to make it clear that the
>> term is shorter, not the record.
>>=20
>> 5.  DNS Servers - p.8
>>=20
>>   This section defines the terms used for the systems that act as DNS
>>   clients, DNS servers, or both.
>>=20
>> Should this section be titled "DNS Servers and Clients"?
>>=20
>> p.9:
>>=20
>>   Authoritative-only server:  A name server which only serves
>>=20
>> "which" -> "that"
>>=20
>> p.10:
>>=20
>>   Zone transfer:  The act of a client requesting a copy of a zone and
>>      an authoritative server sending the needed information.
>>=20
>> Please add a forward reference to Section 6 for the definition of =
"zone".
>>=20
>> 6. Zones - p.14
>>=20
>>   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.
>>=20
>> "top node" -> "apex"
>>=20
>> 8. General DNSSEC - p.17
>>=20
>>   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.
>>=20
>> "mitigates" -> "mitigate"
>>=20
>> idnits 2.13.02 thinks RFC 2119 boilerplate needs to be added:
>>=20
>>  ** 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.
>>=20
>>     RFC 2119 keyword, line 774: '...    the resolver SHOULD treat the
>> chil...'
>>=20
>> Adding that boilerplate is probably a good idea, even though the =
"SHOULD"
>> is in text quoted from RFC 4035.
>>=20
>> --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ---
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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@emc.com        Mobile: +1 (978) 394-7754
>> ----------------------------------------------------
>>=20
>=20
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art


--Apple-Mail=_1F201A33-4BC3-46D0-AAB2-C95DC7481C60
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV+sPvAAoJEM80gCTQU46q7b0P/ifxHHH8/Z4PdZCQuu0hz7Co
ZTRqFjNaolyRkfumfBrWxKBRAlLNCv7E74bTBZwJ/cz0qzuspY5K+dQQiW/V5j7q
YCeXT6s4Kk8eHXQZHHBgJnPvPVuF/EYXC5JVF430yPTYH7y0XaeEvMw5Qz/ox/hD
RlA5HD/RysOWTVaFI7TbFAeTVLVvQgoi/hC1YiJl8N2i4PbOUcUqZWdPPFRgfNsW
7hwdxXEU8OccasiI1+IR9bTaG0ug0/lGqlqK5JEgqp/S0eveClfdQN+ZdMKiOltK
LjZDqVTZA6B7bwC0GDBVW0k1LLP/8ihEAoeULvo0PxZ/otWZ8uCVS4h5o4OZGZ/y
wFa6EW/ynxRgzOg0InyHfl+jfXTcIXzPjfunjQkfAn2uRCoIs5rzvPvp3K/AT9B8
fKb/F7zc3Ch0UImvrLx45DZ8vxIk+rITTDcJg6dGnGUYsE1JHIHGwbmRcz/G7bws
ZRp+FYfm0rBQvIZntmJ59h6TF4xdbZIObXF1jZsnRJjXiuWBnmc5G+McGU3SXlzP
+HggXhP/5kbMStEn1HTBH4jYDxwSflhEC6ZE3sa6IdvsJuR9pbhT5NwHzPPcdjaN
yyQcOcjFnCBpc7szFy1RgcFYTh7OlDm5jWpDaaAhQe3SWF3dsWT9rmvaMM3hYU2d
SywOlqwS4A7FD5rhUPRf
=tGN4
-----END PGP SIGNATURE-----

--Apple-Mail=_1F201A33-4BC3-46D0-AAB2-C95DC7481C60--