| TOC |
|
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 March 9, 2005.
Copyright (C) The Internet Society (2004).
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.
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.
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.
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@ietf.org). The IETF Discussion List is defined in [RFC3005]Harris, S., IETF Discussion List Charter, November 2000. and further defined in [RFC3184]Harris, S., IETF Guidelines for Conduct, October 2001. and [RFC3683]Rose, M., A Practice for Revoking Posting Rights to IETF mailing lists, February 2004..
1.
Introduction
1.1
Goals and Non-Goals
1.1.1
Goals
1.1.2
IETF Standards Process Out of Scope
1.1.3
ISOC Role in Standards Process Out of Scope
1.2
Previous Steps in This Process
1.3
Decision Process
1.4
Criteria for Judging an Administrative Restructuring
1.5
Methodology
2.
Analysis of Current Administrative Framework
2.1
Providers and Functions
2.2
Function 1: Administration
2.3
Function 2: Meetings
2.4
Function 3: Core Information Technology
2.5
Function 4: Document and Information Flow
3.
Recommendations for Restructuring the Administrative Framework
3.1
Recommendation 1: Hire An Administrative Director
3.2
Recommendation 2: Establish Contracts for Core Services
3.2.1
Details of Potential RFP Components
3.3
Recommendation 3: Provide Timely and Uniform Financial Reporting
3.4
Recommendation 4: More Focus on Archives
4.
Options for an Institutional Basis for Administrative Activities
4.1
Discussion of Organizational Form and Legal Domicile
4.2
Scenario A: ISOC Operating Unit
4.2.1
Division of the Internet Society
4.2.2
Intended benefits
4.2.3
Additional Considerations
4.3
Scenario B: More Formalized ISOC Operating Unit
4.4
Scenario C: Well-Defined Entity With Close Ties to ISOC
4.4.1
How Scenario C Might Work In Practice
4.5
Scenario D: Autonomous Entity
4.6
Discussion of Unincorporated Associations
5.
Future Work
5.1
Short-Term
5.2
Long-Term
6.
Acknowledgment of CNRI Contribution to the IETF Community
7.
Acknowledgment of Contributions and Reviews
8.
IANA Considerations
9.
Security Considerations
10.
References
10.1
Normative References
10.2
Informative References
§
Editorial Comments
§
Author's Address
A.
Consulting Contract
B.
IETF Financial Information
B.1
Consolidated 3-Year Historical Income Statement
B.2
Internet Society 2004 Budget Summary
C.
10-Year Meeting Attendance Summary
C.1
Analysis of Meeting-Based Expense and Revenue Drivers
D.
Sample Draft Incorporating Documents for a Hypothetical IETF Foundation
D.1
Sample Draft Articles of Incorporation
D.2
Sample Draft Bylaws of the IETF Foundation
D.2.1
Article I: Organization
D.2.2
Article II: Purpose
D.2.3
Article III: Members
D.2.4
Article IV: Offices
D.2.5
Article V: Board of Trustees
D.2.6
Article VI: Officers
D.2.7
Article VII: Amendments
D.2.8
Article VIII: Dissolution
D.2.9
Article IX: Miscellaneous Provisions
E.
Sample Draft Call for Applications — IETF Administrative Director
F.
Sample Draft Request for Proposals
F.1
Introduction
F.2
General Provisions
F.3
Requirement 1: Core Network Infrastructure
F.4
Requirement 2: Systems Administration Services
F.5
Requirement 3: Postmaster of the IETF Administrative Entity
F.6
Requirement 4: Webmaster of the IETF Administrative Entity
F.7
Requirement 5: Meetings
F.8
Requirement 6: Clerk of the IETF Administrative Entity
F.9
Selection Criteria and Evaluation Process
§
Index
§
Intellectual Property and Copyright Statements
| TOC |
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:
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:
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.
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:
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:
Any changes to the Standards Process Functions would use the 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.
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]Alvestrand, H., A Mission Statement for the IETF, June 2004.). 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]Advisory, IAB., The IETF in the Large: Administration and Execution, March 2004..
This document carries out the requirements of [RFC3716]Advisory, IAB., The IETF in the Large: Administration and Execution, March 2004. 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]Daigle, L., A Proposal for IETF Administrative Restructuring, February 2004., 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.
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]Advisory, IAB., The IETF in the Large: Administration and Execution, March 2004.. 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:
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.
The guiding principles in the analysis of the administrative restructuring are the criteria specified in [RFC3716]Advisory, IAB., The IETF in the Large: Administration and Execution, March 2004., Section 3. These criteria are worth restating:
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.1 Accountability for change.
2.2 Persistence and accessibility of records.
3.1 More service automation where appropriate.
3.2 Better tools.
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 AConsulting Contract.
The following steps were used to gather input to this report:
| TOC |
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]Hoffman, P. and S. Bradner, Defining the IETF, February 2002. A variety of institutions provide administrative support to the IETF community:
For purposes of this analysis, we will examine these institutions using a 4-part taxonomy of functions:
A prime requirement of [RFC3716]Advisory, IAB., The IETF in the Large: Administration and Execution, March 2004. 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]Advisory, IAB., The IETF in the Large: Administration and Execution, March 2004. 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 between the IETF community and CNRI/Foretec is one of the items noted in [RFC3716]Advisory, IAB., The IETF in the Large: Administration and Execution, March 2004., 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:
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.
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]Bradner, S., Intellectual Property Rights in IETF Technology, February 2004.. 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]Advisory, IAB., The IETF in the Large: Administration and Execution, March 2004. goals of "uniform budget responsibility" and "a uniform view of revenue sources" are not being attained. In particular:
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.1Consolidated 3-Year Historical Income Statement 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 C10-Year Meeting Attendance Summary 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 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:
Over the years, a variety of other efforts have sprung up and disbanded aimed at deploying leading-edge technologies in the meeting 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]Carr, C., Network subsystem for time sharing hosts, September 1969. 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 has led to disagreements between the contractor and the IETF leadership. Two situations in particular are apparent:
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:
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. And, a comparison of the IETF home page from January 7, 1997 and from February 15, 2004 shows that it has remained virtually unchanged during that period [Wayback]Internet Archive, Wayback Machine: Comparison of www.ietf.org for Jan. 7, 1997 and Feb. 15, 2004, September 2004..
These are all anecdotal examples, but they certainly reinforce the findings of [RFC3716]Advisory, IAB., The IETF in the Large: Administration and Execution, March 2004. 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.4Recommendation 4: More Focus on Archives, some additional support might help meet goals such as the goal stated in [RFC3716]Advisory, IAB., The IETF in the Large: Administration and Execution, March 2004. 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.
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 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:
A great deal of progress has been made in this area over the last year, and more can be expected in the future with the 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 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.
| TOC |
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 4Options for an Institutional Basis for Administrative Activities discusses the institutional framework in which these activities can be housed, including issues such as whether to incorporate the administrative entity.
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]Davies, E., IETF Problem Statement, May 2004..
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 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 ESample Draft Call for Applications — IETF Administrative Director.
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 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:
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:
In addition to intellectual property considerations, any contract negotiation should be bounded by two other parameters:
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.
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. This is not necessarily an optimum distribution of resources. One could imagine multiple models, including:
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 FSample Draft Request for Proposals and picks the following decomposition:
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.
The terms "Request for Proposals" (RFP) and "Request for Information" (RFI) bear a brief explanation. A wide variety of organizations use formal and open procurement processes. Some of the better known entities, particularly government agencies, have an extremely rigorous process defined in the RFP announcement, including metrics for decision, such as a formula for calculating a final score based on price and a metric such as average panel rankings on subjective criteria such as "quality" or "responsiveness". A process this rigorous would probably not give the IETF administrative entity much flexibility in crafting an appropriate solution.
A "Request for Information" often suggests that a final decision will not be based on the initial information submitted in the call for proposals. Rather, the RFI is used to put together a short list of potential candidates, and engage in negotiation and reformulation of the proposals.
In either case, the term used really does not matter nearly much as the terms specified in the call for proposals. The label is fairly irrelevant and the real meaning is specified in the details. A call for proposals could easily bear either label.
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.
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).
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.
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.
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.
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.
[RFC3716]Advisory, IAB., The IETF in the Large: Administration and Execution, March 2004. 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:
More attention to this important area is recommended as a key 2005 goal.
| TOC |
This report frames the question of organizational form as follows:
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:
As an aide for discussion purposes, this report proposes four scenarios:
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.1Recommendation 1: Hire An Administrative Director. 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).
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 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,
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.
One of the considerations from which the IETF has long benefited is the current separation between corporate donations and IETF actions. 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]Advisory, IAB., The IETF in the Large: Administration and Execution, March 2004..
(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.)
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, 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:
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.3Decision Process, 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.
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.
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 no stockholders.
In addition, any formal organization for administrative support needs to take into account some of the unique characteristics of the IETF:
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 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:
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]State of Delaware, Title 8. Corporations — Chapter 1. General Corporation Law — Subchapter 1. Formation, Undated. and [California]State of California, California Corporations Code, Undated., but there appeared to be no significant advantages. In particular, there are no significant differences in issues such as director liability that would make incorporating outside the place of actual domicile attractive.
[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.]
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.1Sample Draft Articles of Incorporation and the Sample Draft Bylaws attached in Appendix D.2Sample Draft Bylaws of the IETF Foundation:
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. [anchor34]Mike St. Johns: 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.
[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.1Sample Draft Articles of Incorporation and Appendix D.2Sample Draft Bylaws of the IETF Foundation.]
The following are some general principles for the operation of the IETF Foundation:
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.
While many non-profit organizations choose to incorporate, this is not the only institutional structure available. In the U.S., as in several other countries, there is a concept of an unincorporated association, a legal structure that allows groups of individuals to form an association that has certain powers under the law, including in some cases limitations of liability and the ability to hold real property and make agreements. [anchor38]Editor: Several members of the community, including Rob Austein, Brian Carpenter, Donald Eastlake, Robert Kahn, and Patrice Lyons suggested an analysis of the "unincorporated association" mechanism as an alternative to formal incorporation.
The concept of the unincorporated association is important for two reasons:
The concept of unincorporated association has sprung up in case law over many years, as groups of people formed social clubs, veterans groups, and other communities of interest. Inevitably, these communities ran into conflicts and the courts were forced to face questions such as whether these communities could be sued, hold property, or make contracts.
This section does not attempt to discuss the standing of "the IETF" or "the IETF community" as it presently stands under case law governing unincorporated associations. Instead, this section describes a series of fairly recent developments in United States case law that are relevant to the discussion of the legal form that an IETF Administrative Entity might take.
In the United States, a Uniform Unincorporated Nonprofit Association Act was passed in 1996 by the Uniform Law Commissioners [UUNAA]Uniform Law Commissioners, Uniform Unincorporated Nonprofit Association Act (1996), 1996.. The uniform law has since been enacted by Delaware and 9 other states, as well as the District of Columbia [ULC]Uniform Law Commissioners, UUNAA Legislative Fact Sheet, 2004.. Unincorporated nonprofit associations can be granted federal exemption from taxes under section 501(c)(3) of the IRS Code if they meet two tests:
The organization test is thus theory, the operational test practice, and the two must achieve the same purposes.
The unincorporated association structure is also available in other countries, such as the United Kingdom[Charity]Charity Commission for England and Wales, GD3 - Model Constitution for a Charitable Unincorporated Association, July 2004., but this analysis is confined to the U.S. structure.
Some examples of unincorporated associations include:
An association is defined in a chartering document, typically labeled a "Constitution" or "Articles of Association." The association must have two or more members who are "joined by mutual consent for a common purpose." Members are defined as persons (which includes individuals, but also any other legal entity such as a corporation or government department) who "may participate in the selection of persons authorized to manage the affairs of the nonprofit association or in the development of policy of the nonprofit association." Mechanisms such as randomly selected nominating committees appear to adequately satisfy the "may participate in the selection" requirement.
The unincorporated association is not as broad as other forms, such as an incorporated association. However, the unincorporated association does have several rights, such as:
The limitations on liability are important changes over older common law, which held individual members liable for the actions of the association. Needless to say, individual members can still be held liable for their own actions, but under the uniform law, they cannot be held liable for the actions of the association merely by being a member. Likewise, under the uniform law, the association has standing in court and can sue or be sued.
The unincorporated association, under the uniform law, thus provides many of the benefits of the corporate form. It can be considered, to some extent, as a sort of "corporation-lite" [CLRC]California Law Revision Commission, Uniform Unincorporated Nonprofit Association Act: Governance Issues, October 2002..
| TOC |
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:
While [RFC3716]Advisory, IAB., The IETF in the Large: Administration and Execution, March 2004. set out principles for administrative restructuring, it should be remembered that administrative restructuring is just one of the tasks facing the IETF. [RFC3774]Davies, E., IETF Problem Statement, May 2004. 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]Hoffman, P. and S. Bradner, Defining the IETF, February 2002.
Much of that focus on "more important issues" is already present in the IETF today. Working Groups such as [NEWTRK]The IETF, Charter of the New IETF Standards Track Discussion (newtrk) Working Group, June 2004. and [ICAR]The IETF, Charter of the Improved Cross-Area Review (icar) Working Group, June 2004. 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 pursuits [Layton]Layton, E., The Revolt of the Engineers, 1986.. 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]IEEE Center for the History of Electrical Engineering, The Origins of the IEEE, 1984.. 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]Carpenter, B., Architectural Principles of the Internet, June 1996. and an avoidance of entanglements at layers 8-10 of the OSI Reference Model [OSI]Wikepedia, Open Systems Interconnection Reference Model, August 2004..
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]Huxley, T., On the Advisableness of Improving Natural Knowledge (A Lay Sermon Delivered in St. Martin's Hall), January 1866. 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.
| TOC |
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_Kahn]Cerf, V. and R. Kahn, A Protocol for Packet Network Intercommunication, May 1974. his key operational role in engineering the early Internet (see, e.g., [RFC0371]Kahn, R., Demonstration at International Computer Communications Conference, July 1972.), 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.
| TOC |
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, Rob Austein, 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, David Kessens, Robert Kahn, Daniel Karrenberg, John Klensin, Rebecca Malamud, Allison Mankin, Jordi Palet Martinez, 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 xml2rfchttp://xml.resource.org/ using the format specified in [RFC2629]Rose, M., Writing I-Ds and RFCs using XML, June 1999.. PDF renditions of the document were created with Julian Reschke's XSLT style sheets http://greenbytes.de/tech/webdav/rfc2629xslt.zip and diffs from prior draft were produced using Henrik Levkowetz's rfcdiff tool http://ietf.levkowetz.com/tools/rfcdiff/.
| TOC |
[RFC2434]Narten, T. and H. Alvestrand, Guidelines for Writing an IANA Considerations Section in RFCs, October 1998. states each Internet-Draft should contain an "IANA Considerations" section. [RFC3716]Advisory, IAB., The IETF in the Large: Administration and Execution, March 2004. 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.
| TOC |
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.
| TOC |
| TOC |
| TOC |
| TOC |
| anchor24: | Editor: It has been noted that any such action would, of course, require the full approval and cooperation of the Internet Society Board. The fundamental chartering document for ISOC are the articles of incorporation, which require 4/5 approval of the board for changes [RFC2134]. The bylaws, as published in [RFC2135] and periodically amended through board resolutions, requires a 2/3 vote for certain changes to the bylaws. Governance is specified in general terms in [RFC2135] and further specified in a series of board resolutions. Composition of and the procedures for selection of members of the board is specified in Board Resolution 02-2 [ISOC-Gov] which is "generally harmonious" with [ISOC-Gov2], which is currently suspended. |
| anchor25: | Editor: 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. |
| anchor26: | Editor: Reviewers have noted that this mechanism would be necessary under Scenario A as well. |
| anchor27: | Editor: Several reviewers have noted that the ISOC board does in fact already conduct open meetings. This mechanism simply suggests more IETF participation in those meetings as a way of drawing the community together. |
| anchor28: | Editor: This suggestion came from Marshall T. Rose. |
| anchor34: | Mike St. Johns: 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. |
| anchor38: | Editor: Several members of the community, including Rob Austein, Brian Carpenter, Donald Eastlake, Robert Kahn, and Patrice Lyons suggested an analysis of the "unincorporated association" mechanism as an alternative to formal incorporation. |
| TOC |
| Carl Malamud (editor) | |
| Memory Palace Press | |
| PO Box 300 | |
| Sixes, OR 97476 | |
| US | |
| EMail: | carl@media.org |
| URI: | http://infinite.simians.net/ |
| TOC |
AGREEMENT FOR CONSULTING SERVICES
Contract between CARL MALAMUD AND
THE INTERNET SOCIETY
Contract:
Carl Malamud (hereafter known as the Consultant) agrees to provide consulting services to the Internet Engineering Task Force (IETF), the Internet Architecture Board (IAB) and the Internet Society (ISOC) subject to the terms and conditions specified below. Under this agreement, the Consultant is acting as an independent contractor and assumes all responsibilities for federal and state income taxes, social security and medicare tax, medical insurance, and other applicable filings associated with his status.
Scope:
The Consultant will provide the following services outlined in Appendix I. It is anticipated that the responsibilities will require 20 days per month to accomplish the objectives for which said Consultant was engaged.
Consultant understands and agrees that this Contract is being executed with a view to supporting the IETF/IAB as it considers whether, and if so, how, it might wish to restructure for purposes of future IETF/IAB endeavors. In the performance of this Contract, Consultant agrees to exercise fair and professional judgment for the benefit of the IETF/IAB and to treat all existing and/or potential partners of the IETF/IAB in a fair manner while protecting any business confidences that each might have.
Contract Term:
The contract will begin on 21 June 2004 and end on 21 December 2004. For services rendered under this contract the Consultant will be paid a fee of $16,000 per month due and payable at the end of each month upon receipt of an invoice. Consultant will be required to submit a monthly accounting of days worked. Should the days worked in any month exceed 20, no additional fees are due. The contract may only be extended by written agreement specifying new services, terms, and conditions as mutually agreed to by both parties.
Expenses:
All expenses incurred on behalf of the IETF/IAB or ISOC shall be billed to ISOC in addition to charges for services provided above. Such expenses shall include travel, long distance telephone, business meals, and other customary expenses as appropriate. Such expenses should be authorized by ISOC, after consultation with the IETF and the IAB Chairs, and in advance of the expenditure.
Invoicing:
Consultant shall submit invoices at the end of each month (pro-rated for June and December). The Internet Society will make best efforts to make payment within one week of receipt. If consultant worked less than 20 days, then ISOC may reduce the monthly fee due by 1/20th of such fee for each day less than 20. Invoices may be submitted electronically or by mail. The invoices should be addressed to the Internet Society's Finance Director, Lynn DuVal at the Reston office (1775 Wiehle Avenue, Suite 102, Reston, VA 20190) or by e-mail at duval@isoc.org.
Termination:
Either party may terminate this Contract by providing ten (10) days prior written notice sent by e-mail to the addresses noted below.
In addition, should the subject matter addressed in this Contract become, in whole or in part, the subject matter of any filed or threatened litigation then either party may terminate this Contract by providing five (5) days prior written notice sent as per the above paragraph.
The days of prior written notice above shall be measured from the date sent.
The Internet Society will be responsible for all fees properly incurred under this Contract prior to the effective date of termination.
If such a termination should occur other than at a month-end, then payment for services shall be paid pro rata, up to 100% of the monthly rate, at the rate of 1/20th of the monthly services fee per day worked to termination
Miscellaneous:
ISOC does not wish for itself or others to receive any confidential, proprietary information of any other party without proper permission. Consequently, Consultant agrees not to use or divulge, in his efforts relating to this contract, any information in any form, tangible or intangible, that is the confidential information of any third party, whether IETF/IAB, any contractor or partner of IETF/IAB, or any other party, to ISOC or any other party without the express written permission of the party or parties who own or control such confidential material and without first disclosing such written permission to ISOC.
Consultant agrees that any tangible or intangible work product that results from Consultant's efforts under this Contract (whether by Consultant or a contractor to Consultant) shall be the exclusive property of ISOC or the IETF/IAB, as appropriate, and this includes, without limitation, any invention, product, business process, code or other device or discovery that might now or hereafter be entitled to protection, registration or ownership under intellectual property rights regimens such as, but not only, trade secret, patent, copyright, and trademark.
ISOC may disclose the terms of this Contract to the IETF/IAB or any other party having an interest in the subject matter hereof that ISOC deems reasonable.
Warranties and Indemnities:
This written agreement constitutes the full agreement between the parties. No warranties or indemnities are explicitly included or implied.
Amendments:
Amendments to this agreement must be in writing and executed by both parties.
| Executed on behalf of The Internet Society | Executed on behalf of the Consultant |
|---|---|
| Lynn St. Amour | Carl Malamud |
| President & CEO | |
| st.amour@isoc.org | carl@media.org |
| Date: | Date: |
Appendix I: Statement of Work
The IETF/IAB is considering an Administrative restructuring and has asked ISOC to support their efforts. The contract to which this is attached is in furtherance of this endeavor.
Consultant shall become familiar with RFC 3716 as the basis for these efforts and shall use such RFC as a reference point in these efforts except to the extent that this Contract or any guidance supplied to Consultant by IETF/IAB or ISOC under this contract supercedes such RFC.
The types of activities Consultant shall undertake are:
Deliverables hereunder shall include:
| TOC |
(US$)
| 2001 [1] | 2002 [2] | 2003 [3] | 2004 [4] | |
|---|---|---|---|---|
| REVENUE | ||||
| CNRI/Foretec Meeting Revenue | 2,699,239 | 2,350,666 | 2,060,747 | 1,728,125 |
| Less Bank Fees | 81,365 | 70,309 | 62,826 | 51,844 |
| Net Meeting Revenue | 2,617,874 | 2,280,357 | 1,997,921 | 1,676,281 |
| Contribution By The Internet Society [5] | 535,535 | 550,881 | 614,691 | 663,570 |
| Provision of the IANA function by ICANN [6] | — | — | — | — |
| Other Contributions | — | — | — | 150,000 |
| TOTAL FUNDS | 3,153,409 | 2,831,238 | 2,612,612 | 2,489,851 |
| EXPENSE | ||||
| ISOC Expenditures | ||||
| RFC Editor | 428,300 | 462,368 | 516,460 | 574,570 |
| IETF Chair Discretionary Fund | 73,748 | 52,137 | 51,460 | 48,500 |
| IAB Support | 13,287 | 14,446 | 37,270 | 24,500 |
| Insurance | 20,000 | 21,930 | 13,685 | 16,000 |
| Total ISOC Expenditures | 535,535 | 550,881 | 614,691 | 663,570 |
| CNRI/Foretec Expenditures | ||||
| Secretariat Labor | 504,584 | 625,124 | 532,936 | 478,000 |
| IETF Meeting Costs | ||||
| Food & Beverage | 862,500 | 705,610 | 513,081 | 487,500 |
| Audio/Visual | 127,337 | 83,239 | 96,902 | 60,000 |
| Room Rental | 190,265 | 172,907 | 125,187 | 170,000 |
| Terminal Room | — | — | 66,294 | 25,000 |
| Other Meeting Costs | 1,925 | 8,340 | 13,367 | 6,000 |
| Total IETF Meeting Costs | 1,182,027 | 970,096 | 814,831 | 748,500 |
| Non-Meeting Costs | ||||
| Travel | 39,122 | 53,838 | 78,947 | 75,000 |
| Materials | 7,318 | 11,724 | 9,706 | 10,700 |
| Printing & Publication | 59,431 | 31,459 | 14,266 | 12,000 |
| Professional Services | 24,581 | 61,105 | 12,288 | 9,000 |
| Telecommunications | 54,400 | 82,210 | 32,582 | 42,000 |
| Misc. | 12,003 | 577 | — | 4,000 |
| Equipment Rental | 4,668 | 736 | 1,630 | 2,500 |
| Total Non-Meeting Costs | 201,523 | 241,650 | 149,419 | 155,200 |
| Total CNRI/Foretec "Direct" Expenses | 1,888,134 | 1,836,870 | 1,497,186 | 1,381,700 |
| CNRI/Foretec Overhead Charge | 604,990 | 608,805 | 641,939 | 504,560 |
| CNRI/Foretec "Performance Bonus" For Staff | 30,000 | — | — | — |
| Total CNRI/Foretec Expenses | 2,523,124 | 2,445,675 | 2,139,125 | 1,886,260 |
| TOTAL EXPENSES (ISOC and CNRI) | 3,058,659 | 2,996,556 | 2,753,816 | 2,549,830 |
| SURPLUS/DEFICIT | 94,750 | (165,318) | (141,204) | (59,979) |
Notes:
- [1]
- Actual results based on unaudited reports. Source: [IETF-2001]Alvestrand, H., The Financials of the IETF — 2001, February 2003.
- [2]
- Actual results based on unaudited reports. Source: [IETF-2002]Alvestrand, H., The Financials of the IETF — 2002, July 2003.
- [3]
- Actual results based on unaudited reports. Source: [IETF-2003]Alvestrand, H., The Financials of the IETF — 2003, May 2004.
- [4]
- Budgeted. Source: [IETF-2004]Alvestrand, H., The IETF Budget — 2004, May 2004.
- [5]
- ISOC manages expenditures directly. The revenue line here represents funds allocated by the ISOC Board of Trustees for the purpose of IETF support. The figures in this line equal their corresponding cells for Total ISOC Expenditures.
- [6]
- ICANN does not report expenses broken down by functional area, nor are the direct and indirect costs associated with the IETF parameter registries available. We thus value this contribution as "priceless" for purposes of this analysis.
The Internet Society 2004 Budget was approved at a Special Teleconference Meeting of the Internet Society Board of Trustees [ISOC-2004]Internet Society, 37th Board of Trustees meeting of the Internet Society, December 2003..
(US$)
| Standards Pillar | Education Pillar | Public Policy Pillar | Total | |
|---|---|---|---|---|
| REVENUE | ||||
| Organizational and Platinum Membership | 1,050,000 | 242,000 | 200,000 | 1,492,000 |
| Individual Membership | 52,500 | 52,500 | ||
| Conferences (INET, NDSS) | 145,000 | 145,000 | ||
| .org Program Revenue | 900,000 | 450,000 | 550,000 | 1,900,000 |
| Other (Contributions and Security Expert Initiative | 155,000 | 155,000 | ||
| TOTAL REVENUE | 2,105,000 | 837,000 | 802,500 | 3,744,500 |
| EXPENSE | ||||
| ISOC Salaries and Related Costs | 371,337 | 364,623 | 458,128 | 1,194,088 |
| IETF Staff Travel | 10,000 | 10,000 | ||
| RFC Editor | 574,570 | 574,570 | ||
| IETF and IAB Support and Insurance | 89,000 | 89,000 | ||
| IETF Restructuring Project | 709,000 | 709,000 | ||
| Conference Expense | 100,000 | 100,000 | ||
| Professional Services, Travel, Misc. | 12,500 | 20,000 | 4,000 | 36,500 |
| External Costs: .org | 40,000 | 89,400 | 70,000 | 199,400 |
| External Costs: SEINIT & Sida | 70,000 | 42,181 | 112,181 | |
| TOTAL DIRECT EXPENSE | 1,876,407 | 616,204 | 532,128 | 3,024,739 |
| G&A/GOVERNANCE | 192,026 | 188,555 | 236,908 | 617,489 |
| TOTAL EXPENSE | 2,068,433 | 804,759 | 769,036 | 3,642,228 |
| SURPLUS | 36,567 | 32,241 | 33,464 | 102,272 |
| TOC |
| IETF | DATE | Location | Host | Attendees |
|---|---|---|---|---|
| 60th IETF | 01/08/2004 | San Diego, CA, USA | — | 1511 |
| 59th IETF | 29/02/2004 | Seoul, South Korea | — | 1390 |
| 58th IETF | 09/11/2003 | Minneapolis, MN, USA | — | 1233 |
| 57th IETF | 13/07/2003 | Vienna, Austria | — | 1304 |
| 56th IETF | 16/03/2003 | San Francisco, California, USA | — | 1679 |
| 55th IETF | 17/11/2002 | Atlanta, Georgia, USA | Nokia | 1570 |
| 54th IETF | 14/07/2002 | Yokohama, Japan | Fujitsu; The WIDE Project | 1885 |
| 53rd IETF | 17/03/2002 | Minneapolis, Minnesota, USA | Cable & Wireless | 1656 |
| 52nd IETF | 09/12/2001 | Salt Lake City, Utah, USA | Novell | 1691 |
| 51st IETF | 05/08/2001 | London, England | BTexact Technologies | 2226 |
| 50th IETF | 18/03/2001 | Minneapolis, MN, USA | Lucent Technologies | 1822 |
| 49th IETF | 10/12/2000 | San Diego, CA, USA | Cisco Systems; Qualcomm | 2810 |
| 48th IETF | 31/07/2000 | Pittsburgh, PA, USA | Marconi | 2344 |
| 47th IETF | 26/03/2000 | Adelaide, Australia | connect.com.au | 1431 |
| 46th IETF | 07/11/1999 | Washington, DC, USA | Nortel Networks, Inc | 2379 |
| 45th IETF | 11/07/1999 | Oslo, Norway | Uninett | 1710 |
| 44th IETF | 14/03/1999 | Minneapolis, MN, USA | Ascend Communications | 1705 |
| 43rd IETF | 07/12/1998 | Orlando, FL, USA | Microsoft Corporation | 2124 |
| 42nd IETF | 24/08/1998 | Chicago, IL, USA | Motorola | 2106 |
| 41st IETF | 30/03/1998 | Los Angeles, CA, USA | — | 1775 |
| 40th IETF | 08/12/1997 | Washington, DC, USA | Newbridge Networks, Inc | 1897 |
| 39th IETF | 11/08/1997 | Munich, Germany | ISOC-Germany Chapter | 1308 |
| 38th IETF | 07/04/1997 | Memphis, Tennessee, USA | Federal Express | 1321 |
| 37th IETF | 09/12/1996 | San Jose, California, USA | Cisco Systems | 1993 |
| 36th IETF | 24/06/1996 | Montreal, Quebec, CANADA | — | 1283 |
| 35th IETF | 04/03/1996 | Los Angeles, California, USA | — | 1038 |
| 34th IETF | 04/12/1995 | Dallas, Texas, USA | MCI | 1007 |
| 33rd IETF | 17/07/1995 | Stockholm, Sweden | the Royal Institute of Technology; NORDUnet | 617 |
| 32nd IETF | 03/04/1995 | Danvers, Massachusetts, USA | FTP Software; NEARnet | 983 |
| 31st IETF | 05/12/1994 | San Jose, California, USA | Sun Microsystems | 1079 |
| 30th IETF | 25/07/1994 | Toronto, Ontario, CANADA | University of Toronto | 710 |
| 29th IETF | 28/03/1994 | Seattle, Washington, USA | NorthWestNet | 785 |
| Category | 2001 | 2002 | 2003 |
|---|---|---|---|
| Total Attendees | 5,739 | 5,111 | 4,216 |
| Net Meeting Revenue Per Attendee | $456 | $446 | $489 |
| Average Food & Beverage Per Attendee | $150 | $138 | $122 |
| Average Total Direct Meeting Cost Per Attendee [1] | $206 | $190 | $193 |
| Total CNRI/Foretec Secretariat Expenses Divided by Number of Meeting Attendees | $440 | $479 | $507 |
Notes:
- [1]
- Room rental fees are typical for non-U.S. meetings. Average total direct costs will thus be influenced by the choice of location of meetings.
| TOC |
This appendix contains standard, pro-forma Articles of Incorporation. Note well that tax lawyers often make significant alterations to standard Articles as they consider a 501(c)(3) application. They are included here merely as a sample for illustrative purposes only.
Commonwealth of Virginia — State Corporation Commission| Articles of Incorporation — Virginia Nonstock Corporation| Form SCC819, 07/03
———
The undersigned, pursuant to Chapter 10 of Title 13.1 of the Code of Virginia,State of Virginia, Title 13.1: Corporations, Limited Liability Companies, Business Trusts, Undated.[Virginia] state(s) as follows:
- A
- The name of the corporation's initial registered agent is: XXX
- B
- The initial registered agent is a domestic or foreign stock or nonstock corporation, limited liability company, or registered limited liability partnership authorized to transact business in Virginia.
As with the Sample Draft Articles, the Sample Draft Bylaws included here are a pro-forma, standard version. Substantial alteration may be required as legal counsel reviews the specific nature of an incorporation.
The name of the Corporation shall be The IETF Foundation (which shall hereinafter be referred to as the "Foundation").
Section 1: Purpose. The IETF Foundation shall be operated exclusively for nonprofit educational, charitable, and scientific purposes, including, without limitation, the purposes stated in the Foundation's Articles of Incorporation.
Section 2: Restrictions. No part of the net earnings of the IETF Foundation shall inure to the benefit of, or be distributable to, private persons, except that the Foundation shall be authorized and empowered to pay reasonable compensation for services rendered, and to make payments and distributions in furtherance of the purposes set forth in Article II, Section 1 hereof. Any other provision of these Bylaws to the contrary notwithstanding, the IETF Foundation shall not carry on any activities not permitted to be carried on by a corporation exempt from Federal Income Tax under Section 501(a) and Section 501(c)(3) of the Code. These Bylaws shall not be altered or amended in derogation of the provisions of this Section.
The Foundation shall have no members and no stockholders.
The office of the Foundation shall be as determined from time to time by the Board of Trustees within or outside of the State of Virginia.
Section 1: Authority and Responsibilities. The power, authority, property, and affairs of the Foundation shall at all times be exclusively exercised, controlled, and conducted by or under the authority of the Board of Trustees subject to any limitations set forth in the Articles of Incorporation and in accordance with the Virginia Nonstock Corporation Act as it now exists or hereafter may be amended.
Section 2: Board of Trustees Composition. The Board of Trustees shall consist of seven (7) Trustees.
Section 3: Types. There shall be two types of Trustees based on the reason for their selection: Position-Based Trustees, who are trustees because they hold some other office (for example IETF Chair) and Selected Trustees, who are not Position-Based Trustees.
Section 3: Terms. The term of office of Position-Based Trustees shall be co-terminious with the term of the office that qualifies the individual to be a board member. The term of office of Selected Trustees shall be three (3) years or until their successors have been selected and assume office. Selected Trustees may be selected to serve multiple terms.
Section 4: Selection of the Board of Trustee
Section 5: Quorum. A majority of the Trustees shall constitute a quorum for the transaction of business. Unless otherwise stated in these Bylaws, decisions of the Board of Trustees shall be made by the concurrence of a majority of members of the Board of Trustees present and voting. If at any meeting there is no quorum present, the Board must not transact business.
Section 6: Compensation and Reimbursement. No member of the Board of Trustees may receive compensation for his or her services as a Trustee. A Trustee shall, at their request, be reimbursed for actual, necessary and reasonable travel and subsistence expenses incurred by them in performance of their duties.
Section 7: Meetings. The Board of Trustees shall meet at least twice annually.
Section 8: Board Committees. The Trustees may elect or appoint one or more committees (including but not limited to an Executive Committee) and may delegate to any such committee or committees any or all of their powers, provided that any committee to which the powers of the Trustees are delegated shall consist solely of Trustees. Committees shall conduct their affairs in the same manner as is provided in these By Laws for the Trustees. The members of any committee shall remain in office at the pleasure of the Board of Trustees.
Section 9: Trustee Member Conflict of Interest.
Section 10. Approval of Meeting Minutes. Minutes of the Board of the IETF Foundation must be approved by a procedure adopted by the board and published on the IETF Foundation web site.
Section 1: Number. The officers of the IETF Foundation shall consist of a Chairman of the Board, a Treasurer and a Secretary, and such other inferior officers as the Board of Trustees may determine.
Section 2: Election Term of Office and Qualifications. All officers shall be elected annually by the vote of a majority of the Board of Trustees present and voting (excluding abstentions) at the Annual Meeting. The Treasurer and Secretary need not be members of the Board. The Chair of the IETF nor the chair of the IAB shall be the Chairman of the Board of the IETF Foundation.
Section 3: Resignation. An officer may resign by delivering his written resignation to the Foundation at its principal office or to the Chair or Secretary. Such resignation shall be effective upon receipt or upon such date (if any) as is stated in such resignation, unless otherwise determined by the Board.
Section 4: Removal. The Board of Trustees may remove any officer with or without cause by a vote of a majority of the entire number of Trustees then in office, at a meeting of the Board of Trustees called for that purpose. An officer may be removed for cause only if notice of such action shall have been given to all of the Trustees prior to the meeting at which such action is to be taken and if the officer so to be removed shall have been given reasonable notice and opportunity to be heard by the Board of Trustees.
Section 5: Vacancies. In case any elected officer position of the IETF Foundation becomes vacant, the majority of the Trustees in office, although less than a quorum, may elect an officer to fill such vacancy at the next meeting of the Board of Trustees, and the officer so elected shall hold office and serve until the next Annual Meeting.
Section 6: Chairman of the Board. The Chairman of the Board shall, when present, preside at all meetings of the Board of Trustees of IETF Foundation. If the Chairman is not available to preside over a meeting, the majority of the Trustees present shall select another Trustee to preside at that meeting only.
Section 7: Treasurer. The Treasurer shall have the custody of all funds, property, and securities of the IETF Foundation, subject to such regulations as may be imposed by the Board of Trustees. He or she may be required to give bond for the faithful performance of his or her duties, in such sum and with such sureties as the Board of Trustees may require or as required by law, whichever is greater. When necessary or proper, he or she may endorse on behalf of the IETF Foundation for collection, checks, notes and other obligations, and shall deposit same to the credit of the IETF Foundation at such bank or banks or depository as the Board of Trustees may designate. He or she shall make or cause to be made such payments as may be necessary or proper to be made on behalf of the IETF Foundation. He or she shall enter or cause to be entered regularly on the books of the IETF Foundation to be kept by him or her for that purpose, full and accurate account of all monies and obligations received and paid or incurred by him or her for or on account of the IETF Foundation, and shall exhibit such books at all reasonable times to any Trustee on application at the offices of the IETF Foundation incident to the Office of Treasurer, subject to the control of the Board of Trustees. Certain duties of the Treasurer as may be specified by the Board of Trustees may be delegated by the Treasurer.
Section 8: Secretary. The Secretary shall have charge of such books, records, documents, and papers as the Board of Trustees may determine, and shall have custody of the corporate seal. The Secretary shall keep, or cause to be kept the minutes of all meetings of the Board of Trustees. The Secretary may sign, with the Chairman, in the name and on behalf of the IETF Foundation, any contracts or agreements, and he or she may affix the corporate seal of the IETF Foundation. He or she, in general, performs all the duties incident to the Office of Secretary, subject to the supervision and control of the Board of Trustees, and shall do and perform such other duties as may be assigned to him or her by the Board of Trustees or the Chairman of the Board of Trustees. Certain duties of the Secretary as may be specified by the Board of Trustees may be delegated by the Secretary.
Section 9: Other Powers and Duties. Each officer shall have in addition to the duties and powers specifically set forth in these By Laws, such duties and powers as are customarily incident to his office, and such duties and powers as the Trustees may from time to time designate.
Section 1: By Laws. These By Laws may be amended by an affirmative vote of a majority of the Trustees then in office (excluding abstentions) at a regular meeting of the board or a meeting of the board called for that purpose as long as the proposed changes are made available to all trustees and posted to the IETF Announce list at least 30 days before any such meeting.
Section 2: Articles of Incorporation. The Articles of Incorporation of the IETF Foundation may amended by an affirmative vote of two-thirds vote of the Board of Trustees then in office at a regular meeting of the board or a meeting of the board called for that purpose as long as the proposed changes are made available to all trustees and posted to the IETF Announce list at least 30 days before any such meeting.
Upon the dissolution of the IETF Foundation, the IETF Foundation shall, after paying or making provisions for the payment of all of the liabilities of the Foundation, dispose of all of the assets of the IETF Foundation exclusively for the exempt purposes of the IETF Foundation in such manner or to such organization or organizations operated exclusively for social welfare or charitable purposes. Any such assets not so disposed of shall be disposed of by a court of competent jurisdiction of the county in which the principal office of the organization is then located, exclusively for such purposes. In the event of a sale or dissolution of the corporation, the surplus funds of the corporation shall not inure to the benefit of, or be distributable to, its Trustees, officers, or other private persons.
Section 1: Fiscal Year. The fiscal year of the IETF Foundation shall be from January 1 to December 31 of each year.
Section 2: Execution of Instruments. All checks, deeds, leases, transfers, contracts, bonds, notes and other obligations authorized to be executed by an officer of the Foundation in its behalf shall be signed by the Chairman of the Board or the Treasurer, or as the Trustees otherwise determine. A certificate by the Secretary as to any action taken by the Board of Trustees shall as to all persons who rely thereon in good faith be conclusive evidence of such action.
Section 3: Severability. Any determination that any provision of these By-Laws is for any reason inapplicable, illegal or ineffective shall not affect or invalidate any other provision of these By-Laws.
Section 4: Articles of Incorporation. All references in these By Laws to the Articles of Incorporation shall be deemed to refer to the Articles of Incorporation of the IETF Foundation, as amended and in effect from time to time.
Section 5: Gender. Whenever used herein, the singular number shall include the plural, the plural shall include the singular, and the use of any gender shall include all genders.
Section 6: Successor Provisions. All references herein: (1) to the Internal Revenue Code shall be deemed to refer to the Internal Revenue Code of 1986, as now in force or hereafter amended; (2) to the Code of the State of Virginia, or any Chapter thereof, shall be deemed to refer to such Code or Chapter as now in force or hereafter amended; (3) the particular sections of the Internal Revenue Code or such Code shall be deemed to refer to similar or successor provisions hereafter adopted; and (4) to the Request for Comment Series shall be deemed to refer to the Request for Comment Series as they are now in force or hereafter amended.
| TOC |
The IETF Administrative Entity is seeking a highly capable individual to serve as Administrative Director. You will report to the IETF Chair and be accountable to IETF community. This is a highly visible and very demanding job. You will be expected to:
The following characteristics are necessary for this job:
In-depth familiarity with the IETF prior to assuming this position is not required, but you must be able to quickly get up to speed and learn the unique culture and requirements of the organization. Likewise, long-term technical experience is not required, but you must be a quick learner and adept at using the Internet effectively.
You may work out of a home office as a telecommuter, or use the Internet Society facilities in Virginia. In either case, you should be prepared to travel to Virginia, IETF meetings, and the locations where the IETF has contractors.
Applicants should forward a resume, references, and any other relevant materials, with a cover letter explaining why they feel they are the right person for this position to:
URL
Applications are due no later than XXX, however the IETF Administrative Entity reserves the right to make a decision prior to this date or to extend this date in its sole discretion. Applications will be reviewed by an evaluation committee consisting of members of the IAB, IESG, and the community, and a decision shall be made by the Chairs of the IETF and the IAB with the advice and consent of the IESG and the IAB.
The list of applicants will not be posted publicly, but will be reviewed in confidence by members of the evaluation committee, the IAB, and the IESG.
| TOC |
The IETF Administrative Entity is soliciting proposals for the provision of computing and networking requirements, as detailed in this Request for Proposals ("Proposals"). Proposals from any individual person or persons or commercial or non-commercial vendor ("Vendor") are welcome.
Proposals must be received in written electronic form no later than [date]. Extensions may be granted solely in the discretion of the IETF Administrative Entity. Each Proposal, together with all supporting documentation, should be delivered to the following address:
[URI/ADDRESS]
Any inquiries regarding this Request must be submitted in written electronic form to the address listed above. Other than such inquiries, vendors are prohibited from contacting any person or institution involved in the selection process concerning this Request.
Each Proposal must specifically address each of the selection criteria listed below in a format corresponding to this Request. Each Proposal should also be accompanied by any technical or product literature that the Vendor wishes the IETF Administrative Entity to consider. If additional information is required by the IETF Administrative Entity to make a determination, such information may be requested, and shall be submitted in writing in the manner set forth above. Information other than the written Proposal and any information submitted in response to a request by the IETF Administrative Entity will not be considered by the IETF Administrative Entity.
The IETF Administrative Entity reserves the right to cancel this Request, in whole or in part, at any time. The IETF Administrative Entity may reject any or all Proposals received in response to this Request in its sole discretion. The IETF Administrative Entity makes no guarantee or commitment to purchase, license or procure any goods or services resulting from this Request.
Any Proposal which is selected by the IETF Administrative Entity shall be subject to execution of a binding agreement between the IETF Administrative Entity and the Vendor, which agreement shall be prepared by the IETF Administrative Entity and shall reflect the requirements outlined below and any additional provisions that are agreed upon in discussions between the IETF Administrative Entity and the Vendor. Selection may be conditioned upon acceptance of specific contractual terms and conditions, which may be provided to the Vendor during the selection process.
Each Vendor is responsible for its own costs and expenses involved in preparing and submitting its Proposal and any supplemental information requested by the IETF Administrative Entity. The IETF Administrative Entity shall not reimburse any such costs or expenses.
All Proposals submitted in accordance with this Request will be reviewed by a panel of experts drawn from the IETF community. A list of reviewers will be made available. The IETF Administrative Entity will notify Vendors of their selection following receipt and consideration of all Proposals. The IETF Administrative Entity will attempt to make its selection(s) by [date], but shall have full discretion to make a decision earlier or later than this date.
The following provisions apply to all bidders:
[Ed. This section will contain service level specifications. E.g., core bandwidth requirements, CPU capacity, disk space, and other variables. It will also contain core specifications, such as routing, DNS, and other services.]
[Ed. This section will contain the description for the Systems Administration function, including such tasks as keeping key software subsystems such as Apache installed and up-to-date, support for users, operating system upgrades, and other similar tasks.]
The Postmaster of the IETF Administrative Entity is responsible for the functioning and archiving of numerous mailing lists maintained by the IETF and for archiving specific IETF-related mailing lists maintained by others. Note that the archives of most IETF mailing lists are public and the bidder must describe how such archives will be accessed by the public.
The core mailing is described in [RFC3005]Harris, S., IETF Discussion List Charter, November 2000., and a policy with regards to posting rights may be found in [RFC3683]Rose, M., A Practice for Revoking Posting Rights to IETF mailing lists, February 2004.. You will find additional information on IETF mailing lists at:
In addition, the IETF maintains several dozen members-only lists in support of bodies such as the IAB, the IESG, and certain IRTF task forces (see [RFC2014]Weinrib, A. and J. Postel, IRTF Research Group Guidelines and Procedures, October 1996., [RFC2850]Internet Architecture Board and B. Carpenter, Charter of the Internet Architecture Board (IAB), May 2000., and [RFC3710]Alvestrand, H., An IESG charter, February 2004. for more details on these bodies). IETF administrators and chairs of various groups typically will form ad hoc lists which they administer for various tasks.
Familiarity and expertise in administering high-volume lists and in maintaining large numbers of archived lists is necessary. The ability to provide administrative facilities that allow the IETF to delegate authority for moderation and creation of lists is also necessary. Finally, you should be experienced in the very latest spam fighting technologies.
You may propose to provide service in one of two ways:
Your bid should clearly explain what tools you will use, the types of interfaces you will provide to list maintainers and participants, and you would handle issues such as spam. You should also be very clear in your proposal about your understanding of the role and duties of the postmaster.
This task has the responsibility for the look and feel of the IETF network presence, particularly the web site. A series of support contracts will be available to help support this function.
In addition, this task has responsibility to provide overall support, in cooperation with the sysadmin and other contractors, to a variety of working groups, directorates, and other activities that require a workspace.
Your proposal must demonstrate that you are experienced at producing highly standards-conformant and functional network presences and supporting a large and diverse community of users. This is a highly hands-on task.
We are looking for creative proposals from experienced professionals to organize and support the meetings of the IETF.
You will work with the Administrative Director of the IETF and the IETF leadership to organize the three annual meetings of the IETF. Based on current practice, you should expect 1-2 of those meetings to be in the United States and 1-2 of those meetings to be in other countries, though this may change based on the requirements of the IETF. We expect approximately 1500 attendees per meeting, though in the past this number has approached 3,000 based on the location of the meeting and the state of the economy.
You should have very strong experience in meeting planning, particularly working meetings with large numbers of participants. You should be intimately familiar with the details of booking appropriate venues, working with hotel and conference center staff, and providing clear and concise communications with meeting attendees.
Your proposal should detail the mechanisms you would use to provide a simple registration and payment procedure for attendees. You will be able to draw on webmaster and sysadmin support for the IETF, for example, if you would like to provide a secure payment mechanism on the IETF web site. Your proposal should also detail how you will provide additional resources on-site (e.g., staffing a registration desk and other requirements that require additional people).
As part of this function, you will work with Local Hosts (when available), who provide a sophisticated network infrastructure to support the meeting, as well as a team of volunteers who provide additional terminal room support, real-time audio and video streaming from the meeting and other functions.
This requirement is for general high-level administrative support for the day-to-day functioning of the IETF. You will work with the Administrative Director of the IETF to help make the organization function smoothly on a day-to-day basis.
The tasks that are encompassed in this function include:
[Ed. More detail to be filled in here by a transition team.]
All proposals will be evaluated using a process that consists of the following steps:
The IETF Administrative Entity will consider price, experience, technical smarts, and a variety of other factors. Note well that the IETF Administrative Entity will not decide on price alone. Overall benefit to the IETF community will be the prime consideration.
| TOC |
| F | |
| functions 1, 2, 3, 4, 5, 6, 7 | |
| M | |
| mechanisms 1, 2, 3, 4, 5, 6, 7, 8 | |
| O | |
| opinions 1, 2 | |
| options 1, 2, 3, 4, 5, 6, 7, 8 | |
| P | |
| pillars 1, 2, 3 | |
| R | |
| recommendations 1, 2, 3, 4, 5, 6, 7 | |
| S | |
| strategies 1, 2, 3 |
| TOC |
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Funding for the RFC Editor function is currently provided by the Internet Society.