[DNSOP] Barry Leiba's Yes on draft-ietf-dnsop-qname-minimisation-08: (with COMMENT)

["Barry Leiba" <[e-mail]>]

Barry Leiba has entered the following ballot position for
draft-ietf-dnsop-qname-minimisation-08: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-qname-minimisation/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.