Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-edns-chain-query-05

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 Jan 2016 17:21:39 +1300

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?

---

From: Paul Wouters <[email-masked]>
Date: Sun, 10 Jan 2016 23:32:12 -0500

On 01/09/2016 11:21 PM, Brian E Carpenter wrote:

(added dnsop to the CC: for some feedback)

Thanks for the review Brian!

> of method, but since the proposed status is Experimental, that doesn't

Added the word "potentially" as suggested.

> 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.

> whether something needs to be said about this, but DNS64 does mess

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.

> 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.

> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jan 2016 08:10:17 +1300

Hi Paul,

I glanced at the -06 version and (together with your previous
reply) it looks fine to me.

Thanks
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jan 2016 08:10:31 +1300

Hi Paul,

I glanced at the -06 version and (together with your previous reply) it looks fine to me.

Thanks
   Brian