Date: Sun, 08 Sep 2002 18:41:22 +0200
From: Harald Tveit Alvestrand <harald(_at_)alvestrand(_dot_)no>
Message-ID: <878248073(_dot_)1031510482(_at_)localhost>
| > "[A]ny P-header used outside of a very restricted research or
| > teaching environment (such as a student lab on implementing
| > extensions) MUST meet those requirements and MUST be documented in
| > an RFC and be IANA registered."
| If that's extortion, then so be it.
Harald, you missed my point. It wasn't the restrictions on implementors
I was meaning - that implementors shouldn't use headers except where
documented as... is just fine, and the effects that has on conformance
and what they should claim, just as you said.
There's nothing unusual in any of that.
But read the above quote again. What it says is "MUST meet those
requirements and" ...
That is, the IETF (according to this) cannot specify a new P-header
unless it meets the requirements in that doc (or if they do, implementors
are still not free to use it, even if it is documented in an RFC and
registered by IANA. That is, they can't if they want to remain
conformant, of course, and often, they do.
It is extortion aimed at the IETF community that I am worried about,
and what's more, I have seen this work. Some WG (perhaps the same one
that published an earlier doc, perhaps a different one) looks at an RFC
which says what can or cannot be done, and without further thought, rejects
a proposal, because it does not conform with some rule laid down by some
earlier doc (which most likely hadn't even considered the situation
now being proposed).
I take Adam's point that this is just an I-D, and it is, in this particular
case, to the authors of that I-D (and/or its WG) that this point should be
made (it isn't a WG I normally have anything to do with at all).
The point for the wider community is that there is *nothing* in an RFC that
can't be changed by a later RFC. And there should not be language in any
RFC that attempts to prohibit that. The way to avoid future possible changes
perceived as being not in the best interests of the protocol, is to explain
why they would be detrimental, not just to prohibit them (or pretend to).
Of course, when it is noticed that something is contradicting an earlier
RFC (and it always is in the cases here where it matters - if people don't
notice and just do it anyway, that's a completely different problem)
that should give rise to caution - one should ask why the restriction is
there, etc, and consider carefully before ignoring it. But after having
done that, all WGs should be aware that they're free to change anything in
any protocol al all. IETF Last Call will often then raise objections of
course, so the attempt might end up failing. But if the arguments for the
change are good enough, then nothing any earlier RFC says, or claims must be
done, has any particular power to prevent the change.
kre