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

[Olafur Gudmundsson <[e-mail]>]

> On Mar 27, 2017, at 5:49 PM, Dave Lawrence <[e-mail]> 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 to be able to provide
> device-specific identification in an EDNS option sent to a
> full-service resolver, with the principal motivation to be for
> filtering products.  It uses an IANA Address Family value to indicate
> the format of the identifier that is being sent.  One of the design
> goals was to avoid creating any new registries.
> 
> This document treads on controversial grounds because of the obvious
> privacy implications.  It must be noted that both Nominum and Cisco
> are already doing this via EDNS options, and so the general idea
> confronts some similar issues we've encountered before about whether
> to document in-use protocols or let them just continue on with little
> to no public documentation.
> 
> 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 for feedback.
> 
> 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.
> 
> The one other thing I wanted to mention in the WG is that I tried to
> get an EDNS code point assigned through the "Expert Review" process,
> which it turns out is very poorly documented for either process or
> review criteria.  The Expert Reviewer, Olafur Gudmundsson, has
> initially denied the request pending feedback from the WG.  I'll leave
> it to him to state what gave him pause, and to request the feedback he
> seeks.

Strictly speaking the draft was never formally submitted via IANA. 
Rather I was giving David advise on how I would rule if he submitted the draft. 

As expert I do not have any formal guidelines to tell me how to judge 
options. My rule after implementing ClientSubnet is “never again” allow complex type. 
So I told David et. al. that the type requested had 4 sub-types one already allocated,
so stop sub-typing and ask for 3 extra types.

I did not judge anything about the privacy issues that those 4 types may have, as 
that is not in scope.
It is up to the working group to give advice to either editor or expert to change
approach. 

> 
> The denial triggered a bit of a philosophical debate between us, but
> no matter which side of that debate you line up on it's very clear
> that Expert Review really needs documentation to appropriately set
> everyone's expectations.  I'm hoping that he and I will be
> collaborating on a draft.
> 
As Expert I do not want to write the rules for myself :-) 
I will be happy to comment on any suggested rules/advise. 

Olafur