RFC 1871 (rfc1871) - Page 2 of 4

Addendum to RFC 1602 -- Variance Procedure

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