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

<Dirk.von-Hugo@telekom.de> Tue, 10 June 2014 10:30 UTC

Return-Path: <Dirk.von-Hugo@telekom.de>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0AB31A04F6; Tue, 10 Jun 2014 03:30:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.901
X-Spam-Level:
X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, 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 CQRAnVyb_Yuv; Tue, 10 Jun 2014 03:30:54 -0700 (PDT)
Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E21F81A002A; Tue, 10 Jun 2014 03:30:53 -0700 (PDT)
Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 10 Jun 2014 12:30:51 +0200
Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by he110890 ([10.134.92.131]) with mapi; Tue, 10 Jun 2014 12:30:50 +0200
From: Dirk.von-Hugo@telekom.de
To: joelja@bogus.com, stephen.farrell@cs.tcd.ie, brandon.williams@akamai.com, dwing@cisco.com
Date: Tue, 10 Jun 2014 12:30:46 +0200
Thread-Topic: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers
Thread-Index: Ac+EFjUJwii/Fz27Ro+jpZhjUs3c3wAd1VPg
Message-ID: <05C81A773E48DD49B181B04BA21A342A2E0071B529@HE113484.emea1.cds.t-internal.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> <5395EBE3.3030408@bogus.com>
In-Reply-To: <5395EBE3.3030408@bogus.com>
Accept-Language: de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/tbgRxxZaw8BHeZb62C3lyyXqiug
Cc: ietf-privacy@ietf.org, int-area@ietf.org
Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jun 2014 10:30:58 -0000

Dear all,
I would like to confirm this: As already pointed out by Bruno in http://www.ietf.org/mail-archive/web/int-area/current/msg03904.html there is the emergency call use case at ETSI and beside that there are application proposals within WGs SFC, TCPM, etc. beside other drafts which refer to RFC 6967.

And although I might repeat again what has been stated many times: Intended goal is and should be to find a solution to fulfil dedicated and real use cases demands - respecting privacy, reducing vulnerability, strengthening protection against misuse as mentioned in BCP188, and so on ...

Best regards
Dirk 

-----Original Message-----
From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of joel jaeggli
Sent: Montag, 9. Juni 2014 19:16
To: Stephen Farrell; Brandon Williams; Dan Wing
Cc: ietf-privacy@ietf.org; Internet Area
Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers

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
>