1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
|
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]
^L
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]
^L
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]
^L
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: postel@isi.edu
Postel Best Current Practice [Page 4]
^L
|
