Re: IP Security......
Scott Bradner <sob@newdev.harvard.edu> Mon, 20 March 1995 04:01 UTC
Received: from ietf.nri.reston.va.us 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 ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15244; 19 Mar 95 23:01 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10404; 19 Mar 95 23:01 EST
Received: from newdev.harvard.edu by IETF.CNRI.Reston.VA.US id aa10400; 19 Mar 95 23:01 EST
Received: (from sob@localhost) by newdev.harvard.edu (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 <sob@newdev.harvard.edu>
Message-Id: <199503200404.XAA03932@newdev.harvard.edu>
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 community. 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").
- IP Security...... Mike O'Dell
- Re: IP Security...... stev
- Re: IP Security...... Jeffrey I. Schiller
- Re: IP Security...... Mike O'Dell
- Re: IP Security...... Jeffrey I. Schiller
- Re: IP Security...... John C Klensin
- Re: IP Security...... Christian Huitema
- Re: IP Security...... stev
- Re: IP Security...... Paul Mockapetris
- Re: IP Security...... Mike O'Dell
- Re: IP Security...... IETF NM-AD
- Re: IP Security...... Scott Bradner
- Re: IP Security...... Paul Mockapetris
- Re: IP Security...... Paul Mockapetris
- Re: IP Security...... John C Klensin
- Re: IP Security...... Jeffrey I. Schiller
- Re: IP Security...... Christian Huitema