Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Warren Kumari]

On Sun, Feb 15, 2015 at 4:02 PM, Mark Delany  wrote:
> On 15Feb15, Paul Hoffman allegedly wrote:
>> 
>>
>> On Feb 15, 2015, at 4:49 AM, Suzanne Woolf  wrote:
>> >
>> > The WG adopted this document some time ago (the announcement to the list 
>> > is dated Nov. 14, 2014).
>>
>> Yep, and the authors turned in an WG-named draft: 
>> https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-00
>> > It now needs reviewers to review and authors to revise.
>> > If you agreed to review it earlier, or even if you didn't but you're 
>> > interested, please do.
>>
>> FWIW, according to , 
>> four people (including me) agreed to review. It probably needs more.
>
> And I might add that at least some of us (even though not named in
> that list) did post review comments after the call and we've yet to
> hear from the authors on some of the issues raised. That was my point
> in prodding a day or so ago.

Apologies - the authors had all forgotten which one us was holding the
pen, and were all wondering why others were not responding /
incorporating comments.
I've just gone hunting under my desk and have found an old, leaky biro
that looks like it still has sufficient ink.

I'll now go back and try incorporate all the comments, etc. Expect to
see a flurry of updates.
This document lives in GitHub, I'm hoping to incorporate comments and
then commit often, so folk can follow along at home...

W



>
>
> Mark.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Mark Delany]

On 15Feb15, Paul Hoffman allegedly wrote:
> 
> 
> On Feb 15, 2015, at 4:49 AM, Suzanne Woolf  wrote:
> > 
> > The WG adopted this document some time ago (the announcement to the list is 
> > dated Nov. 14, 2014). 
> 
> Yep, and the authors turned in an WG-named draft: 
> https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-00
> > It now needs reviewers to review and authors to revise. 
> > If you agreed to review it earlier, or even if you didn't but you're 
> > interested, please do.
> 
> FWIW, according to , 
> four people (including me) agreed to review. It probably needs more.

And I might add that at least some of us (even though not named in
that list) did post review comments after the call and we've yet to
hear from the authors on some of the issues raised. That was my point
in prodding a day or so ago.


Mark.


pgpI65R5ccboM.pgp
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Paul Hoffman]

On Feb 15, 2015, at 4:49 AM, Suzanne Woolf  wrote:
> 
> The WG adopted this document some time ago (the announcement to the list is 
> dated Nov. 14, 2014). 

Yep, and the authors turned in an WG-named draft: 
https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-00
> It now needs reviewers to review and authors to revise. 
> If you agreed to review it earlier, or even if you didn't but you're 
> interested, please do.

FWIW, according to , four 
people (including me) agreed to review. It probably needs more.

--Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Suzanne Woolf]

The WG adopted this document some time ago (the announcement to the list is 
dated Nov. 14, 2014). 

It now needs reviewers to review and authors to revise. 

If you agreed to review it earlier, or even if you didn't but you're 
interested, please do.

Authors, any feedback on the reviews/comments so far? 


thanks,
Suzanne



On Feb 12, 2015, at 8:01 PM, "Livingood, Jason" 
 wrote:

> On 2/12/15, 2:51 PM, "Mark Delany"  wrote:
> 
>> Tap tap tap. Is this thing turned on?
>> 
>> I think 3-4 people made some well-considered feedback on this draft, but
>> there has been zero discussion or author feedback for some six weeks now.
>> 
>> Does that mean there is insufficient interest in progressing this draft?
> 
> I don¹t think so. I, for one, support adoption and hope the WG does so and
> moves on. This one is important and can actually positively improve the
> experience of end users of the Internet, which is a really good thing and
> something DNSOP should do more often. :-)
> 
>> I ask because in my dayjob we've been recently approached by some
>> large eyeball providers who are now willing to invest in upgrading
>> their resolver infrastructure to support client-subnet now that they see
>> the benefits.
> 
> Awesome! :-)
> 
> Jason 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Livingood, Jason]

On 2/13/15, 9:05 AM, "Livingood, Jason" 
mailto:jason_living...@cable.comcast.com>> 
wrote:
we've got running code in bind. and no doubt other product.

Should be also in Nominet’s resolver.

BTW, I meant NomiNUM not NomiNET. Darned Nomi* names. ;-)

