File: rfc1603.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1627 lines) | stat: -rw-r--r-- 63,900 bytes parent folder | download | duplicates (5)
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
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627






Network Working Group                                          E. Huizer
Request for Comments: 1603                                    SURFnet bv
Category: Informational                                       D. Crocker
                                                  Silicon Graphics, Inc.
                                                              March 1994


                           IETF Working Group
                       Guidelines and Procedures

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   The Internet Engineering Task Force (IETF) has responsibility for
   developing and reviewing specifications intended as Internet
   Standards. IETF activities are organized into working groups (WGs).
   This document describes the guidelines and procedures for formation
   and operation of IETF working groups. It describes the formal
   relationship between IETF participants WG and the Internet
   Engineering Steering Group (IESG). The basic duties of IETF
   participants, including WG Chair and IESG Area Directors are defined.

Table of Contents

   1.   INTRODUCTION..............................................  2
     1.1. IETF approach to standardization........................  3
     1.2. Acknowledgments.........................................  4
   2.   WORKING GROUP (WG) FORMATION..............................  5
     2.1. Criteria for formation..................................  5
     2.2. Charter.................................................  6
     2.3. Charter review & approval...............................  9
     2.4. Birds of a feather (BOF)................................  9
   3.   WORKING GROUP OPERATION................................... 11
     3.1. Session planning........................................ 11
     3.2. Session venue........................................... 12
     3.3. Session management...................................... 14
     3.4. Contention and appeals overview......................... 15
   4.   WORKING GROUP TERMINATION................................. 16
   5.   STAFF ROLES............................................... 17
     5.1. WG Chair................................................ 17
     5.2. WG Editor/Secretary..................................... 19
     5.3. WG Facilitator.......................................... 19
     5.4. Design teams............................................ 19



Huizer & Crocker                                                [Page 1]

RFC 1603             IETF Working Group Guidelines            March 1994


     5.5. Area Consultant......................................... 19
     5.6. Area Director........................................... 20
     5.7. Area Directorate........................................ 21
   6.   WORKING GROUP DOCUMENTS................................... 21
     6.1. Session documents....................................... 21
     6.2. IETF meeting document archive........................... 21
     6.3. Internet-Drafts (I-D)................................... 23
     6.4. Request For Comments (RFC).............................. 24
     6.5. Submission of documents................................. 24
     6.6. Review of documents..................................... 25
   7.   SECURITY CONSIDERATIONS................................... 26
   8.   REFERENCES................................................ 26
   9.   AUTHORS' ADDRESSES........................................ 27
   APPENDIX:  SAMPLE WORKING GROUP CHARTER........................ 28

1.   INTRODUCTION

   This document defines guidelines and procedures for Internet
   Engineering Task Force working groups.  The Internet is a loosely-
   organized international collaboration of autonomous, interconnected
   networks; it supports host-to-host communication through voluntary
   adherence to open protocols and procedures defined by Internet
   Standards, a collection of which are commonly known as "the TCP/IP
   protocol suite". The Internet Standards Process is defined in [1].
   Development and review of potential Internet Standards from all
   sources is conducted by the Internet Engineering Task Force (IETF).

   The IETF is a large, open community of network designers, operators,
   vendors, users, and researchers concerned with the Internet and the
   technology used on it. The IETF is managed by its Internet
   Engineering Steering Group (IESG) whose membership includes an IETF
   Chair, responsible for oversight of general IETF operations, and Area
   Directors, each of whom is responsible for a set of IETF activities
   and working groups. The IETF Executive Director and IESG Secretary
   are ex-officio participants, as are the IAB Chair and a designated
   Internet Architecture Board (IAB) member.  At present there are 10
   areas, though the number and purview of areas changes over time:

            User Services               (USV)
            Applications                (APP)
            Service Applications        (SAP)
            Transport Services          (TSV)
            Internet                    (INT)
            Routing                     (RTG)
            Network Management          (MGT)
            Operational Requirements    (OPS)
            Security                    (SEC)
            Standards & Processes       (STD)



Huizer & Crocker                                                [Page 2]

RFC 1603             IETF Working Group Guidelines            March 1994


   Most areas have an advisory group or directorate.  The specific name
   and the details of the role for each group differs from area to area,
   but the primary intent is that the group assist the Area Director,
   e.g., with the review of specifications produced in the area. An
   advisory group is formed by an Area Director (AD) and comprises
   experienced members of the IETF and technical community represented
   by the area.  A small IETF Secretariat provides staff and
   administrative support for the operation of the IETF.

   The primary activities of the IETF are performed by committees known
   as working groups. There are currently more than 60 of these.
   Working groups tend to have a narrow focus and a lifetime bounded by
   completion of a specific task, although there are exceptions.

   There is no formal membership in the IETF.  Participation is open to
   all.  This participation may be by on-line contribution, attendance
   at face-to-face sessions, or both.  Anyone from the Internet
   community who has the time and interest is urged to participate in
   IETF meetings and any of its on-line working group discussions.
   Participation is by individual technical contributors, rather than by
   formal representatives of organizations.

   This document defines procedures and guidelines for formation and
   operation of working groups in the IETF. It defines the relations of
   working groups to other bodies within the IETF. The duties of working
   group Chairs and Area Directors with respect to the operation of the
   working group are also defined.  The document uses: "shall", "will",
   "must" and "is required" where it describes steps in the process that
   are essential, and uses: "suggested", "should" and "may" are where
   guidelines are described that are not essential, but are strongly
   recommended to help smooth WG operation.

1.1. IETF approach to standardization

   The reader is encouraged to study The Internet Standards Process [1].
   Familiarity with this document is essential for a complete
   understanding of the philosophy, procedures and guidelines described
   in this document.

   The goals of the process are summarized in [1]:

     "In general, an Internet Standard is a specification that is
     stable and well-understood, is technically competent, has
     multiple, independent, and interoperable implementations
     with operational experience, enjoys significant public
     support, and is recognizably useful in some or all parts of
     the Internet.
     ...



Huizer & Crocker                                                [Page 3]

RFC 1603             IETF Working Group Guidelines            March 1994


     "In outline, the process of creating an Internet Standard is
     straightforward: a specification undergoes a period of
     development and several iterations of review by the Internet
     community and perhaps revision based upon experience, is
     adopted as a Standard by the appropriate body (see below),
     and is published.

     "In practice, the process is somewhat more complicated, due
     to (1) the number and type of possible sources for
     specifications; (2) the need to prepare and revise a
     specification in a manner that preserves the interests of
     all of the affected parties;  (3) the importance of
     establishing widespread community agreement on its technical
     content; and (4) the difficulty of evaluating the utility of
     a particular specification for the Internet community.
     ...
     "These procedures are explicitly aimed at developing and
     adopting generally-accepted practices.  Thus, a candidate
     for Internet standardization is implemented and tested for
     correct operation and interoperability by multiple,
     independent parties, and utilized in increasingly demanding
     environments, before it can be adopted as an Internet
     Standard."

   The IETF standardization process has been marked by informality.  As
   the community of participation has grown it has become necessary to
   document procedures, while continuing to avoid unnecessary
   bureaucracy.  This goals of this balancing act are summarized in [1]
   as:

     "The procedures that are described here provide a great deal
     of flexibility to adapt to the wide variety of circumstances
     that occur in the Internet standardization process.
     Experience has shown this flexibility to be vital in
     achieving the following goals for Internet standardization:

           *    high quality,
           *    prior implementation and testing,
           *    openness and fairness, and
           *    timeliness."

1.2. Acknowledgments

   Much of this document is due to the copy-and-paste function of a word
   processor.  Several passages have been taken from the documents cited
   in the reference section. The POISED WG provided discussion and
   comments. Three people deserve special mention, as especially large
   chunks of their documents have been integrated into this one:  Vint



Huizer & Crocker                                                [Page 4]

RFC 1603             IETF Working Group Guidelines            March 1994


   Cerf [7] from whom we borrowed the description of the IETF; and Greg
   Vaudreuil and Steve Coya who provided several paragraphs.  Also, John
   Stewart and Steve Crocker did a truly stellar job of proof-reading.
   However, all the errors you'll find are probably ours.

2.  WORKING GROUP (WG) FORMATION

   IETF working groups (WGs) are the primary mechanism for development
   of IETF specifications and guidelines, many of which are intended as
   standards or recommendations. A working group may be established at
   the initiative of an Area Director (AD) or it may be initiated by an
   individual or group of individuals. Anyone interested in creating an
   IETF working group must obtain the advice and consent of the
   appropriate IETF Area Director under whose direction the working
   group would fall and must proceed through the formal steps detailed
   in this section.

   A working group is typically created to address a specific problem or
   produce a deliverable (a guideline, standards specification, etc.)
   and is expected to be short-lived in nature.  Upon completion of its
   goals and achievement of its objectives, the working group as a unit
   is terminated. Alternatively at the discretion of the IESG, Area
   Director, the WG Chair and the WG participants, the objectives or
   assignment of the working group may be extended by enhancing or
   modifying the working group's charter.

2.1. Criteria for formation

   When determining whether it is appropriate to create a working group,
   the Area Director and the IESG will consider several issues:

   -    Are the issues that the working group plans to address clear
        and relevant for the Internet community?

   -    Are the goals specific and reasonably achievable, and
        achievable within the time frame specified by the
        milestones?

   -    What are the risks and urgency of the work, to determine the
        level of attention required?

   -    Do the working group's activities overlap with those of
        another working group? If so, it may still be appropriate to
        create the working group, but this question must be
        considered carefully by the Area Directors as subdividing
        efforts often dilutes the available technical expertise.





Huizer & Crocker                                                [Page 5]

RFC 1603             IETF Working Group Guidelines            March 1994


   -    Is there sufficient interest and expertise in the working
        group's topic with at least several people willing to expend
        the effort to produce the desired result (e.g., a protocol
        specification)?  Working groups require considerable effort,
        including management of the working group process, editing
        of working group documents, and contribution to the document
        text.  IETF experience suggests that these roles typically
        cannot all be handled by one person; four or five active
        participants are typically required.

   -    Does a base of interested consumers (end users) appear to
        exist for the planned work?  Consumer interest can be
        measured by participation of end-users within the IETF
        process, as well as by less direct means.

   Considering the above criteria, the Area Director will decide whether
   to pursue the formation of the group through the chartering process.

2.2. Charter

   The formation of a working group requires a charter which is
   primarily negotiated between a prospective working group Chair and
   the relevant Area Director, although final approval is made by the
   IESG and all charters are reviewed by the Internet Architecture Board
   (IAB).  A charter is a contract between a working group and the IETF
   to perform a set of tasks.  A charter:

   1.   Lists relevant administrative aspects of the working group;

   2.   Specifies the direction or objectives of the working group
        and describes the approach that will be taken to achieve the
        goals; and

   3.   Enumerates a set of milestones together with time frames for
        their completion.

   When the prospective Chair, the Area Director and the IESG Secretary
   are satisfied with the charter form and content, it becomes the basis
   for forming a working group. The AD may require an initial draft of a
   charter to be available prior to holding an exploratory Birds of a
   Feather (BOF) meeting, as described below.

   Charters may be renegotiated periodically to reflect the current
   status, organization or goals of the working group. Hence, a charter
   is a contract between the IETF and the working group which is
   committing to meet explicit milestones and delivering concrete
   "products".




Huizer & Crocker                                                [Page 6]

RFC 1603             IETF Working Group Guidelines            March 1994


   Specifically, each charter consists of 6 sections:

   Working group name

        A working group name should be reasonably descriptive or
        identifiable. Additionally, the group shall define an
        acronym (maximum 8 printable ASCII characters) to reference
        the group in the IETF directories, mailing lists, and
        general documents.

   Chair(s)

        The working group may have one or two Chair(s) to perform
        the administrative functions of the group. The email
        address(es) of the Chair(s) shall be included.

   Area and Area Director(s)

        The name of the IETF area with which the working group is
        affiliated and the name and electronic mail address of the
        associated Area Director.

   Mailing list

        It is required that an IETF working group have a general
        Internet mailing list.  Most of the work of an IETF working
        group will be conducted that.

        The charter shall include:

             The address to which a participant sends a
             subscription request and the procedures to follow when
             subscribing,

             The address to which a participant sends submissions
             and special procedures, if any, and

             The location of the mailing list archive, if any.

        A message archive should be maintained in a public place
        which can be accessed via FTP. The ability to retrieve from
        the archive via electronic mail requests also is
        recommended. Additionally, the address:

             ietf-archive@cnri.reston.va.us

        shall be included on the mailing list.




Huizer & Crocker                                                [Page 7]

RFC 1603             IETF Working Group Guidelines            March 1994


        NOTE:   It is strongly suggested that the mailing list be on
        a host directly connected to the IP Internet to facilitate
        use of the SMTP expansion command (EXPN) and to allow mail
        archive access via FTP, gopher and the like in keeping with
        the general IETF rule for openness. If this is not possible,
        the message archive and membership of the list must be made
        available to those who request it by sending a message to
        the list-request alias.

   Description of working group

   The focus and intent of the group shall be set forth briefly. By
   reading this section alone, an individual should be able to decide
   whether this group is relevant to their own work. The first paragraph
   must give a brief summary of the problem area, basis, goal(s) and
   approach(es) planned for the working group.  This paragraph will
   frequently be used as an overview of the working group's effort.

   The terms "they", "them" and "their" are used in this document as
   third-person singular pronouns.

        To facilitate evaluation of the intended work and to provide
        on-going guidance to the working group, the charter shall
        describe the problem being solved and shall discuss
        objectives and expected impact with respect to:

        -    Architecture
        -    Operations
        -    Security
        -    Network management
        -    Transition (where applicable)

   Goals and milestones

        The working group charter must establish a timetable for
        work. While this may be re-negotiated over time, the list
        of milestones and dates facilitates the Area Director's
        tracking of working group progress and status, and it is
        indispensable to potential participants identifying the
        critical moments for input. Milestones shall consist of
        deliverables that can be qualified as showing specific
        achievement; e.g., "Internet-Draft finished" is fine, but
        "discuss via email" is not. It is helpful to specify
        milestones for every 3-6 months, so that progress can be
        gauged easily.  This milestone list is expected to be
        updated periodically. Updated milestones are re-negotiated
        with the Area Director and the IESG, as needed, and then are
        submitted to the IESG Secretary:



Huizer & Crocker                                                [Page 8]

RFC 1603             IETF Working Group Guidelines            March 1994



             IESG-secretary@cnri.reston.va.us

   An example of a WG charter is in Appendix A.

2.3. Charter review & approval

   Working groups often comprise technically competent participants who
   are not familiar with the history of Internet architecture or IETF
   processes.  This can, unfortunately, lead to good working group
   consensus about a bad design.  To facilitate working group efforts,
   an Area Director may assign an Area Consultant from among the ranks
   of senior IETF participants.  (Area Consultants are described in the
   section of Staff Roles.)  At the discretion of the AD, approval of a
   new WG may be withheld in the absence of sufficient Consultant
   resources.

   Once the Area Director (and the Area Directorate, as the AD deems
   appropriate) has approved the working group charter, the charter is
   submitted for review by the IAB and approval by the Internet
   Engineering Steering Group using the criteria described previously.

   The Internet Architecture Board (IAB) will review the charter of the
   proposed WG to determine the relationship of the proposed work to the
   overall architecture of the Internet Protocol Suite.

   The approved charter is submitted to the IESG Secretary who records
   and enters the information into the IETF tracking database and
   returns the charter in a form formatted by the database.  The working
   group is announced to the IETF mailing list by the IESG Secretary.

2.4. Birds of a feather (BOF)

   Often it is not clear whether an issue merits the formation of a
   working group. To facilitate exploration of the issues the IETF
   offers the possibility of a Birds of a Feather (BOF) session, as well
   as the early formation of an email list for preliminary discussion.
   Alternatively, a BOF may serve as a forum for a single presentation
   or discussion, without any intent to form a working group.

   A BOF is a session at an IETF meeting which permits "market research"
   and technical "brainstorming".  Any individual may request permission
   to hold a BOF on a subject. The request must be filed with the
   relevant Area Director. The person who requests the BOF is usually
   appointed as Chair of the BOF.  The Chair of the BOF is also
   responsible for providing a report on the outcome of the BOF.





Huizer & Crocker                                                [Page 9]

RFC 1603             IETF Working Group Guidelines            March 1994


   The AD may require the conduct of email discussion, prior to
   authorizing a BOF.  This permits initial exchanges and sharing of
   framework, vocabulary and approaches, in order to make the time spent
   in the BOF more productive.  The AD may require that a BOF be held,
   prior to establishing a working group, and the AD may require that
   there be a draft of the WG charter prior to holding a BOF.

   Usually the outcome of a BOF will be one of the following:

   -    There was enough interest and focus in the subject to
        warrant the formation of a WG;

   -    The discussion came to a fruitful conclusion, with results
        to be written down and published, however there is no need
        to establish a WG; or

   -    There was not enough interest in the subject to warrant the
        formation of a WG.

   There is an increasing demand for BOF sessions at IETF meetings.
   Therefore the following rules apply for BOFs:

   -    All BOFs must have the approval of the appropriate Area
        Director. The Secretariat will NOT schedule or allocate time
        slots without the explicit approval of the Area Director.

   -    The purpose of a BOF is to conduct a single, brief
        discussion or to ascertain interest and establish goals for
        a working group. All BOF organizers are required to submit a
        brief written report of what transpired during the BOF
        session together with a roster of attendees to the IESG
        Secretary for inclusion in the Proceedings.

   -    A BOF may be held only once (ONE slot at one IETF Plenary
        meeting).

   -    Under unusual circumstances an Area Director may, at their
        discretion, allow a BOF to meet for a second time. Typically
        (though not a requirement) this is to develop a charter to
        be submitted to the IESG.

   -    BOFs are not permitted to meet three times.









Huizer & Crocker                                               [Page 10]

RFC 1603             IETF Working Group Guidelines            March 1994


   -    A BOF may be held for single-event discussion, or may pursue
        creation of normal IETF working groups for on-going
        interactions and discussions. When the request for a BOF
        comes from a formally-constituted group, rather than from an
        individual, the rules governing the handling of the request
        are the same as for all other BOFs and working groups.

   -    When necessary, WGs will be given priority for meeting space
        over BOFs.

3.  WORKING GROUP OPERATION

   The IETF has basic requirements for open and fair participation and
   for thorough consideration of technical alternatives.  Within those
   constraints, working groups are autonomous and each determines most
   of the details of its own operation with respect to session
   participation, reaching closure, etc. The core rule for operation is
   that acceptance or agreement is achieved via working group "rough
   consensus".

   A number of procedural questions and issues will arise over time, and
   it is the function of the Working Group Chair to manage the group
   process, keeping in mind that the overall purpose of the group is to
   make progress towards reaching rough consensus in realizing the
   working group's goals and objectives.

   There are few hard and fast rules on organizing or conducting working
   group activities, but a set of guidelines and practices have evolved
   over time that have proven successful. These are listed here, with
   actual choices typically determined by the working group participants
   and the Chair.

3.1. Session planning

   For coordinated, structured WG interactions, the Chair must publish a
   draft agenda well in advance of the actual session. The agenda needs
   to contain at least:

   -    The items for discussion;

   -    The estimated time necessary per item; and

   -    A clear indication of what documents the participants will
        need to read before the session in order to be well
        prepared.






Huizer & Crocker                                               [Page 11]

RFC 1603             IETF Working Group Guidelines            March 1994


   Publication shall include sending a copy to the working group mailing
   list and to the IETF-Announce list.  Notices for the IETF-Announce
   list should be sent to:

          ietf-announce-post@cnri.reston.va.us

   All working group actions shall be taken in a public forum, and wide
   participation is encouraged.   A working group will conduct much of
   its business via electronic mail distribution lists but may meet
   periodically to discuss and review task status and progress, to
   resolve specific issues and to direct future activities. It is
   common, but not required, that a working group will meet at the
   trimester IETF Plenary events. Additionally, interim sessions may be
   scheduled for telephone conference, video teleconference, or for
   face-to-face (physical) sessions.

   All working group sessions (including those held outside of the IETF
   meetings) shall be reported by making minutes available.  These
   minutes should include the agenda for the session, an account of the
   discussion including any decisions made, and a list of attendees. The
   Working Group Chair is responsible for insuring that session minutes
   are written and distributed, though the actual task may be performed
   by someone designated by the Working Group Chair. The minutes shall
   be submitted in printable ASCII text for publication in the IETF
   Proceedings, and for posting in the IETF Directories and are to be
   sent to:

                    minutes@cnri.reston.va.us

3.2. Session venue

   Each working group will determine the balance of email and face-to-
   face sessions that is appropriate for achieving its milestones.
   Electronic mail permits the widest participation; face-to-face
   meetings often permit better focus and therefore can be more
   efficient for reaching a consensus among a core of the working group
   participants.  In determining the balance, the WG must ensure that
   its process does not serve to exclude contribution by email-only
   participants.  Also note that decisions reached during IETF meetings
   are NOT final, but must be conveyed to the mailing list to verify WG
   consensus.

IETF Meetings

   If a WG needs a session at an IETF meeting, the Chair must apply for
   time-slots as soon as the first announcement of that IETF meeting is
   made by the IETF Secretariat to the WG-chairs list.  Session time is
   a scarce resource at IETF meetings, so placing requests early will



Huizer & Crocker                                               [Page 12]

RFC 1603             IETF Working Group Guidelines            March 1994


   facilitate schedule coordination for WGs requiring the same set of
   experts.

   The application for a WG session at an IETF meeting shall be made to
   the IETF Secretariat.  Alternatively some Area Directors may want to
   coordinate WG sessions in their area and request that time slots be
   coordinated through them.  After receiving all requests for time
   slots by WGs in the area, the Area Director(s) form a draft session-
   agenda for their area, which is then sent to the WG chairs of the
   area. After approval it will be sent to the IETF Secretariat.

   An application must contain:

   -    The amount of time requested;

   -    The rough outline of the WG agenda that is expected to be
        covered;

   -    The estimated number of people that will attend the WG
        session;

   -    Related WGs that must not be scheduled for the same time
        slot(s); and

   -    Individuals whose attendance is desired.

   The Secretariat allots time slots on the basis of the session-agenda
   made by the Area Director(s). If the proposed session- agenda for an
   area does not fit into the IETF meeting-agenda, the IETF Secretariat
   will adjust it to fit, after consulting the Area Director(s) and the
   relevant chairs.  The Secretariat will then form a draft session-
   agenda and distribute it among the Working Group Chairs for final
   approval.

   NOTE:  While open discussion and contribution is essential to working
   group success, the Chair is responsible for ensuring forward
   progress.  When acceptable to the WG, the Chair may call for
   restricted participation (but not restricted attendance!) at IETF
   working group sessions for the purpose of achieving progress. The
   Working Group Chair then has the authority to refuse to grant the
   floor to any individual who is unprepared or otherwise covering
   inappropriate material.

On-line

   It can be quite useful to conduct email exchanges in the same manner
   as a face-to-face session, with published schedule and agenda, as
   well as on-going summarization and consensus polling.



Huizer & Crocker                                               [Page 13]

RFC 1603             IETF Working Group Guidelines            March 1994


   Many working group participants hold that mailing list discussion is
   the best place to consider and resolve issues and make decisions.
   Choice of operational style is made by the working group itself.  It
   is important to note, however, that Internet email discussion is
   possible for a much wider base of interested persons than is
   attendance at IETF meetings, due to the time and expense required to
   attend.

3.3. Session management

   Working groups make decisions through a "rough consensus" process.
   IETF consensus does not require that all participants agree although
   this is, of course, preferred.  In general the dominant view of the
   working group shall prevail.  (However, it must be noted that
   "dominance" is not to be determined on the basis of volume or
   persistence, but rather a more general sense of agreement.)
   Consensus can be determined by balloting, humming, or any other means
   on which the WG agrees (by rough consensus, of course).

   The challenge to managing working group sessions is to balance the
   need for open and fair consideration of the issues against the need
   to make forward progress.  The working group, as a whole, has the
   final responsibility for striking this balance.  The Chair has the
   responsibility for overseeing the process but may delegate direct
   process management to a formally-designated Facilitator.

   It is occasionally appropriate to revisit a topic, to re-evaluate
   alternatives or to improve the group's understanding of a relevant
   decision.  However, unnecessary repeated discussions on issues can be
   avoided if the Chair makes sure that the main arguments in the
   discussion (and the outcome) are summarized and archived after a
   discussion has come to conclusion. It is also good practice to note
   important decisions/consensus reached by email in the minutes of the
   next 'live' session, and to summarize briefly the decision-making
   history in the final documents the WG produces.

   To facilitate making forward progress, a Working Group Chair may wish
   to direct a discussion to reject or defer the input from a member,
   based upon the following criteria:

   Old

     The input pertains to a topic that already has been resolved
     and is redundant with information previously available;







Huizer & Crocker                                               [Page 14]

RFC 1603             IETF Working Group Guidelines            March 1994


   Minor

     The input is new and pertains to a topic that has already
     been resolved, but it is felt to be of minor import to the
     existing decision;

   Timing

     The input pertains to a topic that the working group has not
     yet opened for discussion; or

   Scope

     The input is outside of the scope of the working group
     charter.

3.4. Contention and appeals overview

   In the course of group design processes, strife happens.  Strife and
   contention are particularly likely when working groups comprise many
   constituencies.  On the other hand differences in view are vital to
   the success of the IETF and healthy debate is encouraged.  Sometimes
   debates degenerate into something akin to warfare.  For these
   circumstances, the IETF has an extensive review and appeals process.

   Formal procedures for requesting review and conducting appeals are
   documented in The Internet Standards Process [1].  A brief summary is
   provided, here.

   In fact the IETF approach to reviews and appeals is quite simple:
   When an IETF participant feels that matters have not been conducted
   properly, they should state their concern to a member of IETF
   management.  In other words, the process relies upon those who have
   concerns raising them.  If the result is not satisfactory, there are
   several levels of appeal available, to ensure that review is possible
   by a number of people uninvolved in the matter in question.

   Reviews and appeals step through four levels, each in turn:

   WG Chair

     An appeal must begin with the management closest to the
     operation of the working group, even if the concern applies
     to their own handling of working group process.







Huizer & Crocker                                               [Page 15]

RFC 1603             IETF Working Group Guidelines            March 1994


   Area

     If discussion and review with the WG Chair do not produce a
     satisfactory result, the complainant may bring their concern
     to the cognizant Area Director.

   IESG

     If a concerned party is not satisfied with the results of
     the area-level review, then they may bring the matter to the
     IESG Chair and the Area Director for Standards & Processes.
     The IESG Chair and the Standards & Processes AD will bring
     the issue before the full IESG for an additional review and
     will report the resolution back to the parties.

   IAB

     The IAB provides a final opportunity to appeal the results
     of previous reviews.   If a concerned party does not accept
     the outcome of the IESG review, then they may take their
     concern to the IAB, by contacting the IAB Chair.

   Concerns entail either a disagreement with technical decisions by the
   working group or with the process by which working group business has
   been conducted.  Technical disagreements may be about specific
   details or about basic approach.  When an issue pertains to
   preference, it should be resolved within the working group.  When a
   matter pertains to the technical adequacy of a decision, review is
   encouraged whenever the perceived deficiency is noted.  For matters
   having to do with preference, working group rough consensus will
   dominate.

   When a matter pertains to working group process, it is important that
   those with a concern be clear about the manner in which the process
   was not open or fair and that they be willing to discuss the issue
   openly and directly.  In turn, the IETF management will make every
   effort to understand how the process was conducted, what deficiencies
   were present (if any) and how the matter should be corrected.  The
   IETF functions on the good will and mutual respect of its
   participants; continued success requires continued attention to
   working group process.

4.  WORKING GROUP TERMINATION

   Working groups are typically chartered to accomplish a specific task.
   After that task is complete, the group will be disbanded.  However if
   a WG produces a Proposed or Draft Standard, the WG will become
   dormant rather than disband (i.e., the WG will no longer conduct



Huizer & Crocker                                               [Page 16]

RFC 1603             IETF Working Group Guidelines            March 1994


   formal activities, but the mailing list will remain available to
   review the work as it moves to Draft Standard and Standard status.)

   If, at some point, it becomes evident that a working group is unable
   to complete the work outlined in the charter, the group, in
   consultation with its Area Director can either:

   1.   Recharter to refocus on a smaller task,

   2.   Choose new Chair(s), or

   3.   Disband.

   If the working group disagrees with the Area Director's choice, it
   may appeal to the IESG.

5.  STAFF ROLES

   Working groups require considerable care and feeding.  In addition to
   general participation, successful working groups benefit from the
   efforts of participants filling specific functional roles.

5.1. WG Chair

   The Working Group Chair is concerned with making forward progress
   through a fair and open process, and has wide discretion in the
   conduct of WG business.  The Chair must ensure that a number of tasks
   are performed, either directly or by others assigned to the tasks.
   This encompasses at the very least the following:

   Ensure WG process and content management

     The Chair has ultimate responsibility for ensuring that a
     working group achieves forward progress and meets its
     milestones.  For some working groups, this can be
     accomplished by having the Chair perform all management-
     related activities.  In other working groups -- particularly
     those with large or divisive participation -- it is helpful
     to allocate process and/or secretarial functions to other
     participants.  Process management pertains strictly to the
     style of working group interaction and not to its content.
     It ensures fairness and detects redundancy.  The secretarial
     function encompasses document editing.  It is quite common
     for a working group to assign the task of specification
     Editor to one or two participants.  Often, they also are
     part of the design team, described below.





Huizer & Crocker                                               [Page 17]

RFC 1603             IETF Working Group Guidelines            March 1994


   Moderate the WG email list

     The Chair should attempt to ensure that the discussions on
     this list are relevant and that they converge to consensus
     agreements. The Chair should make sure that discussions on
     the list are summarized and that the outcome is well
     documented (to avoid repetition).  The Chair also may choose
     to schedule organized on-line "sessions" with agenda and
     deliverables.  These are structured as true meetings,
     conducted over the course of several days (to allow
     participation across the Internet.)  Participants are
     expected to allocate time to the meeting, usually in the
     range of 1-2 hours per day of the "meeting".

   Organize, prepare and chair face-to-face & on-line formal sessions

     The Chair should plan and announce sessions well in advance.
     (See section on Session Planning for exact procedures.)

   Communicate results of sessions

     The Chair and/or Secretary must ensure that minutes of a
     session are taken and that an attendance list is circulated.
     See the section on Session Documents for detailed
     procedures.

     Immediately after a session, the WG Chair must immediately
     provide the Area Director with a very short report
     (approximately one paragraph, via email) on the session.
     This is used in an Area Report as presented in the
     Proceedings of each IETF meeting.

   Distribute the work

     Of course each WG will have participants who may not be able
     (or want) to do any work at all. Most of the time the bulk
     of the work is done by a few dedicated participants. It is
     the task of the Chair to motivate enough experts to allow
     for a fair distribution of the workload.

   Document development

     Working groups produce documents and documents need authors.
     The Chair will make sure that authors of WG documents
     incorporate changes as discussed by the WG.  See the section
     on Session Documents for details procedures.





Huizer & Crocker                                               [Page 18]

RFC 1603             IETF Working Group Guidelines            March 1994


   Document publication

     The Chair and/or Secretary will work with the RFC Editor to
     ensure document conformance with RFC publication
     requirements and to coordinate any editorial changes
     suggested by the RFC Editor.  A particular concern is that
     all participants are working from the same version of a
     document at the same time.

5.2. WG Editor/Secretary

   Taking minutes and editing working group documents often is performed
   by a specifically-designated participant or set of participants.  In
   this role, the Editor's job is to record WG decisions, rather than to
   perform basic specification.

5.3. WG Facilitator

   When meetings tend to become distracted or divisive, it often is
   helpful to assign the task of "process management" to one
   participant.  Their job is to oversee the nature, rather than the
   content, of participant interactions.  That is, they attend to the
   style of the discussion and to the schedule of the agenda, rather
   than making direct technical contributions themselves.

5.4. Design teams

   The majority of the detailed specification effort within a working
   group may be done by self-selecting sub-groups, called design teams,
   with the (implicit or explicit) approval of the working group.  The
   team may hold closed sessions for conducting portions of the
   specification effort. In some cases design teams are necessary to
   make forward progress when preparing a document.  All work conducted
   by a design team must be available for review by all working group
   participants and the design team must be responsive to the direction
   of the working group's consensus.

5.5. Area Consultant

   At the discretion of the AD, a Consultant may be assigned to a
   working group.  Consultants are senior participants in the IETF
   community.  They have technical background appropriate to the WG and
   experience in Internet architecture and IETF process.








Huizer & Crocker                                               [Page 19]

RFC 1603             IETF Working Group Guidelines            March 1994


5.6. Area Director

   Area Directors are responsible for ensuring that working groups in
   their area produce coherent, coordinated, architecturally consistent
   and timely output as a contribution to the overall results of the
   IETF. This very general description encompasses at the very least
   these detailed tasks related to working groups:

   Area planning

     The Area Director determines activities appropriate to the
     area.  This may include initiating working groups directly,
     rather than waiting for proposals from IETF participants.

   Coordination of WGs

     The Area Director coordinates the work done by the various
     WGs within (and sometimes even outside) the relevant area.

   IETF Meeting Schedule

     The Director tries to coordinate sessions in such a way that
     experts can attend the relevant sessions with a minimum of
     overlap and gaps between sessions. (See section on WG
     sessions for details.)

   Reporting

     The Area Director reports to the IETF on progress in the
     area.

   Reviewing

     The Area Director may appoint independent reviewers prior to
     document approval. The Area Director tracks the progress of
     documents from the area through the IESG review process, and
     report back on this to the WG Chair(s).

   Progress tracking

     The Area Director tracks and manages the progress of the
     various WGs with the aid of a regular status report on
     documents and milestones that is generated by the IESG
     Secretary. The Area Director forwards this report to the WG
     chairs.  This in turn helps the chairs to manage their WGs.






Huizer & Crocker                                               [Page 20]

RFC 1603             IETF Working Group Guidelines            March 1994


5.7. Area Directorate

   An area directorate consists of senior members of the technical
   community and are appointed by the Area Director who then tasks them
   with technical oversight and review of specific area activities.  An
   Area Director chairs the directorate.  At the request of the AD,
   directorate members conduct specification reviews and may be assigned
   as Area Consultants, to provide architectural assistance.

6.  WORKING GROUP DOCUMENTS

6.1. Session documents

   All relevant documents for a session (including the final agenda)
   should be published and available at least two weeks before a session
   starts.

   It is strongly suggested that the WG Chair make sure that an
   anonymous FTP directory be available for the upcoming session.  All
   relevant documents (including the final agenda and the minutes of the
   last session) should be placed in this directory.  This has the
   advantage that all participants can FTP all files in this directory
   and thus make sure they have all relevant documents. Also, it will be
   helpful to provide electronic mail-based retrieval for those
   documents.

6.2. IETF meeting document archive

   In preparing for an IETF meeting it is helpful to have ready access
   to all documents that are being reviewed. While documents usually are
   placed in the internet-drafts Internet Repository or in the
   respective working group archives or just published in some mail-
   lists, there are just too many things to browse or read through.
   Also, many documents are modified immediately before a meeting.

   The InterNIC Directory and Database Services provides a current-
   ietf-docs archive to enable people to get all documents that are
   relevant for the up-coming IETF meeting.  This document database will
   be removed two weeks after the IETF meeting.

   The completeness of this archive depends on the authors and working
   group chairs submitting the documents.  Each WG Chair is requested to
   submit the agenda to this archive.

   Structure of the archive:

   On ds.internic.net documents will be stored under the appropriate
   working group name under the appropriate area name in the directory:



Huizer & Crocker                                               [Page 21]

RFC 1603             IETF Working Group Guidelines            March 1994


          /pub/current-ietf-docs

   Each area will also have a directory called bof where a document to
   be discussed in a BOF meeting will be placed.  At the area level a
   directory called plenary will be created to hold documents or
   presentation material related to a plenary session.  Any filename
   conflicts will be resolved by the InterNIC's administrator and the
   submitter will be informed via electronic mail.  Example:

          /pub/current-ietf-docs/app/osids
          /pub/current-ietf-docs/int/sip

   Access via anonymous FTP:

   Anonymous FTP to ds.internic.net and change directory to

          /pub/current-ietf-docs/

   and browse and get the document of interest.

   Access via gopher:

   Connect to gopher.internic.net  and select the menu item:

          4.  InterNIC Directory and Database Services (AT&T)/

   and then the menu item:

          3.  Documents to be reviewed at the *** IETF

   One may use the public-access gopher client by:

          telnet gopher.internic.net

   Submission of documents via anonymous FTP:

   FTP to ds.internic.net and login as anonymous.  Change directory to:

          /incoming/current-ietf-docs

   Put the document using the following filename convention,

          <area>.<wgname>.<filename>
   e.g.:

          plenary.mondayVGs.ps
          app.osids.agenda
          app.osids.internic-talk-VGs.ps



Huizer & Crocker                                               [Page 22]

RFC 1603             IETF Working Group Guidelines            March 1994


   Note that the names of areas and working groups are their official
   short-form acronyms,

   Submission of documents via electronic mail:

   Send mail to

          admin@ds.internic.net

   with the following subject line:

          IETF - <area>.<wgname>.<filename>

   e.g.:

          IETF - app.osids.agenda

   NOTE:  Instead of sending a fresh copy of an already available
   document, you may ask the InterNIC's administrators to create a link
   to an existing internet-draft/RFC/ID

   NOTE:  If you do not remember your area or working group acronym get
   the file /ftp/ietf/1wg-summary.txt from ds.internic.net via anonymous
   FTP.

6.3. Internet-Drafts (I-D)

   The Internet-Drafts directory is provided to working groups as a
   resource for posting and disseminating early copies of working group
   documents. This repository is replicated at various locations around
   the Internet. It is encouraged that draft documents be posted as soon
   as they become reasonably stable.

   It is stressed here that Internet-Drafts are working documents and
   have no official standards status whatsoever. They may, eventually,
   turn into a standards-track document or they may sink from sight.
   Internet-Drafts are submitted to:

          internet-drafts@cnri.reston.va.us

   The format of an Internet-Draft must be the same as for an RFC [2].
   Further, an I-D must contain:

   -    Beginning, standard, boilerplate text which is provided by
        the Secretariat;

   -    The I-D filename; and




Huizer & Crocker                                               [Page 23]

RFC 1603             IETF Working Group Guidelines            March 1994


   -    The expiration date for the I-D.

   Complete specification of requirements for an Internet-Draft are
   found in the file:

          1id-guidelines.txt

   in the internet-drafts directory at an Internet Repository site.

6.4. Request For Comments (RFC)

   The work of an IETF working group usually results in publication of
   one or more documents, as part of the Request For Comments (RFCs) [2]
   series. This series is the archival publication record for the
   Internet community. A document can be written by an individual in a
   working group, by a group as a whole with a designated Editor, or by
   others not involved with the IETF. The designated author need not be
   the group Chair(s).

   NOTE:  The RFC series is a publication mechanism only and publication
   does not determine the IETF status of a document.  Status is
   determined through separate, explicit status labels assigned by the
   IESG on behalf of the IETF.  In other words, the reader is reminded
   that all Internet Standards are published as RFCs, but NOT all RFCs
   specify standards.

   For a description on the various categories of RFCs the reader is
   referred to [1, 4, 5, 6].

6.5. Submission of documents

   When a WG decides that a document is ready for publication, the
   following must be done:

   -    The version of the relevant document as approved by the WG
        must be in the Internet-Drafts directory;

   -    The relevant document must be formatted according to RFC
        rules [2].

   -    The WG Chair sends email to the relevant Area Director, with
        a copy to the IESG Secretary.  The mail should contain the
        reference to the document, and the request that it be
        progressed as an Informational, Experimental, Prototype or
        standards-track (Proposed, Draft or Internet Standard) RFC.

   The IESG Secretary will acknowledge receipt of the email.  Unless
   returned to the WG for further development, progressing of the



Huizer & Crocker                                               [Page 24]

RFC 1603             IETF Working Group Guidelines            March 1994


   document is then the responsibility of the IESG.  After IESG
   approval, responsibility for final disposition is the joint
   responsibility of the RFC Editor and the WG Chair and Editor.

6.6. Review of documents

   Usually in case of a submission intended as an Informational or
   Experimental RFC minimal review is necessary. However, if the WG or
   the RFC Editor thinks that an extensive review is appropriate, the
   Area Director may be asked to conduct one. This review may either be
   done by the AD and other IESG participants or the IESG may ask for an
   independent review (e.g., by someone not part of the WG in question)
   from the Area Directorate or elsewhere.

   A review will lead to one of three possible conclusions:

   1.   The document is accepted as is.

        This fact will be announced by the IESG Secretary to the
        IETF mailing list and to the RFC Editor. Publication is then
        further handled between the RFC Editor and the author(s).

   2.   Changes regarding content are suggested to the author(s)/WG.

        Suggestions must be clear and direct, so as to facilitate
        working group and author correction of the specification.
        Once the author(s)/WG have made these changes or have
        explained to the satisfaction of the reviewers why the
        changes are not necessary, the document will be accepted for
        publication as under point 1, above.

   3.   The document is rejected.

        This will need strong and thorough arguments from the
        reviewers. The whole IETF and working group process is
        structured such that this alternative is not likely to arise
        for documents coming from a working group. After all, the
        intentions of the document will already have been described
        in the WG charter, and reviewed at the start of the WG.

   If any individual or group of individuals feels that the review
   treatment has been unfair, there is the opportunity to make a
   procedural complaint. The mechanism for procedural complaints is
   described in the section on Contention and Appeal.

   Before the IESG makes a final decision on a standards-track document,
   the IESG Secretary will issue a "Last Call" to the IETF mailing list.
   This Last Call will announce the intention of the IESG to consider



