Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT)

[Brian Haberman <[e-mail]>]

On 1/22/14 4:53 PM, Fernando Gont wrote:
> On 01/22/2014 06:03 PM, Pete Resnick wrote:
>>>> This is an algorithm to generate stable, private, and mostly unique
>>>> addresses. It does not affect interoperability at all if people choose a
>>>> different method.
>>>>      
>>> The short answer to this is what Bob has already responding:
>>>
>>> We currently require nodes to embed their hardware address in the IID
>>> when they do SLAAC. And every other specification to generate IIDs is
>>> also Std track. So we are being consistent.
>>
>> As you might have guessed, consistently doing the incorrect thing isn't
>> terribly convincing to me.
> 
> If how you select an IID is not std track, prepare for lazy
> implementations to set the IID to "1" and hence for collisions to become
> common. At that point that becomes an interoperability problem.

And that vendor will be smacked eventually.  I see Pete's point and I
agree that this document could be Informational.  Especially since the
WG *just* adopted a document that will be BCP giving guidance on which
IID generation mechanisms are preferred.

> 
> And, a folk working on a v6 stack needs to implement *something*. When
> he gets to the point of generating an IID, there's something he has to
> follow. This document is one way to do it. With specific goals in mind.
> And specific requirements if you mean to meet does goals.
> 
> That looks std track to me.
> 

Except that the implementer could do any number of things and it would
not impact interoperability.  And I will note that you can use 2119
keywords in an Informational document so that someone following the spec
gets the same behavior as someone else who follows the spec.

> 
> 
>>> All the above said, there are many documents from different areas where
>>> we have std track RFCs which "do not affect interoperability". e.g. TCP
>>> congestion control, TCPs initial RTO, etc. which, from your pov, should
>>> be informational?
>>
>> I'm happy to extend "interoperability" to mean "an individual host won't
>> screw up the net for everybody else, even if it's not directly
>> communicating with it." 
> 
> That's not interoperability, but a different goal. At that point, you're
> doing your own thing rather than the Section 6 of RFC2119 you're quoting.
> 
> 
>> Perhaps 6410 has simply done away with the whole notion of what it is to
>> standardize things. Maybe I'm in the rough. But I think local
>> configuration options and ways to do things that are not about
>> interoperably communicating across the Internet have no place in the
>> standards track.
> 
> If the "local policy" results in a high number of collisions, which
> subsequently result in a high number of retries, you might find that the
> local policy now has interoperability implications.
> 
> It's entirely local policy if it the whole thing relies on your node.
> But when it comes to IIDs, they are required to be unique. And that's
> not "local" anymore (or not "local to the host", at least).

But DAD helps with uniqueness.

Regards,
Brian