RE: [dhcwg] Last Call: <draft-ietf-dhc-anonymity-profile-06.txt> (Anonymity profile for DHCP clients) to Proposed Standard

"Christian Huitema" <huitema@huitema.net> Tue, 16 February 2016 19:51 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC611A9238 for <ietf@ietfa.amsl.com>; Tue, 16 Feb 2016 11:51:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level:
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 D6b8L4I-c70Z for <ietf@ietfa.amsl.com>; Tue, 16 Feb 2016 11:51:10 -0800 (PST)
Received: from xsmtp03.mail2web.com (xsmtp23.mail2web.com [168.144.250.186]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1248F1A1B4B for <ietf@ietf.org>; Tue, 16 Feb 2016 11:51:09 -0800 (PST)
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1aVk8F-0001wO-3O for ietf@ietf.org; Tue, 16 Feb 2016 13:13:51 -0500
Received: (qmail 1268 invoked from network); 16 Feb 2016 18:13:50 -0000
Received: from unknown (HELO huitema2) (Authenticated-user:_huitema@huitema.net@[131.107.174.247]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <dhc-chairs@ietf.org>; 16 Feb 2016 18:13:49 -0000
From: "Christian Huitema" <huitema@huitema.net>
To: =?UTF-8?B?J+elnuaYjumBlOWTiSc=?= <jinmei@wide.ad.jp>, <ietf@ietf.org>
References: <20160201142413.30288.23248.idtracker@ietfa.amsl.com> <CAJE_bqc8asj-i4FkzT2Oc-=atZasAr1cCDUpdNaJ_wOwkRcm1A@mail.gmail.com>
In-Reply-To: <CAJE_bqc8asj-i4FkzT2Oc-=atZasAr1cCDUpdNaJ_wOwkRcm1A@mail.gmail.com>
Date: Tue, 16 Feb 2016 10:13:49 -0800
Message-ID: <163001d168e5$c9a63ed0$5cf2bc70$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQJtbhbfm6E5go4z/5mQ+0EwmlPxoQG1MG4fnelFLRA=
Content-Language: en-us
Subject: RE: [dhcwg] Last Call: <draft-ietf-dhc-anonymity-profile-06.txt> (Anonymity profile for DHCP clients) to Proposed Standard
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/kG7mMzihl3N5xs0F3vp7kGDgYoE>
Cc: dhc-chairs@ietf.org, 'IETF-Announce' <ietf-announce@ietf.org>, draft-ietf-dhc-anonymity-profile@ietf.org, dhcwg@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Feb 2016 19:51:13 -0000

On Friday, February 12, 2016 11:26 AM, JINMEI, Tatuya wrote:
> Brian Carpenter called for an attention to Section 4.5.2 of the draft:
> https://mailarchive.ietf.org/arch/msg/ipv6/J_SnGxd2JunlpOeL4JprV03UA7s
> 
> so I'm responding to it.
> 
> 4.5.2.  Prefix delegation
> 
>    The interaction between prefix delegation and anonymity require
>    further study.  For now, the simple solution is to avoid using prefix
>    delegation when striving for anonymity.  When using the anonymity
>    profiles, clients SHOULD NOT use IA_PD, the prefix delegation form of
>    address assignment.
> 
> I'm not sure what Brian tried to indicate in his message, but at least this
> section looks vague to me about the rationale for the "SHOULD NOT".  It's
> not obvious to me how IA_PD is worse than IA_NA in terms of privacy.  Is this
> a "SHOULD NOT" simply because the "interaction"
> (is not yet fully understood and) requires further study?

This section was rewritten in draft-07, following the feedback received during IETF last call. Basically, we stopped being lazy and actually did the study. And took a lot of the text that Lorenzo provided.

-- Christian Huitema