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

Dave Lawrence <> Tue, 28 March 2017 21:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D2C701279E5 for <>; Tue, 28 Mar 2017 14:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fhG1hDgCMjCn for <>; Tue, 28 Mar 2017 14:02:11 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0C4E5126C23 for <>; Tue, 28 Mar 2017 14:02:11 -0700 (PDT)
Received: by (Postfix, from userid 102) id 8950B3F468; Tue, 28 Mar 2017 17:02:09 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Tue, 28 Mar 2017 17:02:09 -0400
From: Dave Lawrence <>
In-Reply-To: <>
References: <> <>
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 21:02:13 -0000

Ray Bellis writes:
> I'm somewhat philosophically opposed to anything that injects client
> related information such that it's shared between different parties.

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.