> On Nov 26, 2015, at 7:41 AM 11/26/15, Stephane Bortzmeyer <bortzme...@nic.fr> > wrote: > > On Fri, Nov 20, 2015 at 04:22:21PM +0000, > Ralph Droms (rdroms) <rdr...@cisco.com> 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.
This document is well-written and easy to read. It's a pleasure to do the review. > >> 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.] OK. > >> 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). OK, I understand this is a local technique and does not represent a change to the DNS protocols. Even so, in my opinion there are some details that are not provided in the document (see below). >> 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. Would you consider adding a little text somewhere to make it clear that the Appendix is intended as a guide to implementors? >> 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?" Perhaps "unknown zone cuts"? Otherwise, that title sounds good. My recommendation to improve the document would be the inclusion of another appendix, describing the algorithm to use if zone cuts are known. In my opinion, what's missing from the document for an inexperienced implementor is a summary of how to build the resolver you refer to in section 2: "The minimising resolver works perfectly when it knows the zone cut" >> 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"? OK, that text would be good. >> 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. Great. > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
