Subject: Re: [DNSOP] comments on draft-ietf-dnsop-edns-client-subnet-00

From: Warren Kumari <[email-masked]>
Date: Mon, 23 Feb 2015 15:23:23 -0500

Apologies to everyone for it having taken so long to address your comments.

I'm finally going through and trying to capture and incorporate comments.
Because we've taken so long to release an updated draft, making sure
we are capturing all the points if a bit tricky. In order to try avoid
having things slip through the cracks I'm going to try simply work
through the comments in order, releasing (to Github) version as I go.

On Wed, Dec 31, 2014 at 2:31 PM, 神明達哉 <[email-masked]> wrote:
> I've read the draft and have the following comments.
>
> - Section 5
>
>    o  SOURCE NETMASK, unsigned octet representing the length of the
>       netmask pertaining to the query.  In replies, it mirrors the same
>       value as in the requests.  It can be set to 0 to disable client-
>       based lookups, in which case the ADDRESS field MUST be absent.
>
>   I suspect the term "NETMASK" could be misleading or at least
>   inaccurate.  Technically, a netmask can be an arbitrary bit pattern
>   to represent a "mask", so its "length" may not always be
>   well-defined.  Also, IPv6 doesn't support the concept of
>   non-contiguous "netmask".  This definition seems to implicitly
>   assume contiguous netmasks, and define the term "NETMASK" as the
>   prefix length of an address.  I'm fine with the assumption as
>   non-contiguous IPv4 netmasks can be reasonably considered a thing of
>   past.  But in that case I'd suggest using the term "PREFIX-LENGTH",
>   noting that this specification does not support non-contiguous IPv4
>   netmasks.
>
>   Same for SCOPE NETMASK.

DONE.

Yes. NETMASK was a poor choice early on in the document life. Fixed it
to PREFIX-LENGTH (and borrowed the definition from RFC4291).

>
> - Section 5
>
>    o  SCOPE NETMASK, unsigned octet representing the length of the
>       [...]
>       It might or might not match SOURCE NETMASK; it could be shorter or
>       longer.
>
>   "match" sounds awkward since the "SOURCE NETMASK" is defined as a
>   length of bits (again, I'd suggest renaming it "SOURCE
>   PREFIX-LENGTH").  I suggest: s/match/be equal to/ (and perhaps
>   s/shorter or longer/smaller or larger/)

DONE.
I renamed to PREFIX-LENGTH and update to "be equal to". I left the
"longer or shorter", and this is (IMO) more common usage.

>
> - Section 6.1
>
>    A Stub Resolver MAY generate DNS queries with an edns-client-subnet
>    option with SOURCE NETMASK set to 0 (i.e. 0.0.0.0/0) to indicate that
>
>   I'd suggest: s/i.e./e.g./ since this may also be an IPv6 address (in
>   which case FAMILY is set to 2)

DONE.
Good point, thank you.

I updated this to be explicit ("(i.e. 0.0.0.0/0 for IPv4 or ::/0 for
IPv6) "). This seemed cleaner than the example form.

>
> - Section 6.3
>
>    fields, as detailed below.  Note that the additional and authority
>    sections from a DNS response message are specifically excluded here.
>    Any information cached from these sections MUST NOT be tied to a
>    network.
>
>   What if the "optimized" reply is a negative one for some specific
>   client addresses (while it's positive for some other addresses)?
>   The authoritative server would (or might) return an SOA in the
>   authority section, expecting the Recursive Resolver to use it for
>   negative cache specific to the corresponding client address.
>   Or are we simply excluding the support for negative optimized
>   replies?  (If so, I think it would be worth noting explicitly).

I think that we should just be excluding NXD - this fits in with my
view of how ECS should work (and what NXD "means"). Noting that this
explicitly.
Actually, I don't really know what the right answer here is - if I've
claimed that the best address for 192.0.2.0/24 is 10.10.10.10, can I
now claim that the name doesn't exist for users at 172.16.5.2?! Or,
can I return 10.10.10.10 to uses at 192.0.2.0/24 and then return
SERVFAIL for other folk? Both feel wrong - perhaps we need to say that
any error (defined later :-P) applies to all entries?!
I've created an issue in github to track this:
https://github.com/wkumari/draft-vandergaast-edns-client-subnet/issues/1

>
> - Section 6.3
>
>    If the address of the client is within any of the networks in the
>    cache, then the cached response MUST be returned as usual.  If the
>    address of the client matches multiple networks in the cache, the
>    entry with the longest SCOPE NETMASK value MUST be returned, as with
>    most route-matching algorithms.
>
>   If I understand this (and Section 6.3 in general), the following
>   "suboptimal" scenario could happen:
>   - The Authoritative Server is configured with two prefixes for
>     optimized responses: 2001:db8::/32 and 2001:db8:2::/48
>   - The Recursive Server sends a query with SOURCE of 2001:db8:1::/48
>   - The Authoritative Server finds the best matching prefix for the
>     SOURCE is 2001:db8::/32 and returns a response corresponding to
>     it, setting SCOPE NETMASK to 32
>   - The Recursive Server receives the response and caches it
>   - The Recursive Server receives a query from 2001:db8:2::1, and
>     finds it has a matching cache (with prefix being 2001:db8::/32)
>     and uses the cached response to answer the query, even if it could
>     get the specifically optimized response for 2001:db8:2::/48 from
>     the Authoritative Server.
>
>   Is my understanding correct?  If so, is this a problem to resolve or
>   something we need to accept?

Yup, very good point.

A "good" implementation of the server could note that 2001:db8:2::/48
is a subnet of 2001:db8::/32 and warn the user that the /32 may elide
the /48. It could even break the /32 into shorter prexies (all with
the same answer as the /32, apart from the more specific /48). I do
not think that it is our place to specify which the implementation
chooses, but I've noted that implementations MUST document what they
do.

>
> - Section 6.3: likewise, what about the following scenario?
>   - The Authoritative Server is configured with two prefixes for
>     optimized responses: 2001:db8::1/48 and 2001:db8:2::/48
>   - The Recursive Server receives a query from 2001:db8:3::1 and
>     sends its own query to the Authoritative Server with
>     SOURCE=2001:db8::/32, SCOPE NETMASK=48
>   - The Authoritative Server finds the two /48 prefixes match the
>     source, and returns a response using one of them.
>   - The Recursive Server receives the response and caches it.
>   - The Recursive Server receives a query from 2001:db8:3::1 again.
>     It doesn't match the cached SCOPED address, so it sends its own
>     query to the authoritative server again.
>   - This will be always the case for 2001:db8:3::1, and the cached
>     information is effectively useless, making the Recursive Server
>     busier.
>
> - Section 6.3
>
>    Any reply containing an edns-client-subnet option considered invalid
>    should be treated as if no edns-client-subnet option was specified at
>    all.
>
>   What specifically does "considered invalid" mean?  And, depending on
>   that, shouldn't the reply rather be discarded in such a case?

Addressed.

Not a clue -- I think it was just cruft from an earlier version of the
doc. There are many things that could conceivably make an ECS reply
"invalid" (for example, a PREFIX-LENGTH of /33 for an IPv4 address),
but seeing as the second paragraph of Section 6.3 contains "If the
FAMILY, SOURCE PREFIX-LENGTH, and SOURCE PREFIX-LENGTH bits of ADDRESS
in the reply don't match the fields in the corresponding request, ..."
 I don't think I need to list sanity checks here. If the recursive
sent a bizarre request, it need to deal with figuring out what to do
with the reply... so I just removed this sentence and we can re-add it
if we figure out what corner case it was trying to cover.

>
> - Section 8
>
>    The presence or absence of an [RFC6891] EDNS0 OPT resource record
>    containing an edns-client-subnet option in a DNS query does not
>    change the usage of the resource records and mechanisms used to
>    provide data origin authentication and data integrity to the DNS, as
>    described in [RFC4033], [RFC4034] and [RFC4035].  OPT records are not
>    signed.
>
>   While what's described in this section is not incorrect, I suspect
>   it's not really fair not to mention that intended deployments (i.e.,
>   CDN-like ones) with this option are not really friendly with DNSSEC
>   at best; even if it's not impossible to provide a valid signature
>   for every "optimized" response in theory, it would involve many
>   non-trivial technical challenges such as on-the-fly signing.
>
>   If these challenges make CDN-like operators unwilling to deploy
>   DNSSEC and this option makes the optimization even more attractive,
>   then this option could help hinder wider deployment of DNSSEC.
>   I'm not saying this option is evil and should be banned just because
>   of this, but I'd expect this kind of consideration for this section
>   to be more helpful and fair.

