Hi Paul, I glanced at the -06 version and (together with your previous reply) it looks fine to me.
Thanks Brian On 11/01/2016 17:32, Paul Wouters wrote: > On 01/09/2016 11:21 PM, Brian E Carpenter wrote: > > (added dnsop to the CC: for some feedback) > > Thanks for the review Brian! > >> Summary: Almost ready >> -------- >> >> Comment: >> -------- >> >> As noted in the writeup, there was some WG controversy about this choice >> of method, but since the proposed status is Experimental, that doesn't >> seem to be an issue. >> >> Minor Issues: >> ------------- >> >> It might be better if the abstract didn't make a blunt claim about reduced >> latency. "The reduction in queries potentially lowers the latency..." would >> be safer. > > Added the word "potentially" as suggested. > >> Section 1, last paragraph: >> >>> This EDNS0 extension is only intended to be sent by Forwarders to >>> Recursive Resolvers. It can (and should) be ignored by Authoritative >>> Servers. >> >> That "should" seems normative to me. In fact, it might even be a MUST. > > You are right. I've changed "can (and should)" to MUST. > >> The technical description of the option and how it's used seems fine >> to me. Is a discussion of interaction with DNS64 (RFC6147) needed? >> RFC6147 does not mention forwarders so I don't really understand >> whether something needs to be said about this, but DNS64 does mess >> up validation chains. > > That is a very good question! > > I don't think it would interfere with DNS64 any more than a regular query > would. If the resolver doing the chain-query is the DNS64 resolver, then it > will work > fine, and only after it obtained the query-chain result will it rewrite the > answer to an AAAA record if needed. If the client is a stub asking a > chain-query, > then it would have all the same DNS64 problems with the chain-query as with a > regular query. > > The question is, should we write that up or not? I would lean towards not, as > this is not something that affects chain-queries differently from regular > queries. > >>> 7. Implementation Status >> >> In view of its final sentence, I doubt the value of this section. >> Perhaps a short section on the goals and timeline of experiments >> with this mechanism would be better. > > See https://tools.ietf.org/html/rfc6982 > > The section will be removed before final publication. I will add a note to > make this more explicit. > > >>> 9.1. Simple Query for example.com >>> >>> o A web browser on a client machine asks the Forwarder running on >>> localhost to resolve the A record of "www.example.com." by sending >>> a regular DNS UDP query on port 53 to 127.0.0.1. >> >> Why not use AAAA examples these days? > > I don't think this matters much, and there is still more operational > experience with IPv4. If people think this is important, I have no problem > changing it to AAAA. > > Paul > > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