JL
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Marcus Grando]

Thinking more about this I figure out some things.

First, the resolver query needs to include ECS and can't be a regular
query, that's need to verify end to end ECS support, but I think it's not a
big problem. I think we need a official way to detect if authoritative has
support or not and it need to be automatically, like an SOA query, an TXT
query or another idea, but need to be official. It's important this query
use TTL to revalidate ECS support.

About the manually whitelist, I really think it will be a huge problem and
I'm not a big fan, since the main problem is in the resolver side and not
the authoritative side, but the authoritative side know if support or not
for all domain hosted. It's impossible to know all resolvers around the
world and contact/appy to all those, to whitelist your domain.

Because of that, the idea of an official way to detect if authoritative has
or not support for ECS from a resolver perspective is a good idea. But the
control of this need to be on the authoritative side and the resolver doing
the ECS query to validate end to end and be able to use.

Another point about the SCOPE NETMASK. What you guys think about using
scope netmask to protect resolver resources, an example is: if scope
netmask was 23, authoritative only can use <=23 to scope netmask response.
I know that can be a problem with IPv4 ends, but can save resources on
resolver side.

Best regards
--
Marcus Grando
marcus (at) sbh.eng.br
@marcusgrando

On Thu, Feb 12, 2015 at 11:09 PM, Livingood, Jason <
jason_living...@cable.comcast.com> wrote:

>   Fair point. IMO whitelisting is a common tactic used early on in
> deployment of new stuff to help manage deployment risk. It was also used in
> early IPv6 days where query access to  RRs was whitelisted (see
> http://tools.ietf.org/html/rfc6589). I suspect it would be similar here;
> that the need for and use of whitelisting fades as deployment levels
> increase.
>
>  - Jason
>
>   On 2/13/15, 12:44 AM, "Marcus Grando"  wrote:
>
>   The question about whitelist is the problem. I think it need to be
> addressed on this doc.
>
> There's some approaches, like Google does, doing low rate ECS query:
> https://groups.google.com/forum/#!topic/public-dns-announce/67oxFjSLeUM
>
> Or something not so traditional like TXT record on domain record or
> hostname based like "ns1.ECS.domain.tld". It's not an clean way, but can
> optimize latency and can address problems like keep approved domains in
> memory or save on disk.
>
> It's almost impossible to authoritative guys, guess each one resolver that
> support ECS. It's need to be automatically.
>
> The other side of this problem is about resources of DNS resolver. If more
> domains enable ECS, it can increase exponentially memory usage keeping
> approved list and cache itself. With this, the minimum netmask will be
> extremly important.
>
> I don't know if it's a good idea fix the limit of how many different
> answers one authoritative can emit. This can be a problem. It's clear for
> everyone that it's much more easier to implement this on authoritative side
> than resolver side, so it need to be clear and easy for both sides.
>
> Best regards
>
>   On 12Feb15, George Michaelson allegedly wrote:
>> >
>> > we've got two agencies who do DNS, and probably have > 20% worldwide
>> > eyeball share in DNS (I don't know, thats a guesstimate) now doing
>> > edns0_client_subnet albiet with whitelist, so its a permit-list, but its
>> > functionally 'there'
>>
>> Whitelists are my biggest bugbear actually. All my other comments are
>> nice-to-haves. I hear that Google now adaptively whitelist which is a
>> nice strategy but I'd really like to see the whitelist approach
>> deprecated as much as possible. (And yes, I understand MarkA's stats
>> that show some small percentage of auth queries will break).
>>
>> I've been in other conversations lately where it was all about how do
>> we get "pick some larger resolver" to whitelist us? We all know that
>> doesn't scale. So interest appears to be growing.
>>
>> > Its probably already more widely deployed than IPv6...
>>
>> On the auth side I think you're right. It's the client side that's the
>> missing link. But this is a classic alignment-of-interest problem. The
>> relatively small number of auths who care implement, but there is
>> little incentive on the resolver side.
>>
>>
>> Mark.
>>
>
> --
>  Marcus Grando
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Peter DeVries]

My dayjob supports this as well and has been running resolvers with similar
functionality implemented for a while now.   We are looking to switch to
edns-clent-subnet once it is standardized and have been approached by
parties willing to invest in development.

Peter

On Thu, Feb 12, 2015 at 1:51 AM, Mark Delany  wrote:

> On 24Dec14, Mark Delany allegedly wrote:
> > > The draft is available here:
> http://datatracker.ietf.org/doc/draft-vandergaast-dnsop-edns-client-subnet/
> >
> > a) 6.2 - Intent of SCOPE NETMASK
> >
> >   "In both cases, the value of the SCOPE NETMASK in the reply has strong
> >   implications with regard to how the reply will be cached"
> >
> > I wonder whether SCOPE NETMASK should have a bigger impact beyond how
> > the reply is cached?
>
> Tap tap tap. Is this thing turned on?
>
> I think 3-4 people made some well-considered feedback on this draft,
> but there has been zero discussion or author feedback for some six
> weeks now.
>
> Does that mean there is insufficient interest in progressing this draft?
>
> I ask because in my dayjob we've been recently approached by some
> large eyeball providers who are now willing to invest in upgrading
> their resolver infrastructure to support client-subnet now that they
> see the benefits.
>
> It'd be a pity if this died on the vine just as others are starting to
> come around to the idea.
>
>
> Mark.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[jewforice .]

