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

Dave Lawrence <tale@dd.org> Mon, 27 March 2017 22:49 UTC

Return-Path: <tale@dd.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0EA0B12966F for <dnsop@ietfa.amsl.com>; Mon, 27 Mar 2017 15:49:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cxANVwBP7HHa for <dnsop@ietfa.amsl.com>; Mon, 27 Mar 2017 15:49:31 -0700 (PDT)
Received: from gro.dd.org (gro.dd.org []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D506126E3A for <dnsop@ietf.org>; Mon, 27 Mar 2017 15:49:31 -0700 (PDT)
Received: by gro.dd.org (Postfix, from userid 102) id 329B63F469; Mon, 27 Mar 2017 18:49:30 -0400 (EDT)
Message-ID: <22745.38650.113925.208670@gro.dd.org>
Date: Mon, 27 Mar 2017 18:49:30 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
From: Dave Lawrence <tale@dd.org>
To: dnsop@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-W_wsuQHUcDEEvgPnBc_zx9IItI>
Subject: [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: Mon, 27 Mar 2017 22:49:33 -0000

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

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.