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

[Fernando Gont <[e-mail]>]

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, 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.



>> 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).

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