Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-qname-minimisation-07

[Stephane Bortzmeyer <[e-mail]>]

On Fri, Nov 20, 2015 at 04:22:21PM +0000,
 Ralph Droms (rdroms) <[e-mail]> wrote 
 a message of 97 lines which said:

> I am the assigned Gen-ART reviewer for
> draft-ietf-dnsop-qname-minimisation-07.txt.

Hello. Glad to have reviewers.

> Has the working group considered publishing this document as
> "Informational" rather than "Experimental"?  If the document is
> published as "Experimental", is the intention to publish a
> subsequent proposed standard or BCP?

[See Tim's answer.]

> I found the descriptions in the document understandable, but not
> quite detailed enough to build an interoperable implementation.

There is something very important about qname minimisation: it is a
local technique, not a protocol. It works with unmodified authoritative
name servers. So "interoperability" is not a concern because it does
not change the DNS protocol. Consequence: each resolver MAY implement
it slightly differently (see appendix B).

> Is Appendix A intended as the specification for the QNAME
> minimization techniques described in this document?

No. That's why it's in an appendix. Most resolvers already can find
the zone cuts (they need it to do DNSSEC), this appendix is to give
ideas to developers of the other resolvers.

> The appendix is titled "An algorithm to find the zone cut" and the
> introductory text indicates the algorithm is intended for locating
> the zone cut.  However, as I read the algorithm, it finds and
> traverses all zone cuts until the original QNAME can be resolved.

The title may be misleading. What about "An algorithm to perform QNAME
minimisation in presence of zone cuts?"

> In section 2, is the phrase "closest known parent of the original
> QNAME" something that most DNS developers would understand?

Well, "parent" could be misleading because it is rather "ancestor"
(the example in the draft show a grand-parent).

> Would the phrase "closest enclosing NS RRset" from Appendix A be
> more precise?

"Known" is very important here. What about "closest known enclosing NS
RRset"?

> I wasn't sure at first whether "(section 6)" in the 4th paragraph of
> section 2 referred to section 6 of RFC 2181 or section 6 of this
> document.

OK, fixed in my local copy.