Date: Mon, 16 Sep 2002 03:57:34 +0200
From: Harald Tveit Alvestrand <harald@alvestrand.no>
Message-ID: <44304256.1032148654@localhost>
| Blithely ignoring a conclusion because it was drawn a year ago is as
| harmful (IMHO) as blithely ignoring new ideas because they don't conform to
| the "received wisdom".
Absolutely.
The problem is that when this happens, it can be difficult, at best,
to
| and undertake
| the effort to *change* that rule, because it no longer fits the real world.
Updating some earlier RFC is most likely not in the WG's charter, especially
not if the doc in question originated from some entirely different WG.
When faced with that situation, if the rule really was "that the earlier doc
had to be changed explicitly", then however good the reasons for ignoring some
earlier rule in this particular case, no-one would bother - some other
workaround (possibly with other problems) is going to be found instead.
That is, doc X says we cannot do Y, it is ultra vires for us to change X,
hence, we cannot do Y - we have to do something else instead.
Perhaps fortunately, the rule isn't like that - we have nothing in our
procedures that claims that in the case of a dispute, older RFCs win over
new ones, and lacking anything explicit that way, the rule has to be that
new ones win if there's a dispute. After all, all of these docs are,
when eventually processed, docs issued by the same body (the IETF as a
whole), and when that happens, newer requirements/specifications implicitly
override earlier ones (especially so when the new one is quite specific,
and the old one general, which is the kind of situation here).
Because of that, WGs know that they can go ahead and specify something
that overrides some earlier rule. (That they also sometimes do that
without realising what they're doing is another problem, a quite
different one, as I mentioned in an earlier message).
Note that we do this all the time in "normal" cases without any problems.
A doc might say that "only x y and z are valid here", then some other doc
comes along and adds "and w is valid as well, and means ...".
That kind of thing causes no problems (assuming the extension is
well designed, etc, of course - no interpretation problems I mean).
But when the first doc says "only x y and z are valid, and no others
are ever allowed to be added" (or constrains the method by which more
are added, in such a way that it pretends to limit the IETF) then some
other doc comes along and says "and w is valid as well", then there's
a problem, because according to the first doc, the 2nd one is irrelevant.
That is, there's no way anyone can conform to both.
Fortunately, the fix is easy - we simply don't publish any docs that
pretend that they specify what is permitted to be done in the future,
by the IETF, other than our procedures documents of course (essentially
our constitution, which can itself be modified, and cannot claim that it
can't be).
Regular docs can specify what is required now, and if they want, can also
specify an extension mechanism by which additions can be made. Anything
which pretends to limit the way the IETF processes future documents should
be discarded, or the doc not published.
The restrictions don't, and can't, work anyway, putting them there just
causes problems.
But, once again, by all means have docs explain why future people might
want to act in a certain way, and before approving something which acts
differently, we probably want to take a close look at why. But if we
do that, and are satisfied, let's not complicate matters.
Note: it is OK to require no extensions without explicit IETF action.
In the kind of case that seems to be happening here, that means that
the original community get to look at the proposed change, and object
to it, because of whatever reasons are currently leading the WG to
try and include language to limit the IETF in the future. If a doc
were to propose something, which would run into the problems that the
restriction is trying to avoid, I'd expect someone to object (and if the
reasons were spelled out in the doc, I'd expect that, way off into the
future). If there are objections like that, backed by good reasons,
and no satisfactory answers, then the new doc should be killed at IETF
last call time (killed or modified). But if there are no objections
(or any that are made are answered to the community's satisfaction)
then that's all that we need, to allow the change to proceed.
kre