I support adoption of this document because we're using this spec on our
authority name servers and planning to use it on our recursive resolvers.

On Tue, Oct 28, 2014 at 11:50 PM, Suzanne Woolf 
wrote:

> Dear DNSOP WG,
>
> This draft documents the specification, use, and cautions regarding the
> "client-subnet" EDNS option. Please consider adoption of this draft as a WG
> work item.
>
> As some of you will remember, this is a successor to a draft that was
> considered in DNSEXT some time ago and eventually expired without formal
> action. Since then, the option codepoint has been granted under the
> appropriate registry policy (expert review) and the option is in
> significant operational use.
>
> The topic has come up more than once on the WG mailing list, with some
> vigorous discussion, so a couple of the original authors and a couple of
> new people have revived the draft in the interests of documenting the
> option, including specific behavior and cautions in its use.
>
> The draft is available here:
> http://datatracker.ietf.org/doc/draft-vandergaast-dnsop-edns-client-subnet/
>
> Please review to see if you think this document is suitable for adoption
> by DNSOP and comment to the list.
>
> Please state your view, your reasons, and (if you're in favor of adoption)
> whether you are willing to contribute text, review, etc.
>
> This call for adoption ends Tuesday 11-Nov.-2014, end of the day wherever
> you happen to be. This is the same day as our WG meeting at IETF 91.
>
>
> Thanks,
> Suzanne Woolf
> DNSOP co-chair
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Livingood, Jason]

Fair point. IMO whitelisting is a common tactic used early on in deployment of 
new stuff to help manage deployment risk. It was also used in early IPv6 days 
where query access to  RRs was whitelisted (see 
http://tools.ietf.org/html/rfc6589). I suspect it would be similar here; that 
the need for and use of whitelisting fades as deployment levels increase.

- Jason

On 2/13/15, 12:44 AM, "Marcus Grando" 
mailto:mar...@sbh.eng.br>> wrote:

The question about whitelist is the problem. I think it need to be addressed on 
this doc.

There's some approaches, like Google does, doing low rate ECS query:
https://groups.google.com/forum/#!topic/public-dns-announce/67oxFjSLeUM

Or something not so traditional like TXT record on domain record or hostname 
based like "ns1.ECS.domain.tld". It's not an clean way, but can optimize 
latency and can address problems like keep approved domains in memory or save 
on disk.

It's almost impossible to authoritative guys, guess each one resolver that 
support ECS. It's need to be automatically.

The other side of this problem is about resources of DNS resolver. If more 
domains enable ECS, it can increase exponentially memory usage keeping approved 
list and cache itself. With this, the minimum netmask will be extremly 
important.

I don't know if it's a good idea fix the limit of how many different answers 
one authoritative can emit. This can be a problem. It's clear for everyone that 
it's much more easier to implement this on authoritative side than resolver 
side, so it need to be clear and easy for both sides.

Best regards

On 12Feb15, George Michaelson allegedly wrote:
>
> we've got two agencies who do DNS, and probably have > 20% worldwide
> eyeball share in DNS (I don't know, thats a guesstimate) now doing
> edns0_client_subnet albiet with whitelist, so its a permit-list, but its
> functionally 'there'

Whitelists are my biggest bugbear actually. All my other comments are
nice-to-haves. I hear that Google now adaptively whitelist which is a
nice strategy but I'd really like to see the whitelist approach
deprecated as much as possible. (And yes, I understand MarkA's stats
that show some small percentage of auth queries will break).

I've been in other conversations lately where it was all about how do
we get "pick some larger resolver" to whitelist us? We all know that
doesn't scale. So interest appears to be growing.

> Its probably already more widely deployed than IPv6...

On the auth side I think you're right. It's the client side that's the
missing link. But this is a classic alignment-of-interest problem. The
relatively small number of auths who care implement, but there is
little incentive on the resolver side.


Mark.

--
Marcus Grando
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Livingood, Jason]

On 2/12/15, 2:54 PM, "George Michaelson" 
mailto:g...@algebras.org>> wrote:

we've got two agencies who do DNS, and probably have > 20% worldwide eyeball 
share in DNS (I don't know, thats a guesstimate) now doing edns0_client_subnet 
albiet with whitelist, so its a permit-list, but its functionally 'there'

we've got running code in bind. and no doubt other product.

Should be also in Nominet’s resolver. I suspect many others will soon support 
it as well. Smells like an emerging standard to me. ;-)

wouldn't it be passing strange for the premier body which determines DNS 
standards to decide to drop this one when we have massive widescale adoption, a 
clear use-case, and running code?

Indeed!

Its probably already more widely deployed than IPv6...

Ha! I think that wins the award for best quote of the day. ;-)

