Re: [DNSOP] draft-tale-dnsop-edns-clientid

2017-03-31 Thread Peter van Dijk
On 31 Mar 2017, at 16:09, Peter van Dijk wrote: On 28 Mar 2017, at 23:27, Dave Lawrence wrote: Peter van Dijk writes: Please note that neither draft handles the use case of also passing the port number, which in a world of growing CGN deployment, may soon prove quite important. I agree

Re: [DNSOP] draft-tale-dnsop-edns-clientid

2017-03-31 Thread Peter van Dijk
On 28 Mar 2017, at 21:56, Barry Raveendran Greene wrote: On Mar 28, 2017, at 12:31 PM, Peter van Dijk wrote: Please note that neither draft handles the use case of also passing the port number, which in a world of growing CGN deployment, may soon prove quite

Re: [DNSOP] draft-tale-dnsop-edns-clientid

2017-03-31 Thread Peter van Dijk
On 28 Mar 2017, at 23:27, Dave Lawrence wrote: > Peter van Dijk writes: >> Please note that neither draft handles the use case of also passing the >> port number, which in a world of growing CGN deployment, may soon prove >> quite important. > > I agree that neither handles it explicitly. Ray's

Re: [DNSOP] draft-tale-dnsop-edns-clientid

2017-03-30 Thread Ray Bellis
On 30/03/2017 16:48, Mark Andrews wrote: > > I'm going to assume these two proposals can be merged. > > The simple way to do this is to *always* add a OPT record that only > contains this option to the end of the packet adjusting the additional > section count. This OPT record is removed and

Re: [DNSOP] draft-tale-dnsop-edns-clientid

2017-03-30 Thread Mark Andrews
I'm going to assume these two proposals can be merged. The simple way to do this is to *always* add a OPT record that only contains this option to the end of the packet adjusting the additional section count. This OPT record is removed and the additional section count is adjusted prior to TSIG

Re: [DNSOP] draft-tale-dnsop-edns-clientid

2017-03-30 Thread tjw ietf
Catching up with the discussion I like having two, well documented options. I do see where the option in David's draft has too many moving parts. On Thu, Mar 30, 2017 at 11:20 AM, Dave Lawrence wrote: > On 30/03/2017 09:52, Bob Harold wrote: > >> Just a thought - would it be

Re: [DNSOP] draft-tale-dnsop-edns-clientid

2017-03-30 Thread Dave Lawrence
On 30/03/2017 09:52, Bob Harold wrote: >> Just a thought - would it be better to have two different EDNS0 options >> that carry an IP, or to have one EDNS0 option that carries both an IP >> and a 'type', and allow multiples of that option in a packet? Ray Bellis writes: > IMHO, two options is

Re: [DNSOP] draft-tale-dnsop-edns-clientid

2017-03-30 Thread Ray Bellis
On 30/03/2017 09:52, Bob Harold wrote: > Just a thought - would it be better to have two different EDNS0 options > that carry an IP, or to have one EDNS0 option that carries both an IP > and a 'type', and allow multiples of that option in a packet? IMHO, two options is better. Ray

Re: [DNSOP] draft-tale-dnsop-edns-clientid

2017-03-30 Thread Bob Harold
On Wed, Mar 29, 2017 at 11:47 AM, Ray Bellis wrote: > > > On 29/03/2017 10:41, Dave Lawrence wrote: > > > Well yes, but there's another simple test, the limited Expert Review > > guidance against duplicate functionality. Both xpf and clientid > > provide the functionality of

Re: [DNSOP] draft-tale-dnsop-edns-clientid

2017-03-29 Thread Dave Lawrence
Ray Bellis writes: > It's effectively the same argument about TXT records - there's plenty of > things that use TXT format, but it's preferred that separate RRTYPEs are > used to indicate the use case. If that's the position the WG would like to take, I'd be fine with that.

Re: [DNSOP] draft-tale-dnsop-edns-clientid

2017-03-29 Thread Ray Bellis
On 29/03/2017 10:41, Dave Lawrence wrote: > Well yes, but there's another simple test, the limited Expert Review > guidance against duplicate functionality. Both xpf and clientid > provide the functionality of conveying an IP address in an EDNS0 > option. Whilst you're correct that they both

