The request for review should be addressed to the IAOC chair and
should include a description of the decision or action to be
reviewed, an explanation of how, in the requestor’s opinion, the
decision or action violates the BCPs or operational guidelines, and a
suggestion for how the situation could be rectified. All requests
for review shall be posted publicly, and the IAOC is expected to
respond to these requests within a reasonable period, typically
within 90 days. It is up to the IAOC to determine what type of
review and response is required, based on the nature of the review
request. Based on the results of the review, the IAOC may choose to
overturn their own decision, to change their operational guidelines
to prevent further misunderstandings, to take other action as
appropriate, or just to publish the review result and take no other
action.
If a member of the community is not satisfied with the IAOC’s
response to his or her review request, he or she may escalate the
issue by appealing the decision or action to the IAB, using the
appeals procedures outlined in RFC 2026 [RFC2026]. If he or she is
not satisfied with the IAB response, he or she can escalate the issue
to the ISOC Board of Trustees, as described in RFC 2026.
The reviewing body (the IAB or ISOC Board of Trustees) shall review
the decision of the IAD or IAOC to determine whether it was made in
accordance with existing BCPs and operational guidelines. As a
result of this review, the reviewing body may recommend to the
community that the BCPs governing IAOC actions should be changed.
The reviewing body may also advise the IAOC to modify existing
operational guidelines to avoid similar issues in the future and/or
it may advise the IAOC to re-consider their decision or action. It
may also recommend that no action be taken, based on the review.
In exceptional cases, when no other recourse seems reasonable, the
reviewing body may overturn or reverse a non-binding decision or
action of the IAOC. This should be done only after careful
consideration and consultation with the IAOC regarding the
ramifications of this action. In no circumstances may the IAB or
ISOC Board of Trustees overturn a decision of the IAOC that involves
a binding contract or overturn a personnel-related action (such as
hiring, firing, promotion, demotion, performance reviews, salary
adjustments, etc.).
4. IAOC Membership, Selection and Accountability
The IAOC shall consist of eight voting members who shall be selected
as follows:
o Two members appointed by the IETF Nominations Committee (NomCom);
o One member appointed by the IESG;
o One member appointed by the IAB;
o One member appointed by the ISOC Board of Trustees;
o The IETF Chair (ex officio);
o The IAB Chair (ex officio);
o The ISOC President/CEO (ex officio).
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 it
is not required to do so; the IAOC decides whether to have a liaison
to any particular group. Any such liaisons are non-voting.
Responsibility for selecting the individual filling a particular
liaison role lies with the body from which the IAOC has requested the
liaison.
Subject to paragraph 2 of Section 4.1, appointed members of the IAOC
serve two-year terms. IAOC terms normally end at the end of the
first IETF meeting of a year.
The members of the IAOC shall select one of its appointed voting
members to serve as the chair of the IAOC. The term of the IAOC
chair shall be one year from the time of selection or the remaining
time of his or her tenure on the IAOC, whichever is less. An
individual may serve any number of terms as chair, if selected by the
IAOC.
The Chair serves at the pleasure of the IAOC and may be removed from
that position at any time by a vote of 2/3 of the voting IAOC
members, not counting the IAOC chair.
The chair of the IAOC shall have the authority to manage the
activities and meetings of the IAOC.
The two NomCom-appointed IAOC members are chosen using the procedures
described in RFC 3777 [RFC3777]. 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] might be a good model for how this could work.
After the IETF gains some experience with IAOC selection, these
selection mechanisms should be documented more formally.
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 any appointed
by the IAB, IESG, or ISOC Board of Trustees, may be recalled using
the recall procedure defined in RFC 3777 [RFC3777]. IAOC members are
not, however, subject to recall by the bodies that appointed them.
If a vacancy occurs among the appointed members, this is filled by
the appointing body for that position according to its procedures.
The IAOC members shall not receive any compensation from the IASA,
ISOC, or IETF for their services as members of the IAOC.
The IAOC shall set and publish rules covering reimbursement of
expenses, and such reimbursement shall generally be for exceptional
cases only.
4.1. Initial IAOC Selection
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.
5. IASA Funding
The IASA manages money from three sources:
1. IETF meeting revenues;
2. Designated donations to ISOC (both monetary and in-kind);
3. Other ISOC support.
Note that the goal is to achieve and maintain a viable IETF support
function based on available funding sources. The IETF community
expects the IAOC and ISOC to work together to attain that goal.
5.1. Cost Center Accounting
Funds managed by the IASA shall be accounted for in a separate set of
general ledger accounts within the IASA Cost Center. In the
remainder of this document, these general ledger accounts are termed
"IASA accounts". A periodic summary of the IASA accounts shall be
reported in the form of standard financial statements that reflect
the income, expenses, assets, and liabilities of the IASA.
The IAOC and ISOC shall agree upon and publish procedures for
reporting and auditing of these accounts.
Note that ISOC in consultation with the IAOC can decide to structure
the IASA accounting differently in the future within the constraints
outlined in Section 7.
5.2. IETF Meeting Revenues
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 shall be credited to
the appropriate IASA accounts.
5.3. Designated Donations, Monetary and In-Kind
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 it helps ensure that no undue influence may
be ascribed to those from whom funds are raised.
ISOC shall create and maintain appropriate structures and programs to
coordinate donations intended to support the work of the IETF, and
these shall 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 shall ensure that those programs are not unduly
restrictive. ISOC shall maintain programs that allow for designated
donations to the IETF.
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 shall be credited to the
appropriate IASA accounts.
5.4. Other ISOC Support
Other ISOC support shall be based on the budget process as specified
in Section 6, which includes deciding when ISOC monetary support is
to be credited to the IASA accounts.
All ISOC support, no matter how it is delivered, shall be reported in
the IASA financial reports.
5.5. IASA Expenses
The IASA exists to support the IETF. Funds designated for the IASA
shall be used solely to support IETF activities and for no other
purposes.
5.6. Operating Reserve
As an initial guideline and 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. The IASA, in
cooperation with ISOC, shall establish detailed targets for a reserve
fund to cover normal operating expenses and meeting expenses, in
accordance with prudent planning and as part of the budget process.
The IASA expects ISOC to use reasonable efforts to build and provide
that operational reserve, through whatever mechanisms ISOC deems
appropriate.
If the IASA accounts accumulate a surplus, ISOC may count that as
part of the reserve.
6. IASA Budget Process
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 shall be established each year by IASA and
ISOC. As an example, a general annual timeline for budgeting is:
July 1: The IAD presents a budget proposal (prepared in consultation
with ISOC staff) 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 its 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 examples and are subject to change.
They will most likely be modified each year based on the dates of the
second and third IETF meetings of that year. They also need to be
synchronized with the ISOC budgeting process.
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.
7. ISOC Responsibilities for IASA
Within ISOC, support for the IASA shall meet the following goals:
Transparency: The IETF community shall have complete visibility into
the financial and legal structure of the ISOC activities that are
related to, but not part of, the IASA standards support activity.
In particular, a detailed budget for the entire related ISOC
activity, quarterly financial reports, and audited annual
financial reports shall all be available to the IETF community.
In addition, key contract material and MOUs shall also be publicly
available, subject to any reasonable confidentiality obligations
approved by the IAOC.
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 shall be distinct from other ISOC activities.
ISOC shall support the IASA through the mechanisms specified in
this document and its successors.
Support: ISOC shall work with the IAD and IAOC to ensure appropriate
financial support for the IASA, following the mechanisms described
in this document and its successors.
Removability: While there is no current plan to transfer the legal
and financial home of the IASA to another corporation, the IASA
shall be structured to enable a clean transition in the event that
the IETF community decides that such a transition is required and
documents its consensus in a formal document (currently called a
BCP). In such a case, the IAOC shall give ISOC a minimum of six
months’ notice before the transition formally occurs. During that
period, the IETF and ISOC shall 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 the IASA shall either include a clause allowing termination by
ISOC with six months notice, or be transferable to another
corporation in the event that the IASA transitions away from ISOC.
To the extent allowed by law, any balance in the IASA accounts,
any IETF-specific intellectual property rights, and any IETF-
specific data and tools shall also transition to the new entity.
Other terms shall be negotiated between the IETF and ISOC.
Within the constraints outlined above, all other details of how to
structure this activity within ISOC (for instance, as a cost center,
a division, or an affiliate) shall be determined by ISOC in
consultation with the IAOC.
8. Security Considerations
This document describes the structure of the IETF’s administrative
support activity. It introduces no security considerations for the
Internet.
9. IANA Considerations
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 the IANA, so the IANA may be
interested in the contents.
10. Acknowledgements
The editors would like to thank everyone who provided feedback on
this document or any of its predecessors back to the original
"Scenario O" e-mail message. In particular, the editors would like
to thank: Bernard Aboba, Jari Arkko, Fred Baker, Scott Bradner, Scott
Brim, Brian Carpenter, Jorge Contreras, Dave Crocker, Elwyn Davies,
Spencer Dawkins, Avri Doria, Tony Hain, Joel Halpern, Ted Hardie, Sam
Hartman, Russel Housley, Geoff Huston, Jeff Hutzelman, John Klensin,
Valdis Kletnieks, Eliot Lear, Henrik Levkowetz, Kurt Erik Lindqvist,
John Loughney. Carl Malamud, Allison Mankin, Tom Petch, Eric
Rescorla, Pete Resnick, Glenn Ricart, Jonne Soininen, Lynn St. Amour,
and Michael StJohns.
Special thanks are due to Leslie Daigle and Margaret Wasserman, who
wrote the original "Scenario O" message and edited the earliest
versions of this document.
Special thanks are also due to Henrik Levkowetz for kindly
volunteering to maintain the issue tracking system associated with
this document.
Last, special thanks are due to Harald Alvestrand, for leading the
search for consensus on the IETF mailing list.
No doubt the above list is incomplete. We apologize to anyone whom
we left out.
This document was written using the xml2rfc tool described in RFC
2629 [RFC2629].
11. References
11.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC3716] IAB Advisory Committee, "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.
11.2. Informative References
[ISOC] Internet Society, "Internet Society By-Laws", February
2001,
<http://www.isoc.org/isoc/general/trustees/bylaws.shtml>.
[RFC2031] Huizer, E., "IETF-ISOC relationship", RFC 2031, October
1996.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC2850] Internet Architecture Board and B. Carpenter, "Charter of
the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
May 2000.
[RFC3233] Hoffman, P. and S. Bradner, "Defining the IETF", BCP 58,
RFC 3233, February 2002.
[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.
Authors’ Addresses
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
Phone: +31-348-407-775
EMail: bwijnen@lucent.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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.
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.
Intellectual Property
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.