- Jason
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Livingood, Jason]

On 2/12/15, 2:51 PM, "Mark Delany"  wrote:

>Tap tap tap. Is this thing turned on?
>
>I think 3-4 people made some well-considered feedback on this draft, but
>there has been zero discussion or author feedback for some six weeks now.
>
>Does that mean there is insufficient interest in progressing this draft?

I don¹t think so. I, for one, support adoption and hope the WG does so and
moves on. This one is important and can actually positively improve the
experience of end users of the Internet, which is a really good thing and
something DNSOP should do more often. :-)

>I ask because in my dayjob we've been recently approached by some
>large eyeball providers who are now willing to invest in upgrading
>their resolver infrastructure to support client-subnet now that they see
>the benefits.

Awesome! :-)

Jason 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Marcus Grando]

The question about whitelist is the problem. I think it need to be
addressed on this doc.

There's some approaches, like Google does, doing low rate ECS query:
https://groups.google.com/forum/#!topic/public-dns-announce/67oxFjSLeUM

Or something not so traditional like TXT record on domain record or
hostname based like "ns1.ECS.domain.tld". It's not an clean way, but can
optimize latency and can address problems like keep approved domains in
memory or save on disk.

It's almost impossible to authoritative guys, guess each one resolver that
support ECS. It's need to be automatically.

The other side of this problem is about resources of DNS resolver. If more
domains enable ECS, it can increase exponentially memory usage keeping
approved list and cache itself. With this, the minimum netmask will be
extremly important.

I don't know if it's a good idea fix the limit of how many different
answers one authoritative can emit. This can be a problem. It's clear for
everyone that it's much more easier to implement this on authoritative side
than resolver side, so it need to be clear and easy for both sides.

Best regards

On 12Feb15, George Michaelson allegedly wrote:
> >
> > we've got two agencies who do DNS, and probably have > 20% worldwide
> > eyeball share in DNS (I don't know, thats a guesstimate) now doing
> > edns0_client_subnet albiet with whitelist, so its a permit-list, but its
> > functionally 'there'
>
> Whitelists are my biggest bugbear actually. All my other comments are
> nice-to-haves. I hear that Google now adaptively whitelist which is a
> nice strategy but I'd really like to see the whitelist approach
> deprecated as much as possible. (And yes, I understand MarkA's stats
> that show some small percentage of auth queries will break).
>
> I've been in other conversations lately where it was all about how do
> we get "pick some larger resolver" to whitelist us? We all know that
> doesn't scale. So interest appears to be growing.
>
> > Its probably already more widely deployed than IPv6...
>
> On the auth side I think you're right. It's the client side that's the
> missing link. But this is a classic alignment-of-interest problem. The
> relatively small number of auths who care implement, but there is
> little incentive on the resolver side.
>
>
> Mark.
>

--
Marcus Grando
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Mark Delany]

