> On Nov 23, 2015, at 9:01 AM 11/23/15, Tim Wicinski <tjw.i...@gmail.com> wrote: > > Ralph > > Thanks for the detailed review. Commeinline > > On 11/20/15 11:22 AM, Ralph Droms (rdroms) wrote: >> >> I am the assigned Gen-ART reviewer for >> draft-ietf-dnsop-qname-minimisation-07.txt. >> >> For background on Gen-ART, please see the FAQ at >> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>. >> >> Please resolve these comments along with any other Last Call comments you >> may receive. >> >> >> Document: draft-ietf-dnsop-qname-minimisation-07 >> Reviewer: Ralph Droms >> Review Date: 2015-11-20 >> IETF LC End Date: 2015-11-23 >> IESG Telechat date: unknown >> >> Summary: >> >> This draft is on the right track but has open issues, described in the >> review. >> >> Major issues: >> >> The document is well-written and easy to understand. Thank you. >> >> 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? >> > > The WG has considered several options. I believe we settled on "Experimental" > because passing the entire QNAME all the way to the root servers has always > existed, and it was unclear what unintended consequences would happen if this > was deployed. > > We do plan on producing a Standards Track document.
OK, glad to hear the WG thought through the alternatives. > >> In my opinion, the document needs a little more work if it is to be >> published as "Experimental", especially if the intention is to publish a >> proposed standard based on the results of experiments with the techniques >> described in this document. I found the descriptions in the document >> understandable, but not quite detailed enough to build an interoperable >> implementation. >> > > Do you have anything in particular on details? I can revisit with the > authors on this. In my opinion, the document provides a collection of techniques but doesn't explicitly define a specific, testable mechanism to implement. (continued below) >> Is Appendix A intended as the specification for the QNAME minimization >> techniques described in this document? 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. Here is the text I would focus on if I were writing an implementation: A resolver which implements QNAME minimisation, [...], sends a request to the name server authoritative for the closest known parent of the original QNAME. [...] The minimising resolver works perfectly when it knows the zone cut [RFC2181] (section 6). [...] (Appendix A describes this algorithm in deeper details.) As I wrote in my review, it appears to me that Appendix A gives a specification of the resolver behavior. If that's the case, it would be helpful to make that explicit statement in section 2. >> If Appendix A is not the specification for the QNAME minimization >> techniques, then I don't know exactly what specific behavior or algorithm is >> referred to by "minimising resolver" in this sentence from section 2: "The >> minimising resolver works perfectly when it knows the zone cut [...]". >> >> My suggestion would be to include another algorithm description, similar to >> that in Appendix A, but that describes how to use knowledge of zone cuts. >> > > OK > >> Editorial >> --------- >> >> In section 2, is the phrase "closest known parent of the original QNAME" >> something that most DNS developers would understand? Would the phrase >> "closest enclosing NS RRset" from Appendix A be more precise? >> > > "closest enclosing NS RRset" may be more relevant. OK. > >> 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. >> > > This is RFC2181, so perhaps it can be reworded like this: > > The minimising resolver works perfectly when it knows the zone > cut, as described in section 6 of [RFC2181]. That wording would eliminate the confusion. > > thanks > tim
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
