Last Call Review of draft-ietf-dnsop-edns-chain-query-05
review-ietf-dnsop-edns-chain-query-05-genart-lc-carpenter-2016-01-10-00
| Request | Review of | draft-ietf-dnsop-edns-chain-query |
|---|---|---|
| Requested revision | No specific revision (document currently at 07) | |
| Type | Last Call Review | |
| Team | General Area Review Team (Gen-ART) (genart) | |
| Deadline | 2016-01-18 | |
| Requested | 2016-01-07 | |
| Authors | Paul Wouters | |
| I-D last updated | 2016-01-10 | |
| Completed reviews |
Genart Last Call review of -05
by Brian E. Carpenter
(diff)
Genart Telechat review of -06 by Brian E. Carpenter (diff) Secdir Last Call review of -05 by Derek Atkins (diff) |
|
| Assignment | Reviewer | Brian E. Carpenter |
| State | Completed | |
| Request | Last Call review on draft-ietf-dnsop-edns-chain-query by General Area Review Team (Gen-ART) Assigned | |
| Reviewed revision | 05 (document currently at 07) | |
| Result | Almost ready | |
| Completed | 2016-01-10 |
review-ietf-dnsop-edns-chain-query-05-genart-lc-carpenter-2016-01-10-00
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-dnsop-edns-chain-query-05.txt Reviewer: Brian Carpenter Review Date: 2016-01-07 IETF LC End Date: 2016-01-18 IESG Telechat date: 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. 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. 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. > 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. > 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?