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

Olafur Gudmundsson <ogud@ogud.com> Tue, 28 March 2017 04:35 UTC

Return-Path: <ogud@ogud.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A54129851 for <dnsop@ietfa.amsl.com>; Mon, 27 Mar 2017 21:35:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id op7jk1s9ZAfx for <dnsop@ietfa.amsl.com>; Mon, 27 Mar 2017 21:35:10 -0700 (PDT)
Received: from smtp109.ord1c.emailsrvr.com (smtp109.ord1c.emailsrvr.com [108.166.43.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8F7128B44 for <dnsop@ietf.org>; Mon, 27 Mar 2017 21:35:10 -0700 (PDT)
Received: from smtp22.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp22.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 4CC65E02DA; Tue, 28 Mar 2017 00:35:09 -0400 (EDT)
X-Auth-ID: ogud@ogud.com
Received: by smtp22.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 3EBD0E0231; Tue, 28 Mar 2017 00:35:07 -0400 (EDT)
X-Sender-Id: ogud@ogud.com
Received: from dhcp-ba84.meeting.ietf.org (dhcp-ba84.meeting.ietf.org [31.133.186.132]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Tue, 28 Mar 2017 00:35:09 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Olafur Gudmundsson <ogud@ogud.com>
In-Reply-To: <22745.38650.113925.208670@gro.dd.org>
Date: Mon, 27 Mar 2017 23:35:05 -0500
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3BE34823-E83C-4F9D-ABE1-35C61F9E2996@ogud.com>
References: <22745.38650.113925.208670@gro.dd.org>
To: Dave Lawrence <tale@dd.org>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/yanAFz3EfbKkRjIBuAdsMAfdkKg>
Subject: Re: [DNSOP] draft-tale-dnsop-edns-clientid
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2017 04:35:12 -0000

> On Mar 27, 2017, at 5:49 PM, Dave Lawrence <tale@dd.org> 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