Re: "RFC4941bis" and draft-gont-6man-non-stable-iids

[Tim Chown <[e-mail]>]

> On 19 Jul 2017, at 13:57, Fernando Gont <[e-mail]> wrote:
> 
> On 07/19/2017 01:58 PM, Tim Chown wrote:
>>> On 18 Jul 2017, at 15:52, Fernando Gont <[e-mail]>
>>> wrote:
>>> 
>>> Folks,
>>> 
>>> Among the list of RFCs to be progressed to full std is/was RFC4941 
>>> ("Privacy Extensions for Stateless Address Autoconfiguration in
>>> IPv6").
>>> 
>>> As it stands, RFC4941 has a number of issues:
>>> 
>>> * Using the same IID for multiple prefixes * Not changing the IID
>>> upon "security events" (including e.g., change in the underlying
>>> MAC address) * Using MD5 as opposed to something better * Requiring
>>> the use of temporary addresses along stable addresses (preventing
>>> use of temporary-only, for nodes that feel like) * Not treating
>>> IIDs as opaque values (see RFC7136)  when generating the randomized
>>> IIDs (see step 3 in section 3.2.1 of RFC4941) * Mandating one
>>> specific algorithm, when the same goals/properties can be achieved
>>> with multiple algorithms (see section 4 of 
>>> draft-gont-6man-non-stable-iids-01)
>>> 
>>> 
>>> Based on the above, I personally don't think that it would make
>>> sense to progress RFC4941 to Internet Standard, but rather think
>>> that we should work on  a replacement of it -- our proposal being 
>>> draft-gont-6man-non-stable-iids-01.
>>> 
>>> Thoughts?
>> 
>> Certainly any update on 4941 needs to be done in the light of a few
>> deficiencies that have emerged over the years, and the publication of
>> RFC7217.
>> 
>> I think it’s still possible to do a -bis off 4941.
> 
> My questions would be:
> 
> 1) Can you actually address the aforementioned deficiencies without
> significant changes to RFC4941? -- It would seem to me that in order to
> address them, rfc4941bis would not be a bis document anymore.
> 
> 2) If you were to address such deficiencies, could the bis document be
> progressed to Internet Standard? -- My assessment of this question is: No.
> 
> If RFC4941 would take significant work, and the end result would
> actually be significantly different from what's in RFC4941, then I'm not
> sure that'd be different than starting from the I-D we already have...

Just to be clear, I like the material in your new draft.

That said, it seems you could do a similar style of update from 3041 to 4941, with a similar structure; the content is there in your draft, it “just" needs to be merged in.

That would mean obsoleting 4941, just as 4941 obsoleted 3041.  So you would include the details in 4941 that would carry forward.

Tim