Client Subnet in DNS Queries
draft-ietf-dnsop-edns-client-subnet-08

I support Stephen's DISCUSS point. My assumption in reading the recommendation is that all recursive resolvers are recommended to disable ECS by default.

= Section 1 =
"The
   motivation for a user to configure such a Centralized Resolver varies
   but is usually because of some enhanced experience, such as greater
   cache security or applying policies regarding where users may
   connect."

Assuming by "user" you mean end user of the DNS, I think this would make more sense if it said "user or ISP" or something like that. I assume it's much more common for ISPs to explicitly choose to use centralized resolvers than for end users to do so.

= Section 2 =
Given that you reference specific implementations in various places in the document, would be interesting to note any specific implementations that surface the opt-out choice to users.

= Section 5 =

s/client location/client network location/

= Section 7.2.1 =

"A SCOPE PREFIX-LENGTH value longer than the SOURCE PREFIX-LENGTH
   indicates that the provided prefix length was not specific enough to
   select the most appropriate Tailored Response.  Future queries for
   the name within the specified network SHOULD use the longer SCOPE
   PREFIX-LENGTH."

I think it would help to expand a bit about using the exception case for the SHOULD here. It seems to me that this basically involves a judgment call by the operator of the recursive resolver between exposing a longer prefix or providing less useful information to an authoritative resolver that is indicating that it needs more information. But setting SOURCE PREFIX-LENGTH involved a judgment call in the first place about the privacy protection involved in providing a less-than-full address. So how is a recursive resolver supposed to decide whether to follow the indication from the authoritative resolver about prefix length?

I agree with Stephen's DISCUSS, and his comment about mentioning that this documents rather than recommends existing behavior in the abstract. (Or at least closer to the beginning of the introduction.)

I agree with the following suggestions from Russ Housley's Gen-ART review:

In Section 6, I think it would be useful to say that the SCOPE
PREFIX-LENGTH in a response MUST be less than or equal to the SOURCE
PREFIX-LENGTH from the request.

In Section 7.3, last paragraph, last sentence, I think that "should"
ought to be in all capital letters.

In Section 7.4, fourth paragraph, last sentence, I think that
"recommended" ought to be in all capital letters.

Thanks for handling my discuss point and the comments
below (which I didn't check in detail, but am happy to
chat about it you want).

Cheers,
S.


- abstract: I think it'd be good if the abstract noted that this
was documenting a deployed option and not necessarily
recommending this as the best thing ever. There's text in the
write-up and intro that does that nicely that could work if
reduced to one sentence, e.g. maybe something like: "This
documents an EDNS0 option that is in active use on the Internet
today that is intended to be revised in the near future to
improve it's security and privacy features."  

- Thanks for section 2.

- 7.2.2 says "Because a client that did not use an ECS option
might not be able to understand it, the server MUST NOT provide
one in its response." That seems like a bit of a pity - one
comment I was going to make was that it might be good to include
this (or something) in a response so that a client that didn't
ask for ECS could be informed that some DNS server is doing ECS.
Would that actually break things? 

- section 10 has RFC1918 as a SHOULD but doesn't refer to e.g.
RFC6598 at all.  RFC6890 has a MAY associated with it, but does
refer to 6598. And what about stuff like RFC7534, which isn't
mentioned? Is that all correct and up to date? 

- 11.1, 4th para: "Users" isn't really right. People don't know
about any of this stuff really. "Clients" would be more accurate