[ih] Internet Draft: when and why exactly 6 months?

[Ted Faber]

On Tue, Aug 21, 2001 at 10:45:22AM +0700, Rahmat M. Samik-Ibrahim wrote:
> However, it does not say anything about when and why
> 6 months. Why not 5 or 9 months (ca. 1 or 2 IETF meeting 
> intervals)?

I don't know why 6 months was picked (I suspect because it's big and
round), but it is an upper bound on the life of an ID.  If I write an
ID on the history of IDs and decide I want to change it to a history
of all IETF docs, I can do so at my whim.  This paragraph in all IDs (
that I copied from http://ietf.org/ietf/1id-guidelines.txt) describes
their lifetime :

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.

In other words, the *longest* that an ID can exist for is 6 months.

> 
> BTW, 
> * I consider anything before mid 1990s (when .com < .others)
>   as internet pre-history.

How nice to know I'm pre-historic.

> * There are some (many?) "recycled expired I-Ds" that become 
>   RFC after reincarnation. Example: BCP-1.

It's certainly possible to have an idea that's before its time, write
up an ID or 2 and have them expire for lack of interest.  Then later
events make the idea feasible, and the old text is recycled into an
RFC.  "Before its time" can be a technical or political phenomenon.

I don't know what happened with the ID you mention, but that's one
possibility.  There are many others.  

IDs are very human artifacts.  They can refelect an organized drive
for consensus, or some whack-o's idea he had in the shower one
morning.  Ultimately, though they're the scribbled notes on the
coctail napkins of Internet design, just formatted with troff.  Don't
look for too much more there.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20010821/98723ce1/attachment.sig>