Subject: [newtrk] Sunset intervals for specifications?

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 12 Dec 2003 06:52:45 -0600

This ghastly thread (don't ask, if you didn't see it) on [email-masked]
did produce one interesting point.

We don't seem to have any notion (beyond moving RFCs to Historic,which
we've done about 75 times, or about as often as we promote something
to Full Standard) of saying "this is too old to care about
interoperability with".

In some sense, this is OK. If someone is running full standard TCP
(RFC 793) with no additional mods, everything still sort of works
today.

In some sense, it is not OK, because RFC 793 does not include adaptive
congestion control (remember, adaptive RTO and slow start were *added*
to TCP, right)?

So our current process makes it look like people who are running RFC
2581, a Proposed Standard, aren't doing the "safe for widespread
deployment" thing, while anyone who was still running unmodified RFC
793 is being responsible. We know this isn't true, but it just looks
silly.

If we actually produce "standards", shouldn't we be thinking about
sunset intervals for specifications?

Spencer

----- Original Message ----- 
From: "Anthony G. Atkielski" <[email-masked]>
To: "IETF Discussion" <[email-masked]>
Sent: Friday, December 12, 2003 1:15 AM
Subject: Re[12]: www.isoc.org unreachable when ECN is used

>
> But ECN has not always been a standard.  If all RFCs had been
> simultaneously written forty years ago, it would be reasonable to
speak
> of one organization or another not respecting standards because it
did
> not adhere to a given RFC.  But in the real world, RFCs have been
> written over time, and whether or not an entity is conformant cannot
be
> determined without a reference to time.  Publishing a new standard
does
> not automatically make the entire planet non-conformant.
>
> I suspect that ISOC's site is conformant up to a certain point, but
not
> beyond ... like most sites on the Internet.  The wise developer
allows
> for the impossibility of instantaneous updates in the development
and
> implementation of new standards.
>
>
> _______________________________________________
> This message was passed through [email-masked],
which is a sublist of [email-masked]. Not all messages are passed.
Decisions on what to pass are made solely by IETF_CENSORED ML
Administrator ([email-masked]).

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: John Leslie <[email-masked]>
Date: Fri, 12 Dec 2003 11:26:54 -0500

> to Full Standard) of saying "this is too old to care about

   Actually, "Historic" is a warning that implementing from that RFC
is probably a bad idea. It's not necessarily related to age.

> (RFC 793) with no additional mods, everything still sort of works

   In the absence of congestion, etc., yes...

> 793 is being responsible. We know this isn't true, but it just looks

   No doubt it looks "silly" to some; but mostly it makes us look like
bumbling amateurs when we claim to be a "standards" organization.

> sunset intervals for specifications?

   Sunset intervals really isn't the question. (And it's wrongheaded
to think that we can predict years in advance when a particular RFC
will deserve to transition to "historic".)

   The issue is that nobody has responsibility to update our "standards"
to refect the actual usage in the current Internet.

   We've always tried to operate with a good deal less formality than
most "standards" organizations: that's fine when we claim to be engaged
in "engineering"; but it's not going to work if we claim "standards"
are our primary purpose.

--
John Leslie <[email-masked]>
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: David Meyer <[email-masked]>
Date: Fri, 12 Dec 2003 08:35:25 -0800

>> is probably a bad idea. It's not necessarily related to age.

	The Historic mechanism can also be used to remove (the
	need for) code for a feature that is not really in use
	anywhere, but is still widely implemented (because RFP
	checklists include the RFC, or some such). In any event,
	that is how I've used the "move to Historic" mechanism in
	the past e.g. RFCs 3166 and 3167.  

	Dave
.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 13 Dec 2003 00:31:22 -0600

Sorry for being more precise than I should have been...

> will deserve to transition to "historic".)

I could have been trying to raise the issue of periodic review of our
standards, and that wouldn't be wrong, but what I was actually trying
to say without being clear enough was that we should be thinking about
how standards might go away/be deprecated/be obsoleted..

Right now, the answer is that most of them never will "go away", so
the Internet will get cruftier and cruftier, and we'll be able to do
less and less as complexity rises.

Every place I've ever worked had a policy (not always the same one)
about how many releases back we guaranteed interoperability, and the
number was never "all the way back to the invention of zeros and
ones".

John was able to extract something coherent out of my posting, though.
Way to go!

Spencer

.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Dec 2003 08:31:33 -0800

Spencer,

SD> I could have been trying to raise the issue of periodic review of our
SD> standards, and that wouldn't be wrong,

In fact that would be quite a reasonable idea.  However, this is exactly
the sort of activity that we are proving very bad at doing.  It is
triggered by formality rather than a community "pull" to deal with an
immediate need.  We don't even pay attention to immediate review
requirements, like milestones.

SD> but what I was actually trying
SD> to say without being clear enough was that we should be thinking about
SD> how standards might go away/be deprecated/be obsoleted..

That's exactly what Historic is for.  The only issue is being diligent
at using it for obsolete or failed standards.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

.