summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4071.txt
blob: f9067e5be12513bb6541d70f650395c7a4b94138 (plain) (blame)
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
Network Working Group                                    R. Austein, Ed.
Request for Comments: 4071                                           ISC
BCP: 101                                                  B. Wijnen, Ed.
Category: Best Current Practice                      Lucent Technologies
                                                              April 2005


      Structure of the IETF Administrative Support Activity (IASA)

Status of This Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes the structure of the IETF Administrative
   Support Activity (IASA) as an activity housed within the Internet
   Society (ISOC).  It defines the roles and responsibilities of the
   IETF Administrative Oversight Committee (IAOC), the IETF
   Administrative Director (IAD), and ISOC in the fiscal and
   administrative support of the IETF standards process.  It also
   defines the membership and selection rules for the IAOC.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Definitions and Principles . . . . . . . . . . . . . . . . . .  3
       2.1.  Alphabet Soup  . . . . . . . . . . . . . . . . . . . . .  3
       2.2.  Principles of the IASA, IETF, and ISOC Relationship  . .  4
       2.3.  Community Consensus and Grant of Authority . . . . . . .  5
       2.4.  Termination and Change . . . . . . . . . . . . . . . . .  5
       2.5.  Effective Date for Commencement of IASA  . . . . . . . .  5
   3.  Structure of the IASA  . . . . . . . . . . . . . . . . . . . .  5
       3.1.  IAD Responsibilities . . . . . . . . . . . . . . . . . .  7
       3.2.  IAOC Responsibilities  . . . . . . . . . . . . . . . . .  9
       3.3.  Relationship of the IAOC to Existing IETF Leadership . . 10
       3.4.  IAOC Decision Making . . . . . . . . . . . . . . . . . . 10
       3.5.  Review and Appeal of IAD and IAOC Decision . . . . . . . 10
   4.  IAOC Membership, Selection and Accountability  . . . . . . . . 11
       4.1.  Initial IAOC Selection . . . . . . . . . . . . . . . . . 13





Austein & Wijnen         Best Current Practice                  [Page 1]
^L
RFC 4071                   Structure of IASA                  April 2005


   5.  IASA Funding . . . . . . . . . . . . . . . . . . . . . . . . . 14
       5.1.  Cost Center Accounting . . . . . . . . . . . . . . . . . 14
       5.2.  IETF Meeting Revenues  . . . . . . . . . . . . . . . . . 14
       5.3.  Designated Donations, Monetary and In-Kind . . . . . . . 14
       5.4.  Other ISOC Support . . . . . . . . . . . . . . . . . . . 15
       5.5.  IASA Expenses  . . . . . . . . . . . . . . . . . . . . . 15
       5.6.  Operating Reserve  . . . . . . . . . . . . . . . . . . . 15
   6.  IASA Budget Process  . . . . . . . . . . . . . . . . . . . . . 16
   7.  ISOC Responsibilities for IASA . . . . . . . . . . . . . . . . 16
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
       11.1. Normative References . . . . . . . . . . . . . . . . . . 18
       11.2. Informative References . . . . . . . . . . . . . . . . . 19

1.  Introduction

   This document describes the structure of the IETF Administrative
   Support Activity (IASA) as an activity housed within the Internet
   Society (ISOC).  It defines the roles and responsibilities of the
   IETF Administrative Oversight Committee (IAOC), the IETF
   Administrative Director (IAD), and ISOC in the fiscal and
   administrative support of the IETF standards process.  It also
   defines the membership and selection rules for the IAOC.

   The IETF undertakes its technical activities as an ongoing, open,
   consensus-based process.  This document defines an administrative
   support structure intended to be responsive to the administrative
   needs of the IETF technical community, and it describes how that
   support structure fits under ISOC's organizational umbrella.  This
   document does not affect the ISOC-IETF working relationship as it
   relates to standards development or the communication of technical
   advice relevant to the policy and educational goals of ISOC.

   The IETF Administrative Support Activity (IASA) provides the
   administrative structure required to support the IETF standards
   process and to support the IETF's technical activities.  As of the
   time at which this document was written, this included the work of
   IETF working groups, the IESG, the IAB, and the IRTF.  Should the
   IETF standards process at some future date come to include other
   technical activities, the IAOC is responsible for developing plans to
   provide administrative support for them.  Such support includes, as
   appropriate, undertaking or contracting for the work described in
   [RFC3716], including IETF document and data management, IETF
   meetings, and any operational agreements or contracts with the RFC
   Editor and the Internet Assigned Numbers Authority (IANA).  The IASA
   is also ultimately responsible for the financial activities



