On Mar 11, 2015, at 9:02 AM, Stephane Bortzmeyer <bortzme...@nic.fr> wrote: > > On Wed, Mar 11, 2015 at 12:35:29AM -0400, > Shumon Huque <shu...@gmail.com> wrote > a message of 400 lines which said: > >> Are we standardizing on the british spelling of "minimisation" in >> preference to the americanized "minimization"? > > Bikeshedding is postponed until Working Group Last Call :-)
Or beyond. The RFC Editor allows both types of spelling, and they will make it consistent. >> I'd prefer the simpler "The problem statement is described in ..". >> The term "exposed" in my mind carries a more sensational connotation, >> but I might be nitpicking. > > Advice from english writers here? +1 to Shumon: "exposed" is more sensational, and not appropriate here. >> "The idea is to minimize the form of the query name sent by the >> resolver, by including only the minimum number of rightmost labels >> needed in outbound queries to authoritative servers. Additional >> labels are prepended to the query name for subsequent queries as >> responses and referrals are obtained." > > Rigorous but may be too long and convoluted? I prefer rigor, and it is not convoluted. >>> Under current practice, when a resolver receives the query >>> "What is the AAAA record for www.example.com?", it sends to the root >>> (assuming a cold resolver, whose cache is empty) the very same >>> question. >> >> "Under current practice" implies a description of what is currently >> being done before this new resolution method is introduced. When in >> fact this paragraph is describing the new method. > > No, not at all. It describes the current practice. Under the new > (qname minimisation), the resolver would send only "com" to the root. +1 to Stephane here. >>> To do such minimisation, the resolver needs to know the zone cut >>> [[54]RFC2181]. Zone cuts do not necessarily exist at every label >>> boundary. If we take the name www.foo.bar.example, it is possible >> >> This makes it sound like minimisation requires a resolver to apriori >> know the zone cuts. This is not necessarily correct. A resolver can >> learn the zone cuts in the process of adding labels and doing normal >> iterative resolution. > > Yes, it is explained later. It would be better to say "as described later" right after the reference to RFC 2181 so that the reader doesn't think "therefore I can't do this". We want the document to not only describe the practice, but also to encourage it. > >> One thing this document doesn't make clear is that the algorithm >> being presented not only minimizes the query name, but also hides >> the query type until it reaches the target zone (by using the NS >> query type rather than the actual type). > > Do note the use of NS is not mandatory. See section 3, the paragraph > starting with "Another way to deal with such broken name servers" > (which you mention later) and also section 3, 1st paragraph about the > statistics of qtypes. My strong preference is that this document only deal with qname minimization. If someone wants to extend that to qtype minimization, which covers a different threat model, that should be done in a different document. >> This should more precisely define which types of forwarders will get >> less data. I think you mean the forwarders upstream of the resolver >> performing qname minimization, rather than forwarders that might exist >> between the client and the minimizing resolver. > > They are not typically called forwarders (see the discussion about > draft-hoffman-dns-terminology) Different thread. :-) >> This suggested workaround doesn't help with all forms of broken >> servers. > > Nothing deals with all the brokenness found on the Internet. +1, and unnecessary to state. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
