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. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop