[dhcwg] draft-ietf-dhc-stable-privacy-addresses discussion summary

[Tomek Mrugalski <[e-mail]>]

During DHC meeting in Prague, we had a discussion about the next steps
for draft-ietf-dhc-stable-privacy-addresses. This discussion was brought
up, because new opinions were voiced questioning the value of this work,
in particular in the light of other developments in the privacy area. A
number of possible ways forward - continue as is (std), continue as
informational, drop the work - was discussed. The consensus in the room
was to drop the work. A follow-up discussion on the mailing list
unfolded. It's now a high time to wrap up this topic, so here it goes.
After much deliberation, DHC chairs, after consulting with the
responsible AD, determined that there was a strong consensus to stop
working on draft-ietf-dhc-stable-privacy-addresses.

This is one of the toughest decisions we had to make, so I think
explaining the reasoning that led us to that decision is in order. We
feel that this solution is strongly supported by a very small number of
very active people, but the large majority of participants is against
it. There were number of arguments raised, and we'd like to summarize
the most important ones. Links to the specific discussions are included.

1. By definition, stable addresses allow for tracking over time, which
is the antinomy of privacy. This is the biggest, fundamental objection
that cannot be solved with any amount of edits. Details:
https://mailarchive.ietf.org/arch/msg/dhcwg/4zYHTadYZDJj97KIC83yS1u6O_0

2. It was claimed that "it offers a useful way to implement DHCPv6
Failover using a calculated technique rather than state-sharing". This
argument is not valid, because of possible Declines. Details:
https://mailarchive.ietf.org/arch/msg/dhcwg/wfpCAY_yZ_AdVbLnzKUIbU-MkbI

3. An issue was raised that the proposal implicitly assumes that
Declines will never happen. Addressing this would require updating
"stable" to "probabilistically stable". Details:
https://mailarchive.ietf.org/arch/msg/dhcwg/T800BcOIagprjjfxVLuLUSh8iUA

4. Given the recent focus on privacy in IETF, publishing this draft
would send a confusing message to implementors, especially in the
context of anonymity-profile work and related drafts that recommend
different approach to solving privacy issues. Details:
https://mailarchive.ietf.org/arch/msg/dhcwg/U1T77_xagStBpFoMyQJ3CJb2BhU

Several other smaller issues were raised, but they were not factored
into the assessment of the WG's willingness to continue the work.

The document will be marked dead and WG time will not be spent on it.
There are several other efforts aimed at improving privacy within DHCP
and we encourage WG participants to actively contribute to those drafts.
If you have questions about this decision, please contact the chairs or
the shepherding AD off-list.

Because of the increased concerns for privacy, we will look at the
3315bis work (draft-ietf-dhc-rfc3315bis) to see what we might want to
add about guidelines for server implementers in terms of address
generation techniques to assure privacy. We already have a ticket
related to privacy issues,
http://trac.tools.ietf.org/group/dhcpv6bis/ticket/145.

Bernie & Tomek
DHC co-chairs