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: [email protected]
















Postel                   Best Current Practice                  [Page 4]


You are viewing proxied material from gopher.fnord.one. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.