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
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
|
<pre>Network Working Group H. Alvestrand
Request for Comments: 4693 Google
Category: Experimental October 2006
<span class="h1">IETF Operational Notes</span>
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a new document series intended for use as a
repository for IETF operations documents, which should be more
ephemeral than RFCs, but more referenceable than Internet-Drafts, and
with more clear handling procedures than a random Web page.
It proposes to establish this series as an <a href="./rfc3933">RFC 3933</a> process
experiment.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. A Description of the ION Mechanism ..............................<a href="#page-2">2</a>
<a href="#section-2.1">2.1</a>. Properties of an ION .......................................<a href="#page-2">2</a>
<a href="#section-2.2">2.2</a>. ION Approval ...............................................<a href="#page-3">3</a>
<a href="#section-2.3">2.3</a>. Draft IONs .................................................<a href="#page-3">3</a>
<a href="#section-2.4">2.4</a>. The ION Store ..............................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Proposed Initial IONs ...........................................<a href="#page-4">4</a>
<a href="#section-4">4</a>. Success Criteria and Sunset Period ..............................<a href="#page-5">5</a>
<a href="#section-5">5</a>. Background and Motivation .......................................<a href="#page-6">6</a>
<a href="#section-6">6</a>. IANA Considerations .............................................<a href="#page-7">7</a>
<a href="#section-7">7</a>. Security Considerations .........................................<a href="#page-8">8</a>
<a href="#section-8">8</a>. Acknowledgements ................................................<a href="#page-8">8</a>
<a href="#section-9">9</a>. References ......................................................<a href="#page-8">8</a>
<a href="#section-9.1">9.1</a>. Normative References .......................................<a href="#page-8">8</a>
<a href="#section-9.2">9.2</a>. Informative References .....................................<a href="#page-8">8</a>
<span class="grey">Alvestrand Experimental [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4693">RFC 4693</a> ION October 2006</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document describes a new document series, called the IETF
Operational Notes, or IONs.
This document series is intended to capture the set of procedures
that the IETF follows, but for which the RFC process is an
inappropriate documentation vehicle.
The document series defined here does not modify the IETF process
rules that are defined in currently valid BCP documents.
The document series is a process experiment according to <a href="./rfc3933">RFC 3933</a>
[<a href="./rfc3933" title=""A Model for IETF Process Experiments"">RFC3933</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. A Description of the ION Mechanism</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Properties of an ION</span>
An ION is a document with a certain set of attributes ("front page
matter"). This specification does not place any limits on what else
an ION can contain.
An ION has the following attributes:
o A name, which is usable as the filename of the document
o A title
o A date of approval
o An identification of the body that approved this version
The format of the document is not restricted by this document. It's
suggested that there be an ION that describes expectations for ION
formats.
An ION is a versioned document. When a new ION is issued with the
same name, it obsoletes the previous version. When one desires to
retire an ION, one issues an ION saying "This document name is now
obsolete".
The ION name + the approval date forms a stable identifier for one
particular version of an ION; once it is published, it shall never be
changed, although it may be withdrawn (see below).
<span class="grey">Alvestrand Experimental [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4693">RFC 4693</a> ION October 2006</span>
The properties list does not include a "category"; while the set of
documents that might be IONs is extremely wide, we do not know yet
which categories could make sense. The question of categories might
get revisited at the end of the experiment period.
Procedurally, an ION has the formal authority of a statement from its
approving body. This means that an ION cannot change those
procedures of the IETF that are documented via the BCP series, since
the BCP series represents a determination of IETF consensus.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. ION Approval</span>
An ION is always approved by some body. The IESG is granted
authority by this document over the practical management of the
series and the definition of detailed processes and rules associated
with it.
The IESG, the IAB, and IAOC are given the right to approve IONs by
this document. The IESG, IAB, or IAOC may decide that other groups
or roles should be given the right to approve IONs.
The ION-approving groups are expected to issue IONs related to their
own areas of responsibility, and to use common sense when IONs are
needed where it isn't obvious who's responsible for them.
An updated ION will normally be approved by the same body that
approved the previous version, or by another body with the approval
of the previously-approving body. In case of conflict, or when the
previous body no longer exists, the IESG will decide who gets to
approve an updated ION.
A decision by any other body than the IESG to approve an ION can be
appealed to the IESG, in which case the IESG can nullify the
approval. A decision of the IESG can be appealed using the common
IETF appeals procedure, except that an IESG decision to nullify an
IAB decision to approve an ION cannot be appealed to the IAB.
In the case that the IESG ceases to exist, its successors or
assignees will take over the tasks given to the IESG in this
document.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Draft IONs</span>
There is no requirement that an ION will be published as a draft
before publication. This will, however, be desirable in many cases,
and thus, this document describes the properties and procedures for
handling draft IONs.
<span class="grey">Alvestrand Experimental [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4693">RFC 4693</a> ION October 2006</span>
Draft IONs shall have, instead of an approval date and an
identification of the body that approved it, information about:
o The word "DRAFT", prominently displayed
o The publication date and time
o The approval date of the document it is intended to update (if
any)
o The body that is intended to approve this version
o The appropriate forum for discussion of this draft (if any)
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. The ION Store</span>
All approved IONs are archived, in all their versions, and made
publicly available from resources operated by the IETF secretariat.
The store should be reachable by common methods like HTTP and FTP,
and should offer both easy access to the "current" version of all
IONs and bulk download of all IONs, all versions.
This document does not constrain the form of the ION Store, but
mandates that there be a public one.
Public draft IONs are published separately from the approved IONs.
Old versions may be published in the draft store and must be kept in
a version management system for the duration of the experiment.
Experience will show what the best policy for draft retention is if
the series is made permanent.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Proposed Initial IONs</span>
The following IONs should be created as soon as possible after this
document is published, to give the details of the maintenance of the
ION series, in order to bootstrap the process:
o The ION Format Guide
o The ION Store Description
The following list of documents, some of which currently exist,
provides examples of documents that could be converted to IONs. This
is not a binding recommendation, but gives examples of what IONs can
be good for.
o The I-D publishing procedure
<span class="grey">Alvestrand Experimental [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4693">RFC 4693</a> ION October 2006</span>
o The checklist for I-D submission to the IESG (formerly known as
id-nits)
o Procedures for spam control on IETF mailing lists
o Procedures for requesting a WG meeting slot
o Procedures for IETF minutes
o Procedures for IESG meeting minutes
Once the ION series is permanent, the existence of the ION series may
cause the following documents to be split into a "policy and
principles" BCP and a "procedures and boilerplate" document published
as ION:
o IETF Rights in Documents (currently <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>) <a href="./rfc3978">RFC 3978</a> [<a href="./rfc3978" title=""IETF Rights in Contributions"">RFC3978</a>]
o IETF Rights in Technology (currently <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>) <a href="./rfc3979">RFC 3979</a> [<a href="./rfc3979" title=""Intellectual Property Rights in IETF Technology"">RFC3979</a>]
o IETF mailing list management (currently <a href="./rfc3005">RFC 3005</a> [<a href="./rfc3005" title=""IETF Discussion List Charter"">RFC3005</a>], <a href="https://www.rfc-editor.org/bcp/bcp45">BCP</a>
<a href="https://www.rfc-editor.org/bcp/bcp45">45</a>, <a href="./rfc3683">RFC 3683</a> [<a href="./rfc3683" title=""A Practice for Revoking Posting Rights to IETF mailing lists"">RFC3683</a>], <a href="https://www.rfc-editor.org/bcp/bcp83">BCP 83</a>, and <a href="./rfc3934">RFC 3934</a> [<a href="./rfc3934" title=""Updates to RFC 2418 Regarding the Management of IETF Mailing Lists"">RFC3934</a>], <a href="./bcp94">BCP 94</a>)
If someone wishes to do such a split while the experiment is running,
the BCPs cannot refer to the "procedures" documents as IONs, since
the concept of an ION may go away. In that case, any procedures
removed from a BCP must either be reinstated or otherwise stored as a
permanently available reference.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Success Criteria and Sunset Period</span>
This experiment is expected to run for a period of 12 months,
starting from the date of the first ION published using this
mechanism. At the end of the period, the IESG should issue a call
for comments from the community, asking for people to state their
agreement to one of the following statements (or a suitable
reformulation thereof):
1. This document series has proved useful, and should be made
permanent
2. This document series is less useful than the equivalent
information in RFCs and informal Web pages, and should be
abandoned
3. We cannot decide yet; the experiment should continue
<span class="grey">Alvestrand Experimental [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4693">RFC 4693</a> ION October 2006</span>
The author believes that establishing objective metrics for the
success or failure of this experiment is not a worthwhile exercise;
the success or failure will be readily apparent in the community's
attitudes towards the series.
If the feedback reveals a community consensus for keeping the series,
the IESG may choose to create a new BCP RFC containing the
information herein, suitably modified by experience.
If the IESG decides that the feedback warrants terminating the
series, the repository will be closed for new documents, and the
existing ION documents will be returned to having the same status as
any other Web page or file on the IETF servers -- this situation will
closely resemble the situation before the experiment started.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Background and Motivation</span>
The IETF is an open organization, which means (among other things)
that there are always newcomers coming in to learn how to perform
work; this places a requirement on the organization to document its
processes and procedures in an accessible manner.
The IETF is also a large organization, which means that when
procedures change, there are a number of people who will like to know
of the change, to figure out what has changed, and possibly to
protest or appeal the change if they disagree with it.
At the present time (spring 2006), there are three kinds of documents
used for IETF documentation of its operations and procedures:
o BCP and Informational RFCs, which require an IETF consensus call
for BCP, approval by the IESG, and usually a great deal of debate
and effort to change, and which bind up editing resources in the
final edit stage, as well as being limited (in practice) to ASCII.
The BCP number forms a means of having a stable reference for new
versions of a document, but an updated Info RFC has a completely
different identifier from the RFC that it updates; "updates/
obsoletes" links can give some of the same information, but can
also be quite confusing to follow.
o Web pages, which can be changed without notice, provide very
little ability to track changes, and have no formal standing --
confusion is often seen about who has the right to update them,
what the process for updating them is, and so on. It is hard when
looking at a Web page to see whether this is a current procedure,
a procedure introduced and abandoned, or a draft of a future
procedure. For certain procedures, their informal documentation
<span class="grey">Alvestrand Experimental [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4693">RFC 4693</a> ION October 2006</span>
in the "IESG Guide" wiki has partially clarified this situation
but has no official status.
o "floating" Internet-Drafts, which are frequently updated, in a
trackable manner, but have no approval mechanism, are limited (in
practice) to ASCII format, and whose use as semi-permanent
documents clutters up their use as 6-month temporary working
documents.
This note introduces a new series that seems to fulfil the
requirements for "something in between":
o Unlike RFCs, they can be produced without a post-editing stage,
they can be in any format the controllers of the series choose
(allowing web pages with hyperlinks, which is an advantage for
newcomers).
o Also unlike RFCs, they can be produced by any body that the IESG
gives the right to use the mechanism; this allows certain
procedures to be updated without having to wait for the IESG
approval cycle.
o Unlike Internet-Drafts, they have an explicit approval step --
this allows a reader to easily see the difference between an idea
and an operational procedure.
o Unlike Web pages, there is an explicit mechanism for finding "all
current versions", and a mechanism for tracking the history of a
document.
The "author" attribute has quite deliberately been omitted from the
required property list. While there may be many cases where
identifying an author is a Good Thing, the responsibility for an
approved ION rests with the approving body.
Note: This proposal is NOT intended to affect the standards track in
any way -- a side effect may be to reduce the number of "process
BCPs" emitted, but this has no direct bearing on the IETF's technical
specifications. It is therefore not within the scope of the NEWTRK
working group.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
IONs will not include protocol specifications, so IONs will make no
requests for IANA actions. IANA will not need to review all IONs.
This document makes no requests of IANA either.
<span class="grey">Alvestrand Experimental [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4693">RFC 4693</a> ION October 2006</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
IONs will not include protocol specifications, so shouldn't have much
need to talk about security the way RFCs do.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgements</span>
Many people have contributed over the years to the ideas that I have
tried to express here.
I'm in particular indebted to John Klensin for his work on trying to
find a balance between formalism and flexibility in the IETF process,
and for his earlier attempts at creating such a document series as an
adjunct to the "ISD" effort, and for his many valuable comments on
this document.
In addition, Dave Crocker, Spencer Dawkins, Jeff Hutzelman, Sam
Hartman, and David Black (gen-ART reviewer) provided valuable
comments at Last Call time.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-RFC3933">RFC3933</a>] Klensin, J. and S. Dawkins, "A Model for IETF Process
Experiments", <a href="https://www.rfc-editor.org/bcp/bcp93">BCP 93</a>, <a href="./rfc3933">RFC 3933</a>, November 2004.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-RFC3005">RFC3005</a>] Harris, S., "IETF Discussion List Charter", <a href="https://www.rfc-editor.org/bcp/bcp45">BCP 45</a>,
<a href="./rfc3005">RFC 3005</a>, November 2000.
[<a id="ref-RFC3683">RFC3683</a>] Rose, M., "A Practice for Revoking Posting Rights to IETF
mailing lists", <a href="https://www.rfc-editor.org/bcp/bcp83">BCP 83</a>, <a href="./rfc3683">RFC 3683</a>, February 2004.
[<a id="ref-RFC3934">RFC3934</a>] Wasserman, M., "Updates to <a href="./rfc2418">RFC 2418</a> Regarding the
Management of IETF Mailing Lists", <a href="https://www.rfc-editor.org/bcp/bcp94">BCP 94</a>, <a href="./rfc3934">RFC 3934</a>,
October 2004.
[<a id="ref-RFC3978">RFC3978</a>] Bradner, S., "IETF Rights in Contributions", <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>,
<a href="./rfc3978">RFC 3978</a>, March 2005.
[<a id="ref-RFC3979">RFC3979</a>] Bradner, S., "Intellectual Property Rights in IETF
Technology", <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>, <a href="./rfc3979">RFC 3979</a>, March 2005.
<span class="grey">Alvestrand Experimental [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4693">RFC 4693</a> ION October 2006</span>
Author's Address
Harald Tveit Alvestrand
Google
Beddingen 10
N-7014 Trondheim
Norway
EMail: harald@alvestrand.no
<span class="grey">Alvestrand Experimental [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4693">RFC 4693</a> ION October 2006</span>
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Alvestrand Experimental [Page 10]
</pre>
|
