1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc1871.txt b/doc/rfc/rfc1871.txt
new file mode 100644
index 0000000..d37a0fe
--- /dev/null
+++ b/doc/rfc/rfc1871.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                          J. Postel
+Request for Comments: 1871                                           ISI
+Updates: 1602, 1603                                        November 1995
+BCP: 2
+Category: Best Current Practice
+
+
+               Addendum to RFC 1602 -- Variance Procedure
+
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document describes a modification to the IETF procedures to
+   allow an escape from a situation where the existing procedures are
+   not working or do not seem to apply.  This is a modification to the
+   procedures of RFC 1602 and 1603.
+
+Introduction
+
+   The current IETF procedures are documented in "The Internet Standards
+   Process -- Revision 2" [1], and "IETF Working Group Guidelines and
+   Procedures" [2].
+
+   There may be situations where following the procedures leads to a
+   deadlock, or there may be situations where the procedures provide no
+   guidance.  In these cases it may be appropriate to invoke the
+   variance procedure described below.
+
+   A revision of the rules specified in RFC 1602 is underway, but may
+   take some time. This document describes an interim amendment to RFC
+   1602, to avoid having to wait for this major revision in a state of
+   paralysis.
+
+Guiding Principles
+
+   Any variance from following the written rules must be a public
+   process with opportunity for all concerned parties to comment.
+
+   The variance procedure should be similar to existing mechanisms and
+   involve existing bodies.
+
+
+
+
+
+Postel                   Best Current Practice                  [Page 1]
+
+RFC 1871                   Variance Procedure              November 1995
+
+
+The Variance Procedure
+
+   Upon the recommendation of the responsible IETF Working Group (or, if
+   no Working Group is constituted, upon the recommendation of the
+   responsible ad hoc committee), the IESG may enter a particular
+   specification into, or advance it within, the standards track even
+   though some of the requirements of section 5 of RFC 1602 have not or
+   will not be met. The IESG may approve such a variance, however, only
+   if it first determines that the likely benefits to the Internet
+   community from entering or advancing the specification on the
+   standards track are likely to outweigh the costs to the Internet
+   community that result from noncompliance with section 5.  In
+   exercising this discretion, the IESG shall consider (a) the technical
+   merit of the specification, (b) the possibility of achieving the
+   goals of the Internet standards process without granting a variance,
+   (c) alternatives to the granting of a variance, (d) the collateral
+   and precedential effects of granting a variance, and (e) the IESG's
+   ability to craft a variance that is as narrow as possible.  In
+   determining whether to approve a variance, the IESG has discretion to
+   limit the scope of the variance to particular parts of section 5 and
+   to impose such additional restrictions or limitations as it
+   determines appropriate to protect the interests of the Internet
+   community.
+
+   There are five aspects that are involved in the variance procedure:
+   (1) detecting the problem, (2) proposing a solution, (3) public
+   review, (4) accepting the solution, and (5) an appeal process.
+
+   1. Detecting the problem
+
+   The responsible IETF Working Group, (or, if no Working Group is
+   constituted, the responsible ad hoc committee), may bring the matter
+   of a variance before the IESG.
+
+   2. Proposing the solution
+
+   The IESG is responsible for proposing the solution.
+
+   The IESG may enter a particular specification into, or advance it
+   within, the standards track even though some of the requirements of
+   section 5 of RFC 1602 have not or will not be met.
+
+   In exercising this discretion, the IESG shall consider (a) the
+   technical merit of the specification, (b) the possibility of
+   achieving the goals of the Internet standards process without
+   granting a variance, (c) alternatives to the granting of a variance,
+   (d) the collateral and precedential effects of granting a variance,
+   and (e) the IESG's ability to craft a variance that is as narrow as
+
+
+
+Postel                   Best Current Practice                  [Page 2]
+
+RFC 1871                   Variance Procedure              November 1995
+
+
+   possible.
+
+   The IESG should consult WG chair and appropriate WG members as
+   needed, and the wishes of the WG should also be taken into account.
+
+   3. Public review
+
+   There shall be an extended Last Call for public review.
+
+   4. Accepting the solution
+
+   The IESG is responsible for accepting the solution, and incorporating
+   comments from the Last Call.
+
+   The IESG may approve such a variance, however, only if it first
+   determines that the likely benefits to the Internet community from
+   entering or advancing the specification on the standards track are
+   likely to outweigh the costs to the Internet community that result
+   from noncompliance with section 5 of RFC 1602.
+
+   In determining whether to approve a variance, the IESG has discretion
+   to limit the scope of the variance to particular parts of section 5
+   of RFC 1602 and to impose such additional restrictions or limitations
+   as it determines appropriate to protect the interests of the Internet
+   community.
+
+   5. The appeal procedure
+
+   The IAB is responsible for hearing and deciding appeals.
+
+Discussion
+
+   When the IESG (on reviewing a recommendation for a variance) the has
+   determined that there is a situation where the existing written rules
+   do not apply or lead to a deadlock, the IESG may propose a solution
+   to the problem.
+
+   The solution may be developed by the IESG or suggested to the IESG.
+
+   The solution may either (1) decide the particular instance of the
+   matter, or (2) define a procedure for resolving matters of this kind.
+
+   In any case, the proposed solution will be documented in an Internet
+   Draft and subjected to an extended Last Call.
+
+   Depending on the results of the Last Call, the IESG will either
+   accept the solution; or revise the proposal, update the Internet
+   Draft, and initiate another extended Last Call.
+
+
+
+Postel                   Best Current Practice                  [Page 3]
+
+RFC 1871                   Variance Procedure              November 1995
+
+
+   When the IESG accepts a solution the Internet Draft shall be
+   forwarded to the RFC Editor and published as an RFC.
+
+   The IAB shall be available to hear and decide on appeals of the use
+   this variance procedure.
+
+Acknowledgements
+
+   The contributions of the IAB and the IESG -- and Brian Carpenter,
+   Paul Mockapetris, Christian Huitema, Robert Elz, Frank Kastenholz,
+   and Scott Bradner, in particular -- are gratefully acknowledged.
+   Scott deserves special credit for working with the lawyers to get
+   that first paragraph in the "The Variance Procedure" section.
+
+References
+
+   [1] IAB, and IESG, "Internet Standards Process -- Revision 2", RFC
+       1602, IAB and IESG, March 1994.
+
+   [2] Huizer, E., and D. Crocker, "IETF Working Group Guidelines and
+       Procedures", RFC 1603, SURFnet and Silicon Graphics, Inc., March
+       1994.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+Authors' Address
+
+      Jon Postel
+      USC - ISI, Suite 1001
+      4676 Admiralty Way
+      Marina del Rey, CA  90292-6695
+      Phone: 310-822-1511
+      EMail: postel@isi.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                   Best Current Practice                  [Page 4]
+