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

[Fernando Gont <[e-mail]>]

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.
>> 
[....]
>> Agreed. However, it looks like this document should update RFC2464,
>> though.
>> 
>> Thoughts?
> 
> 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,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1