Austein & Wijnen         Best Current Practice                  [Page 2]
^L
RFC 4071                   Structure of IASA                  April 2005


   associated with IETF administrative support, such as collecting IETF
   meeting fees, paying invoices, managing budgets and financial
   accounts, and so forth.

   The IASA is responsible for ensuring that the IETF's administrative
   needs are met, and met well.  The IETF does not expect the IASA to
   undertake the bulk of this work directly; rather, the IETF expects
   the IASA to contract this work from others and to manage these
   contractual relationships to achieve efficiency, transparency, and
   cost effectiveness.

   The IASA is distinct from IETF-related technical functions, such as
   the RFC Editor, the IANA, and the IETF standards process itself.  The
   IASA has no influence on the technical decisions of the IETF or on
   the technical contents of IETF work.  Note, however, that this in no
   way prevents people who form part of the IASA from participating as
   individuals in IETF technical activities.

2.  Definitions and Principles

   This section describes terminology and underlying principles used in
   the rest of this document.

2.1.  Alphabet Soup

   Although most of the terms, abbreviations, and acronyms used in this
   document are reasonably well known, first-time readers may find this
   alphabet soup confusing.  This section therefore attempts to provide
   a quick summary.

   IAB: Internet Architecture Board (see [RFC2026], [RFC2850]).

   IAD: IETF Administrative Director, defined by this document.

   IAOC: IETF Administrative Oversight Committee, defined by this
         document.

   IASA: IETF Administrative Support Activity, defined by this document.

   IESG: Internet Engineering Steering Group (see [RFC2026], [RFC3710]).

   IETF: Internet Engineering Task Force (see [RFC3233]).

   ISOC: Internet Society (see [RFC2031] and [ISOC]).







Austein & Wijnen         Best Current Practice                  [Page 3]
^L
RFC 4071                   Structure of IASA                  April 2005


2.2.  Principles of the IASA, IETF, and ISOC Relationship

   This section attempts to describe principles underlying the
   mechanisms described in this document.

   1.  The IETF intends to establish a structure (the IASA) in order to
       have IETF administrative functions managed appropriately,
       according to good administrative, fiscal, and management
       principles.  The IASA includes the IAD and the IAOC and shall be
       housed within ISOC.

   2.  The IAD and IAOC shall not have any authority over the IETF
       standards development activities.  This document does not modify
       ISOC's other roles related to the IETF standards process.

   3.  The IAD and IAOC, in cooperation with the ISOC President/CEO and
       staff, shall develop an annual budget for the IASA.  The budget
       must clearly identify all expected direct and indirect
       expenditures related to the IASA.  ISOC, through its normal
       procedures, shall evaluate and approve the IASA budget as part of
       ISOC's own budget process and commit to ensuring funds to support
       the approved budget.

   4.  Responsibility for the evaluation, review, and negotiation of
       contracts and other IETF administrative and support agreements
       and other expenditures of funds under the IASA shall rest with
       the IAD, operating in accordance with policies and procedures set
       by the IAOC and consistent with ISOC operating policies.

   5.  Once funds or in-kind donations have been credited to the IASA
       accounts, they shall be irrevocably allocated to the support of
       the IETF.

   6.  There shall be a detailed public accounting to separately
       identify all funds available to and all expenditures relating to
       the IETF and to the IASA, including any donations, of funds or in
       kind, received by ISOC for IETF-related activities.  In-kind
       donations shall only be accepted at the direction of the IAD and
       IAOC.

   7.  Amongst the IETF, IASA and ISOC, the IETF, through the IASA,
       shall have a perpetual right to use, display, distribute,
       reproduce, modify, and create derivatives of all software and
       data created in support of IETF activities.







Austein & Wijnen         Best Current Practice                  [Page 4]
^L
RFC 4071                   Structure of IASA                  April 2005


   8.  The IASA, in cooperation with ISOC, shall use reasonable efforts
       to ensure that sufficient reserves exist to keep the IETF
       operational in the case of unexpected events such as income
       shortfalls.

   The remainder of this document contains details based on the above
   principles.

2.3.  Community Consensus and Grant of Authority

   The IETF is a consensus-based group, and authority to act on behalf
   of the community requires a high degree of consensus and the
   continued consent of the community.  After a careful process of
   deliberation, a broad-based community consensus emerged to house the
   IETF Administrative Support Activity (IASA) within the Internet
   Society.  This document reflects that consensus.

2.4.  Termination and Change

   Any change to this agreement shall require a similar level of
   community consensus and deliberation and shall be reflected by a
   subsequent Best Current Practice (BCP) document.

2.5.  Effective Date for Commencement of IASA

   The procedures in this document shall become operational after this
   document has been approved by the process defined in BCP 9 [RFC2026],
   including its acceptance as an IETF process BCP by the ISOC Board of
   Trustees, and after the ISOC Board of Trustees has confirmed its
   acceptance of ISOC's responsibilities under the terms herein
   described.

