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 <[email protected]> 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; [email protected]; [email protected]; General Area Review >> Team ([email protected]); [email protected] >> Cc: [email protected]; [email protected]; 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 >> [email protected] Mobile: +1 (978) 394-7754 >> ---------------------------------------------------- >> > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
