RFC 1871 (rfc1871) - Page 2 of 4
Addendum to RFC 1602 -- Variance Procedure
Alternative Format: Original Text Document
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