3.  Structure of the IASA

   The IASA structure is designed to ensure accountability and
   transparency of the IETF administrative and fiscal activities to the
   IETF community.  The IETF Administrative Oversight Committee (IAOC)
   directs and oversees the IASA.  The IAOC consists of volunteers, all
   chosen directly or indirectly by the IETF community, as well as
   appropriate ex officio members from ISOC and IETF leadership.  The
   IAOC shall be accountable to the IETF community for the
   effectiveness, efficiency, and transparency of the IASA.

   The IASA consists initially of a single full-time ISOC employee, the
   IETF Administrative Director (IAD), who is entitled to act on behalf
   of the IASA at the direction of the IAOC.  The IAD is likely to draw
   on financial, legal, and administrative support furnished by ISOC
   support staff or consultants.  Costs for ISOC support staff and



Austein & Wijnen         Best Current Practice                  [Page 5]
^L
RFC 4071                   Structure of IASA                  April 2005


   consultants are allocated based on actual expenses or on some other
   allocation model determined by consultation between the IAOC and
   ISOC.

   Although the IAD is an ISOC employee, he or she works under the
   direction of the IAOC.  A committee of the IAOC is responsible for
   hiring and firing the IAD, for reviewing the IAD's performance, and
   for setting the compensation of the IAD.  The members of this
   committee are appointed by the IAOC and consist at minimum of the
   ISOC President, the IETF Chair, and one of the Nomcom-appointed IAOC
   members.

   The IAOC determines what IETF administrative functions are to be
   performed, and how or where they should be performed (whether
   internally within the IASA or by outside organizations), so as to
   maintain an optimal balance of functional performance and cost of
   each such function.  The IAOC should document all such decisions, and
   the justification for them, for review by the community.  Each
   function should be reviewed on a regular basis using the assumption
   that, absent such justification, the function is either unnecessary
   or, if necessary, it is overstaffed, rather than using an assumption
   that anything that has been done in the past is still necessary; each
   function should be adjusted as needed given the result of this
   review.

   The IAD is responsible for negotiating and maintaining contracts or
   equivalent instruments with outside organizations, and for providing
   any coordination necessary to make sure that the IETF administrative
   support functions are covered properly.  All functions, whether
   contracted to outside organizations or performed internally within
   the IASA, must be clearly specified and documented with well-defined
   deliverables, service level agreements, and transparent accounting
   for the cost of such functions.

   The IASA is responsible for managing all intellectual property rights
   (IPR), including but not limited to trademarks, and copyrights that
   belong to the IETF.  The IASA is also responsible for managing the
   ownership, registration, and administration of relevant domain names.
   The IASA is responsible for undertaking any and all required actions
   on behalf of the IETF to obtain, protect, and manage the rights that
   the IETF needs to carry out its work.

   If the IASA cannot comply with the procedures described in this
   document for legal, accounting, or practical reasons, the IAOC shall
   report that fact to the community, along with the variant procedure
   that the IAOC intends to follow.  If the problem is a long-term one,
   the IAOC shall ask the IETF to update this document to reflect the
   changed procedure.



Austein & Wijnen         Best Current Practice                  [Page 6]
^L
RFC 4071                   Structure of IASA                  April 2005


3.1.  IAD Responsibilities

   The IAD is responsible for working with the IAOC and others to
   understand the administrative requirements of the IETF, and for
   managing the IASA to meet those needs.  This includes determining the
   structure of the IASA effort, establishing an operating budget,
   negotiating contracts with service providers, managing the business
   relationship with those providers, and establishing mechanisms to
   track their performance.  The IAD may also manage other contractors
   or ISOC employees (such as support staff) as necessary, when such
   contractors or employees are engaged in IASA-related work.

   The IAD is responsible for running the IASA in an open and
   transparent manner, and for producing regular monthly, quarterly, and
   annual financial and operational updates for IAOC and IETF community
   review.

   The IAD is responsible for administering the IETF finances, for
   managing separate financial accounts for the IASA, and for
   establishing and administering the IASA budget.  The IAD (with IAOC
   approval, as appropriate) should have signing authority consistent
   with carrying out IASA work effectively, efficiently and
   independently, taking into account ISOC's financial and approval
   controls.  If there are any problems regarding the level of financial
   approval granted to the IAD, the IAOC and ISOC shall work out a
   policy that is mutually agreeable, and they shall do so within a
   reasonable time frame.

   The IAD negotiates service contracts, with input, as appropriate,
   from other bodies, including legal advice, and with review, as
   appropriate, by the IAOC.  The IAOC should establish guidelines for
   what level of review is expected based on contract type, size, cost,
   or duration.  ISOC executes contracts on behalf of the IASA, after
   whatever review ISOC requires to ensure that the contracts meet
   ISOC's legal and financial guidelines.

   The IAD shall ensure that contracts entered into by ISOC on behalf of
   the IASA and/or the IETF (an "IASA Contract") that provide for the
   creation, development, modification, or storage of any data
   (including, without limitation, any data relating to IETF membership,
   documents, archives, mailing lists, correspondence, financial
   records, personnel records and the like) ("Data"), grant to ISOC the
   perpetual, irrevocable right, on behalf of IASA and IETF, to use,
   display, distribute, reproduce, modify and create derivatives of such
   Data.  ISOC will permit IASA and its designee(s) to have sole control
   and custodianship of such Data, and ISOC will not utilize or access
   such Data in connection with any ISOC function other than IETF
   without the written consent of the IAD.



Austein & Wijnen         Best Current Practice                  [Page 7]
^L
RFC 4071                   Structure of IASA                  April 2005


   The IAD shall ensure that personal data collected for legitimate
   purposes of the IASA are protected appropriately; at minimum, such
   data must be protected to a degree consistent with relevant
   legislation and applicable privacy policies.

   If an IASA Contract provides for the creation, development, or
   modification of any software (including, without limitation, any
   search tools, indexing tools, and the like) ("Developed Software"),
   then the IAD shall, whenever reasonable and practical, ensure that
   such contract either (a) grants ownership of such Developed Software
   to ISOC, or (b) grants ISOC a perpetual, irrevocable right, on behalf
   of IASA and IETF, to use, display, distribute, reproduce, modify, and
   create derivatives of such Software (including, without limitation,
   pursuant to an open source style license).  It is preferred that
   Developed Software be provided and licensed for IASA and IETF use in
   source code form, with no ongoing payments.  ISOC will permit the
   IASA and its designee(s) to have sole control and custodianship of
   such Developed Software.  The foregoing rights are not required in
   the case of off-the-shelf or other commercially-available software
   that is not developed at the expense of ISOC.

   If an IASA Contract relates to the licensing of third-party software,
   the IAD shall ensure that such license expressly permits use of such
   software for and on behalf of the IASA and/or the IETF, as
   applicable, and that such license is transferable in accordance with
   the provisions of Section 7 (Removability).

   Notwithstanding the foregoing, the IAD can enter into different terms
   if doing so is in the best interest of the IETF and upon approval of
   the IAOC.

   The IAD and IAOC are responsible for making all business decisions
   regarding the IASA.  In particular, the ISOC Board of Trustees shall
   not have direct influence over the choice of IASA contractors or IETF
   meeting sponsors.  This restriction is meant to enforce the
   separation between fund-raising and the actual operation of the
   standards process.

   The IAD prepares an annual budget, which is subject to review and
   approval by the IAOC.  The IAD is responsible for presenting this
   budget to the ISOC Board of Trustees, as part of ISOC's annual
   financial planning process.  As described elsewhere in this document,
   the IAOC is responsible for ensuring the budget's suitability for
   meeting the IETF community's administrative needs, but the IAOC does
   not bear fiduciary responsibility for ISOC.  The ISOC Board of
   Trustees therefore needs to review and understand the budget and
   planned activity in enough detail to carry out its fiduciary
   responsibility properly.  The IAD is responsible for managing this



Austein & Wijnen         Best Current Practice                  [Page 8]
^L
RFC 4071                   Structure of IASA                  April 2005


   process of review and approval.  The IAD sees to it that the IASA
   publishes its complete approved budget to the IETF community each
   year.

3.2.  IAOC Responsibilities

   The IAOC's role is to provide appropriate direction to the IAD, to
   review the IAD's regular reports, and to oversee IASA functions to
   ensure that the administrative needs of the IETF community are being
   properly met.  The IAOC's mission is not to be engaged in the day-
   to-day administrative work of the IASA, but rather to provide
   appropriate direction, oversight, and approval.

   Therefore, the IAOC's responsibilities are as follows:

   o  To select the IAD and to provide high-level review and direction
      for his or her work.  This task should be handled by a sub-
      committee, as described above.

   o  To review the IAD's plans and contracts to ensure that they will
      meet the administrative needs of the IETF.

   o  To track whether the IASA functions are meeting the IETF
      community's administrative needs, and to work with the IAD to
      determine a plan for corrective action if they are not.

   o  To review the IAD's budget proposals to ensure that they will meet
      the IETF's needs, and to review the IAD's regular financial
      reports.

   o  To ensure that the IASA is run in a transparent and accountable
      manner.  Although the day-to-day work should be delegated to the
      IAD and others, the IAOC is responsible for ensuring that IASA
      finances and operational status are tracked appropriately, and
      that monthly, quarterly, and annual financial and operational
      reports are published to the IETF community.

   o  To designate, in consultation with the IAB and the IESG, the
      person or people who carry out the tasks that other IETF process
      documents say are carried out by the IETF Executive Director.

   The IAOC's role is to direct and review, not to perform, the work of
   the IAD and IASA.  The IAOC holds periodic teleconferences and face-
   to-face meetings as needed to carry out the IAOC's duties efficiently
   and effectively.






Austein & Wijnen         Best Current Practice                  [Page 9]
^L
RFC 4071                   Structure of IASA                  April 2005


   If there is no IAD or if the IAD is unavailable, the IAOC may
   temporarily assign the IAD's duties to individual members of the
   IAOC.

