Re: IP Security......

Scott Bradner <> Mon, 20 March 1995 04:01 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa10416; 19 Mar 95 23:01 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10412; 19 Mar 95 23:01 EST
Received: from by CNRI.Reston.VA.US id aa15244; 19 Mar 95 23:01 EST
Received: from by IETF.CNRI.Reston.VA.US id aa10404; 19 Mar 95 23:01 EST
Received: from by IETF.CNRI.Reston.VA.US id aa10400; 19 Mar 95 23:01 EST
Received: (from sob@localhost) by (8.6.9/8.6.9-MT2.02) id XAA03932 for iesg@IETF.CNRI.Reston.VA.US; Sun, 19 Mar 1995 23:04:57 -0500 (EST)
Date: Sun, 19 Mar 1995 23:04:57 -0500
X-Orig-Sender: iesg-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Scott Bradner <>
Message-Id: <>
To: iesg@IETF.CNRI.Reston.VA.US
Subject: Re: IP Security......

from rfc 1602

      Specifications not on the standards track are labeled with one of
      four off-track maturity levels: "Prototype, "Experimental",
      "Informational", and "Historic".  There are no time limits
      associated with these non-standard track labels, and the documents
      bearing these labels are not Internet standards in any sense.  As
      the Internet grows, there is a growing amount of credible
      technical work being submitted directly to the RFC Editor without
      having been gone through the IETF.  It is possible that such
      outside submissions may overlap or even conflict with ongoing IETF
      activities.  In order for the best technical result to emerge for
      the community, we believe that the such outside submissions should
      be given the opportunity to work within IETF to gain the broadest
      possible consensus.

      It is also possible that supporters of a view different from the
      IETF may wish to publish their divergent view.  For this reason,
      it is important that, ultimately, authors should have the
      opportunity to publish Informational and Experimental RFCs should
      they wish to.  However, it is also possible that this could open a
      loophole in which developers could try to bypass the IETF
      consensus process completely by publishing an Informational RFC
      (and relying on the prestige of the RFC series to gain community
      support for their document).

      For all these reasons, the IESG and the RFC Editor have agreed to
      the following policy for publishing Info and Exp RFCs:

      1.   The RFC Editor will bring to the attention of the IESG all
           Informational and Experimental submissions that the RFC
           Editor feels may be related to, or of interest to, the IETF

      2.   The IESG will review all such referrals within a fixed length
           of time and make a recommendation on whether to publish, or
           to suggest that the author bring their work within the IETF.

      3.   If the IESG recommends that the work be brought within the
           IETF, but the author declines the invitation, the IESG may
           add disclaimer text into the standard boilerplate material
           added by the RFC Editor (e.g., "Status of this memo").