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 informed. > > What I'm trying to accomplish with this draft is acknowledge the > practical realities that this sort of option is already in use on the > Internet and will continue to be used no matter what the WG does about > either of our drafts. I also wanted to drag the PII issues out into > the open, into one place where they would have to be confronted by > implementers and operators. > > I fear that a splintered effort on including full client-identifying > information in several different ways is going to lead to problematic > fragmentation and harder management. The examples in your draft appear focused on identifying specific end user devices, e.g. to selectively enable parental controls on a per-device basis. Mine is intended to identify clients based on their presented IP address (whether that be the public IP address of multiple NATed end users talking to a recursor, or the external IP address of a recursor talking to an authoritative server). The primary purpose is for admission control (i.e. ACLs). I therefore think there's a simple test here: If we can imagine scenarios in which an auth or recursive server that is behind e.g. a load-balancing proxy needs to know *both* the internal "client ID" (per your draft) and the client's effective external source IP address (per mine) then both drafts serve their own distinct purpose and shouldn't be merged. Ray _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
