[rfc-i] citing historic internet drafts

Bob Braden braden at ISI.EDU
Thu Oct 16 11:59:30 PDT 2008

  *> I hear from the RFC Editor that the current policy is:
  *>        Non-normative references to Internet Drafts are allowed, but they
  *>        must take the following restricted form: the author(s), the title,
  *>        the phrase "Work in Progress", and the date; for example:
  *>                 [doe13] Doe, J., "The Deployment of IPv6",
  *>                         Work in Progress, May 2013. -- 
  *> <http://www.rfc-editor.org/rfc-style-guide/rfc-style-manual-08.txt>

Probably nobody cares, but some might be interested in how we got
here.  When the IETF was formed by the IAB around 1984 and Phil Gross
became chair, he felt a need to create a series of informal working
drafts within the IETF.  This caused a minor fight with the rest of the
IAB, which was very concerned that the RFC series remain the sole
document series for the Internet (this prejudice was based upon
experience ... when the ARPAnet research project morphed into the
Internet research project, a new document series, IENs
(www.rfc-editor.org/rfc/ien/) was created for the new Internet stuff,
while ARPAnet stuff continued to be published in the RFC series.  That
resulted in considerable confusion, so after a few years the IAB/Jon
Postel/ARPA decided to kill the IENs and continue RFCs as the sole
publication channel.)  Phil and the rest of the IAB reached a
compromise: the IETF document series would be called "... Draft", to
emphasize its ephemeral nature, and each Internet Draft would vanish
after 6 months.

(Of course, in today's Internet, nothing ever vanishes, and the
Internet Draft series has effectively become another document
series, albeit without the "guaranteed forever" quality of RFCs.)

Jon Postel adopted the convention of "Work in Progress" as an
effectively meaningless designation for Internet Draft references.
Since Internet Drafts vanish (supposedly) 6 months after they
are published but RFCs last forever, any additional information
in an I-D reference in an RFC could become false at a later time.

The RFC Editor tries to avoid publishing information that will
become false at some time in the future.  Thus, we try to avoid
URL references that do not appear to be reasonably stable.
We often fail in this, as one can easily discover by writing
a script that plucks references out of RFCs, extracts any
URLs, and tries to access them.  The last time I tried it,
approximately 1/2 of the published URLs were already undefined.
But we try.

An aside: the cases that Julian cites for wanting more explicit
references to Internet Drafts could be handled another way:  simply
publish the Drafts as RFCs and reference them as RFCs.  Not all RFCs
are standards track, and in fact the independent submission stream is
often used to publish documents that WGs have considered and for some
reason did not pursue, but which were thought to be of some historic
interest.  Sometimes individual submissions in the IETF stream are used
the same way.

In the days of Jon Postel, the RFC series was not only a channel for
standards publication by the IETF, but more broadly a repository of
ideas, hopefully good ideas.  How often do we reinvent the same
wheels?  How often is it worthwhile to re-examine ideas that earlier
were rejected?  A case in point that arose during yesterday's
NANOG meeting is variable-length IP addresses (but let's NOT
go there on THIS list, please!)

Bob Braden

More information about the rfc-interest mailing list