--On lørdag, desember 18, 2004 11:51:56 -0800 Bob Braden <braden@xxxxxxx> wrote:
*> >> *> > This must be some new redefinition of the meaning of a Historic RFC. *> > In the past, it meant "don't do it this way anymore, we no longer *> > recommend it, there's another way to accomplish the same goal". *> > So, for the PPP items listed, what's the better way to accomplish the *> > same goal? *> *> No, it's the old definition of Historic. *>
Harald,
I am puzzled by your comment. I believe that Bill Simpson is correct about the "old" (historic) definition of Historic category, defined by Jon Postel. Jon believed that if you have a standard defining interoperability, it is ALWAYS a standard unless there is a compelling reason to warn people away. The IETF can change the meaning of Historic, but let's not change history.
With all respect to Jon Postel - the IETF's meaning of Historic is defined by reference to IETF consensus, not to Jon Postel's opinion.
We may be confused by different meanings of "old" - I was referring to 1994.
Shows how young I am, I guess :-)
Harald, I don't think it is because of your tender age, but it seems to me that "defined by reference to IETF consensus" puts us into dangerous territory. The justification for this de-crufting effort seems to me to be (i) finding a relatively lightweight way to get what we are actually doing aligned with the requirements of 2026 and (ii) begin more clear to relative "outsiders" about just what we intend and are encouraging.
That suggests two things to me...
(1) A definition, whether in 2026 or earlier, or developed by some newer IETF consensus process, is useful only if the definition itself is absolutely clear. We aren't there any more, if ever we were. The language in 2026 isn't clear enough to prevent several of us from disagreeing about what it really means. There hasn't been a clear statement and a consensus call on it in the last decade or more. We aren't making progress if our definition "by IETF consensus" requires a royal assertion of what that consensus is, without a clear basis in IETF consideration.
(2) Part of what has gotten us into this mess is that we got rid of the old "required"/ "recommended"/ "not recommended" categories that were orthogonal to standards maturity levels. Once upon a time, we could say "X is a standard because it is interoperable and widely deployed, but we have concluded that it stinks so no one should be implementing and relying on it". That is "standard, not recommended". Too much of the discussions of the last few weeks feel to me like an attempt to conflate (or avoid conflating) "Historic" with "Not recommended" and that just doesn't work very well in the edge cases... and there are lots of edge cases.
john
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf