Subject: Re: Consensus call on adopting: <draft-gont-6man-stable-privacy-addresses-01>

From: Ole Trøan <[email-masked]>
Date: Tue, 8 May 2012 19:42:17 +0200

All,

Based on the feedback received, the 6man chairs believe there is consensus
for 6MAN to work on creating a new type of IPv6 interface identifiers,
as described in draft-gont-6man-stable-privacy-addresses-01.

The discussion brought up some issues that we will work with the author to
resolve, in particular:

 - The current draft is written to not allow the IETF to create derivative works.
   This is incompatible with the IETF standards process.
   See section 4 of http://www.ietf.org/id-info/1id-guidelines.txt

 - The draft should not replace modified EUI-64 IIDs. It intents to provide an alternative to
   IEEE MAC based modified EUI-64 IIDs.
   The draft should not update RFC4191 and RFC4862
 
 - The proposed mechanism has merit separately from the perceived "security" benefits,
   because it creates modified EUI-64 Internet Identifiers that are not IEEE Mac based and
   eliminates any concern about host tracking based on the IEEE MAC addresses.
 
We will instruct the author to post the next revision as an 6MAN document.

Regards,
Bob Hinden and Ole Troan

---

From: Fernando Gont <[email-masked]>
Date: Wed, 09 May 2012 20:50:45 -0300

Hi, Ole,

>    See section 4 of http://www.ietf.org/id-info/1id-guidelines.txt

My understanding is that this is perfectly compatible with the IETF
standards process, as long as this restriction is removed before posting
as draft-ietf (for instance, I guess that's why it's allowed in the
first place). (this restriction will be removed in the upcoming
draft-ietf version, accordingly)

>    IEEE MAC based modified EUI-64 IIDs.

Agreed.

>    The draft should not update RFC4191 and RFC4862

Agreed. However, it looks like this document should update RFC2464, though.

Thoughts?

>    eliminates any concern about host tracking based on the IEEE MAC addresses.

I agree with this -- e.g. using the interface index in the hash leads to
stable NIC-independent addresses that don't vary even if you replace the
NIC. Is *this* what I should note in the next rev of the document?

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Bob Hinden <[email-masked]>
Date: Thu, 10 May 2012 07:36:56 -0400

Fernando,

> draft-ietf version, accordingly)

It is allowed and I don't want to start a big IPR thread here, but I think the intent for this clause (no derivative works) is for work that someone wants to present to a w.g. that was not intended to be an IETF work item.  My opinion is that it's not appropriate for documents intended to become an IETF work item as yours was.

> Agreed. However, it looks like this document should update RFC2464, though.

Perhaps at some point in the future if the working group wants to require stable privacy addresses, but not at this point.  I think we will need operational experience before making that change.

Bob

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 May 2012 09:16:27 -0300

Hi, Bob,

On 05/10/2012 08:36 AM, Bob Hinden wrote:
>>> - The current draft is written to not allow the IETF to create
>>> derivative works. This is incompatible with the IETF standards
>>> process. See section 4 of
>>> http://www.ietf.org/id-info/1id-guidelines.txt
>> 
>> My understanding is that this is perfectly compatible with the
>> IETF standards process, as long as this restriction is removed
>> before posting as draft-ietf (for instance, I guess that's why it's
>> allowed in the first place). (this restriction will be removed in
>> the upcoming draft-ietf version, accordingly)
> 
> It is allowed and I don't want to start a big IPR thread here, but I
> think the intent for this clause (no derivative works) is for work
> that someone wants to present to a w.g. that was not intended to be
> an IETF work item.  My opinion is that it's not appropriate for
> documents intended to become an IETF work item as yours was.

I will consult this upstream and try to remove this restriction in
future items. However, I should say that since the above restriction is
completely removed once/if the document is adopted by a WG (as required
by the standards process), I find it hard to see what's the issue.

IMHO, it would be kind of weird for an individual I-D to be
controversial because of this, and then have *RFCs* that have real and
concrete implementation restrictions -- in this case, any such
restrictions are gone way before the document becomes an actual RFC.

>>> - The draft should not replace modified EUI-64 IIDs. It intents
>>> to provide an alternative to IEEE MAC based modified EUI-64
>>> IIDs.
>> 
[....]
> Perhaps at some point in the future if the working group wants to
> require stable privacy addresses, but not at this point.  I think we
> will need operational experience before making that change.

Fair enough. My concern was that, specs-wise, IIDs will still be
required to embed IEEE-identifiers. So even if the "update" is not about
"you must use stable privacy addresses", the metadata should help anyone
implementing IPv6 over Ethernet to notice the problems of IEEE-derived
IIDs, and possible alternatives.

Thanks!

Best regards,

---

From: Randy Bush <[email-masked]>
Date: Thu, 10 May 2012 16:46:25 -1000

i have scanned and support adoption of the draft as a wg item.

> that someone wants to present to a w.g. that was not intended to be an
> IETF work item.  My opinion is that it's not appropriate for documents
> intended to become an IETF work item as yours was.

i beg to differ.  i have used the restrictive clause for years exactly
as fernando states.  if the wg does not adopt, then i may take *my*
marbles and go home.

randy

---

From: Bob Hinden <[email-masked]>
Date: Fri, 11 May 2012 16:12:28 -0400

Randy,

> as fernando states.  if the wg does not adopt, then i may take *my*

Thanks for saying it so clearly.  I choose to not do that as do many others.  I allow my contributions to be used by others in the IETF process.

Bob

---

From: Randy Bush <[email-masked]>
Date: Fri, 11 May 2012 10:16:15 -1000

> Thanks for saying it so clearly.  I choose to not do that as do many
> others.  I allow my contributions to be used by others in the IETF
> process.

_in the ietf process_ i too allow other to use the works.  but it ain't
in the ietf process unless the wg adopts it.  which is when i change the
clause.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 May 2012 07:34:04 +0100

> in the ietf process unless the wg adopts it.  which is when i change the

fwiw I agree that this is quite legitimate. I've never done it, but
I can imagine circumstances in which I might do so.

     Brian