3.3.  Relationship of the IAOC to Existing IETF Leadership

   The IAOC is directly accountable to the IETF community for the
   performance of the IASA.  However, the nature of the IAOC's work
   involves treating the IESG and IAB as major internal customers of the
   administrative support services.  The IAOC and the IAD should not
   consider their work successful unless the IESG and IAB are also
   satisfied with the administrative support that the IETF is receiving.

3.4.  IAOC Decision Making

   The IAOC attempts to reach consensus on all decisions.  If the IAOC
   cannot achieve a consensus decision, then the IAOC may decide by
   voting.

   The IAOC decides the details about its decision-making rules,
   including its rules for quorum, conflict of interest, and breaking of
   ties.  These rules shall be made public.

   All IAOC decisions shall be recorded in IAOC minutes, and IAOC
   minutes shall be published in a timely fashion.

3.5.  Review and Appeal of IAD and IAOC Decision

   The IAOC is directly accountable to the IETF community for the
   performance of the IASA.  In order to achieve this, the IAOC and IAD
   will ensure that guidelines are developed for regular operational
   decision making.  Where appropriate, these guidelines should be
   developed with public input.  In all cases, they must be made public.

   If a member of the IETF community questions whether a decision or
   action of the IAD or the IAOC has been undertaken in accordance with
   IETF BCPs or IASA operational guidelines, or questions whether the
   IASA has created and maintained appropriate guidelines, he or she may
   ask the IAOC for a formal review of the decision or action.

   The request for review should be addressed to the IAOC chair and
   should include a description of the decision or action to be
   reviewed, an explanation of how, in the requestor's opinion, the
   decision or action violates the BCPs or operational guidelines, and a
   suggestion for how the situation could be rectified.  All requests
   for review shall be posted publicly, and the IAOC is expected to
   respond to these requests within a reasonable period, typically
   within 90 days.  It is up to the IAOC to determine what type of



Austein & Wijnen         Best Current Practice                 [Page 10]
^L
RFC 4071                   Structure of IASA                  April 2005


   review and response is required, based on the nature of the review
   request.  Based on the results of the review, the IAOC may choose to
   overturn their own decision, to change their operational guidelines
   to prevent further misunderstandings, to take other action as
   appropriate, or just to publish the review result and take no other
   action.

   If a member of the community is not satisfied with the IAOC's
   response to his or her review request, he or she may escalate the
   issue by appealing the decision or action to the IAB, using the
   appeals procedures outlined in RFC 2026 [RFC2026].  If he or she is
   not satisfied with the IAB response, he or she can escalate the issue
   to the ISOC Board of Trustees, as described in RFC 2026.

   The reviewing body (the IAB or ISOC Board of Trustees) shall review
   the decision of the IAD or IAOC to determine whether it was made in
   accordance with existing BCPs and operational guidelines.  As a
   result of this review, the reviewing body may recommend to the
   community that the BCPs governing IAOC actions should be changed.
   The reviewing body may also advise the IAOC to modify existing
   operational guidelines to avoid similar issues in the future and/or
   it may advise the IAOC to re-consider their decision or action.  It
   may also recommend that no action be taken, based on the review.

   In exceptional cases, when no other recourse seems reasonable, the
   reviewing body may overturn or reverse a non-binding decision or
   action of the IAOC.  This should be done only after careful
   consideration and consultation with the IAOC regarding the
   ramifications of this action.  In no circumstances may the IAB or
   ISOC Board of Trustees overturn a decision of the IAOC that involves
   a binding contract or overturn a personnel-related action (such as
   hiring, firing, promotion, demotion, performance reviews, salary
   adjustments, etc.).

4.  IAOC Membership, Selection and Accountability

   The IAOC shall consist of eight voting members who shall be selected
   as follows:

   o  Two members appointed by the IETF Nominations Committee (NomCom);

   o  One member appointed by the IESG;

   o  One member appointed by the IAB;

   o  One member appointed by the ISOC Board of Trustees;

   o  The IETF Chair (ex officio);



Austein & Wijnen         Best Current Practice                 [Page 11]
^L
RFC 4071                   Structure of IASA                  April 2005


   o  The IAB Chair (ex officio);

   o  The ISOC President/CEO (ex officio).

   The IETF Administrative Director also serves, ex officio, as a non-
   voting member of the IAOC.

   The IAOC may also choose to invite liaisons from other groups, but it
   is not required to do so; the IAOC decides whether to have a liaison
   to any particular group.  Any such liaisons are non-voting.
   Responsibility for selecting the individual filling a particular
   liaison role lies with the body from which the IAOC has requested the
   liaison.

   Subject to paragraph 2 of Section 4.1, appointed members of the IAOC
   serve two-year terms.  IAOC terms normally end at the end of the
   first IETF meeting of a year.

   The members of the IAOC shall select one of its appointed voting
   members to serve as the chair of the IAOC.  The term of the IAOC
   chair shall be one year from the time of selection or the remaining
   time of his or her tenure on the IAOC, whichever is less.  An
   individual may serve any number of terms as chair, if selected by the
   IAOC.

   The Chair serves at the pleasure of the IAOC and may be removed from
   that position at any time by a vote of 2/3 of the voting IAOC
   members, not counting the IAOC chair.

   The chair of the IAOC shall have the authority to manage the
   activities and meetings of the IAOC.

   The two NomCom-appointed IAOC members are chosen using the procedures
   described in RFC 3777 [RFC3777].  For the initial IAOC selection, the
   IESG will provide the list of desired qualifications for these
   positions; in later years, the IAOC will provide this qualification
   list.  The IESG will serve as the confirming body for IAOC
   appointments by the NomCom.

   While there are no hard rules regarding how the IAB and the IESG
   should select members of the IAOC, such appointees need not be
   current IAB or IESG members (and probably should not be, if only to
   avoid overloading the existing leadership).  The IAB and IESG should
   choose people with some knowledge of contracts and financial
   procedures, who are familiar with the administrative support needs of
   the IAB, the IESG, or the IETF standards process.  The IAB and IESG
   should follow a fairly open process for these selections, perhaps
   with an open call for nominations or a period of public comment on



Austein & Wijnen         Best Current Practice                 [Page 12]
^L
RFC 4071                   Structure of IASA                  April 2005


   the candidates.  The procedure for IAB selection of ISOC Board of
   Trustees [RFC3677] might be a good model for how this could work.
   After the IETF gains some experience with IAOC selection, these
   selection mechanisms should be documented more formally.

   Although the IAB, the IESG, and the ISOC Board of Trustees choose
   some members of the IAOC, those members do not directly represent the
   bodies that chose them.  All members of the IAOC are accountable
   directly to the IETF community.  To receive direct feedback from the
   community, the IAOC holds an open meeting at least once per year at
   an IETF meeting.  This may take the form of an open IAOC plenary or a
   working meeting held during an IETF meeting slot.  The form and
   contents of this meeting are left to the discretion of the IAOC
   Chair.  The IAOC should also consider open mailing lists or other
   means to establish open communication with the community.

   IAOC members are subject to recall in the event that an IAOC member
   abrogates his or her duties or acts against the best interests of the
   IETF community.  Any appointed IAOC member, including any appointed
   by the IAB, IESG, or ISOC Board of Trustees, may be recalled using
   the recall procedure defined in RFC 3777 [RFC3777].  IAOC members are
   not, however, subject to recall by the bodies that appointed them.

   If a vacancy occurs among the appointed members, this is filled by
   the appointing body for that position according to its procedures.

   The IAOC members shall not receive any compensation from the IASA,
   ISOC, or IETF for their services as members of the IAOC.

   The IAOC shall set and publish rules covering reimbursement of
   expenses, and such reimbursement shall generally be for exceptional
   cases only.

4.1.  Initial IAOC Selection

   The initial IAOC selection will start after this document is approved
   as a BCP by the IESG and accepted by the ISOC Board of Trustees.  The
   IESG, IAB, and ISOC Board of Trustees should make their selections
   within 45 days of BCP approval, and the NomCom should make their
   selections as quickly as possible while complying with the documented
   NomCom procedures.  The IAOC will become active as soon as a majority
   (three or more) of the appointed members have been selected.

   Initially, the IESG and the ISOC Board of Trustees will make one-year
   appointments, the IAB will make a two-year appointment, and the
   NomCom will make one one-year appointment and one two-year
   appointment.  This will establish a pattern in which approximately
   half of the IAOC is selected each year.



Austein & Wijnen         Best Current Practice                 [Page 13]
^L
RFC 4071                   Structure of IASA                  April 2005


5.  IASA Funding

   The IASA manages money from three sources:

   1.  IETF meeting revenues;

   2.  Designated donations to ISOC (both monetary and in-kind);

   3.  Other ISOC support.

   Note that the goal is to achieve and maintain a viable IETF support
   function based on available funding sources.  The IETF community
   expects the IAOC and ISOC to work together to attain that goal.

5.1.  Cost Center Accounting

   Funds managed by the IASA shall be accounted for in a separate set of
   general ledger accounts within the IASA Cost Center.  In the
   remainder of this document, these general ledger accounts are termed
   "IASA accounts".  A periodic summary of the IASA accounts shall be
   reported in the form of standard financial statements that reflect
   the income, expenses, assets, and liabilities of the IASA.

   The IAOC and ISOC shall agree upon and publish procedures for
   reporting and auditing of these accounts.

   Note that ISOC in consultation with the IAOC can decide to structure
   the IASA accounting differently in the future within the constraints
   outlined in Section 7.

5.2.  IETF Meeting Revenues

   Meeting revenues are an important source of funds for IETF functions.
   The IAD, in consultation with the IAOC, sets the meeting fees as part
   of the budgeting process.  All meeting revenues shall be credited to
   the appropriate IASA accounts.

