Subject: Re: [DNSOP] New Version Notification for draft-ietf-dnsop-edns-client-subnet-01.txt

From: Warren Kumari <[email-masked]>
Date: Tue, 26 May 2015 17:07:37 -0400

This version incorporates a *large* number of comments received, and
also reverts the changes made to SCOPE / SOURCE NETMASK, making this
document describe how this has actually been implemented in practice.

It also clarifies that you cannot hand NXDOMAIN to some clients and
not others, some new text describing the birthday attack mitigations,
whitelisting some clients.

W

-00 to -01 (IETF)
o <David> Made the document describe how things are actually
implmented now. This makes the document be more of a "this is how
we are doing things, this provides information on that". There
may be a future document that describes additional funcationality.
o NETMASK was not a good desription, changed to PREFIX-LENGTH
(Jinmei, others). Stole most of the definition for prefix length
from RFC4291.
o Fixed the "SOURCE PREFIX-LENGTH set to 0" definition to include
IPv6 (Tatuya Jinmei)
o Comment that ECS cannot be used to hand NXDOMAIN to some clients
and not others, primarily because of interoperability issues.
(Tatuya Jinmei)
o Added text explaining that implmentations need to document thier
behavior with overlapping networks.
o Soften "optimized reply" language. (Andrew Sullivan).
o Fixed some of legacy IPv4 cruft (things like 0.0.0.0/0)
o Some more grammar / working cleanups.
o Replaced a whole heap of occurances of "edns-client-subnet" with
"ECS" for readability. (John Dickinson)
o More clearly describe the process from the point of view of each
type of nameserver. (John Dickinson)
o Birthday attack still possible if attacker floods with ECS-less
responses. (Yuri Schaeffer)
o Added some open issues directly to the text.

On Tue, May 26, 2015 at 4:49 PM,  <[email-masked]> wrote:
>
> A new version of I-D, draft-ietf-dnsop-edns-client-subnet-01.txt
> has been successfully submitted by Warren Kumari and posted to the
> IETF repository.
>
> Name:           draft-ietf-dnsop-edns-client-subnet
> Revision:       01
> Title:          Client Subnet in DNS Querys
> Document date:  2015-05-26
> Group:          dnsop
> Pages:          26
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-dnsop-edns-client-subnet-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-client-subnet/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-edns-client-subnet-01
>
> Abstract:
>    This draft defines an EDNS0 extension to carry information about the
>    network that originated a DNS query, and the network for which the
>    subsequent response can be cached.
>
> IESG Note
>
>    [RFC Editor: Please remove this note prior to publication ]
>
>    This informational document describes an existing, implemented and
>    deployed system.  A subset of the operators using this is at
>    http://www.afasterinternet.com/participants.htm . The authors believe
>    that it is better to document this system (even if not everyone
>    agrees with the concept) than leave it undocumented and proprietary.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>

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