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 18:13 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3526B1B3099 for <dhcwg@ietfa.amsl.com>; Tue, 16 Feb 2016 10:13:59 -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 D_COKGARzZPK for <dhcwg@ietfa.amsl.com>; Tue, 16 Feb 2016 10:13:58 -0800 (PST)
Received: from xsmtp12.mail2web.com (xsmtp32.mail2web.com [168.144.250.235]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E1211B31DB for <dhcwg@ietf.org>; Tue, 16 Feb 2016 10:13:57 -0800 (PST)
Received: from internal.xmail06.myhosting.com ([10.5.2.16] helo=xmail06.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <huitema@huitema.net>) id 1aVk8F-0006KE-M5 for dhcwg@ietf.org; Tue, 16 Feb 2016 13:13:55 -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: '神明達哉' <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
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/4bDXS5MmV9_cChDSSPgvYSdpst8>
Cc: dhc-chairs@ietf.org, 'IETF-Announce' <ietf-announce@ietf.org>, draft-ietf-dhc-anonymity-profile@ietf.org, dhcwg@ietf.org
Subject: Re: [dhcwg] Last Call: <draft-ietf-dhc-anonymity-profile-06.txt> (Anonymity profile for DHCP clients) to Proposed Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Feb 2016 18:13:59 -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