On 12Feb15, George Michaelson allegedly wrote:
> 
> we've got two agencies who do DNS, and probably have > 20% worldwide
> eyeball share in DNS (I don't know, thats a guesstimate) now doing
> edns0_client_subnet albiet with whitelist, so its a permit-list, but its
> functionally 'there'

Whitelists are my biggest bugbear actually. All my other comments are
nice-to-haves. I hear that Google now adaptively whitelist which is a
nice strategy but I'd really like to see the whitelist approach
deprecated as much as possible. (And yes, I understand MarkA's stats
that show some small percentage of auth queries will break).

I've been in other conversations lately where it was all about how do
we get "pick some larger resolver" to whitelist us? We all know that
doesn't scale. So interest appears to be growing.

> Its probably already more widely deployed than IPv6...

On the auth side I think you're right. It's the client side that's the
missing link. But this is a classic alignment-of-interest problem. The
relatively small number of auths who care implement, but there is
little incentive on the resolver side.


Mark.


pgpJYRF8Ef4iY.pgp
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[George Michaelson]

we've got two agencies who do DNS, and probably have > 20% worldwide
eyeball share in DNS (I don't know, thats a guesstimate) now doing
edns0_client_subnet albiet with whitelist, so its a permit-list, but its
functionally 'there'

we've got running code in bind. and no doubt other product.

wouldn't it be passing strange for the premier body which determines DNS
standards to decide to drop this one when we have massive widescale
adoption, a clear use-case, and running code?

Its probably already more widely deployed than IPv6...

-G

On Thu, Feb 12, 2015 at 4:51 PM, Mark Delany  wrote:

> On 24Dec14, Mark Delany allegedly wrote:
> > > The draft is available here:
> http://datatracker.ietf.org/doc/draft-vandergaast-dnsop-edns-client-subnet/
> >
> > a) 6.2 - Intent of SCOPE NETMASK
> >
> >   "In both cases, the value of the SCOPE NETMASK in the reply has strong
> >   implications with regard to how the reply will be cached"
> >
> > I wonder whether SCOPE NETMASK should have a bigger impact beyond how
> > the reply is cached?
>
> Tap tap tap. Is this thing turned on?
>
> I think 3-4 people made some well-considered feedback on this draft,
> but there has been zero discussion or author feedback for some six
> weeks now.
>
> Does that mean there is insufficient interest in progressing this draft?
>
> I ask because in my dayjob we've been recently approached by some
> large eyeball providers who are now willing to invest in upgrading
> their resolver infrastructure to support client-subnet now that they
> see the benefits.
>
> It'd be a pity if this died on the vine just as others are starting to
> come around to the idea.
>
>
> Mark.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Mark Delany]

On 24Dec14, Mark Delany allegedly wrote:
> > The draft is available here: 
> > http://datatracker.ietf.org/doc/draft-vandergaast-dnsop-edns-client-subnet/
> 
> a) 6.2 - Intent of SCOPE NETMASK
> 
>   "In both cases, the value of the SCOPE NETMASK in the reply has strong
>   implications with regard to how the reply will be cached"
> 
> I wonder whether SCOPE NETMASK should have a bigger impact beyond how
> the reply is cached?

Tap tap tap. Is this thing turned on?

I think 3-4 people made some well-considered feedback on this draft,
but there has been zero discussion or author feedback for some six
weeks now.

Does that mean there is insufficient interest in progressing this draft?

I ask because in my dayjob we've been recently approached by some
large eyeball providers who are now willing to invest in upgrading
their resolver infrastructure to support client-subnet now that they
see the benefits.

It'd be a pity if this died on the vine just as others are starting to
come around to the idea.


Mark.


pgpGZBF5mZcRH.pgp
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Mark Delany]

> The draft is available here: 
> http://datatracker.ietf.org/doc/draft-vandergaast-dnsop-edns-client-subnet/

a) 6.2 - Intent of SCOPE NETMASK

  "In both cases, the value of the SCOPE NETMASK in the reply has strong
  implications with regard to how the reply will be cached"

I wonder whether SCOPE NETMASK should have a bigger impact beyond how
the reply is cached?

Specifically, if an auth returns a SCOPE NETMASK that is more
fine-grained than the SOURCE NETMASK, should that granularity
influence the SOURCE NETMASK of future queries from that cache to that
auth/domain?

If you think about it, SCOPE NETMASK is the auth communicating its
knowledge of the client network back to the cache. And, in the cases
where the client-subnet option is most useful (CDN-like applications),
it is commonly the case that auths do indeed have better knowledge
than the cache/resolver.

By way of example if a cache issues a query with a default SOURCE
NETMASK of /24 to a well-managed CDN auth, it is entirely possible
that the auth has greater knowledge of the SOURCE network and may
return a SCOPE NETMASK of, say, /25 because it knows that that /24 is
distributed topologically from the auth's perspective.

As it stands today, this cache will continue to issue queries to that
auth/domain with a /24 SOURCE NETMASK even though the replies coming
back indicate that the client network is divided on /25 basis as far
as the auth is concerned. In effect the auth has no way to correct the
erroneous assumptions of the cache.

I'm primarily concerned that client implementations of client-subnet
will hard-code a minimum or default SOURCE NETMASK which may not be
granular enough in the future. As we approach v4 exhaustion I can
easily imagine a corp network dividing a /24 up on a regional basis
and who knows what will happen to public routing as we really do get
close to v4 exhaustion?

If caches allow returned SCOPE NETMASKs to influence future SOURCE
NETMASKs (modulo privacy policy of course) then as networks get more
granular, auths - which have the greatest incentive to adapt - can
dynamically influence caches as the Internet changes.

(Admittedly this may not help if caches adopt a default privacy mask
that matches their default SOURCE NETMASK - which I expect many will).


b) 11.2 - Whitelist

   "Only a few Recursive Resolvers will need to use edns-client-subnet"

Does "few" refer to implementations or deployments? If the later, then
I wonder whether that estimate is accurate?

I would think that any enterprise or ISP with multiple ingress points
is a candidate user. Maybe that's still a "few" in the grand scheme of
things but the number of relevant operators goes well beyond the tiny
population of public caches and giant eyeball networks.

Has "few" been quantified? Are we talking about 1,000 deployments,
10,000? What is the threshold at which "few" no longer applies?

I'm also thinking of medium sized corporates which could easily run
regional networks with internal caches and auths. Maybe this isn't a
concern here because it's not the "Internet", but generally they will
want to use the same technology.

My ulterior motive is to revisit the whole notion of whitelisting. Why
have it at all? I worry that the desire to make a manageable
Internet-wide whitelist (if that's not an oxymoron) is driving some of
the assumptions and text in the spec.


Apologies if this is a rehash of earlier discussions, ignore anything
that has been previously settled.


Mark.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Warren Kumari]

On Fri, Nov 14, 2014 at 2:04 PM, Suzanne Woolf  wrote:
> Colleagues,
>
> This call for adoption closed earlier this week, during IETF91.
>
> We see significant support in the WG for working on 
> draft-vandergaast-dnsop-edns-client-subnet.  We're adopting it as a WG item.
>
> Thanks to the authors for reviving it, please resubmit with any changes you 
> have pending as "draft-ietf-dnsop-edns-client-subnet-00.txt"

Done.

Thanks to everyone who showed support.

W

>
> Paul Hoffman as WG secretary will be reminding the folks who offered to 
> review. Please post reviews and comments on the list to promote discussion.
>
>
> best,
> Suzanne & Tim
>
>
>
>
> On Oct 28, 2014, at 11:50 AM, Suzanne Woolf  wrote:
>
>> Dear DNSOP WG,
>>
>> This draft documents the specification, use, and cautions regarding the 
>> "client-subnet" EDNS option. Please consider adoption of this draft as a WG 
>> work item.
>>
>> As some of you will remember, this is a successor to a draft that was 
>> considered in DNSEXT some time ago and eventually expired without formal 
>> action. Since then, the option codepoint has been granted under the 
>> appropriate registry policy (expert review) and the option is in significant 
>> operational use.
>>
>> The topic has come up more than once on the WG mailing list, with some 
>> vigorous discussion, so a couple of the original authors and a couple of new 
>> people have revived the draft in the interests of documenting the option, 
>> including specific behavior and cautions in its use.
>>
>> The draft is available here: 
>> http://datatracker.ietf.org/doc/draft-vandergaast-dnsop-edns-client-subnet/
>>
>> Please review to see if you think this document is suitable for adoption by 
>> DNSOP and comment to the list.
>>
>> Please state your view, your reasons, and (if you're in favor of adoption) 
>> whether you are willing to contribute text, review, etc.
>>
>> This call for adoption ends Tuesday 11-Nov.-2014, end of the day wherever 
>> you happen to be. This is the same day as our WG meeting at IETF 91.
>>
>>
>> Thanks,
>> Suzanne Woolf
>> DNSOP co-chair
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Suzanne Woolf]