5.3.  Designated Donations, Monetary and In-Kind

   Donations are an essential component of funding.  The IASA undertakes
   no direct fund-raising activities.  This establishes a practice of
   separating IETF administrative and standards activities from fund-
   raising activities, and it helps ensure that no undue influence may
   be ascribed to those from whom funds are raised.

   ISOC shall create and maintain appropriate structures and programs to
   coordinate donations intended to support the work of the IETF, and
   these shall include mechanisms for both in-kind and direct



Austein & Wijnen         Best Current Practice                 [Page 14]
^L
RFC 4071                   Structure of IASA                  April 2005


   contributions to the work supported by IASA.  Since ISOC will be the
   sole entity through whom donations may be made to the work of the
   IETF, ISOC shall ensure that those programs are not unduly
   restrictive.  ISOC shall maintain programs that allow for designated
   donations to the IETF.

   In-kind resources are owned by the ISOC on behalf of the IETF and
   shall be reported and accounted for in a manner that identifies them
   as such.  Designated monetary donations shall be credited to the
   appropriate IASA accounts.

5.4.  Other ISOC Support

   Other ISOC support shall be based on the budget process as specified
   in Section 6, which includes deciding when ISOC monetary support is
   to be credited to the IASA accounts.

   All ISOC support, no matter how it is delivered, shall be reported in
   the IASA financial reports.

5.5.  IASA Expenses

   The IASA exists to support the IETF.  Funds designated for the IASA
   shall be used solely to support IETF activities and for no other
   purposes.

5.6.  Operating Reserve

   As an initial guideline and in normal operating circumstances, the
   IASA should have an operating reserve for its activities sufficient
   to cover 6 months of non-meeting operational expenses, plus twice the
   recent average for meeting contract guarantees.  The IASA, in
   cooperation with ISOC, shall establish detailed targets for a reserve
   fund to cover normal operating expenses and meeting expenses, in
   accordance with prudent planning and as part of the budget process.

   The IASA expects ISOC to use reasonable efforts to build and provide
   that operational reserve, through whatever mechanisms ISOC deems
   appropriate.

   If the IASA accounts accumulate a surplus, ISOC may count that as
   part of the reserve.









Austein & Wijnen         Best Current Practice                 [Page 15]
^L
RFC 4071                   Structure of IASA                  April 2005


6.  IASA Budget Process

   While the IASA sets a budget for the IETF's administrative needs, its
   budget process clearly needs to be closely coordinated with ISOC's.
   The specific timeline shall be established each year by IASA and
   ISOC.  As an example, a general annual timeline for budgeting is:

   July 1: The IAD presents a budget proposal (prepared in consultation
      with ISOC staff) for the following fiscal year, with 3-year
      projections, to the IAOC.

   August 1: The IAOC approves the budget proposal for IETF purposes,
      after any appropriate revisions.  As the ISOC President is part of
      the IAOC, the IAOC should have a preliminary indication of how the
      budget will fit with ISOC's own budgetary expectations.  The
      budget proposal is passed to the ISOC Board of Trustees for review
      in accordance with its fiduciary duty.

   September 1: The ISOC Board of Trustees approves the budget proposal
      provisionally.  During the next 2 months, the budget may be
      revised to be integrated in ISOC's overall budgeting process.

   November 1: Final budget to the ISOC Board for approval.

   The dates described above are examples and are subject to change.
   They will most likely be modified each year based on the dates of the
   second and third IETF meetings of that year.  They also need to be
   synchronized with the ISOC budgeting process.

   The IAD shall provide monthly accountings of expenses and shall
   update expenditures forecasts every quarter.  This may require
   adjustment of the IASA budget.  If so, the revised budget will need
   to be approved by the IAOC, the ISOC President/CEO and, if necessary,
   the ISOC Board of Trustees.

7.  ISOC Responsibilities for IASA

   Within ISOC, support for the IASA shall meet the following goals:

   Transparency: The IETF community shall have complete visibility into
      the financial and legal structure of the ISOC activities that are
      related to, but not part of, the IASA standards support activity.
      In particular, a detailed budget for the entire related ISOC
      activity, quarterly financial reports, and audited annual
      financial reports shall all be available to the IETF community.
      In addition, key contract material and MOUs shall also be publicly
      available, subject to any reasonable confidentiality obligations
      approved by the IAOC.



