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

[Pete Resnick <[e-mail]>]

On 1/22/14 8:07 PM, Thomas Narten wrote:

> Glad this is only a comment, but I think if one argues this document
> shouldn't be PS, it opens up the door to saying a rather substantial
> number of the standards the IETF has produced in the past should not
> be on standards track either.
>
> I think its worth noting that the classifications we have
> (standard/info/bcp/applicability statements) have a very course
> granularity. There are lots of individual "things" that don't fit
> cleanly into exactly one category, if you start looking closely.
>    

We're now off into "the bigger picture", but I do think we've been 
pretty lousy about deciding once and for all what we mean by certain 
documents. Coarse-grained is fine, and I don't have a problem with us 
picking "the best fit" when a document isn't clearly one or the other. 
The problem is that we are now in a state of assigning states for 
marketing reasons ("people will take this more seriously if we make it a 
standard") rather than to improve how we do things on the Internet. I 
think it weakens the document series generally to be calling things 
standards that aren't and vice-versa. With documents that should be 
Informational that are called standards, people start turning into the 
protocol police ("The document says you MUST have a button to switch 
this feature off, and you don't expose that in the UI; you are required 
by the IETF to fix your UI") and people start viewing the things that 
*are* interoperability standards as conformance documents. It lowers the 
usefulness and relevance of our protocols.

The problem is not where any given document goes. It's that we haven't 
been good about defining the categories clearly.

> For example, the IETF doesn't really (usually) produce informational
> documents that people go off and implement. If you are going to code
> something, then presumably you want all implementations do things in a
> certain way (so they exhibit important behavior). And you want to be
> able to verify that implementations were able to implement from the
> spec (perhaps using MUST/SHOULD type language - or perhaps not). We
> get that with standards track documents. We have no mechanism in our
> processes for reviewing Informational RFCs and whether they were
> implementable and meet our criteria for being called a standard. Isn't
> that one of the core reasons the IETF exists?
>    

To a certain extent. It is true that one of the aspects of 
standardization is implementability. But we are supposed to judge 
implementability from a standpoint of interoperability. In fact, we are 
quite clear that it is *independent* implementation is key: We *don't* 
want people implementing things exactly the same way, because that makes 
for brittle implementations. What we want is for the network-visible 
output of those implementations to do certain things, but we want the 
implementations to be independent and we ignore their local (i.e., 
non-networked) behaviors.

So while I agree that we usually don't produce informational document 
that people go off and implement, I would add that we usually don't (and 
generally shouldn't) produce standards track documents that prescribe 
specific local implementation details that do not affect 
interoperability. In those instances we think that a local 
implementation problem is important to explain ("Every implementation 
ends up needing to do X, and we've seen that they never seem to get it 
right, so here's a a way to do it"), even though we are not saying it is 
necessary for interoperability, I think an Informational document is 
appropriate if it's going to be a separate document. (Sometimes a BCP is 
also reasonable, if we find that we need to give policy or operational 
guidance to deployment.)

> Thus, for IETF WGs, I would say that the vast majority of stuff that
> is produced that describes an implementation should be on standards
> track.
>    

I agree with the general statement. The issue is that there are a bunch 
of things about local implementation details that I don't think we 
should be making normative statements about at all. When we do want to 
make statements about local implementation details, I don't think those 
statements should be on the standards track.

> This document fits squarely in that category.
>
>    
>> 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.
>>      
> Sure it may.

How will it?

> If we want the IETF "standard" to be "generate addresses
> however you want, hopefully they will work, but it's not the business
> of an IETF standard to tell you how to ensure you are doing things
> right", then I guess publishing this document as informational (and
> giving it the same status as an RFC such as "FooBar's Proprietary
> Protocol") would be the way to go.
>    

I am curious about the "doing things right" bit. If doing things right 
is simply "it must be stable, private, and unique", and we're giving an 
example about how to get such a thing, peachy. But this document does 
more than that. It says, for example, that the DAD_Counter MUST start at 
zero and go up. But of course my implementation doesn't need to do that. 
I could plausibly start high and work my way down (if I were being 
recalcitrant). I could also come up with something nifty other than the 
Prefix to put into my generator. And if either of these things works 
better in my implementation (because it's more efficient, or I'm in a 
weird local environment that makes doing it the way the document 
describes hard) and I'm still able to produce stable, private, and 
unique addresses, that's fine and the IETF can take their standard and 
piss-off.

> But be careful what you wish for. I'm pretty sure the IPv6 addressing
> architecture shouldn't be on standards track per your argument.  And
> maybe the original SLAAC spec shouldn't be either. Beware the slippery
> slope.
>    

Well, if this document was saying, "You MUST have addresses that are 
private because doing otherwise exposes information and potentially 
harms things" and therefore updated the old way of doing address 
selection, I would be more inclined to say that this is a reasonable as 
a standard because it's saying that this is the one way we've all agreed 
to accomplish this and other ways are bad. But from what I understand, 
the WG is not inclined to do that.

>> Anyone can accomplish the same task in a number of
>> different ways. This is just a nice method to use if someone wanted to
>> use it. This should just be an Informational document explaining a
>> nice way to generate stable, private, mostly unique addresses without
>> all of the MUSTs and SHOULDs, which are not interoperability
>> requirements in the first place. Standardizing this is silly in the
>> extreme.
>>      
> Others have commented on this, but it is perfectly fine (and has been
> in the IETF for a long time) to use MUST/MAY type language in
> informational documents. Especially ones that describe protocol
> details. Why bring up this Red Herring?
>    

It's not the existence of the MUSTs and SHOULDs, it's what they are 
requiring in this document. They are not requiring things that are 
required for interoperation or to prevent harm.

pr

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