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
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
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
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
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
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
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
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
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
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.
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
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.
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
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
>
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
> 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?
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,
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
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
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.
> 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
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
22 matches
Mail list logo