On Aug 10, 2013, at 8:32 AM, Hadriel Kaplan
<hadriel(_dot_)kaplan(_at_)oracle(_dot_)com> wrote:
I'm not saying that will happen in this case at all, but we shouldn't kid
ourselves that it doesn't matter. If it didn't matter, people wouldn't care
about labeling their IDs Informational or Experimental. People seem to
*want* the PS label, and I don't think it's because people want to upgrade to
an IS someday. [as an aside: that's what the 2-level RFC experiment should
teach us - that there is only 1 level that people care about, in practice]
It almost certainly will happen. But "we shouldn't do this because someone
might later on draw an incorrect conclusion about what we did" is just not a
valid argument against advancing the document to proposed standard. What it
is is an argument for understanding the IETF process so that when people make
assertions about this sort of thing, you can have a meaningful debate with them
and point at RFCs. Otherwise your working group can get sidetracked by the
ownership assertion problem, which as you are already aware can be very
damaging.
The reason we call things "proposed standard" is because we expect
interoperability. A thing that can't have or affect interoperability probably
isn't a "proposed standard." In this case, what we have is definitely a
proposed standard and not an informational document; the question is whether
it's a standard that will get IETF consensus.
I should point out that a lot of arguments have been raised here that don't
really affect consensus. The arguments to raise if you think a proposed
standard is a bad idea are technical arguments: "this won't work because of X"
or architectural arguments: "we shouldn't do this because there is a better way
to do it that fits better with the Internet architecture" or "this is
needlessly complicated for the use case we are trying to address."
Importantly, "we shouldn't do this because there's a proposed standard that
does something similar" is _not_ a valid argument; if the proposed standard is
technically or architecturally better, _that_ is the argument to raise. The
mere existence of the RFC is not an argument in itself.
Seriously, RFC 1958 is a good document to read if you are interested in this
issue. You might also want to read RFC 5218.
(Dave Thaler will know why I know to reference these two documents... :)