Subject: [newtrk] Re: Historic (Re: List of Old Standards to be retired)

From: Bob Braden <[email-masked]>
Date: Sat, 18 Dec 2004 11:51:56 -0800 (PST)

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

Bob Braden

  *> The definition "Historic = Bad" is a change that has been encouraged by the 
  *> practice of not routinely making documents Historic.
  *> 
  *> This is, to my mind, no more sensible than the twisting of "Experimental = 
  *> Kiss of Death" that was the vogue some years ago, which we seem to have 
  *> successfully untwisted.
  *> 
  *> I think it makes sense for Historic to mean what RFC 2026 said it was.
  *> And if it does not, we should explicitly decide to say otherwise.
  *> 
  *>                   Harald
  *> 
  *> 
  *> 
  *> _______________________________________________
  *> Ietf mailing list
  *> [email-masked]
  *> https://www1.ietf.org/mailman/listinfo/ietf
  *> 
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 19 Dec 2004 12:39:19 +0100

--On lørdag, desember 18, 2004 11:51:56 -0800 Bob Braden <[email-masked]> 
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?
>   *>

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

.

---

From: John C Klensin <[email-masked]>
Date: Sun, 19 Dec 2004 16:47:39 -0500

--On Sunday, December 19, 2004 12:39 PM +0100 Harald Tveit 
Alvestrand <[email-masked]> wrote:

> --On lørdag, desember 18, 2004 11:51:56 -0800 Bob Braden
> <[email-masked]> 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?
>>   *>
>> 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.
>

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

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 20 Dec 2004 22:05:30 -0600

Not to be a drudge about this, but my copy of 
http://www.ietf.org/rfc/rfc2026.txt still has "3.3 Requirement Levels" 
in it, containing exactly the text John referred to.

So we haven't gotten rid of this aspect of our standards process, 
we're just ignoring it enthusiastically.

I keep oscillating at about 33 1/3 RPM between

o we've really gotta update 2026, and

o 2026 is so hopeless that regrouping around ISDs and acting like we 
never heard of 2026 is a perfectly reasonable strategy...

I really DON'T want to answer this question the week before a bunch of 
major holidays, but I keep wondering - if we were doing BCPs, would we 
Cruft 2026 into Historic?

... and if not, one wonders why not ...

Spencer

From http://members.aol.com/h4texas/undouble.htm: There is a story 
that when drilling his militia company during the Black Hawk War, 
Captain Abe Lincoln marched his men up to a fence with a narrow gate 
and tried to remember what to do. For the life of him, the story goes, 
he could not think of the commands to march his unit through the gate. 
At last he ordered, "This company will fall out and assemble in one 
minute on the other side of that fence!"

... and Spencer is wondering if this is how we're going to "get 
through" 2026 ...

-----------------------------------------------------------

   john 

.