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

[Pete Resnick <[e-mail]>]

On 1/22/14 2:37 PM, Fernando Gont wrote:
> Hi, Pete,
>
> Thanks so much for your feedback! -- Please find my responses in-line...
>
> On 01/22/2014 04:20 PM, Pete Resnick wrote:
>    
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> 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.

> In addition, the document itself has requirements when it comes to
> things you MUST or SHOULD do... otherwise, the mechanism doesn't work as
> expected.
>    

Section 6 of 2119 is a good read.

> 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 why I think it's reasonable to include 
congestion control, some security mechanisms, etc. But if the only 
reason I'm doing something a particular way is for *my* privacy, or *my* 
convenience, or to accomplish a local task on my system, that doesn't 
need standardized documentation requiring (eventually) two independent 
interoperable implementations.

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. Otherwise, we're just a publication house for 
interesting Internet technologies. I'm not interested in being that.

So I stand by my claim: This should not be on the standards track.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]