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 rev. 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
Draft last updated 2016-01-10
Completed reviews Genart Last Call review of -05 by Brian Carpenter (diff)
Genart Telechat review of -06 by Brian Carpenter (diff)
Secdir Last Call review of -05 by Derek Atkins (diff)
Assignment Reviewer Brian Carpenter
State Completed
Review review-ietf-dnsop-edns-chain-query-05-genart-lc-carpenter-2016-01-10
Reviewed rev. 05 (document currently at 07)
Review result Almost Ready
Review completed: 2016-01-10

Review
review-ietf-dnsop-edns-chain-query-05-genart-lc-carpenter-2016-01-10

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?