Austein & Wijnen         Best Current Practice                 [Page 16]
^L
RFC 4071                   Structure of IASA                  April 2005


   Unification: As part of this arrangement, ISOC's sponsorship of the
      RFC Editor, IAB and IESG shall be managed as part of the IASA
      under the IAOC.

   Independence: The IASA shall be distinct from other ISOC activities.
      ISOC shall support the IASA through the mechanisms specified in
      this document and its successors.

   Support: ISOC shall work with the IAD and IAOC to ensure appropriate
      financial support for the IASA, following the mechanisms described
      in this document and its successors.

   Removability: While there is no current plan to transfer the legal
      and financial home of the IASA to another corporation, the IASA
      shall be structured to enable a clean transition in the event that
      the IETF community decides that such a transition is required and
      documents its consensus in a formal document (currently called a
      BCP).  In such a case, the IAOC shall give ISOC a minimum of six
      months' notice before the transition formally occurs.  During that
      period, the IETF and ISOC shall work together to create a smooth
      transition that does not result in any significant service outages
      or missed IETF meetings.  All contracts executed by ISOC on behalf
      of the IASA shall either include a clause allowing termination by
      ISOC with six months notice, or be transferable to another
      corporation in the event that the IASA transitions away from ISOC.
      To the extent allowed by law, any balance in the IASA accounts,
      any IETF-specific intellectual property rights, and any IETF-
      specific data and tools shall also transition to the new entity.
      Other terms shall be negotiated between the IETF and ISOC.

   Within the constraints outlined above, all other details of how to
   structure this activity within ISOC (for instance, as a cost center,
   a division, or an affiliate) shall be determined by ISOC in
   consultation with the IAOC.

8.  Security Considerations

   This document describes the structure of the IETF's administrative
   support activity.  It introduces no security considerations for the
   Internet.

9.  IANA Considerations

   This document has no IANA considerations in the traditional sense.
   However, some of the information in this document may affect how the
   IETF standards process interfaces with the IANA, so the IANA may be
   interested in the contents.




Austein & Wijnen         Best Current Practice                 [Page 17]
^L
RFC 4071                   Structure of IASA                  April 2005


10.  Acknowledgements

   The editors would like to thank everyone who provided feedback on
   this document or any of its predecessors back to the original
   "Scenario O" e-mail message.  In particular, the editors would like
   to thank: Bernard Aboba, Jari Arkko, Fred Baker, Scott Bradner, Scott
   Brim, Brian Carpenter, Jorge Contreras, Dave Crocker, Elwyn Davies,
   Spencer Dawkins, Avri Doria, Tony Hain, Joel Halpern, Ted Hardie, Sam
   Hartman, Russel Housley, Geoff Huston, Jeff Hutzelman, John Klensin,
   Valdis Kletnieks, Eliot Lear, Henrik Levkowetz, Kurt Erik Lindqvist,
   John Loughney.  Carl Malamud, Allison Mankin, Tom Petch, Eric
   Rescorla, Pete Resnick, Glenn Ricart, Jonne Soininen, Lynn St. Amour,
   and Michael StJohns.

   Special thanks are due to Leslie Daigle and Margaret Wasserman, who
   wrote the original "Scenario O" message and edited the earliest
   versions of this document.

   Special thanks are also due to Henrik Levkowetz for kindly
   volunteering to maintain the issue tracking system associated with
   this document.

   Last, special thanks are due to Harald Alvestrand, for leading the
   search for consensus on the IETF mailing list.

   No doubt the above list is incomplete.  We apologize to anyone whom
   we left out.

   This document was written using the xml2rfc tool described in RFC
   2629 [RFC2629].

11.  References

11.1.  Normative References

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC3716]  IAB Advisory Committee, "The IETF in the Large:
              Administration and Execution", RFC 3716, March 2004.

   [RFC3777]  Galvin, J., "IAB and IESG Selection, Confirmation, and
              Recall Process: Operation of the Nominating and Recall
              Committees", BCP 10, RFC 3777, June 2004.







Austein & Wijnen         Best Current Practice                 [Page 18]
^L
RFC 4071                   Structure of IASA                  April 2005


11.2.  Informative References

   [ISOC]     Internet Society, "Internet Society By-Laws", February
              2001,
              <http://www.isoc.org/isoc/general/trustees/bylaws.shtml>.

   [RFC2031]  Huizer, E., "IETF-ISOC relationship", RFC 2031, October
              1996.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC2850]  Internet Architecture Board and B. Carpenter, "Charter of
              the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
              May 2000.

   [RFC3233]  Hoffman, P. and S. Bradner, "Defining the IETF", BCP 58,
              RFC 3233, February 2002.

   [RFC3677]  Daigle, L. and Internet Architecture Board, "IETF ISOC
              Board of Trustee Appointment Procedures", BCP 77, RFC
              3677, December 2003.

   [RFC3710]  Alvestrand, H., "An IESG charter", RFC 3710, February
              2004.

Authors' Addresses

   Rob Austein (editor)
   Internet Systems Consortium
   950 Charter Street
   Redwood City, CA  94063
   USA

   EMail: sra@isc.org


   Bert Wijnen (editor)
   Lucent Technologies
   Schagen 33
   3461 GL Linschoten
   NL

   Phone: +31-348-407-775
   EMail: bwijnen@lucent.com






Austein & Wijnen         Best Current Practice                 [Page 19]
^L
RFC 4071                   Structure of IASA                  April 2005


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Austein & Wijnen         Best Current Practice                 [Page 20]
^L