Re: [DNSOP] draft-tale-dnsop-edns-clientid

2017-03-29 Thread Dave Lawrence
Ray Bellis writes: > I therefore think there's a simple test here: [...] Well yes, but there's another simple test, the limited Expert Review guidance against duplicate functionality. Both xpf and clientid provide the functionality of conveying an IP address in an EDNS0 option.

Re: [DNSOP] draft-tale-dnsop-edns-clientid

2017-03-28 Thread Ray Bellis
On 28/03/2017 16:02, Dave Lawrence wrote: > Understandable. I honestly have similar reservations. > > One thing that clouds this a little, as far as our draft is concerned, > is that the ISP's CPE already knows this information so in a sense it > isn't that a different party is being

Re: [DNSOP] draft-tale-dnsop-edns-clientid

2017-03-28 Thread Dave Lawrence
Peter van Dijk writes: > On 28 Mar 2017, at 16:35, Dave Lawrence wrote: > > I grant that there is reason for pause because both Nominum and > > OpenDNS have squatted code points which have duplicate functionality. > > Should this squatting perhaps be documented in the style of RFC 8093 to >

Re: [DNSOP] draft-tale-dnsop-edns-clientid

2017-03-28 Thread Dave Lawrence
Ray Bellis writes: > I'm somewhat philosophically opposed to anything that injects client > related information such that it's shared between different parties. Understandable. I honestly have similar reservations. One thing that clouds this a little, as far as our draft is concerned, is that

Re: [DNSOP] draft-tale-dnsop-edns-clientid

2017-03-28 Thread Barry Raveendran Greene
> On Mar 28, 2017, at 12:31 PM, Peter van Dijk > wrote: > > Please note that neither draft handles the use case of also passing the port > number, which in a world of growing CGN deployment, may soon prove quite > important. Can you elaborate?

Re: [DNSOP] draft-tale-dnsop-edns-clientid

2017-03-28 Thread Peter van Dijk
Hello, On 28 Mar 2017, at 0:49, Dave Lawrence wrote: Speaking of Ray's draft, our proposal is able to handle his use case but unfortunately our use cases are not achievable in his. I'd welcome joining up. Please note that neither draft handles the use case of also passing the port number,

Re: [DNSOP] draft-tale-dnsop-edns-clientid

2017-03-28 Thread Peter van Dijk
Hello, On 28 Mar 2017, at 16:35, Dave Lawrence wrote: I grant that there is reason for pause because both Nominum and OpenDNS have squatted code points which have duplicate functionality. Should this squatting perhaps be documented in the style of RFC 8093 to avoid future surprises? Kind

Re: [DNSOP] draft-tale-dnsop-edns-clientid

2017-03-28 Thread Ray Bellis
On 27/03/2017 17:49, Dave Lawrence wrote: > As Sara commented on Ray's draft that proposes a very similar option, > draft-bellis-dnsop-xpf, this sort of thing clearly needs a close look > at privacy, and I whole-heartedly agree. I've already been directly > poking privacy-concerned individuals

Re: [DNSOP] draft-tale-dnsop-edns-clientid

2017-03-28 Thread Dave Lawrence
Olafur Gudmundsson writes: > Strictly speaking the draft was never formally submitted via IANA. This is part of the problem with documentation. At least one natural entry point for the process, the IANA assignments page, doesn't indicate how to initiate expert review.

Re: [DNSOP] draft-tale-dnsop-edns-clientid

2017-03-27 Thread Olafur Gudmundsson
> On Mar 27, 2017, at 5:49 PM, Dave Lawrence wrote: > > One of the two drafts I wanted to talk about at dnsop today for WG > adoption was "Client ID in Forwarded DNS Queries": > https://datatracker.ietf.org/doc/draft-tale-dnsop-edns0-clientid/ > > The core idea of this document is

[DNSOP] draft-tale-dnsop-edns-clientid

2017-03-27 Thread Dave Lawrence
One of the two drafts I wanted to talk about at dnsop today for WG adoption was "Client ID in Forwarded DNS Queries": https://datatracker.ietf.org/doc/draft-tale-dnsop-edns0-clientid/ The core idea of this document is to be able to provide device-specific identification in an EDNS option sent to