Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers

Brandon Williams <> Wed, 11 June 2014 17:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 784591A01CE; Wed, 11 Jun 2014 10:04:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dXCG4UxmwXpL; Wed, 11 Jun 2014 10:04:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AA72B1A01B7; Wed, 11 Jun 2014 10:04:11 -0700 (PDT)
Received: from (localhost []) by postfix.imss70 (Postfix) with ESMTP id F1467286CD; Wed, 11 Jun 2014 17:04:10 +0000 (GMT)
Received: from ( []) by (Postfix) with ESMTP id DC50028634; Wed, 11 Jun 2014 17:04:10 +0000 (GMT)
Received: from [] ( []) by (Postfix) with ESMTP id BFDF38003C; Wed, 11 Jun 2014 17:04:10 +0000 (GMT)
Message-ID: <>
Date: Wed, 11 Jun 2014 13:04:10 -0400
From: Brandon Williams <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: joel jaeggli <>, Stephen Farrell <>, Dan Wing <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" <>, Internet Area <>
Subject: Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Privacy Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Jun 2014 17:04:13 -0000

I agree entirely that defining host identification as a problem 
indicates that the authors believe a solution is called for. I also 
agree that the privacy impact of solution candidates must be discussed, 
including making a concerted effort to mitigate the possibility of those 
solution candidates being used for pervasive monitoring purposes. My 
point is simply that this draft is not intended to propose solutions or 
discuss solution candidates.

RFC6967, which as you note is repeatedly cited, discusses solution 
candidates and lays out a framework for privacy discussion related to 
solution proposals. Future RFCs that actually propose solutions are 
already expected to follow the guidance from RFC6967, and the references 
to that RFC in this draft are meant to point to RFC6967 as the 
authoritative guidance.

Is there some reason why you do not consider it adequate for this "use 
cases" draft to reference the existing and already published "potential 
solutions analysis" rfc? What specific content related to privacy and/or 
pervasive monitoring belongs in this draft that is not already present 
in RFC6967?


On 06/09/2014 01:16 PM, joel jaeggli wrote:
> On 6/9/14, 7:01 AM, Stephen Farrell wrote:
>> On 09/06/14 14:46, Brandon Williams wrote:
>>> Would you please indicate where the draft proposes a new identifier? If
>>> you are seeing a proposal for protocol changes somewhere in the draft,
>>> editing work is required in order to either clarify or excise the
>>> associated text.
> There are 6 citations of
> the document doesn't exist in a vacuum where somehow how to do it has
> fallen off the table.
> given the repeated asertion that this work is useful because of external
> requests (etsi) and that request is in fact tied closely to a particular
> method it is relatively strait forward to conflate the discussion of
> scenarios and methods.
>> Fair enough that its an assumption of mine that adding some kind of
>> identifier is required to meet the (no-longer mis-stated:-)
>> requirements for these use-cases. But I think that is logically
>> required, and its valid to draw obvious conclusions and its also
>> invalid to ignore obvious conclusions.
>> S.
>> _______________________________________________
>> Int-area mailing list

Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.