DNS Query Name Minimisation to Improve Privacy
draft-ietf-dnsop-qname-minimisation-09

What is the purpose of the experiment?  

As explained in the text, the implementation is a unilateral change…do you want to experiment on the impact of the algorithm in the document, on comparing multiple algorithms (how much they're used, efficiency wrt privacy), etc..  All of the above?  Something else?

I like the general approach here.  I agree with Alvaro that it'd be good to be clearer about what the experiment is -- for the purpose of knowing when it's been satisfied and when we can consider having this a standard or a BCP.

I found the document to be a difficult read because of the language.  I'll try to suggest things that I think will improve some places, but, in general, the RFC Editor will have to do a lot of editing.

The Introduction is a bit abrupt, and starts out by giving an over-broad pointer to the dprive problem statement (and using an odd word: exposed).  I suggest this opening instead:

OLD
   The problem statement is exposed in [RFC7626].  The terminology
   ("QNAME", "resolver", etc) is also defined in this companion
   document.  This specific solution is not intended to fully solve the
   DNS privacy problem; instead, it should be viewed as one tool amongst
   many.

NEW
   QNAME minimisation attempts to address one aspect of the general
   DNS privacy problem [RFC7626], and should be considered as one tool
   among many that will address different aspects.  Some terminology
   used herein ("QNAME", "resolver", etc) is also defined in the
   problem statement document.

END

The "it" in the next sentence ("It follows the principle") should probably also be replaced by "QNAME minimisation"; the sentence is otherwise unclear.

-- Section 3 --

   For instance, some authoritative name servers embedded in load
   balancers reply properly to A queries but send REFUSED to NS queries.
   This behaviour is a gross protocol violation, and there is no need to
   stop improving the DNS because of such brokenness.

We do better when we avoid this kind of invective in our standards specs, and when we support statements with references.  I suggest eliminating the words "gross" and "brokenness", and to instead include a reference to a section of a specification that says why this behaviour is incorrect.  Like this:

NEW
   For instance, some authoritative name servers embedded in load
   balancers reply properly to A queries but send REFUSED to NS queries.
   This behaviour violates the DNS protocol (see Section ??? of [RFC??],
   and improvements to the DNS are impeded if we accept such behaviour
   as normal.
END

   Another way to deal with such broken name servers would be to try
   with QTYPE=A requests

Again: please lose "broken" and try to describe things more calmly.  And "to try with QTYPE=A requests"... to try *what* with QTYPE=A requests?  "Try" seems to want a direct object here, and I don't see one.

   See also section 3 of [I-D.vixie-dnsext-resimprove] for the other bad
   consequences of this brokenness.

Again: "brokenness"...

   Other strange and non-conformant practices may pose a problem:

"Other practices that do not conform to the DNS protocol standards may also pose problems."

   there
   is a common DNS anti-pattern

Is "anti-pattern" a common term that I'm just not familiar with?  That's likely, of course.  But if not, please replace it.  And probably remove "serious" later in the sentence.

   (It is not known why they don't just wildcard all of "*." and be done
   with it.)

What's the point of this sentence?  Can't it just be removed?  We really shouldn't write standards that sound like rants... please.

   This lets them turn up many web hosting customers without having to
   configure thousands of individual zones on their nameservers.

What does "turn up" mean here?

-- Section 6 --

   However, it may have other advantages.

I suggest changing "However, it may have" to "It may also have", to give this a more positive tone.

   Thus in this common case the total number of upstream
   queries under QNAME minimisation would be counter-intuitively less
   than the number of queries under the traditional iteration (as
   described in the DNS standard).

I think changing "be counter-intuitively" to "actually be" works much better here.

This seems like a well thought out idea.

I concur with Alvaro's comment about the nature of the experiment, and most of Barry's comments about removing invective. (To which I add "low-end web hosters").

Thanks - this looks like it's really really well worked
out. I like the basic idea of course, but the execution
here is very well done. 

The secdir review noted some nits you might want to fix
at auth-48. [1]

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06230.html

I like this idea and the way this is constructed. Well done.