From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1871.txt | 227 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 227 insertions(+) create mode 100644 doc/rfc/rfc1871.txt (limited to 'doc/rfc/rfc1871.txt') 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] + -- cgit v1.2.3