Colleagues,

This call for adoption closed earlier this week, during IETF91.

We see significant support in the WG for working on 
draft-vandergaast-dnsop-edns-client-subnet.  We're adopting it as a WG item. 

Thanks to the authors for reviving it, please resubmit with any changes you 
have pending as "draft-ietf-dnsop-edns-client-subnet-00.txt"

Paul Hoffman as WG secretary will be reminding the folks who offered to review. 
Please post reviews and comments on the list to promote discussion.


best,
Suzanne & Tim




On Oct 28, 2014, at 11:50 AM, Suzanne Woolf  wrote:

> Dear DNSOP WG,
> 
> This draft documents the specification, use, and cautions regarding the 
> "client-subnet" EDNS option. Please consider adoption of this draft as a WG 
> work item.
> 
> As some of you will remember, this is a successor to a draft that was 
> considered in DNSEXT some time ago and eventually expired without formal 
> action. Since then, the option codepoint has been granted under the 
> appropriate registry policy (expert review) and the option is in significant 
> operational use. 
> 
> The topic has come up more than once on the WG mailing list, with some 
> vigorous discussion, so a couple of the original authors and a couple of new 
> people have revived the draft in the interests of documenting the option, 
> including specific behavior and cautions in its use.
> 
> The draft is available here: 
> http://datatracker.ietf.org/doc/draft-vandergaast-dnsop-edns-client-subnet/
> 
> Please review to see if you think this document is suitable for adoption by 
> DNSOP and comment to the list. 
> 
> Please state your view, your reasons, and (if you're in favor of adoption) 
> whether you are willing to contribute text, review, etc.
> 
> This call for adoption ends Tuesday 11-Nov.-2014, end of the day wherever you 
> happen to be. This is the same day as our WG meeting at IETF 91.
> 
> 
> Thanks,
> Suzanne Woolf
> DNSOP co-chair

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Allison Mankin]

I support adoption because operators are using this spec.  I plan to review
and also to encourage a few others who have reviews to contribute.

On 28 October 2014 08:50, Suzanne Woolf  wrote:

> Dear DNSOP WG,
>
> This draft documents the specification, use, and cautions regarding the
> "client-subnet" EDNS option. Please consider adoption of this draft as a WG
> work item.
>
> As some of you will remember, this is a successor to a draft that was
> considered in DNSEXT some time ago and eventually expired without formal
> action. Since then, the option codepoint has been granted under the
> appropriate registry policy (expert review) and the option is in
> significant operational use.
>
> The topic has come up more than once on the WG mailing list, with some
> vigorous discussion, so a couple of the original authors and a couple of
> new people have revived the draft in the interests of documenting the
> option, including specific behavior and cautions in its use.
>
> The draft is available here:
> http://datatracker.ietf.org/doc/draft-vandergaast-dnsop-edns-client-subnet/
>
> Please review to see if you think this document is suitable for adoption
> by DNSOP and comment to the list.
>
> Please state your view, your reasons, and (if you're in favor of adoption)
> whether you are willing to contribute text, review, etc.
>
> This call for adoption ends Tuesday 11-Nov.-2014, end of the day wherever
> you happen to be. This is the same day as our WG meeting at IETF 91.
>
>
> Thanks,
> Suzanne Woolf
> DNSOP co-chair
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Paul Wouters]

On Tue, 28 Oct 2014, Suzanne Woolf wrote:


This draft documents the specification, use, and cautions regarding the 
"client-subnet" EDNS option. Please consider adoption of this draft as a WG 
work item.


I have a recollection we already did this call? Because I said I
reluctantly agreed to adopt the document before. Anyway, yes
I support adopting the work.

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[David C Lawrence]

Warren Kumari:
> We actually have some updates that unfortunately didn't *quite* make
> it in before the cutoff[0].
> 
> [0]: Yes, making it in before the cut-off or not making it in before
> the cut-off is a binary, but, well

Please feel free to hurl suitably non-lethal objects at me.  It was
all my fault.

> The updated version / version in the edit buffer is at:
> https://github.com/wkumari/draft-vandergaast-edns-client-subnet
> The changes are minor, so review the
> http://datatracker.ietf.org/doc/draft-vandergaast-dnsop-edns-client-subnet/
> version, but if you mention typos / etc we might say "Thanks! Already
> fixed in edit buffer :-)"

I just synced some more changes, primarily of the typo / grammatical
consistency variety, and am done for now.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Paul Ebersman]

suzworldwide> The draft is available here: 
http://datatracker.ietf.org/doc/draft-vandergaast-dnsop-edns-client-subnet/

suzworldwide> Please review to see if you think this document is
suzworldwide> suitable for adoption by DNSOP and comment to the list.

I support this draft as a working group item and am willing to review
the draft.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Paul Hoffman]

I support the adoption of this document in the WG even if it gets significantly 
changed during the WG discussion. I will review it as it progresses.

--Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Warren Kumari]

On Tue, Oct 28, 2014 at 11:50 AM, Suzanne Woolf  wrote:
> Dear DNSOP WG,
>
> This draft documents the specification, use, and cautions regarding the 
> "client-subnet" EDNS option. Please consider adoption of this draft as a WG 
> work item.
>
> As some of you will remember, this is a successor to a draft that was 
> considered in DNSEXT some time ago and eventually expired without formal 
> action. Since then, the option codepoint has been granted under the 
> appropriate registry policy (expert review) and the option is in significant 
> operational use.
>
> The topic has come up more than once on the WG mailing list, with some 
> vigorous discussion, so a couple of the original authors and a couple of new 
> people have revived the draft in the interests of documenting the option, 
> including specific behavior and cautions in its use.
>
> The draft is available here: 
> http://datatracker.ietf.org/doc/draft-vandergaast-dnsop-edns-client-subnet/

We actually have some updates that unfortunately didn't *quite* make
it in before the cutoff[0].

The updated version / version in the edit buffer is at:
https://github.com/wkumari/draft-vandergaast-edns-client-subnet
The changes are minor, so review the
http://datatracker.ietf.org/doc/draft-vandergaast-dnsop-edns-client-subnet/
version, but if you mention typos / etc we might say "Thanks! Already
fixed in edit buffer :-)"

W

[0]: Yes, making it in before the cut-off or not making it in before
the cut-off is a binary, but, well


>
> Please review to see if you think this document is suitable for adoption by 
> DNSOP and comment to the list.
>
> Please state your view, your reasons, and (if you're in favor of adoption) 
> whether you are willing to contribute text, review, etc.
>
> This call for adoption ends Tuesday 11-Nov.-2014, end of the day wherever you 
> happen to be. This is the same day as our WG meeting at IETF 91.
>
>
> Thanks,
> Suzanne Woolf
> DNSOP co-chair
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Suzanne Woolf]

Dear DNSOP WG,

This draft documents the specification, use, and cautions regarding the 
"client-subnet" EDNS option. Please consider adoption of this draft as a WG 
work item.

As some of you will remember, this is a successor to a draft that was 
considered in DNSEXT some time ago and eventually expired without formal 
action. Since then, the option codepoint has been granted under the appropriate 
registry policy (expert review) and the option is in significant operational 
use. 

The topic has come up more than once on the WG mailing list, with some vigorous 
discussion, so a couple of the original authors and a couple of new people have 
revived the draft in the interests of documenting the option, including 
specific behavior and cautions in its use.

The draft is available here: 
http://datatracker.ietf.org/doc/draft-vandergaast-dnsop-edns-client-subnet/

Please review to see if you think this document is suitable for adoption by 
DNSOP and comment to the list. 

Please state your view, your reasons, and (if you're in favor of adoption) 
whether you are willing to contribute text, review, etc.

This call for adoption ends Tuesday 11-Nov.-2014, end of the day wherever you 
happen to be. This is the same day as our WG meeting at IETF 91.


Thanks,
Suzanne Woolf
DNSOP co-chair
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop