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
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
|
<pre>Internet Engineering Task Force (IETF) P. Hoffman
Request for Comments: 6292 VPN Consortium
Category: Informational June 2011
ISSN: 2070-1721
<span class="h1">Requirements for a Working Group Charter Tool</span>
Abstract
The IETF intends to provide a new tool to Area Directors for the
creation, re-chartering, and closing of Working Groups. The tool
will also allow the IETF community to view the status of the
chartering process. This document describes the requirements for the
proposed new tool, and it is intended as input to a later activity
for the design and development of such a tool.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6292">http://www.rfc-editor.org/info/rfc6292</a>.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Hoffman Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6292">RFC 6292</a> WG Charter Tool Reqs June 2011</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. WG Charter Process Overview . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. General Requirements . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. WG Records . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. Comments . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.3">2.3</a>. Naming of Charter Text Proposals . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.4">2.4</a>. Wording of Announcements . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.5">2.5</a>. Access to the Tool . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.6">2.6</a>. Initializing the Tool . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3">3</a>. Creating and Rechartering WGs . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.1">3.1</a>. Chartering a New WG . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.2">3.2</a>. Rechartering an Existing WG . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.3">3.3</a>. Ballots for Charter Approval . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4">4</a>. Requesting the Closing of a WG . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5">5</a>. Searching, Comparing, and Tracking Charters . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5.1">5.1</a>. Viewing and Searching the Charter Database . . . . . . . . <a href="#page-9">9</a>
5.2. Seeing Differences between Versions of Pre-Approval
Wordings . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5.3">5.3</a>. Tracking Charters with an Atom Feed . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-7">7</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<span class="grey">Hoffman Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6292">RFC 6292</a> WG Charter Tool Reqs June 2011</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
[<a id="ref-RFC2418">RFC2418</a>] describes the guidelines and procedures for formation and
operation of IETF Working Groups (WGs). Since the publication of <a href="./rfc2418">RFC</a>
<a href="./rfc2418">2418</a> in 1998, the IETF has started many dozen new WGs, and has shut
down many dozen. In that time, many WGs have had some (often dozens)
changes to their charters.
Today, virtually all of the tasks associated with creating,
rechartering, and closing a WG are performed manually. An Area
Director (AD) requests one of these actions by manually sending a
message to the Secretariat's ticket system. A member of the
Secretariat staff manually updates the internal Secretariat database
and the IETF Datatracker, manually places the WG on the IESG
teleconference agenda (when appropriate), and manually sends out all
of the required messages and announcements.
The IETF Administrative Oversight Committee (IAOC) would like to
create a better tool for those tasks, and this document lists the
requirements for such a tool. When complete, this document may be
used to issue an RFP for the design and development of the tool.
This document was prepared at the request of the IAOC.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. WG Charter Process Overview</span>
As described in [<a href="./rfc2418" title=""IETF Working Group Guidelines and Procedures"">RFC2418</a>], a key responsibility of the IESG is the
creation, re-chartering, and closing of WGs. Creation and
rechartering of WGs is a multi-step process that involves internal
review of a draft charter by the IESG and IAB, an external review of
the draft charter by the IETF community and by other standards
bodies, and (likely) approval of a final charter by the IESG. The
internal review by the IESG and IAB, and the external review by the
IETF community, often result in revisions to the draft charter.
Closing of a WG does not require review or approval by the IESG.
Rather, a WG may be closed at the request of an AD, normally the Area
Advisor for the WG.
Note that the charter and recharter processes do not involve changing
of WG milestones. A tool that handles milestone updates will likely
be created in the future.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. General Requirements</span>
The tool described here holds records for new WGs that are being
considered as well as for all WGs whose charter are under review.
<span class="grey">Hoffman Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6292">RFC 6292</a> WG Charter Tool Reqs June 2011</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. WG Records</span>
A WG record contains the following fields:
o name of the WG
o the WG's acronym
o names of the WG chairs (if known)
o names of the WG secretary (if any)
o names of the WG technical advisors (if any)
o shepherding AD
o IETF area
o charter text
o mailing list address and archive location
o previous mailing list (if any)
o other web sites (such as wikis, trackers, and/or project sites, if
any) including web sites existing prior to the WG formation
o earlier acronyms for the WG
o explanation for why the WG is being chartered or rechartered (if
any)
In addition, a WG record contains the state of the WG in the review
process. That state has one annotation: whether or not the state is
for a proposed WG or for an existing WG undergoing rechartering.
Some changes in state cause messages to be sent to the Secretariat so
that the Secretariat can perform additional steps, such as sending
out mail to various parties about the latest version of the charter
text, deadlines for an upcoming decision, and so on.
When a WG record is displayed, that display should also reflect
whether the WG currently exists or has been closed; that data comes
from a different part of the Datatracker database.
Any AD can modify fields in an existing WG record. Any AD can use
the tool to change the review state of a WG record. The normal order
for steps is shown in this document, but an AD can set the state to
any valid value at any time.
<span class="grey">Hoffman Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6292">RFC 6292</a> WG Charter Tool Reqs June 2011</span>
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Comments</span>
During the reviews for WG creation and rechartering, ADs can comment
on the reviews. Any AD can add a comment to the record of a WG that
is under review. Each comment can be flagged as either "blocking"
(meaning blocking forward movement until it is resolved) and "non-
blocking" (meaning that it is only informative or editorial).
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Naming of Charter Text Proposals</span>
Charter text proposals are to be kept for historical purposes. They
are kept in files with a specific naming pattern. The pattern for
charters before a WG is formed is:
charter-ietf-wgacronym-nn[-mm]
o "wgacronym" is the acronym of the proposed WG.
o "nn" is a two-digit charter number assigned in sequence. It
starts at "00" for before the WG is first chartered; the first
finished charter has a value of "01".
o "mm" is a two-digit proposal number assigned in sequence. It
starts at "00" for the first proposal for a particular version of
charter. It is omitted in the actual charter file.
For instance, if the "example" WG is chartered and then rechartered
twice, you might have the following sequence of files:
charter-ietf-example-00-00.txt (first proposal)
charter-ietf-example-00-01.txt (second proposal)
charter-ietf-example-00-02.txt (third proposal)
charter-ietf-example-01.txt (first charter)
charter-ietf-example-01-00.txt (first recharter proposal)
charter-ietf-example-01-01.txt (second recharter proposal)
charter-ietf-example-01-02.txt (third recharter proposal)
charter-ietf-example-02.txt (second charter)
charter-ietf-example-02-00.txt (next recharter proposal)
. . .
charter-ietf-example-03.txt (third charter)
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Wording of Announcements</span>
An AD can view and edit the standard "WG Review" and "WG Action"
announcements before they are sent out during the WG creation,
rechartering, and closing processes. If the AD edits the message,
the Secretariat is alerted to that fact when they receive the
request.
<span class="grey">Hoffman Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6292">RFC 6292</a> WG Charter Tool Reqs June 2011</span>
<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>. Access to the Tool</span>
Area Directors and the IETF Secretariat currently have access to
perform some actions in the Datatracker that other community members
do not; this access control continues to be used in many of the
extensions listed in this document. Further, the IETF Secretariat
can perform all actions that can be performed by any AD in this tool.
<span class="h3"><a class="selflink" id="section-2.6" href="#section-2.6">2.6</a>. Initializing the Tool</span>
Records for all WGs that are being created, or are in the process of
charter updates, will be added before the tool is first publicly
deployed.
The database should also be initialized with current and historical
data, namely as much information as is currently known about existing
and closed WGs that can be done in a mostly-automated fashion.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Creating and Rechartering WGs</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Chartering a New WG</span>
Any AD can create a new WG record using a simple web form. Creating
a record should succeed as long as there is no other WG with the same
name. Names must be unique, so the tool will warn the AD if the
acronym that is being proposed has been used in earlier WG charter
proposals and suggest against its use for a new charter. By default,
the field in the form listing the shepherding AD will be prepopulated
with the name of the AD who is filling in the form. The AD can fill
in all the fields for the proposed WG. The names of the WG chairs
can be left off during the initial chartering process.
(Some Secretariat tools have trouble with acronyms of more than eight
characters: they truncate the name. This will probably be fixed in
the future. The new tool should have a configuration setting that is
set to 8 initially, and it should be adjusted when the Secretariat
tools are updated. There may also be problems with names that have
hyphens in them. However, WGs that have more than eight characters
in their names, and WGs with hyphens in their names, have existed for
over a year.)
Creating a new WG record causes the Datatracker state for this
potential new WG to be "Informal IESG review". When the record is
created, the AD proposes a length of time (in weeks) for the internal
review time; the default is one week.
The review states in which a WG can exist during its initial
chartering are:
<span class="grey">Hoffman Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6292">RFC 6292</a> WG Charter Tool Reqs June 2011</span>
o Informal IESG review -- This is the initial state, moved into by
the tool when an AD creates a WG record. When the WG record is
moved to this state, a message is sent to the Secretariat. The
normal next state is "Internal review" if the idea is accepted, or
"Not currently under review" if the idea is abandoned. The tool
should prompt the AD if they try to move to the next state in less
than the minimum elapsed time set by the AD when creating the WG,
but allow the move if the AD responds to the prompt.
o Internal review -- The IESG and IAB are reviewing the early draft
of the charter; this is the initial IESG and IAB review. When
moved to this state, a note is sent to the Secretariat to place
this on the next IESG telechat and to inform the IAB. The usual
next state is "External review" if the idea is adopted, or
"Informal IESG review" if the IESG decides the idea needs more
work, or "Not currently under review" if the idea is abandoned.
o External review -- The IETF community and possibly other standards
development organizations (SDOs) are reviewing the proposed
charter. When moved to this state, a note is sent to the
Secretariat to send out the external review announcement to the
appropriate lists. The external review announcement will be sent
out to the normal IETF-related mailing lists. The AD can specify
whether or not to send the announcement to other SDOs (with the
default being that it should be), and the AD can also specify
additional recipients who should receive the announcement. When
moved to this state, a separate note is sent to the Secretariat to
schedule discussion for the next IESG telechat. The usual next
state is "IESG review", although it might move to "Not currently
under review" if the idea is abandoned during the external review.
o IESG review -- The IESG is reviewing the discussion from the
external review of the proposed charter. The usual next state is
"WG exists", or "Not currently under review" if the idea is
abandoned.
o WG exists -- The WG was approved by the IESG. When moved to this
state, a note is sent to the Secretariat to publish the charter
and send the appropriate announcements. The WG remains in this
state until there is a request to update the charter.
o Not currently under review -- The proposed WG is not being
considered at this time. A proposed WG charter will remain in
this state until an AD moves it to "Informa1 IESG review".
All states above, except for "WG exists", are given the annotation
"Initial chartering".
<span class="grey">Hoffman Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6292">RFC 6292</a> WG Charter Tool Reqs June 2011</span>
The chartering process involves the proposed charter appearing on two
IESG telechats. The tool should allow an AD and/or the Secretariat
to select the telechat date for the approval events. When the
telechat is selected, the state determines where it appears on that
telechat's agenda.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Rechartering an Existing WG</span>
Any AD can request that a WG be rechartered using a simple web form.
This form prompts with the current charter and allows all fields to
be edited. Asking for a recharter causes the Datatracker state for
this WG to be "Informal IESG review". When the recharter record is
created, the AD proposes a length of time (in weeks) for the internal
review time; the default is one week.
The review states in which a WG can exist during rechartering are:
o WG exists; Informal IESG recharter review -- This is the initial
state, moved into by the tool when an AD asks for a WG to be
rechartered. When the WG record is moved to this state, a message
is sent to the Secretariat. The normal next state is "WG exists;
Internal review" if the idea is accepted, or "WG exists" if this
attempt to recharter is abandoned. The tool should prompt the AD
if they try to move to the next state in less than the minimum
elapsed time set by the AD when asking to recharter the WG.
o WG exists; Internal recharter review -- The IESG and IAB are
reviewing the proposed new charter; this is the initial IESG and
IAB review of the new charter. When moved to this state, a note
is sent to the Secretariat to place this on the next IESG telechat
and to inform the IAB. The usual next state is "WG exists;
External review" if the idea is adopted, or "WG exists; Informal
IESG review" if the IESG decides the idea needs more work, or "WG
exists" if the current rechartering is abandoned or if the new
charter is approved during internal review.
o WG exists; External recharter review -- The IETF community and
possibly other SDOs are reviewing the proposed new charter. When
moved to this state, a note is sent to the Secretariat to send out
the external review announcement to the appropriate lists. The
external review announcement will be sent to the normal IETF-
related mailing lists. The AD can specify whether or not to send
the announcement to other SDOs (with the default being that it
should be), and the AD can also specify additional recipients who
should receive the announcement. The usual next state is "WG
exists; IESG review", although it might move to "WG exists" if the
current rechartering is abandoned during the external review.
<span class="grey">Hoffman Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6292">RFC 6292</a> WG Charter Tool Reqs June 2011</span>
o WG exists; IESG recharter review -- The IESG is reviewing the
discussion from the external review of the recharter. When moved
to this state, a note is sent to the Secretariat to schedule
discussion for the next IESG telechat. The usual next state is
"WG exists".
All states above are given the annotation "Rechartering".
When rechartering existing WGs, the IESG decides whether or not the
recharter needs an external review; many do not.
The rechartering process involves the proposed charter appearing on
one or two IESG telechats. The tool should allow an AD and/or the
Secretariat to select the telechat date for the approval events.
When the telechat is selected, the state determines where it appears
on that telechat's agenda.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Ballots for Charter Approval</span>
The current Datatracker has facilities for ballots on adoption of
Internet-Drafts to become RFCs. A separate facility needs to be
created to allow balloting for initial chartering or rechartering
during IESG review. The balloting for charter and rechartering will
allow ADs to express "yes", "no", and "abstain" positions, and will
allow ADs to change their positions over time.
As described in <a href="#section-2.2">Section 2.2</a>, comments can be added to the record for
a WG. It is expected that such comments will be added during the
balloting process.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Requesting the Closing of a WG</span>
An AD can use the tool to request that the Secretariat close an
existing WG. The request action will prompt the AD to provide
instructions regarding the disposition of each active Internet-Draft
(such as to withdraw the draft, move it to another WG, convert it to
an individual submission, and so on), wording for the closure
announcement, and the status of the WG mailing list (will it remain
open or should it be closed).
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Searching, Comparing, and Tracking Charters</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Viewing and Searching the Charter Database</span>
All members of the IETF community can view the public portions of the
charter database. This public view should have an explanation of the
states given in this document. They can also search for a WG record
in the tool based on one or more of the following criteria:
<span class="grey">Hoffman Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6292">RFC 6292</a> WG Charter Tool Reqs June 2011</span>
o WG name (full or partial)
o WG acronym
o WG charter state
o Shepherding AD
o Area
o Text in any of the fields
o Earlier acronyms for the WG
Further, all users can view all snapshots of earlier versions of a
WG's charter. Snapshots include the Area, AD, WG name, WG acronym,
chairs, and charter text.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Seeing Differences between Versions of Pre-Approval Wordings</span>
It needs to be easy to compare differences between different versions
of proposed charter language, up to and including the approved
version. Using the naming formats given in <a href="#section-2">Section 2</a>, this means
that it must be easy to compare wgacronym-charter-ss (for the highest
value of "ss") with wgacronym-recharter-ss-nn. It must also be
possible to compare any two versions of approved charters (that is,
of two values for "ss" in wgacronym-charter-ss). It also must be
easy to compare two versions that have different acronyms in the case
that the acronym changes during the chartering process.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Tracking Charters with an Atom Feed</span>
The tool needs to provide an Atom feed [<a href="./rfc4287" title=""The Atom Syndication Format"">RFC4287</a>] for the changes in a
charter. The contents of the feed are the full WG record, plus an
indication of what changed since the last entry in the feed.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
Creating a new tool for tracking the charter of WGs does not affect
the security of the Internet in any significant fashion.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgements</span>
This document draws heavily on earlier work done on this topic by
other writers, such as previous IESG and IAB members. Various
members of the IESG contributed many suggestions to this document.
In particular David Harrington, Robert Sparks, and Russ Housley
contributed a great deal of wording and many ideas.
<span class="grey">Hoffman Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6292">RFC 6292</a> WG Charter Tool Reqs June 2011</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2418">RFC2418</a>] Bradner, S., "IETF Working Group Guidelines and
Procedures", <a href="https://www.rfc-editor.org/bcp/bcp25">BCP 25</a>, <a href="./rfc2418">RFC 2418</a>, September 1998.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-RFC4287">RFC4287</a>] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", <a href="./rfc4287">RFC 4287</a>, December 2005.
Author's Address
Paul Hoffman
VPN Consortium
EMail: paul.hoffman@vpnc.org
Hoffman Informational [Page 11]
</pre>
|
