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(_at_)thinkingcat(_dot_)com
-------------------------------------------------------------------
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(_at_)ietf(_dot_)org). 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