Movatterモバイル変換

Network Working Group                                          J. PostelRequest for Comments: 1871                                           ISIUpdates:1602,1603                                        November 1995BCP: 2Category: Best Current PracticeAddendum toRFC 1602 -- Variance ProcedureStatus 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 ofRFC 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 inRFC 1602 is underway, but may   take some time. This document describes an interim amendment toRFC1602, 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 1995The 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 ofsection 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 withsection 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 ofsection 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 ofsection 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 asPostel                   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 withsection 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 ofsection 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",RFC1602, 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.eduPostel                   Best Current Practice                  [Page 4]