Huizer & Crocker                                               [Page 25]

RFC 1603             IETF Working Group Guidelines            March 1994


   the document, and it will solicit final comments from the IETF within
   a period of two weeks.  It is important to note that a Last Call is
   intended as a brief, final check with the Internet community, to make
   sure that no important concerns have been missed or misunderstood.
   The Last Call cannot serve as a more general, in-depth review.

7.  SECURITY CONSIDERATIONS

   Security issues are not discussed in this memo.

8.  REFERENCES

   [1] Internet Architecture Board and Internet Engineering Steering
       Group, "The Internet Standards Process -- Revision 2", RFC 1602,
       IAB, IESG, March 1994.

   [2] Postel, J., "Instructions to RFC Authors", RFC 1543,
       USC/Information Sciences Institute, October 1993.

   [3] Malkin, G., and J. Reynolds, "F.Y.I. on F.Y.I. - Introduction to
       the F.Y.I. Notes", RFC 1150, Proteon, USC/Information Sciences
       Institute, March 1990.

   [4] Postel, J., Editor, "Introduction to the STD Notes", RFC 1311,
       USC/Information Sciences Institute, March 1992.

   [5] Postel, J., Editor, "Internet Official Protocol Standards", STD
       1, RFC 1600, IAB, March 1994.

   [6] Cerf, V., "The Internet Activities Board", RFC 1160, NRI, May
       1990.




















Huizer & Crocker                                               [Page 26]

RFC 1603             IETF Working Group Guidelines            March 1994


9.  AUTHORS' ADDRESSES

       Erik Huizer
       SURFnet bv
       P.O. Box 19035
       3501 DA  Utrecht
       The Netherlands

       Phone: +31 30 310290
       Fax: +31 30 340903
       EMail: Erik.Huizer@SURFnet.nl


       Dave Crocker
       Silicon Graphics, Inc.
       2011 N. Shoreline Blvd.
       P.O. Box 7311
       Mountain View, CA 94039

       Phone: +1 415 390 1804
       Fax: +1 415 962 8404
       EMail: dcrocker@sgi.com





























Huizer & Crocker                                               [Page 27]

RFC 1603             IETF Working Group Guidelines            March 1994


APPENDIX:  SAMPLE WORKING GROUP CHARTER

       Multiparty Multimedia Session Control (mmusic)

        Charter

        Chair(s):
            Eve Schooler  <schooler@isi.edu>
            Abel Weinrib  <abel@bellcore.com>

        Transport Area Director(s)
            Allison Mankin  <mankin@cmf.nrl.navy.mil>

        Mailing lists:
            General Discussion:confctrl@isi.edu
            To Subscribe:      confctrl-request@isi.edu
            Archive:           venera.isi.edu:~/confctrl/confcrtl.mail

       Description of Working Group:

       The demand for Internet teleconferencing has arrived, yet an
       infrastructure to support this demand is barely in place.
       Multimedia session control, defined as the management and
       coordination of multiple sessions and their multiple users in
       multiple media (e.g., audio, video), is one component of the
       infrastructure.  The Multiparty Multimedia Session Control
       Working Group is chartered to design and specify a protocol to
       perform these functions.

       The protocol will provide negotiation for session membership,
       underlying communication topology and media configuration.  In
       particular, the protocol will support a user initiating a
       multimedia multiparty session with other users ("calling" other
       users) over the Internet by allowing a teleconferencing
       application on one workstation to explicitly rendezvous with
       teleconferencing applications running on remote workstations.
       Defining a standard protocol will enable session-level
       interoperability between different teleconferencing
       implementations.

       The focus of the working group is to design a session negotiation
       protocol that is tailored to support tightly-controlled
       conferences.  The MBONE currently carries primarily loosely-
       controlled sessions, i.e., sessions with little to no interaction
       among members and with no arbitration facility, security, or
       coordination of quality-of-service options for time-critical
       media.  Users may learn of available sessions using the "sd"
       utility or other out of band mechanisms (e.g., email).  However,



Huizer & Crocker                                               [Page 28]

RFC 1603             IETF Working Group Guidelines            March 1994


       there is clearly also a need for tightly-controlled sessions that
       provide mechanisms for directly contacting other users to
       initiate a session and for negotiating conference parameters such
       as membership, media encodings and encryption keys.  In addition,
       these sessions should support renegotiation during a session, for
       example to add or delete members or change the media encoding.
       It is possible that the protocol will, in the limiting case, also
       support loosely-controlled sessions.

       The main goal of the working group will be to specify the session
       control protocol for use within teleconferencing software over
       the Internet.  The working group will focus on the aspects of the
       session control problem that are well understood, while keeping
       an eye on evolving research issues.  Toward this end, the working
       group has made an inventory of existing conferencing systems and
       their session control protocols.  The working group will document
       the requirements of the existing prototypes as a basis for the
       protocol development.  The working group will iteratively refine
       the protocol based on implementation and operational experience.

       Furthermore, the working group will coordinate with other efforts
       related to multimedia conferencing, such as directory services
       for cataloguing users and conferences, the RTP and RTCP protocols
       developed by the Audio/Video Transport Working Group, resource
       reservation and management at the network level, and schemes for
       multicast address allocation.

       Goals and Milestones:

            May 93     Hold an on-line working group meeting to discuss
                       the conference control framework, the relevant
                       terminology, a functional taxonomy and how
                       different conversational styles place
                       requirements on session protocols.

            Jun 93     Submit the Conference Session Control Protocol to
                       the IESG for consideration as an Experimental
                       Protocol.

            Aug 93     Post an Internet-Draft describing the Session
                       Control Requirements.

            Nov 93     Post an Internet-Draft of the Session Control
                       Protocol.

            Mar 94     Submit a revised Internet-Draft based on
                       implementation experience.




Huizer & Crocker                                               [Page 29]