I have been asked to review this draft on behalf of the OPS Directorate.  This draft describes to initialize a recursive DNS resolver when its cache is empty (i.e., at initial start time).  While I found the document well-written, it left me with a few questions.  Maybe these are more my issues vs. issues with the document, but I wanted to ask to see if some clarifying text might better help other operators.

First, in Section 3 why not just say that RD bit MUST NOT be set?  Why leave it to a MAY when setting the bit is undefined?  Seems like the more prescriptive you are the better.

More importantly, I found Section 4 a bit confusing.  Section 4 itself starts by saying, "A priming query is a normal DNS query".  This is good.  Makes things simple.  But then in Section 4.1 there are specific requirements for the priming response.  Those requirements seem reasonable, but it kind of conflicted (at least in my mind) with the second sentence in Section 4: "Thus, a root server cannot distinguish a priming query from any other query for the root NS RRset."  So I'm not sure that a server could know to adhere to those requirements in its response.  I suppose this could be cleared up by being explicit that the client processing the priming response MUST ensure the response has those properties or it must not prime its cache with that response.

One other question left in my head is with the priming targets configuration.  You mentioned named.root (which I'm familiar with), but you say this should not be used.  I think bind does use this by default, and I _think_ this is okay with this draft since the point is that it shouldn't solely rely on those addresses.  That is, it should use that as a list of initial target addresses, but still use the NS priming process to get the current set of A/AAAA records for the roots.  I guess what I'm asking is that if that language could be softened a bit to say that this file _could_ be used as that initial address configuration?

Thanks for your consideration.