RFC 1871

RFC 1871: Addendum to RFC 1602 -- Variance Procedure 🎀

okay bestie, first the ID card 🪪 Network Working Group, Request for Comments: 1871, dated November 1995. It was written by J. Postel at ISI 💖. It's a Best Current Practice (BCP: 2) 👑. It updates RFC 1602 and RFC 1603 🦋. It doesn't list anything it obsoletes ✨.

---

Status of this Memo 🌸

so this doc is an Internet Best Current Practice for the whole Internet Community 🫶 and it's literally asking everyone to chat, discuss, and suggest improvements 💬. Distribution is unlimited, so share away 🧚

Abstract 💅

the tea: this doc tweaks the IETF procedures so there's a way out when the usual process is stuck or just doesn't seem to apply 🙈. It's a modification to the procedures of RFC 1602 and 1603 🔥.

Introduction ✨

the current IETF procedures live in "The Internet Standards Process -- Revision 2" [1] and "IETF Working Group Guidelines and Procedures" [2] 📚.

sometimes following the procedures leads to a deadlock 😭, or the procedures just don't give any guidance at all 💀. When that happens, it may be appropriate to invoke the variance procedure described below 🦋.

a revision of the RFC 1602 rules is underway, but it may take some time. So this doc is an interim amendment to RFC 1602, so nobody has to sit around in a state of paralysis while they wait 🌈.

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 🫶.

The Variance Procedure 👑

okay this is the big one 😤. Upon the recommendation of the responsible IETF Working Group (or, if no Working Group is constituted, the responsible ad hoc committee), the IESG may enter a particular specification into the standards track, or advance it within the standards track, even though some of the requirements of section 5 of RFC 1602 have not been met or will not be met.

but the IESG may approve such a variance 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 come from noncompliance with section 5. When deciding, 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 granting 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 🧐.

and when it's deciding 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 whatever additional restrictions or limitations it determines appropriate to protect the interests of the Internet community 🛡️.

there are five aspects 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 the standards track, or advance it within the standards track, even though some of the requirements of section 5 of RFC 1602 have not been met or will not be met.

when it's 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 granting 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 🧠.

the IESG should consult the 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 for 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 is reviewing a recommendation for a variance and determines that there's a situation where the existing written rules don't apply or lead to a deadlock, the IESG may propose a solution to the problem 🔥.

the solution may be developed by the IESG, or it may be 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 🔁.

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 about the use of this variance procedure ⚖️✨.

Acknowledgements 🙌

huge thanks to the IAB and the IESG, and especially to Brian Carpenter, Paul Mockapetris, Christian Huitema, Robert Elz, Frank Kastenholz, and Scott Bradner 💖. Scott deserves special credit for working with the lawyers to get that first paragraph in "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 🚨

okay, serious moment 🫢. This memo does not discuss security issues at all. Not one. So if you came here looking for security guidance, it isn't in this doc 💀.

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