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

joel jaeggli <joelja@bogus.com> Mon, 09 June 2014 19:08 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: ietf-privacy@ietfa.amsl.com
Delivered-To: ietf-privacy@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE0D1A02CE; Mon, 9 Jun 2014 12:08:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 lhHicYd8Xbwj; Mon, 9 Jun 2014 12:08:12 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67CF91A029F; Mon, 9 Jun 2014 12:08:12 -0700 (PDT)
Received: from mbp.local (31.66.208.web-pass.com [208.66.31.202] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s59J6Cs3001227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Jun 2014 19:06:12 GMT (envelope-from joelja@bogus.com)
Message-ID: <5395EBE3.3030408@bogus.com>
Date: Mon, 09 Jun 2014 10:16:19 -0700
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Brandon Williams <brandon.williams@akamai.com>, Dan Wing <dwing@cisco.com>
References: <E87B771635882B4BA20096B589152EF628724B2C@eusaamb107.ericsson.se> <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> <5395BAD3.4040506@akamai.com> <5395BE2A.6090708@cs.tcd.ie>
In-Reply-To: <5395BE2A.6090708@cs.tcd.ie>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="TOmxHNR2EjEGCDosKdeWOu7aWFuRa5ruF"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 09 Jun 2014 19:06:15 +0000 (UTC)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-privacy/NObZyc56eLMK4nkjfiU_KvydNXo
Cc: "ietf-privacy@ietf.org" <ietf-privacy@ietf.org>, Internet Area <int-area@ietf.org>
Subject: Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
X-BeenThere: ietf-privacy@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Privacy Discussion List <ietf-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-privacy/>
List-Post: <mailto:ietf-privacy@ietf.org>
List-Help: <mailto:ietf-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jun 2014 19:08:13 -0000

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

http://tools.ietf.org/html/rfc6967

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
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>