idnits 2.17.1
draft-malamud-consultant-report-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1.a on line 16.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 3884.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3861.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3868.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3874.
** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
Acknowledgement.
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission
of drafts without verbatim RFC 3978 boilerplate is not accepted.
The following non-3978 patterns matched text found in the document.
That text should be removed or replaced:
This document is an Internet-Draft and is subject to all provisions of
Section 3 of RFC 3667.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The abstract seems to contain references ([RFC3683], [RFC3184],
[RFC3005]), which it shouldn't. Please replace those with straight
textual mentions of the documents in question.
== There are 3 instances of lines with non-RFC2606-compliant FQDNs in the
document.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 61: '...rent Status--YOU MUST READ THIS SECTIO...'
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== Line 2106 has weird spacing: '... format speci...'
== Line 2524 has weird spacing: '... Nomcom and t...'
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (September 8, 2004) is 7169 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Unused Reference: 'RFC1958' is defined on line 2152, but no explicit
reference was found in the text
== Unused Reference: 'RFC3233' is defined on line 2196, but no explicit
reference was found in the text
== Unused Reference: 'RFC3667' is defined on line 2199, but no explicit
reference was found in the text
== Unused Reference: 'Eastlake' is defined on line 2277, but no explicit
reference was found in the text
== Unused Reference: 'Huxley' is defined on line 2293, but no explicit
reference was found in the text
== Unused Reference: 'RFC2134' is defined on line 2496, but no explicit
reference was found in the text
== Unused Reference: 'RFC3844' is defined on line 2415, but no explicit
reference was found in the text
** Downref: Normative reference to an Informational RFC: RFC 1958
** Obsolete normative reference: RFC 2028 (Obsoleted by RFC 9281)
** Obsolete normative reference: RFC 2031 (Obsoleted by RFC 8712)
** Obsolete normative reference: RFC 2223 (Obsoleted by RFC 7322)
** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)
** Downref: Normative reference to an Informational RFC: RFC 2555
** Downref: Normative reference to an Informational RFC: RFC 2860
** Obsolete normative reference: RFC 3005 (Obsoleted by RFC 9245)
** Obsolete normative reference: RFC 3184 (Obsoleted by RFC 7154)
** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978)
** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979)
** Downref: Normative reference to an Informational RFC: RFC 3710
** Downref: Normative reference to an Historic RFC: RFC 3716
** Downref: Normative reference to an Informational RFC: RFC 3774
** Obsolete normative reference: RFC 3777 (Obsoleted by RFC 7437)
== Outdated reference: A later version (-09) exists of
draft-narten-iana-considerations-rfc2434bis-00
-- Duplicate reference: RFC2135, mentioned in 'RFC2135', was also mentioned
in 'RFC2134'.
-- Obsolete informational reference (is this intentional?): RFC 2629
(Obsoleted by RFC 7749)
Summary: 22 errors (**), 0 flaws (~~), 13 warnings (==), 9 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group C. Malamud, Ed.
3 Internet-Draft Memory Palace Press
4 Expires: March 9, 2005 September 8, 2004
6 IETF Administrative Support Functions
7 draft-malamud-consultant-report-01
9 Status of this Memo
11 This document is an Internet-Draft and is subject to all provisions
12 of section 3 of RFC 3667. By submitting this Internet-Draft, each
13 author represents that any applicable patent or other IPR claims of
14 which he or she is aware have been or will be disclosed, and any of
15 which he or she become aware will be disclosed, in accordance with
16 RFC 3668.
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as
21 Internet-Drafts.
23 Internet-Drafts are draft documents valid for a maximum of six months
24 and may be updated, replaced, or obsoleted by other documents at any
25 time. It is inappropriate to use Internet-Drafts as reference
26 material or to cite them other than as "work in progress."
28 The list of current Internet-Drafts can be accessed at
29 http://www.ietf.org/ietf/1id-abstracts.txt.
31 The list of Internet-Draft Shadow Directories can be accessed at
32 http://www.ietf.org/shadow.html.
34 This Internet-Draft will expire on March 9, 2005.
36 Copyright Notice
38 Copyright (C) The Internet Society (2004).
40 Abstract
42 This Internet-Draft discusses the restructuring of administrative
43 support functions for the IETF. The draft begins with a discussion
44 of prior steps in the process that led up to this report and
45 discusses the process going forward. The draft then examines the
46 current functioning of administrative support functions, analyzes
47 options for restructuring operational functions, and analyzes options
48 available to provide an institutional framework for such support.
50 The provision of such administrative support functions is limited in
51 scope with responsibility only for the administrative, fiscal, and
52 legal infrastructure needed to support the IETF community. In
53 particular, issues such as defining and managing the standards-making
54 process and the governance of that process are explicitly out of
55 scope for this restructuring.
57 This Internet-Draft is an independent consultant's report and should
58 not be regarded as a consensus view or a policy statement. The
59 report contains only the author's views.
61 Current Status--YOU MUST READ THIS SECTION
63 This is a FIRST DRAFT and DOES NOT represent a position or a
64 consensus. It should be regarded as a starting point for community
65 discussion, followed by eventual decision making by the leadership
66 based on a community consensus.
68 In particular, the key word "we" in this document is to be
69 interpreted as meaning "I, the author". This document does not
70 represent a consensus, policies, or opinions that are to be
71 attributed to anything but the personal views of the author.
73 Intended Status and Mailing List
75 This document is intended for publication as an Internet-Draft and is
76 expected to undergo numerous revisions. It is intended that this
77 document be submitted for publication as an Informational RFC.
79 The forum for discussion of this draft is the IETF Discussion list
80 (ietf@ietf.org). The IETF Discussion List is defined in [RFC3005]
81 and further defined in [RFC3184] and [RFC3683].
83 Table of Contents
85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
86 1.1 Goals and Non-Goals . . . . . . . . . . . . . . . . . . . 5
87 1.1.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
88 1.1.2 IETF Standards Process Out of Scope . . . . . . . . . 5
89 1.1.3 ISOC Role in Standards Process Out of Scope . . . . . 6
90 1.2 Previous Steps in This Process . . . . . . . . . . . . . . 7
91 1.3 Decision Process . . . . . . . . . . . . . . . . . . . . . 7
92 1.4 Criteria for Judging an Administrative Restructuring . . . 8
93 1.5 Methodology . . . . . . . . . . . . . . . . . . . . . . . 8
94 2. Analysis of Current Administrative Framework . . . . . . . . . 10
95 2.1 Providers and Functions . . . . . . . . . . . . . . . . . 10
96 2.2 Function 1: Administration . . . . . . . . . . . . . . . . 11
97 2.3 Function 2: Meetings . . . . . . . . . . . . . . . . . . . 13
98 2.4 Function 3: Core Information Technology . . . . . . . . . 16
99 2.5 Function 4: Document and Information Flow . . . . . . . . 17
100 3. Recommendations for Restructuring the Administrative
101 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 20
102 3.1 Recommendation 1: Hire An Administrative Director . . . . 20
103 3.2 Recommendation 2: Establish Contracts for Core Services . 21
104 3.2.1 Details of Potential RFP Components . . . . . . . . . 24
105 3.3 Recommendation 3: Provide Timely and Uniform Financial
106 Reporting . . . . . . . . . . . . . . . . . . . . . . . . 28
107 3.4 Recommendation 4: More Focus on Archives . . . . . . . . . 28
108 4. Options for an Institutional Basis for Administrative
109 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . 30
110 4.1 Discussion of Organizational Form and Legal Domicile . . . 30
111 4.2 Scenario A: ISOC Operating Unit . . . . . . . . . . . . . 31
112 4.2.1 Division of the Internet Society . . . . . . . . . . . 31
113 4.2.2 Intended benefits . . . . . . . . . . . . . . . . . . 32
114 4.2.3 Additional Considerations . . . . . . . . . . . . . . 32
115 4.3 Scenario B: More Formalized ISOC Operating Unit . . . . . 33
116 4.4 Scenario C: Well-Defined Entity With Close Ties to ISOC . 35
117 4.4.1 How Scenario C Might Work In Practice . . . . . . . . 35
118 4.5 Scenario D: Autonomous Entity . . . . . . . . . . . . . . 41
119 4.6 Discussion of Unincorporated Associations . . . . . . . . 41
120 5. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 45
121 5.1 Short-Term . . . . . . . . . . . . . . . . . . . . . . . . 45
122 5.2 Long-Term . . . . . . . . . . . . . . . . . . . . . . . . 45
123 6. Acknowledgment of CNRI Contribution to the IETF Community . . 47
124 7. Acknowledgment of Contributions and Reviews . . . . . . . . . 48
125 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
126 9. Security Considerations . . . . . . . . . . . . . . . . . . . 50
127 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
128 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 51
129 10.2 Informative References . . . . . . . . . . . . . . . . . . . 52
130 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 60
131 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 60
132 A. Consulting Contract . . . . . . . . . . . . . . . . . . . . . 61
133 B. IETF Financial Information . . . . . . . . . . . . . . . . . . 65
134 B.1 Consolidated 3-Year Historical Income Statement . . . . . 65
135 B.2 Internet Society 2004 Budget Summary . . . . . . . . . . . 67
136 C. 10-Year Meeting Attendance Summary . . . . . . . . . . . . . . 70
137 C.1 Analysis of Meeting-Based Expense and Revenue Drivers . . 72
138 D. Sample Draft Incorporating Documents for a Hypothetical
139 IETF Foundation . . . . . . . . . . . . . . . . . . . . . . . 74
140 D.1 Sample Draft Articles of Incorporation . . . . . . . . . . 74
141 D.2 Sample Draft Bylaws of the IETF Foundation . . . . . . . . 74
142 D.2.1 Article I: Organization . . . . . . . . . . . . . . . 74
143 D.2.2 Article II: Purpose . . . . . . . . . . . . . . . . . 74
144 D.2.3 Article III: Members . . . . . . . . . . . . . . . . . 75
145 D.2.4 Article IV: Offices . . . . . . . . . . . . . . . . . 75
146 D.2.5 Article V: Board of Trustees . . . . . . . . . . . . . 75
147 D.2.6 Article VI: Officers . . . . . . . . . . . . . . . . . 79
148 D.2.7 Article VII: Amendments . . . . . . . . . . . . . . . 80
149 D.2.8 Article VIII: Dissolution . . . . . . . . . . . . . . 81
150 D.2.9 Article IX: Miscellaneous Provisions . . . . . . . . . 81
151 E. Sample Draft Call for Applications -- IETF Administrative
152 Director . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
153 F. Sample Draft Request for Proposals . . . . . . . . . . . . . . 85
154 F.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 85
155 F.2 General Provisions . . . . . . . . . . . . . . . . . . . . 86
156 F.3 Requirement 1: Core Network Infrastructure . . . . . . . . 87
157 F.4 Requirement 2: Systems Administration Services . . . . . . 87
158 F.5 Requirement 3: Postmaster of the IETF Administrative
159 Entity . . . . . . . . . . . . . . . . . . . . . . . . . . 87
160 F.6 Requirement 4: Webmaster of the IETF Administrative
161 Entity . . . . . . . . . . . . . . . . . . . . . . . . . . 88
162 F.7 Requirement 5: Meetings . . . . . . . . . . . . . . . . . 88
163 F.8 Requirement 6: Clerk of the IETF Administrative Entity . . 89
164 F.9 Selection Criteria and Evaluation Process . . . . . . . . 89
165 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
166 Intellectual Property and Copyright Statements . . . . . . . . 92
168 1. Introduction
170 1.1 Goals and Non-Goals
172 1.1.1 Goals
174 Any plan for restructuring the administrative support functions of
175 the IETF and for establishing an institutional foundation for those
176 administrative functions must meet three goals:
177 1. The IETF process must continue to work. The smooth and stable
178 operation of the IETF is paramount. Any changes that are made
179 should be made with the goal of making that process work better.
180 This means that the continuation of the current operation, the
181 transition, and the future steady-state must all be carefully
182 thought out and executed.
183 2. The administrative, fiscal, and legal processes--including those
184 that effect this restructuring--must be transparent to the IETF
185 community. Any potential IETF administrative support
186 organization must be accountable to the community. Both the
187 transition and the future steady state will require the support
188 of the community, which requires that we observe the IETF
189 processes for decision making and that all necessary information
190 for making those decisions be made publicly available.
191 Transparency of financial transactions and in the decision making
192 process are of particular importance.
193 3. Any organization that provides administrative support functions
194 for the IETF must be subservient to and support the existing IETF
195 structures and decision-making processes.
197 1.1.2 IETF Standards Process Out of Scope
199 This restructuring exercise is limited in scope to IETF
200 administrative functions. In particular, it does not cover areas
201 including (but not limited to) the following:
202 1. The IETF technical standards-making process.
203 2. Selection of the IETF leadership and operation of the nominating
204 committee.
205 3. Any other topics already covered in our existing procedure Best
206 Current Practices documents unless called out specifically here.
208 As will be seen in subsequent sections, we explicitly reference our
209 existing purpose, governance, process, and core values as they now
210 exist and as they may be changed in the future. A new institutional
211 home for the IETF administrative functions will not supplant the IETF
212 technical processes, it will support them.
214 1.1.3 ISOC Role in Standards Process Out of Scope
216 The Internet Society and the IETF both have the good of the Internet
217 as a primary mission goal. The Internet Society has a broader
218 mandate than the IETF. Those mandates are organized as the "Pillars"
219 of the Internet Society, and include the following activities:
220 o Pillar 1: Education & Training
221 o Pillar 2: Public Policy
222 o Pillar 3: Standards & Protocols
224 In support of these pillars, the Internet Society conducts global
225 conferences including INET and NDSS, and conducts or participates in
226 regional meetings either directly or through its chapters.
228 The IETF is focused exclusively on the standards and protocol
229 activity. The Internet Society plays a complementary and vital role
230 with an active education and policy effort that allows the IETF to
231 maintain a focus on protocols and standards.
233 The Internet Society is an international membership organization,
234 open to all organizations and individuals. ISOC supports the IETF
235 and IAB in a number of ways (as detailed below), historically raising
236 funds through Organization and Individual member dues. ISOC conducts
237 and/or participates in global conferences including INET and NDSS,
238 network training workshops for developing countries, topical
239 tutorials, and various policy forums. ISOC participates in many
240 regional meetings either directly or through its chapters.
242 While a variety of administrative functions provided by the Internet
243 Society will be considered in this document, it is important to state
244 at the outset that the Internet Society currently provides two
245 important functions to the IETF:
246 1. *Administration Functions.* As discussed in subsequent sections,
247 the Internet Society provides administrative and financial
248 functions, managing the contract with the RFC Editor, providing
249 insurance for selected IETF participants, and administering a
250 discretionary fund for use by the IAB and the IETF Chairs.
251 2. *Standards Process Functions* The Internet Society plays a
252 fundamental role in the IETF Standards Process, including
253 appointment of the Nominating Committee chair, confirmation of
254 IAB members, confirmation of documents that describe the
255 standards processes, and acting as the last resort in the appeals
256 process. These Standards Process Functions are defined in
257 [RFC2026], [RFC2028], [RFC2031], and [RFC3677] and are out of
258 scope for this analysis. No changes are proposed to these
259 Standards Process Functions.
261 Any changes to the *Standards Process Functions* would use the
262 existing procedures, which require a draft to progress through the
263 process, ultimately being subject to a Last Call and a declaration of
264 consensus. In the case of modifications to existing process BCP
265 RFCs, this is a high bar to cross.
267 1.2 Previous Steps in This Process
269 A process for restructuring IETF administrative support functions as
270 well as other more general IETF issues was started in 2002. This
271 process has resulted in a number of documents that have defined the
272 goals of the IETF and basic principles for restructuring (see, e.g.,
273 [I-D.alvestrand-ietf-mission]). The basic outline of the
274 administrative restructuring process was defined by an Advisory
275 Committee to the IAB, the results of which are published in
276 [RFC3716].
278 This document carries out the requirements of [RFC3716] in discussing
279 various options for administrative restructuring and the definition
280 of relationships with institutions which support the activities of
281 the IETF community.
283 The specific goals of the administrative restructuring effort, as
284 outlined in [I-D.daigle-adminrest], are to recognize and preserve the
285 community-driven nature of the IETF technical work, and to continue
286 to support that work through the formalization of a single
287 administrative umbrella organization that will be openly accountable
288 to that same community.
290 1.3 Decision Process
292 Restructuring of IETF administrative support functions is a
293 fundamental activity that must have the support of the IETF
294 community. This document attempts to present an "omnibus" plan,
295 addressing the full scope of the requirements stated in [RFC3716].
296 This document has already undergone numerous revisions, and will
297 undergo subsequent revisions based on input from the IETF community.
298 The first stage in reaching consensus around proposed changes include
299 the following steps:
300 1. Publication of [RFC3716].
301 2. Continued deliberation and issuance of Internet-Drafts on the
302 Administrative Restructuring.
303 3. A decision to "move forward" including a request for funding by
304 the IETF and IAB Chairs to the Internet Society Board of
305 Trustees, allocation of those funds, and the engagement of a
306 consultant.
307 4. Drafting of this draft.
308 5. Initial reviews of this draft, including reviews by the IAB,
309 IESG, ISOC Board, and legal counsel, and others.
311 6. Briefings to the community via the IETF discussion list and at
312 IETF60 about what to expect.
313 7. Publication as an Internet-Draft.
314 8. Discussion of the Internet-Draft in the IETF community. *<----
315 You Are Here.*
316 9. Reconsideration of the draft by the IAB, IESG, ISOC board, and
317 IETF legal counsel and issuance of a set of specific
318 recommendations by the IAB and/or IESG.
319 10. Issuance of a Last Call on this document and on the subsequent
320 memorandum published by the IESG and IAB.
321 11. Determination of community consensus on the updated plan.
322 12. Publication of this draft, as revised, as an Informational RFC.
323 13. Implementation, with periodic reporting back to the community.
324 At each stage, the draft will be revised as appropriate.
326 In addition, portions of this document are intended to form the basis
327 for one or more drafts containing new procedures or Memoranda of
328 Understanding related to the IETF administrative practices; these
329 would eventually be published as Best Current Practices (BCP) RFCs.
330 That process would begin after the initial community consensus.
332 1.4 Criteria for Judging an Administrative Restructuring
334 The guiding principles in the analysis of the administrative
335 restructuring are the criteria specified in [RFC3716], Section 3.
336 These criteria are worth restating:
337 1. Better resource management:
338 1.1 Uniform budgetary responsibility.
339 1.2 A uniform view of revenue sources
340 1.3 Clarity in the relationship with supporting organizations.
341 1.4 Flexibility to provision and reprovision services.
342 1.5 Administrative efficiency.
343 2. Stewardship:
344 2.1 Accountability for change.
345 2.2 Persistence and accessibility of records.
346 3. A better working environment:
347 3.1 More service automation where appropriate.
348 3.2 Better tools.
350 1.5 Methodology
352 Preparation of this report began on June 18, 2004 as part of a
353 consulting engagement to support the IETF and IAB chairs in the
354 restructuring effort, based on their request for funding
355 restructuring activities which was approved by the Internet Society
356 Board of Trustees. The contract is attached as Appendix A.
358 The following steps were used to gather input to this report:
360 o Initial briefings and continued close coordination with the Chairs
361 of the IAB and the IETF.
362 o A series of consultations with members of the IAB and IESG through
363 teleconferences, one-on-one email and phone conversations, and
364 face-to-face discussions at IETF60.
365 o A series of consultations with staff, officers, and board members
366 of the Internet Society.
367 o Discussions, by phone, email, and in person, with the staff of
368 Foretec Seminars, the Internet Society, the RFC Editor, and the
369 IANA, as well as a series of discussions with management at host
370 institutions including CNRI, ISI, and ICANN.
371 o A large number (over 100) of discussions by phone, email, and in
372 person with members of the community, including former members of
373 the leadership, and individuals known to represent a wide variety
374 of views.
375 o A detailed examination of relevant finances, including the
376 financial reports and tax returns of organizations providing
377 various support functions to the IETF.
378 o A detailed examination of operational issues, including the
379 functioning of key applications such as the Internet-Draft
380 Tracker, the operational and planning aspects of meetings, and the
381 functioning of the core IETF network presence.
382 o A detailed review of relevant documents, including electronic mail
383 archives, plenary transcripts, and RFCs, particularly the process
384 BCP RFCs.
385 o In cooperation with legal counsel, a detailed examination of the
386 current contractual framework and options available for
387 incorporation or otherwise providing more formalization of the
388 existing administrative structures, as well as a detailed
389 assessment of potential risks and liabilities of such a
390 transition.
392 2. Analysis of Current Administrative Framework
394 2.1 Providers and Functions
396 The IETF is an "open global community of network designers,
397 operators, vendors, and researchers producing technical
398 specifications for the evolution of the Internet architecture and the
399 smooth operation of the Internet."[RFC3233] A variety of institutions
400 provide administrative support to the IETF community:
401 o The Internet Society is "the organizational home of the Internet
402 Engineering Task Force (IETF), the Internet Architecture Board
403 (IAB), the Internet Engineering Steering Group (IESG), and the
404 Internet Research Task Force." [www.isoc.org] [1] The Internet
405 Society is a 501(c)(3) corporation with total 2002 revenues of
406 $1,695,833 and expenses of $1,681,064, of which $763,423 was
407 allocated as program expense to support the Standards Pillar of
408 the Internet Society [ISOC-2002]. The 2004 budget for the
409 Internet Society is attached in Appendix B.2. The Internet
410 Society and the IETF cooperate closely in a number of areas, as
411 defined in [RFC2026], [RFC2028], [RFC2031], and [RFC3677].
412 o Foretec Seminars, Inc., a for-profit subsidiary of the non-profit
413 Corporation for National Research Initiatives (CNRI), provides a
414 variety of support services, including the planning of meetings
415 three times per year, a network presence for IETF activities, and
416 secretariat services such as coordination of the flow of documents
417 through the IESG. CNRI is a non-profit corporation registered
418 under section 501(c)(3) of the US tax code [IRS] and has been
419 providing service to the IETF since 1986 (see Section 6 for more
420 details on these long-term contributions to the community). CNRI
421 owns approximately 96% of the shares of the Delaware-chartered
422 Foretec Seminars, Inc [CNRI-2002].
423 o Since 1969, the Requests for Comments (RFC) document series and
424 the office of the RFC Editor has been hosted at the Information
425 Sciences Institute (ISI). The RFC Editor's office and submission
426 process is further defined in [RFC2223],
427 [I-D.rfc-editor-rfc2223bis], and [RFC2555].
428 o The IETF has delegated the parameter registration function to the
429 IANA, which is hosted at ICANN. The relationship is defined in
430 [RFC2860]. IANA instructions for RFC authors are defined in
431 [RFC2434] and in [I-D.narten-iana-considerations-rfc2434bis].
433 For purposes of this analysis, we will examine these institutions
434 using a 4-part taxonomy of functions:
435 o *Function 1: Administration.* This function includes program
436 management tasks such as contract administration. It also
437 includes any legal matters and issues of financial reporting and
438 transparency.
440 o *Function 2: Meeting Planning.* This function includes the
441 planning and management of large events such as the IETF meetings
442 held three times per year, as well as more specialized activities
443 such as retreats and interim Working Group meetings.
444 o *Function 3: Core Information Technology.* This function includes
445 most of the network presence of the IETF, including the basic
446 provisioning of computing resources (e.g., colocation, name
447 service, routing, transit), and core services such as mail, web
448 site, rsync, and FTP.
449 o *Function 4: Document and Information Flow.* This function
450 includes the flow of information through the IETF process. While
451 Function 3, Core Information Technology, provides the basic
452 platform, Function 4 uses that platform. For example, basic
453 configuration of Apache or a mail server is a core IT function,
454 while what goes on the web site and in particular email messages
455 is part of the document flow. Likewise, booking an appropriate
456 venue is a meeting planning function, but deciding the specific
457 agenda for a meeting is part of Function 4.
459 2.2 Function 1: Administration
461 A prime requirement of [RFC3716] was "clarity in the relationship
462 with supporting organizations." The IETF sits on, to paraphrase the
463 words of Brian Carpenter, a "four-legged" stool for administrative
464 support functions. Unfortunately, not all of the legs are fully
465 defined.
467 The most serious undefined area is the on-going relationship with
468 CNRI, which in turn subcontracts to Foretec Seminars, Inc., a
469 for-profit subsidiary. CNRI has provided secretariat services for 18
470 years, but there is no contract or memorandum of understanding with
471 the IETF that defines the relationship. When the arrangement was
472 first started, a few dozen people attended IETF meetings. Over time,
473 that grew to over a hundred attendees, then several hundred, and
474 today well over 1,000 people attend each meeting. The gentleman's
475 agreement was perfectly appropriate 18 years ago. But, [RFC3716] was
476 quite clear that today it is not a sufficient basis for managing
477 close to US$2 million in annual meeting fees collected on behalf of
478 the IETF community.
480 The lack of a specific contract between the IETF community and
481 CNRI/Foretec is one of the items noted in [RFC3716], however that
482 analysis also pointed to broader problems throughout the IETF
483 community. In general, the administrative and support relationships
484 have not been defined or kept up to date. That has led to a variety
485 of issues observed in interviews conducted for drafting this report:
486 o A lack of financial information.
488 o Confusion over intellectual property.
489 o Vague definition of the lines of authority in the contracting
490 relationship.
492 *Financial Information.* There is no systematic, comprehensive, or
493 timely reporting of financial information to the IETF leadership by
494 support organizations, nor from the IETF leadership to the IETF
495 community.
496 o Budgets are prepared at a very high level, are not based on
497 program goals prepared by the IETF leadership, and are not based
498 on historical information, such as actual versus budgeted results
499 in previous periods. This reduces the ability of the leadership
500 to participate in a meaningful budget-setting process.
501 o Financial reporting is also minimal: financial results are not
502 available during the course of the year, and have been typically
503 reported as late as 6 months after the close of the year. The
504 reports furnished to the IETF community are non-standard in
505 format, lack sufficient detail for evaluation, and are not
506 furnished to the IETF with an auditor's or accountant's statement.
508 *Intellectual Property.* In conducting research for this report, the
509 author noted a lack of clear definition of community intellectual
510 property. Because relationships with support organizations are
511 poorly defined, there is no clear, unambiguous paper trail that shows
512 that resources are held in trust for the IETF community and must be
513 managed in the public interest and in a manner that is responsive to
514 the IETF community. The IETF is a public standards-making
515 organization and a fundamental defining characteristic of the IETF is
516 the openness of the process [RFC3668]. All data, including
517 databases, correspondence, minutes, and other documentation of the
518 IETF operations or deliberations are an integral part of that
519 process.
521 *Definition of the Relationship* The third effect of a lack of a
522 concrete understanding has been an apparent deterioration in the
523 working relationship between the IETF leadership and support
524 organizations. In particular, a review of correspondence shows
525 numerous instances where requests for specific functions have led to
526 discussions over who has the right to request what.
528 While the lack of a formal relationship with CNRI and/or Foretec
529 Seminars is the most pressing issue in the Administration Function,
530 the [RFC3716] goals of "uniform budget responsibility" and "a uniform
531 view of revenue sources" are not being attained. In particular:
532 o The Internet Society provides a number of administrative functions
533 that go beyond the matters specified in [RFC2031]. While that
534 memorandum of understanding does cover the provision of insurance,
535 in addition to that task the Internet Society also provides
536 discretionary funds to the IETF and IAB Chairs, and funds the
537 operation of the IAB. These expenditures are reported the IETF
538 community based on totals with no detail. In addition, the RFC
539 Editor contract is not published, although the statement of work
540 and total expenditures are [RFC-SOW].
541 o The IANA provides parameter registry services to the IETF. While
542 the substance of that relationship is defined in [RFC2860], the
543 host institution (ICANN) does not provide financial reporting at
544 sufficient granularity for an analyst to understand how much that
545 function costs and thus understand the level of resources being
546 used to perform that function. In addition, no public tracking of
547 requests or announcements of new registrations are provided,
548 making it difficult to estimate the workload.
549 o The IETF has no uniform reporting of overall financial results.
550 While the IETF Chair has posted financial reports as they are made
551 available, there is no single location where an interested member
552 of the community can get a fiscal picture of the operation of the
553 IETF over time, or examine a standards-compliant financial report
554 for a particular time period [FASB-117].
556 2.3 Function 2: Meetings
558 IETF meetings revenues have traditionally funded a wide variety of
559 non-meeting support functions, such as the document tracking,
560 submission, and distribution systems. Meeting revenues make up the
561 largest single revenue stream for IETF support (see Appendix B.1 for
562 a summary of IETF financial information over the last 3 years).
564 The cost per attendee per meeting has stayed at roughly $200 and
565 average revenue per attendee has been roughly $450 over the last 3
566 years, though recent gross fees have been as high as $545 including
567 late fees. Note that the $200/attendee cost is only direct costs
568 incurred on-site, and does not include additional personnel, travel,
569 and other expenses from support organizations to plan and staff the
570 meeting. Appendix C contains a summary of meeting attendance, as
571 well as a summary analysis of revenue and expense figures.
573 Although the number of participants in the IETF process as a whole
574 appears to have been growing, the number of attendees at IETF
575 meetings has been steadily dropping from a previous peak. From 2000
576 to 2003 the drop was fairly dramatic, though the figures appear to
577 have stabilized recently. The drop in attendees from the previous
578 peak means a smaller number of attendees have been funding a largely
579 fixed cost of non-meeting expenses.
581 The meeting business is based on several cost factors. An
582 organization will contract with a primary hotel with a guaranteed
583 rental of a certain number of guest rooms. This is known as a "hard"
584 contract and requires an advance deposit of a negotiable amount of
585 the expected room revenue.
587 These amounts can be substantial. For example, a typical contract
588 where an organization is doing a one-time event might require 50% of
589 expected revenue deposited as far ahead as 90 days before the event.
590 In the case of a typical IETF meeting, this might be 1,000 rooms at
591 $150/night for 5 nights, or a 90-day deposit of $375,000. Proper
592 negotiation of long-term relationships can reduce these cash flow
593 requirements by an order of magnitude.
595 In addition, the IETF requires certain facilities provided by the
596 hotel, such as audio visual equipment, electrical services, and food.
597 In the U.S., meeting rooms are often provided at no charge, but only
598 after matters such as food have been negotiated. In non-U.S.
599 venues, the cost for meeting rooms can be as high as $125,000.
601 The planning and execution of an event such as this, particularly
602 three times per year, requires experienced professionals. There are
603 a number of companies and free lance professionals that specialize in
604 organizing meetings for professional groups. Many of these companies
605 have become quite adept at computer networking, and if properly
606 assisted in areas such as routing and the DNS, could do a very
607 credible job for the IETF. It is important to note that IETF
608 meetings have been organized quite skillfully over a number of years
609 and attendees have become accustomed to this level of
610 professionalism. It is important that the IETF maintain those
611 standards.
613 Assistance from members of the community is an important part of
614 staging an IETF meeting. In addition to formal secretariat
615 activities, at least three teams of volunteers have been active
616 recently:
617 o For all unhosted meetings, and for most hosted meetings, a NOC
618 team of volunteers has helped establish a wireless infrastructure,
619 provisioned external lines and transit, managed DNS, and provided
620 a wide variety of other core services. At IETF60, the lead
621 engineer for this activity was Jim Martin.
622 o A team of volunteers organized by the University of Oregon's Video
623 Lab produces audio and video streams from IETF meetings (as well
624 as NANOG and a variety of other events).
625 o A team of volunteers organized by xmpp.org [2] manages a series of
626 XMPP[I-D.ietf-xmpp-core] servers which are used for general
627 commentary by participants, creation of informal transcriptions
628 which are archived, and for a variety of personal productivity
629 enhancements [Bingo].
631 Over the years, a variety of other efforts have sprung up and
632 disbanded aimed at deploying leading-edge technologies in the meeting
633 network for interoperability testing or to familiarize attendees with
634 new protocols. Some of these activities, such as PGP key signing
635 parties, are ongoing. Others have been organized as one-time events.
636 These ad hoc activities are an important part of IETF meetings.
638 These self-organized, volunteer efforts, benefit from coordination
639 with formal meeting planning functions. For example, the core
640 network group requires facilities and coordination with the hotel's
641 telecommunications service, while the audio/video effort requires
642 coordination with the hotel's audio-visual contractors. Currently,
643 none of these volunteer efforts is linked to from meeting web pages
644 which are maintained by CNRI/Foretec, and there is no IETF leadership
645 policy on this subject.
647 While the day-to-day operational aspects of meetings are extremely
648 well coordinated, long-range planning for IETF meetings is almost
649 non-existent. For example, by IETF60 in August, 2004, planning for
650 2005 meetings had not reached any apparent degree of closure. The
651 IETF leadership were unaware of any firm plans for Spring or Fall of
652 2005, and while some progress had been made in identifying a general
653 location for the Summer 2005 meeting, specific venues were still
654 being evaluated.
656 Long-range planning is absolutely essential in the meeting business.
657 Booking well in advance and using techniques such as repeat visits to
658 properties that are allied through common ownership or marketing
659 arrangements can lead to dramatic reductions in guest room rates,
660 deposit requirements, and hotel charges. Long-range planning also
661 helps IETF meeting attendees plan their own schedules. For many
662 people, the commitment to go to an IETF is a major one, requiring the
663 use of vacation time, personal funds, and other resources.
665 Often in the past, a "host" has volunteered to assist in a meeting, a
666 task that traditionally consisted of organizing the terminal room
667 effort. The concept of a single host has, for recent meetings, been
668 supplanted by a series of sponsors who furnish specific resources,
669 such as bandwidth or equipment. Terminal room efforts have become
670 significantly easier as the IETF has shifted from importing hundreds
671 of bulky computers and terminals for attendees (see [RFC0015] for
672 more information on the concept of "terminals") to a wireless network
673 for laptops. The concept of "host" (or "primary sponsor") is
674 certainly a useful one, however instead of focusing on terminal room,
675 the device could be used as a way of defraying meeting room charges,
676 food, or other major expenses.
678 One final issue should be noted that has become apparent during the
679 course of research for this report. There appears to be no clear
680 guidelines on some issues related to the conduct of meetings, which
681 has led to disagreements between the contractor and the IETF
682 leadership. Two situations in particular are apparent:
683 1. Signage. In most association meetings, signage is strictly
684 controlled so that all sponsors and contractors (and in the case
685 of the IETF, volunteers) receive appropriate billing. There is
686 no IETF policy on this topic. The IETF leadership should
687 formulate such a policy.
688 2. Corollary activities. There have been several attempts to defray
689 meeting costs or increase profits through the use of trade
690 exhibitions, user groups, engineering task forces, and various
691 other activities affiliated loosely or closely with an IETF
692 meeting. Any policy on colocation of related events at an IETF
693 meeting is a policy matter that should be under the direction of
694 the IAB and IESG and ultimately the IETF community. The IETF
695 leadership should formulate such a policy.
697 2.4 Function 3: Core Information Technology
699 While meetings provide an important part of the IETF process, it has
700 always been a basic policy of the community that participation in
701 meetings is not required to participate in the IETF. Mailing lists,
702 document submissions, and other aspects of a continuing network
703 presence are a core part of the IETF.
705 As noted above, this analysis divides that network presence between a
706 core information technology function, which is discussed here, and
707 the uses of that network, which is described in the next section.
709 Unfortunately, the IETF does not do a very good job of providing a
710 network presence for its own activities.
712 There are many opinions about how "good" or "standards-compliant" or
713 "well-provisioned" a network infrastructure should be for any
714 particular activity. However, by most standards, it is hard to argue
715 that the IETF is using the technology effectively. A comprehensive
716 analysis of network performance is impossible simply because
717 statistics and logs or any other reporting is not available.
718 However, a few anecdotes will serve to illustrate the point.
720 There are six Web sites that contain information important for IETF
721 participants. None of these Web sites, as of August 13, 2004, were
722 compliant with the W3C Validation Service and with published HTML
723 standards:
724 o http://www.iana.org/ [3]
725 o http://www.rfc-editor.org/ [4]
726 o http://www.isoc.org/ [5]
727 o http://www.ietf.org/ [6]
728 o http://www.iab.org/ [7]
729 o http://www.irtf.org [8]
731 Likewise, none of these sites is reachable using IPv6. Search
732 engines on all four sites are primitive at best, and are not
733 operational in the case of www.iana.org and www.isoc.org. Few
734 attempts are made at authentication of information, domain names, or
735 applications. And, a comparison of the IETF home page from January
736 7, 1997 and from February 15, 2004 shows that it has remained
737 virtually unchanged during that period [Wayback].
739 These are all anecdotal examples, but they certainly reinforce the
740 findings of [RFC3716] that the IETF does not use technology as
741 effectively as it could.
743 One function that appears sorely lacking on any of these systems is
744 the provisioning of shared environments for use by working groups,
745 directorates, the IAB, the IESG, and other groups. Working groups,
746 as part of the management of chartering activity, are able to specify
747 a web site and a mailing list, but there appears to be no mechanism
748 that allows a portion of the web, FTP, or other core operational
749 servers to be delegated for use by a particular group.
751 The result has been that working groups, teams and areas create a
752 diverse plethora of unconnected sites for handling IETF functions,
753 such as rtg.ietf.org, ops.ietf.org, edu.ietf.org, various issue
754 trackers, WG web sites and other tools hosted at diverse private web
755 sites, the availability of which is critically dependent on
756 volunteers - which are usually drawn from the WG. This is not
757 necessarily a bad thing, but as will be seen in Section 3.4, some
758 additional support might help meet goals such as the goal stated in
759 [RFC3716] of "persistence and accessibility of records." For example,
760 a systematic archiving facility can assist decentralized efforts,
761 unified search facilities might prove useful to those searching for
762 information, and one could certainly find many ways to improve the
763 navigation, presentation, and timeliness of the current IETF network
764 presence.
766 2.5 Function 4: Document and Information Flow
768 Function 4, Document and Information Flow, is the part that directly
769 supports the day-to-day functioning of the IETF. While core
770 information technology provides a web server or a mail server, this
771 function populates those servers with information based on the rules
772 defined in process BCP RFCs as well as various unwritten procedures
773 and customs.
775 A demanding part of the current IETF Secretariat is the process of
776 supporting the numerous bodies that proliferate through the
777 community. The IESG, of course, requires a great deal of support,
778 given their bi-weekly teleconferences, and the tremendous workload of
779 documents to consider, working groups to charter, and other functions
780 the group performs. The high workload of IESG members has been noted
781 repeatedly.
783 Many of the functions required to support a deliberative body such as
784 the IESG are ideally suited for a capable administrative office, a
785 task often labeled as "Clerk." In the U.S., for example, the "Clerk
786 of the Court" or "County Clerk" are key tasks in their respective
787 organizations. These officers and offices facilitate the flow and
788 archiving of information, providing both a human and a procedural
789 interface for disseminating information among participants in a
790 process.
792 The tasks that are encompassed in this function include:
793 o Supporting the working group charter process, which includes
794 processing the initial charter, rechartering, milestone
795 management, and closing of the working group.
796 o Publication of Internet-Drafts. It is assumed that current
797 efforts to automate the submission process will be successful,
798 alleviating much of the manual effort that this function currently
799 has.
800 o Document tracking, including a ticket-system-based response to
801 document and working group management problems, announcements of
802 last calls, and a variety of other functions.
803 o Managing IESG meetings, including scheduling, creation of the
804 agenda, and collecting the minutes, as well as the creation and
805 long-term archiving of IETF meeting proceedings.
806 o Handling the Intellectual Property Rights disclosure process (a
807 process which is presently undergoing automation).
808 o Publication of official actions, such as document approvals,
809 including communication of such status to groups such as the RFC
810 Editor.
811 o Registration and publication of liaison statements from other
812 standards bodies and publication of liaison statements, responses
813 and other communications by the IETF to Standards Development
814 Organizations (SDOs).
815 o Support of the Nominating Committee.
816 o Assisting the Meeting Planners in crafting an appropriate agenda
817 for the IETF meetings, a complex task that requires a fairly
818 detailed knowledge of the IETF operation.
820 A great deal of progress has been made in this area over the last
821 year, and more can be expected in the future with the active
822 participation of a new Tools group and of IESG members. However,
823 there is still substantial work to make the flow of information
824 smoother and more predictable. For example, even though the
825 Internet-Draft, RFC, and IANA processes are all closely linked in
826 theory, in practice each organization currently maintains their own
827 tracking system. In the case of the IANA, that tracking system is
828 not visible outside of the organization. Thus, interaction among
829 these three bodies often relies on personal communications, and there
830 are fairly frequent issues of tokens being lost, or "customers"
831 (e.g., the author of a particular draft) being unclear where in the
832 process they are.
834 3. Recommendations for Restructuring the Administrative Framework
836 This section contains recommendations for changing how the day-to-day
837 support functions are provided. Issues such as how to contract for
838 services and whether or not a full-time staff member should be hired
839 are dealt with in this section. Section 4 discusses the
840 institutional framework in which these activities can be housed,
841 including issues such as whether to incorporate the administrative
842 entity.
844 3.1 Recommendation 1: Hire An Administrative Director
846 The deliberations of the Problem Statement Working Group made it
847 clear that the IESG and IAB are both overworked with an increasingly
848 large flow of technical issues. The group also made it clear that
849 the IETF Chair and the IAB Chair should continue to be picked for
850 their ability to lead the IETF technical activities, not solely on
851 their ability to create a conformant income statement [RFC3774].
853 One key cause of the current ambiguous management structure is the
854 lack of even one full-time staff member who reports directly to the
855 IETF leadership. For example, the IETF Chair and IAB Chair attempt
856 to prepare an annual budget and do financial reporting, but they do
857 so without any professional help. Among leading standards
858 organizations, the IETF is alone in failing to provide any staff to
859 assist the leadership in such activities.
861 While zero staff is a non-standard way to run a standards body, a
862 large staff would run counter to a long-established feeling
863 throughout the community that the creation of a large bureaucracy
864 would go against the fundamental tenets of how the IETF operates.
866 In the IETF, there thus appears to be a philosophy that strongly
867 favors outsourcing services whenever possible. A first step would be
868 to hire a single staff member, an Administrative Director. This
869 position would be responsible for tasks such as hiring and working
870 with contractors, managing finances, and working with other
871 professionals such as lawyers and auditors. A decision on whether or
872 not the ultimate size of the support staff remains at 1 or grows very
873 modestly thereafter can be deferred.
875 This is a fairly demanding position, as it requires a firm knowledge
876 of business fundamentals, such as budgeting, contracting, logistics,
877 and MIS operations. The successful applicant for such a position
878 would also have to either be already familiar with the IETF or be
879 able to quickly assimilate the culture. Prior knowledge of IETF
880 politics should not be prerequisite for this position, but since an
881 Administrative Director would have to work on a day-to-day basis with
882 a decentralized, consensus-based community, the position will require
883 a certain level of political sensitivity. The position will also
884 require a certain technical cluefulness, though again, such skills
885 could be acquired on the job in certain cases.
887 Creation of this position should be fairly straightforward. First, a
888 job description should be created. The position can be advertised
889 using a variety of media, ranging from the IETF mailing lists to more
890 formal mechanisms such as advertisements in publications such as the
891 International Herald Tribune, the New York Times, the Economist, or
892 the Wall Street Journal. A yet more formal strategy would be to
893 engage a professional search firm.
895 Evaluation of applicants might consist of a search committee
896 appointed by the IETF Chair. The committee would conduct an initial
897 review of applications, possibly solicit additional applications, and
898 present a short-list for further consideration. This short list of
899 applicants could be reviewed by the IESG and IAB, possibly with
900 further interviews. The IESG and/or IAB should specify this
901 procedure more fully before beginning the search.
903 As part of the drafting of a call for applicants, the IETF leadership
904 may want to consider what the IETF leadership groups need in the way
905 of support and how they can structure the position in a way that
906 attracts the best applicants. For example, procedural mechanisms
907 such as explicitly allowing the staff to be present on mailing lists,
908 teleconferences, and meetings may be necessary before applicants will
909 consider the position one which is doable.
911 A sample draft Call for Applications is attached as Appendix E.
913 3.2 Recommendation 2: Establish Contracts for Core Services
915 The lack of a contractual basis for present services is, as discussed
916 earlier, a historical artifact of the dramatic growth of the IETF
917 from a few to a few hundred to several thousand participants.
919 Establishing a formal basis for such services by the close of this
920 calendar year is a fundamental recommendation of this report. A
921 formal understanding for support services can take several forms,
922 including contracts or memoranda of understandings. Since the IETF
923 is based on an open process, it is important that all significant
924 contracts be published so they have formal standing within the
925 context of the IETF community. Such publication can be on a web
926 site, or can be a republication of the contract in the RFC series.
928 Just as a contract should be published as an RFC so they have formal
929 standing in the community, it is important that any Memoranda of
930 Understandings published as an RFC have similar standing in the legal
931 world. It is important that such contracts or memoranda have
932 adequate legal review to insure that the key elements required in
933 contract law are present.
935 For organizations providing support services who are not presently
936 under contract, there are two broad strategies that can be used to
937 move from the present administrative framework to the more formal one
938 proposed here: sole source procurement or a Request for Information
939 (RFI) or Request for Proposals (RFP) to solicit a variety of bids
940 from multiple vendors, including the present providers.
942 It is important to note that with the present granularity of
943 historical financial information, an RFP will be an essential part of
944 understanding the various expense models associated with different
945 services levels and provisioning strategies.
947 A decision also has to made whether the current services are
948 monolithic or can be decomposed into separate pieces. A case can be
949 made that a single vendor for most services can provide the most
950 responsive service. Alternatively, one could argue that some
951 services are specialized, such as meeting planning, and might be
952 better carried out by a specialist.
954 A final factor comes into play, which is the risk to continuity of
955 operations caused by any transition. There is also a financial cost
956 to any transition, including capital costs (e.g., acquiring
957 sufficient assets to do the job), cash flow requirements (e.g., hotel
958 deposits for meetings can be substantial), and professional help
959 (e.g., lawyers, accountants, and a variety of other services).
961 There are thus a spectrum of options available within the extremes of
962 RFP and sole source procurement. This report recommends one of the
963 following three strategies:
964 o *Strategy 1.* Issue an RFP for all core secretariat services.
965 This would allow the current provider to bid and thus establish
966 contract terms upon a successful bid, but would also allow other
967 vendors to compete.
968 o *Strategy 2.* Attempt to negotiate a sole source procurement on
969 all of the functions, but after a designated time-out period
970 (e.g., 30 days), if the negotiation is not successful, issue an
971 RFP. The term of the sole source procurement could be a subject
972 of the negotiation, or a fixed term (e.g., 1 year) could be
973 established a priori. The intention would be to issue an RFP for
974 the subsequent contractual period.
975 o *Strategy 3.* Some combination of the two above options. For
976 example, attempt a sole source procurement on two of the three
977 functions, and issue an RFP for the third.
979 Based on research conducted for this report, the author is of the
980 opinion that meetings and the core "Clerk" functions would be the
981 most difficult to transition to a new provider. Meetings are
982 difficult because of long lead times (and an RFP process would
983 further delay 2005 planning unless an interim planning process can be
984 established). The "Clerk" functions have a great deal of
985 institutional knowledge, much of which is not properly documented.
987 Thus, the author of this report recommends that, if a hybrid strategy
988 of attempting a sole source contract on two functions and an RFP is
989 used for the third function, that core network services is a good
990 candidate for an RFP and meeting planning and "Clerk" functions would
991 be a good candidate for sole source procurement negotiations.
993 Providing a computing infrastructure is an area with many qualified
994 professionals and some well-established industry norms. This
995 strategy would also allow the IETF to move core archives that are
996 presently decentralized into a common infrastructure, would provide
997 more flexibility to provide resources to workgroups, and would allow
998 non-contractor developed tools to coexist with existing resources.
1000 If an RFP is not issued a particular function, then a sole-source
1001 contract negotiation would be used. There should be a clear
1002 understanding on intellectual property ownership, in particular a
1003 clear statement about all information flowing through the IETF
1004 process belonging to the IETF community, including the following:
1005 1. Domain names, including iab.org, ietf.org, iesg.org, and
1006 irtf.org.
1007 2. Content of Internet-Draft directories.
1008 3. Content of Web sites.
1009 4. Subscriber lists for all mailing lists (public and private).
1010 5. Mailing list archives for all archived mailing lists (public and
1011 private).
1012 6. Working group database content including charters.
1013 7. Internet-Draft history database content.
1014 8. Internet-Draft tracker database content.
1015 9. Meeting minutes.
1016 10. Meeting attendance records, including "blue sheets".
1017 11. Archive of expired Internet-Drafts.
1018 12. Documents relating to the creation and reporting of working
1019 group status.
1020 13. Copies of any other IETF information including correspondence
1021 and historical records.
1023 In addition to intellectual property considerations, any contract
1024 negotiation should be bounded by two other parameters:
1025 1. A transition clause is essential to allow for an orderly
1026 transition to other vendors in the future. For example, if
1027 meetings are provided on a one-year support contract, but meeting
1028 venues are being booked on a longer time scale, a clause in the
1029 contract would allow the transfer of venue to a new contractor.
1030 In addition, a fairly standard clause in many such contracts
1031 would allow the ability for a new contractor to issue employment
1032 offers to non-managerial employees of the old contractor as a
1033 transition mechanism.
1034 2. A negotiating period time-out clause is essential in such a
1035 process. This report recommends that a small team be assembled
1036 to negotiate such contracts under the direction of the IETF and
1037 IAB chairs, reporting back for the advice and consent of the IAB
1038 and IESG, and that any resulting contract be published. If 30
1039 days lapse and no agreement is reached, the IAB and IESG should
1040 have the option, after reporting back to the community, of either
1041 extending the negotiating period for an additional 30 days, or
1042 issuing an RFP.
1044 While establishing a contract for uncontracted services is absolutely
1045 essential, some attention should also be paid to services provided by
1046 the IANA or the RFC Editor. For example, returning to a multi-year
1047 contract with the RFC Editor instead of the current one-year
1048 extensions might provide for a larger investment in the function by
1049 the host institution. Likewise, agreements with the Internet Society
1050 and ICANN should be kept current.
1052 3.2.1 Details of Potential RFP Components
1054 3.2.1.1 Structure of the RFP
1056 Part of the philosophy of the IETF support process is to not make
1057 large organizations whose sole purpose is to support the IETF. This
1058 is still a valid approach.
1060 In recent years, the support for the IETF has been carried out by a
1061 small number of organizations working on fairly unconnected tasks
1062 (RFC Editor at ISI, IANA at ICANN and secretariat and meeting
1063 services both handled at Foretec).
1065 Each organization has provided its own facilities for storage,
1066 publication, information distribution and list maintenance, as they
1067 saw it required for their tasks. This is not necessarily an optimum
1068 distribution of resources. One could imagine multiple models,
1069 including:
1070 o The IETF controlling a distributed compute platform and storage
1071 facility, with multiple organizations using that to perform work
1072 under contract, and using each others' services when appropriate
1073 (management of the platform being of course one such contract).
1075 o A distribution much like the present, where suppliers bring their
1076 own resources, but with tasks distributed differently, with (for
1077 instance) meeting planning and Web presence maintenance being
1078 separate tasks, but with increased emphasis on information sharing
1079 and open access to information.
1080 o An even larger concentration of roles, where one service
1081 organization takes on tasks that are distinct today.
1083 There is not sufficient information on price, performance or benefits
1084 of the various approaches today. A Request for Proposals process,
1085 however, would generate the necessary information. An RFP process
1086 where the components of the work are separated out to the largest
1087 extent practical will encourage the people who offer proposals in
1088 response to tell explain which parts of the RFP they would be willing
1089 to take on, how they would get synergy out of combining them, and
1090 what services they would be capable of using from other providers.
1092 The RFP is an information gathering tool, and will be followed by
1093 extensive negotiations and planning on how the services the IETF
1094 needs can be supplied. This needs time, and because of this, sending
1095 out an RFP earlier rather than later in the decision process will
1096 provide important input used to structure the work to be performed.
1098 A draft RFP is contained in Appendix F and picks the following
1099 decomposition:
1100 1. Provision of the Core Network and Systems
1101 2. Systems Administration
1102 3. Mailing list management
1103 4. The Web presence
1104 5. Meeting planning
1105 6. The Clerk of the IETF
1107 The RFP is structured so proposals may be received for one or more of
1108 the above requirements. A single bidder may elect to provide all
1109 functions, one function, or some combination. The RFP is structured
1110 to include a review process, and the selection criteria are based on
1111 what is best for the IETF as a whole, as opposed to a single formula
1112 such as lowest price.
1114 One important factor in all bids for supporting service will be the
1115 degree of continuity and accountability. A "key person" principle is
1116 proposed where an individual contact is identified as responsible
1117 manager for the function. It is this person who will give guarantees
1118 to the IETF for the services being available to the IETF with
1119 adequate availability and response times, and who will take charge of
1120 the organization that supplies the services.
1122 The terms "Request for Proposals" (RFP) and "Request for Information"
1123 (RFI) bear a brief explanation. A wide variety of organizations use
1124 formal and open procurement processes. Some of the better known
1125 entities, particularly government agencies, have an extremely
1126 rigorous process defined in the RFP announcement, including metrics
1127 for decision, such as a formula for calculating a final score based
1128 on price and a metric such as average panel rankings on subjective
1129 criteria such as "quality" or "responsiveness". A process this
1130 rigorous would probably not give the IETF administrative entity much
1131 flexibility in crafting an appropriate solution.
1133 A "Request for Information" often suggests that a final decision will
1134 not be based on the initial information submitted in the call for
1135 proposals. Rather, the RFI is used to put together a short list of
1136 potential candidates, and engage in negotiation and reformulation of
1137 the proposals.
1139 In either case, the term used really does not matter nearly much as
1140 the terms specified in the call for proposals. The label is fairly
1141 irrelevant and the real meaning is specified in the details. A call
1142 for proposals could easily bear either label.
1144 3.2.1.2 Core Network
1146 Currently, the IETF does not own any computers, colocation space, or
1147 transit capacity. Indeed, the IETF does not even run a web site.
1148 All of these functions are contracted out, and the contracts include
1149 full provisioning of the underlying infrastructure. As mentioned
1150 above, this is only one possible arrangement. We do not have data
1151 that will allow us to know what to choose between the alternatives
1152 here.
1154 If adequate resources can be obtained at the right price, including
1155 servers, colocation space, and bandwidth, and if those resources meet
1156 the high standards needed to sustain IETF operations, the best thing
1157 for the IETF may be to operate on such an infrastructure. Having an
1158 adequate in-house infrastructure controlled by the IETF also provides
1159 substantial flexibility in the case of future transitions of key
1160 contractors, but it also burdens the IETF with the requirement to
1161 maintain and replace equipment.
1163 An organization able to provide highly competent systems
1164 administration would be needed to support a solid computing platform.
1165 If purchased at commercial rates, this would probably be a
1166 significant part of the cost of this way of supporting services. The
1167 RFP process will tell us what we can depend on.
1169 In terms of volunteer contributions for specialized areas such as
1170 nameservice or routing, the IETF may be able to draw upon volunteer
1171 help from participants. It would make sense to have the relationship
1172 with the volunteer be slightly formalized, including a public
1173 appointment to the named task. This impresses upon all that such a
1174 task is one of trust and makes the community aware that the
1175 individual or organization has assumed this particular
1176 responsibility.
1178 3.2.1.3 Mail
1180 The IETF is a mail-intensive operation, with mailing lists for
1181 working groups, directorates, the IESG, the IAB, and a raft of other
1182 lists, not to mention the core IETF and announcement lists.
1184 Certain specialties in computing are considered an art unto
1185 themselves. Mail is one of those areas. The IETF Administrative
1186 Entity should simply contract the postmaster function to a vendor
1187 experienced in running environments characterized by high-volume mail
1188 servers, large numbers of lists with various access and moderation
1189 policies, a stringent archive requirement, and an ability to
1190 implement appropriate filtering policies (where the policy, of
1191 course, is ultimately set by the community).
1193 This task is as much a public service position as it is a contract.
1194 The task of postmaster to the IETF Administrative Entity should be
1195 sufficiently attractive that it will attract highly capable bids.
1197 Since a variety of provisioning options are available for this
1198 service, the evaluation process should carefully consider each
1199 proposal for criteria such as stability of service and infrastructure
1200 redundancy.
1202 3.2.1.4 Community Workspace Support and the IETF Network Presence
1204 The IETF needs far better support for our various groups that wish to
1205 maintain a network presence. While the core document submission
1206 process is highly structured, currently the operation of individual
1207 working groups, directorates, or other groups all have very different
1208 styles. A variety of styles is a Good Thing and should be supported.
1210 Systems administration can provide core tools such as web servers,
1211 FTP servers, and can allocate space to groups. However, an effective
1212 network presence for the IETF involves many issues about how we
1213 archive our information, how we make it easy for new groups to form
1214 workspaces, and how we interface to our data through search and
1215 navigation facilities.
1217 Core systems administration is on a different layer of the stack than
1218 the applications support that is needed to help maintain a
1219 productive, happy community with a clueful Internet presence.
1221 It is proposed that the IETF Administrative Entity needs a webmaster
1222 to supplement the resources of the systems administrators. The
1223 sysadmin can install Apache with appropriate modules, but building a
1224 core web site for the IETF involves other skills, including knowledge
1225 of CSS, HTML, XML, and a variety of scripting skills in languages
1226 such as PHP or PERL or TCL (pick your poison).
1228 At first glance, this may seem to be a development effort, not an
1229 ongoing operations effort. However, we believe a more sustainable
1230 system can be built with a webmaster task which combines on-going
1231 responsibility for access to the core IETF information along with a
1232 support role for the broader community of working group chairs,
1233 directorates, and the like.
1235 3.3 Recommendation 3: Provide Timely and Uniform Financial Reporting
1237 This report recommends that all available historical financial
1238 information be posted in a single public location, and that an
1239 immediate commitment to post more complete and timely financial
1240 information in the future be made.
1242 In addition, the IETF leadership should begin formalizing the budget
1243 process in anticipation of any administrative restructuring efforts.
1244 Once issues of an institutional home for administrative functions
1245 have been decided, a full budget with program goals, including any
1246 relevant transition expenses and a cash flow analysis, will be
1247 required by any potential groups helping finance the IETF
1248 Administrative Entity as part of the funding group's annual budget
1249 planning processes.
1251 These functions are all envisioned to be the primary responsibility
1252 of the Administrative Director, with some contractor assistance for
1253 accounting and auditing tasks.
1255 3.4 Recommendation 4: More Focus on Archives
1257 [RFC3716] stressed the importance of proper attention to the
1258 persistence and accessibility of records, including the requirement
1259 that "the IETF needs to maintain and support the archiving of all of
1260 its working documents in a way that continues to be accessible, for
1261 all current and future IETF workers." The IETF does not currently
1262 meet that requirement. In particular:
1263 o Although the RFC Editor maintains an "RFC-Online Project", over
1264 200 RFCs have yet to be put online.
1265 o Archives of IETF working group mailing lists are spotty and
1266 sometimes unreliable.
1268 o The ietf.org Web site does not include a comprehensive archive of
1269 all Internet-Drafts, though several volunteers in the community do
1270 maintain such sites on an informal basis. It should be noted that
1271 this lack of a public comprehensive archive is a policy decision
1272 of the IESG. A private comprehensive archive is a legal
1273 requirement, as the IETF is the original publisher of
1274 Internet-Drafts and is sometimes asked for old drafts in cases
1275 such as patent disputes. Even if the archive is not available on
1276 a public site, regular audits of the completeness of the archive
1277 are necessary.
1278 o On a short-term basis, there is no adequate backup for the
1279 www.ietf.org web site, which has led to periodic accessibility
1280 issues.
1281 o Although videolab.uoregon.edu has an archive of past meeting audio
1282 and video feeds, that archive only dates back to IETF49.
1284 More attention to this important area is recommended as a key 2005
1285 goal.
1287 4. Options for an Institutional Basis for Administrative Activities
1289 4.1 Discussion of Organizational Form and Legal Domicile
1291 This report frames the question of organizational form as follows:
1292 o Should the IETF administrative support organization be
1293 incorporated?
1294 o If so, should it be now or later?
1295 o If so, what domicile and specific form should be chosen?
1296 o If so, what would be the specific nature of the relationship
1297 between any potential new organization and the Internet Society?
1299 As seen above, there is a close relationship between ISOC and the
1300 IETF that is independent of the administrative restructuring of IETF
1301 support.
1303 The requirements for the relationship between the IETF Administrative
1304 Entity and the IETF Community are:
1305 o The process must generate the support that the IETF needs.
1306 o The process must be transparent; people and organizations who
1307 donate money to the standards process must be able to verify that
1308 the funds have been spent on effective support of the standards
1309 process.
1310 o The process must be efficient; the overhead of a large bureaucracy
1311 is not in the best interest of the IETF.
1312 o The process must be flexible enough to allow the IETF support
1313 structure to adapt to changing IETF community requirements.
1314 o The administrative entity must be responsible to the IETF.
1316 As an aide for discussion purposes, this report proposes four
1317 scenarios:
1318 o *Scenario A.* The Internet Society role as legal home of the IETF
1319 is augmented to include the new administrative function. As
1320 issues arise in the future, appropriate memoranda of understanding
1321 or other formal checks and balances can be developed.
1322 o *Scenario B.* As in Scenario A, the Internet Society's role is
1323 augmented to include administration of IETF support functions.
1324 However, instead of waiting to understand what the issues are, the
1325 IETF takes proactive steps to take a more fundamental role in the
1326 Internet Society as its administrative home. Thus, the difference
1327 is that in Scenario B, more time is spent up-front on formal
1328 definition of the relationship. Needless to say, more up-front
1329 definition is sometimes a good thing, but can also lead to a great
1330 deal of time solving problems that don't exist.
1331 o *Scenario C.* This scenario says that the IETF community is ready
1332 and willing to undertake the responsibilities for managing its
1333 administrative efforts. A new incorporated body is formed to
1334 house those functions. That body would be closely tied to the
1335 Internet Society through a variety of mechanisms that show that
1336 the two entities are part of a "symbiotic whole."
1337 o *Scenario D.* As in Scenario C, a new incorporated body is formed
1338 to house the administrative support functions. But, instead of
1339 being as closely linked to the Internet Society, the entity bears
1340 much more of the burden of setting up an infrastructure. In this
1341 scenario, the IETF community is now completely responsible for
1342 ensuring all aspects of its continued, long-term financial
1343 viability.
1345 4.2 Scenario A: ISOC Operating Unit
1347 Presently, the Internet Society administers the RFC Editor contract
1348 under the direction of the IAB, provides the IAB and IETF
1349 discretionary funds, and purchases insurance to cover some people
1350 involved in IETF decision making. The Internet Society also raises
1351 all funds need in excess of those provided by IETF meeting revenue.
1352 In this scenario, the Internet Society simply augments their current
1353 provision of services with appropriate contracts and program
1354 management services to manage the core IETF support contracts,
1355 including a significant number of large and small meetings, a fairly
1356 complex Clerk's Office, and a significant Internet presence.
1358 In this scenario, the Internet Society would employ the
1359 Administrative Director proposed in Section 3.1. The job search
1360 would be conducted in consultation with the IAB and IESG. That
1361 employee would in turn, again in consultation with the IAB and IESG,
1362 manage any sole source procurements or RFP processes that are
1363 approved by the Internet Society in consultation with the IAB and
1364 IESG. The IETF activities would appear as line items in the Internet
1365 Society budget, with revenue and expenses clearly allocated by
1366 program area (as they currently are on ISOC financials).
1368 4.2.1 Division of the Internet Society
1370 In this scenario, the IETF administrative activities would be
1371 undertaken as a Division of ISOC. It would have as its day-to-day
1372 operational head a senior Administrative Director who would have
1373 operational responsibility for all the IETF administrative activities
1374 on behalf of the IETF community. This individual would be an
1375 employee of ISOC, but management oversight would be structured to
1376 include direct IETF involvement including the IETF and IAB Chairs,
1377 and/or an Oversight Committee appointed by some IETF-specified
1378 process.
1380 Budgets would be established each year in consultation with the IAB
1381 and IESG, and approved by the ISOC Board as well as the IETF
1382 leadership. The IETF Division would have its own bank account and
1383 the Administrative Director would collect and manage all receipts
1384 (including revenues from ISOC destined for the IETF) and
1385 disbursements. Operationally, this reserves for the IETF Division
1386 the ability to prioritize and re-allocate funds within the
1387 constraints of the approved budget as seems best and will provide
1388 maximum flexibility in service provisioning. Once the budget has
1389 been agreed upon it would be the responsibility of the IETF
1390 Administrative Director to manage it. All IETF finances would be
1391 separately accounted for and fully transparent.
1393 In particular,
1394 o The IETF Administrative Director would have ISOC signatory
1395 authority for IETF contracts and would be responsible for managing
1396 all contractors/vendors to the IETF.
1397 o The responsibilities that the IETF Administrative Director would
1398 have with respect to IETF activities would be determined by
1399 standard IETF processes (BCPs, RFCs, etc.)
1400 o The Administrative Director would be hired (and removed) jointly
1401 by the IETF Chair, IAB Chair and the ISOC CEO according to a job
1402 description established by the IETF community. Performance would
1403 be evaluated by those same individuals, and the personnel home for
1404 the Administrative Director would be in ISOC (benefits, pension,
1405 medical, etc.).
1406 o The IETF Administrative Director could draw upon the other
1407 resources (accounting, technical infrastructure, reception, legal,
1408 etc.) of ISOC.
1410 4.2.2 Intended benefits
1412 By hosting the IETF administrative activity within an existing
1413 organization, there is the possibility of cost reduction by sharing
1414 resources. This proposal would give closer and more flexible access
1415 to a broad range of skills and competencies (e.g., sharing portions
1416 of employees time as needed). Note: IT facilities is one area where
1417 the IETF may need separate support/facilities.
1419 Under this model, the IETF could continue to expect ISOC to take a
1420 significant fallback responsibility for any liabilities, whether
1421 financial or legal, that might be incurred by the IETF.
1423 This model also provides an unambiguous fund-raising model, in which
1424 the possibility of confusion between ISOC and IETF efforts is
1425 minimized.
1427 4.2.3 Additional Considerations
1429 One of the considerations from which the IETF has long benefited is
1430 the current separation between corporate donations and IETF actions.
1432 Instantiating this scenario would require continued care to ensure
1433 that the IETF maintains a reasonable distance from the funding
1434 streams (apart from meeting fees) and minimizes the potential of
1435 conflicts of interest with funding sources and other perceptions of
1436 excessive influence by particular participants or their
1437 organizations.
1439 While standards have always been an important component of ISOC's
1440 activities, ISOC as a whole does have a broader mandate, and its
1441 Board must be selected and empowered to meet that broader mandate,
1442 not just the IETF's needs. Nevertheless, from ISOC's perspective, it
1443 is by design and in the governance structure, very complementary and
1444 ISOC has always seen its core responsibility as being to the IETF.
1445 The dedicated IETF Administrative Director and separated budget are
1446 seen as a means of ensuring continuous and adequate attention to IETF
1447 activities, and 3 IETF appointed seats on the Internet Society Board
1448 provides representation within the governing body.
1450 Under this model, the IETF administrative activity is naturally
1451 responsive to and part of the overall ISOC management structure and
1452 its evolution. That is, the scenario described here is modeled on
1453 ISOC's current management and mission structure, assuming that it
1454 will be largely static over time. ISOC has demonstrated several
1455 times in the past that it was willing and able to change its own
1456 governance structure in ways that benefited the IETF activity, and
1457 this specific proposal assumes that will continue to be the case,
1458 without making specific provision for ensuring it.
1460 As the Internet Society, and the Internet Society Board, would bear
1461 responsibility for making sure the continued IETF support function is
1462 carried out in a fashion that is responsible to and responsive to the
1463 IETF community, this scenario is potentially a large undertaking and
1464 should take careful consideration of the financial and logistical
1465 implications of undertaking such an operation and of the requirements
1466 of [RFC3716].
1468 (Note that careful consideration of the responsibilities and the size
1469 of the undertaking applies to all actors in all scenarios, and
1470 applies equally to the Internet Society, the IETF community, and to
1471 any other support organizations.)
1473 4.3 Scenario B: More Formalized ISOC Operating Unit
1475 The philosophy in Scenario A is understand the basic parameters of
1476 how the relationship would work, but instead of spending considerable
1477 time defining all possible parameters, get to work quickly on
1478 pressing problems and deal with longer-term institutional issues as
1479 they come up or after experience is gained. Another strategy,
1480 outlined here as Scenario B, is to lay down more of those basic
1481 parameters about how the relationship would work, enshrining those
1482 parameters in a process BCP RFC.
1484 Scenario B leverages the benefits of Scenario A, while providing for
1485 additional mechanism further define the relationship of the Internet
1486 Society to the IETF community and what the provision of
1487 administrative support functions means. Scenario B is identical to
1488 Scenario A, but more up-front work is put into defining the
1489 relationship.
1491 These mechanisms are simply suggested directions to explore based on
1492 suggestions from early reviewers of this draft, and further
1493 discussions may add or remove mechanisms from this list:
1494 o Mechanism 1: Modify the Internet Society bylaws and articles of
1495 incorporation to explicitly recognize this expanded role and to
1496 explicitly refer to process BCP RFCs such as [RFC2026], [RFC3777],
1497 [RFC2418], and their successors as the governing mechanism for the
1498 standards process. [anchor24]
1499 o Mechanism 2: Re-task the three IETF appointees to the Internet
1500 Society Board of Trustees so that they are representatives of the
1501 IETF and can receive instructions from the IETF leadership on
1502 particular issues. [anchor25]
1503 o Mechanism 3: Give the IETF and IAB Chairs ex-officio, non-voting
1504 seats on the Internet Society Board of Trustees.
1505 o Mechanism 4: Grant the Administrative Director observer rights at
1506 Internet Society Board of Trustee and Executive Committee
1507 meetings.
1508 o Mechanism 5: Create a Memorandum of Understanding between the IETF
1509 and the Internet Society outlining operational parameters, such as
1510 how contract services get managed, how financial results are
1511 reported, and how other services such as insurance shall function.
1512 [anchor26]
1513 o Mechanism 6: Require that Internet Society meeting notices also
1514 include notice of consideration of issues affecting the IETF.
1515 This mechanism allows for community feedback on those issues prior
1516 to any decisions. A variant of this mechanism would allow the IAB
1517 and IESG to assert that a particular issue is critical to the
1518 functioning of the IETF, thus requiring a supra-majority of the
1519 Board to approve the action.
1520 o Mechanism 7: Hold an open ISOC annual Board of Trustees meeting at
1521 an IETF plenary meeting to facilitate more community
1522 participation.[anchor27]
1523 o Mechanism 8: Insert a sunset review clause in any operating
1524 agreement. A sunset review clause stipulates that after a period
1525 of time (e.g., 3 years), a review of operations is conducted.
1526 Often, this review consists of public input, a staff report, and a
1527 formal decision to renew or not renew the charter for an activity
1529 [Texas]. [anchor28]
1531 As noted above, these mechanisms are simply "straw-men" proposed by
1532 members of the community. Any decision to pursue this Scenario, as
1533 with all other Scenarios, will require a careful look at the specific
1534 language and provisions needed to meet the overall goals set by the
1535 community. As noted in Section 1.3, this would likely be in the form
1536 of a process BCP RFC.
1538 The intended benefits of this Scenario are as in Scenario A, with the
1539 additional intended benefit of bringing the IETF community and ISOC
1540 community more closely together to manage their futures.
1542 4.4 Scenario C: Well-Defined Entity With Close Ties to ISOC
1544 In this scenario, administrative support functions for the IETF are
1545 legally housed in a focused, incorporated institution (although the
1546 Administrative Directory might be physically housed within the
1547 Internet Society). This scenario, as well as Scenario D, raises a
1548 series of issues as to the form and legal domicile of such an
1549 organization.
1551 Scenario C envisions a number of concrete linkages with the Internet
1552 Society, which supplement the current close interconnection of the
1553 IETF community with ISOC. For example, under this scenario, primary
1554 fund raising responsibility would be invested in the Internet
1555 Society, allowing ISOC to create a unified fund raising voice
1556 (thought the proposed IETF Foundation would still be in a position to
1557 accept in-kind contributions). In addition to the fund-raising
1558 agreements, this Scenario envisions a variety of other linkages, such
1559 as continued cooperation on education and policy.
1561 4.4.1 How Scenario C Might Work In Practice
1563 There are a variety of legal forms that a formal IETF administrative
1564 support organization could take, but the public, non-commercial
1565 nature of the IETF standards process points fairly clearly to the
1566 formation of a non-profit organization of some sort. A non-profit
1567 organization, if formally recognized, has substantial benefits, such
1568 as exemption from income tax, relief from VAT and sales taxes when
1569 procuring services, and the ability for certain contributors to
1570 deduct donations made to the organization.
1572 It also seems important symbolically that any legal underpinning that
1573 creates an organization for administrative support functions should
1574 reflect the non-profit nature of the IETF as well as reflect the
1575 basic nature of the IETF, which has participants and not members.
1576 While there are numerous organizational structures available, the
1577 most straightforward form for the providing IETF administrative
1578 support is likely to be a non-profit corporation with no members and
1579 no stockholders.
1581 In addition, any formal organization for administrative support needs
1582 to take into account some of the unique characteristics of the IETF:
1583 o It is possible that none of the members of the board of the
1584 administrative support organization will come from the country
1585 that the organization is incorporated in.
1586 o The IETF already has a decision making process for a large number
1587 of our important decisions. The incorporating law should allow us
1588 to subordinate the administrative support organization to these
1589 already-existing processes, as they exist now and as they may
1590 change in the future.
1592 4.4.1.1 Where Might the Administrative Support Organization Be
1593 Domiciled?
1595 Perhaps the most difficult question to consider is which country the
1596 IETF support organization should incorporate in. A characteristic of
1597 the IETF is that we are individual participants. Unlike many
1598 standards bodies, the participants do not represent employers and,
1599 unlike the most formal standards bodies, participants do not
1600 represent countries.
1602 There is a predisposition to strongly consider countries other than
1603 the United States, simply because the IETF is an international group
1604 and a large number of key Internet institutions are already in the
1605 United States. Incorporation of the IETF administrative support
1606 organization is an important milestone, and a predisposition is to
1607 try to show diversity.
1609 Nonprofit incorporation in a number of countries with significant
1610 nonprofit sectors as well as a significant number of IETF
1611 participants was considered. These countries include France, Japan,
1612 the Netherlands, Switzerland, the United Kingdom, and the United
1613 States.
1615 Several countries were initially ruled out because their nonprofit
1616 laws do not permit entities that are not member-based, or have local
1617 requirements such as conducting business in a certain language. In
1618 other cases, there are difficult to meet local requirements for
1619 non-profits. For example, in order for an organization to qualify
1620 for tax exemption in the United Kingdom, an organization has to fall
1621 under one of four "heads" of charity. Three of these are
1622 general-purpose heads, including the relief of poverty, advancement
1623 of education, and the advancement of religion. However, none of
1624 these three are the intended direct focus of the IETF administrative
1625 support organization. The fourth category is "purposes beneficial to
1626 the community" and it appears that our local nexus to the country is
1627 somewhat slim and might be viewed somewhat skeptically by the Charity
1628 Commissioners.
1630 As part of this analysis, a "flag of convenience" approach, such as
1631 the Bahamas, was considered and ruled out. It does not seem that an
1632 off-shore registration poses substantial benefits and would certainly
1633 make it appear that the IETF administrative support organization
1634 perhaps had something to hide. This is clearly not appropriate.
1636 Incorporating simultaneously in several jurisdictions to make the
1637 point that the IETF is not part of any one country was also
1638 considered. As appealing as this is in theory, in practice it
1639 substantially increases the cost of incorporation, the complexity of
1640 on-going operations, and exposes the IETF administrative support
1641 organization to liability in multiple legal jurisdictions.
1643 After weighing a number of issues, it appears that the Netherlands,
1644 Switzerland, and the United States make the most sense.
1646 Either of these three jurisdictions would work. The IETF has strong
1647 participation from the Netherlands, and a number of nonprofit
1648 Internet groups have thrived in this environment. By contrast, we
1649 have far fewer participants from Switzerland. However, because
1650 Switzerland is not part of the European Union, it does not suffer
1651 from the potential risks of the more activist governmental presence
1652 in the EU and in the US.
1654 A U.S. non-profit, non-member corporation is being recommended under
1655 Scenario C, but with an important proviso. This recommendation is
1656 based on simple considerations of expediency and pragmatism: a
1657 transition will be simplest and least risky (in the short term).
1658 Since there are enough issues on the table, it seems easiest to
1659 simplify the equation by taking this variable out. The reasoning is
1660 as follows:
1661 o Administrative support for the IETF is currently enmeshed in a
1662 series of relationships with other institutions, most of which are
1663 also U.S.-chartered non-profit organizations. Any change in the
1664 institutional status of administrative support functions will
1665 require familiarity with U.S. nonprofit law. Incorporation in
1666 another country would require familiarity with those laws as well.
1667 Thus, the incorporation expenses would be higher and the process
1668 would take longer.
1669 o U.S. law has a strong concept of "nexus," which is a
1670 determination of when a foreign organization has enough
1671 relationship to U.S. law to fall under the jurisdiction of a U.S.
1672 court. Because of a long history of operating in the U.S.,
1673 numerous meetings in the U.S., and the large number of U.S.
1674 residents who are participants and leaders, we feel it is likely
1675 that U.S. courts would find nexus in relation to our US-based
1676 activities, even if the IETF administrative support organization
1677 was incorporated in another country. In other words,
1678 incorporating in a country besides the U.S. does not necessarily
1679 free the support organization from any perceived vagaries of U.S.
1680 law.
1681 o Incorporating in a country other than the US may have tax
1682 implications if the Internet Society is providing funding support.
1683 o U.S. corporations have traditionally been large contributors to
1684 the development of public aspects of the Internet, a category into
1685 which IETF activities fall (and consequently, the activities of an
1686 IETF administrative support organization fall). U.S.
1687 corporations are somewhat chauvinistic, and it is our experience
1688 in raising funds that it is easier to get a donation if the
1689 recipient is a duly-chartered U.S. tax-exempt organization. Not
1690 surprisingly, non-U.S. corporations have shown more flexibility
1691 in this regard. Note that under this scenario, the Internet
1692 Society would take primary responsibility for fund-raising,
1693 however deductibility of donated resources such as computers and
1694 bandwidth is still useful.
1695 o It is very likely that an IETF administrative support organization
1696 would be deemed to clearly fall under the "scientific" and
1697 "educational" grounds for classification as a tax-exempt charity
1698 under section 501(c)(3) of the IRS code, so a tax-exempt
1699 application should be quite straight-forward.
1700 o The incorporation laws of the U.S. states being considered do not
1701 require that any members of the Board of Trustees be of a certain
1702 nationality or state residency (e.g., there are no "local
1703 director" requirements). The U.S. Dept. of Commerce
1704 foreign-controlled organization reporting requirements apply only
1705 to "business enterprises", and do not apply to non-profit entities
1706 such as an IETF administrative support organization.
1708 That said, it should be stated very clearly that any of the three
1709 incorporation domiciles (Switzerland, Netherlands, and U.S.) could
1710 probably be made to work. If the community feels a further in-depth
1711 examination of alternative domiciles is in order, and is willing to
1712 bear the increased costs of time and money, alternative domiciles
1713 could be more carefully examined.
1715 If incorporating in the U.S., Virginia seems a logical pick as the
1716 state of domicile to allow the IETF administrative support
1717 organization to make use of ISOC headquarters to house its single
1718 employee (though the employee might be able to be housed at the
1719 Internet Society even if the incorporation were elsewhere, for
1720 example the ISOC Geneva office). A variety of other options were
1721 examined as states of incorporation, including [Delaware] and
1722 [California], but there appeared to be no significant advantages. In
1723 particular, there are no significant differences in issues such as
1724 director liability that would make incorporating outside the place of
1725 actual domicile attractive.
1727 4.4.1.2 Sample Draft Core Principles
1729 [Ed.: This section intends to state basic principles of establishment
1730 and governance, suitable for publication, after considerable
1731 discussion, as a procedural Best Current Practice document.]
1733 4.4.1.2.1 Sample Draft Principles of Establishment and Governance
1735 The following principles are proposed for the establishment and
1736 governance of an administrative support organization in support of
1737 the IETF under Scenario C, and are based on the Sample Draft Articles
1738 of Incorporation attached in Appendix D.1 and the Sample Draft Bylaws
1739 attached in Appendix D.2:
1740 1. The name of the organization shall be the IETF Foundation.
1741 2. The IETF Foundation shall be incorporated under the laws of the
1742 State of the Virginia in the United States as a non-stock
1743 corporation with a domicile in the State of Virginia and shall
1744 apply for exemption from U.S. taxation under section 501(c)(3)
1745 of the Internal Revenue Code of the United States.
1746 3. The IETF Foundation shall have no members or shareholders.
1747 4. The IETF Foundation shall be governed by a Board of Trustees, who
1748 shall be responsible for the fiscal, legal, and administrative
1749 infrastructure that support the activities of the IETF. The
1750 governance of the IETF, the standards process, and all other
1751 aspects of how we make our standards are defined in the
1752 procedural Best Current Practice RFC series, which will be
1753 explicitly referenced in the organization documents of the IETF
1754 Foundation.
1755 5. The Board of Trustees shall consist of a fixed, odd number of
1756 members, initially set at 7 members.
1757 6. The annual meeting of the Board of Trustees of the IETF
1758 Foundation shall be announced on the IETF mailing list at least
1759 30 days before it occurs and must be held at a regular IETF
1760 meeting. This meeting shall be open to IETF attendees and
1761 minutes shall be promptly published.
1762 7. The Board of Trustees shall appoint a Secretary and a Treasurer,
1763 who need not be members of the Board of Trustees. The
1764 Administrative Director of the IETF Foundation shall provide
1765 staff support to the Board of Trustees.
1766 8. The Board of Trustees shall be composed to strike a balance
1767 between outside and "inside" directors. It is proposed that the
1768 IETF and IAB chairs hold voting, ex-officio seats, and that
1769 mechanisms such as the Nominating Committee and the appointment
1770 of certain seats by the Internet Society fulfill the outside
1771 director obligations.
1773 The Board of Trustees would have strong governance over a limited
1774 scope of activities (e.g., the fiscal, legal, and administrative
1775 infrastructure that are the charter of the IETF Foundation) but would
1776 have no authority over the IETF standards process. In this board
1777 composition, the ISOC and Nomcom appointments insure that outside
1778 directors with no perceived conflicts of interest are on the board.
1780 All nominating bodies should make strong fiscal, legal, and
1781 administrative acumen essential selection criteria for this position.
1782 However, we should note strongly that the Chairs of the IAB and IETF
1783 are ex-officio members (e.g., they are full voting members who hold
1784 the position based on their official roles as chairs of these two
1785 bodies), and that it is not expected that the current criteria for
1786 selection of these two positions should be changed.
1788 For position-based appointments such as the IETF Chair, the Trustee
1789 would serve concurrent with their normal appointment. For non
1790 position-based appointments, a term proposed for the nominated
1791 positions is three years with staggered appointments. However, the
1792 nominating body might have the power to change their appointee during
1793 their term.
1795 All members of the Board of Trustees IETF Foundation are subject to
1796 the same recall procedures in effect for the IETF leadership such as
1797 members of the IAB and IESG. [anchor34]
1799 4.4.1.2.2 Sample Draft Principles of Operation of a Potential IETF
1800 Foundation
1802 [Ed.: This section intends to state basic principles of establishment
1803 and governance, suitable for publication, after considerable
1804 discussion, as a procedural Best Current Practice document. This
1805 section is very tentative and contains principles that are used to
1806 draft bylaws and articles of corporation, samples of which are shown
1807 in Appendix D.1 and Appendix D.2.]
1809 The following are some general principles for the operation of the
1810 IETF Foundation:
1811 1. The IETF Foundation shall employ a Administrative Director of the
1812 IETF Foundation, who shall be hired by the Board of Trustees with
1813 the the advice and consent of the IESG and IAB.
1814 2. All support services shall be contracted in an open and
1815 transparent manner.
1817 3. The Administrative Director shall submit a proposed annual budget
1818 to the Board of Trustees at least 90 days before the beginning of
1819 the fiscal year. Such budget shall be developed with the advice
1820 and consent of the IAB and IESG.
1821 4. The Administrative Director shall serve on the Board of Trustees
1822 as a non-voting, ex-officio member.
1823 5. The Board of Trustees shall select a professional audit firm and
1824 shall commission an audit immediately upon the close of each
1825 fiscal year.
1826 6. The IETF Foundation will conduct financial reporting in a fully
1827 transparent fashion. Audits shall be conducted promptly and
1828 published. Tax returns shall be published. Detailed financial
1829 statements will be published on a regular basis, including timely
1830 reports on the financial results of IETF meetings.
1832 4.5 Scenario D: Autonomous Entity
1834 Scenario D has much of the same analysis as for Scenario C. However,
1835 in this scenario, instead of a mutually-beneficial symbiotic whole,
1836 the IETF Foundation sets out to ensure its own viability independent
1837 of the Internet Society. For instance, the foundation might pursue
1838 direct contributions from industry instead of relying on a unified,
1839 ISOC-based fund raising effort as outlined in Scenario C.
1841 Needless to say, direct solicitation of funds would require great
1842 care to isolate the IETF standards process from funding agencies so
1843 that there can be no question of undue influence. In Scenarios A
1844 through C, this isolation of process from funding is provided by the
1845 Internet Society.
1847 4.6 Discussion of Unincorporated Associations
1849 While many non-profit organizations choose to incorporate, this is
1850 not the only institutional structure available. In the U.S., as in
1851 several other countries, there is a concept of an unincorporated
1852 association, a legal structure that allows groups of individuals to
1853 form an association that has certain powers under the law, including
1854 in some cases limitations of liability and the ability to hold real
1855 property and make agreements. [anchor38]
1857 The concept of the unincorporated association is important for two
1858 reasons:
1859 1. "The IETF" is a nebulous concept since the community has chosen
1860 not to incorporated, define membership, or perform other actions
1861 that give the community "standing" in the legal world. But, to
1862 the extent that "the IETF" does exist, it is an unincorporated
1863 association. For example, [RFC2860] creates a Memorandum of
1864 Understanding between ICANN and "the Internet Engineering Task
1865 Force, the unincorporated association operating under such name
1866 that creates Internet Standards and related documents."
1867 2. In addition, a formal registration of an unincorporated
1868 association, as discussed in this section, is a legal mechanism
1869 that could be used to create an IETF Administrative Entity and is
1870 thus relevant to the discussion of Scenarios A through D.
1872 The concept of unincorporated association has sprung up in case law
1873 over many years, as groups of people formed social clubs, veterans
1874 groups, and other communities of interest. Inevitably, these
1875 communities ran into conflicts and the courts were forced to face
1876 questions such as whether these communities could be sued, hold
1877 property, or make contracts.
1879 This section does not attempt to discuss the standing of "the IETF"
1880 or "the IETF community" as it presently stands under case law
1881 governing unincorporated associations. Instead, this section
1882 describes a series of fairly recent developments in United States
1883 case law that are relevant to the discussion of the legal form that
1884 an IETF Administrative Entity might take.
1886 In the United States, a Uniform Unincorporated Nonprofit Association
1887 Act was passed in 1996 by the Uniform Law Commissioners [UUNAA]. The
1888 uniform law has since been enacted by Delaware and 9 other states, as
1889 well as the District of Columbia [ULC]. Unincorporated nonprofit
1890 associations can be granted federal exemption from taxes under
1891 section 501(c)(3) of the IRS Code if they meet two tests:
1892 1. *The Organizational Test.* The basic chartering document must
1893 state that the organization is "organized and operated
1894 exclusively" for an exempt purpose and that "no part of the net
1895 income of which inures to the benefit of any private shareholder
1896 or individual." In addition, upon dissolution, any assets must
1897 be distributed only for one or more exempt purposes (or to the
1898 federal government). [IRS-Org]
1899 2. *The Operational Test.* The actual operation of the organization
1900 must meet the requirements of the Internal Revenue Service and
1901 must fall within the limits and purposes set out in the
1902 chartering document.
1903 The organization test is thus theory, the operational test practice,
1904 and the two must achieve the same purposes.
1906 The unincorporated association structure is also available in other
1907 countries, such as the United Kingdom[Charity], but this analysis is
1908 confined to the U.S. structure.
1910 Some examples of unincorporated associations include:
1911 o For 180 years, from the founding until 1971, the New York Stock
1912 Exchange was an unincorporated association. In 1971, the Exchange
1913 shifted to a nonprofit corporate structure as part of a governance
1914 reform that gave greater voice to non-owners, such as listed
1915 companies and investors. The incorporation was concurrent with
1916 other changes, such as an increased role for professional
1917 management and other mechanisms suited to the "unique role and
1918 governance structure" of the Exchange [NYSE].
1919 o Founded in 1878, the American Bar Association functioned
1920 exclusively as an unincorporated association until 1972, at which
1921 time a parallel incorporated entity was chartered under Illinois
1922 law, also called the American Bar Association [ABA].
1923 o The World Science Fiction Society (WSFS) has "for over 50 years
1924 ... annually franchised local groups to run the World Science
1925 Fiction Convention (typical attendance over 5000) and oversee the
1926 selection of the Hugo Award winners."[Eastlake]
1927 o Many labor unions are organized as unincorporated associations
1928 (see [Busby]) as well as church groups, homeowner associations,
1929 scouting troops, parent teacher associations, and many others.
1931 An association is defined in a chartering document, typically labeled
1932 a "Constitution" or "Articles of Association." The association must
1933 have two or more members who are "joined by mutual consent for a
1934 common purpose." Members are defined as persons (which includes
1935 individuals, but also any other legal entity such as a corporation or
1936 government department) who "may participate in the selection of
1937 persons authorized to manage the affairs of the nonprofit association
1938 or in the development of policy of the nonprofit association."
1939 Mechanisms such as randomly selected nominating committees appear to
1940 adequately satisfy the "may participate in the selection"
1941 requirement.
1943 The unincorporated association is not as broad as other forms, such
1944 as an incorporated association. However, the unincorporated
1945 association does have several rights, such as:
1946 1. The ability to hold property which is separate from its members.
1947 This includes the ability to have a bank account
1948 2. A nonprofit association is a legal entity separate from its
1949 members for the purposes of determining and enforcing rights,
1950 duties, and liabilities in contract and tort. This also results
1951 in the ability to contract for insurance coverage, such as
1952 general liability, general commercial liability, errors &
1953 omissions (E&O), or directors and officers (D&O) policies.
1954 3. The ability to employ staff.
1956 The limitations on liability are important changes over older common
1957 law, which held individual members liable for the actions of the
1958 association. Needless to say, individual members can still be held
1959 liable for their own actions, but under the uniform law, they cannot
1960 be held liable for the actions of the association merely by being a
1961 member. Likewise, under the uniform law, the association has
1962 standing in court and can sue or be sued.
1964 The unincorporated association, under the uniform law, thus provides
1965 many of the benefits of the corporate form. It can be considered, to
1966 some extent, as a sort of "corporation-lite" [CLRC].
1968 5. Future Work
1970 5.1 Short-Term
1972 This report outlines some fundamental decisions facing the IETF
1973 community about how administrative support functions should be
1974 procured and what institutional framework they should be housed in.
1975 If a consensus is reached on a direction to move on these key
1976 decisions, a number of short-term tasks will be required:
1977 1. Formulation of a budget for 2005, including a cash flow analysis.
1978 2. If formal incorporation is chosen, drafting and filing of bylaws
1979 and articles. If an operating unit is chosen, drafting of any
1980 memoranda of understanding.
1981 3. If a decision is made to negotiate a sole source contract for one
1982 or more functions, a negotiating team would need to be appointed.
1983 4. If a decision is made to issue a Request for Proposal for one or
1984 more functions, a drafting team would need to be appointed and a
1985 process for evaluation described.
1986 5. If a decision is made to appoint an Administrative Director, a
1987 call for applicants would need to be issued.
1989 5.2 Long-Term
1991 While [RFC3716] set out principles for administrative restructuring,
1992 it should be remembered that administrative restructuring is just one
1993 of the tasks facing the IETF. [RFC3774] set out a number of
1994 fundamental issues facing the community. Any administrative
1995 restructuring should be performed quickly and efficiently, allowing a
1996 renewed focus on more important issues, such as how the IETF can
1997 remain and become "an open global community of network designers,
1998 operators, vendors, and researchers producing technical
1999 specifications for the evolution of the Internet architecture and the
2000 smooth operation of the Internet."[RFC3233]
2002 Much of that focus on "more important issues" is already present in
2003 the IETF today. Working Groups such as [NEWTRK] and [ICAR] are
2004 looking hard at the basic IETF processes and how they can be made
2005 better.
2007 In considering the future, it is often worth looking at the past.
2008 Edwin T. Layton, Jr., in his 1986 study of the rise (and fall) of
2009 standards bodies in 1900's, tells of an interesting group, the
2010 Institute of Radio Engineers (IRA). Founded in 1912, the IRA was
2011 different from other professional bodies of the time, with a focus on
2012 individual instead of corporate membership, an adherence to
2013 engineering excellence, and, despite being a predominantly American
2014 body, insisting that the word "American" not be added to the IRE's
2015 name as a way of emphasizing the international nature of their
2016 pursuits [Layton]. The IRA was founded in reaction to
2017 dissatisfaction with a more formal body of the time, the American
2018 Institute of Electrical Engineers (AIEE). The IRA became known for
2019 pioneering work in standards area such as FM and commercial
2020 black-and-white and color television. Although the IRA was one of
2021 the smaller standards bodies, it was one of the most effective
2022 [Hoffman]. In 1963, the IRA merged with the AIEE to become the IEEE.
2024 Layton's study of professional societies and standards bodies in the
2025 engineering profession from early the 1900 to the 1960s is highly
2026 instructive, particularly the way different groups dealt with the
2027 tensions between the role of participants as individuals engineers
2028 versus their other roles as corporate employees or representatives of
2029 countries. The long-term relevance of the IETF is directly tied to
2030 the ability of the community to focus on core values such as "rough
2031 consensus and running code"[RFC1958] and an avoidance of
2032 entanglements at layers 8-10 of the OSI Reference Model [OSI].
2034 As Thomas Huxley once commented in describing the conduct of the
2035 affairs of the Royal Society, "our business was (precluding matters
2036 of theology and state affairs) to discourse and consider of
2037 philosophical enquiries, and such as related thereunto."[Huxley] The
2038 IETF can certainly learn much from an examination of it's own guiding
2039 principles and by examining the history of other SDOs such as the
2040 Royal Society and the Institute of Radio Engineers.
2042 6. Acknowledgment of CNRI Contribution to the IETF Community
2044 As this plan proposes a transition from the past to the future, the
2045 author feel it is essential to acknowledge the enormous contributions
2046 made to the IETF and the Internet by the Corporation for National
2047 Research Initiatives (CNRI) and their Chairman, CEO, and President,
2048 Dr. Robert E. Kahn.
2050 Dr. Kahn's pioneering early leadership in the evolution of the
2051 Internet is well-known, including the seminal paper on the
2052 Transmission Control Protocol,[Cerf_Kahn] his key operational role in
2053 engineering the early Internet (see, e.g., [RFC0371]), and his
2054 leadership of the vastly influential DARPA Information Processing
2055 Techniques Office (IPTO), where he initiated a billion-dollar
2056 Strategic Computing Program which was responsible for funding,
2057 guiding, and encouraging technology that makes up much of today's
2058 infrastructure.
2060 Perhaps less well-known or appreciated is the contribution that Dr.
2061 Kahn and CNRI have made to the evolution of the IETF. Since 1987,
2062 CNRI has housed the IETF Secretariat, supporting 56 IETF meetings
2063 with over 55,000 total attendees, not to mention over 30,000
2064 Internet-Drafts processed, several thousand teleconferences hosted,
2065 and a theoretically finite but practically uncountable number of
2066 cookies consumed.
2068 CNRI's support allowed the IETF community to evolve in the way it
2069 has. Many of the values we have created as a community were possible
2070 only possible because we had a professional secretariat to provide
2071 support. For example, the IETF takes very seriously the idea that
2072 individuals, not institutions or countries, are the participants (not
2073 members) in the process. A stable secretariat has allowed us to
2074 preserve those values without worrying about pesky issues such as
2075 corporate sponsorship or membership fees.
2077 A number of CNRI and Foretec staff have formed the secretariat over
2078 the years. These people have all worked long and hard and, for many
2079 IETF participants, these staff have been instrumental in making the
2080 IETF an effective forum for the development of Internet standards and
2081 technology. They deserve our sincere and continuing thanks.
2083 As the IETF has scaled, we have continued to rely on CNRI to provide
2084 a base of stability. As the IETF passes the age of 18, it is time
2085 for the IETF to take responsibility for its own affairs.
2087 7. Acknowledgment of Contributions and Reviews
2089 A number of people contributed their time in telephone interviews,
2090 email exchanges, and reviews of the draft. These exchanges resulted
2091 in many useful suggestions. Needless to say, our acknowledgment of
2092 their contribution should not in any way be used to necessarily infer
2093 support for anything contained herein. These individuals include:
2094 Bernard Aboba, Harald Alvestrand, Rob Austein, Fred Baker, Bob
2095 Braden, Scott Bradner, Brian Carpenter, David Clark, Jorge Contreras,
2096 Dave Crocker, Steve Crocker, Joao Damas, Leslie Daigle, Lynn DuVal,
2097 Patrik Falstrom, Bill Fenner, Ted Hardie, Bob Hinden, Paul Hoffman,
2098 Geoff Huston, David Kessens, Robert Kahn, Daniel Karrenberg, John
2099 Klensin, Rebecca Malamud, Allison Mankin, Jordi Palet Martinez,
2100 Thomas Narten, Jun Murai, Thomas Narten, Eric Rescorla, Pete Resnick,
2101 Joyce Reynolds, Lynn St. Amour, Mike St. Johns, Paul Vixie,
2102 Margaret Wasserman, and Bert Wijnen. The author apologizes for any
2103 names inadvertently omitted.
2105 This document was created with "xml2rfc"
2106 using the format specified in [RFC2629]. PDF renditions of the
2107 document were created with Julian Reschke's XSLT style sheets
2108 and diffs from
2109 prior draft were produced using Henrik Levkowetz's "rfcdiff" tool
2110 .
2112 8. IANA Considerations
2114 [RFC2434] states each Internet-Draft should contain an "IANA
2115 Considerations" section. [RFC3716] noted that a frequent problem for
2116 the IANA is documents that do not contain such a section, thus
2117 requiring a full scan of the document.
2119 This submission contains no specific modifications to existing
2120 registries or creation of new registries. However, the submission
2121 contains a number of sections that may impact the overall operation
2122 of the IANA. A full scan of the document is thus recommended.
2124 9. Security Considerations
2126 Improper formulation of the legal framework underlying the IETF may
2127 expose the institution and individuals in leadership positions to
2128 potential legal risks. Any such risk under this plan appears to be
2129 equivalent to the risk faced by the community under the current legal
2130 framework. This risk is further mitigated by a thorough review by
2131 legal counsel, and by use of insurance coverage.
2133 The legal exposure is best minimized by a careful adherence to our
2134 procedures and processes, as defined by the Best Current Practice
2135 Series. A carefully stated process, such as the BCP documents that
2136 govern the selection of leadership positions and define the standards
2137 process are the best insurance against legal exposure, provided care
2138 is taken to stick to the process standards that have been set.
2139 Adherence to a public rule book and a fully open process are the most
2140 effective mechanisms the IETF community can use.
2142 Improper management controls and procedures or other imprudent fiscal
2143 or administrative practices could expose the IETF to a risk of
2144 insolvency. Careful selection of trustees, a process of budget
2145 approval, and a methodical system of fiscal controls are necessary to
2146 minimize this risk.
2148 10. References
2150 10.1 Normative References
2152 [RFC1958] Carpenter, B., "Architectural Principles of the Internet",
2153 RFC 1958, June 1996.
2155 [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines
2156 and Procedures", BCP 8, RFC 2014, October 1996.
2158 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
2159 3", BCP 9, RFC 2026, October 1996.
2161 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in
2162 the IETF Standards Process", BCP 11, RFC 2028, October
2163 1996.
2165 [RFC2031] Huizer, E., "IETF-ISOC relationship", RFC 2031, October
2166 1996.
2168 [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
2169 RFC 2223, October 1997.
2171 [RFC2418] Bradner, S., "IETF Working Group Guidelines and
2172 Procedures", BCP 25, RFC 2418, September 1998.
2174 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
2175 IANA Considerations Section in RFCs", BCP 26, RFC 2434,
2176 October 1998.
2178 [RFC2555] Braden, R., Reynolds, J., Crocker, S., Cerf, V., Feinler,
2179 J. and C. Anderson, "30 Years of RFCs", RFC 2555, April
2180 1999.
2182 [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of
2183 the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
2184 May 2000.
2186 [RFC2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of
2187 Understanding Concerning the Technical Work of the
2188 Internet Assigned Numbers Authority", RFC 2860, June 2000.
2190 [RFC3005] Harris, S., "IETF Discussion List Charter", BCP 45, RFC
2191 3005, November 2000.
2193 [RFC3184] Harris, S., "IETF Guidelines for Conduct", BCP 54, RFC
2194 3184, October 2001.
2196 [RFC3233] Hoffman, P. and S. Bradner, "Defining the IETF", BCP 58,
2197 RFC 3233, February 2002.
2199 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
2200 3667, February 2004.
2202 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF
2203 Technology", BCP 79, RFC 3668, February 2004.
2205 [RFC3677] Daigle, L. and Internet Architecture Board, "IETF ISOC
2206 Board of Trustee Appointment Procedures", BCP 77, RFC
2207 3677, December 2003.
2209 [RFC3683] Rose, M., "A Practice for Revoking Posting Rights to IETF
2210 mailing lists", BCP 83, RFC 3683, February 2004.
2212 [RFC3710] Alvestrand, H., "An IESG charter", RFC 3710, February
2213 2004.
2215 [RFC3716] Advisory, IAB., "The IETF in the Large: Administration and
2216 Execution", RFC 3716, March 2004.
2218 [RFC3774] Davies, E., "IETF Problem Statement", RFC 3774, May 2004.
2220 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and
2221 Recall Process: Operation of the Nominating and Recall
2222 Committees", BCP 10, RFC 3777, June 2004.
2224 10.2 Informative References
2226 [.] Malamud, C., Ed., "IETF Administrative Support Functions",
2227 draft-malamud-consultant-report-01 (work in progress),
2228 September 2004, .
2230 [ABA] American Bar Association, "Constitution and Bylaws of the
2231 American Bar Association and Rules of Procedure of the
2232 House of Delegates", August 1994,
2233 .
2236 [Bingo] Anonymous, "Buzzword Bingo", 1996,
2237 .
2239 [Busby] U.S. Supreme Court, "Busby v. Electric Utilities Employees
2240 Union", 323 U.S. 72, December 1944,
2241 .
2244 [CLRC] California Law Revision Commission, "Uniform
2245 Unincorporated Nonprofit Association Act: Governance
2246 Issues", Staff Memorandum 2002-59, Study B-501, October
2247 2002, .
2249 [CNRI-2002]
2250 CNRI, "Form 990 - Return of Organization Exempt from
2251 Income Tax - 2002", EIN 52-1447747, November 2003.
2253 [California]
2254 State of California, "California Corporations Code",
2255 Undated,
2256 .
2259 [Cerf_Kahn]
2260 Cerf, V. and R. Kahn, "A Protocol for Packet Network
2261 Intercommunication", IEEE Trans. on Comm., Vol. COM-23,
2262 pp. 637-648, May 1974.
2264 [Charity] Charity Commission for England and Wales, "GD3 - Model
2265 Constitution for a Charitable Unincorporated Association",
2266 July 2004,
2267 .
2270 [Delaware]
2271 State of Delaware, "Title 8. Corporations -- Chapter 1.
2272 General Corporation Law -- Subchapter 1. Formation",
2273 Undated,
2274 .
2277 [Eastlake]
2278 Eastlake, D., "ISOC etc. (ignore if you don't like lengthy
2279 legal flames)", IETF Mailing List, February 1995,
2280 .
2282 [FASB-117]
2283 Financial Accounting Standards Board (FASB), "Financial
2284 Statements of Not-For-Profit Organizations", FASB 117,
2285 June 1993,
2286 .
2288 [Hoffman] IEEE Center for the History of Electrical Engineering,
2289 "The Origins of the IEEE", 1984,
2290 .
2293 [Huxley] Huxley, T., "On the Advisableness of Improving Natural
2294 Knowledge (A Lay Sermon Delivered in St. Martin's Hall)",
2295 Project Gutenberg THX1410, Fortnightly Review 3 (1866):
2296 626-37, January 1866,
2297 .
2300 [I-D.alvestrand-ietf-mission]
2301 Alvestrand, H., "A Mission Statement for the IETF",
2302 draft-alvestrand-ietf-mission-02 (work in progress), June
2303 2004.
2305 [I-D.daigle-adminrest]
2306 Daigle, L., "A Proposal for IETF Administrative
2307 Restructuring", draft-daigle-adminrest-00 (work in
2308 progress), February 2004.
2310 [I-D.ietf-xmpp-core]
2311 Saint-Andre, P., "Extensible Messaging and Presence
2312 Protocol (XMPP): Core", draft-ietf-xmpp-core-24 (work in
2313 progress), May 2004.
2315 [I-D.narten-iana-considerations-rfc2434bis]
2316 Narten, T. and H. Alvestrand, "Guidelines for Writing an
2317 IANA Considerations Section in RFCs",
2318 draft-narten-iana-considerations-rfc2434bis-00 (work in
2319 progress), August 2004.
2321 [I-D.rfc-editor-rfc2223bis]
2322 Reynolds, J. and R. Braden, "Instructions to Request for
2323 Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-08
2324 (work in progress - do not cite as a normative reference),
2325 July 2004,
2326 .
2329 [ICAR] The IETF, "Charter of the Improved Cross-Area Review
2330 (icar) Working Group", June 2004,
2331 .
2333 [IETF-2001]
2334 Alvestrand, H., "The Financials of the IETF -- 2001",
2335 February 2003,
2336 .
2338 [IETF-2002]
2339 Alvestrand, H., "The Financials of the IETF -- 2002", July
2340 2003,
2341
2342 .
2344 [IETF-2003]
2345 Alvestrand, H., "The Financials of the IETF -- 2003", May
2346 2004,
2347
2348 .
2350 [IETF-2004]
2351 Alvestrand, H., "The IETF Budget -- 2004", May 2004,
2352 .
2354 [IRS] U.S. Code, "Title 26, Sec. 501: Exemption from tax on
2355 corporations, certain trusts, etc.", Undated,
2356 .
2358 [IRS-Org] Internal Revenue Service, "The Organizational Test for
2359 Under IRC 501(c)(3)", August 2003,
2360 .
2362 [ISOC-2002]
2363 Internet Society, "Form 990 - Return of Organization
2364 Exempt from Income Tax - 2002", EIN 52-1650477, October
2365 2003.
2367 [ISOC-2004]
2368 Internet Society, "37th Board of Trustees meeting of the
2369 Internet Society", Resolution 3-20, December 2003,
2370 .
2372 [ISOC-Gov]
2373 Internet Society, "Procedures for selecting Trustees",
2374 Board Resolution 02-2, 2002.
2376 [ISOC-Gov2]
2377 Internet Society, "Resolution 01-10 Procedures for
2378 Nomination and Election of Trustees by Individual
2379 Members", Board Resolution 01-10, 2001.
2381 [Layton] Layton, E., "The Revolt of the Engineers", The John
2382 Hopkins University Press, ISBN 0-8018-3287-X, 1986.
2384 [NEWTRK] The IETF, "Charter of the New IETF Standards Track
2385 Discussion (newtrk) Working Group", June 2004,
2386 .
2388 [NYSE] Governance Committee of the NYSE Board, "Governance of the
2389 New York Stock Exchange", May 2003,
2390 .
2392 [OSI] Wikepedia, "Open Systems Interconnection Reference Model",
2393 ISO/IEC 7498-1, August 2004,
2394 .
2396 [RFC-SOW] Internet Society, "Statement of Work--RFC Editor",
2397 Undated,
2398 .
2400 [RFC0015] Carr, C., "Network subsystem for time sharing hosts", RFC
2401 15, September 1969.
2403 [RFC0371] Kahn, R., "Demonstration at International Computer
2404 Communications Conference", RFC 371, July 1972.
2406 [RFC2134] ISOC Board of Trustees, "ARTICLES OF INCORPORATION OF
2407 INTERNET SOCIETY", RFC 2134, April 1997.
2409 [RFC2135] ISOC Board of Trustees, "Internet Society By-Laws", RFC
2410 2135, April 1997.
2412 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
2413 June 1999.
2415 [RFC3844] Davies, E. and J. Hofmann, "IETF Problem Resolution
2416 Process", RFC 3844, August 2004.
2418 [Texas] Texas Sunset Advisory Commission, "Guide to the Texas
2419 Sunset Process", December 2003,
2420 .
2422 [ULC] Uniform Law Commissioners, "UUNAA Legislative Fact Sheet",
2423 2004,
2424 .
2427 [UUNAA] Uniform Law Commissioners, "Uniform Unincorporated
2428 Nonprofit Association Act (1996)", National Conference of
2429 Commissioners on Uniform State Laws, 1996,
2430 .
2433 [Virginia]
2434 State of Virginia, "Title 13.1: Corporations, Limited
2435 Liability Companies, Business Trusts", Undated,
2436 .
2439 [Wayback] Internet Archive, "Wayback Machine: Comparison of
2440 www.ietf.org for Jan. 7, 1997 and Feb. 15, 2004",
2441 September 2004,
2442 .
2448 URIs
2450 [1]
2452 [2]
2454 [3]
2458 [4]
2462 [5]
2466 [6]
2470 [7]
2472 [8]
2476 [12]
2478 [13]
2480 [14]
2482 [15]
2484 [16]
2486 [17]
2489 Editorial Comments
2491 [anchor24] Editor: It has been noted that any such action would, of
2492 course, require the full approval and cooperation of the
2493 Internet Society Board. The fundamental chartering
2494 document for ISOC are the articles of incorporation,
2495 which require 4/5 approval of the board for changes
2496 [RFC2134]. The bylaws, as published in [RFC2135] and
2497 periodically amended through board resolutions, requires
2498 a 2/3 vote for certain changes to the bylaws. Governance
2499 is specified in general terms in [RFC2135] and further
2500 specified in a series of board resolutions. Composition
2501 of and the procedures for selection of members of the
2502 board is specified in Board Resolution 02-2 [ISOC-Gov]
2503 which is "generally harmonious" with [ISOC-Gov2], which
2504 is currently suspended.
2506 [anchor25] Editor: Several reviewers have pointed out drawbacks of
2507 this mechanism, particularly the loss of independence of
2508 those director seats. These reviewers have pointed out
2509 that if the IETF and IAB Chairs have seats on the board
2510 as ex-officio members, sufficient representation of IETF
2511 interests is present.
2513 [anchor26] Editor: Reviewers have noted that this mechanism would be
2514 necessary under Scenario A as well.
2516 [anchor27] Editor: Several reviewers have noted that the ISOC board
2517 does in fact already conduct open meetings. This
2518 mechanism simply suggests more IETF participation in
2519 those meetings as a way of drawing the community
2520 together.
2522 [anchor28] Editor: This suggestion came from Marshall T. Rose.
2524 [anchor34] Mike St. Johns: Use of the Nomcom and the recall
2525 procedure are both inappropriate as they are tailored
2526 towards selection of and recall of technical leadership,
2527 which is not necessarily appropriate for the fiscal,
2528 legal, and administrative skill sets needed in a board
2529 for the Foundation.
2531 [anchor38] Editor: Several members of the community, including Rob
2532 Austein, Brian Carpenter, Donald Eastlake, Robert Kahn,
2533 and Patrice Lyons suggested an analysis of the
2534 "unincorporated association" mechanism as an alternative
2535 to formal incorporation.
2537 Author's Address
2539 Carl Malamud (editor)
2540 Memory Palace Press
2541 PO Box 300
2542 Sixes, OR 97476
2543 US
2545 EMail: carl@media.org
2546 URI: http://infinite.simians.net/
2548 Appendix A. Consulting Contract
2550 AGREEMENT FOR CONSULTING SERVICES
2551 Contract between CARL MALAMUD AND THE INTERNET SOCIETY
2553 *Contract:*
2555 Carl Malamud (hereafter known as the Consultant) agrees to provide
2556 consulting services to the Internet Engineering Task Force (IETF),
2557 the Internet Architecture Board (IAB) and the Internet Society (ISOC)
2558 subject to the terms and conditions specified below. Under this
2559 agreement, the Consultant is acting as an independent contractor and
2560 assumes all responsibilities for federal and state income taxes,
2561 social security and medicare tax, medical insurance, and other
2562 applicable filings associated with his status.
2564 *Scope:*
2566 The Consultant will provide the following services outlined in
2567 Appendix I. It is anticipated that the responsibilities will require
2568 20 days per month to accomplish the objectives for which said
2569 Consultant was engaged.
2571 Consultant understands and agrees that this Contract is being
2572 executed with a view to supporting the IETF/IAB as it considers
2573 whether, and if so, how, it might wish to restructure for purposes of
2574 future IETF/IAB endeavors. In the performance of this Contract,
2575 Consultant agrees to exercise fair and professional judgment for the
2576 benefit of the IETF/IAB and to treat all existing and/or potential
2577 partners of the IETF/IAB in a fair manner while protecting any
2578 business confidences that each might have.
2580 *Contract Term:*
2582 The contract will begin on 21 June 2004 and end on 21 December 2004.
2583 For services rendered under this contract the Consultant will be paid
2584 a fee of $16,000 per month due and payable at the end of each month
2585 upon receipt of an invoice. Consultant will be required to submit a
2586 monthly accounting of days worked. Should the days worked in any
2587 month exceed 20, no additional fees are due. The contract may only
2588 be extended by written agreement specifying new services, terms, and
2589 conditions as mutually agreed to by both parties.
2591 *Expenses:*
2593 All expenses incurred on behalf of the IETF/IAB or ISOC shall be
2594 billed to ISOC in addition to charges for services provided above.
2595 Such expenses shall include travel, long distance telephone, business
2596 meals, and other customary expenses as appropriate. Such expenses
2597 should be authorized by ISOC, after consultation with the IETF and
2598 the IAB Chairs, and in advance of the expenditure.
2600 *Invoicing:*
2602 Consultant shall submit invoices at the end of each month (pro-rated
2603 for June and December). The Internet Society will make best efforts
2604 to make payment within one week of receipt. If consultant worked
2605 less than 20 days, then ISOC may reduce the monthly fee due by 1/20th
2606 of such fee for each day less than 20. Invoices may be submitted
2607 electronically or by mail. The invoices should be addressed to the
2608 Internet Society's Finance Director, Lynn DuVal at the Reston office
2609 (1775 Wiehle Avenue, Suite 102, Reston, VA 20190) or by e-mail at
2610 duval@isoc.org.
2612 *Termination:*
2614 Either party may terminate this Contract by providing ten (10) days
2615 prior written notice sent by e-mail to the addresses noted below.
2617 In addition, should the subject matter addressed in this Contract
2618 become, in whole or in part, the subject matter of any filed or
2619 threatened litigation then either party may terminate this Contract
2620 by providing five (5) days prior written notice sent as per the above
2621 paragraph.
2623 The days of prior written notice above shall be measured from the
2624 date sent.
2626 The Internet Society will be responsible for all fees properly
2627 incurred under this Contract prior to the effective date of
2628 termination.
2630 If such a termination should occur other than at a month-end, then
2631 payment for services shall be paid pro rata, up to 100% of the
2632 monthly rate, at the rate of 1/20th of the monthly services fee per
2633 day worked to termination
2635 *Miscellaneous:*
2637 ISOC does not wish for itself or others to receive any confidential,
2638 proprietary information of any other party without proper permission.
2639 Consequently, Consultant agrees not to use or divulge, in his efforts
2640 relating to this contract, any information in any form, tangible or
2641 intangible, that is the confidential information of any third party,
2642 whether IETF/IAB, any contractor or partner of IETF/IAB, or any other
2643 party, to ISOC or any other party without the express written
2644 permission of the party or parties who own or control such
2645 confidential material and without first disclosing such written
2646 permission to ISOC.
2648 Consultant agrees that any tangible or intangible work product that
2649 results from Consultant's efforts under this Contract (whether by
2650 Consultant or a contractor to Consultant) shall be the exclusive
2651 property of ISOC or the IETF/IAB, as appropriate, and this includes,
2652 without limitation, any invention, product, business process, code or
2653 other device or discovery that might now or hereafter be entitled to
2654 protection, registration or ownership under intellectual property
2655 rights regimens such as, but not only, trade secret, patent,
2656 copyright, and trademark.
2658 ISOC may disclose the terms of this Contract to the IETF/IAB or any
2659 other party having an interest in the subject matter hereof that ISOC
2660 deems reasonable.
2662 *Warranties and Indemnities:*
2664 This written agreement constitutes the full agreement between the
2665 parties. No warranties or indemnities are explicitly included or
2666 implied.
2668 *Amendments:*
2670 Amendments to this agreement must be in writing and executed by both
2671 parties.
2673 +---------------------------------+---------------------------------+
2674 | Executed on behalf of The | Executed on behalf of the |
2675 | Internet Society | Consultant |
2676 +---------------------------------+---------------------------------+
2677 | Lynn St. Amour | Carl Malamud |
2678 | | |
2679 | President & CEO | |
2680 | | |
2681 | st.amour@isoc.org | carl@media.org |
2682 | | |
2683 | Date: | Date: |
2684 +---------------------------------+---------------------------------+
2686 *Appendix I: Statement of Work*
2688 The IETF/IAB is considering an Administrative restructuring and has
2689 asked ISOC to support their efforts. The contract to which this is
2690 attached is in furtherance of this endeavor.
2692 Consultant shall become familiar with RFC 3716 as the basis for these
2693 efforts and shall use such RFC as a reference point in these efforts
2694 except to the extent that this Contract or any guidance supplied to
2695 Consultant by IETF/IAB or ISOC under this contract supercedes such
2696 RFC.
2698 The types of activities Consultant shall undertake are:
2699 o Assist in researching, recommending and ultimately drafting the
2700 proposed structure/bylaws for the IETF administrative entity;
2701 o Revising proposed structure and/or bylaws based on the public
2702 review, including reviews by counsel;
2703 o Negotiate appropriate contract(s) for RFC Editor and/or other
2704 contractors as a model for eventual use by the IETF administrative
2705 entity;
2706 o Conduct appropriate liaison with the RFC Editor, IANA and
2707 Secretariat to determine the requirements for inter-organizational
2708 document flow matched to overall IETF/IAB process needs.
2709 o Others as reasonably directed by ISOC, IETF and or IAB
2711 Deliverables hereunder shall include:
2712 o Data Flow: a comprehensive set of requirements for implementing
2713 appropriate tracking of IETF/IAB documents and reporting of status
2714 across support organizations.
2715 o Negotiated contracts, per the above, that are acceptable to all
2716 concerned parties and are ready for execution.
2717 o Administrative restructuring: documentation and support, as
2718 appropriate, to the continued evolution of the restructuring
2719 effort, which shall be periodically reviewed by the IAB, IESG and
2720 other appropriate parts of the IETF community of interest.
2722 Appendix B. IETF Financial Information
2724 B.1 Consolidated 3-Year Historical Income Statement
2726 (US$)
2728 +------------------+------------+-----------+-----------+-----------+
2729 | | 2001 [1] | 2002 [2] | 2003 [3] | 2004 [4] |
2730 +------------------+------------+-----------+-----------+-----------+
2731 | REVENUE | | | | |
2732 | | | | | |
2733 | CNRI/Foretec | 2,699,239 | 2,350,666 | 2,060,747 | 1,728,125 |
2734 | Meeting Revenue | | | | |
2735 | | | | | |
2736 | Less Bank Fees | 81,365 | 70,309 | 62,826 | 51,844 |
2737 | | | | | |
2738 | Net Meeting | 2,617,874 | 2,280,357 | 1,997,921 | 1,676,281 |
2739 | Revenue | | | | |
2740 | | | | | |
2741 | Contribution By | 535,535 | 550,881 | 614,691 | 663,570 |
2742 | The Internet | | | | |
2743 | Society [5] | | | | |
2744 | | | | | |
2745 | Provision of the | -- | -- | -- | -- |
2746 | IANA function by | | | | |
2747 | ICANN [6] | | | | |
2748 | | | | | |
2749 | Other | -- | -- | -- | 150,000 |
2750 | Contributions | | | | |
2751 | | | | | |
2752 | TOTAL FUNDS | 3,153,409 | 2,831,238 | 2,612,612 | 2,489,851 |
2753 | | | | | |
2754 | | | | | |
2755 | EXPENSE | | | | |
2756 | | | | | |
2757 | ISOC | | | | |
2758 | Expenditures | | | | |
2759 | | | | | |
2760 | RFC Editor | 428,300 | 462,368 | 516,460 | 574,570 |
2761 | | | | | |
2762 | IETF Chair | 73,748 | 52,137 | 51,460 | 48,500 |
2763 | Discretionary | | | | |
2764 | Fund | | | | |
2765 | | | | | |
2766 | IAB Support | 13,287 | 14,446 | 37,270 | 24,500 |
2767 | | | | | |
2768 | Insurance | 20,000 | 21,930 | 13,685 | 16,000 |
2769 | | | | | |
2770 | Total ISOC | 535,535 | 550,881 | 614,691 | 663,570 |
2771 | Expenditures | | | | |
2772 | | | | | |
2773 | | | | | |
2774 | CNRI/Foretec | | | | |
2775 | Expenditures | | | | |
2776 | | | | | |
2777 | Secretariat | 504,584 | 625,124 | 532,936 | 478,000 |
2778 | Labor | | | | |
2779 | | | | | |
2780 | IETF Meeting | | | | |
2781 | Costs | | | | |
2782 | | | | | |
2783 | Food & Beverage | 862,500 | 705,610 | 513,081 | 487,500 |
2784 | | | | | |
2785 | Audio/Visual | 127,337 | 83,239 | 96,902 | 60,000 |
2786 | | | | | |
2787 | Room Rental | 190,265 | 172,907 | 125,187 | 170,000 |
2788 | | | | | |
2789 | Terminal Room | -- | -- | 66,294 | 25,000 |
2790 | | | | | |
2791 | Other Meeting | 1,925 | 8,340 | 13,367 | 6,000 |
2792 | Costs | | | | |
2793 | | | | | |
2794 | Total IETF | 1,182,027 | 970,096 | 814,831 | 748,500 |
2795 | Meeting Costs | | | | |
2796 | | | | | |
2797 | | | | | |
2798 | Non-Meeting | | | | |
2799 | Costs | | | | |
2800 | | | | | |
2801 | Travel | 39,122 | 53,838 | 78,947 | 75,000 |
2802 | | | | | |
2803 | Materials | 7,318 | 11,724 | 9,706 | 10,700 |
2804 | | | | | |
2805 | Printing & | 59,431 | 31,459 | 14,266 | 12,000 |
2806 | Publication | | | | |
2807 | | | | | |
2808 | Professional | 24,581 | 61,105 | 12,288 | 9,000 |
2809 | Services | | | | |
2810 | | | | | |
2811 | Telecommunicatio | 54,400 | 82,210 | 32,582 | 42,000 |
2812 | ns | | | | |
2813 | | | | | |
2814 | Misc. | 12,003 | 577 | -- | 4,000 |
2815 | | | | | |
2816 | Equipment Rental | 4,668 | 736 | 1,630 | 2,500 |
2817 | | | | | |
2818 | Total | 201,523 | 241,650 | 149,419 | 155,200 |
2819 | Non-Meeting | | | | |
2820 | Costs | | | | |
2821 | | | | | |
2822 | | | | | |
2823 | Total | 1,888,134 | 1,836,870 | 1,497,186 | 1,381,700 |
2824 | CNRI/Foretec | | | | |
2825 | "Direct" | | | | |
2826 | Expenses | | | | |
2827 | | | | | |
2828 | | | | | |
2829 | CNRI/Foretec | 604,990 | 608,805 | 641,939 | 504,560 |
2830 | Overhead Charge | | | | |
2831 | | | | | |
2832 | CNRI/Foretec | 30,000 | -- | -- | -- |
2833 | "Performance | | | | |
2834 | Bonus" For Staff | | | | |
2835 | | | | | |
2836 | | | | | |
2837 | Total | 2,523,124 | 2,445,675 | 2,139,125 | 1,886,260 |
2838 | CNRI/Foretec | | | | |
2839 | Expenses | | | | |
2840 | | | | | |
2841 | | | | | |
2842 | TOTAL EXPENSES | 3,058,659 | 2,996,556 | 2,753,816 | 2,549,830 |
2843 | (ISOC and CNRI) | | | | |
2844 | | | | | |
2845 | | | | | |
2846 | SURPLUS/DEFICIT | 94,750 | (165,318) | (141,204) | (59,979) |
2847 +------------------+------------+-----------+-----------+-----------+
2849 Notes:
2850 [1] Actual results based on unaudited reports. Source: [IETF-2001]
2851 [2] Actual results based on unaudited reports. Source: [IETF-2002]
2852 [3] Actual results based on unaudited reports. Source: [IETF-2003]
2853 [4] Budgeted. Source: [IETF-2004]
2854 [5] ISOC manages expenditures directly. The revenue line here
2855 represents funds allocated by the ISOC Board of Trustees for the
2856 purpose of IETF support. The figures in this line equal their
2857 corresponding cells for Total ISOC Expenditures.
2858 [6] ICANN does not report expenses broken down by functional area,
2859 nor are the direct and indirect costs associated with the IETF
2860 parameter registries available. We thus value this contribution
2861 as "priceless" for purposes of this analysis.
2863 B.2 Internet Society 2004 Budget Summary
2865 The Internet Society 2004 Budget was approved at a Special
2866 Teleconference Meeting of the Internet Society Board of Trustees
2867 [ISOC-2004].
2869 (US$)
2871 +------------------+------------+-----------+-----------+-----------+
2872 | | Standards | Education | Public | Total |
2873 | | Pillar | Pillar | Policy | |
2874 | | | | Pillar | |
2875 +------------------+------------+-----------+-----------+-----------+
2876 | REVENUE | | | | |
2877 | | | | | |
2878 | Organizational | 1,050,000 | 242,000 | 200,000 | 1,492,000 |
2879 | and Platinum | | | | |
2880 | Membership | | | | |
2881 | | | | | |
2882 | Individual | | | 52,500 | 52,500 |
2883 | Membership | | | | |
2884 | | | | | |
2885 | Conferences | | 145,000 | | 145,000 |
2886 | (INET, NDSS) | | | | |
2887 | | | | | |
2888 | .org Program | 900,000 | 450,000 | 550,000 | 1,900,000 |
2889 | Revenue | | | | |
2890 | | | | | |
2891 | Other | 155,000 | | | 155,000 |
2892 | (Contributions | | | | |
2893 | and Security | | | | |
2894 | Expert | | | | |
2895 | Initiative | | | | |
2896 | | | | | |
2897 | TOTAL REVENUE | 2,105,000 | 837,000 | 802,500 | 3,744,500 |
2898 | | | | | |
2899 | | | | | |
2900 | EXPENSE | | | | |
2901 | | | | | |
2902 | ISOC Salaries | 371,337 | 364,623 | 458,128 | 1,194,088 |
2903 | and Related | | | | |
2904 | Costs | | | | |
2905 | | | | | |
2906 | IETF Staff | 10,000 | | | 10,000 |
2907 | Travel | | | | |
2908 | | | | | |
2909 | RFC Editor | 574,570 | | | 574,570 |
2910 | | | | | |
2911 | IETF and IAB | 89,000 | | | 89,000 |
2912 | Support and | | | | |
2913 | Insurance | | | | |
2914 | | | | | |
2915 | IETF | 709,000 | | | 709,000 |
2916 | Restructuring | | | | |
2917 | Project | | | | |
2918 | | | | | |
2919 | Conference | | 100,000 | | 100,000 |
2920 | Expense | | | | |
2921 | | | | | |
2922 | Professional | 12,500 | 20,000 | 4,000 | 36,500 |
2923 | Services, | | | | |
2924 | Travel, Misc. | | | | |
2925 | | | | | |
2926 | External Costs: | 40,000 | 89,400 | 70,000 | 199,400 |
2927 | .org | | | | |
2928 | | | | | |
2929 | External Costs: | 70,000 | 42,181 | | 112,181 |
2930 | SEINIT & Sida | | | | |
2931 | | | | | |
2932 | | | | | |
2933 | TOTAL DIRECT | 1,876,407 | 616,204 | 532,128 | 3,024,739 |
2934 | EXPENSE | | | | |
2935 | | | | | |
2936 | G&A/GOVERNANCE | 192,026 | 188,555 | 236,908 | 617,489 |
2937 | | | | | |
2938 | TOTAL EXPENSE | 2,068,433 | 804,759 | 769,036 | 3,642,228 |
2939 | | | | | |
2940 | | | | | |
2941 | SURPLUS | 36,567 | 32,241 | 33,464 | 102,272 |
2942 +------------------+------------+-----------+-----------+-----------+
2944 Appendix C. 10-Year Meeting Attendance Summary
2946 +------------+------------+-------------+-------------+-------------+
2947 | IETF | DATE | Location | Host | Attendees |
2948 +------------+------------+-------------+-------------+-------------+
2949 | 60th IETF | 01/08/2004 | San Diego, | -- | 1511 |
2950 | [12] | | CA, USA | | |
2951 | | | | | |
2952 | 59th IETF | 29/02/2004 | Seoul, | -- | 1390 |
2953 | [13] | | South Korea | | |
2954 | | | | | |
2955 | 58th IETF | 09/11/2003 | Minneapolis | -- | 1233 |
2956 | [14] | | , MN, USA | | |
2957 | | | | | |
2958 | 57th IETF | 13/07/2003 | Vienna, | -- | 1304 |
2959 | [15] | | Austria | | |
2960 | | | | | |
2961 | 56th IETF | 16/03/2003 | San | -- | 1679 |
2962 | [16] | | Francisco, | | |
2963 | | | California, | | |
2964 | | | USA | | |
2965 | | | | | |
2966 | 55th IETF | 17/11/2002 | Atlanta, | Nokia | 1570 |
2967 | | | Georgia, | | |
2968 | | | USA | | |
2969 | | | | | |
2970 | 54th IETF | 14/07/2002 | Yokohama, | Fujitsu; | 1885 |
2971 | | | Japan | The WIDE | |
2972 | | | | Project | |
2973 | | | | | |
2974 | 53rd IETF | 17/03/2002 | Minneapolis | Cable & | 1656 |
2975 | | | , | Wireless | |
2976 | | | Minnesota, | | |
2977 | | | USA | | |
2978 | | | | | |
2979 | 52nd IETF | 09/12/2001 | Salt Lake | Novell | 1691 |
2980 | | | City, Utah, | | |
2981 | | | USA | | |
2982 | | | | | |
2983 | 51st IETF | 05/08/2001 | London, | BTexact | 2226 |
2984 | | | England | Technologie | |
2985 | | | | s | |
2986 | | | | | |
2987 | 50th IETF | 18/03/2001 | Minneapolis | Lucent | 1822 |
2988 | | | , MN, USA | Technologie | |
2989 | | | | s | |
2990 | | | | | |
2991 | 49th IETF | 10/12/2000 | San Diego, | Cisco | 2810 |
2992 | | | CA, USA | Systems; | |
2993 | | | | Qualcomm | |
2994 | | | | | |
2995 | 48th IETF | 31/07/2000 | Pittsburgh, | Marconi | 2344 |
2996 | | | PA, USA | | |
2997 | | | | | |
2998 | 47th IETF | 26/03/2000 | Adelaide, | connect.com | 1431 |
2999 | | | Australia | .au | |
3000 | | | | | |
3001 | 46th IETF | 07/11/1999 | Washington, | Nortel | 2379 |
3002 | | | DC, USA | Networks, | |
3003 | | | | Inc | |
3004 | | | | | |
3005 | 45th IETF | 11/07/1999 | Oslo, | Uninett | 1710 |
3006 | | | Norway | | |
3007 | | | | | |
3008 | 44th IETF | 14/03/1999 | Minneapolis | Ascend | 1705 |
3009 | | | , MN, USA | Communicati | |
3010 | | | | ons | |
3011 | | | | | |
3012 | 43rd IETF | 07/12/1998 | Orlando, | Microsoft | 2124 |
3013 | | | FL, USA | Corporation | |
3014 | | | | | |
3015 | 42nd IETF | 24/08/1998 | Chicago, | Motorola | 2106 |
3016 | | | IL, USA | | |
3017 | | | | | |
3018 | 41st IETF | 30/03/1998 | Los | -- | 1775 |
3019 | | | Angeles, | | |
3020 | | | CA, USA | | |
3021 | | | | | |
3022 | 40th IETF | 08/12/1997 | Washington, | Newbridge | 1897 |
3023 | | | DC, USA | Networks, | |
3024 | | | | Inc | |
3025 | | | | | |
3026 | 39th IETF | 11/08/1997 | Munich, | ISOC-German | 1308 |
3027 | | | Germany | y Chapter | |
3028 | | | | | |
3029 | 38th IETF | 07/04/1997 | Memphis, | Federal | 1321 |
3030 | | | Tennessee, | Express | |
3031 | | | USA | | |
3032 | | | | | |
3033 | 37th IETF | 09/12/1996 | San Jose, | Cisco | 1993 |
3034 | | | California, | Systems | |
3035 | | | USA | | |
3036 | | | | | |
3037 | 36th IETF | 24/06/1996 | Montreal, | -- | 1283 |
3038 | | | Quebec, | | |
3039 | | | CANADA | | |
3040 | | | | | |
3041 | 35th IETF | 04/03/1996 | Los | -- | 1038 |
3042 | | | Angeles, | | |
3043 | | | California, | | |
3044 | | | USA | | |
3045 | | | | | |
3046 | 34th IETF | 04/12/1995 | Dallas, | MCI | 1007 |
3047 | | | Texas, USA | | |
3048 | | | | | |
3049 | 33rd IETF | 17/07/1995 | Stockholm, | the Royal | 617 |
3050 | | | Sweden | Institute | |
3051 | | | | of | |
3052 | | | | Technology; | |
3053 | | | | NORDUnet | |
3054 | | | | | |
3055 | 32nd IETF | 03/04/1995 | Danvers, | FTP | 983 |
3056 | | | Massachuset | Software; | |
3057 | | | ts, USA | NEARnet | |
3058 | | | | | |
3059 | 31st IETF | 05/12/1994 | San Jose, | Sun | 1079 |
3060 | | | California, | Microsystem | |
3061 | | | USA | s | |
3062 | | | | | |
3063 | 30th IETF | 25/07/1994 | Toronto, | University | 710 |
3064 | | | Ontario, | of Toronto | |
3065 | | | CANADA | | |
3066 | | | | | |
3067 | 29th IETF | 28/03/1994 | Seattle, | NorthWestNe | 785 |
3068 | | | Washington, | t | |
3069 | | | USA | | |
3070 +------------+------------+-------------+-------------+-------------+
3072 C.1 Analysis of Meeting-Based Expense and Revenue Drivers
3074 +----------------+----------------+----------------+----------------+
3075 | Category | 2001 | 2002 | 2003 |
3076 +----------------+----------------+----------------+----------------+
3077 | Total | 5,739 | 5,111 | 4,216 |
3078 | Attendees | | | |
3079 | | | | |
3080 | Net Meeting | $456 | $446 | $489 |
3081 | Revenue Per | | | |
3082 | Attendee | | | |
3083 | | | | |
3084 | Average Food & | $150 | $138 | $122 |
3085 | Beverage Per | | | |
3086 | Attendee | | | |
3087 | | | | |
3088 | Average Total | $206 | $190 | $193 |
3089 | Direct Meeting | | | |
3090 | Cost Per | | | |
3091 | Attendee [1] | | | |
3092 | | | | |
3093 | Total | $440 | $479 | $507 |
3094 | CNRI/Foretec | | | |
3095 | Secretariat | | | |
3096 | Expenses | | | |
3097 | Divided by | | | |
3098 | Number of | | | |
3099 | Meeting | | | |
3100 | Attendees | | | |
3101 +----------------+----------------+----------------+----------------+
3103 Notes:
3104 [1] Room rental fees are typical for non-U.S. meetings. Average
3105 total direct costs will thus be influenced by the choice of
3106 location of meetings.
3108 Appendix D. Sample Draft Incorporating Documents for a Hypothetical
3109 IETF Foundation
3111 D.1 Sample Draft Articles of Incorporation
3113 This appendix contains standard, pro-forma Articles of Incorporation.
3114 Note well that tax lawyers often make significant alterations to
3115 standard Articles as they consider a 501(c)(3) application. They are
3116 included here merely as a sample for illustrative purposes only.
3118 'Commonwealth of Virginia -- State Corporation Commission'| 'Articles
3119 of Incorporation -- Virginia Nonstock Corporation'| Form SCC819,
3120 07/03 [17]
3121 ------
3123 The undersigned, pursuant to Chapter 10 of Title 13.1 of the Code of
3124 Virginia, [Virginia] state(s) as follows:
3125 1. The name of the corporation is The IETF Foundation.
3126 2. The corporation shall have no members.
3127 3. The Trustees of the corporation shall be elected or appointed as
3128 specified in Article IV (Appendix D.2.5) of the Bylaws.
3129 4. Name and agent:
3130 A. The name of the corporation's initial registered agent is:
3131 XXX
3132 B. The initial registered agent is a domestic or foreign stock
3133 or nonstock corporation, limited liability company, or
3134 registered limited liability partnership authorized to
3135 transact business in Virginia.
3136 5. The initial Trustees are: XXX
3137 6. The incorporators are: XXX
3139 D.2 Sample Draft Bylaws of the IETF Foundation
3141 As with the Sample Draft Articles, the Sample Draft Bylaws included
3142 here are a pro-forma, standard version. Substantial alteration may
3143 be required as legal counsel reviews the specific nature of an
3144 incorporation.
3146 D.2.1 Article I: Organization
3148 The name of the Corporation shall be The IETF Foundation (which shall
3149 hereinafter be referred to as the "Foundation").
3151 D.2.2 Article II: Purpose
3153 *Section 1: Purpose.* The IETF Foundation shall be operated
3154 exclusively for nonprofit educational, charitable, and scientific
3155 purposes, including, without limitation, the purposes stated in the
3156 Foundation's Articles of Incorporation.
3158 *Section 2: Restrictions.* No part of the net earnings of the IETF
3159 Foundation shall inure to the benefit of, or be distributable to,
3160 private persons, except that the Foundation shall be authorized and
3161 empowered to pay reasonable compensation for services rendered, and
3162 to make payments and distributions in furtherance of the purposes set
3163 forth in Article II, Section 1 hereof. Any other provision of these
3164 Bylaws to the contrary notwithstanding, the IETF Foundation shall not
3165 carry on any activities not permitted to be carried on by a
3166 corporation exempt from Federal Income Tax under Section 501(a) and
3167 Section 501(c)(3) of the Code. These Bylaws shall not be altered or
3168 amended in derogation of the provisions of this Section.
3170 D.2.3 Article III: Members
3172 The Foundation shall have no members and no stockholders.
3174 D.2.4 Article IV: Offices
3176 The office of the Foundation shall be as determined from time to time
3177 by the Board of Trustees within or outside of the State of Virginia.
3179 D.2.5 Article V: Board of Trustees
3181 *Section 1: Authority and Responsibilities.* The power, authority,
3182 property, and affairs of the Foundation shall at all times be
3183 exclusively exercised, controlled, and conducted by or under the
3184 authority of the Board of Trustees subject to any limitations set
3185 forth in the Articles of Incorporation and in accordance with the
3186 Virginia Nonstock Corporation Act as it now exists or hereafter may
3187 be amended.
3189 *Section 2: Board of Trustees Composition.* The Board of Trustees
3190 shall consist of seven (7) Trustees.
3192 *Section 3: Types.* There shall be two types of Trustees based on the
3193 reason for their selection: Position-Based Trustees, who are trustees
3194 because they hold some other office (for example IETF Chair) and
3195 Selected Trustees, who are not Position-Based Trustees.
3197 *Section 3: Terms.* The term of office of Position-Based Trustees
3198 shall be co-terminious with the term of the office that qualifies the
3199 individual to be a board member. The term of office of Selected
3200 Trustees shall be three (3) years or until their successors have been
3201 selected and assume office. Selected Trustees may be selected to
3202 serve multiple terms.
3204 *Section 4: Selection of the Board of Trustee*
3205 1. *Selection of Position-Based Trustees.* The Chairs of the IETF
3206 and IAB shall be the two Position-Based Trustees. These
3207 individuals are selected by IETF participants using the
3208 procedures set forth in [RFC3777] or its successor.
3209 2. *Selection of Selected Trustees.* Three Selected Trustees shall
3210 be selected by the IETF nominations process (as defined in
3211 [RFC3777] or its successor) and confirmed by the IESG. Two
3212 Selected Trustees shall be selected by the internet Society using
3213 means of their own choosing.
3214 3. *Resignation.* A Selected Trustee may resign by delivering his
3215 resignation in writing to the Foundation at its principal office
3216 or to the Secretary of the Foundation. Such resignation shall be
3217 effective upon its receipt or upon such date (if any) as is
3218 stated in such resignation, unless otherwise determined by the
3219 Board.
3220 4. *Removal.* A Selected Trustee selected by the IETF nominations
3221 process may be removed from office at any time using the
3222 procedures specified in [RFC3777] or its successor. A Selected
3223 Trustee selected by the Internet Society my be removed by the
3224 Internet Society using means of their own choosing.
3225 5. *Vacancies.* Any vacancy in the Board of Trustees shall be filled
3226 using the procedures set forth above on the composition of the
3227 Board of Trustees. The Trustees shall have and may exercise all
3228 of their powers notwithstanding the existence of one or more
3229 vacancies in their number.
3231 *Section 5: Quorum.* A majority of the Trustees shall constitute a
3232 quorum for the transaction of business. Unless otherwise stated in
3233 these Bylaws, decisions of the Board of Trustees shall be made by the
3234 concurrence of a majority of members of the Board of Trustees present
3235 and voting. If at any meeting there is no quorum present, the Board
3236 must not transact business.
3238 *Section 6: Compensation and Reimbursement.* No member of the Board
3239 of Trustees may receive compensation for his or her services as a
3240 Trustee. A Trustee shall, at their request, be reimbursed for
3241 actual, necessary and reasonable travel and subsistence expenses
3242 incurred by them in performance of their duties.
3244 *Section 7: Meetings.* The Board of Trustees shall meet at least
3245 twice annually.
3246 1. *Annual Meeting.* The Board of Trustees shall hold a public
3247 Annual Meeting at a time and place associated with the first IETF
3248 meeting each year. This Annual meeting shall be open to all IETF
3249 attendees except that the parts of the meeting dealing with
3250 personnel issues may be held in executive session.
3252 2. *Meeting Types, Methods, and Notice.* Meetings of the Board may
3253 be held from time to time at such intervals and at such places as
3254 may be fixed by the Board. Meetings of the Board may be held
3255 only in person or via teleconference. Notice of all regular
3256 meetings of the Board shall be delivered to each Trustee by
3257 e-mail or by postal mail and announced on the IETF-Announce list
3258 at least ten (10) calendar days before the meeting. Special
3259 meetings of the Board may be called for any purpose at any time
3260 by the Chairman of the Board or by any three (3) Trustees.
3261 Notice of any special meeting shall state the purpose of the
3262 meeting. A Trustee may waive notice of a meeting of the Board of
3263 Trustees by submitting a signed, written waiver of notice, either
3264 before or after the meeting. A Trustee's attendance at or
3265 participation in a meeting waives any required notice of the
3266 meeting unless at the start of such meeting or promptly upon
3267 arrival the Trustee objects to holding the meeting or transacting
3268 business at the meeting, and does not thereafter vote for or
3269 assent to action taken at the meeting.
3270 3. *Actions Taken By the Board of Trustees Without Meeting.* Any
3271 action required or permitted to be taken at any meeting of the
3272 Board of Trustees may be taken without a meeting if all Trustees
3273 consent in writing to such action. Such action shall be
3274 evidenced by written consents approving the lack of a meeting,
3275 signed by each Trustee.
3277 *Section 8: Board Committees.* The Trustees may elect or appoint one
3278 or more committees (including but not limited to an Executive
3279 Committee) and may delegate to any such committee or committees any
3280 or all of their powers, provided that any committee to which the
3281 powers of the Trustees are delegated shall consist solely of
3282 Trustees. Committees shall conduct their affairs in the same manner
3283 as is provided in these By Laws for the Trustees. The members of any
3284 committee shall remain in office at the pleasure of the Board of
3285 Trustees.
3287 *Section 9: Trustee Member Conflict of Interest.*
3288 1. As set forth in Section 9(3) below, a Trustee of the IETF
3289 Foundation who has a personal interest in a transaction, as
3290 defined below, may not participate in any discussion of that
3291 transaction by the Trustees of The IETF Foundation and may not
3292 vote to determine whether to authorize, approve, or ratify that
3293 transaction except as specifically described below. For purposes
3294 of these Bylaws, a "personal interest" is defined as any act that
3295 will provide, directly or indirectly, a financial benefit or a
3296 disparate benefit individually to the Trustee, or to a company he
3297 or she is employed by, has a significant financial interest in,
3298 or represents in any fashion. However, policies under
3299 consideration by the Foundation are likely to have an impact on
3300 the business of every Trustee. It is expected that most policy
3301 decisions will have a direct or indirect impact on the Trustee's
3302 company, but such a non-individualized interest does not
3303 constitute a "personal interest" as used in these Bylaws. A
3304 "transaction" with The IETF Foundation for purposes of these
3305 Bylaws is a contract or consultancy in which the Trustee has a
3306 direct or indirect financial benefit, or a policy under
3307 consideration that will have a disparate and unusual impact on a
3308 business with which the Trustee is directly or indirectly
3309 associated.
3310 2. The mere existence of a personal interest by a Trustee of The
3311 IETF Foundation in a transaction with The IETF Foundation shall
3312 not invalidate The IETF Foundation's ability to enter that
3313 transaction so long as the following conditions are met: (i) the
3314 material facts of the personal nature of the transaction with The
3315 IETF Foundation and the Trustee's interest in the transaction
3316 with The IETF Foundation are fully disclosed to the Board of
3317 Trustees of The IETF Foundation, either by the Trustee having a
3318 direct or indirect personal interest in the transaction with The
3319 IETF Foundation, or are brought to the attention of the Board by
3320 a third party; or (ii) the Board of Trustees of The IETF
3321 Foundation, by a vote of the disinterested Trustees of The IETF
3322 Foundation vote to authorize, approve, or ratify a transaction
3323 with The IETF Foundation; or (iii) the transaction with The IETF
3324 Foundation in which the direct or indirect personal interest of
3325 an The IETF Foundation Trustee was disclosed to the Board of
3326 Trustees of The IETF Foundation and was determined by the Board
3327 of Trustees of The IETF Foundation entitled to vote on the matter
3328 is determined by the Board of Trustees voting to be in The IETF
3329 Foundation's interests, notwithstanding the personal interest of
3330 the non-voting Trustee.
3331 3. In determining whether a conflict of interest exists, the Board
3332 of Trustees of The IETF Foundation has the prerogative, upon
3333 review of all facts and circumstances, to make its own
3334 determination of whether a conflict of interest exists and how it
3335 is appropriate to proceed. A Trustee who perceives the
3336 possibility of a conflict of interest for him or herself, or for
3337 another Board member, may raise this issue at any point prior to
3338 a vote on any issue. Any Trustee who perceives a possible
3339 conflict of interest may present justification with respect to
3340 whether or not a conflict of interest exists, but the entire
3341 Board, with the exception of the Trustee having the potential
3342 conflict of interest, shall make the final determination to
3343 proceed in such a matter. If the Board of Trustees finds there
3344 is a conflict of interest, the Trustee with the conflict may be
3345 excluded by the Chair of the Board from that portion of any
3346 meeting where a substantive discussion or decision to engage or
3347 not in such a transaction is made, except that he or she may
3348 provide any information that will assist the Trustees in such a
3349 matter before leaving such a meeting.
3351 *Section 10. Approval of Meeting Minutes.* Minutes of the Board of
3352 the IETF Foundation must be approved by a procedure adopted by the
3353 board and published on the IETF Foundation web site.
3355 D.2.6 Article VI: Officers
3357 *Section 1: Number.* The officers of the IETF Foundation shall
3358 consist of a Chairman of the Board, a Treasurer and a Secretary, and
3359 such other inferior officers as the Board of Trustees may determine.
3361 *Section 2: Election Term of Office and Qualifications.* All officers
3362 shall be elected annually by the vote of a majority of the Board of
3363 Trustees present and voting (excluding abstentions) at the Annual
3364 Meeting. The Treasurer and Secretary need not be members of the
3365 Board. The Chair of the IETF nor the chair of the IAB shall be the
3366 Chairman of the Board of the IETF Foundation.
3368 *Section 3: Resignation.* An officer may resign by delivering his
3369 written resignation to the Foundation at its principal office or to
3370 the Chair or Secretary. Such resignation shall be effective upon
3371 receipt or upon such date (if any) as is stated in such resignation,
3372 unless otherwise determined by the Board.
3374 *Section 4: Removal.* The Board of Trustees may remove any officer
3375 with or without cause by a vote of a majority of the entire number of
3376 Trustees then in office, at a meeting of the Board of Trustees called
3377 for that purpose. An officer may be removed for cause only if notice
3378 of such action shall have been given to all of the Trustees prior to
3379 the meeting at which such action is to be taken and if the officer so
3380 to be removed shall have been given reasonable notice and opportunity
3381 to be heard by the Board of Trustees.
3383 *Section 5: Vacancies.* In case any elected officer position of the
3384 IETF Foundation becomes vacant, the majority of the Trustees in
3385 office, although less than a quorum, may elect an officer to fill
3386 such vacancy at the next meeting of the Board of Trustees, and the
3387 officer so elected shall hold office and serve until the next Annual
3388 Meeting.
3390 *Section 6: Chairman of the Board.* The Chairman of the Board shall,
3391 when present, preside at all meetings of the Board of Trustees of
3392 IETF Foundation. If the Chairman is not available to preside over a
3393 meeting, the majority of the Trustees present shall select another
3394 Trustee to preside at that meeting only.
3396 *Section 7: Treasurer.* The Treasurer shall have the custody of all
3397 funds, property, and securities of the IETF Foundation, subject to
3398 such regulations as may be imposed by the Board of Trustees. He or
3399 she may be required to give bond for the faithful performance of his
3400 or her duties, in such sum and with such sureties as the Board of
3401 Trustees may require or as required by law, whichever is greater.
3402 When necessary or proper, he or she may endorse on behalf of the IETF
3403 Foundation for collection, checks, notes and other obligations, and
3404 shall deposit same to the credit of the IETF Foundation at such bank
3405 or banks or depository as the Board of Trustees may designate. He or
3406 she shall make or cause to be made such payments as may be necessary
3407 or proper to be made on behalf of the IETF Foundation. He or she
3408 shall enter or cause to be entered regularly on the books of the IETF
3409 Foundation to be kept by him or her for that purpose, full and
3410 accurate account of all monies and obligations received and paid or
3411 incurred by him or her for or on account of the IETF Foundation, and
3412 shall exhibit such books at all reasonable times to any Trustee on
3413 application at the offices of the IETF Foundation incident to the
3414 Office of Treasurer, subject to the control of the Board of Trustees.
3415 Certain duties of the Treasurer as may be specified by the Board of
3416 Trustees may be delegated by the Treasurer.
3418 *Section 8: Secretary.* The Secretary shall have charge of such
3419 books, records, documents, and papers as the Board of Trustees may
3420 determine, and shall have custody of the corporate seal. The
3421 Secretary shall keep, or cause to be kept the minutes of all meetings
3422 of the Board of Trustees. The Secretary may sign, with the Chairman,
3423 in the name and on behalf of the IETF Foundation, any contracts or
3424 agreements, and he or she may affix the corporate seal of the IETF
3425 Foundation. He or she, in general, performs all the duties incident
3426 to the Office of Secretary, subject to the supervision and control of
3427 the Board of Trustees, and shall do and perform such other duties as
3428 may be assigned to him or her by the Board of Trustees or the
3429 Chairman of the Board of Trustees. Certain duties of the Secretary
3430 as may be specified by the Board of Trustees may be delegated by the
3431 Secretary.
3433 *Section 9: Other Powers and Duties.* Each officer shall have in
3434 addition to the duties and powers specifically set forth in these By
3435 Laws, such duties and powers as are customarily incident to his
3436 office, and such duties and powers as the Trustees may from time to
3437 time designate.
3439 D.2.7 Article VII: Amendments
3441 *Section 1: By Laws.* These By Laws may be amended by an affirmative
3442 vote of a majority of the Trustees then in office (excluding
3443 abstentions) at a regular meeting of the board or a meeting of the
3444 board called for that purpose as long as the proposed changes are
3445 made available to all trustees and posted to the IETF Announce list
3446 at least 30 days before any such meeting.
3448 *Section 2: Articles of Incorporation.* The Articles of Incorporation
3449 of the IETF Foundation may amended by an affirmative vote of
3450 two-thirds vote of the Board of Trustees then in office at a regular
3451 meeting of the board or a meeting of the board called for that
3452 purpose as long as the proposed changes are made available to all
3453 trustees and posted to the IETF Announce list at least 30 days before
3454 any such meeting.
3456 D.2.8 Article VIII: Dissolution
3458 Upon the dissolution of the IETF Foundation, the IETF Foundation
3459 shall, after paying or making provisions for the payment of all of
3460 the liabilities of the Foundation, dispose of all of the assets of
3461 the IETF Foundation exclusively for the exempt purposes of the IETF
3462 Foundation in such manner or to such organization or organizations
3463 operated exclusively for social welfare or charitable purposes. Any
3464 such assets not so disposed of shall be disposed of by a court of
3465 competent jurisdiction of the county in which the principal office of
3466 the organization is then located, exclusively for such purposes. In
3467 the event of a sale or dissolution of the corporation, the surplus
3468 funds of the corporation shall not inure to the benefit of, or be
3469 distributable to, its Trustees, officers, or other private persons.
3471 D.2.9 Article IX: Miscellaneous Provisions
3473 *Section 1: Fiscal Year.* The fiscal year of the IETF Foundation
3474 shall be from January 1 to December 31 of each year.
3476 *Section 2: Execution of Instruments.* All checks, deeds, leases,
3477 transfers, contracts, bonds, notes and other obligations authorized
3478 to be executed by an officer of the Foundation in its behalf shall be
3479 signed by the Chairman of the Board or the Treasurer, or as the
3480 Trustees otherwise determine. A certificate by the Secretary as to
3481 any action taken by the Board of Trustees shall as to all persons who
3482 rely thereon in good faith be conclusive evidence of such action.
3484 *Section 3: Severability.* Any determination that any provision of
3485 these By-Laws is for any reason inapplicable, illegal or ineffective
3486 shall not affect or invalidate any other provision of these By-Laws.
3488 *Section 4: Articles of Incorporation.* All references in these By
3489 Laws to the Articles of Incorporation shall be deemed to refer to the
3490 Articles of Incorporation of the IETF Foundation, as amended and in
3491 effect from time to time.
3493 *Section 5: Gender.* Whenever used herein, the singular number shall
3494 include the plural, the plural shall include the singular, and the
3495 use of any gender shall include all genders.
3497 *Section 6: Successor Provisions.* All references herein: (1) to the
3498 Internal Revenue Code shall be deemed to refer to the Internal
3499 Revenue Code of 1986, as now in force or hereafter amended; (2) to
3500 the Code of the State of Virginia, or any Chapter thereof, shall be
3501 deemed to refer to such Code or Chapter as now in force or hereafter
3502 amended; (3) the particular sections of the Internal Revenue Code or
3503 such Code shall be deemed to refer to similar or successor provisions
3504 hereafter adopted; and (4) to the Request for Comment Series shall be
3505 deemed to refer to the Request for Comment Series as they are now in
3506 force or hereafter amended.
3508 Appendix E. Sample Draft Call for Applications -- IETF Administrative
3509 Director
3511 The IETF Administrative Entity is seeking a highly capable individual
3512 to serve as Administrative Director. You will report to the IETF
3513 Chair and be accountable to IETF community. This is a highly visible
3514 and very demanding job. You will be expected to:
3515 o Serve as the day-to-day chief operating officer of the IETF,
3516 managing a number of contractors and working with a number of
3517 volunteers.
3518 o Provide primary support for budgeting and financial reporting
3519 processes.
3520 o Serve as the primary staff resource for the governing body of the
3521 administrative entity for the IETF.
3522 o Work with your contractors and members of the IETF community to
3523 provide adequate support and planning for 3 IETF meetings
3524 annually, and for frequent meetings and teleconferences of the
3525 IAB, IESG, and other bodies that support the IETF.
3526 o Work with our liaison organizations, such as the RFC Editor and
3527 the IANA.
3528 o Coordinate the standards-making support process, in particular the
3529 periodic meetings of the IESG.
3531 The following characteristics are necessary for this job:
3532 o This job is public service. You should be able to work
3533 successfully with large numbers of people. This requires a high
3534 clock rate, a large stack, and the ability to listen carefully.
3535 o This is an operations job. IETF meetings are large and complex,
3536 and the day-to-day activities of the standards-making process is
3537 demanding. You should be adept at getting real results and
3538 helping large groups work together towards common goals and
3539 deadlines.
3540 o This job requires a financially astute individual. The IETF is a
3541 $2-$3 million/year operation. IETF funds are tight and we expect
3542 you to take leadership in establishing our budgetary procedures,
3543 our procurement standards, and understanding our revenue sources.
3545 In-depth familiarity with the IETF prior to assuming this position is
3546 not required, but you must be able to quickly get up to speed and
3547 learn the unique culture and requirements of the organization.
3548 Likewise, long-term technical experience is not required, but you
3549 must be a quick learner and adept at using the Internet effectively.
3551 You may work out of a home office as a telecommuter, or use the
3552 Internet Society facilities in Virginia. In either case, you should
3553 be prepared to travel to Virginia, IETF meetings, and the locations
3554 where the IETF has contractors.
3556 Applicants should forward a resume, references, and any other
3557 relevant materials, with a cover letter explaining why they feel they
3558 are the right person for this position to:
3559 URL
3561 Applications are due no later than XXX, however the IETF
3562 Administrative Entity reserves the right to make a decision prior to
3563 this date or to extend this date in its sole discretion.
3564 Applications will be reviewed by an evaluation committee consisting
3565 of members of the IAB, IESG, and the community, and a decision shall
3566 be made by the Chairs of the IETF and the IAB with the advice and
3567 consent of the IESG and the IAB.
3569 The list of applicants will not be posted publicly, but will be
3570 reviewed in confidence by members of the evaluation committee, the
3571 IAB, and the IESG.
3573 Appendix F. Sample Draft Request for Proposals
3575 F.1 Introduction
3577 The IETF Administrative Entity is soliciting proposals for the
3578 provision of computing and networking requirements, as detailed in
3579 this Request for Proposals ("Proposals"). Proposals from any
3580 individual person or persons or commercial or non-commercial vendor
3581 ("Vendor") are welcome.
3583 Proposals must be received in written electronic form no later than
3584 [date]. Extensions may be granted solely in the discretion of the
3585 IETF Administrative Entity. Each Proposal, together with all
3586 supporting documentation, should be delivered to the following
3587 address:
3589 [URI/ADDRESS]
3591 Any inquiries regarding this Request must be submitted in written
3592 electronic form to the address listed above. Other than such
3593 inquiries, vendors are prohibited from contacting any person or
3594 institution involved in the selection process concerning this
3595 Request.
3597 Each Proposal must specifically address each of the selection
3598 criteria listed below in a format corresponding to this Request.
3599 Each Proposal should also be accompanied by any technical or product
3600 literature that the Vendor wishes the IETF Administrative Entity to
3601 consider. If additional information is required by the IETF
3602 Administrative Entity to make a determination, such information may
3603 be requested, and shall be submitted in writing in the manner set
3604 forth above. Information other than the written Proposal and any
3605 information submitted in response to a request by the IETF
3606 Administrative Entity will not be considered by the IETF
3607 Administrative Entity.
3609 The IETF Administrative Entity reserves the right to cancel this
3610 Request, in whole or in part, at any time. The IETF Administrative
3611 Entity may reject any or all Proposals received in response to this
3612 Request in its sole discretion. The IETF Administrative Entity makes
3613 no guarantee or commitment to purchase, license or procure any goods
3614 or services resulting from this Request.
3616 Any Proposal which is selected by the IETF Administrative Entity
3617 shall be subject to execution of a binding agreement between the IETF
3618 Administrative Entity and the Vendor, which agreement shall be
3619 prepared by the IETF Administrative Entity and shall reflect the
3620 requirements outlined below and any additional provisions that are
3621 agreed upon in discussions between the IETF Administrative Entity and
3622 the Vendor. Selection may be conditioned upon acceptance of specific
3623 contractual terms and conditions, which may be provided to the Vendor
3624 during the selection process.
3626 Each Vendor is responsible for its own costs and expenses involved in
3627 preparing and submitting its Proposal and any supplemental
3628 information requested by the IETF Administrative Entity. The IETF
3629 Administrative Entity shall not reimburse any such costs or expenses.
3631 All Proposals submitted in accordance with this Request will be
3632 reviewed by a panel of experts drawn from the IETF community. A list
3633 of reviewers will be made available. The IETF Administrative Entity
3634 will notify Vendors of their selection following receipt and
3635 consideration of all Proposals. The IETF Administrative Entity will
3636 attempt to make its selection(s) by [date], but shall have full
3637 discretion to make a decision earlier or later than this date.
3639 F.2 General Provisions
3641 The following provisions apply to all bidders:
3642 1. A response may be submitted for one or more of the 6 listed
3643 support requirements. If response addresses more than one of the
3644 listed support requirements, the proposal should be written to
3645 clearly separate costs by area. The IETF Administrative Entity
3646 reserves the right to accept only a partial proposal.
3647 2. Key Person Principle: Each requirement requires the designation
3648 of one individual as the "Key Person" in your response. That
3649 person will be the individual accountable to the IETF. The IETF
3650 Administrative Entity will require a binding key personnel clause
3651 in the contract. Any change in the Key Person will require prior
3652 approval. The IETF Administrative Entity will also require a
3653 written process that describes procedures for backing up the key
3654 person when that person is not available. The IETF
3655 Administrative Entity will also require that the bidder obtain
3656 and maintain key person insurance for dealing with the
3657 possibility that the designated key person becomes unavailable.
3658 3. The IETF Administrative Entity encourages zero-cost or zero-cost
3659 plus materials bids, but will insist on a binding agreement.
3660 4. The IETF Administrative Entity encourages bids from individuals
3661 as well as public and private institutions as long as the above
3662 conditions are met. You should submit a detailed work history of
3663 each individual, personal references, and a detailed description
3664 of any sub-contractual arrangements you have put in place to
3665 assist you.
3666 5. Appropriate insurance and other mechanisms to minimize the
3667 liability of the IETF Administrative Entity should be discussed
3668 in your proposal.
3670 F.3 Requirement 1: Core Network Infrastructure
3672 [Ed. This section will contain service level specifications. E.g.,
3673 core bandwidth requirements, CPU capacity, disk space, and other
3674 variables. It will also contain core specifications, such as
3675 routing, DNS, and other services.]
3677 F.4 Requirement 2: Systems Administration Services
3679 [Ed. This section will contain the description for the Systems
3680 Administration function, including such tasks as keeping key software
3681 subsystems such as Apache installed and up-to-date, support for
3682 users, operating system upgrades, and other similar tasks.]
3684 F.5 Requirement 3: Postmaster of the IETF Administrative Entity
3686 The Postmaster of the IETF Administrative Entity is responsible for
3687 the functioning and archiving of numerous mailing lists maintained by
3688 the IETF and for archiving specific IETF-related mailing lists
3689 maintained by others. Note that the archives of most IETF mailing
3690 lists are public and the bidder must describe how such archives will
3691 be accessed by the public.
3693 The core mailing is described in [RFC3005], and a policy with regards
3694 to posting rights may be found in [RFC3683]. You will find
3695 additional information on IETF mailing lists at:
3696
3698 In addition, the IETF maintains several dozen members-only lists in
3699 support of bodies such as the IAB, the IESG, and certain IRTF task
3700 forces (see [RFC2014], [RFC2850], and [RFC3710] for more details on
3701 these bodies). IETF administrators and chairs of various groups
3702 typically will form ad hoc lists which they administer for various
3703 tasks.
3705 Familiarity and expertise in administering high-volume lists and in
3706 maintaining large numbers of archived lists is necessary. The
3707 ability to provide administrative facilities that allow the IETF to
3708 delegate authority for moderation and creation of lists is also
3709 necessary. Finally, you should be experienced in the very latest
3710 spam fighting technologies.
3712 You may propose to provide service in one of two ways:
3713 o Move the IETF mail handling onto an existing well-provisioned
3714 infrastructure that you are responsible for.
3715 o Provide mail services on machines that are maintained by the IETF.
3717 Your bid should clearly explain what tools you will use, the types of
3718 interfaces you will provide to list maintainers and participants, and
3719 you would handle issues such as spam. You should also be very clear
3720 in your proposal about your understanding of the role and duties of
3721 the postmaster.
3723 F.6 Requirement 4: Webmaster of the IETF Administrative Entity
3725 This task has the responsibility for the look and feel of the IETF
3726 network presence, particularly the web site. A series of support
3727 contracts will be available to help support this function.
3729 In addition, this task has responsibility to provide overall support,
3730 in cooperation with the sysadmin and other contractors, to a variety
3731 of working groups, directorates, and other activities that require a
3732 workspace.
3734 Your proposal must demonstrate that you are experienced at producing
3735 highly standards-conformant and functional network presences and
3736 supporting a large and diverse community of users. This is a highly
3737 hands-on task.
3739 F.7 Requirement 5: Meetings
3741 We are looking for creative proposals from experienced professionals
3742 to organize and support the meetings of the IETF.
3744 You will work with the Administrative Director of the IETF and the
3745 IETF leadership to organize the three annual meetings of the IETF.
3746 Based on current practice, you should expect 1-2 of those meetings to
3747 be in the United States and 1-2 of those meetings to be in other
3748 countries, though this may change based on the requirements of the
3749 IETF. We expect approximately 1500 attendees per meeting, though in
3750 the past this number has approached 3,000 based on the location of
3751 the meeting and the state of the economy.
3753 You should have very strong experience in meeting planning,
3754 particularly working meetings with large numbers of participants.
3755 You should be intimately familiar with the details of booking
3756 appropriate venues, working with hotel and conference center staff,
3757 and providing clear and concise communications with meeting
3758 attendees.
3760 Your proposal should detail the mechanisms you would use to provide a
3761 simple registration and payment procedure for attendees. You will be
3762 able to draw on webmaster and sysadmin support for the IETF, for
3763 example, if you would like to provide a secure payment mechanism on
3764 the IETF web site. Your proposal should also detail how you will
3765 provide additional resources on-site (e.g., staffing a registration
3766 desk and other requirements that require additional people).
3768 As part of this function, you will work with Local Hosts (when
3769 available), who provide a sophisticated network infrastructure to
3770 support the meeting, as well as a team of volunteers who provide
3771 additional terminal room support, real-time audio and video streaming
3772 from the meeting and other functions.
3774 F.8 Requirement 6: Clerk of the IETF Administrative Entity
3776 This requirement is for general high-level administrative support for
3777 the day-to-day functioning of the IETF. You will work with the
3778 Administrative Director of the IETF to help make the organization
3779 function smoothly on a day-to-day basis.
3781 The tasks that are encompassed in this function include:
3782 o Supporting the working group charter process, which includes
3783 processing the initial charter, rechartering, milestone
3784 management, and closing of the working group.
3785 o Publication of Internet-Drafts. It is assumed that current
3786 efforts to automate the submission process will be successful,
3787 alleviating much of the manual effort that this function currently
3788 has.
3789 o Document tracking, including a ticket-system-based response to
3790 document and working group management problems, announcements of
3791 last calls, and a variety of other functions.
3792 o Managing IESG meetings, including scheduling, creation of the
3793 agenda, and collecting the minutes, as well as the creation and
3794 long-term archiving of IETF meeting proceedings.
3795 o Handling the Intellectual Property Rights disclosure process (a
3796 process which is presently undergoing automation).
3797 o Publication of official actions, such as document approvals,
3798 including communication of such status to groups such as the RFC
3799 Editor.
3800 o Registration and publication of liaison statements from other
3801 standards bodies and publication of liaison statements, responses
3802 and other communications by the IETF to Standards Development
3803 Organizations (SDOs).
3804 o Support of the Nominating Committee.
3805 o Assisting the Meeting Planners in crafting an appropriate agenda
3806 for the IETF meetings, a complex task that requires a fairly
3807 detailed knowledge of the IETF operation.
3809 [Ed. More detail to be filled in here by a transition team.]
3811 F.9 Selection Criteria and Evaluation Process
3813 All proposals will be evaluated using a process that consists of the
3814 following steps:
3815 1. An evaluation committee will be formed by the IETF and IAB
3816 Chairs, and will include the Administrative Director of the IETF
3817 Administrative Entity.
3818 2. The evaluation committee will perform an initial evaluation of
3819 submitted responses.
3820 3. A dialogue will be started with selected responses.
3821 4. The IETF will decide on the initial best candidate.
3822 5. The A further dialogue will ensue with that candidate.
3823 6. A contract may be signed or the discussion may continue with
3824 other candidates.
3826 The IETF Administrative Entity will consider price, experience,
3827 technical smarts, and a variety of other factors. Note well that the
3828 IETF Administrative Entity will not decide on price alone. Overall
3829 benefit to the IETF community will be the prime consideration.
3831 Index
3833 F
3834 functions 6, 6, 10, 11, 13, 16, 17
3836 M
3837 mechanisms 34, 34, 34, 34, 34, 34, 34, 34
3839 O
3840 opinions 16, 23
3841 options 1, 7, 9, 22, 22, 24, 27, 38
3843 P
3844 pillars 6, 6, 6
3846 R
3847 recommendations 8, 20, 21, 21, 28, 28, 37
3849 S
3850 strategies 22, 22, 22
3852 Intellectual Property Statement
3854 The IETF takes no position regarding the validity or scope of any
3855 Intellectual Property Rights or other rights that might be claimed to
3856 pertain to the implementation or use of the technology described in
3857 this document or the extent to which any license under such rights
3858 might or might not be available; nor does it represent that it has
3859 made any independent effort to identify any such rights. Information
3860 on the procedures with respect to rights in RFC documents can be
3861 found in BCP 78 and BCP 79.
3863 Copies of IPR disclosures made to the IETF Secretariat and any
3864 assurances of licenses to be made available, or the result of an
3865 attempt made to obtain a general license or permission for the use of
3866 such proprietary rights by implementers or users of this
3867 specification can be obtained from the IETF on-line IPR repository at
3868 http://www.ietf.org/ipr.
3870 The IETF invites any interested party to bring to its attention any
3871 copyrights, patents or patent applications, or other proprietary
3872 rights that may cover technology that may be required to implement
3873 this standard. Please address the information to the IETF at
3874 ietf-ipr@ietf.org.
3876 Disclaimer of Validity
3878 This document and the information contained herein are provided on an
3879 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
3880 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
3881 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
3882 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
3883 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
3884 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
3886 Copyright Statement
3888 Copyright (C) The Internet Society (2004). This document is subject
3889 to the rights, licenses and restrictions contained in BCP 78, and
3890 except as set forth therein, the authors retain all their rights.
3892 Acknowledgment
3894 Funding for the RFC Editor function is currently provided by the
3895 Internet Society.