Hi Jinmei, Thanks for taking the time to verify the changes. See comments inline.
Thanks Suresh
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.
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?
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.
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?
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.
Looks good. I will use your suggested text.
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
