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

[Thomas Narten <[e-mail]>]

Hi Pete.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------

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.

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?

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.

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

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.

> 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?

Thomas