As per Relevance of the word procedure, we have this rfc below:
Network Working Group J.
Request for Comments: 1871
Updates: 1602, 1603 November 1995
BCP: 2
Category: Best Current
Addendum to RFC 1602 -- Variance
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
This document describes a modification to the IETF procedures
allow an escape from a situation where the existing procedures
not working or do not seem to apply. This is a modification to
procedures of RFC 1602 and 1603.
The current IETF procedures are documented in "The Internet
Process -- Revision 2" [1], and "IETF Working Group Guidelines
Procedures" [2].
There may be situations where following the procedures leads to
deadlock, or there may be situations where the procedures provide
guidance. In these cases it may be appropriate to invoke
variance procedure described below
A revision of the rules specified in RFC 1602 is underway, but
take some time. This document describes an interim amendment to
1602, to avoid having to wait for this major revision in a state
paralysis
Guiding
Any variance from following the written rules must be a
process with opportunity for all concerned parties to comment
The variance procedure should be similar to existing mechanisms
involve existing bodies
Postel Best Current Practice [Page 1]
RFC 1871 Variance Procedure November 1995
The Variance
Upon the recommendation of the responsible IETF Working Group (or,
no Working Group is constituted, upon the recommendation of
responsible ad hoc committee), the IESG may enter a
specification into, or advance it within, the standards track
though some of the requirements of section 5 of RFC 1602 have not
will not be met. The IESG may approve such a variance, however,
if it first determines that the likely benefits to the
community from entering or advancing the specification on
standards track are likely to outweigh the costs to the
community that result from noncompliance with section 5.
exercising this discretion, the IESG shall consider (a) the
merit of the specification, (b) the possibility of achieving
goals of the Internet standards process without granting a variance
(c) alternatives to the granting of a variance, (d) the
and precedential effects of granting a variance, and (e) the IESG'
ability to craft a variance that is as narrow as possible.
determining whether to approve a variance, the IESG has discretion
limit the scope of the variance to particular parts of section 5
to impose such additional restrictions or limitations as
determines appropriate to protect the interests of the
community
There are five aspects that are involved in the variance procedure
(1) detecting the problem, (2) proposing a solution, (3)
review, (4) accepting the solution, and (5) an appeal process
1. Detecting the
The responsible IETF Working Group, (or, if no Working Group
constituted, the responsible ad hoc committee), may bring the
of a variance before the IESG
2. Proposing the
The IESG is responsible for proposing the solution
The IESG may enter a particular specification into, or advance
within, the standards track even though some of the requirements
section 5 of RFC 1602 have not or will not be met
In exercising this discretion, the IESG shall consider (a)
technical merit of the specification, (b) the possibility
achieving the goals of the Internet standards process
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
Postel Best Current Practice [Page 2]
RFC 1871 Variance Procedure November 1995
possible
The IESG should consult WG chair and appropriate WG members
needed, and the wishes of the WG should also be taken into account
3. Public
There shall be an extended Last Call for public review
4. Accepting the
The IESG is responsible for accepting the solution, and
comments from the Last Call
The IESG may approve such a variance, however, only if it
determines that the likely benefits to the Internet community
entering or advancing the specification on the standards track
likely to outweigh the costs to the Internet community that
from noncompliance with section 5 of RFC 1602.
In determining whether to approve a variance, the IESG has
to limit the scope of the variance to particular parts of section 5
of RFC 1602 and to impose such additional restrictions or
as it determines appropriate to protect the interests of the
community
5. The appeal
The IAB is responsible for hearing and deciding appeals
When the IESG (on reviewing a recommendation for a variance) the
determined that there is a situation where the existing written
do not apply or lead to a deadlock, the IESG may propose a
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
matter, or (2) define a procedure for resolving matters of this kind
In any case, the proposed solution will be documented in an
Draft and subjected to an extended Last Call
Depending on the results of the Last Call, the IESG will
accept the solution; or revise the proposal, update the
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
forwarded to the RFC Editor and published as an RFC
The IAB shall be available to hear and decide on appeals of the
this variance procedure
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
that first paragraph in the "The Variance Procedure" section
[1] IAB, and IESG, "Internet Standards Process -- Revision 2",
1602, IAB and IESG, March 1994.
[2] Huizer, E., and D. Crocker, "IETF Working Group Guidelines
Procedures", RFC 1603, SURFnet and Silicon Graphics, Inc.,
1994.
Security
Security issues are not discussed in this memo
Authors'
Jon
USC - ISI, Suite 1001
4676 Admiralty
Marina del Rey, CA 90292-6695
Phone: 310-822-1511
EMail: postel@isi.
Postel Best Current Practice [Page 4]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
