Hello, IETF community.
Attached is the document we promised you in San Diego - a report from
our consultant, Carl Malamud, which lays out a series of options and
recommendations for moving forward with the IETF administrative
restructuring process, according to the recommendations laid out
in RFC3716 (the Advisory Committee report). It has been submitted
to the Internet Drafts repository and should be showing up there
shortly.
Some important things to note:
THIS IS NOT A DOCUMENT TO BE READ IN ISOLATION.
Minimally, reviewing the Advisory Committee report (RFC3716) is
necessary to understand the context of the proposals laid out in
this draft.
THIS IS NOT YET AN IETF DECISION.
That will be taken later, based on your input and IETF rough consensus.
THIS IS NOT THE IESG/IAB's RECOMMENDATION.
Our recommendation will come later, based on your input and the
evolution of our thinking.
THIS IS NOT AN ISOC POSITION.
The document describes potential relationships of the IETF
administrative activity and ISOC. However, the document is written
as a proposal for IETF discussion -- the ISOC Board has not been asked
to formulate a position on supporting one or any of these proposals; we
need to have that discussion as it becomes clearer what the IETF wants
in its future.
This IS, however, the culmination of many, many hours of information
gathering and a near-infinite number of conversations by Carl Malamud,
attempting to give the best basis on which the IETF could make a
decision that he could within the timeframe given.
We encourage all interested IETF participants to read the report most
carefully, and give feedback on it - on the IETF list for public
discussion, directly to Carl or the IETF and IAB chairs if you want to
make off-list comments.
FURTHER STEPS
The next steps in this process depend on the community feedback and
whether we can gauge a consensus of the IETF on this mailing list. What
we think is reasonable so far is:
- Have a public discussion on the IETF list on the options presented in
the draft
- By early September, the IESG and IAB will attempt to distill a set of
recommendations that we think capture a reasonable consensus of the
community, and publish this as an internet-draft, which will be revised
over the next month, possibly several times, based on further
discussions
- By late September, we emit a Last Call on this set of recommendations,
if we deem that we have a reasonable consensus for the proposals
- By late October, if the IETF community still shows consensus, we will
declare that we have a decision, and will start executing based on that
decision.
In order to be able to move rapidly when we go into the "execution"
phase, we may initiate some activities of a "fact-finding" nature - such
as investigating possible suppliers of services and candidates for the
positions we envisage filling - before that, but irrevocable decisions
will await IETF consensus.
Please read the attachment - please comment - please THINK.
While this in itself should not change the IETF standards process at
all, support functions are important to the IETF.
We need to take the time to get this one right.
Leslie and Harald.
--
-------------------------------------------------------------------
"Reality:
Yours to discover."
-- ThinkingCat
Leslie Daigle
leslie@xxxxxxxxxxxxxxx
-------------------------------------------------------------------
Network Working Group C. Malamud, Ed.
Internet-Draft Memory Palace Press
Expires: February 23, 2005 August 25, 2004
IETF Administrative Support Functions
draft-malamud-consultant-report-00
Status of this Memo
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 become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 23, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This Internet-Draft discusses the restructuring of administrative
support functions for the IETF. The draft begins with a discussion
of prior steps in the process that led up to this report and
discusses the process going forward. The draft then examines the
current functioning of administrative support functions, analyzes
options for restructuring operational functions, and analyzes options
available to provide an institutional framework for such support.
Malamud Expires February 23, 2005 [Page 1]
Internet-Draft Administrative Support Analysis August 2004
The provision of such administrative support functions is limited in
scope with responsibility only for the administrative, fiscal, and
legal infrastructure needed to support the IETF community. In
particular, issues such as defining and managing the standards-making
process and the governance of that process are explicitly out of
scope for this restructuring.
This Internet-Draft is an independent consultant's report and should
not be regarded as a consensus view or a policy statement. The
report contains only the author's views.
Current Status--YOU MUST READ THIS SECTION
This is a FIRST DRAFT and DOES NOT represent a position or a
consensus. It should be regarded as a starting point for community
discussion, followed by eventual decision making by the leadership
based on a community consensus.
In particular, the key word "we" in this document is to be
interpreted as meaning "I, the author". This document does not
represent a consensus, policies, or opinions that are to be
attributed to anything but the personal views of the author.
Intended Status and Mailing List
This document is intended for publication as an Internet-Draft and is
expected to undergo numerous revisions. It is intended that this
document be submitted for publication as an Informational RFC.
The forum for discussion of this draft is the IETF Discussion list
(ietf@xxxxxxxx). The IETF Discussion List is defined in [RFC3005]
and further defined in [RFC3184] and [RFC3683].
Malamud Expires February 23, 2005 [Page 2]
Internet-Draft Administrative Support Analysis August 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Goals and Non-Goals . . . . . . . . . . . . . . . . . . . 5
1.1.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.2 IETF Standards Process Out of Scope . . . . . . . . . 5
1.1.3 ISOC Role in Standards Process Out of Scope . . . . . 6
1.2 Previous Steps in This Process . . . . . . . . . . . . . . 7
1.3 Decision Process . . . . . . . . . . . . . . . . . . . . . 7
1.4 Criteria for Judging an Administrative Restructuring . . . 8
1.5 Methodology . . . . . . . . . . . . . . . . . . . . . . . 8
2. Analysis of Current Administrative Framework . . . . . . . . . 10
2.1 Providers and Functions . . . . . . . . . . . . . . . . . 10
2.2 Function 1: Administration . . . . . . . . . . . . . . . . 11
2.3 Function 2: Meetings . . . . . . . . . . . . . . . . . . . 13
2.4 Function 3: Core Information Technology . . . . . . . . . 16
2.5 Function 4: Document and Information Flow . . . . . . . . 17
3. Recommendations for Restructuring the Administrative
Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1 Recommendation 1: Hire An Administrative Director . . . . 20
3.2 Recommendation 2: Establish Contracts for Core Services . 21
3.2.1 Details of Potential RFP Components . . . . . . . . . 24
3.3 Recommendation 3: Provide Timely and Uniform Financial
Reporting . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 Recommendation 4: More Focus on Archives . . . . . . . . . 28
4. Options for an Institutional Basis for Administrative
Activities . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1 Discussion of Organizational Form and Legal Domicile . . . 29
4.2 Scenario A: ISOC Operating Unit . . . . . . . . . . . . . 30
4.2.1 Division of the Internet Society . . . . . . . . . . . 30
4.2.2 Intended benefits . . . . . . . . . . . . . . . . . . 31
4.2.3 Additional Considerations . . . . . . . . . . . . . . 31
4.3 Scenario B: More Formalized ISOC Operating Unit . . . . . 32
4.4 Scenario C: Well-Defined Entity With Close Ties to ISOC . 34
4.4.1 How Scenario C Might Work In Practice . . . . . . . . 34
4.5 Scenario D: Autonomous Entity . . . . . . . . . . . . . . 40
5. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.1 Short-Term . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2 Long-Term . . . . . . . . . . . . . . . . . . . . . . . . 41
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
7. Security Considerations . . . . . . . . . . . . . . . . . . . 44
8. Acknowledgment of CNRI Contribution to the IETF Community . . 45
9. Acknowledgment of Contributions and Reviews . . . . . . . . . 46
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 47
10.2 Informative References . . . . . . . . . . . . . . . . . . . 48
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 52
A. Consulting Contract . . . . . . . . . . . . . . . . . . . . . 53
Malamud Expires February 23, 2005 [Page 3]
Internet-Draft Administrative Support Analysis August 2004
B. IETF Financial Information . . . . . . . . . . . . . . . . . . 57
B.1 Consolidated 3-Year Historical Income Statement . . . . . 57
B.2 Internet Society 2004 Budget Summary . . . . . . . . . . . 59
C. 10-Year Meeting Attendance Summary . . . . . . . . . . . . . . 62
C.1 Analysis of Meeting-Based Expense and Revenue Drivers . . 64
D. Sample Draft Incorporating Documents for a Hypothetical
IETF Foundation . . . . . . . . . . . . . . . . . . . . . . . 66
D.1 Sample Draft Articles of Incorporation . . . . . . . . . . 66
D.2 Sample Draft Bylaws of the IETF Foundation . . . . . . . . 66
D.2.1 Article I: Organization . . . . . . . . . . . . . . . 66
D.2.2 Article II: Purpose . . . . . . . . . . . . . . . . . 66
D.2.3 Article III: Members . . . . . . . . . . . . . . . . . 67
D.2.4 Article IV: Offices . . . . . . . . . . . . . . . . . 67
D.2.5 Article V: Board of Trustees . . . . . . . . . . . . . 67
D.2.6 Article VI: Officers . . . . . . . . . . . . . . . . . 71
D.2.7 Article VII: Amendments . . . . . . . . . . . . . . . 72
D.2.8 Article VIII: Dissolution . . . . . . . . . . . . . . 73
D.2.9 Article IX: Miscellaneous Provisions . . . . . . . . . 73
E. Sample Draft Call for Applications -- IETF Administrative
Director . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
F. Sample Draft Request for Proposals . . . . . . . . . . . . . . 77
F.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 77
F.2 General Provisions . . . . . . . . . . . . . . . . . . . . 78
F.3 Requirement 1: Meetings . . . . . . . . . . . . . . . . . 79
F.4 Requirement 2: Systems and Systems Administration . . . . 79
F.4.1 Core Network Infrastructure . . . . . . . . . . . . . 79
F.4.2 Systems Administration Services . . . . . . . . . . . 80
F.5 Requirement 3: Postmaster of the IETF Administrative
Entity . . . . . . . . . . . . . . . . . . . . . . . . . . 80
F.6 Requirement 4: Clerk of the IETF Administrative Entity . . 81
F.7 Requirement 5: Webmaster of the IETF Administrative
Entity . . . . . . . . . . . . . . . . . . . . . . . . . . 81
F.8 Selection Criteria and Evaluation Process . . . . . . . . 81
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Intellectual Property and Copyright Statements . . . . . . . . 84
Malamud Expires February 23, 2005 [Page 4]
Internet-Draft Administrative Support Analysis August 2004
1. Introduction
1.1 Goals and Non-Goals
1.1.1 Goals
Any plan for restructuring the administrative support functions of
the IETF and for establishing an institutional foundation for those
administrative functions must meet three goals:
1. The IETF process must continue to work. The smooth and stable
operation of the IETF is paramount. Any changes that are made
should be made with the goal of making that process work better.
This means that the continuation of the current operation, the
transition, and the future steady-state must all be carefully
thought out and executed.
2. The administrative, fiscal, and legal processes--including those
that effect this restructuring--must be transparent to the IETF
community. Any potential IETF administrative support
organization must be accountable to the community. Both the
transition and the future steady state will require the support
of the community, which requires that we observe the IETF
processes for decision making and that all necessary information
for making those decisions be made publicly available.
Transparency of financial transactions and in the decision making
process are of particular importance.
3. Any organization that provides administrative support functions
for the IETF must be subservient to and support the existing IETF
structures and decision-making processes.
1.1.2 IETF Standards Process Out of Scope
This restructuring exercise is limited in scope to IETF
administrative functions. In particular, it does not cover areas
including (but not limited to) the following:
1. The IETF technical standards-making process.
2. Selection of the IETF leadership and operation of the nominating
committee.
3. Any other topics already covered in our existing procedure Best
Current Practices documents unless called out specifically here.
As will be seen in subsequent sections, we explicitly reference our
existing purpose, governance, process, and core values as they now
exist and as they may be changed in the future. A new institutional
home for the IETF administrative functions will not supplant the IETF
technical processes, it will support them.
Malamud Expires February 23, 2005 [Page 5]
Internet-Draft Administrative Support Analysis August 2004
1.1.3 ISOC Role in Standards Process Out of Scope
The Internet Society and the IETF both have the good of the Internet
as a primary mission goal. The Internet Society has a broader
mandate than the IETF. Those mandates are organized as the "Pillars"
of the Internet Society, and include the following activities:
o Pillar 1: Education & Training
o Pillar 2: Public Policy
o Pillar 3: Standards & Protocols
In support of these pillars, the Internet Society conducts global
conferences including INET and NDSS, and conducts or participates in
regional meetings either directly or through its chapters.
The IETF is focused exclusively on the standards and protocol
activity. The Internet Society plays a complementary and vital role
with an active education and policy effort that allows the IETF to
maintain a focus on protocols and standards.
The Internet Society is an international membership organization,
open to all organizations and individuals. ISOC supports the IETF
and IAB in a number of ways (as detailed below), historically raising
funds through Organization and Individual member dues. ISOC conducts
and/or participates in global conferences including INET and NDSS,
network training workshops for developing countries, topical
tutorials, and various policy forums. ISOC participates in many
regional meetings either directly or through its chapters.
While a variety of administrative functions provided by the Internet
Society will be considered in this document, it is important to state
at the outset that the Internet Society currently provides two
important functions to the IETF:
1. *Administration Functions.* As discussed in subsequent sections,
the Internet Society provides administrative and financial
functions, managing the contract with the RFC Editor, providing
insurance for selected IETF participants, and administering a
discretionary fund for use by the IAB and the IETF Chairs.
2. *Standards Process Functions* The Internet Society plays a
fundamental role in the IETF Standards Process, including
appointment of the Nominating Committee chair, confirmation of
IAB members, confirmation of documents that describe the
standards processes, and acting as the last resort in the appeals
process. These Standards Process Functions are defined in
[RFC2026], [RFC2028], [RFC2031], and [RFC3677] and are out of
scope for this analysis. No changes are proposed to these
Standards Process Functions.
Any changes to the *Standards Process Functions* would use the
Malamud Expires February 23, 2005 [Page 6]
Internet-Draft Administrative Support Analysis August 2004
existing procedures, which require a draft to progress through the
process, ultimately being subject to a Last Call and a declaration of
consensus. In the case of modifications to existing process BCP
RFCs, this is a high bar to cross.
1.2 Previous Steps in This Process
A process for restructuring IETF administrative support functions as
well as other more general IETF issues was started in 2002. This
process has resulted in a number of documents that have defined the
goals of the IETF and basic principles for restructuring (see, e.g.,
[I-D.alvestrand-ietf-mission]). The basic outline of the
administrative restructuring process was defined by an Advisory
Committee to the IAB, the results of which are published in
[RFC3716].
This document carries out the requirements of [RFC3716] in discussing
various options for administrative restructuring and the definition
of relationships with institutions which support the activities of
the IETF community.
The specific goals of the administrative restructuring effort, as
outlined in [I-D.daigle-adminrest], are to recognize and preserve the
community-driven nature of the IETF technical work, and to continue
to support that work through the formalization of a single
administrative umbrella organization that will be openly accountable
to that same community.
1.3 Decision Process
Restructuring of IETF administrative support functions is a
fundamental activity that must have the support of the IETF
community. This document attempts to present an "omnibus" plan,
addressing the full scope of the requirements stated in [RFC3716].
This document has already undergone numerous revisions, and will
undergo subsequent revisions based on input from the IETF community.
The first stage in reaching consensus around proposed changes include
the following steps:
1. Publication of [RFC3716].
2. Continued deliberation and issuance of Internet-Drafts on the
Administrative Restructuring.
3. A decision to "move forward" including a request for funding by
the IETF and IAB Chairs to the Internet Society Board of
Trustees, allocation of those funds, and the engagement of a
consultant.
4. Drafting of this draft.
5. Initial reviews of this draft, including reviews by the IAB,
IESG, ISOC Board, and legal counsel, and others.
Malamud Expires February 23, 2005 [Page 7]
Internet-Draft Administrative Support Analysis August 2004
6. Briefings to the community via the IETF discussion list and at
IETF60 about what to expect.
7. Publication as an Internet-Draft.
8. Discussion of the Internet-Draft in the IETF community. *<----
You Are Here.*
9. Reconsideration of the draft by the IAB, IESG, ISOC board, and
IETF legal counsel and issuance of a set of specific
recommendations by the IAB and/or IESG.
10. Issuance of a Last Call on this document and on the subsequent
memorandum published by the IESG and IAB.
11. Determination of community consensus on the updated plan.
12. Publication of this draft, as revised, as an Informational RFC.
13. Implementation, with periodic reporting back to the community.
At each stage, the draft will be revised as appropriate.
In addition, portions of this document are intended to form the basis
for one or more drafts containing new procedures or Memoranda of
Understanding related to the IETF administrative practices; these
would eventually be published as Best Current Practices (BCP) RFCs.
That process would begin after the initial community consensus.
1.4 Criteria for Judging an Administrative Restructuring
The guiding principles in the analysis of the administrative
restructuring are the criteria specified in [RFC3716], Section 3.
These criteria are worth restating:
1. Better resource management:
1.1 Uniform budgetary responsibility.
1.2 A uniform view of revenue sources
1.3 Clarity in the relationship with supporting organizations.
1.4 Flexibility to provision and reprovision services.
1.5 Administrative efficiency.
2. Stewardship:
2.1 Accountability for change.
2.2 Persistence and accessibility of records.
3. A better working environment:
3.1 More service automation where appropriate.
3.2 Better tools.
1.5 Methodology
Preparation of this report began on June 18, 2004 as part of a
consulting engagement to support the IETF and IAB chairs in the
restructuring effort, based on their request for funding
restructuring activities which was approved by the Internet Society
Board of Trustees. The contract is attached as Appendix A.
The following steps were used to gather input to this report:
Malamud Expires February 23, 2005 [Page 8]
Internet-Draft Administrative Support Analysis August 2004
o Initial briefings and continued close coordination with the Chairs
of the IAB and the IETF.
o A series of consultations with members of the IAB and IESG through
teleconferences, one-on-one email and phone conversations, and
face-to-face discussions at IETF60.
o A series of consultations with staff, officers, and board members
of the Internet Society.
o Discussions, by phone, email, and in person, with the staff of
Foretec Seminars, the Internet Society, the RFC Editor, and the
IANA, as well as a series of discussions with management at host
institutions including CNRI, ISI, and ICANN.
o A large number (over 100) of discussions by phone, email, and in
person with members of the community, including former members of
the leadership, and individuals known to represent a wide variety
of views.
o A detailed examination of relevant finances, including the
financial reports and tax returns of organizations providing
various support functions to the IETF.
o A detailed examination of operational issues, including the
functioning of key applications such as the Internet-Draft
Tracker, the operational and planning aspects of meetings, and the
functioning of the core IETF network presence.
o A detailed review of relevant documents, including electronic mail
archives, plenary transcripts, and RFCs, particularly the process
BCP RFCs.
o In cooperation with legal counsel, a detailed examination of the
current contractual framework and options available for
incorporation or otherwise providing more formalization of the
existing administrative structures, as well as a detailed
assessment of potential risks and liabilities of such a
transition.
Malamud Expires February 23, 2005 [Page 9]
Internet-Draft Administrative Support Analysis August 2004
2. Analysis of Current Administrative Framework
2.1 Providers and Functions
The IETF is an "open global community of network designers,
operators, vendors, and researchers producing technical
specifications for the evolution of the Internet architecture and the
smooth operation of the Internet."[RFC3233] A variety of institutions
provide administrative support to the IETF community:
o The Internet Society is "the organizational home of the Internet
Engineering Task Force (IETF), the Internet Architecture Board
(IAB), the Internet Engineering Steering Group (IESG), and the
Internet Research Task Force." [www.isoc.org] [1] The Internet
Society is a 501(c)(3) corporation with total 2002 revenues of
$1,695,833 and expenses of $1,681,064, of which $763,423 was
allocated as program expense to support the Standards Pillar of
the Internet Society.[ISOC-2002] The 2004 budget for the Internet
Society is attached in Appendix B.2. The Internet Society and the
IETF cooperate closely in a number of areas, as defined in
[RFC2026], [RFC2028], [RFC2031], and [RFC3677].
o Since 1969, the Requests for Comments (RFC) document series and
the office of the RFC Editor has been hosted at the Information
Sciences Institute (ISI). The RFC Editor's office and submission
process is further defined in [RFC2223],
[I-D.rfc-editor-rfc2223bis], and [RFC2555].
o The IETF has delegated the parameter registration function to the
IANA, which is hosted at ICANN. The relationship is defined in
[RFC2860]. IANA instructions for RFC authors are defined in
[RFC2434] and in [I-D.narten-iana-considerations-rfc2434bis].
o Foretec Seminars, Inc., a for-profit subsidiary of the non-profit
Corporation for National Research Initiatives (CNRI), provides a
variety of support services, including the planning of meetings
three times per year, a network presence for IETF activities, and
secretariat services such as coordination of the flow of documents
through the IESG. CNRI is a non-profit corporation registered
under section 501(c)(3) of the US tax code [IRS] and has been
providing service to the IETF since 1986 (see Section 8 for more
details on these long-term contributions to the community). CNRI
owns approximately 96% of the shares of the Delaware-chartered
Foretec Seminars, Inc.[CNRI-2002]
For purposes of this analysis, we will examine these institutions
using a 4-part taxonomy of functions:
o *Function 1: Administration.* This function includes program
management tasks such as contract administration. It also
includes any legal matters and issues of financial reporting and
transparency.
Malamud Expires February 23, 2005 [Page 10]
Internet-Draft Administrative Support Analysis August 2004
o *Function 2: Meeting Planning.* This function includes the
planning and management of large events such as the IETF meetings
held three times per year, as well as more specialized activities
such as retreats and interim Working Group meetings.
o *Function 3: Core Information Technology.* This function includes
most of the network presence of the IETF, including the basic
provisioning of computing resources (e.g., colocation, name
service, routing, transit), and core services such as mail, web
site, rsync, and ftp.
o *Function 4: Document and Information Flow.* This function
includes the flow of information through the IETF process. While
Function 3, Core Information Technology, provides the basic
platform, Function 4 uses that platform. For example, basic
configuration of Apache or a mail server is a core IT function,
while what goes on the web site and in particular email messages
is part of the document flow. Likewise, booking an appropriate
venue is a meeting planning function, but deciding the specific
agenda for a meeting is part of Function 4.
2.2 Function 1: Administration
A prime requirement of [RFC3716] was "clarity in the relationship
with supporting organizations." The IETF sits on, to paraphrase the
words of Brian Carpenter, a "four-legged" stool for administrative
support functions. Unfortunately, not all of the legs are fully
defined.
The most serious undefined area is the on-going relationship with
CNRI, which in turn subcontracts to Foretec Seminars, Inc., a
for-profit subsidiary. CNRI has provided secretariat services for 18
years, but there is no contract or memorandum of understanding with
the IETF that defines the relationship. When the arrangement was
first started, a few dozen people attended IETF meetings. Over time,
that grew to over a hundred attendees, then several hundred, and
today well over 1,000 people attend each meeting. The gentleman's
agreement was perfectly appropriate 18 years ago. But, [RFC3716] was
quite clear that today it is not a sufficient basis for managing
close to US$2 million in annual meeting fees collected on behalf of
the IETF community.
The lack of a specific contract with CNRI/Foretec is one of the items
noted in [RFC3716], however that analysis also pointed to broader
problems throughout the IETF community. In general, the
administrative and support relationships have not been defined or
kept up to date. That has led to a variety of issues observed in
interviews conducted for drafting this report:
o A lack of financial information.
Malamud Expires February 23, 2005 [Page 11]
Internet-Draft Administrative Support Analysis August 2004
o Confusion over intellectual property.
o Vague definition of the lines of authority in the contracting
relationship.
*Financial Information.* There is no systematic, comprehensive, or
timely reporting of financial information to the IETF leadership by
support organizations, nor from the IETF leadership to the IETF
community.
o Budgets are prepared at a very high level, are not based on
program goals prepared by the IETF leadership, and are not based
on historical information, such as actual versus budgeted results
in previous periods. This reduces the ability of the leadership
to participate in a meaningful budget-setting process.
o Financial reporting is also minimal: financial results are not
available during the course of the year, and have been typically
reported as late as 6 months after the close of the year. The
reports furnished to the IETF community are non-standard in
format, lack sufficient detail for evaluation, and are not
furnished to the IETF with an auditor's or accountant's statement.
*Intellectual Property.* In conducting research for this report, the
author noted a lack of clear definition of community intellectual
property. Because relationships with support organizations are
poorly defined, there is no clear, unambiguous paper trail that shows
that resources are held in trust for the IETF community and must be
managed in the public interest and in a manner that is responsive to
the IETF community. The IETF is a public standards-making
organization and a fundamental defining characteristic of the IETF is
the openness of the process.[RFC3668] All data, including databases,
correspondence, minutes, and other documentation of the IETF
operations or deliberations are an integral part of that process.
*Definition of the Relationship* The third effect of a lack of a
concrete understanding has been an apparent deterioration in the
working relationship between the IETF leadership and support
organizations. In particular, a review of correspondence shows
numerous instances where requests for specific functions have led to
discussions over who has the right to request what.
While the lack of a formal relationship with CNRI and/or Foretec
Seminars is the most pressing issue in the Administration Function,
the [RFC3716] goals of "uniform budget responsibility" and "a uniform
view of revenue sources" are not being attained. In particular:
o The Internet Society provides a number of administrative functions
that go beyond the matters specified in [RFC2031]. While that
memorandum of understanding does cover the provision of insurance,
in addition to that task the Internet Society also provides
discretionary funds to the IETF and IAB Chairs, and funds the
Malamud Expires February 23, 2005 [Page 12]
Internet-Draft Administrative Support Analysis August 2004
operation of the IAB. These expenditures are reported the IETF
community based on totals with no detail. In addition, the RFC
Editor contract is not published, although the statement of work
and total expenditures are.[RFC-SOW]
o The IANA provides parameter registry services to the IETF. While
the substance of that relationship is defined in [RFC2860], the
host institution (ICANN) does not provide financial reporting at
sufficient granularity for an analyst to understand how much that
function costs and thus understand the level of resources being
used to perform that function. In addition, no public tracking of
requests or announcements of new registrations are provided,
making it difficult to estimate the workload.
o The IETF has no uniform reporting of overall financial results.
While the IETF Chair has posted financial reports as they are made
available, there is no single location where an interested member
of the community can get a fiscal picture of the operation of the
IETF over time, or examine a standards-compliant financial report
for a particular time period.[FASB-117]
2.3 Function 2: Meetings
IETF meetings revenues have traditionally funded a wide variety of
non-meeting support functions, such as the document tracking,
submission, and distribution systems. Meeting revenues make up the
largest single revenue stream for IETF support (see Appendix B.1 for
a summary of IETF financial information over the last 3 years).
The cost per attendee per meeting has stayed at roughly $200 and
average revenue per attendee has been roughly $450 over the last 3
years, though recent gross fees have been as high as $545 including
late fees. Note that the $200/attendee cost is only direct costs
incurred on-site, and does not include additional personnel, travel,
and other expenses from support organizations to plan and staff the
meeting. Appendix C contains a summary of meeting attendance, as
well as a summary analysis of revenue and expense figures.
Although the number of participants in the IETF process as a whole
appears to have been growing, the number of attendees at IETF
meetings has been steadily dropping from a previous peak. From 2000
to 2003 the drop was fairly dramatic, though the figures appear to
have stabilized recently. The drop in attendees from the previous
peak means a smaller number of attendees have been funding a largely
fixed cost of non-meeting expenses.
The meeting business is based on several cost factors. An
organization will contract with a primary hotel with a guaranteed
rental of a certain number of guest rooms. This is known as a "hard"
contract and requires an advance deposit of a negotiable amount of
Malamud Expires February 23, 2005 [Page 13]
Internet-Draft Administrative Support Analysis August 2004
the expected room revenue.
These amounts can be substantial. For example, a typical contract
where an organization is doing a one-time event might require 50% of
expected revenue deposited as far ahead as 90 days before the event.
In the case of a typical IETF meeting, this might be 1,000 rooms at
$150/night for 5 nights, or a 90-day deposit of $375,000. Proper
negotiation of long-term relationships can reduce these cash flow
requirements by an order of magnitude.
In addition, the IETF requires certain facilities provided by the
hotel, such as audio visual equipment, electrical services, and food.
In the U.S., meeting rooms are often provided at no charge, but only
after matters such as food have been negotiated. In non-U.S.
venues, the cost for meeting rooms can be as high as $125,000.
The planning and execution of an event such as this, particularly
three times per year, requires experienced professionals. There are
a number of companies and free lance professionals that specialize in
organizing meetings for professional groups. Many of these companies
have become quite adept at computer networking, and if properly
assisted in areas such as routing and the DNS, could do a very
credible job for the IETF. It is important to note that IETF
meetings have been organized quite skillfully over a number of years
and attendees have become accustomed to this level of
professionalism. It is important that the IETF maintain those
standards.
Assistance from members of the community is an important part of
staging an IETF meeting. In addition to formal secretariat
activities, at least three teams of volunteers have been active
recently:
o For all unhosted meetings, and for most hosted meetings, a NOC
team of volunteers has helped establish a wireless infrastructure,
provisioned external lines and transit, managed DNS, and provided
a wide variety of other core services. At IETF60, the lead
engineer for this activity was Jim Martin.
o A team of volunteers organized by the University of Oregon's Video
Lab produces audio and video streams from IETF meetings (as well
as NANOG and a variety of other events).
o A team of volunteers organized by xmpp.org [2] manages a series of
XMPP[I-D.ietf-xmpp-core] servers which are used for general
commentary by participants, creation of informal transcriptions
which are archived, and for a variety of personal productivity
enhancements.[Bingo]
Over the years, a variety of other efforts have sprung up and
disbanded aimed at deploying leading-edge technologies in the meeting
Malamud Expires February 23, 2005 [Page 14]
Internet-Draft Administrative Support Analysis August 2004
network for interoperability testing or to familiarize attendees with
new protocols. Some of these activities, such as PGP key signing
parties, are ongoing. Others have been organized as one-time events.
These ad hoc activities are an important part of IETF meetings.
These self-organized, volunteer efforts, benefit from coordination
with formal meeting planning functions. For example, the core
network group requires facilities and coordination with the hotel's
telecommunications service, while the audio/video effort requires
coordination with the hotel's audio-visual contractors. Currently,
none of these volunteer efforts is linked to from meeting web pages
which are maintained by CNRI/Foretec, and there is no IETF leadership
policy on this subject.
While the day-to-day operational aspects of meetings are extremely
well coordinated, long-range planning for IETF meetings is almost
non-existent. For example, by IETF60 in August, 2004, planning for
2005 meetings had not reached any apparent degree of closure. The
IETF leadership were unaware of any firm plans for Spring or Fall of
2005, and while some progress had been made in identifying a general
location for the Summer 2005 meeting, specific venues were still
being evaluated.
Long-range planning is absolutely essential in the meeting business.
Booking well in advance and using techniques such as repeat visits to
properties that are allied through common ownership or marketing
arrangements can lead to dramatic reductions in guest room rates,
deposit requirements, and hotel charges. Long-range planning also
helps IETF meeting attendees plan their own schedules. For many
people, the commitment to go to an IETF is a major one, requiring the
use of vacation time, personal funds, and other resources.
Often in the past, a "host" has volunteered to assist in a meeting, a
task that traditionally consisted of organizing the terminal room
effort. The concept of a single host has, for recent meetings, been
supplanted by a series of sponsors who furnish specific resources,
such as bandwidth or equipment. Terminal room efforts have become
significantly easier as the IETF has shifted from importing hundreds
of bulky computers and terminals for attendees (see [RFC0015] for
more information on the concept of "terminals") to a wireless network
for laptops. The concept of "host" (or "primary sponsor") is
certainly a useful one, however instead of focusing on terminal room,
the device could be used as a way of defraying meeting room charges,
food, or other major expenses.
One final issue should be noted that has become apparent during the
course of research for this report. There appears to be no clear
guidelines on some issues related to the conduct of meetings, which
Malamud Expires February 23, 2005 [Page 15]
Internet-Draft Administrative Support Analysis August 2004
has led to disagreements between the contractor and the IETF
leadership. Two situations in particular are apparent:
1. Signage. All hotel signage for IETF60 was in the form of the
"Foretec IETF Summer Meeting." While this is perhaps a small
matter, it was brought up numerous times by meeting attendees.
In most association meetings, signage is strictly controlled so
that all sponsors and contractors (and in the case of the IETF,
volunteers) receive appropriate billing.
2. Corollary activities. There have been several attempts to defray
meeting costs or increase profits through the use of trade
exhibitions, user groups, engineering task forces, and various
other activities affiliated loosely or closely with an IETF
meeting. Any policy on colocation of related events at an IETF
meeting is a policy matter that should be under the direction of
the IAB and IESG and ultimately the IETF community. The IETF
leadership should formulate such a policy.
2.4 Function 3: Core Information Technology
While meetings provide an important part of the IETF process, it has
always been a basic policy of the community that participation in
meetings is not required to participate in the IETF. Mailing lists,
document submissions, and other aspects of a continuing network
presence are a core part of the IETF.
As noted above, this analysis divides that network presence between a
core information technology function, which is discussed here, and
the uses of that network, which is described in the next section.
Unfortunately, the IETF does not do a very good job of providing a
network presence for its own activities.
There are many opinions about how "good" or "standards-compliant" or
"well-provisioned" a network infrastructure should be for any
particular activity. However, by most standards, it is hard to argue
that the IETF is using the technology effectively. A comprehensive
analysis of network performance is impossible simply because
statistics and logs or any other reporting is not available.
However, a few anecdotes will serve to illustrate the point.
There are six Web sites that contain information important for IETF
participants. None of these Web sites, as of August 13, 2004, were
compliant with the W3C Validation Service and with published HTML
standards:
o http://www.iana.org/ [3]
o http://www.rfc-editor.org/ [4]
o http://www.isoc.org/ [5]
Malamud Expires February 23, 2005 [Page 16]
Internet-Draft Administrative Support Analysis August 2004
o http://www.ietf.org/ [6]
o http://www.iab.org/ [7]
o http://www.irtf.org [8]
Likewise, none of these sites is reachable using IPv6. Search
engines on all four sites are primitive at best, and are not
operational in the case of www.iana.org and www.isoc.org. Few
attempts are made at authentication of information, domain names, or
applications. Again, these are all anecdotal examples, but they
match the findings of [RFC3716] that the IETF does not use technology
as effectively as it could.
One function that appears sorely lacking on any of these systems is
the provisioning of shared environments for use by working groups,
directorates, the IAB, the IESG, and other groups. Working groups,
as part of the management of chartering activity, are able to specify
a web site and a mailing list, but there appears to be no mechanism
that allows a portion of the web, FTP, or other core operational
servers to be delegated for use by a particular group.
The result has been that working groups, teams and areas create a
diverse plethora of unconnected sites for handling IETF functions,
such as rtg.ietf.org, ops.ietf.org, edu.ietf.org, various issue
trackers, WG web sites and other tools hosted at diverse private web
sites, the availability of which is critically dependent on
volunteers - which are usually drawn from the WG. This is not
necessarily a bad thing, but as will be seen in Section 3.4, some
additional support might help meet goals such as the goal stated in
[RFC3716] of "persistence and accessibility of records." For example,
a systematic archiving facility can assist decentralized efforts,
unified search facilities might prove useful to those searching for
information, and one could certainly find many ways to improve the
navigation, presentation, and timeliness of the current IETF network
presence.
2.5 Function 4: Document and Information Flow
Function 4, Document and Information Flow, is the part that directly
supports the day-to-day functioning of the IETF. While core
information technology provides a web server or a mail server, this
function populates those servers with information based on the rules
defined in process BCP RFCs as well as various unwritten procedures
and customs.
A demanding part of the current IETF Secretariat is the process of
supporting the numerous bodies that proliferate through the
community. The IESG, of course, requires a great deal of support,
given their bi-weekly teleconferences, and the tremendous workload of
Malamud Expires February 23, 2005 [Page 17]
Internet-Draft Administrative Support Analysis August 2004
documents to consider, working groups to charter, and other functions
the group performs. The high workload of IESG members has been noted
repeatedly.
Many of the functions required to support a deliberative body such as
the IESG are ideally suited for a capable administrative office, a
task often labeled as "Clerk." In the U.S., for example, the "Clerk
of the Court" or "County Clerk" are key tasks in their respective
organizations. These officers and offices facilitate the flow and
archiving of information, providing both a human and a procedural
interface for disseminating information among participants in a
process.
The tasks that are encompassed in this function include:
o Supporting the working group charter process, which includes
processing the initial charter, rechartering, milestone
management, and closing of the working group.
o Publication of Internet-Drafts. It is assumed that current
efforts to automate the submission process will be successful,
alleviating much of the manual effort that this function currently
has.
o Document tracking, including a ticket-system-based response to
document and working group management problems, announcements of
last calls, and a variety of other functions.
o Managing IESG meetings, including scheduling, creation of the
agenda, and collecting the minutes, as well as the creation and
long-term archiving of IETF meeting proceedings.
o Handling the Intellectual Property Rights disclosure process (a
process which is presently undergoing automation).
o Publication of official actions, such as document approvals,
including communication of such status to groups such as the RFC
Editor.
o Registration and publication of liaison statements from other
standards bodies and publication of liaison statements, responses
and other communications by the IETF to Standards Development
Organizations (SDOs).
o Support of the Nominating Committee.
o Assisting the Meeting Planners in crafting an appropriate agenda
for the IETF meetings, a complex task that requires a fairly
detailed knowledge of the IETF operation.
A great deal of progress has been made in this area over the last
year, with active participation of a new Tools group and of IESG
members. However, there is still substantial work to make the flow
of information smoother and more predictable. For example, even
though the Internet-Draft, RFC, and IANA processes are all closely
linked in theory, in practice each organization currently maintains
their own tracking system. In the case of the IANA, that tracking
Malamud Expires February 23, 2005 [Page 18]
Internet-Draft Administrative Support Analysis August 2004
system is not visible outside of the organization. Thus, interaction
among these three bodies often relies on personal communications, and
there are fairly frequent issues of tokens being lost, or "customers"
(e.g., the author of a particular draft) being unclear where in the
process they are.
Malamud Expires February 23, 2005 [Page 19]
Internet-Draft Administrative Support Analysis August 2004
3. Recommendations for Restructuring the Administrative Framework
This section contains recommendations for changing how the day-to-day
support functions are provided. Issues such as how to contract for
services and whether or not a full-time staff member should be hired
are dealt with in this section. Section 4 discusses the
institutional framework in which these activities can be housed,
including issues such as whether to incorporate the administrative
entity.
3.1 Recommendation 1: Hire An Administrative Director
The deliberations of the Problem Statement Working Group made it
clear that the IESG and IAB are both overworked with an increasingly
large flow of technical issues. The group also made it clear that
the IETF Chair and the IAB Chair should continue to be picked for
their ability to lead the IETF technical activities, not solely on
their ability to create a conformant income statement.[RFC3774]
One key cause of the current ambiguous management structure is the
lack of even one full-time staff member who reports directly to the
IETF leadership. For example, the IETF Chair and IAB Chair attempt
to prepare an annual budget and do financial reporting, but they do
so without any professional help. Among leading standards
organizations, the IETF is alone in failing to provide any staff to
assist the leadership in such activities.
While zero staff is a non-standard way to run a standards body, a
large staff would run counter to a long-established feeling
throughout the community that the creation of a large bureaucracy
would go against the fundamental tenets of how the IETF operates.
In the IETF, there thus appears to be a philosophy that strongly
favors outsourcing services whenever possible. A first step would be
to hire a single staff member, an Administrative Director. This
position would be responsible for tasks such as hiring and working
with contractors, managing finances, and working with other
professionals such as lawyers and auditors. A decision on whether or
not the ultimate size of the support staff remains at 1 or grows very
modestly thereafter can be deferred.
This is a fairly demanding position, as it requires a firm knowledge
of business fundamentals, such as budgeting, contracting, logistics,
and MIS operations. The successful applicant for such a position
would also have to either be already familiar with the IETF or be
able to quickly assimilate the culture. Prior knowledge of IETF
politics should not be prerequisite for this position, but since an
Administrative Director would have to work on a day-to-day basis with
Malamud Expires February 23, 2005 [Page 20]
Internet-Draft Administrative Support Analysis August 2004
a decentralized, consensus-based community, the position will require
a certain level of political sensitivity. The position will also
require a certain technical cluefulness, though again, such skills
could be acquired on the job in certain cases.
Creation of this position should be fairly straightforward. First, a
job description should be created. The position can be advertised
using a variety of media, ranging from the IETF mailing lists to more
formal mechanisms such as advertisements in publications such as the
International Herald Tribune, the New York Times, the Economist, or
the Wall Street Journal. A yet more formal strategy would be to
engage a professional search firm.
Evaluation of applicants might consist of a search committee
appointed by the IETF Chair. The committee would conduct an initial
review of applications, possibly solicit additional applications, and
present a short-list for further consideration. This short list of
applicants could be reviewed by the IESG and IAB, possibly with
further interviews. The IESG and/or IAB should specify this
procedure more fully before beginning the search.
As part of the drafting of a call for applicants, the IETF leadership
may want to consider what the IETF leadership groups need in the way
of support and how they can structure the position in a way that
attracts the best applicants. For example, procedural mechanisms
such as explicitly allowing the staff to be present on mailing lists,
teleconferences, and meetings may be necessary before applicants will
consider the position one which is doable.
A sample draft Call for Applications is attached as Appendix E.
3.2 Recommendation 2: Establish Contracts for Core Services
The lack of a contractual basis for present services is, as discussed
earlier, a historical artifact of the dramatic growth of the IETF
from a few to a few hundred to several thousand participants.
Establishing a formal basis for such services by the close of this
calendar year is a fundamental recommendation of this report. A
formal understanding for support services can take several forms,
including contracts or memoranda of understandings. Since the IETF
is based on an open process, it is important that all significant
contracts be published so they have formal standing within the
context of the IETF community. Such publication can be on a web
site, or can be a republication of the contract in the RFC series.
Just as a contract should be published as an RFC so they have formal
standing in the community, it is important that any Memoranda of
Malamud Expires February 23, 2005 [Page 21]
Internet-Draft Administrative Support Analysis August 2004
Understandings published as an RFC have similar standing in the legal
world. It is important that such contracts or memoranda have
adequate legal review to insure that the key elements required in
contract law are present.
For organizations providing support services who are not presently
under contract, there are two broad strategies that can be used to
move from the present administrative framework to the more formal one
proposed here: sole source procurement or a Request for Information
(RFI) or Request for Proposals (RFP) to solicit a variety of bids
from multiple vendors, including the present providers.
It is important to note that with the present granularity of
historical financial information, an RFP will be an essential part of
understanding the various expense models associated with different
services levels and provisioning strategies.
A decision also has to made whether the current services are
monolithic or can be decomposed into separate pieces. A case can be
made that a single vendor for most services can provide the most
responsive service. Alternatively, one could argue that some
services are specialized, such as meeting planning, and might be
better carried out by a specialist.
A final factor comes into play, which is the risk to continuity of
operations caused by any transition. There is also a financial cost
to any transition, including capital costs (e.g., acquiring
sufficient assets to do the job), cash flow requirements (e.g., hotel
deposits for meetings can be substantial), and professional help
(e.g., lawyers, accountants, and a variety of other services).
There are thus a spectrum of options available within the extremes of
RFP and sole source procurement. This report recommends one of the
following three strategies:
o *Strategy 1.* Issue an RFP for all core secretariat services.
This would allow the current provider to bid and thus establish
contract terms upon a successful bid, but would also allow other
vendors to compete.
o *Strategy 2.* Attempt to negotiate a sole source procurement on
all of the functions, but after a designated time-out period
(e.g., 30 days), if the negotiation is not successful, issue an
RFP. The term of the sole source procurement could be a subject
of the negotiation, or a fixed term (e.g., 1 year) could be
established a priori. The intention would be to issue an RFP for
the subsequent contractual period.
o *Strategy 3.* Some combination of the two above options. For
example, attempt a sole source procurement on two of the three
functions, and issue an RFP for the third.
Malamud Expires February 23, 2005 [Page 22]
Internet-Draft Administrative Support Analysis August 2004
Based on research conducted for this report, the author is of the
opinion that meetings and the core "Clerk" functions would be the
most difficult to transition to a new provider. Meetings are
difficult because of long lead times (and an RFP process would
further delay 2005 planning unless an interim planning process can be
established). The "Clerk" functions have a great deal of
institutional knowledge, much of which is not properly documented.
Thus, the author of this report recommends that, if a hybrid strategy
of attempting a sole source contract on two functions and an RFP is
used for the third function, that core network services is a good
candidate for an RFP and meeting planning and "Clerk" functions would
be a good candidate for sole source procurement negotiations.
Providing a computing infrastructure is an area with many qualified
professionals and some well-established industry norms. This
strategy would also allow the IETF to move core archives that are
presently decentralized into a common infrastructure, would provide
more flexibility to provide resources to workgroups, and would allow
non-contractor developed tools to coexist with existing resources.
If an RFP is not issued a particular function, then a sole-source
contract negotiation would be used. There should be a clear
understanding on intellectual property ownership, in particular a
clear statement about all information flowing through the IETF
process belonging to the IETF community, including the following:
1. Domain names, including iab.org, ietf.org, iesg.org, and
irtf.org.
2. Content of Internet-Draft directories.
3. Content of Web sites.
4. Subscriber lists for all mailing lists (public and private).
5. Mailing list archives for all archived mailing lists (public and
private).
6. Working group database content including charters.
7. Internet-Draft history database content.
8. Internet-Draft tracker database content.
9. Meeting minutes.
10. Meeting attendance records, including "blue sheets".
11. Archive of expired Internet-Drafts.
12. Documents relating to the creation and reporting of working
group status.
13. Copies of any other IETF information including correspondence
and historical records.
In addition to intellectual property considerations, any contract
negotiation should be bounded by two other parameters:
1. A transition clause is essential to allow for an orderly
transition to other vendors in the future. For example, if
Malamud Expires February 23, 2005 [Page 23]
Internet-Draft Administrative Support Analysis August 2004
meetings are provided on a one-year support contract, but meeting
venues are being booked on a longer time scale, a clause in the
contract would allow the transfer of venue to a new contractor.
In addition, a fairly standard clause in many such contracts
would allow the ability for a new contractor to issue employment
offers to non-managerial employees of the old contractor as a
transition mechanism.
2. A negotiating period time-out clause is essential in such a
process. This report recommends that a small team be assembled
to negotiate such contracts under the direction of the IETF and
IAB chairs, reporting back for the advice and consent of the IAB
and IESG, and that any resulting contract be published. If 30
days lapse and no agreement is reached, the IAB and IESG should
have the option, after reporting back to the community, of either
extending the negotiating period for an additional 30 days, or
issuing an RFP.
While establishing a contract for uncontracted services is absolutely
essential, some attention should also be paid to services provided by
the IANA or the RFC Editor. For example, returning to a multi-year
contract with the RFC Editor instead of the current one-year
extensions might provide for a larger investment in the function by
the host institution. Likewise, agreements with the Internet Society
and ICANN should be kept current.
3.2.1 Details of Potential RFP Components
3.2.1.1 Provision of a Basic Computing Infrastructure
Part of the philosophy of the IETF support process is to not make
large organizations whose sole purpose is to support the IETF. This
is still a valid approach.
In recent years, the support for the IETF has been carried out by a
small number of organizations working on fairly unconnected tasks
(RFC Editor at ISI, IANA at ICANN and secretariat and meeting
services both handled at Foretec).
Each organization has provided its own facilities for storage,
publication, information distribution and list maintenance, as they
saw it required for their tasks. his is not necessarily an optimum
distribution of resources. One could imagine multiple models,
including:
o The IETF controlling a distributed compute platform and storage
facility, with multiple organizations using that to perform work
under contract, and using each others' services when appropriate
(management of the platform being of course one such contract).
Malamud Expires February 23, 2005 [Page 24]
Internet-Draft Administrative Support Analysis August 2004
o A distribution much like the present, where suppliers bring their
own resources, but with tasks distributed differently, with (for
instance) meeting planning and Web presence maintenance being
separate tasks, but with increased emphasis on information sharing
and open access to information.
o An even larger concentration of roles, where one service
organization takes on tasks that are distinct today.
There is not sufficient information on price, performance or benefits
of the various approaches today. A Request for Proposals process,
however, would generate the necessary information. An RFP process
where the components of the work are separated out to the largest
extent practical will encourage the people who offer proposals in
response to tell explain which parts of the RFP they would be willing
to take on, how they would get synergy out of combining them, and
what services they would be capable of using from other providers.
The RFP is an information gathering tool, and will be followed by
extensive negotiations and planning on how the services the IETF
needs can be supplied. This needs time, and because of this, sending
out an RFP earlier rather than later in the decision process will
provide important input used to structure the work to be performed.
A draft RFP is contained in Appendix F and picks the following
decomposition:
1. Meeting Planning
2. Systems Administration (support infrastructure)
3. Mailing list management
4. The Web presence
5. The "Clerk's Office" which would be responsible for the flow of
information and administrative support for the IESG and WGs and
the Internet-Draft publishing service.
The RFP is structured so proposals may be received for one or more of
the above requirements. A single bidder may elect to provide all
functions, one function, or some combination. The RFP is structured
to include a review process, and the selection criteria are based on
what is best for the IETF as a whole, as opposed to a single formula
such as lowest price.
One important factor in all bids for supporting service will be the
degree of continuity and accountability. A "key person" principle is
proposed where an individual contact is identified as responsible
manager for the function. It is this person who will give guarantees
to the IETF for the services being available to the IETF with
adequate availability and response times, and who will take charge of
the organization that supplies the services.
Malamud Expires February 23, 2005 [Page 25]
Internet-Draft Administrative Support Analysis August 2004
3.2.1.2 Core Network
Currently, the IETF does not own any computers, colocation space, or
transit capacity. Indeed, the IETF does not even run a web site.
All of these functions are contracted out, and the contracts include
full provisioning of the underlying infrastructure. As mentioned
above, this is only one possible arrangement. We do not have data
that will allow us to know what to choose between the alternatives
here.
If adequate resources can be obtained at the right price, including
servers, colocation space, and bandwidth, and if those resources meet
the high standards needed to sustain IETF operations, the best thing
for the IETF may be to operate on such an infrastructure. Having an
adequate in-house infrastructure controlled by the IETF also provides
substantial flexibility in the case of future transitions of key
contractors, but it also burdens the IETF with the requirement to
maintain and replace equipment.
An organization able to provide highly competent systems
administration would be needed to support a solid computing platform.
If purchased at commercial rates, this would probably be a
significant part of the cost of this way of supporting services. The
RFP process will tell us what we can depend on.
In terms of volunteer contributions for specialized areas such as
nameservice or routing, the IETF may be able to draw upon volunteer
help from participants. It would make sense to have the relationship
with the volunteer be slightly formalized, including a public
appointment to the named task. This impresses upon all that such a
task is one of trust and makes the community aware that the
individual or organization has assumed this particular
responsibility.
3.2.1.3 Mail
The IETF is a mail-intensive operation, with mailing lists for
working groups, directorates, the IESG, the IAB, and a raft of other
lists, not to mention the core IETF and announcement lists.
Certain specialties in computing are considered an art unto
themselves. Mail is one of those areas. The IETF Administrative
Entity should simply contract the postmaster function to a vendor
experienced in running environments characterized by high-volume mail
servers, large numbers of lists with various access and moderation
policies, a stringent archive requirement, and an ability to
implement appropriate filtering policies (where the policy, of
course, is ultimately set by the community).
Malamud Expires February 23, 2005 [Page 26]
Internet-Draft Administrative Support Analysis August 2004
This task is as much a public service position as it is a contract.
The task of postmaster to the IETF Administrative Entity should be
sufficiently attractive that it will attract highly capable bids.
Since a variety of provisioning options are available for this
service, the evaluation process should carefully consider each
proposal for criteria such as stability of service and infrastructure
redundancy.
3.2.1.4 Community Workspace Support and the IETF Network Presence
The IETF needs far better support for our various groups that wish to
maintain a network presence. While the core document submission
process is highly structured, currently the operation of individual
working groups, directorates, or other groups all have very different
styles. A variety of styles is a Good Thing and should be supported.
Systems administration can provide core tools such as web servers,
FTP servers, and can allocate space to groups. However, an effective
network presence for the IETF involves many issues about how we
archive our information, how we make it easy for new groups to form
workspaces, and how we interface to our data through search and
navigation facilities.
Core systems administration is on a different layer of the stack than
the applications support that is needed to help maintain a
productive, happy community with a clueful Internet presence.
It is proposed that the IETF Administrative Entity needs a webmaster
to supplement the resources of the systems administrators. The
sysadmin can install Apache with appropriate modules, but building a
core web site for the IETF involves other skills, including knowledge
of CSS, HTML, XML, and a variety of scripting skills in languages
such as PHP or PERL or TCL (pick your poison).
At first glance, this may seem to be a development effort, not an
ongoing operations effort. However, we believe a more sustainable
system can be built with a webmaster task which combines on-going
responsibility for access to the core IETF information along with a
support role for the broader community of working group chairs,
directorates, and the like.
3.3 Recommendation 3: Provide Timely and Uniform Financial Reporting
This report recommends that all available historical financial
information be posted in a single public location, and that an
immediate commitment to post more complete and timely financial
information in the future be made.
Malamud Expires February 23, 2005 [Page 27]
Internet-Draft Administrative Support Analysis August 2004
In addition, the IETF leadership should begin formalizing the budget
process in anticipation of any administrative restructuring efforts.
Once issues of an institutional home for administrative functions
have been decided, a full budget with program goals, including any
relevant transition expenses and a cash flow analysis, will be
required by any potential groups helping finance the IETF
Administrative Entity as part of the funding group's annual budget
planning processes.
These functions are all envisioned to be the primary responsibility
of the Administrative Director, with some contractor assistance for
accounting and auditing tasks.
3.4 Recommendation 4: More Focus on Archives
[RFC3716] stressed the importance of proper attention to the
persistence and accessibility of records, including the requirement
that "the IETF needs to maintain and support the archiving of all of
its working documents in a way that continues to be accessible, for
all current and future IETF workers." The IETF does not currently
meet that requirement. In particular:
o Although the RFC Editor maintains an "RFC-Online Project", over
200 RFCs have yet to be put online.
o Archives of IETF working group mailing lists are spotty and
sometimes unreliable.
o The ietf.org Web site does not include a comprehensive archive of
all Internet-Drafts, though several volunteers in the community do
maintain such sites on an informal basis. It should be noted that
this lack of a public comprehensive archive is a policy decision
of the IESG. A private comprehensive archive is a legal
requirement, as the IETF is the original publisher of
Internet-Drafts and is sometimes asked for old drafts in cases
such as patent disputes. Even if the archive is not available on
a public site, regular audits of the completeness of the archive
are necessary.
o On a short-term basis, there is no adequate backup for the
www.ietf.org web site, which has led to periodic accessibility
issues.
o Although videolab.uoregon.edu has an archive of past meeting audio
and video feeds, that archive only dates back to IETF49.
More attention to this important area is recommended as a key 2005
goal.
Malamud Expires February 23, 2005 [Page 28]
Internet-Draft Administrative Support Analysis August 2004
4. Options for an Institutional Basis for Administrative Activities
4.1 Discussion of Organizational Form and Legal Domicile
This report frames the question of organizational form as follows:
o Should the IETF administrative support organization be
incorporated?
o If so, should it be now or later?
o If so, what domicile and specific form should be chosen?
o If so, what would be the specific nature of the relationship
between any potential new organization and the Internet Society?
As seen above, there is a close relationship between ISOC and the
IETF that is independent of the administrative restructuring of IETF
support.
The requirements for the relationship between the IETF Administrative
Entity and the IETF Community are:
o The process must generate the support that the IETF needs.
o The process must be transparent; people and organizations who
donate money to the standards process must be able to verify that
the funds have been spent on effective support of the standards
process.
o The process must be efficient; the overhead of a large bureaucracy
is not in the best interest of the IETF.
o The process must be flexible enough to allow the IETF support
structure to adapt to changing IETF community requirements.
o The administrative entity must be responsible to the IETF.
As an aide for discussion purposes, this report proposes four
scenarios:
o *Scenario A.* The Internet Society role as legal home of the IETF
is augmented to include the new administrative function. As
issues arise in the future, appropriate memoranda of understanding
or other formal checks and balances can be developed.
o *Scenario B.* As in Scenario A, the Internet Society's role is
augmented to include administration of IETF support functions.
However, instead of waiting to understand what the issues are, the
IETF takes proactive steps to take a more fundamental role in the
Internet Society as its administrative home. Thus, the difference
is that in Scenario B, more time is spent up-front on formal
definition of the relationship. Needless to say, more up-front
definition is sometimes a good thing, but can also lead to a great
deal of time solving problems that don't exist.
o *Scenario C.* This scenario says that the IETF community is ready
and willing to undertake the responsibilities for managing its
administrative efforts. A new incorporated body is formed to
house those functions. That body would be closely tied to the
Malamud Expires February 23, 2005 [Page 29]
Internet-Draft Administrative Support Analysis August 2004
Internet Society through a variety of mechanisms that show that
the two entities are part of a "symbiotic whole."
o *Scenario D.* As in Scenario C, a new incorporated body is formed
to house the administrative support functions. But, instead of
being as closely linked to the Internet Society, the entity bears
much more of the burden of setting up an infrastructure. In this
scenario, the IETF community is now completely responsible for
ensuring all aspects of its continued, long-term financial
viability.
4.2 Scenario A: ISOC Operating Unit
Presently, the Internet Society administers the RFC Editor contract
under the direction of the IAB, provides the IAB and IETF
discretionary funds, and purchases insurance to cover some people
involved in IETF decision making. The Internet Society also raises
all funds need in excess of those provided by IETF meeting revenue.
In this scenario, the Internet Society simply augments their current
provision of services with appropriate contracts and program
management services to manage the core IETF support contracts,
including a significant number of large and small meetings, a fairly
complex Clerk's Office, and a significant Internet presence.
In this scenario, the Internet Society would employ the
Administrative Director proposed in Section 3.1. The job search
would be conducted in consultation with the IAB and IESG. That
employee would in turn, again in consultation with the IAB and IESG,
manage any sole source procurements or RFP processes that are
approved by the Internet Society in consultation with the IAB and
IESG. The IETF activities would appear as line items in the Internet
Society budget, with revenue and expenses clearly allocated by
program area (as they currently are on ISOC financials).
4.2.1 Division of the Internet Society
In this scenario, the IETF administrative activities would be
undertaken as a Division of ISOC. It would have as its day-to-day
operational head a senior Administrative Director who would have
operational responsibility for all the IETF administrative activities
on behalf of the IETF community. This individual would be an
employee of ISOC, but management oversight would be structured to
include direct IETF involvement including the IETF and IAB Chairs,
and/or an Oversight Committee appointed by some IETF-specified
process.
Budgets would be established each year in consultation with the IAB
and IESG, and approved by the ISOC Board as well as the IETF
leadership. The IETF Division would have its own bank account and
Malamud Expires February 23, 2005 [Page 30]
Internet-Draft Administrative Support Analysis August 2004
the Administrative Director would collect and manage all receipts
(including revenues from ISOC destined for the IETF) and
disbursements. Operationally, this reserves for the IETF Division
the ability to prioritize and re-allocate funds within the
constraints of the approved budget as seems best and will provide
maximum flexibility in service provisioning. Once the budget has
been agreed upon it would be the responsibility of the IETF
Administrative Director to manage it. All IETF finances would be
separately accounted for and fully transparent.
In particular,
o The IETF Administrative Director would have ISOC signatory
authority for IETF contracts and would be responsible for managing
all contractors/vendors to the IETF.
o The responsibilities that the IETF Administrative Director would
have with respect to IETF activities would be determined by
standard IETF processes (BCPs, RFCs, etc.)
o The Administrative Director would be hired (and removed) jointly
by the IETF Chair, IAB Chair and the ISOC CEO according to a job
description established by the IETF community. Performance would
be evaluated by those same individuals, and the personnel home for
the Administrative Director would be in ISOC (benefits, pension,
medical, etc.).
o The IETF Administrative Director could draw upon the other
resources (accounting, technical infrastructure, reception, legal,
etc.) of ISOC.
4.2.2 Intended benefits
By hosting the IETF administrative activity within an existing
organization, there is the possibility of cost reduction by sharing
resources. This proposal would give closer and more flexible access
to a broad range of skills and competencies (e.g., sharing portions
of employees time as needed). Note: IT facilities is one area where
the IETF may need separate support/facilities.
Under this model, the IETF could continue to expect ISOC to take a
significant fallback responsibility for any liabilities, whether
financial or legal, that might be incurred by the IETF.
This model also provides an unambiguous fund-raising model, in which
the possibility of confusion between ISOC and IETF efforts is
minimized.
4.2.3 Additional Considerations
One of the considerations from which the IETF has long benefited is
the current separation between corporate donations and IETF actions.
Malamud Expires February 23, 2005 [Page 31]
Internet-Draft Administrative Support Analysis August 2004
Instantiating this scenario would require continued care to ensure
that the IETF maintains a reasonable distance from the funding
streams (apart from meeting fees) and minimizes the potential of
conflicts of interest with funding sources and other perceptions of
excessive influence by particular participants or their
organizations.
While standards have always been an important component of ISOC's
activities, ISOC as a whole does have a broader mandate, and its
Board must be selected and empowered to meet that broader mandate,
not just the IETF's needs. Nevertheless, from ISOC's perspective, it
is by design and in the governance structure, very complementary and
ISOC has always seen its core responsibility as being to the IETF.
The dedicated IETF Administrative Director and separated budget are
seen as a means of ensuring continuous and adequate attention to IETF
activities, and 3 IETF appointed seats on the Internet Society Board
provides representation within the governing body.
Under this model, the IETF administrative activity is naturally
responsive to and part of the overall ISOC management structure and
its evolution. That is, the scenario described here is modeled on
ISOC's current management and mission structure, assuming that it
will be largely static over time. ISOC has demonstrated several
times in the past that it was willing and able to change its own
governance structure in ways that benefited the IETF activity, and
this specific proposal assumes that will continue to be the case,
without making specific provision for ensuring it.
As the Internet Society, and the Internet Society Board, would bear
responsibility for making sure the continued IETF support function is
carried out in a fashion that is responsible to and responsive to the
IETF community, this scenario is potentially a large undertaking and
should take careful consideration of the financial and logistical
implications of undertaking such an operation and of the requirements
of [RFC3716].
(Note that careful consideration of the responsibilities and the size
of the undertaking applies to all actors in all scenarios, and
applies equally to the Internet Society, the IETF community, and to
any other support organizations.)
4.3 Scenario B: More Formalized ISOC Operating Unit
The philosophy in Scenario A is understand the basic parameters of
how the relationship would work, but instead of spending considerable
time defining all possible parameters, get to work quickly on
pressing problems and deal with longer-term institutional issues as
they come up or after experience is gained. Another strategy,
Malamud Expires February 23, 2005 [Page 32]
Internet-Draft Administrative Support Analysis August 2004
outlined here as Scenario B, is to lay down more of those basic
parameters about how the relationship would work, enshrining those
parameters in a process BCP RFC.
Scenario B leverages the benefits of Scenario A, while providing for
additional mechanism further define the relationship of the Internet
Society to the IETF community and what the provision of
administrative support functions means. Scenario B is identical to
Scenario A, but more up-front work is put into defining the
relationship.
These mechanisms are simply suggested directions to explore based on
suggestions from early reviewers of this draft, and further
discussions may add or remove mechanisms from this list:
o Mechanism 1: Modify the Internet Society bylaws and articles of
incorporation to explicitly recognize this expanded role and to
explicitly refer to process BCP RFCs such as [RFC2026], [RFC3777],
[RFC2418], and their successors as the governing mechanism for the
standards process.
o Mechanism 2: Re-task the three IETF appointees to the Internet
Society Board of Trustees so that they are representatives of the
IETF and can receive instructions from the IETF leadership on
particular issues. [[anchor24: Several reviewers have pointed out
drawbacks of this mechanism, particularly the loss of independence
of those director seats. These reviewers have pointed out that if
the IETF and IAB Chairs have seats on the board as ex-officio
members, sufficient representation of IETF interests is present.]]
o Mechanism 3: Give the IETF and IAB Chairs ex-officio, non-voting
seats on the Internet Society Board of Trustees.
o Mechanism 4: Grant the Administrative Director observer rights at
Internet Society Board of Trustee and Executive Committee
meetings.
o Mechanism 5: Create a Memorandum of Understanding between the IETF
and the Internet Society outlining operational parameters, such as
how contract services get managed, how financial results are
reported, and how other services such as insurance shall function.
[[anchor25: Reviewers have noted that this mechanism would be
necessary under Scenario A as well.]]
o Mechanism 6: Require that Internet Society meeting notices also
include notice of consideration of issues affecting the IETF.
This mechanism allows for community feedback on those issues prior
to any decisions. A variant of this mechanism would allow the IAB
and IESG to assert that a particular issue is critical to the
functioning of the IETF, thus requiring a supra-majority of the
Board to approve the action.
o Mechanism 7: Hold an open ISOC annual Board of Trustees meeting at
an IETF plenary meeting to facilitate more community
participation.
Malamud Expires February 23, 2005 [Page 33]
Internet-Draft Administrative Support Analysis August 2004
As noted above, these mechanisms are simply "straw-men" proposed by
members of the community. Any decision to pursue this Scenario, as
with all other Scenarios, will require a careful look at the specific
language and provisions needed to meet the overall goals set by the
community. As noted in Section 1.3, this would likely be in the form
of a process BCP RFC.
The intended benefits of this Scenario are as in Scenario A, with the
additional intended benefit of bringing the IETF community and ISOC
community more closely together to manage their futures.
4.4 Scenario C: Well-Defined Entity With Close Ties to ISOC
In this scenario, administrative support functions for the IETF are
legally housed in a focused, incorporated institution (although the
Administrative Directory might be physically housed within the
Internet Society). This scenario, as well as Scenario D, raises a
series of issues as to the form and legal domicile of such an
organization.
Scenario C envisions a number of concrete linkages with the Internet
Society, which supplement the current close interconnection of the
IETF community with ISOC. For example, under this scenario, primary
fund raising responsibility would be invested in the Internet
Society, allowing ISOC to create a unified fund raising voice
(thought the proposed IETF Foundation would still be in a position to
accept in-kind contributions). In addition to the fund-raising
agreements, this Scenario envisions a variety of other linkages, such
as continued cooperation on education and policy.
4.4.1 How Scenario C Might Work In Practice
There are a variety of legal forms that a formal IETF administrative
support organization could take, but the public, non-commercial
nature of the IETF standards process points fairly clearly to the
formation of a non-profit organization of some sort. A non-profit
organization, if formally recognized, has substantial benefits, such
as exemption from income tax, relief from VAT and sales taxes when
procuring services, and the ability for certain contributors to
deduct donations made to the organization.
It also seems important symbolically that any legal underpinning that
creates an organization for administrative support functions should
reflect the non-profit nature of the IETF as well as reflect the
basic nature of the IETF, which has participants and not members.
While there are numerous organizational structures available, the
most straightforward form for the providing IETF administrative
support is likely to be a non-profit corporation with no members and
Malamud Expires February 23, 2005 [Page 34]
Internet-Draft Administrative Support Analysis August 2004
no stockholders.
In addition, any formal organization for administrative support needs
to take into account some of the unique characteristics of the IETF:
o It is possible that none of the members of the board of the
administrative support organization will come from the country
that the organization is incorporated in.
o The IETF already has a decision making process for a large number
of our important decisions. The incorporating law should allow us
to subordinate the administrative support organization to these
already-existing processes, as they exist now and as they may
change in the future.
4.4.1.1 Where Might the Administrative Support Organization Be
Domiciled?
Perhaps the most difficult question to consider is which country the
IETF support organization should incorporate in. A characteristic of
the IETF is that we are individual participants. Unlike many
standards bodies, the participants do not represent employers and,
unlike the most formal standards bodies, participants do not
represent countries.
There is a predisposition to strongly consider countries other than
the United States, simply because the IETF is an international group
and a large number of key Internet institutions are already in the
United States. Incorporation of the IETF administrative support
organization is an important milestone, and a predisposition is to
try to show diversity.
Nonprofit incorporation in a number of countries with significant
nonprofit sectors as well as a significant number of IETF
participants was considered. These countries include France, Japan,
the Netherlands, Switzerland, the United Kingdom, and the United
States.
Several countries were initially ruled out because their nonprofit
laws do not permit entities that are not member-based, or have local
requirements such as conducting business in a certain language. In
other cases, there are difficult to meet local requirements for
non-profits. For example, in order for an organization to qualify
for tax exemption in the United Kingdom, an organization has to fall
under one of four "heads" of charity. Three of these are
general-purpose heads, including the relief of poverty, advancement
of education, and the advancement of religion. However, none of
these three are the intended direct focus of the IETF administrative
support organization. The fourth category is "purposes beneficial to
the community" and it appears that our local nexus to the country is
Malamud Expires February 23, 2005 [Page 35]
Internet-Draft Administrative Support Analysis August 2004
somewhat slim and might be viewed somewhat skeptically by the Charity
Commissioners.
As part of this analysis, a "flag of convenience" approach, such as
the Bahamas, was considered and ruled out. It does not seem that an
off-shore registration poses substantial benefits and would certainly
make it appear that the IETF administrative support organization
perhaps had something to hide. This is clearly not appropriate.
Incorporating simultaneously in several jurisdictions to make the
point that the IETF is not part of any one country was also
considered. As appealing as this is in theory, in practice it
substantially increases the cost of incorporation, the complexity of
on-going operations, and exposes the IETF administrative support
organization to liability in multiple legal jurisdictions.
After weighing a number of issues, it appears that the Netherlands,
Switzerland, and the United States make the most sense.
Either of these three jurisdictions would work. The IETF has strong
participation from the Netherlands, and a number of nonprofit
Internet groups have thrived in this environment. By contrast, we
have far fewer participants from Switzerland. However, because
Switzerland is not part of the European Union, it does not suffer
from the potential risks of the more activist governmental presence
in the EU and in the US.
A U.S. non-profit, non-member corporation is being recommended under
Scenario C, but with an important proviso. This recommendation is
based on simple considerations of expediency and pragmatism: a
transition will be simplest and least risky (in the short term).
Since there are enough issues on the table, it seems easiest to
simplify the equation by taking this variable out. The reasoning is
as follows:
o Administrative support for the IETF is currently enmeshed in a
series of relationships with other institutions, most of which are
also U.S.-chartered non-profit organizations. Any change in the
institutional status of administrative support functions will
require familiarity with U.S. nonprofit law. Incorporation in
another country would require familiarity with those laws as well.
Thus, the incorporation expenses would be higher and the process
would take longer.
o U.S. law has a strong concept of "nexus," which is a
determination of when a foreign organization has enough
relationship to U.S. law to fall under the jurisdiction of a U.S.
court. Because of a long history of operating in the U.S.,
numerous meetings in the U.S., and the large number of U.S.
residents who are participants and leaders, we feel it is likely
Malamud Expires February 23, 2005 [Page 36]
Internet-Draft Administrative Support Analysis August 2004
that U.S. courts would find nexus in relation to our US-based
activities, even if the IETF administrative support organization
was incorporated in another country. In other words,
incorporating in a country besides the U.S. does not necessarily
free the support organization from any perceived vagaries of U.S.
law.
o Incorporating in a country other than the US may have tax
implications if the Internet Society is providing funding support.
o U.S. corporations have traditionally been large contributors to
the development of public aspects of the Internet, a category into
which IETF activities fall (and consequently, the activities of an
IETF administrative support organization fall). U.S.
corporations are somewhat chauvinistic, and it is our experience
in raising funds that it is easier to get a donation if the
recipient is a duly-chartered U.S. tax-exempt organization. Not
surprisingly, non-U.S. corporations have shown more flexibility
in this regard. Note that under this scenario, the Internet
Society would take primary responsibility for fund-raising,
however deductibility of donated resources such as computers and
bandwidth is still useful.
o It is very likely that an IETF administrative support organization
would be deemed to clearly fall under the "scientific" and
"educational" grounds for classification as a tax-exempt charity
under section 501(c)(3) of the IRS code, so a tax-exempt
application should be quite straight-forward.
o The incorporation laws of the U.S. states being considered do not
require that any members of the Board of Trustees be of a certain
nationality or state residency (e.g., there are no "local
director" requirements). The U.S. Dept. of Commerce
foreign-controlled organization reporting requirements apply only
to "business enterprises", and do not apply to non-profit entities
such as an IETF administrative support organization.
That said, it should be stated very clearly that any of the three
incorporation domiciles (Switzerland, Netherlands, and U.S.) could
probably be made to work. If the community feels a further in-depth
examination of alternative domiciles is in order, and is willing to
bear the increased costs of time and money, alternative domiciles
could be more carefully examined.
If incorporating in the U.S., Virginia seems a logical pick as the
state of domicile to allow the IETF administrative support
organization to make use of ISOC headquarters to house its single
employee (though the employee might be able to be housed at the
Internet Society even if the incorporation were elsewhere, for
example the ISOC Geneva office). A variety of other options were
examined as states of incorporation, including [Delaware] and
[California], but there appeared to be no significant advantages. In
Malamud Expires February 23, 2005 [Page 37]
Internet-Draft Administrative Support Analysis August 2004
particular, there are no significant differences in issues such as
director liability that would make incorporating outside the place of
actual domicile attractive.
4.4.1.2 Sample Draft Core Principles
[ed.: This section intends to state basic principles of establishment
and governance, suitable for publication, after considerable
discussion, as a procedural Best Current Practice document.]
4.4.1.2.1 Sample Draft Principles of Establishment and Governance
The following principles are proposed for the establishment and
governance of an administrative support organization in support of
the IETF under Scenario C, and are based on the Sample Draft Articles
of Incorporation attached in Appendix D.1 and the Sample Draft Bylaws
attached in Appendix D.2:
1. The name of the organization shall be the IETF Foundation.
2. The IETF Foundation shall be incorporated under the laws of the
State of the Virginia in the United States as a non-stock
corporation with a domicile in the State of Virginia and shall
apply for exemption from U.S. taxation under section 501(c)(3)
of the Internal Revenue Code of the United States.
3. The IETF Foundation shall have no members or shareholders.
4. The IETF Foundation shall be governed by a Board of Trustees, who
shall be responsible for the fiscal, legal, and administrative
infrastructure that support the activities of the IETF. The
governance of the IETF, the standards process, and all other
aspects of how we make our standards are defined in the
procedural Best Current Practice RFC series, which will be
explicitly referenced in the organization documents of the IETF
Foundation.
5. The Board of Trustees shall consist of a fixed, odd number of
members, initially set at 7 members.
6. The annual meeting of the Board of Trustees of the IETF
Foundation shall be announced on the IETF mailing list at least
30 days before it occurs and must be held at a regular IETF
meeting. This meeting shall be open to IETF attendees and
minutes shall be promptly posted on-line.
7. The Board of Trustees shall appoint a Secretary and a Treasurer,
who need not be members of the Board of Trustees. The
Administrative Director of the IETF Foundation shall provide
staff support to the Board of Trustees.
8. The Board of Trustees shall be composed to strike a balance
between outside and "inside" directors. It is proposed that the
IETF and IAB chairs hold voting, ex-officio seats, and that
mechanisms such as the Nominating Committee and the appointment
of certain seats by the Internet Society fulfill the outside
Malamud Expires February 23, 2005 [Page 38]
Internet-Draft Administrative Support Analysis August 2004
director obligations.
The Board of Trustees would have strong governance over a limited
scope of activities (e.g., the fiscal, legal, and administrative
infrastructure that are the charter of the IETF Foundation) but would
have no authority over the IETF standards process. In this board
composition, the ISOC and Nomcom appointments insure that outside
directors with no perceived conflicts of interest are on the board.
All nominating bodies should make strong fiscal, legal, and
administrative acumen essential selection criteria for this position.
However, we should note strongly that the Chairs of the IAB and IETF
are ex-officio members (e.g., they are full voting members who hold
the position based on their official roles as chairs of these two
bodies), and that it is not expected that the current criteria for
selection of these two positions should be changed.
For position-based appointments such as the IETF Chair, the Trustee
would serve concurrent with their normal appointment. For non
position-based appointments, a term proposed for the nominated
positions is three years with staggered appointments. However, the
nominating body might have the power to change their appointee during
their term.
All members of the Board of Trustees IETF Foundation are subject to
the same recall procedures in effect for the IETF leadership such as
members of the IAB and IESG. [[anchor31: Mike St. Johns comments
that use of the Nomcom and the recall procedure are both
inappropriate as they are tailored towards selection of and recall of
technical leadership, which is not necessarily appropriate for the
fiscal, legal, and administrative skill sets needed in a board for
the Foundation. --Mike St. Johns]]
4.4.1.2.2 Sample Draft Principles of Operation of a Potential IETF
Foundation
[ed.: This section intends to state basic principles of establishment
and governance, suitable for publication, after considerable
discussion, as a procedural Best Current Practice document. This
section is very tentative and contains principles that are used to
draft bylaws and articles of corporation, samples of which are shown
in Appendix D.1 and Appendix D.2.]
The following are some general principles for the operation of the
IETF Foundation:
1. The IETF Foundation shall employ a Administrative Director of the
IETF Foundation, who shall be hired by the Board of Trustees with
the the advice and consent of the IESG and IAB.
Malamud Expires February 23, 2005 [Page 39]
Internet-Draft Administrative Support Analysis August 2004
2. All support services shall be contracted in an open and
transparent manner.
3. The Administrative Director shall submit a proposed annual budget
to the Board of Trustees at least 90 days before the beginning of
the fiscal year. Such budget shall be developed with the advice
and consent of the IAB and IESG.
4. The Administrative Director shall serve on the Board of Trustees
as a non-voting, ex-officio member.
5. The Board of Trustees shall select a professional audit firm and
shall commission an audit immediately upon the close of each
fiscal year.
6. The IETF Foundation will conduct financial reporting in a fully
transparent fashion. Audits shall be conducted promptly and
published. Tax returns shall be published. Detailed financial
statements will be published on a regular basis, including timely
reports on the financial results of IETF meetings.
4.5 Scenario D: Autonomous Entity
Scenario D has much of the same analysis as for Scenario C. However,
in this scenario, instead of a mutually-beneficial symbiotic whole,
the IETF Foundation sets out to ensure its own viability independent
of the Internet Society. For instance, the foundation might pursue
direct contributions from industry instead of relying on a unified,
ISOC-based fund raising effort as outlined in Scenario C.
Needless to say, direct solicitation of funds would require great
care to isolate the IETF standards process from funding agencies so
that there can be no question of undue influence. In Scenarios A
through C, this isolation of process from funding is provided by the
Internet Society.
Malamud Expires February 23, 2005 [Page 40]
Internet-Draft Administrative Support Analysis August 2004
5. Future Work
5.1 Short-Term
This report outlines some fundamental decisions facing the IETF
community about how administrative support functions should be
procured and what institutional framework they should be housed in.
If a consensus is reached on a direction to move on these key
decisions, a number of short-term tasks will be required:
1. Formulation of a budget for 2005, including a cash flow analysis.
2. If formal incorporation is chosen, drafting and filing of bylaws
and articles. If an operating unit is chosen, drafting of any
memoranda of understanding.
3. If a decision is made to negotiate a sole source contract for one
or more functions, a negotiating team would need to be appointed.
4. If a decision is made to issue a Request for Proposal for one or
more functions, a drafting team would need to be appointed and a
process for evaluation described.
5. If a decision is made to appoint an Administrative Director, a
call for applicants would need to be issued.
5.2 Long-Term
While [RFC3716] set out principles for administrative restructuring,
it should be remembered that administrative restructuring is just one
of the tasks facing the IETF. [RFC3774] set out a number of
fundamental issues facing the community. Any administrative
restructuring should be performed quickly and efficiently, allowing a
renewed focus on more important issues, such as how the IETF can
remain and become "an open global community of network designers,
operators, vendors, and researchers producing technical
specifications for the evolution of the Internet architecture and the
smooth operation of the Internet."[RFC3233]
Much of that focus on "more important issues" is already present in
the IETF today. Working Groups such as [NEWTRK] and [ICAR] are
looking hard at the basic IETF processes and how they can be made
better.
In considering the future, it is often worth looking at the past.
Edwin T. Layton, Jr., in his 1986 study of the rise (and fall) of
standards bodies in 1900's, tells of an interesting group, the
Institute of Radio Engineers (IRA). Founded in 1912, the IRA was
different from other professional bodies of the time, with a focus on
individual instead of corporate membership, an adherence to
engineering excellence, and, despite being a predominantly American
body, insisting that the word "American" not be added to the IRE's
name as a way of emphasizing the international nature of their
Malamud Expires February 23, 2005 [Page 41]
Internet-Draft Administrative Support Analysis August 2004
pursuits.[Layton] The IRA was founded in reaction to dissatisfaction
with a more formal body of the time, the American Institute of
Electrical Engineers (AIEE). The IRA became known for pioneering
work in standards area such as FM and commercial black-and-white and
color television. Although the IRA was one of the smaller standards
bodies, it was one of the most effective.[Hoffman] In 1963, the IRA
merged with the AIEE to become the IEEE.
Layton's study of professional societies and standards bodies in the
engineering profession from early the 1900 to the 1960s is highly
instructive, particularly the way different groups dealt with the
tensions between the role of participants as individuals engineers
versus their other roles as corporate employees or representatives of
countries. The long-term relevance of the IETF is directly tied to
the ability of the community to focus on core values such as "rough
consensus and running code"[RFC1958] and an avoidance of
entanglements at layers 8-10 of the OSI Reference Model.[OSI]
As Thomas Huxley once commented in describing the conduct of the
affairs of the Royal Society, "our business was (precluding matters
of theology and state affairs) to discourse and consider of
philosophical enquiries, and such as related thereunto."[Huxley] The
IETF can certainly learn much from an examination of it's own guiding
principles and by examining the history of other SDOs such as the
Royal Society and the Institute of Radio Engineers.
Malamud Expires February 23, 2005 [Page 42]
Internet-Draft Administrative Support Analysis August 2004
6. IANA Considerations
[RFC2434] states each Internet-Draft should contain an "IANA
Considerations" section. [RFC3716] noted that a frequent problem for
the IANA is documents that do not contain such a section, thus
requiring a full scan of the document.
This submission contains no specific modifications to existing
registries or creation of new registries. However, the submission
contains a number of sections that may impact the overall operation
of the IANA. A full scan of the document is thus recommended.
Malamud Expires February 23, 2005 [Page 43]
Internet-Draft Administrative Support Analysis August 2004
7. Security Considerations
Improper formulation of the legal framework underlying the IETF may
expose the institution and individuals in leadership positions to
potential legal risks. Any such risk under this plan appears to be
equivalent to the risk faced by the community under the current legal
framework. This risk is further mitigated by a thorough review by
legal counsel, and by use of insurance coverage.
The legal exposure is best minimized by a careful adherence to our
procedures and processes, as defined by the Best Current Practice
Series. A carefully stated process, such as the BCP documents that
govern the selection of leadership positions and define the standards
process are the best insurance against legal exposure, provided care
is taken to stick to the process standards that have been set.
Adherence to a public rule book and a fully open process are the most
effective mechanisms the IETF community can use.
Improper management controls and procedures or other imprudent fiscal
or administrative practices could expose the IETF to a risk of
insolvency. Careful selection of trustees, a process of budget
approval, and a methodical system of fiscal controls are necessary to
minimize this risk.
Malamud Expires February 23, 2005 [Page 44]
Internet-Draft Administrative Support Analysis August 2004
8. Acknowledgment of CNRI Contribution to the IETF Community
As this plan proposes a transition from the past to the future, the
author feel it is essential to acknowledge the enormous contributions
made to the IETF and the Internet by the Corporation for National
Research Initiatives (CNRI) and their Chairman, CEO, and President,
Dr. Robert E. Kahn.
Dr. Kahn's pioneering early leadership in the evolution of the
Internet is well-known, including the seminal paper on the
Transmission Control Protocol,[Cerf and Kahn] his key operational
role in engineering the early Internet (see, e.g., [RFC0371]), and
his leadership of the vastly influential DARPA Information Processing
Techniques Office (IPTO), where he initiated a billion-dollar
Strategic Computing Program which was responsible for funding,
guiding, and encouraging technology that makes up much of today's
infrastructure.
Perhaps less well-known or appreciated is the contribution that Dr.
Kahn and CNRI have made to the evolution of the IETF. Since 1987,
CNRI has housed the IETF Secretariat, supporting 56 IETF meetings
with over 55,000 total attendees, not to mention over 30,000
Internet-Drafts processed, several thousand teleconferences hosted,
and a theoretically finite but practically uncountable number of
cookies consumed.
CNRI's support allowed the IETF community to evolve in the way it
has. Many of the values we have created as a community were possible
only possible because we had a professional secretariat to provide
support. For example, the IETF takes very seriously the idea that
individuals, not institutions or countries, are the participants (not
members) in the process. A stable secretariat has allowed us to
preserve those values without worrying about pesky issues such as
corporate sponsorship or membership fees.
A number of CNRI and Foretec staff have formed the secretariat over
the years. These people have all worked long and hard and, for many
IETF participants, these staff have been instrumental in making the
IETF an effective forum for the development of Internet standards and
technology. They deserve our sincere and continuing thanks.
As the IETF has scaled, we have continued to rely on CNRI to provide
a base of stability. As the IETF passes the age of 18, it is time
for the IETF to take responsibility for its own affairs.
Malamud Expires February 23, 2005 [Page 45]
Internet-Draft Administrative Support Analysis August 2004
9. Acknowledgment of Contributions and Reviews
A number of people contributed their time in telephone interviews,
email exchanges, and reviews of the draft. These exchanges resulted
in many useful suggestions. Needless to say, our acknowledgment of
their contribution should not in any way be used to necessarily infer
support for anything contained herein. These individuals include:
Bernard Aboba, Harald Alvestrand, Fred Baker, Bob Braden, Scott
Bradner, Brian Carpenter, David Clark, Jorge Contreras, Dave Crocker,
Steve Crocker, Joao Damas, Leslie Daigle, Lynn DuVal, Patrik
Falstrom, Bill Fenner, Ted Hardie, Bob Hinden, Paul Hoffman, Geoff
Huston, Mike St. Johns, David Kessens, Robert Kahn, Daniel
Karrenberg, John Klensin, Rebecca Malamud, Allison Mankin, Thomas
Narten, Jun Murai, Thomas Narten, Eric Rescorla, Pete Resnick, Joyce
Reynolds, Lynn St. Amour, Mike St. Johns, Paul Vixie, Margaret
Wasserman, and Bert Wijnen. The author apologizes for any names
inadvertently omitted.
This document was created with "xml2rfc" as specified in [RFC2629].
Malamud Expires February 23, 2005 [Page 46]
Internet-Draft Administrative Support Analysis August 2004
10. References
10.1 Normative References
[RFC1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996.
[RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines
and Procedures", BCP 8, RFC 2014, October 1996.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in
the IETF Standards Process", BCP 11, RFC 2028, October
1996.
[RFC2031] Huizer, E., "IETF-ISOC relationship", RFC 2031, October
1996.
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
RFC 2223, October 1997.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2555] Braden, R., Reynolds, J., Crocker, S., Cerf, V., Feinler,
J. and C. Anderson, "30 Years of RFCs", RFC 2555, April
1999.
[RFC2850] Internet Architecture Board and B. Carpenter, "Charter of
the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
May 2000.
[RFC2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860, June 2000.
[RFC3005] Harris, S., "IETF Discussion List Charter", BCP 45, RFC
3005, November 2000.
[RFC3184] Harris, S., "IETF Guidelines for Conduct", BCP 54, RFC
3184, October 2001.
Malamud Expires February 23, 2005 [Page 47]
Internet-Draft Administrative Support Analysis August 2004
[RFC3233] Hoffman, P. and S. Bradner, "Defining the IETF", BCP 58,
RFC 3233, February 2002.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3667, February 2004.
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
[RFC3677] Daigle, L. and Internet Architecture Board, "IETF ISOC
Board of Trustee Appointment Procedures", BCP 77, RFC
3677, December 2003.
[RFC3683] Rose, M., "A Practice for Revoking Posting Rights to IETF
mailing lists", BCP 83, RFC 3683, February 2004.
[RFC3710] Alvestrand, H., "An IESG charter", RFC 3710, February
2004.
[RFC3716] Advisory, IAB., "The IETF in the Large: Administration and
Execution", RFC 3716, March 2004.
[RFC3774] Davies, E., "IETF Problem Statement", RFC 3774, May 2004.
[RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and
Recall Process: Operation of the Nominating and Recall
Committees", BCP 10, RFC 3777, June 2004.
10.2 Informative References
[.] Malamud, C., Ed., "IETF Administrative Support Functions",
draft-malamud-consultant-report-00 (work in progress),
August 2004, <http://public.resource.org/adminrest/>.
[Bingo] Anonymous, "Buzzword Bingo", 1996,
<http://hacks.mit.edu/Hacks/by_year/1996/gore/>.
[CNRI-2002]
CNRI, "Form 990 - Return of Organization Exempt from
Income Tax - 2002", EIN 52-1447747, November 2003.
[California]
State of California, "California Corporations Code",
Undated,
<http://www.leginfo.ca.gov/cgi-bin/calawquery?codesection=corp>
.
[Cerf and Kahn]
Malamud Expires February 23, 2005 [Page 48]
Internet-Draft Administrative Support Analysis August 2004
Cerf, V. and R. Kahn, "A Protocol for Packet Network
Intercommunication", IEEE Trans. on Comm., Vol. COM-23,
pp. 637-648, May 1974.
[Delaware]
State of Delaware, "Title 8. Corporations -- Chapter 1.
General Corporation Law -- Subchapter 1. Formation",
Undated,
<http://www.delcode.state.de.us/title8/c001/sc01/index.htm#TopOfPage>
.
[FASB-117]
FASB, "Financial Statements of Not-For-Profit
Organizations", FASB 117, June 1993,
<htttp://www.fasb.org/st/summary/stsum117.shtml>.
[Hoffman] IEEE Center for the History of Electrical Engineering,
"The Origins of the IEEE", 1984,
<http://www.ieee.org/organizations/history_center/historical_articles/history_of_ieee.html>
.
[Huxley] Huxley, T., "On the Advisableness of Improving Natural
Knowledge (A Lay Sermon Delivered in St. Martin's Hall)",
Project Gutenberg THX1410, Fortnightly Review 3 (1866):
626-37, January 1866,
<http://etext.library.adelaide.edu.au/cgi-bin/pg-html/mirror/pg/etext01/thx1410.txt>
.
[I-D.alvestrand-ietf-mission]
Alvestrand, H., "A Mission Statement for the IETF",
draft-alvestrand-ietf-mission-02 (work in progress), June
2004.
[I-D.daigle-adminrest]
Daigle, L., "A Proposal for IETF Administrative
Restructuring", draft-daigle-adminrest-00 (work in
progress), February 2004.
[I-D.ietf-problem-process]
Davies, E. and J. Hofmann, "IETF Problem Resolution
Process", draft-ietf-problem-process-04 (work in
progress), January 2004.
[I-D.ietf-xmpp-core]
Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", draft-ietf-xmpp-core-24 (work in
progress), May 2004.
Malamud Expires February 23, 2005 [Page 49]
Internet-Draft Administrative Support Analysis August 2004
[I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-00 (work in
progress), August 2004.
[I-D.rfc-editor-rfc2223bis]
Reynolds, J. and R. Braden, "Instructions to Request for
Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-07
(work in progress - do not cite as a normative reference),
August 2003,
<http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-07.txt>
.
[ICAR] The IETF, "Charter of the Improved Cross-Area Review
(icar) Working Group", June 2004,
<http://www.ietf.org/html.charters/icar-charter.html>.
[IETF-2001]
Alvestrand, H., "The Financials of the IETF -- 2001",
February 2003,
<http://www.alvestrand.no/ietf/chair/financials.html>.
[IETF-2002]
Alvestrand, H., "The Financials of the IETF -- 2002", July
2003,
<http://www.alvestrand.no/ietf/chair/financials-2002.html>.
[IETF-2003]
Alvestrand, H., "The Financials of the IETF -- 2003", May
2004,
<http://www.alvestrand.no/ietf/chair/financials-2003.html>.
[IETF-2004]
Alvestrand, H., "The IETF Budget -- 2004", May 2004,
<http://www.alvestrand.no/ietf/chair/budget-2004.html>.
[IRS] U.S. Code, "Title 26, Sec. 501: Exemption from tax on
corporations, certain trusts, etc.", Undated,
<http://www4.law.cornell.edu/uscode/26/501.html>.
[ISOC-2002]
Internet Society, "Form 990 - Return of Organization
Exempt from Income Tax - 2002", EIN 52-1650477, October
2003.
[ISOC-2004]
Internet Society, "37th Board of Trustees meeting of the
Malamud Expires February 23, 2005 [Page 50]
Internet-Draft Administrative Support Analysis August 2004
Internet Society", Resolution 3-20, December 2003, <http:/
/www.isoc.org/isoc/general/trustees/mtg37.shtml>.
[Layton] Layton, E., "The Revolt of the Engineers", The John
Hopkins University Press, ISBN 0-8018-3287-X, 1986.
[NEWTRK] The IETF, "Charter of the New IETF Standards Track
Discussion (newtrk) Working Group", June 2004,
<http://www.ietf.org/html.charters/newtrk-charter.html>.
[OSI] Wikepedia, "Open Systems Interconnection Reference Model",
ISO/IEC 7498-1, August 2004,
<http://en.wikipedia.org/wiki/OSI_seven-layer_model>.
[RFC-SOW] Internet Society, "Statement of Work--RFC Editor",
Undated,
<http://www.isoc.org/standards/rfceditor/sow.shtml>.
[RFC0015] Carr, C., "Network subsystem for time sharing hosts", RFC
15, September 1969.
[RFC0371] Kahn, R., "Demonstration at International Computer
Communications Conference", RFC 371, July 1972.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[Virginia]
State of Virginia, "Title 13.1: Corporations, Limited
Liability Companies, Business Trusts", Undated,
<http://leg1.state.va.us/cgi-bin/legp504.exe?000+cod+TOC1301000>
.
Malamud Expires February 23, 2005 [Page 51]
Internet-Draft Administrative Support Analysis August 2004
URIs
[1] <http://www.isoc.org/standards>
[2] <http://www.xmpp.org/>
[3] <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.iana.org%2F&charset=%28detect+automatically%29&doctype=%28detect+automatically%29>
[4] <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.rfc-editor.org%2F&charset=%28detect+automatically%29&doctype=%28detect+automatically%29>
[5] <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.isoc.org%2F&charset=%28detect+automatically%29&doctype=%28detect+automatically%29>
[6] <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.ietf.org%2F&charset=%28detect+automatically%29&doctype=%28detect+automatically%29>
[7] <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.iab.org%2F>
[8] <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.irtf.org%2F&charset=%28detect+automatically%29&doctype=%28detect+automatically%29>
[9] <http://www.ietf.org/PASTMEETINGS/IETF-60b.html>
[10] <http://www.ietf.org/PASTMEETINGS/IETF-59b.html>
[11] <http://www.ietf.org/PASTMEETINGS/IETF-58b.html>
[12] <http://www.ietf.org/PASTMEETINGS/IETF-57b.html>
[13] <http://www.ietf.org/PASTMEETINGS/IETF-56B.html>
[14] <http://www.state.va.us/cgi-bin/scc-clerkdl.pl?scc819&Articles_of_Incorporation_-_Nonstock_Corporation>
Author's Address
Carl Malamud (editor)
Memory Palace Press
PO Box 300
Sixes, OR 97476
US
EMail: carl@xxxxxxxxx
Malamud Expires February 23, 2005 [Page 52]
Internet-Draft Administrative Support Analysis August 2004
Appendix A. Consulting Contract
AGREEMENT FOR CONSULTING SERVICES
Contract between CARL MALAMUD AND THE INTERNET SOCIETY
*Contract:*
Carl Malamud (hereafter known as the Consultant) agrees to provide
consulting services to the Internet Engineering Task Force (IETF),
the Internet Architecture Board (IAB) and the Internet Society (ISOC)
subject to the terms and conditions specified below. Under this
agreement, the Consultant is acting as an independent contractor and
assumes all responsibilities for federal and state income taxes,
social security and medicare tax, medical insurance, and other
applicable filings associated with his status.
*Scope:*
The Consultant will provide the following services outlined in
Appendix I. It is anticipated that the responsibilities will require
20 days per month to accomplish the objectives for which said
Consultant was engaged.
Consultant understands and agrees that this Contract is being
executed with a view to supporting the IETF/IAB as it considers
whether, and if so, how, it might wish to restructure for purposes of
future IETF/IAB endeavors. In the performance of this Contract,
Consultant agrees to exercise fair and professional judgment for the
benefit of the IETF/IAB and to treat all existing and/or potential
partners of the IETF/IAB in a fair manner while protecting any
business confidences that each might have.
*Contract Term:*
The contract will begin on 21 June 2004 and end on 21 December 2004.
For services rendered under this contract the Consultant will be paid
a fee of $16,000 per month due and payable at the end of each month
upon receipt of an invoice. Consultant will be required to submit a
monthly accounting of days worked. Should the days worked in any
month exceed 20, no additional fees are due. The contract may only
be extended by written agreement specifying new services, terms, and
conditions as mutually agreed to by both parties.
*Expenses:*
All expenses incurred on behalf of the IETF/IAB or ISOC shall be
billed to ISOC in addition to charges for services provided above.
Such expenses shall include travel, long distance telephone, business
Malamud Expires February 23, 2005 [Page 53]
Internet-Draft Administrative Support Analysis August 2004
meals, and other customary expenses as appropriate. Such expenses
should be authorized by ISOC, after consultation with the IETF and
the IAB Chairs, and in advance of the expenditure.
*Invoicing:*
Consultant shall submit invoices at the end of each month (pro-rated
for June and December). The Internet Society will make best efforts
to make payment within one week of receipt. If consultant worked
less than 20 days, then ISOC may reduce the monthly fee due by 1/20th
of such fee for each day less than 20. Invoices may be submitted
electronically or by mail. The invoices should be addressed to the
Internet Society's Finance Director, Lynn DuVal at the Reston office
(1775 Wiehle Avenue, Suite 102, Reston, VA 20190) or by e-mail at
duval@xxxxxxxxx
*Termination:*
Either party may terminate this Contract by providing ten (10) days
prior written notice sent by e-mail to the addresses noted below.
In addition, should the subject matter addressed in this Contract
become, in whole or in part, the subject matter of any filed or
threatened litigation then either party may terminate this Contract
by providing five (5) days prior written notice sent as per the above
paragraph.
The days of prior written notice above shall be measured from the
date sent.
The Internet Society will be responsible for all fees properly
incurred under this Contract prior to the effective date of
termination.
If such a termination should occur other than at a month-end, then
payment for services shall be paid pro rata, up to 100% of the
monthly rate, at the rate of 1/20th of the monthly services fee per
day worked to termination
*Miscellaneous:*
ISOC does not wish for itself or others to receive any confidential,
proprietary information of any other party without proper permission.
Consequently, Consultant agrees not to use or divulge, in his efforts
relating to this contract, any information in any form, tangible or
intangible, that is the confidential information of any third party,
whether IETF/IAB, any contractor or partner of IETF/IAB, or any other
party, to ISOC or any other party without the express written
Malamud Expires February 23, 2005 [Page 54]
Internet-Draft Administrative Support Analysis August 2004
permission of the party or parties who own or control such
confidential material and without first disclosing such written
permission to ISOC.
Consultant agrees that any tangible or intangible work product that
results from Consultant's efforts under this Contract (whether by
Consultant or a contractor to Consultant) shall be the exclusive
property of ISOC or the IETF/IAB, as appropriate, and this includes,
without limitation, any invention, product, business process, code or
other device or discovery that might now or hereafter be entitled to
protection, registration or ownership under intellectual property
rights regimens such as, but not only, trade secret, patent,
copyright, and trademark.
ISOC may disclose the terms of this Contract to the IETF/IAB or any
other party having an interest in the subject matter hereof that ISOC
deems reasonable.
*Warranties and Indemnities:*
This written agreement constitutes the full agreement between the
parties. No warranties or indemnities are explicitly included or
implied.
*Amendments:*
Amendments to this agreement must be in writing and executed by both
parties.
+---------------------------------+---------------------------------+
| Executed on behalf of The | Executed on behalf of the |
| Internet Society | Consultant |
+---------------------------------+---------------------------------+
| Lynn St. Amour | Carl Malamud |
| | |
| President & CEO | |
| | |
| st.amour@xxxxxxxx | carl@xxxxxxxxx |
| | |
| Date: | Date: |
+---------------------------------+---------------------------------+
*Appendix I: Statement of Work*
The IETF/IAB is considering an Administrative restructuring and has
asked ISOC to support their efforts. The contract to which this is
attached is in furtherance of this endeavor.
Malamud Expires February 23, 2005 [Page 55]
Internet-Draft Administrative Support Analysis August 2004
Consultant shall become familiar with RFC 3716 as the basis for these
efforts and shall use such RFC as a reference point in these efforts
except to the extent that this Contract or any guidance supplied to
Consultant by IETF/IAB or ISOC under this contract supercedes such
RFC.
The types of activities Consultant shall undertake are:
o Assist in researching, recommending and ultimately drafting the
proposed structure/bylaws for the IETF administrative entity;
o Revising proposed structure and/or bylaws based on the public
review, including reviews by counsel;
o Negotiate appropriate contract(s) for RFC Editor and/or other
contractors as a model for eventual use by the IETF administrative
entity;
o Conduct appropriate liaison with the RFC Editor, IANA and
Secretariat to determine the requirements for inter-organizational
document flow matched to overall IETF/IAB process needs.
o Others as reasonably directed by ISOC, IETF and or IAB
Deliverables hereunder shall include:
o Data Flow: a comprehensive set of requirements for implementing
appropriate tracking of IETF/IAB documents and reporting of status
across support organizations.
o Negotiated contracts, per the above, that are acceptable to all
concerned parties and are ready for execution.
o Administrative restructuring: documentation and support, as
appropriate, to the continued evolution of the restructuring
effort, which shall be periodically reviewed by the IAB, IESG and
other appropriate parts of the IETF community of interest.
Malamud Expires February 23, 2005 [Page 56]
Internet-Draft Administrative Support Analysis August 2004
Appendix B. IETF Financial Information
B.1 Consolidated 3-Year Historical Income Statement
(US$)
+------------------+------------+-----------+-----------+-----------+
| | 2001 [1] | 2002 [2] | 2003 [3] | 2004 [4] |
+------------------+------------+-----------+-----------+-----------+
| REVENUE | | | | |
| | | | | |
| CNRI/Foretec | 2,699,239 | 2,350,666 | 2,060,747 | 1,728,125 |
| Meeting Revenue | | | | |
| | | | | |
| Less Bank Fees | 81,365 | 70,309 | 62,826 | 51,844 |
| | | | | |
| Net Meeting | 2,617,874 | 2,280,357 | 1,997,921 | 1,676,281 |
| Revenue | | | | |
| | | | | |
| Contribution By | 535,535 | 550,881 | 614,691 | 663,570 |
| The Internet | | | | |
| Society [5] | | | | |
| | | | | |
| Provision of the | -- | -- | -- | -- |
| IANA function by | | | | |
| ICANN [6] | | | | |
| | | | | |
| Other | -- | -- | -- | 150,000 |
| Contributions | | | | |
| | | | | |
| TOTAL FUNDS | 3,153,409 | 2,831,238 | 2,612,612 | 2,489,851 |
| | | | | |
| | | | | |
| EXPENSE | | | | |
| | | | | |
| ISOC | | | | |
| Expenditures | | | | |
| | | | | |
| RFC Editor | 428,300 | 462,368 | 516,460 | 574,570 |
| | | | | |
| IETF Chair | 73,748 | 52,137 | 51,460 | 48,500 |
| Discretionary | | | | |
| Fund | | | | |
| | | | | |
| IAB Support | 13,287 | 14,446 | 37,270 | 24,500 |
| | | | | |
| Insurance | 20,000 | 21,930 | 13,685 | 16,000 |
| | | | | |
Malamud Expires February 23, 2005 [Page 57]
Internet-Draft Administrative Support Analysis August 2004
| Total ISOC | 535,535 | 550,881 | 614,691 | 663,570 |
| Expenditures | | | | |
| | | | | |
| | | | | |
| CNRI/Foretec | | | | |
| Expenditures | | | | |
| | | | | |
| Secretariat | 504,584 | 625,124 | 532,936 | 478,000 |
| Labor | | | | |
| | | | | |
| IETF Meeting | | | | |
| Costs | | | | |
| | | | | |
| Food & Beverage | 862,500 | 705,610 | 513,081 | 487,500 |
| | | | | |
| Audio/Visual | 127,337 | 83,239 | 96,902 | 60,000 |
| | | | | |
| Room Rental | 190,265 | 172,907 | 125,187 | 170,000 |
| | | | | |
| Terminal Room | -- | -- | 66,294 | 25,000 |
| | | | | |
| Other Meeting | 1,925 | 8,340 | 13,367 | 6,000 |
| Costs | | | | |
| | | | | |
| Total IETF | 1,182,027 | 970,096 | 814,831 | 748,500 |
| Meeting Costs | | | | |
| | | | | |
| | | | | |
| Non-Meeting | | | | |
| Costs | | | | |
| | | | | |
| Travel | 39,122 | 53,838 | 78,947 | 75,000 |
| | | | | |
| Materials | 7,318 | 11,724 | 9,706 | 10,700 |
| | | | | |
| Printing & | 59,431 | 31,459 | 14,266 | 12,000 |
| Publication | | | | |
| | | | | |
| Professional | 24,581 | 61,105 | 12,288 | 9,000 |
| Services | | | | |
| | | | | |
| Telecommunicatio | 54,400 | 82,210 | 32,582 | 42,000 |
| ns | | | | |
| | | | | |
| Misc. | 12,003 | 577 | -- | 4,000 |
| | | | | |
| Equipment Rental | 4,668 | 736 | 1,630 | 2,500 |
| | | | | |
Malamud Expires February 23, 2005 [Page 58]
Internet-Draft Administrative Support Analysis August 2004
| Total | 201,523 | 241,650 | 149,419 | 155,200 |
| Non-Meeting | | | | |
| Costs | | | | |
| | | | | |
| | | | | |
| Total | 1,888,134 | 1,836,870 | 1,497,186 | 1,381,700 |
| CNRI/Foretec | | | | |
| "Direct" | | | | |
| Expenses | | | | |
| | | | | |
| | | | | |
| CNRI/Foretec | 604,990 | 608,805 | 641,939 | 504,560 |
| Overhead Charge | | | | |
| | | | | |
| CNRI/Foretec | 30,000 | -- | -- | -- |
| "Performance | | | | |
| Bonus" | | | | |
| | | | | |
| | | | | |
| Total | 2,124,523 | 2,445,675 | 2,139,125 | 1,886,260 |
| CNRI/Foretec | | | | |
| Expenses | | | | |
| | | | | |
| | | | | |
| TOTAL EXPENSES | 2,660,058 | 2,996,556 | 2,753,816 | 2,549,830 |
| (ISOC and CNRI) | | | | |
| | | | | |
| | | | | |
| SURPLUS/DEFICIT | 94,750 | (165,318) | (141,204) | (59,979) |
+------------------+------------+-----------+-----------+-----------+
Notes:
[1] Actual results based on unaudited reports. Source: [IETF-2001]
[2] Actual results based on unaudited reports. Source: [IETF-2002]
[3] Actual results based on unaudited reports. Source: [IETF-2003]
[4] Budgeted. Source: [IETF-2004]
[5] ISOC manages expenditures directly. The revenue line here
represents funds allocated by the ISOC Board of Trustees for the
purpose of IETF support. The figures in this line equal their
corresponding cells for Total ISOC Expenditures.
[6] ICANN does not report expenses broken down by functional area,
nor are the direct and indirect costs associated with the IETF
parameter registries available. We thus value this contribution
as "priceless" for purposes of this analysis.
B.2 Internet Society 2004 Budget Summary
The Internet Society 2004 Budget was approved at a Special
Malamud Expires February 23, 2005 [Page 59]
Internet-Draft Administrative Support Analysis August 2004
Teleconference Meeting of the Internet Society Board of
Trustees.[ISOC-2004] All figures are in U.S. dollars.
+------------------+------------+-----------+-----------+-----------+
| | Standards | Education | Public | Total |
| | Pillar | Pillar | Policy | |
| | | | Pillar | |
+------------------+------------+-----------+-----------+-----------+
| REVENUE | | | | |
| | | | | |
| Organizational | 1,050,000 | 242,000 | 200,000 | 1,492,000 |
| and Platinum | | | | |
| Membership | | | | |
| | | | | |
| Individual | | | 52,500 | 52,500 |
| Membership | | | | |
| | | | | |
| Conferences | | 145,000 | | 145,000 |
| (INET, NDSS) | | | | |
| | | | | |
| .org Program | 900,000 | 450,000 | 550,000 | 1,900,000 |
| Revenue | | | | |
| | | | | |
| Other | 155,000 | | | 155,000 |
| (Contributions | | | | |
| and Security | | | | |
| Expert | | | | |
| Initiative | | | | |
| | | | | |
| TOTAL REVENUE | 2,105,000 | 837,000 | 802,500 | 3,744,500 |
| | | | | |
| | | | | |
| EXPENSE | | | | |
| | | | | |
| ISOC Salaries | 371,337 | 364,623 | 458,128 | 1,194,088 |
| and Related | | | | |
| Costs | | | | |
| | | | | |
| IETF Staff | 10,000 | | | 10,000 |
| Travel | | | | |
| | | | | |
| RFC Editor | 574,570 | | | 574,570 |
| | | | | |
| IETF and IAB | 89,000 | | | 89,000 |
| Support and | | | | |
| Insurance | | | | |
| | | | | |
| IETF | 709,000 | | | 709,000 |
Malamud Expires February 23, 2005 [Page 60]
Internet-Draft Administrative Support Analysis August 2004
| Restructuring | | | | |
| Project | | | | |
| | | | | |
| Conference | | 100,000 | | 100,000 |
| Expense | | | | |
| | | | | |
| Professional | 12,500 | 20,000 | 4,000 | 36,500 |
| Services, | | | | |
| Travel, Misc. | | | | |
| | | | | |
| External Costs: | 40,000 | 89,400 | 70,000 | 199,400 |
| .org | | | | |
| | | | | |
| External Costs: | 70,000 | 42,181 | | 112,181 |
| SEINIT & Sida | | | | |
| | | | | |
| | | | | |
| TOTAL DIRECT | 1,876,407 | 616,204 | 532,128 | 3,024,739 |
| EXPENSE | | | | |
| | | | | |
| G&A/GOVERNANCE | 192,026 | 188,555 | 236,908 | 617,489 |
| | | | | |
| TOTAL EXPENSE | 2,068,433 | 804,759 | 769,036 | 3,642,228 |
| | | | | |
| | | | | |
| SURPLUS | 36,567 | 32,241 | 33,464 | 102,272 |
+------------------+------------+-----------+-----------+-----------+
Malamud Expires February 23, 2005 [Page 61]
Internet-Draft Administrative Support Analysis August 2004
Appendix C. 10-Year Meeting Attendance Summary
+------------+------------+-------------+-------------+-------------+
| IETF | DATE | Location | Host | Attendees |
+------------+------------+-------------+-------------+-------------+
| 60th IETF | 01/08/2004 | San Diego, | -- | 1511 |
| [9] | | CA, USA | | |
| | | | | |
| 59th IETF | 29/02/2004 | Seoul, | -- | 1390 |
| [10] | | South Korea | | |
| | | | | |
| 58th IETF | 09/11/2003 | Minneapolis | -- | 1233 |
| [11] | | , MN, USA | | |
| | | | | |
| 57th IETF | 13/07/2003 | Vienna, | -- | 1304 |
| [12] | | Austria | | |
| | | | | |
| 56th IETF | 16/03/2003 | San | -- | 1679 |
| [13] | | Francisco, | | |
| | | California, | | |
| | | USA | | |
| | | | | |
| 55th IETF | 17/11/2002 | Atlanta, | Nokia | 1570 |
| | | Georgia, | | |
| | | USA | | |
| | | | | |
| 54th IETF | 14/07/2002 | Yokohama, | Fujitsu; | 1885 |
| | | Japan | The WIDE | |
| | | | Project | |
| | | | | |
| 53rd IETF | 17/03/2002 | Minneapolis | Cable & | 1656 |
| | | , | Wireless | |
| | | Minnesota, | | |
| | | USA | | |
| | | | | |
| 52nd IETF | 09/12/2001 | Salt Lake | Novell | 1691 |
| | | City, Utah, | | |
| | | USA | | |
| | | | | |
| 51st IETF | 05/08/2001 | London, | BTexact | 2226 |
| | | England | Technologie | |
| | | | s | |
| | | | | |
| 50th IETF | 18/03/2001 | Minneapolis | Lucent | 1822 |
| | | , MN, USA | Technologie | |
| | | | s | |
| | | | | |
| 49th IETF | 10/12/2000 | San Diego, | Cisco | 2810 |
Malamud Expires February 23, 2005 [Page 62]
Internet-Draft Administrative Support Analysis August 2004
| | | CA, USA | Systems; | |
| | | | Qualcomm | |
| | | | | |
| 48th IETF | 31/07/2000 | Pittsburgh, | Marconi | 2344 |
| | | PA, USA | | |
| | | | | |
| 47th IETF | 26/03/2000 | Adelaide, | connect.com | 1431 |
| | | Australia | .au | |
| | | | | |
| 46th IETF | 07/11/1999 | Washington, | Nortel | 2379 |
| | | DC, USA | Networks, | |
| | | | Inc | |
| | | | | |
| 45th IETF | 11/07/1999 | Oslo, | Uninett | 1710 |
| | | Norway | | |
| | | | | |
| 44th IETF | 14/03/1999 | Minneapolis | Ascend | 1705 |
| | | , MN, USA | Communicati | |
| | | | ons | |
| | | | | |
| 43rd IETF | 07/12/1998 | Orlando, | Microsoft | 2124 |
| | | FL, USA | Corporation | |
| | | | | |
| 42nd IETF | 24/08/1998 | Chicago, | Motorola | 2106 |
| | | IL, USA | | |
| | | | | |
| 41st IETF | 30/03/1998 | Los | -- | 1775 |
| | | Angeles, | | |
| | | CA, USA | | |
| | | | | |
| 40th IETF | 08/12/1997 | Washington, | Newbridge | 1897 |
| | | DC, USA | Networks, | |
| | | | Inc | |
| | | | | |
| 39th IETF | 11/08/1997 | Munich, | ISOC-German | 1308 |
| | | Germany | y Chapter | |
| | | | | |
| 38th IETF | 07/04/1997 | Memphis, | Federal | 1321 |
| | | Tennessee, | Express | |
| | | USA | | |
| | | | | |
| 37th IETF | 09/12/1996 | San Jose, | Cisco | 1993 |
| | | California, | Systems | |
| | | USA | | |
| | | | | |
| 36th IETF | 24/06/1996 | Montreal, | -- | 1283 |
| | | Quebec, | | |
| | | CANADA | | |
Malamud Expires February 23, 2005 [Page 63]
Internet-Draft Administrative Support Analysis August 2004
| | | | | |
| 35th IETF | 04/03/1996 | Los | -- | 1038 |
| | | Angeles, | | |
| | | California, | | |
| | | USA | | |
| | | | | |
| 34th IETF | 04/12/1995 | Dallas, | MCI | 1007 |
| | | Texas, USA | | |
| | | | | |
| 33rd IETF | 17/07/1995 | Stockholm, | the Royal | 617 |
| | | Sweden | Institute | |
| | | | of | |
| | | | Technology; | |
| | | | NORDUnet | |
| | | | | |
| 32nd IETF | 03/04/1995 | Danvers, | FTP | 983 |
| | | Massachuset | Software; | |
| | | ts, USA | NEARnet | |
| | | | | |
| 31st IETF | 05/12/1994 | San Jose, | Sun | 1079 |
| | | California, | Microsystem | |
| | | USA | s | |
| | | | | |
| 30th IETF | 25/07/1994 | Toronto, | University | 710 |
| | | Ontario, | of Toronto | |
| | | CANADA | | |
| | | | | |
| 29th IETF | 28/03/1994 | Seattle, | NorthWestNe | 785 |
| | | Washington, | t | |
| | | USA | | |
+------------+------------+-------------+-------------+-------------+
C.1 Analysis of Meeting-Based Expense and Revenue Drivers
+----------------+----------------+----------------+----------------+
| Category | 2001 | 2002 | 2003 |
+----------------+----------------+----------------+----------------+
| Total | 5,739 | 5,111 | 4,216 |
| Attendees | | | |
| | | | |
| Net Meeting | $456 | $446 | $489 |
| Revenue Per | | | |
| Attendee | | | |
| | | | |
| Average Food & | $150 | $138 | $122 |
| Beverage Per | | | |
| Attendee | | | |
Malamud Expires February 23, 2005 [Page 64]
Internet-Draft Administrative Support Analysis August 2004
| | | | |
| Average Total | $206 | $190 | $193 |
| Direct Meeting | | | |
| Cost Per | | | |
| Attendee [1] | | | |
| | | | |
| Total | $370 | $479 | $507 |
| CNRI/Foretec | | | |
| Secretariat | | | |
| Expenses | | | |
| Divided by | | | |
| Number of | | | |
| Meeting | | | |
| Attendees | | | |
+----------------+----------------+----------------+----------------+
Notes:
[1] Room rental fees are typical for non-U.S. meetings. Average
total direct costs will thus be influenced by the choice of
location of meetings.
Malamud Expires February 23, 2005 [Page 65]
Internet-Draft Administrative Support Analysis August 2004
Appendix D. Sample Draft Incorporating Documents for a Hypothetical
IETF Foundation
D.1 Sample Draft Articles of Incorporation
This appendix contains standard, pro-forma Articles of Incorporation.
Note well that tax lawyers often make significant alterations to
standard Articles as they consider a 501(c)(3) application. They are
included here merely as a sample for illustrative purposes only.
'Commonwealth of Virginia -- State Corporation Commission'| 'Articles
of Incorporation -- Virginia Nonstock Corporation'| Form SCC819, 07/
03 [14]
------
The undersigned, pursuant to Chapter 10 of Title 13.1 of the Code of
Virginia, [Virginia] state(s) as follows:
1. The name of the corporation is The IETF Foundation.
2. The corporation shall have no members.
3. The Trustees of the corporation shall be elected or appointed as
specified in Article IV (Appendix D.2.5) of the Bylaws.
4. Name and agent:
A. The name of the corporation's initial registered agent is:
XXX
B. The initial registered agent is a domestic or foreign stock
or nonstock corporation, limited liability company, or
registered limited liability partnership authorized to
transact business in Virginia.
5. The initial Trustees are: XXX
6. The incorporators are: XXX
D.2 Sample Draft Bylaws of the IETF Foundation
As with the Sample Draft Articles, the Sample Draft Bylaws included
here are a pro-forma, standard version. Substantial alteration may
be required as legal counsel reviews the specific nature of an
incorporation.
D.2.1 Article I: Organization
The name of the Corporation shall be The IETF Foundation (which shall
hereinafter be referred to as the "Foundation").
D.2.2 Article II: Purpose
*Section 1: Purpose.* The IETF Foundation shall be operated
exclusively for nonprofit educational, charitable, and scientific
purposes, including, without limitation, the purposes stated in the
Malamud Expires February 23, 2005 [Page 66]
Internet-Draft Administrative Support Analysis August 2004
Foundation's Articles of Incorporation.
*Section 2: Restrictions.* No part of the net earnings of the IETF
Foundation shall inure to the benefit of, or be distributable to,
private persons, except that the Foundation shall be authorized and
empowered to pay reasonable compensation for services rendered, and
to make payments and distributions in furtherance of the purposes set
forth in Article II, Section 1 hereof. Any other provision of these
Bylaws to the contrary notwithstanding, the IETF Foundation shall not
carry on any activities not permitted to be carried on by a
corporation exempt from Federal Income Tax under Section 501(a) and
Section 501(c)(3) of the Code. These Bylaws shall not be altered or
amended in derogation of the provisions of this Section.
D.2.3 Article III: Members
The Foundation shall have no members and no stockholders.
D.2.4 Article IV: Offices
The office of the Foundation shall be as determined from time to time
by the Board of Trustees within or outside of the State of Virginia.
D.2.5 Article V: Board of Trustees
*Section 1: Authority and Responsibilities.* The power, authority,
property, and affairs of the Foundation shall at all times be
exclusively exercised, controlled, and conducted by or under the
authority of the Board of Trustees subject to any limitations set
forth in the Articles of Incorporation and in accordance with the
Virginia Nonstock Corporation Act as it now exists or hereafter may
be amended.
*Section 2: Board of Trustees Composition.* The Board of Trustees
shall consist of seven (7) Trustees.
*Section 3: Types.* There shall be two types of Trustees based on the
reason for their selection: Position-Based Trustees, who are trustees
because they hold some other office (for example IETF Chair) and
Selected Trustees, who are not Position-Based Trustees.
*Section 3: Terms.* The term of office of Position-Based Trustees
shall be co-terminious with the term of the office that qualifies the
individual to be a board member. The term of office of Selected
Trustees shall be three (3) years or until their successors have been
selected and assume office. Selected Trustees may be selected to
serve multiple terms.
Malamud Expires February 23, 2005 [Page 67]
Internet-Draft Administrative Support Analysis August 2004
*Section 4: Selection of the Board of Trustee*
1. *Selection of Position-Based Trustees.* The Chairs of the IETF
and IAB shall be the two Position-Based Trustees. These
individuals are selected by IETF participants using the
procedures set forth in [RFC3777] or its successor.
2. *Selection of Selected Trustees.* Three Selected Trustees shall
be selected by the IETF nominations process (as defined in
[RFC3777] or its successor) and confirmed by the IESG. Two
Selected Trustees shall be selected by the internet Society using
means of their own choosing.
3. *Resignation.* A Selected Trustee may resign by delivering his
resignation in writing to the Foundation at its principal office
or to the Secretary of the Foundation. Such resignation shall be
effective upon its receipt or upon such date (if any) as is
stated in such resignation, unless otherwise determined by the
Board.
4. *Removal.* A Selected Trustee selected by the IETF nominations
process may be removed from office at any time using the
procedures specified in [RFC3777] or its successor. A Selected
Trustee selected by the Internet Society my be removed by the
Internet Society using means of their own choosing.
5. *Vacancies.* Any vacancy in the Board of Trustees shall be filled
using the procedures set forth above on the composition of the
Board of Trustees. The Trustees shall have and may exercise all
of their powers notwithstanding the existence of one or more
vacancies in their number.
*Section 5: Quorum.* A majority of the Trustees shall constitute a
quorum for the transaction of business. Unless otherwise stated in
these Bylaws, decisions of the Board of Trustees shall be made by the
concurrence of a majority of members of the Board of Trustees present
and voting. If at any meeting there is no quorum present, the Board
must not transact business.
*Section 6: Compensation and Reimbursement.* No member of the Board
of Trustees may receive compensation for his or her services as a
Trustee. A Trustee shall, at their request, be reimbursed for
actual, necessary and reasonable travel and subsistence expenses
incurred by them in performance of their duties.
*Section 7: Meetings.* The Board of Trustees shall meet at least
twice annually.
1. *Annual Meeting.* The Board of Trustees shall hold a public
Annual Meeting at a time and place associated with the first IETF
meeting each year. This Annual meeting shall be open to all IETF
attendees except that the parts of the meeting dealing with
personnel issues may be held in executive session.
Malamud Expires February 23, 2005 [Page 68]
Internet-Draft Administrative Support Analysis August 2004
2. *Meeting Types, Methods, and Notice.* Meetings of the Board may
be held from time to time at such intervals and at such places as
may be fixed by the Board. Meetings of the Board may be held
only in person or via teleconference. Notice of all regular
meetings of the Board shall be delivered to each Trustee by
e-mail or by postal mail and announced on the IETF-Announce list
at least ten (10) calendar days before the meeting. Special
meetings of the Board may be called for any purpose at any time
by the Chairman of the Board or by any three (3) Trustees.
Notice of any special meeting shall state the purpose of the
meeting. A Trustee may waive notice of a meeting of the Board of
Trustees by submitting a signed, written waiver of notice, either
before or after the meeting. A Trustee's attendance at or
participation in a meeting waives any required notice of the
meeting unless at the start of such meeting or promptly upon
arrival the Trustee objects to holding the meeting or transacting
business at the meeting, and does not thereafter vote for or
assent to action taken at the meeting.
3. *Actions Taken By the Board of Trustees Without Meeting.* Any
action required or permitted to be taken at any meeting of the
Board of Trustees may be taken without a meeting if all Trustees
consent in writing to such action. Such action shall be
evidenced by written consents approving the lack of a meeting,
signed by each Trustee.
*Section 8: Board Committees.* The Trustees may elect or appoint one
or more committees (including but not limited to an Executive
Committee) and may delegate to any such committee or committees any
or all of their powers, provided that any committee to which the
powers of the Trustees are delegated shall consist solely of
Trustees. Committees shall conduct their affairs in the same manner
as is provided in these By Laws for the Trustees. The members of any
committee shall remain in office at the pleasure of the Board of
Trustees.
*Section 9: Trustee Member Conflict of Interest.*
1. As set forth in Section 9(3) below, a Trustee of the IETF
Foundation who has a personal interest in a transaction, as
defined below, may not participate in any discussion of that
transaction by the Trustees of The IETF Foundation and may not
vote to determine whether to authorize, approve, or ratify that
transaction except as specifically described below. For purposes
of these Bylaws, a "personal interest" is defined as any act that
will provide, directly or indirectly, a financial benefit or a
disparate benefit individually to the Trustee, or to a company he
or she is employed by, has a significant financial interest in,
or represents in any fashion. However, policies under
consideration by the Foundation are likely to have an impact on
Malamud Expires February 23, 2005 [Page 69]
Internet-Draft Administrative Support Analysis August 2004
the business of every Trustee. It is expected that most policy
decisions will have a direct or indirect impact on the Trustee's
company, but such a non-individualized interest does not
constitute a "personal interest" as used in these Bylaws. A
"transaction" with The IETF Foundation for purposes of these
Bylaws is a contract or consultancy in which the Trustee has a
direct or indirect financial benefit, or a policy under
consideration that will have a disparate and unusual impact on a
business with which the Trustee is directly or indirectly
associated.
2. The mere existence of a personal interest by a Trustee of The
IETF Foundation in a transaction with The IETF Foundation shall
not invalidate The IETF Foundation's ability to enter that
transaction so long as the following conditions are met: (i) the
material facts of the personal nature of the transaction with The
IETF Foundation and the Trustee's interest in the transaction
with The IETF Foundation are fully disclosed to the Board of
Trustees of The IETF Foundation, either by the Trustee having a
direct or indirect personal interest in the transaction with The
IETF Foundation, or are brought to the attention of the Board by
a third party; or (ii) the Board of Trustees of The IETF
Foundation, by a vote of the disinterested Trustees of The IETF
Foundation vote to authorize, approve, or ratify a transaction
with The IETF Foundation; or (iii) the transaction with The IETF
Foundation in which the direct or indirect personal interest of
an The IETF Foundation Trustee was disclosed to the Board of
Trustees of The IETF Foundation and was determined by the Board
of Trustees of The IETF Foundation entitled to vote on the matter
is determined by the Board of Trustees voting to be in The IETF
Foundation's interests, notwithstanding the personal interest of
the non-voting Trustee.
3. In determining whether a conflict of interest exists, the Board
of Trustees of The IETF Foundation has the prerogative, upon
review of all facts and circumstances, to make its own
determination of whether a conflict of interest exists and how it
is appropriate to proceed. A Trustee who perceives the
possibility of a conflict of interest for him or herself, or for
another Board member, may raise this issue at any point prior to
a vote on any issue. Any Trustee who perceives a possible
conflict of interest may present justification with respect to
whether or not a conflict of interest exists, but the entire
Board, with the exception of the Trustee having the potential
conflict of interest, shall make the final determination to
proceed in such a matter. If the Board of Trustees finds there
is a conflict of interest, the Trustee with the conflict may be
excluded by the Chair of the Board from that portion of any
meeting where a substantive discussion or decision to engage or
not in such a transaction is made, except that he or she may
Malamud Expires February 23, 2005 [Page 70]
Internet-Draft Administrative Support Analysis August 2004
provide any information that will assist the Trustees in such a
matter before leaving such a meeting.
*Section 10. Approval of Meeting Minutes.* Minutes of the Board of
the IETF Foundation must be approved by a procedure adopted by the
board and published on the IETF Foundation web site.
D.2.6 Article VI: Officers
*Section 1: Number.* The officers of the IETF Foundation shall
consist of a Chairman of the Board, a Treasurer and a Secretary, and
such other inferior officers as the Board of Trustees may determine.
*Section 2: Election Term of Office and Qualifications.* All officers
shall be elected annually by the vote of a majority of the Board of
Trustees present and voting (excluding abstentions) at the Annual
Meeting. The Treasurer and Secretary need not be members of the
Board. The Chair of the IETF nor the chair of the IAB shall be the
Chairman of the Board of the IETF Foundation.
*Section 3: Resignation.* An officer may resign by delivering his
written resignation to the Foundation at its principal office or to
the Chair or Secretary. Such resignation shall be effective upon
receipt or upon such date (if any) as is stated in such resignation,
unless otherwise determined by the Board.
*Section 4: Removal.* The Board of Trustees may remove any officer
with or without cause by a vote of a majority of the entire number of
Trustees then in office, at a meeting of the Board of Trustees called
for that purpose. An officer may be removed for cause only if notice
of such action shall have been given to all of the Trustees prior to
the meeting at which such action is to be taken and if the officer so
to be removed shall have been given reasonable notice and opportunity
to be heard by the Board of Trustees.
*Section 5: Vacancies.* In case any elected officer position of the
IETF Foundation becomes vacant, the majority of the Trustees in
office, although less than a quorum, may elect an officer to fill
such vacancy at the next meeting of the Board of Trustees, and the
officer so elected shall hold office and serve until the next Annual
Meeting.
*Section 6: Chairman of the Board.* The Chairman of the Board shall,
when present, preside at all meetings of the Board of Trustees of
IETF Foundation. If the Chairman is not available to preside over a
meeting, the majority of the Trustees present shall select another
Trustee to preside at that meeting only.
Malamud Expires February 23, 2005 [Page 71]
Internet-Draft Administrative Support Analysis August 2004
*Section 7: Treasurer.* The Treasurer shall have the custody of all
funds, property, and securities of the IETF Foundation, subject to
such regulations as may be imposed by the Board of Trustees. He or
she may be required to give bond for the faithful performance of his
or her duties, in such sum and with such sureties as the Board of
Trustees may require or as required by law, whichever is greater.
When necessary or proper, he or she may endorse on behalf of the IETF
Foundation for collection, checks, notes and other obligations, and
shall deposit same to the credit of the IETF Foundation at such bank
or banks or depository as the Board of Trustees may designate. He or
she shall make or cause to be made such payments as may be necessary
or proper to be made on behalf of the IETF Foundation. He or she
shall enter or cause to be entered regularly on the books of the IETF
Foundation to be kept by him or her for that purpose, full and
accurate account of all monies and obligations received and paid or
incurred by him or her for or on account of the IETF Foundation, and
shall exhibit such books at all reasonable times to any Trustee on
application at the offices of the IETF Foundation incident to the
Office of Treasurer, subject to the control of the Board of Trustees.
Certain duties of the Treasurer as may be specified by the Board of
Trustees may be delegated by the Treasurer.
*Section 8: Secretary.* The Secretary shall have charge of such
books, records, documents, and papers as the Board of Trustees may
determine, and shall have custody of the corporate seal. The
Secretary shall keep, or cause to be kept the minutes of all meetings
of the Board of Trustees. The Secretary may sign, with the Chairman,
in the name and on behalf of the IETF Foundation, any contracts or
agreements, and he or she may affix the corporate seal of the IETF
Foundation. He or she, in general, performs all the duties incident
to the Office of Secretary, subject to the supervision and control of
the Board of Trustees, and shall do and perform such other duties as
may be assigned to him or her by the Board of Trustees or the
Chairman of the Board of Trustees. Certain duties of the Secretary
as may be specified by the Board of Trustees may be delegated by the
Secretary.
*Section 9: Other Powers and Duties.* Each officer shall have in
addition to the duties and powers specifically set forth in these By
Laws, such duties and powers as are customarily incident to his
office, and such duties and powers as the Trustees may from time to
time designate.
D.2.7 Article VII: Amendments
*Section 1: By Laws.* These By Laws may be amended by an affirmative
vote of a majority of the Trustees then in office (excluding
abstentions) at a regular meeting of the board or a meeting of the
Malamud Expires February 23, 2005 [Page 72]
Internet-Draft Administrative Support Analysis August 2004
board called for that purpose as long as the proposed changes are
made available to all trustees and posted to the IETF Announce list
at least 30 days before any such meeting.
*Section 2: Articles of Incorporation.* The Articles of Incorporation
of the IETF Foundation may amended by an affirmative vote of
two-thirds vote of the Board of Trustees then in office at a regular
meeting of the board or a meeting of the board called for that
purpose as long as the proposed changes are made available to all
trustees and posted to the IETF Announce list at least 30 days before
any such meeting.
D.2.8 Article VIII: Dissolution
Upon the dissolution of the IETF Foundation, the IETF Foundation
shall, after paying or making provisions for the payment of all of
the liabilities of the Foundation, dispose of all of the assets of
the IETF Foundation exclusively for the exempt purposes of the IETF
Foundation in such manner or to such organization or organizations
operated exclusively for social welfare or charitable purposes. Any
such assets not so disposed of shall be disposed of by a court of
competent jurisdiction of the county in which the principal office of
the organization is then located, exclusively for such purposes. In
the event of a sale or dissolution of the corporation, the surplus
funds of the corporation shall not inure to the benefit of, or be
distributable to, its Trustees, officers, or other private persons.
D.2.9 Article IX: Miscellaneous Provisions
*Section 1: Fiscal Year.* The fiscal year of the IETF Foundation
shall be from January 1 to December 31 of each year.
*Section 2: Execution of Instruments.* All checks, deeds, leases,
transfers, contracts, bonds, notes and other obligations authorized
to be executed by an officer of the Foundation in its behalf shall be
signed by the Chairman of the Board or the Treasurer, or as the
Trustees otherwise determine. A certificate by the Secretary as to
any action taken by the Board of Trustees shall as to all persons who
rely thereon in good faith be conclusive evidence of such action.
*Section 3: Severability.* Any determination that any provision of
these By-Laws is for any reason inapplicable, illegal or ineffective
shall not affect or invalidate any other provision of these By-Laws.
*Section 4: Articles of Incorporation.* All references in these By
Laws to the Articles of Incorporation shall be deemed to refer to the
Articles of Incorporation of the IETF Foundation, as amended and in
effect from time to time.
Malamud Expires February 23, 2005 [Page 73]
Internet-Draft Administrative Support Analysis August 2004
*Section 5: Gender.* Whenever used herein, the singular number shall
include the plural, the plural shall include the singular, and the
use of any gender shall include all genders.
*Section 6: Successor Provisions.* All references herein: (1) to the
Internal Revenue Code shall be deemed to refer to the Internal
Revenue Code of 1986, as now in force or hereafter amended; (2) to
the Code of the State of Virginia, or any Chapter thereof, shall be
deemed to refer to such Code or Chapter as now in force or hereafter
amended; (3) the particular sections of the Internal Revenue Code or
such Code shall be deemed to refer to similar or successor provisions
hereafter adopted; and (4) to the Request for Comment Series shall be
deemed to refer to the Request for Comment Series as they are now in
force or hereafter amended.
Malamud Expires February 23, 2005 [Page 74]
Internet-Draft Administrative Support Analysis August 2004
Appendix E. Sample Draft Call for Applications -- IETF Administrative
Director
The IETF is seeking a highly capable individual to serve as
Administrative Director. You will report to the IETF Chair and be
accountable to IETF Community. This is a highly visible and very
demanding job. You will be expected to:
o Serve as the day-to-day chief operating officer of the IETF,
managing a number of contractors and working with a number of
volunteers.
o Provide primary support for budgeting and financial reporting
processes.
o Serve as the primary staff resource for the governing body of the
administrative entity for the IETF.
o Work with your contractors and members of the IETF community to
provide adequate support and planning for 3 IETF meetings
annually, and for frequent meetings and teleconferences of the
IAB, IESG, and other bodies that support the IETF.
o Work with our liaison organizations, such as the RFC Editor and
the IANA.
o Coordinate the standards-making support process, in particular the
periodic meetings of the IESG.
The following characteristics are necessary for this job:
o This job is public service. You should be able to work
successfully with large numbers of people. This requires a high
clock rate, a large stack, and the ability to listen carefully.
o This is an operations job. IETF meetings are large and complex,
and the day-to-day activities of the standards-making process is
demanding. You should be adept at getting real results and
helping large groups work together towards common goals and
deadlines.
o This job requires a financially astute individual. The IETF is a
$2-$3 million/year operation. IETF funds are tight and we expect
you to take leadership in establishing our budgetary procedures,
our procurement standards, and understanding our revenue sources.
In-depth familiarity with the IETF prior to assuming this position is
not required, but you must be able to quickly get up to speed and
learn the unique culture and requirements of the organization.
Likewise, long-term technical experience is not required, but you
must be a quick learner and adept at using the Internet effectively.
You may work out of a home office as a telecommuter, or use the
Internet Society facilities in Virginia. In either case, you should
be prepared to travel to Virginia, IETF meetings, and the locations
where the IETF has contractors.
Malamud Expires February 23, 2005 [Page 75]
Internet-Draft Administrative Support Analysis August 2004
Applicants should forward a resume, references, and any other
relevant materials, with a cover letter explaining why they feel they
are the right person for this position to:
URL
Applications are due no later than XXX, however the IETF
Administrative Entity reserves the right to make a decision prior to
this date or to extend this date in its sole discretion.
Applications will be reviewed by an evaluation committee consisting
of members of the IAB, IESG, and the community, and a decision shall
be made by the Chairs of the IETF and the IAB with the advice and
consent of the IESG and the IAB.
The list of applicants will not be posted publicly, but will be
reviewed in confidence by members of the evaluation committee, the
IAB, and the IESG.
Malamud Expires February 23, 2005 [Page 76]
Internet-Draft Administrative Support Analysis August 2004
Appendix F. Sample Draft Request for Proposals
F.1 Introduction
The IETF Administrative Entity is soliciting proposals for the
provision of five requirements, as detailed in this Request for
Proposals ("Proposals"). Proposals from any individual person or
persons or commercial or non-commercial vendor ("Vendor") are
welcome.
Proposals must be received in written electronic form no later than
[date]. Extensions may be granted solely in the discretion of the
IETF Administrative Entity. Each Proposal, together with all
supporting documentation, should be delivered to the following
address:
[URI/ADDRESS]
Any inquiries regarding this Request must be submitted in written
electronic form to the address listed above. Other than such
inquiries, vendors are prohibited from contacting any person or
institution involved in the selection process concerning this
Request.
Each Proposal must specifically address each of the selection
criteria listed below in a format corresponding to this Request.
Each Proposal should also be accompanied by any technical or product
literature that the Vendor wishes the IETF Administrative Entity to
consider. If additional information is required by the IETF
Administrative Entity to make a determination, such information may
be requested, and shall be submitted in writing in the manner set
forth above. Information other than the written Proposal and any
information submitted in response to a request by the IETF
Administrative Entity will not be considered by the IETF
Administrative Entity.
The IETF Administrative Entity reserves the right to cancel this
Request, in whole or in part, at any time. The IETF Administrative
Entity may reject any or all Proposals received in response to this
Request in its sole discretion. The IETF Administrative Entity makes
no guarantee or commitment to purchase, license or procure any goods
or services resulting from this Request.
Any Proposal which is selected by the IETF Administrative Entity
shall be subject to execution of a binding agreement between the IETF
Administrative Entity and the Vendor, which agreement shall be
prepared by the IETF Administrative Entity and shall reflect the
requirements outlined below and any additional provisions that are
Malamud Expires February 23, 2005 [Page 77]
Internet-Draft Administrative Support Analysis August 2004
agreed upon in discussions between the IETF Administrative Entity and
the Vendor. Selection may be conditioned upon acceptance of specific
contractual terms and conditions, which may be provided to the Vendor
during the selection process.
Each Vendor is responsible for its own costs and expenses involved in
preparing and submitting its Proposal and any supplemental
information requested by the IETF Administrative Entity. The IETF
Administrative Entity shall not reimburse any such costs or expenses.
All Proposals submitted in accordance with this Request will be
reviewed by a panel of experts drawn from the IETF community. A list
of reviewers will be made available. The IETF Administrative Entity
will notify Vendors of their selection following receipt and
consideration of all Proposals. The IETF Administrative Entity will
attempt to make its selection(s) by [date], but shall have full
discretion to make a decision earlier or later than this date.
F.2 General Provisions
The following provisions apply to all bidders:
1. A response may be submitted for one or more of the 5 listed
support requirements. If response addresses more than one of the
listed support requirements, the proposal should be written to
clearly separate costs by area. The IETF Administrative Entity
reserves the right to accept only a partial proposal.
2. Key Person Principle: Each requirement requires the designation
of one individual as the "Key Person" in your response. That
person will be the individual accountable to the IETF. The IETF
Administrative Entity will require a binding key personnel clause
in the contract. Any change in the Key Person will require prior
approval. The IETF Administrative Entity will also require a
written process that describes procedures for backing up the key
person when that person is not available. The IETF
Administrative Entity will also require that the bidder obtain
and maintain key person insurance for dealing with the
possibility that the designated key person becomes unavailable.
3. The IETF Administrative Entity encourages zero-cost or zero-cost
plus materials bids, but will insist on a binding agreement.
4. The IETF Administrative Entity encourages bids from individuals
as well as public and private institutions as long as the above
conditions are met. You should submit a detailed work history of
each individual, personal references, and a detailed description
of any sub-contractual arrangements you have put in place to
assist you.
5. Appropriate insurance and other mechanisms to minimize the
liability of the IETF Administrative Entity should be discussed
in your proposal.
Malamud Expires February 23, 2005 [Page 78]
Internet-Draft Administrative Support Analysis August 2004
F.3 Requirement 1: Meetings
We are looking for creative proposals from experienced professionals
to organize and support the meetings of the IETF.
You will work with the Administrative Director of the IETF and the
IETF leadership to organize the three annual meetings of the IETF.
Based on current practice, you should expect 1-2 of those meetings to
be in the United States and 1-2 of those meetings to be in other
countries, though this may change based on the requirements of the
IETF. We expect approximately 1500 attendees per meeting, though in
the past this number has approached 3,000 based on the location of
the meeting and the state of the economy.
You should have very strong experience in meeting planning,
particularly working meetings with large numbers of participants.
You should be intimately familiar with the details of booking
appropriate venues, working with hotel and conference center staff,
and providing clear and concise communications with meeting
attendees.
Your proposal should detail the mechanisms you would use to provide a
simple registration and payment procedure for attendees. You will be
able to draw on webmaster and sysadmin support for the IETF, for
example, if you would like to provide a secure payment mechanism on
the IETF web site. Your proposal should also detail how you will
provide additional resources on-site (e.g., staffing a registration
desk and other requirements that require additional people).
As part of this function, you will work with Local Hosts (when
available), who provide a sophisticated network infrastructure to
support the meeting, as well as a team of volunteers who provide
additional terminal room support, real-time audio and video streaming
from the meeting and other functions.
F.4 Requirement 2: Systems and Systems Administration
This requirement consists of two functions. You may bid on one or
both of these functions, which include:
1. Provision of a core network infrastructure.
2. Systems Administration.
F.4.1 Core Network Infrastructure
[Ed. This section will contain service level specifications. E.g.,
core bandwidth requirements, CPU capacity, disk space, and other
variables. It will also contain core specifications, such as
routing, DNS, and other services.]
Malamud Expires February 23, 2005 [Page 79]
Internet-Draft Administrative Support Analysis August 2004
F.4.2 Systems Administration Services
[Ed. This section will contain the description for the Systems
Administration function, including such tasks as keeping key software
subsystems such as Apache installed and up-to-date and support for
users.]
F.5 Requirement 3: Postmaster of the IETF Administrative Entity
The Postmaster of the IETF Administrative Entity is responsible for
the functioning and archiving of numerous mailing lists maintained by
the IETF and for archiving specific IETF-related mailing lists
maintained by others. Note that the archives of most IETF mailing
lists are public and the bidder must describe how such archives will
be accessed by the public.
The core mailing is described in [RFC3005], and a policy with regards
to posting rights may be found in [RFC3683]. You will find
additional information on IETF mailing lists at:
<http://www.ietf.org/maillist.html>
In addition, the IETF maintains several dozen members-only lists in
support of bodies such as the IAB, the IESG, and certain IRTF task
forces (see [RFC2014], [RFC2850], and [RFC3710] for more details on
these bodies). IETF administrators and chairs of various groups
typically will form ad hoc lists which they administer for various
tasks.
Familiarity and expertise in administering high-volume lists and in
maintaining large numbers of archived lists is necessary. The
ability to provide administrative facilities that allow the IETF to
delegate authority for moderation and creation of lists is also
necessary. Finally, you should be experienced in the very latest
spam fighting technologies.
You may propose to provide service in one of two ways:
o Move the IETF mail handling onto an existing well-provisioned
infrastructure that you are responsible for.
o Provide mail services on machines that are maintained by the IETF.
Your bid should clearly explain what tools you will use, the types of
interfaces you will provide to list maintainers and participants, and
you would handle issues such as spam. You should also be very clear
in your proposal about your understanding of the role and duties of
the postmaster.
Malamud Expires February 23, 2005 [Page 80]
Internet-Draft Administrative Support Analysis August 2004
F.6 Requirement 4: Clerk of the IETF Administrative Entity
This requirement is for general high-level administrative support for
the day-to-day functioning of the IETF. A specialized subfunction in
the Clerk's office is the processing of the Internet-Draft submission
queue. Such documents must conform to requirements for
Internet-Drafts as defined by the IETF.
In addition to processing the Internet-Draft queue, you will work
with the Administrative Director of the IETF to help make the
organization function smoothly on a day-to-day basis.
[Ed. More detail to be filled in here by a transition team.]
F.7 Requirement 5: Webmaster of the IETF Administrative Entity
This task has the responsibility for the look and feel of the IETF
network presence, particularly the web site. A series of support
contracts will be available to help support this function.
In addition, this task has responsibility to provide overall support,
in cooperation with the sysadmin and other contractors, to a variety
of working groups, directorates, and other activities that require a
workspace.
Your proposal must demonstrate that you are experienced at producing
highly standards-conformant and functional network presences and
supporting a large and diverse community of users. This is a highly
hands-on task.
F.8 Selection Criteria and Evaluation Process
All proposals will be evaluated using a process that consists of the
following steps:
1. An evaluation committee will be formed by the IETF and IAB
Chairs, and will include the Administrative Director of the IETF
Administrative Entity.
2. The evaluation committee will perform an initial evaluation of
submitted responses.
3. A dialogue will be started with selected responses.
4. The IETF will decide on the initial best candidate.
5. The A further dialogue will ensue with that candidate.
6. A contract may be signed or the discussion may continue with
other candidates.
The IETF Administrative Entity will consider price, experience,
technical smarts, and a variety of other factors. Note well that the
IETF Administrative Entity will not decide on price alone. Overall
Malamud Expires February 23, 2005 [Page 81]
Internet-Draft Administrative Support Analysis August 2004
benefit to the IETF community will be the prime consideration.
Malamud Expires February 23, 2005 [Page 82]
Internet-Draft Administrative Support Analysis August 2004
Index
F
functions 6, 6, 10, 11, 13, 16, 17
M
mechanisms 33, 33, 33, 33, 33, 33, 33
O
opinions 16, 23
options 1, 7, 9, 22, 22, 24, 27, 37
P
pillars 6, 6, 6
R
recommendations 8, 20, 21, 21, 27, 28, 36
S
strategies 22, 22, 22
Malamud Expires February 23, 2005 [Page 83]
Internet-Draft Administrative Support Analysis August 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@xxxxxxxxx
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Malamud Expires February 23, 2005 [Page 84]
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf