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

Olafur Gudmundsson <> Tue, 28 March 2017 04:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27A54129851 for <>; Mon, 27 Mar 2017 21:35:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.921
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id op7jk1s9ZAfx for <>; Mon, 27 Mar 2017 21:35:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D8F7128B44 for <>; Mon, 27 Mar 2017 21:35:10 -0700 (PDT)
Received: from (localhost []) by (SMTP Server) with ESMTP id 4CC65E02DA; Tue, 28 Mar 2017 00:35:09 -0400 (EDT)
Received: by (Authenticated sender: with ESMTPSA id 3EBD0E0231; Tue, 28 Mar 2017 00:35:07 -0400 (EDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by (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 <>
In-Reply-To: <>
Date: Mon, 27 Mar 2017 23:35:05 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Dave Lawrence <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Subject: Re: [DNSOP] draft-tale-dnsop-edns-clientid
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Mar 2017 04:35:12 -0000

> 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":
> 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

> 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.