CDNs already face this issue - the availability of ECS does not (IMO)
materially change how many different answers CDNs provide, it just
allows them to better choose which of the N sets of responses get to
which client.

>
> - Section 10.1
>
>    Users who wish their full IP address to be hidden can include an
>    edns-client-subnet option specifying the wildcard address 0.0.0.0/0
>    (i.e.  FAMILY set to 1 (IPv4), SOURCE NETMASK to 0 and no ADDRESS).
>
>   What if the user (stub resolver)'s address is IPv6?  Should it still
>   set FAMILY to 1?

DONE.

I updated this to just be "Users who wish their full IP address to be
hidden can include an edns-client-subnet option specifying the
wildcard address (i.e. SOURCE PREFIX-LENGTH of 0)."

>
> - Section 10.2
>
>    With multiple queries for the same name in flight, the attacker has a
>    higher chance of success in sending a matching response (with the
>    address 0.0.0.0/0 to get it cached for many hosts).
>
>   Another IPv4-centric description.  This should probably be, e.g.
>   "with the SCOPE NETMASK being 0, meaning an empty prefix".

DONE.
... and thanks for the suggested text.

>
> - Section 12
>
>    1.   A stub resolver SR with IP address 192.0.2.37 tries to resolve
>         www.example.com, by forwarding the query to the Recursive
>         Resolver R from IP address IP, asking for recursion.
>
>   I guess the intent was: s/Resolver R/Resolver RNS/.  And some other
>   "R"s in the section will also have to be changed to "RNS".

DONE.
Thank you.

>
> - Section 12
>
>         *  ADDRESS, set to 0xC0 0x00 0x02 0xE0, copied from the request.
>
>   This is not a verbatim copy from the request, so I suggest:
>   "extended from the request".

DONE.

>
> Editorial nits
>
> - Section 3: A very minor point, but this draft seems to always use
>   the term "Section" to refer to a numbered portion of RFCs/drafts,
>   such as "Section 5" or "Section 6.1", so to be consistent "chapter"
>   would better be "Section".
>
>    Authoritative Nameserver:  A nameserver that has authority over one
>       or more DNS zones.  These are normally not contacted by clients
>       directly but by Recursive Resolvers.  Described in [RFC1035]
>       chapter 6.

DONE.

Well spotted.

>
> - Section 6.3: s/.././
>
>       to queries originating from the network covered by the ADDRESS and
>       SCOPE NETMASK..

DONE.
Thank you.

W

>
> --
> JINMEI, Tatuya
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Warren Kumari <[email-masked]>
Date: Mon, 23 Feb 2015 15:26:54 -0500

[ Incorporating more of the the comments. Newer version with some of
these incorporated posted on github:
https://github.com/wkumari/draft-vandergaast-edns-client-subnet. ]

Responses inline.

On Wed, Jan 7, 2015 at 9:27 AM, John Dickinson <[email-masked]> wrote:
> Hi,
>
> I have been reading this draft with a view to designing an implementation.
> In an attempt to understand section 6 I tried to pull it apart in to
> more sections. I have attempted to describe the behaviour of each possible
> type of name server (e.g., auth, recursive, caching, forwarding, stub, etc.)
> in separate sections even if that requires repeating text. My re-write can
> be found below (with questions inline and a summary of changes at the end).
> I hope the authors find it useful. If I have mis-understood anything please
> let me know.
>
> In addition:
>
> 1. I also strongly agree with the comments made by JINMEI, Tatuya. Especially
> those about changing NETMASK to PREFIX_LENGTH.

Excellent, DONE!

>
> 2. For clarity, I think edns-client-subnet should be changed to ECS and
> consistent use made of the terms query and response and not terms like
> question, request or reply.

DONE, where appropriate (e.g: not for "We request the IANA... " :-)).

>
> 3. I think that there might be places where Intermediate Nameserver and
> Recursive Nameserver have been used interchangeably/inconsistently.
> I am not sure I have it correct in the suggested text below.

I *think* we have it, but am checking with co-authors....

