| 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 May 2, 2005.
Copyright (C) The Internet Society (2004).
This document describes the structure of the IETF Administrative Support Activity (IASA) as an IETF-controlled activity housed within the Internet Society (ISOC) legal umbrella. It defines the roles and responsibilities of the IETF Administrative Oversight Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IAOC.
1.
Introduction
1.1
Editors' Notes
1.2
Open issues
2.
Definitions and Principles
2.1
Alphabet Soup
2.2
Principles of the IASA, IETF and ISOC relationship
2.3
Community Consensus and Grant of Authority
3.
Structure of the IASA
3.1
IAD Responsibilities
3.2
IAD Committees
3.3
IAOC Responsibilities
3.4
Relationship of the IAOC to Existing IETF Leadership
3.5
IAOC Decision Making
4.
IAOC Membership, Selection and Accountability
4.1
Initial IAOC Selection
5.
IASA Funding
5.1
Divisional Accounting
5.2
IETF meeting revenues
5.3
Designated donations, monetary and in-kind
5.4
Other ISOC support
5.5
Operating Reserve
6.
IASA Budget Process
7.
ISOC Responsibilities for IASA
8.
Security Considerations
9.
IANA Considerations
10.
Acknowledgements
11.
References
11.1
Normative References
11.2
Informative References
§
Authors' Addresses
A.
Change Log
§
Intellectual Property and Copyright Statements
| TOC |
This document describes the structure of the IETF Administrative Support Activity (IASA) as an IETF-controlled activity housed within the Internet Society (ISOC) legal umbrella. It defines the roles and responsibilities of the IETF Administrative Oversight Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IAOC.
The IETF undertakes its technical activities as an ongoing, open, consensus-based process. This document defines an administrative support structure intended to be responsive to the administrative needs of the IETF technical community, and describes how that support structure fits under ISOC's organizational umbrella. This document does not affect the ISOC-IETF working relationship as it relates to standards development or the communication of technical advice relevant to the policy and educational goals of ISOC.
The IETF Administrative Support Activity (IASA) provides the administrative structure required to support the IETF standards process and to support the IETF's technical activities. As of the time at which this document was written, this included the work of IETF working groups, the IESG, the IAB, and the IRTF. Should the IETF standards process at some future date come to include other technical activities, the IASA shall provide administrative support for those activities as well. Such support includes, as appropriate, undertaking or contracting for the work described in [RFC3716]Advisory, IAB., The IETF in the Large: Administration and Execution, March 2004.,including IETF document and data management, IETF meetings, and any operational agreements or contracts with the RFC Editor and IANA. The IASA is also ultimately responsible for the financial activities associated with IETF administrative support such as collecting IETF meeting fees, paying invoices, managing budgets and financial accounts, and so forth.
The IASA is responsible for ensuring that the IETF's administrative needs are met, and met well. The IETF does not expect the IASA to undertake the bulk of this work directly; rather, the IETF expects the IASA to contract this work from others, and manage these contractual relationships to achieve efficiency, transparency and cost effectiveness.
The IASA is distinct from IETF-related technical functions, such as the RFC Editor, the Internet Assigned Numbers Authority (IANA), and the IETF standards process itself. The IASA has no influence on the technical decisions of the IETF or on the technical contents of IETF work. Note, however, that this in no way prevents people who form part of the IASA from participating as individuals in IETF technical activities.
This document is still a work in progress, and, due to time pressure and lack of a clear consensus on some issues, the editors have not yet been able to incorporate all of the outstanding change requests. Work will continue after this version has shipped.
In some cases the best way to handle a particular suggestion (in the editors' opinion, at any rate) has been to incorporate new text with an "Editors' note" which attempts to explain the change.
The editors request that substantive comments and requested changes be sent, one per message, with a clear and meaningful subject line on each message, as this will make it easier for the editors to keep track of change requests.
Summary of open issues for which we need to find specific IETF consensus so that editors can put in correct and agreed-upon text.
Do we need "pre-nuptial" agreement text as part of the BCP? Currently, the doc does not have text for it. Seems IETF consensus on choosing Scenario O means that we (the IETF) trust ISOC.
Do we need separate bank accounts? Consensus seems to be emerging not to ask for that. So this doc does not claim so now. Instead we specify "Divisional Accounting" (Section 5.1Divisional Accounting).
Do we need to add text to protect IETF from an IAD or an IAOC going amok? Seems that IAD can be suspended/fired and IAOC can be recalled, and so maybe that is sufficient.
Are designated donations specified appropriately? In particular, does requiring that not be "unduly restricted" address previously stated concerns? That is what current text says.
Do we need to be more specific as to how reserves are built for emergency situations, or can we leave that at ISOC's discretion?
We have added a set of principles (Section 2.2Principles of the IASA, IETF and ISOC relationship). The remainder of the document still contains a fair amount of detail (based on the principles) but potentially some of those details can be removed. It is not clear whether the IETF wants to keep the details or remove them.
There has been a suggestion that we may need some more wording on startup phase. Not clear exactly what might be needed. Send text if you feel additions are needed.
Not clear yet if we have too much about the IAD task. Should that task be specified elsewhere, initially by the Transition Team, later by IAOC or some committee?
Would we want the IAOC to sign off on the yearly (or more frequent) reports in some formal sense within a reasonable amount of time? This might protect the IAD from some form of open-ended lingering responsibility for previous years. It might also protect against having somebody, five years from now, state "this is wrong and by the way this was already wrong N years ago"
How should we deal with conflict between IAD, IAOC and ISOC? This is complicated by the fact that ISOC officially employs the IAD while a small committee hires and fires and evaluates the IAD.
Related to above: What happens if/when there is a disagreement between the ISOC BoT and IAOC regarding business decisions, spending, hiring, etc?
Do we need wording about the ownership of IETF tools and data? We have some text (in Section 2.2Principles of the IASA, IETF and ISOC relationship) about IPR, but does that fully cover tools and data?
| TOC |
This section describes terminology and underlying principles used in the rest of this document.
Although most of the terms, abbreviations, and acronyms used in this document are reasonably well-known, first-time readers may find this alphabet soup confusing. This section therefore attempts to provide a quick summary.
- IAB
- Internet Architecture Board (see [RFC2026]Bradner, S., The Internet Standards Process -- Revision 3, October 1996., [RFC2850]Internet Architecture Board and B. Carpenter, Charter of the Internet Architecture Board (IAB), May 2000.).
- IAD
- Internet Administrative Director, defined by this document.
- IAOC
- Internet Administrative Oversight Committee, defined by this document.
- IESG
- Internet Engineering Steering Group (see [RFC2026]Bradner, S., The Internet Standards Process -- Revision 3, October 1996., [RFC3710]Alvestrand, H., An IESG charter, February 2004.).
- ISOC
- Internet Society (see [RFC2031]Huizer, E., IETF-ISOC relationship, October 1996. and [ISOC]Internet Society, Internet Society By-Laws, February 2001.).
This section attempts to describe principles underlying the mechanisms described in this document.
The remainder of this document contains details based on the above principles.
The IETF is a consensus-based group, and authority to act on behalf of the community requires a high degree of consensus and the continued consent of the community. After a careful process of deliberation, a broad-based community consensus emerged to house the IETF Administrative Support Activity (IASA) within the Internet Society. This document reflects that consensus.
Termination and change: Any change to this agreement shall require a similar level of community consensus and deliberation and shall be reflected by a subsequent Best Current Practice (BCP) document.
| TOC |
The IASA structure is designed to ensure accountability and transparency of the IETF administrative and fiscal activities to the IETF community. The IETF Administrative Oversight Committee (IAOC) directs and oversees the IASA. The IAOC consists of volunteers, all chosen directly or indirectly by the IETF community, as well as appropriate ex officio appointments from ISOC and IETF leadership. The IAOC shall be accountable to the IETF community for the effectiveness, efficiency and transparency of the IASA.
The IASA consists initially of a single full-time ISOC employee, the IETF Administrative Director (IAD), an officer entitled to act on behalf of the IASA at the direction of the IAOC. The IAD is likely to draw on financial, legal and administrative support furnished by ISOC support staff or consultants. Costs for ISOC support staff and consultants are allocated based on actual expenses or on some other allocation model determined by consultation between the IAOC and ISOC.
Although the IAD is an ISOC employee, he or she works under the direction of the IAOC. The IAD is selected and hired by a committee of the IAOC. The members of this committee are appointed by the IAOC, and consist at minimum of the ISOC President and the IETF Chair. This same committee is responsible for setting the IAD's initial compensation, reviewing the performance of the IAD periodically, and determining any changes to the IAD's employment and compensation.
In principle, IETF administrative functions should be outsourced. The IAD is responsible for negotiating and maintaining such contracts, as well as providing any coordination necessary to make sure the IETF administrative support functions are covered properly. The IAOC is accountable for the structure of the IASA and thus decides which functions are to be outsourced. All outsourcing must be via well-defined contracts or equivalent instruments. If any functions are performed in-house, they must be clearly specified and documented with well-defined deliverables, service level agreements, and transparent accounting for the cost of such functions.
The IAD is responsible for working with the IAOC and others to understand the administrative requirements of the IETF, and for managing the IASA to meet those needs. This includes determining the structure of the IASA effort, establishing an operating budget, negotiating contracts with service providers, managing the business relationship with those providers, and establishing mechanisms to track their performance. The IAD may also manage other contractors or ISOC employees (such as support staff) as necessary, when such contractors or employees are engaged in IASA-related work.
The IAD is responsible for running IASA in an open and transparent manner, and for producing regular monthly, quarterly, and annual financial and operational updates for IAOC and IETF community review.
The IAD is responsible for administering the IETF finances, managing a separate financial account for the IASA, and establishing and administering the IASA budget. While ISOC will need to put some financial controls in place to protect ISOC's fiscal stability, the IAD (with IAOC approval, as appropriate) should have signing authority consistent with carrying out IASA work effectively, efficiently and independently. If there are any problems regarding the level of financial approval granted to the IAD, the IAOC and ISOC shall work out a policy that is mutually agreeable, and shall do so within a reasonable timeframe.
The IAD negotiates service contracts, with input, as appropriate, from other bodies, and with review, as appropriate, by the IAOC. The IAOC should establish guidelines for what level of review is expected based on contract type, size, cost, or duration. Contracts are executed by ISOC, on behalf of the IASA, after whatever review ISOC requires to ensure that the contracts meet ISOC's legal and financial requirements.
The IAD and IAOC are responsible for making all business decisions regarding the IASA. In particular, the ISOC Board of Trustees shall not have direct influence over the choice of IASA contractors or IETF meeting sponsors. This restriction is meant to enforce the separation between fund raising and the actual operation of the standards process.
The IAD prepares an annual budget, which is subject to review and approval by the IAOC. The IAD is responsible for presenting this budget to the ISOC Board of Trustees, as part of ISOC's annual financial planning process. The IAOC is responsible for ensuring the budget's suitability for meeting the IETF community's administrative needs, but the IAOC does not bear fiduciary responsibility for ISOC. The ISOC Board therefore needs to review and understand the budget and planned activity in enough detail to carry out their fiduciary responsibility properly. The IASA publishes its complete budget to the IETF community each year.
The IAOC, in consultation with the IAB and the IESG, designates the person or people who carry out the tasks which other IETF process documents say are carried out by the IETF Executive Director.
Editors' note: The preceding paragraph has generated some comments, given that the role of the IETF Executive director is mentioned in a number of documents, some of which are fairly old and dusty. The editors actively solicit feedback on whether this paragraph is ok as it stands.
The IAD may constitute special-purpose, chartered committees to bring in expertise (on topics such as finance, IETF process, or tools), to engage volunteers in IASA activities, or to gain additional perspectives. Such committees may consist of subsets of the IAOC, IAB or IESG, selected IETF participants, or external experts, depending on the need. These committees are advisory in nature -- the IAD is responsible for the outcome, including presenting and supporting any decisions or work items to the IAOC and the IETF community, as appropriate.
The IAOC's role is to provide appropriate direction to the IAD, to review the IAD's regular reports, and to oversee the IASA functions to ensure that the administrative needs of the IETF community are being properly met. The IAOC's mission is not to be be engaged in the day-to-day administrative work of IASA, but rather to provide appropriate direction, oversight and approval.
Therefore, the IAOC's responsibilities are:
The IAOC's role is to direct and review, not perform, the work of the IAD and IASA. The IAOC holds periodic teleconferences and face-to-face meetings as needed to carry out the IAOC's duties efficiently and effectively.
The IAOC is directly accountable to the IETF community for the performance of the IASA. However, the nature of the IAOC's work involves treating the IESG and IAB as internal customers. The IAOC and the IAD should not consider their work successful unless the IESG and IAB are satisfied with the administrative support that they are receiving.
The IAOC attempts to reach all decisions unanimously. If unanimity cannot be achieved, the IAOC chair may conduct informal polls to determine the consensus of the group. In cases where it is necessary, some decisions may be made by voting. For the purpose of judging consensus or voting, only the "voting members" (as defined in Section 4IAOC Membership, Selection and Accountability) shall be counted. If voting results in a tie, then IAOC chair decides how to proceed with the decision process.
Editors' note: The above text was changed from the previous version. Are the voting rules in the preceding paragraph sufficient? Do we need to define rules for determining a quorum? The editors would prefer to specify the minimum necessary mechanism here, but no less. The text above seems to be acceptable to most.
Decisions of IAOC members or the entire IAOC are subject to appeal using the procedures described in RFC 2026 [RFC2026]Bradner, S., The Internet Standards Process -- Revision 3, October 1996.. Appeals of IAOC decisions go first to the IESG, then continue up the chain as necessary to the IAB and the ISOC Board of Trustees.
The IAOC plays no role in appeals of WG Chair, IESG, or IAB decisions.
| TOC |
The IAOC will consist of eight voting members who will be selected as follows:
The IETF Administrative Director also serves, ex officio, as a non-voting member of the IAOC.
The IAOC may also choose to invite liaisons from other groups, but is not required to do so; the IAOC decides whether or not to have a liaison to any particular group. Any such liaisons are non-voting. Responsibility for selecting the individual filling a particular liaison role with the body from which the IAOC has requested the liaison.
Editors' note: There has been some question about whether the IAB Chair should be a voting or non-voting member of the IAOC. There are multiple trade-offs here, and this should be discussed by the community. Discussion up till November 15th seems to indicate to go for voting member, as currently described in the text above.
Earlier versions of this document used the term "liaison" to refer to non-voting IAOC members, but this usage has since been dropped. However, the term begs the question of whether the IAOC might wish to have -other- liaisons (ex officio or not), such as liaisons to the RFC editor or the IANA. The text above has been modified to permit this. Feedback requested.
Appointed members of the IAOC serve two year terms. IAOC terms normally end at the first IETF meeting of a year, just as as IAB and IESG terms do.
The members of the IAOC choose their own chair each year using a consensus mechanism of their choosing. Any appointed voting member of the IAOC may serve as the IAOC Chair; the IETF Administrative Director, the IETF Chair, the IAB Chair, the ISOC President/CEO, and non-voting liaisons are not eligible to serve as IAOC Chair. The IAOC Chair's role is to manage the IAOC. The IAOC Chair has no formal duty to represent the IAOC, except as directed by IAOC consensus.
The two NomCom-selected IAOC members are chosen using the procedures described in RFC 3777 [RFC3777]Galvin, J., IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees, June 2004.. For the initial IAOC selection, the IESG will provide the list of desired qualifications for these positions; in later years, the IAOC will provide this qualification list. The IESG will serve as the confirming body for IAOC appointments by the NomCom.
While there are no hard rules regarding how the IAB and the IESG should select members of the IAOC, such appointees need not be current IAB or IESG members (and probably should not be, if only to avoid overloading the existing leadership). The IAB and IESG should choose people with some knowledge of contracts and financial procedures, who are familiar with the administrative support needs of the IAB, the IESG, or the IETF standards process. The IAB and IESG should follow a fairly open process for these selections, perhaps with an open call for nominations or a period of public comment on the candidates. The procedure for IAB selection of ISOC Board of Trustees [RFC3677]Daigle, L. and Internet Architecture Board, IETF ISOC Board of Trustee Appointment Procedures, December 2003. might be a good model for how this could work. After the IETF gains some experience with IAOC selection, these selection mechanisms should be more formally documented.
Although the IAB, the IESG and the ISOC Board of Trustees choose some members of the IAOC, those members do not directly represent the bodies that chose them. All members of the IAOC are accountable directly to the IETF community. To receive direct feedback from the community, the IAOC holds an open meeting at least once per year at an IETF meeting. This may take the form of an open IAOC plenary or a working meeting held during an IETF meeting slot. The form and contents of this meeting are left to the discretion of the IAOC Chair. The IAOC should also consider open mailing lists or other means to establish open communication with the community.
IAOC members are subject to recall in the event that an IAOC member abrogates his or her duties or acts against the best interests of the IETF community. Any appointed IAOC member, including those appointed by the IAB, IESG or ISOC Board of Trustees, may be recalled using the recall procedure defined in RFC 3777 [RFC3777]Galvin, J., IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees, June 2004.. IAOC members are not, however, subject to recall by the bodies that appointed them.
The initial IAOC selection will start after this document is approved as a BCP by the IESG and accepted by the ISOC Board of Trustees. The IESG, IAB, and ISOC Board of Trustees should make their selections within 45-days of BCP approval, and the NomCom should make their selections as quickly as possible while complying with the documented NomCom procedures. The IAOC will become active as soon as a majority (three or more) of the appointed members have been selected.
Initially, the IESG and the ISOC Board of Trustees will make one-year appointments, the IAB will make a two-year appointment, and the NomCom will make one one-year appointment and one two-year appointment. This will establish a pattern in which approximately half of the IAOC is selected each year.
| TOC |
Editors' note: Changes were made to this section to be more specific about funding sources and where they go. Some text has also been added or changed regarding the reserve funds.
Disclaimer: The IAOC is authorized to vary the procedures for legal, accounting or practical reasons as long as it reports the variance to the IETF community and triggers an update of this BCP.
The IASA manages money from three sources:
Note that the goal is to achieve and maintain a viable IETF support function based on meeting fees and designated donations. The IETF community expects the IAOC and ISOC to work together to attain that goal, and recognizes that doing so will require striking some sort of balance. For example, dropping the meeting fees to $0 and expecting ISOC to pick up the slack would not be viable in the long term, and neither would be raising the meeting fees to prohibitive levels in order to fund all non-meeting-related activities.
Editors' note: Added following paragraph on Divisional accounting (thanks Glenn Ricart) and then removed the text about "deposit in IASA account" from subsections below. To the best of the editors' ability to determine the will of the community, there does not appear to be enough support to prescribe separate bank accounts, and Divisional Accounting as described below should suffice to achieve transparency. If you do not agree, please speak up ASAP.
For bookkeeping purposes, funds managed by IASA should be kept in a separate set of accounts which can be rolled-up periodically to the equivalent of a balance sheet and a profit and loss statement for IASA alone after taking into account the effect of common items paid for or received by ISOC as a whole.
Meeting revenues are an important source of funds for IETF functions. The IAD, in consultation with the IAOC, sets the meeting fees as part of the budgeting process. All meeting revenues will be credited to the appropriate IASA account.
Donations are an essential component of funding. The IASA undertakes no direct fund-raising activities. This establishes a practice of separating IETF administrative and standards activities from fund-raising activities, and helps ensure that no undue influence may be ascribed to those from whom funds are raised.
ISOC will create and maintain appropriate structures and programs to coordinate donations intended to support the work of the IETF, and these will include mechanisms for both in-kind and direct contributions to the work supported by IASA. Since ISOC will be the sole entity through whom donations may be made to the work of the IETF, ISOC will ensure that those programs are not unduly restrictive. For the benefit of individuals, smaller organizations and countries with developing economies, it will maintain programs that allow for designated donations to the IETF.
Editors' note: Some have suggested we need explicit IETF consensus on the above. So if you do not agree, please speak up ASAP.
Editors' note: Removed "either using an overhead model or other unrestricted donation program." because it is too detailed and prescriptive. Send objections ASAP if you do not agree.
ISOC will create appropriate administrative structures to coordinate such donations with the IASA. In particular, it is important that in-kind contributions be "useful". In-kind resources are owned by the ISOC on behalf of the IETF and shall be reported and accounted for in a manner that identifies them as such. Designated monetary donations will be credited to the appropriate IASA account.
Other ISOC support shall be based on the budget process as specified in Section 6IASA Budget Process. ISOC will credit the appropriate IASA accounts at least quarterly.
If ISOC pays any other IETF expenses directly, without transferring funds to the IASA, this will be documented as a footnote to the IASA accounts.
In normal operating circumstances, the IASA should have an operating reserve for its activities sufficient to cover 6-months of non-meeting operational expenses, plus twice the recent average for meeting contract guarantees. Rather than having the IASA attempt to build that reserve in its separate accounts, the IASA looks to ISOC to build and provide that operational reserve, through whatever mechanisms ISOC deems appropriate: line of credit, financial reserves, meeting cancellation insurance, and so forth. Such reserves do not appear instantaneously; the goal is to reach this level of reserves within 3 years after the creation of the IASA. Such funds shall be held in reserve for use by IASA for use in the event of IETF meeting cancellation or other unexpected fiscal emergencies. These reserves shall only be spent on IETF support functions.
| TOC |
While the IASA sets a budget for the IETF's administrative needs, its budget process clearly needs to be closely coordinated with ISOC's. The specific timeline will be established each year. A general annual timeline for budgeting will be:
- July 1:
- The IAD presents a budget proposal for the following fiscal year, with 3 year projections, to the IAOC.
- August 1:
- The IAOC approves the budget proposal for IETF purposes, after any appropriate revisions. As the ISOC President is part of the IAOC, the IAOC should have a preliminary indication of how the budget will fit with ISOC's own budgetary expectations. The budget proposal is passed to the ISOC Board of Trustees for review in accordance with their fiduciary duty.
- September 1:
- The ISOC Board of Trustees approves the budget proposal provisionally. During the next 2 months, the budget may be revised to be integrated in ISOC's overall budgeting process.
- November 1:
- Final budget to the ISOC Board for approval.
The dates described above are subject to change, and will most likely be modified each year based on the dates of the second and third IETF meetings of that year.
The IAD shall provide monthly accountings of expenses, and shall update expenditures forecasts every quarter. This may require adjustment of the IASA budget: if so, the revised budget will need to be approved by the IAOC, the ISOC President/CEO and, if necessary, the ISOC Board of Trustees.
| TOC |
Within ISOC, support for the IASA should meet the following goals:
- Transparency:
- The IETF community should have complete visibility into the financial and legal structure of the ISOC standards activity. In particular, a detailed budget for the entire standards activity, quarterly financial reports, and audited annual financials should all be available to the IETF community. In addition, key contract material and MOUs should also be publicly available. The IAOC is responsible for providing regular overviews of the state of the IASA to the IETF community.
- Unification:
- As part of this arrangement, ISOC's sponsorship of the RFC Editor, IAB and IESG shall be managed as part of the IASA under the IAOC.
- Independence:
- The IASA should be financially and legally distinct from other ISOC activities. IETF meeting fees shall be deposited in a separate IETF-specific financial account and used to fund the IASA under the direction and oversight of the IAOC. Any fees or payments collected from IETF meeting sponsors should also be deposited into this account. The IAD administers this account and uses it to fund the IASA in accordance with a budget and policies developed as described above.
- Support:
- ISOC may, from time to time, choose to transfer other funds into the IASA account to fund IETF administrative projects or to cover IETF meeting revenue shortfalls. There may also be cases where ISOC chooses to loan money to the IASA to help with temporary cash flow issues. These cases should be documented carefully and tracked on both sides. ISOC will work to provide the operational reserve for IASA functioning described above.
- Removability:
- While there is no current plan to transfer the legal and financial home of the IASA to another corporation, the IASA should be structured to enable a clean transition in the event that the IETF community decides, through BCP publication, that such a transition is required. In such a case case, the IAOC will give ISOC a minimum of six months notice before the transition formally occurs. During that period, the IAOC and ISOC will work together to create a smooth transition that does not result in any significant service outages or missed IETF meetings. All contracts executed by ISOC on behalf of IASA should either include a clause allowing termination or transfer by ISOC with six months notice, or should be transferable to another corporation in the event that the IASA transitions away from ISOC. Any accrued funds or IETF-specific intellectual property rights concerning administrative data and tools should also transition to the new entity.
Within the constraints outlined above, all other details of how to structure this activity within ISOC (whether as a cost center, a department, or a formal subsidiary) shall be determined by ISOC in consultation with the IAOC.
| TOC |
This document describes the structure of the IETF's administrative support activity. It introduces no security considerations for the Internet.
| TOC |
This document has no IANA considerations in the traditional sense. However, some of the information in this document may affect how the IETF standards process interfaces with IANA, so IANA may be interested in the contents.
| TOC |
The editors would like to thank the following people for their feedback on the original "Scenario O" e-mail message or intermediate versions of this document: Bernard Aboba, Harald Alvestrand, Scott Bradner, Brian Carpenter, Dave Crocker, Tony Hain, Joel Halpern, Sam Hartman, John Klensin, Valdis Kletnieks, Eliot Lear, Carl Malamud, and Glenn Ricart.
Particular thanks are due to Leslie Daigle and Margaret Wasserman, who wrote the original "Scenario O" message and edited the earliest versions of this document.
This document was written using the xml2rfc tool described in RFC 2629 [RFC2629]Rose, M., Writing I-Ds and RFCs using XML, June 1999..
No doubt the above list is incomplete. We apologize to anyone whom we left out.
| TOC |
| TOC |
| [RFC2026] | Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. |
| [RFC3716] | Advisory, IAB., "The IETF in the Large: Administration and Execution", RFC 3716, March 2004. |
| [RFC3777] | Galvin, J., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 3777, June 2004. |
| TOC |
| [ISOC] | Internet Society, "Internet Society By-Laws", February 2001. |
| [RFC2031] | Huizer, E., "IETF-ISOC relationship", RFC 2031, October 1996 (TXT, HTML, XML). |
| [RFC2629] | Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999 (TXT, HTML, XML). |
| [RFC2850] | Internet Architecture Board and B. Carpenter, "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000. |
| [RFC3668] | Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. |
| [RFC3677] | Daigle, L. and Internet Architecture Board, "IETF ISOC Board of Trustee Appointment Procedures", BCP 77, RFC 3677, December 2003. |
| [RFC3710] | Alvestrand, H., "An IESG charter", RFC 3710, February 2004. |
| TOC |
| Rob Austein (editor) | |
| Internet Systems Consortium | |
| 950 Charter Street | |
| Redwood City, CA 94063 | |
| USA | |
| EMail: | sra@isc.org |
| Bert Wijnen (editor) | |
| Lucent Technologies | |
| Schagen 33 | |
| 3461 GL Linschoten | |
| NL | |
| EMail: | bwijnen@lucent.com |
| TOC |
Note to RFC Editor: Please remove this entire appendix prior to publication.
This document was produced as part of the overall IETF Administrative Restructuring (AdminRest) effort. Information about the effort and related documents can be found at:
http://www.alvestrand.no/ietf/adminrest
We are using an issue tracker to track the editorial and substantive feedback on this document. It can be found at:
https://rt.psg.com (user: ietf, password: ietf, queue: iasa-bcp).
Changes in draft-ietf-iasa-bcp-01.txt:
Changes in draft-ietf-iasa-bcp-00.txt:
Changes in draft-wasserman-iasa-bcp-01.txt:
Origination of draft-wasserman-iasa-bcp-00.txt:
draft-wasserman-iasa-bcp-00.txt was derived from an e-mail message written by Leslie Daigle and Margaret Wasserman and posted to the IETF by Leslie Daigle. The original message can be found at:
http://www1.ietf.org/mail-archive/web/ietf/current/msg31326.html
This document was derived from the "Draft BCP" portion of that message and has been updated based on comments received.
$Revision: 1.1 $
| 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.