Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-privacy-addrs-v2-02.txt

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 01 Apr 2005 16:12:13 +0900

>>>>> On Tue, 29 Mar 2005 13:32:55 -0500, 
>>>>> Brian Haberman <[email-masked]> said:

>       The WG Last Call ended almost two months ago with no comments
> received.  There was some in-depth conversation about this document
> during the Washington D.C. meeting.  I need those people who raised
> issues with the -01 version to indicate that those issues were resolved
> in this -02 version.

Sorry for the delayed response.  I've checked the latest draft,
recalling my comments on the previous version:
  http://www1.ietf.org/mail-archive/web/ipv6/current/msg03875.html

I'm NOT opposing to submitting the 02 version to the IESG, but I still
have some comments on it (which may be addressed with IESG feedback).

1. Regarding comment 1 in "msg03875.html", I'd also revise the first
   sentence of Section 1.1

   From:
     Addresses generated using Stateless address autoconfiguration
     [ADDRCONF]contain an embedded 64-bit interface identifier, which
     remains constant over time.

  To:
     Addresses generated using Stateless address autoconfiguration
     [ADDRCONF] contain an embedded interface identifier, which
     remains constant over time.

  In this context, the point should be that the interface identifier
  remains constant, and the exact number of ID length (64-bit) is
  rather minor.  Thus, removing the number should be safe, and is
  actually more aligned with the latest sense of rfc2462bis.

2. Comment 3 in "msg03875.html" does not seem to be addressed.
   Perhaps this is too minor, however, and I could live with the
   current text.

3. I'd like to see more clarity for comment 6 in "msg03875.html".  How
   about changing the first paragraph of Section 2.4

From:
   One way to avoid having a static non-changing address is to use
   DHCPv6 [DHCPV6] for obtaining addresses.  The DHCPv6 server could be
   configured to hand out addresses that change over time.  But DHCPv6
   will solve the privacy issue only if it frequently handed out
   constantly changing addresses to the nodes.  Since this does not
   happen automatically, and is difficult to configure manually, DHCPv6
   is not a self contained alternative for solving the privacy issues
   addressed by this document.  However, in the absence of stateless
   address autoconfiguration, DHCPv6 can be used for distributing
   temporary addresses to clients.

To:
   One way to avoid having a static non-changing address is to use
   DHCPv6 [DHCPV6] for obtaining addresses.  The DHCPv6 server could
   be configured to hand out addresses that change over time.  But
   DHCPv6 will solve the privacy issue only if it frequently handed
   out constantly changing addresses to the nodes or if the DHCPv6
   client moves from links to links frequently, being allocated
   independent addresses from different DHCPv6 servers.  However, the
   former does not happen automatically, and is difficult to configure
   manually; the latter cannot be assumed for static (not frequently
   moving) hosts.  Thus, DHCPv6 is not a self contained alternative
   for solving the privacy issues addressed by this document.
   However, in the absence of stateless address autoconfiguration,
   DHCPv6 can be used for distributing temporary addresses to clients.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 01 Apr 2005 16:46:31 +0900

>>>>> On Fri, 01 Apr 2005 16:12:13 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> have some comments on it (which may be addressed with IESG feedback).

I forgot to add one more thing.  This is not related to my previous
comments, but will probably be an issue later, so I think it's worth
raising at this point.

4. The normative reference to [ADDR_SELECT] (RFC3484) will cause a
   down-reference problem (privacy-addrs-v2 will become a DS while
   RFC3484 is a PS).  As far as I can see, I think we can safely
   categorize this reference as an informative one, which is the
   easiest resolution to this type of issue.

					JINMEI, Tatuya

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 1 Apr 2005 11:29:06 -0500 (EST)

Hi Jinmei,
   Thanks for taking the time to verify the changes. See comments inline.

Thanks
Suresh

>  actually more aligned with the latest sense of rfc2462bis.

I have the following text in the introduction which restricts the scope of 
the document to 64 bit identifiers.

" Note that an IPv6 identifier does not necessarily have to be 64 bits in
   length, but the algorithm specified in this document is targeted towards
   64-bit interface identifiers."

Do you still want me to make this change?

>   Perhaps this is too minor, however, and I could live with the

The concerns are described in section 2.3. I did not want to repeat them 
here. However, I can rephrase the sentence
from

" The focus of this document is on addresses derived from IEEE identifiers,
   as the concern being addressed exists only in those cases where the
   interface identifier is globally unique and non-changing"

to

" The focus of this document is on addresses derived from IEEE identifiers,
   because an interface identifier that is globally unique and non-changing
   can facilitate the tracking of individual devices and possibly users
   of those devices."

Is that OK?

>   DHCPv6 can be used for distributing temporary addresses to clients.

Looks good. I will use your suggested text.

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 1 Apr 2005 11:31:52 -0500 (EST)

Hi Jinmei,

Thanks
Suresh

>  actually more aligned with the latest sense of rfc2462bis.

I have the following text in the introduction which restricts the scope of the
document to 64 bit identifiers.

>   Perhaps this is too minor, however, and I could live with the

The concerns are described in section 2.3. I did not want to repeat them here.
However, I can rephrase the sentence
from

to

Is that OK?

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 02 Apr 2005 19:19:32 +0900

>>>>> On Fri, 1 Apr 2005 11:31:52 -0500 (EST), 
>>>>> Suresh Krishnan <[email-masked]> said:

> document to 64 bit identifiers.

Yes, I noticed this, but I wanted to make the proposed change in
addition to this one for the reason I mentioned above.

> Is that OK?

This is better than the original text, but I'd rephrase it a bit:

   The focus of this document is on addresses derived from IEEE
   identifiers, because tracking of individual devices, the concern
   being addressed here, is possible only in those cases where the
   interface identifier is globally unique and non-changing.

But it's completely up to you whether to make a change at all or which
text to use.

					JINMEI, Tatuya

---

From: Suresh Krishnan <[email-masked]>
Date: Sun, 3 Apr 2005 22:52:22 -0400 (EDT)

Hi Jinmei,
   I will make the changes you suggested. I will also change the address 
selection reference (RFC3484) to informative to avoid the downref.

Brian & Bob,
   Should I submit another version of the draft immediately or wait for the 
IESG to come back with more comments to make these changes?

Thanks
Suresh