>
> 4. There is no mention of DNS CLASS. Somewhere it should state this is only
> for IN and that IN is assumed throughout. Especially when matching queries
> with responses.

DONE.
Good point, done.

>
> 5. Several more examples would be useful as well. (I did send one to the
> authors off list.)

[ Will incorporate later ]

> My attempt at text:
> 3.  Terminology
>       ECS: Edns Client Subnet.

DONE.

>       Stub Resolver: A simple DNS protocol implementation on the client
>       side as described in [RFC1034] section 5.3.1.  A client to a
>       Recursive Resolver or a Forwarder.
>
>       Recursive Resolver: A nameserver that is responsible for resolving
>       domain names for clients by following the domain's delegation
>       chain.  Recursive Resolvers frequently use caches to be able to
>       respond to client queries quickly.  Described in [RFC1035] chapter
>       7.

The above two seem like they are as in the document (just noting so I
don't miss things).
>
>       Forwarder: A nameserver that receives queries from a Stub Resolver
>       and forwards them on to a Recursive Resolver.  A client to a
>       Recursive Resolver.  It is possible to have a chain of Forwarders.
>       Forwarders frequently use caches to be able to respond to client
>       queries quickly.

DONE.

>
>       Intermediate Nameserver: Any nameserver (either a Recursive
>       Resolver or a Forwarder) in between the Stub Resolver and the
>       Authoritative Nameserver.

DONE.
>       or more DNS zones.  These are normally not contacted by Stub
>       Resolvers directly but by Recursive Resolvers.  Described in
>       [RFC1035] chapter 6.
>
>       Client: A Stub Resolver, Forwarder or Recursive Resolver.
>
>       Server: A Forwarder, Recursive Resolver or Authoritative
>       Nameserver.
>

DONE. I suspect we might need to do some more cleanup on these later,
especially after normalizing with PaulH's terminology draft.

>    ...The rest of section 3 as is...
>
> 5.  Option Format
>
>    ...as is...
>
>    Question: Clarify the meaning of significant in the last bullet
>    point: "Otherwise, the bits for ADDRESS will be significant through
>    the maximum of the SOURCE NETMASK or SCOPE NETMASK, and 0 filled to
>    the end of an octet" so that it cannot be misinterpreted as "set
>    additional significant bits to 1".
>

[ Checking with co-authors ]

[ Stopping here for now. Will resume later / after more coffee... ]

> 6.  Protocol Description
>
> 6.1.  Adding the ECS Option
>
>    The ECS option should generally be added by Recursive Resolvers when
>    querying other servers, as described in Section 11, but can be added
>    by a Stub Resolver.
>
> 6.1.1.  Stub Resolvers
>
>    A Stub Resolver MAY generate DNS queries with an ECS option with
>    SOURCE NETMASK set to 0 (i.e. 0.0.0.0/0) to indicate that the
>    Recursive Resolvers MUST NOT add address information of the client to
>    its queries.
>
>    The Stub Resolver may add non-zero ECS options to its queries.
>
>    Question: Would be useful to clarify what should be used in the SCOPE
>    NETMASK here - since there is no discussion on this in section 5?
>
> 6.1.2.  Recursive Resolver Receiving Queries
>
>    A Recursive Resolver supporting ECS MAY use client address
>    information in order to generate an optimized response.  The
>    Recursive Resolver will look in its cache (see section 6.3.2) or send
>    queries to Authoritative Servers to get a response.  The queries MAY
>    contain an ECS option.
>
>    Recursive Resolvers that have not implemented or enabled support for
>    the ECS option may safely ignore it within incoming queries.  Per
>    [RFC6891] section 6.1.2, such a server MUST NOT include an ECS option
>    within replies, to indicate lack of support for the option.
>
>    Queries with wrongly formatted options (e.g., wrong size) MUST be
>    rejected and a FORMERR response MUST be returned to the sender, as
>    described by [RFC6891], Transport Considerations.
>
>    If no ECS option is present in a query received by a Recursive
>    Resolver which supports ECS then it SHOULD add an ECS option to its
>    queries including the IP address of the client that caused the query
>    to be generated.
>
>    For privacy reasons, and because the whole IP address is rarely
>    required to determine an optimized response, the ADDRESS field in the
>    option SHOULD be truncated to a certain number of bits, chosen by the
>    administrators of the Recursive Nameserver, as described in
>    Section 10
>
>    If the client query contains an ECS option with SOURCE NETMASK set to
>    0 then the Recursive Resolver MAY either not include an ECS option or
>    MAY optionally include its own address information, which is what an
>    ECS aware Authoritative Nameserver will use anyway to generate the
>    response in lieu of no option.  This allows the answer to be handled
>    by the same caching mechanism as other queries, with an explicit
>    indicator of the applicable scope.  Subsequent Stub Resolver queries
>    for /0 can then be answered from this cached response.
>
>    If the client query contains an ECS option with a non-zero SOURCE
>    NETMASK then the Recursive Resolver is not required to use this
>    information.  The Recursive Resolver MAY act as if no ECS option was
>    specified (see above), or it may respect the ECS option in the query
>    and use this information to obtain an optimised response.  In the
>    second case,
>
>    o  the ECS information should be used when searching the cache for an
>       answer instead of the client address (see section 6.3.2.1)
>
>    o  if recursion is required and if the client query contains a SOURCE
>       NETMASK that is shorter than the maximum cacheable SCOPE NETMASK
>       that the Recursive Resolver allows, the Recursive Resolver SHOULD
>       issue the upstream query with its longer SCOPE NETMASK
>
> 6.2.  Authoritative Server
>
>    ...as is until paragraph 7...
>
>    Question: Would it be better to convert P7 and P8 to be definitions
>    of optimal and suboptimal?
>
>       SUBOPTIMAL RESPONSES: A SCOPE NETMASK value longer than the SOURCE
>       NETMASK indicates that the address and netmask provided in the
>       query was not specific enough to select a single, best response,
>       and it means that the response might be suboptimal.  The ADDRESS
>       in the response ECS option MUST be extended to SCOPE NETMASK
>       significant bits to indicate the network for which it is optimal.
>
>       Question: Refer to Question in section 5?
>
>       OPTIMAL RESPONSES: Conversely if the SCOPE NETMASK in the response
>       is shorter than or equal to the SOURCE NETMASK this indicates that
>       more bits than necessary were provided, and the answer is suitable
>       for a broader range of addresses.  The response is optimal for the
>       network described by the SCOPE NETMASK.
>
>    ...Rest of section 6.2 from paragraph 9 as is...
>
> 6.3.  Intermediate Nameservers handling responses and caching
>
>    When an Intermediate Nameserver receives a response containing an ECS
>    option, it will return a response to its client and SHOULD cache the
>    result.
>
>    If the FAMILY, SOURCE NETMASK, and SOURCE NETMASK bits of ADDRESS in
>    the response don't match the fields in the corresponding query, the
>    full response MUST be dropped, as described in Section 10.
>
>    If the Authoritative Nameserver extended the ADDRESS in the response
>    to SCOPE NETMASK significant bits to indicate the network for which
>    it is optimal, The Recursive Resolver SHOULD still provide the
>    result as the answer to the triggering query even if the client is in
>    a different address range.
>
>    Any response containing an ECS option considered invalid should be
>    treated as if no ECS option was specified at all.
>
>    Responses coming from servers not supporting ECS or otherwise not
>    containing an ECS option SHOULD be considered as containing a SCOPE
>    NETMASK of 0 (e.g., cache the result for 0.0.0.0/0 or ::/0) for all
>    the supported families.
>
> 6.3.1.  Caching responses
>
>    In the cache, any resource record in the answer section will be tied
>    to the network specified by the FAMILY, ADDRESS and SCOPE NETMASK
>    fields in the response, as detailed below, even if the address has
>    been extended.  This includes negative responses.  Note that the
>    additional and authority sections from a DNS response message are
>    specifically excluded here.  Any information cached from these
>    sections MUST NOT be tied to a network.
>
>    Although omitting network-specific caching will significantly
>    simplify an implementation, the resulting drop in cache hits is very
>    likely to defeat most latency benefits provided by ECS.  Therefore,
>    when implementing this option for latency purposes, implementing full
>    caching support as described in this section is STRONGLY RECOMMENDED.
>
>    Enabling support for ECS in an Intermediate Nameserver will
>    significantly increase the size of the cache, reduce the number of
>    results that can be served from cache, and increase the load on the
>    server.  Implementing the mitigation techniques described in
>    Section 10 is strongly recommended.
>
> 6.3.2.  Answering from the cache
>
> 6.3.2.1.  No ECS option in client query
>
>    If a query is received matching the name and type of an entry in the
>    cache, the Intermediate Nameserver will check whether the IP version
>    and source address of the client matches one of the networks in the
>    cache for that entry.
>
> 6.3.2.2.  ECS option in client query
>
>    If the original client query contained an ECS option the Intermediate
>    Nameserver MAY use either the client source address or the
>    information in the ECS option to perform the cache lookup.
>
>    Question: What is the recommended behaviour here?
>
> 6.3.2.3.  Selecting the best response
>
>    If the address of the client does not match any network in the cache,
>    then the Intermediate Nameserver MUST behave as if no match was found
>    and perform forwarding/resolution as usual.  This is necessary to
>    avoid suboptimal replies in the cache from being returned to the
>    wrong clients, and to avoid a single query coming from a client on a
>    different network from polluting the cache with a suboptimal response
>    for all the users of that Intermediate Nameserver.
>
> 6.3.2.4.  Sub-optimal responses
>
>    Suboptimal responses may be returned for several reasons e.g.,
>
>    o  Every time a Recursive Resolver queries an Authoritative
>       Nameserver by forwarding the ECS option that it
>       received from another client, a short SOURCE NETMASK in the
>       original request could cause a suboptimal reply to be returned by
>       the Authoritative Nameserver.
>
>    o  Question: This would be clearer if it specified what the SOURCE
>       NETMASK was shorter than.
>
>    o  When the request includes a longer SCOPE NETMASK, the reply
>       returned may still be cached as optimal for the ADDRESS and SCOPE
>       NETMASK of the reply.  This might still be suboptimal for the
>       original client.
>
>    o  Question: Again longer then what?
>
>    To avoid a suboptimal response from being served from a cache for
>    clients for which a better response would be available, the
>    Intermediate Nameserver MUST check the SCOPE NETMASK that was
>    returned in the response.
>
>    o  If the SCOPE NETMASK in the response is longer than the SOURCE
>       NETMASK, it means that the response might be suboptimal.  A
>       Intermediate Nameserver MUST return this entry from cache only to
>       queries that do not contain or allow a longer SOURCE NETMASK to be
>       forwarded, or to queries originating from the network covered by
>       the ADDRESS and SCOPE NETMASK.
>
>    o  If the SCOPE NETMASK in the response is shorter than or equal to
>       the SOURCE NETMASK, the response is optimal, and SHOULD be
>       returned from cache to any client within the network indicated by
>       ADDRESS and SCOPE NETMASK.
>
>    Question: I find the above very hard to parse.  I think it needs
>    rewriting and some examples.
>
>    As another response is received, the response will be tied to a
>    different network.  The Intermediate Nameserver SHOULD keep in cache
>    both reponses, and return the most appropriate one depending on the
>    address of the client.  Per standard DNS caching behavior, all
>    records SHOULD be retained until their TTL expires.  Subsequent
>    queries to refresh the data should always specify the longest SCOPE
>    NETMASK that the Intermediate Nameserver is willing to cache, even if
>    previous responses indicated that a shorter netmask was the optimal
>    response.
>
> 6.3.3.  Responses to clients
>
>    The response from the Intermediate Nameserver to the client MUST NOT
>    contain the ECS option if none was present in the client's original
>    query.
>
>    If the original client query contained a valid ECS option that was
>    respected and the information used during recursion, the Recursive
>    Resolver MUST include the ECS option from the Authoritative
>    Nameserver response in the response to the client.
>
>    Question: What about the case of a valid ECS option that is received
>    but not used, and the Recursive Resolver uses its own ECS option
>    instead?  How about adding this text "In the case of a valid ECS
>    option that is received but not used, and when the Recursive Resolver
>    uses its own ECS option instead, the Recursive Resolver SHOULD
>    include the ECS option it received from the Authoritative Nameserver
>    in the response to the client".
>
> 6.4.  Transitivity
>
>    Question: would this section be better earlier in the text?
>
>    .. as is until paragraph 3...
>
>    Options received with a SOURCE_NETMASK set to 0 (completely
>    anonymized) MUST be forwarded unchanged by all Intermediate
>    Nameservers supporting ECS, including Recursive Resolvers.  Such an
>    option MUST NOT be replaced with an option with more accurate address
>    information.
>
>    ...rest of section 6.4 as is...
>
>
>
> Summary of changes...
> New sections:
>
>       Added new section 6.1.1 Stub Resolvers
>
>       Added new section 6.1.2 Recursive Resolver Receiving Queries
>
>       Added new section 6.3.1 Caching responses
>
>       Added new section 6.3.2 Answering from the cache
>
>       Added new section 6.3.2.1 no ECS option in client query
>
>       Added new section 6.3.2.2 ECS option in client query
>
>       Added new section 6.3.2.3 Selecting the best response
>
>       Added new section 6.3.2.4 Sub-optimal responses
>
>       Added new section 6.3.3 Responses to clients
>
> Changes:
>
>       section 3 Modified and added additional terminology
>
>       section 5 Question about last bullet point
>
>       section 6.1 Section title changed and question added to text
>
>       section 6.1.P1 Modified
>
>       section 6.1.P2 Modified and moved to section 6.1.2
>
>       section 6.1.P3 Modified and split between sections 6.1.1 and 6.1.2
>
>       section 6.1.P4 Modified and split between sections 6.1.1 and 6.1.2
>
>       section 6.1.P5 Modified and moved to section 6.1.2
>
>       section 6.1.P6 Modified and moved to section 6.1.2
>
>       section 6.2 Section title changed
>
>       section 6.2.P7 Modified and questions
>
>       section 6.2.P8 Modified and questions
>
>       section 6.3 Section title changed
>
>       section 6.3.P1 Modified
>
>       section 6.3.P2 Modified
>
>       section 6.3.P3 Modified and moved to section 6.3.1
>
>       section 6.3.P4 Modified and moved to section 6.3.2.1
>
>       section 6.3.P5 Moved to section 6.3.2.3
>
>       section 6.3.P6 Modified and moved to section 6.3.2.3
>
>       section 6.3.P7 Now bullet points in section 6.3.2.4
>
>       section 6.3.P8 Now bullet points in section 6.3.2.4
>
>       section 6.3.P9 (and bullet points) Modified, questions and
>       moved to section 6.3.2.4
>
>       section 6.3.P10 Moved to 6.3.2.4
>
>       section 6.3.P11 Moved to 6.3.1
>
>       section 6.3.P14 Modified and moved to section 6.3.3
>
>       section 6.3.P15 Modified and moved to section 6.3.1
>
>       section 6.4.P3 Modified
>
> regards,
> John
>
> ---
> [email-masked]
>
> http://sinodun.com
>
> Sinodun Internet Technologies
> Magdalen Centre
> The Oxford Science Park
> Oxford
> OX4 4GA
> U.K.
>
>

---

From: 神明達哉 <[email-masked]>
Date: Wed, 25 Feb 2015 09:24:02 -0800

At Mon, 23 Feb 2015 15:23:23 -0500,

> IPv6) "). This seemed cleaner than the example form.

I'm fine with this, but I remember we discussed whether hiding the
actual type (e.g. by always using an IPv6/IPv4 prefix) might be better
in terms of privacy.

[...]
> view of how ECS should work (and what NXD "means"). Noting that this

I'm okay with this.

> chooses, but I've noted that implementations MUST document what they

Hmm, according to the previous discussion in January, I was told that
it was my misunderstanding:
http://www.ietf.org/mail-archive/web/dnsop/current/msg13095.html
and this is my response to that:
http://www.ietf.org/mail-archive/web/dnsop/current/msg13099.html
http://www.ietf.org/mail-archive/web/dnsop/current/msg13101.html

In short, if the original intent was that explained in msg13095.html
I see it doesn't have the suboptimal case I described, but then I
believe the documentation should be much more clearer about the
intent.  I also had a concern about on complexity and cost.

--
JINMEI, Tatuya

---

From: Warren Kumari <[email-masked]>
Date: Wed, 25 Feb 2015 18:11:30 -0500

> intent.  I also had a concern about on complexity and cost.

I think that this is a point that:
A: needs to be figured out (between the authors, and then the WG)
B: made *much* more clear in the document.

Just as an update, John has the pen now and we expect more updated by
end of the week.
W