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

 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