Last Call Review of draft-ietf-dnsop-resolver-priming-09
review-ietf-dnsop-resolver-priming-09-opsdir-lc-ersue-2016-12-12-00

Request Review of draft-ietf-dnsop-resolver-priming
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-11-10
Requested 2016-11-03
Draft last updated 2016-12-12
Completed reviews Genart Last Call review of -09 by Joel Halpern (diff)
Opsdir Last Call review of -09 by Mehmet Ersue (diff)
Assignment Reviewer Mehmet Ersue
State Completed
Review review-ietf-dnsop-resolver-priming-09-opsdir-lc-ersue-2016-12-12
Reviewed rev. 09 (document currently at 11)
Review result Ready
Review completed: 2016-12-12

Review
review-ietf-dnsop-resolver-priming-09-opsdir-lc-ersue-2016-12-12

 reviewed the document "Initializing a DNS Resolver with Priming Queries" (draft-ietf-dnsop-resolver-priming-09.txt)
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.
 
Intended status: Best Current Practice                          
Current IESG state: IESG Evaluation
IANA State: OK
 
Summary: The document describes the queries that a DNS resolver should emit to initialize its cache.
 
The document states:
"[RFC1034] describes that configuration as a list of servers that will give authoritative answers to queries about the root.  This has become a _common implementation choice_ for recursive resolvers, and is the topic of this document."
 
The document further states:
"This document describes the steps needed for _this common implementation choice_.  Note that this is not the only way to start a recursive name server with an empty cache, but it is the only one described in [RFC1034]."
 
I don't see any issues related to operations and management.
 
However I have an issue with the intended document status being a "Best Current Practice".
Describing the necessary steps for a _common implementation choice_ is IMO not worth to publish as a BCP document. Furthermore, as the document states there are other possible ways to start recursive name servers and "some implementers have chosen other directions, some of which work well . . .".
 
As BCP 9 clarifies, BCP documents are designed to be a way to standardize practices and the results of community consensus. As I understand the document did not achieve a community consensus on one of the available _implementation choices_. It just describes one of the options.
 
BCP 9 further clarifies:
BCP document "is a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function."
 
I believe describing the steps needed for a _common implementation choice_ would be much better published as an Experimental RFC.
 
To be able to declare a _common implementation choice_ as BCP we would need substantial references to current practice in the Internet and an IETF consensus on being this the best solution. What I see in the draft is not sufficient for this purpose.
 
Regards,
Mehmet