Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-privacy-01 - Respond by Sept. 22, 2015
神明達哉 <jinmei@wide.ad.jp> Tue, 15 September 2015 18:06 UTC
Return-Path: <jinmei.tatuya@gmail.com>
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 8DF371A8A52 for <dhcwg@ietfa.amsl.com>; Tue, 15 Sep 2015 11:06:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level:
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 Jne3fNenb-Rf for <dhcwg@ietfa.amsl.com>; Tue, 15 Sep 2015 11:06:15 -0700 (PDT)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6D2D1A8A16 for <dhcwg@ietf.org>; Tue, 15 Sep 2015 11:06:13 -0700 (PDT)
Received: by igcpb10 with SMTP id pb10so19757445igc.1 for <dhcwg@ietf.org>; Tue, 15 Sep 2015 11:06:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=FqPyAGQ4JwhsBF/AWhfE0p/Wk4gISPRRSc+B0GZYXA4=; b=qC6rmcAfpZ/2+XmEjhmLvlt7dROcXVFeGUc3nbYuPpfpFycMd0aDuOJQzcMmUf2kJr 4YxHzdiYBt01PMPKRaNPUwj536aEXqgPnUAy4vY7Q9jHJ2ZHPxXQyQkSDcBwxQHV+J2c 6x/iuUcOfrbwF7+Nhb5l3ZsxxWUgPxuUeysSQSC434UA3v7Z4v4NGzwfe6cUsJoWtTR6 qmkyy8iVTIGXWKtnQzhPOecxeWBqpUwSxcMe7D98oPCdJGR0CsWN4AmzrUQM+zIduhQm EudKSp0oVDS/le6Z5R2+pjSYmWNpYl7tNhkDDfyv4fLrkPHGe8lik9lo3bLJVLA2C2BM peGg==
MIME-Version: 1.0
X-Received: by 10.50.126.66 with SMTP id mw2mr8111463igb.64.1442340373136; Tue, 15 Sep 2015 11:06:13 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.140.12 with HTTP; Tue, 15 Sep 2015 11:06:13 -0700 (PDT)
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1CC66123@xmb-rcd-x04.cisco.com>
References: <489D13FBFA9B3E41812EA89F188F018E1CC66123@xmb-rcd-x04.cisco.com>
Date: Tue, 15 Sep 2015 11:06:13 -0700
X-Google-Sender-Auth: IzzvcikagFvtOxRuTnXuPBymnlI
Message-ID: <CAJE_bqfV1DPm7XtbTJqKXRGXc_e9bDCuwzmMJ6p5xOnLUARDUA@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: "Bernie Volz (volz)" <volz@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/6DsdZl-QJcevqMktaxvhtg9gGeo>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-privacy-01 - Respond by Sept. 22, 2015
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, 15 Sep 2015 18:06:17 -0000
On Wed, Sep 2, 2015 at 2:44 PM, Bernie Volz (volz) <volz@cisco.com> wrote: > This message starts the DHC Working Group Last Call to advance > draft-ietf-dhc-dhcpv6-privacy-01, Privacy considerations for DHCPv6, > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-privacy-01. This document’s > intended status is Informational. At present, there is no IPR file against > this document. [...] > Please send your comments by September 22th, 2015. If you do not feel this > document should advance, please state your reasons why. I don't have a strong opinion on whether to advance it, but I personally think it's premature to be published. There are several confusing points in the draft (see below for specific points), and if I were to decide I'd first clarify these before sending it to the IESG. Also, as someone who is not a privacy expert, I don't know for sure if there are missing important points (while I can make comments on what's currently written). It would be nice if someone with this expertise can explicitly comment on that point (rather than interpret silence as acceptance). Specific comments on the draft: - Section 3.1 Even if the administrator enables privacy extensions (see [RFC4941]) and its equivalent for link-layer address randomization, it is likely that those privacy mechanisms were disabled during the first device boot. I don't understand how RFC4941 is relevant in this context (I understand the relevance of LL addr randomization). Elaboration? (or if it's not really relevant I suggest just removing it). - Section 3.2 Client ID is an example of DUID. I don't understand this sentence. First off, RFC3315 barely defines "Client ID(entifier)" while it defines "DUID" or "Client ID Option". If you mean the DUID field value of client ID option by "Client ID", this sentence sounds too obvious to me. It's not a big deal, but I suggest just removing this sentence as I don't think it helps readers and can rather confuse them. - Section 3.11.2 it is often a text string that includes the relay agent name followed by interface name. What does "often" mean? Does this mean the vast majority of relay implementations behave this way? If so, is it based on a survey of implementations? - Section 4.1 Many client implementations renew those addresses during a renewal procedure initiated by other resources (non-temporary addresses or prefixes), thus forfeiting shortliveness. What does this 'many' mean? Specifically how many implementation out of which behave this way? Regardless of exactly how many, this behavior rather seems to be an implementation bug, since, as the draft itself states, it would forfeit the point of temporary addresses. If that's what this draft tries to point out, I think it should state it's an implementation defect to be fixed more clearly. Right now it could rather read this is a protocol problem. - Section 4.1 Second, [RFC4704] allows servers to update DNS for assigned temporary addresses. Publishing client's IPv6 address in DNS that is publicly available is a major privacy breach. Similar to the previous point, if a server performs dynamic DNS update for a temporary address it assigns to a client (corresponding to IA_TA), it seems to me that the server implementation is just too naive. And, like the previous point, currently the draft doesn't seem to read it's an implementation problem. - Section 4.2 DNS Updates [RFC4704] defines a mechanism that allows both clients and server to insert into DNS domain information about clients. Both "DNS Updates [RFC4704]" looks confusing/misleading to me. I believe the term "DNS Updates" generally refers to the protocol defined in RFC2136. If this "DNS Updates" is intended to mean the protocol described in RFC4704 (I think that's the intent from the context), I suggest using some other term than "DNS Updates". If it actually means the protocol defined in RFC2136, it should refer to RFC2136, not RFC4704. Same comment applies to Section 5.7. - Section 4.3 Identifier-based allocation - a server may choose to allocate an address that is based on one of available identifiers, e.g. IID or MAC address. What does this "IID" mean? Interface Identifier? If so, I don't understand it. Or perhaps DUID? - Section 5.4 They do this by putting the previously assigned address(es) in the IA Address Option(s) inside the IA_NA, IA_TA. Is a client really supposed to include IA_TA? Or is this about specific implementations? Either way this behavior seems to be simply broken. If it talks about (a defect of) specific implementation, it may be worth noting, but I think it should be clearly separated from the case of IA_NA and described as an implementation defect. - Section 7 As such, no dedicated section about this is needed. This sounds awkward to me since Section 7 is actually a "dedicated section about" privacy. Guessing author's intent, perhaps this should be "no dedicated discussion"? Editorial nits: - Section 1: s/or/of/ or s/or/for/ (?) The privacy or DHCP servers and relay agents are - Section 4.1 There are number of serious issues, both protocolar and implementational, that make them nearly useless for their original The term "protocolar" is not in my usual dictionaries...is it some kind of jargon that I yet to learn, or is it just a typo? - I've found other several trivial typos and grammar errors, but I won't bother to list all of them here. The authors might want to run another cycle of proofread before finally submitting it to the IESG (or with RFC editor) -- JINMEI, Tatuya
- [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-privacy-01 … Bernie Volz (volz)
- Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-privacy… 神明達哉
- Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-privacy… Marcin Siodelski
- Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-privacy… Tomek Mrugalski
- Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-privacy… Bernie Volz (volz)
- Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-privacy… 神明達哉
- Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-privacy… Tomek Mrugalski
- Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-privacy… Tomek Mrugalski