The RFC Archive
 The RFC Archive   RFC 1871   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 1871

Addendum to RFC 1602 -- Variance Procedure

Last modified on Tuesday, November 28th, 1995

Permanent link to RFC 1871
Search GitHub Wiki for RFC 1871
Show other RFCs mentioning RFC 1871







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 top


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 top

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 top

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 top

Addendum to RFC 1602 -- Variance Procedure RFC TOTAL SIZE: 7747 bytes PUBLICATION DATE: Tuesday, November 28th, 1995 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 1871: The IETF Trust, Tuesday, November 28th, 1995
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement