GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4071

Network Working Group R. Austein, Ed. Request for Comments: 4071 ISC BCP: 101 B. Wijnen, Ed. Category: Best Current Practice Lucent Technologies

                                                            April 2005
    Structure of the IETF Administrative Support Activity (IASA)

Status of This Memo

 This document specifies an Internet Best Current Practices for the
 Internet Community, and requests discussion and suggestions for
 improvements.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2005).

Abstract

 This document describes the structure of the IETF Administrative
 Support Activity (IASA) as an activity housed within the Internet
 Society (ISOC).  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.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
 2.  Definitions and Principles . . . . . . . . . . . . . . . . . .  3
     2.1.  Alphabet Soup  . . . . . . . . . . . . . . . . . . . . .  3
     2.2.  Principles of the IASA, IETF, and ISOC Relationship  . .  4
     2.3.  Community Consensus and Grant of Authority . . . . . . .  5
     2.4.  Termination and Change . . . . . . . . . . . . . . . . .  5
     2.5.  Effective Date for Commencement of IASA  . . . . . . . .  5
 3.  Structure of the IASA  . . . . . . . . . . . . . . . . . . . .  5
     3.1.  IAD Responsibilities . . . . . . . . . . . . . . . . . .  7
     3.2.  IAOC Responsibilities  . . . . . . . . . . . . . . . . .  9
     3.3.  Relationship of the IAOC to Existing IETF Leadership . . 10
     3.4.  IAOC Decision Making . . . . . . . . . . . . . . . . . . 10
     3.5.  Review and Appeal of IAD and IAOC Decision . . . . . . . 10
 4.  IAOC Membership, Selection and Accountability  . . . . . . . . 11
     4.1.  Initial IAOC Selection . . . . . . . . . . . . . . . . . 13

Austein & Wijnen Best Current Practice [Page 1] RFC 4071 Structure of IASA April 2005

 5.  IASA Funding . . . . . . . . . . . . . . . . . . . . . . . . . 14
     5.1.  Cost Center Accounting . . . . . . . . . . . . . . . . . 14
     5.2.  IETF Meeting Revenues  . . . . . . . . . . . . . . . . . 14
     5.3.  Designated Donations, Monetary and In-Kind . . . . . . . 14
     5.4.  Other ISOC Support . . . . . . . . . . . . . . . . . . . 15
     5.5.  IASA Expenses  . . . . . . . . . . . . . . . . . . . . . 15
     5.6.  Operating Reserve  . . . . . . . . . . . . . . . . . . . 15
 6.  IASA Budget Process  . . . . . . . . . . . . . . . . . . . . . 16
 7.  ISOC Responsibilities for IASA . . . . . . . . . . . . . . . . 16
 8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
 9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     11.1. Normative References . . . . . . . . . . . . . . . . . . 18
     11.2. Informative References . . . . . . . . . . . . . . . . . 19

1. Introduction

 This document describes the structure of the IETF Administrative
 Support Activity (IASA) as an activity housed within the Internet
 Society (ISOC).  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 it 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 IAOC is responsible for developing plans to
 provide administrative support for them.  Such support includes, as
 appropriate, undertaking or contracting for the work described in
 [RFC3716], including IETF document and data management, IETF
 meetings, and any operational agreements or contracts with the RFC
 Editor and the Internet Assigned Numbers Authority (IANA).  The IASA
 is also ultimately responsible for the financial activities

Austein & Wijnen Best Current Practice [Page 2] RFC 4071 Structure of IASA April 2005

 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 to 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 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.

2. Definitions and Principles

 This section describes terminology and underlying principles used in
 the rest of this document.

2.1. Alphabet Soup

 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], [RFC2850]).
 IAD: IETF Administrative Director, defined by this document.
 IAOC: IETF Administrative Oversight Committee, defined by this
       document.
 IASA: IETF Administrative Support Activity, defined by this document.
 IESG: Internet Engineering Steering Group (see [RFC2026], [RFC3710]).
 IETF: Internet Engineering Task Force (see [RFC3233]).
 ISOC: Internet Society (see [RFC2031] and [ISOC]).

Austein & Wijnen Best Current Practice [Page 3] RFC 4071 Structure of IASA April 2005

2.2. Principles of the IASA, IETF, and ISOC Relationship

 This section attempts to describe principles underlying the
 mechanisms described in this document.
 1.  The IETF intends to establish a structure (the IASA) in order to
     have IETF administrative functions managed appropriately,
     according to good administrative, fiscal, and management
     principles.  The IASA includes the IAD and the IAOC and shall be
     housed within ISOC.
 2.  The IAD and IAOC shall not have any authority over the IETF
     standards development activities.  This document does not modify
     ISOC's other roles related to the IETF standards process.
 3.  The IAD and IAOC, in cooperation with the ISOC President/CEO and
     staff, shall develop an annual budget for the IASA.  The budget
     must clearly identify all expected direct and indirect
     expenditures related to the IASA.  ISOC, through its normal
     procedures, shall evaluate and approve the IASA budget as part of
     ISOC's own budget process and commit to ensuring funds to support
     the approved budget.
 4.  Responsibility for the evaluation, review, and negotiation of
     contracts and other IETF administrative and support agreements
     and other expenditures of funds under the IASA shall rest with
     the IAD, operating in accordance with policies and procedures set
     by the IAOC and consistent with ISOC operating policies.
 5.  Once funds or in-kind donations have been credited to the IASA
     accounts, they shall be irrevocably allocated to the support of
     the IETF.
 6.  There shall be a detailed public accounting to separately
     identify all funds available to and all expenditures relating to
     the IETF and to the IASA, including any donations, of funds or in
     kind, received by ISOC for IETF-related activities.  In-kind
     donations shall only be accepted at the direction of the IAD and
     IAOC.
 7.  Amongst the IETF, IASA and ISOC, the IETF, through the IASA,
     shall have a perpetual right to use, display, distribute,
     reproduce, modify, and create derivatives of all software and
     data created in support of IETF activities.

Austein & Wijnen Best Current Practice [Page 4] RFC 4071 Structure of IASA April 2005

 8.  The IASA, in cooperation with ISOC, shall use reasonable efforts
     to ensure that sufficient reserves exist to keep the IETF
     operational in the case of unexpected events such as income
     shortfalls.
 The remainder of this document contains details based on the above
 principles.

2.3. Community Consensus and Grant of Authority

 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.

2.4. 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.

2.5. Effective Date for Commencement of IASA

 The procedures in this document shall become operational after this
 document has been approved by the process defined in BCP 9 [RFC2026],
 including its acceptance as an IETF process BCP by the ISOC Board of
 Trustees, and after the ISOC Board of Trustees has confirmed its
 acceptance of ISOC's responsibilities under the terms herein
 described.

3. Structure of the IASA

 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 members 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), who is 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

Austein & Wijnen Best Current Practice [Page 5] RFC 4071 Structure of IASA April 2005

 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.  A committee of the IAOC is responsible for
 hiring and firing the IAD, for reviewing the IAD's performance, and
 for setting the compensation of the IAD.  The members of this
 committee are appointed by the IAOC and consist at minimum of the
 ISOC President, the IETF Chair, and one of the Nomcom-appointed IAOC
 members.
 The IAOC determines what IETF administrative functions are to be
 performed, and how or where they should be performed (whether
 internally within the IASA or by outside organizations), so as to
 maintain an optimal balance of functional performance and cost of
 each such function.  The IAOC should document all such decisions, and
 the justification for them, for review by the community.  Each
 function should be reviewed on a regular basis using the assumption
 that, absent such justification, the function is either unnecessary
 or, if necessary, it is overstaffed, rather than using an assumption
 that anything that has been done in the past is still necessary; each
 function should be adjusted as needed given the result of this
 review.
 The IAD is responsible for negotiating and maintaining contracts or
 equivalent instruments with outside organizations, and for providing
 any coordination necessary to make sure that the IETF administrative
 support functions are covered properly.  All functions, whether
 contracted to outside organizations or performed internally within
 the IASA, must be clearly specified and documented with well-defined
 deliverables, service level agreements, and transparent accounting
 for the cost of such functions.
 The IASA is responsible for managing all intellectual property rights
 (IPR), including but not limited to trademarks, and copyrights that
 belong to the IETF.  The IASA is also responsible for managing the
 ownership, registration, and administration of relevant domain names.
 The IASA is responsible for undertaking any and all required actions
 on behalf of the IETF to obtain, protect, and manage the rights that
 the IETF needs to carry out its work.
 If the IASA cannot comply with the procedures described in this
 document for legal, accounting, or practical reasons, the IAOC shall
 report that fact to the community, along with the variant procedure
 that the IAOC intends to follow.  If the problem is a long-term one,
 the IAOC shall ask the IETF to update this document to reflect the
 changed procedure.

Austein & Wijnen Best Current Practice [Page 6] RFC 4071 Structure of IASA April 2005

3.1. IAD Responsibilities

 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 the 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, for
 managing separate financial accounts for the IASA, and for
 establishing and administering the IASA budget.  The IAD (with IAOC
 approval, as appropriate) should have signing authority consistent
 with carrying out IASA work effectively, efficiently and
 independently, taking into account ISOC's financial and approval
 controls.  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 they shall do so within a
 reasonable time frame.
 The IAD negotiates service contracts, with input, as appropriate,
 from other bodies, including legal advice, 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.  ISOC executes contracts on behalf of the IASA, after
 whatever review ISOC requires to ensure that the contracts meet
 ISOC's legal and financial guidelines.
 The IAD shall ensure that contracts entered into by ISOC on behalf of
 the IASA and/or the IETF (an "IASA Contract") that provide for the
 creation, development, modification, or storage of any data
 (including, without limitation, any data relating to IETF membership,
 documents, archives, mailing lists, correspondence, financial
 records, personnel records and the like) ("Data"), grant to ISOC the
 perpetual, irrevocable right, on behalf of IASA and IETF, to use,
 display, distribute, reproduce, modify and create derivatives of such
 Data.  ISOC will permit IASA and its designee(s) to have sole control
 and custodianship of such Data, and ISOC will not utilize or access
 such Data in connection with any ISOC function other than IETF
 without the written consent of the IAD.

Austein & Wijnen Best Current Practice [Page 7] RFC 4071 Structure of IASA April 2005

 The IAD shall ensure that personal data collected for legitimate
 purposes of the IASA are protected appropriately; at minimum, such
 data must be protected to a degree consistent with relevant
 legislation and applicable privacy policies.
 If an IASA Contract provides for the creation, development, or
 modification of any software (including, without limitation, any
 search tools, indexing tools, and the like) ("Developed Software"),
 then the IAD shall, whenever reasonable and practical, ensure that
 such contract either (a) grants ownership of such Developed Software
 to ISOC, or (b) grants ISOC a perpetual, irrevocable right, on behalf
 of IASA and IETF, to use, display, distribute, reproduce, modify, and
 create derivatives of such Software (including, without limitation,
 pursuant to an open source style license).  It is preferred that
 Developed Software be provided and licensed for IASA and IETF use in
 source code form, with no ongoing payments.  ISOC will permit the
 IASA and its designee(s) to have sole control and custodianship of
 such Developed Software.  The foregoing rights are not required in
 the case of off-the-shelf or other commercially-available software
 that is not developed at the expense of ISOC.
 If an IASA Contract relates to the licensing of third-party software,
 the IAD shall ensure that such license expressly permits use of such
 software for and on behalf of the IASA and/or the IETF, as
 applicable, and that such license is transferable in accordance with
 the provisions of Section 7 (Removability).
 Notwithstanding the foregoing, the IAD can enter into different terms
 if doing so is in the best interest of the IETF and upon approval of
 the IAOC.
 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.  As described elsewhere in this document,
 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 of
 Trustees therefore needs to review and understand the budget and
 planned activity in enough detail to carry out its fiduciary
 responsibility properly.  The IAD is responsible for managing this

Austein & Wijnen Best Current Practice [Page 8] RFC 4071 Structure of IASA April 2005

 process of review and approval.  The IAD sees to it that the IASA
 publishes its complete approved budget to the IETF community each
 year.

3.2. IAOC Responsibilities

 The IAOC's role is to provide appropriate direction to the IAD, to
 review the IAD's regular reports, and to oversee IASA functions to
 ensure that the administrative needs of the IETF community are being
 properly met.  The IAOC's mission is not to be engaged in the day-
 to-day administrative work of the IASA, but rather to provide
 appropriate direction, oversight, and approval.
 Therefore, the IAOC's responsibilities are as follows:
 o  To select the IAD and to provide high-level review and direction
    for his or her work.  This task should be handled by a sub-
    committee, as described above.
 o  To review the IAD's plans and contracts to ensure that they will
    meet the administrative needs of the IETF.
 o  To track whether the IASA functions are meeting the IETF
    community's administrative needs, and to work with the IAD to
    determine a plan for corrective action if they are not.
 o  To review the IAD's budget proposals to ensure that they will meet
    the IETF's needs, and to review the IAD's regular financial
    reports.
 o  To ensure that the IASA is run in a transparent and accountable
    manner.  Although the day-to-day work should be delegated to the
    IAD and others, the IAOC is responsible for ensuring that IASA
    finances and operational status are tracked appropriately, and
    that monthly, quarterly, and annual financial and operational
    reports are published to the IETF community.
 o  To designate, in consultation with the IAB and the IESG, the
    person or people who carry out the tasks that other IETF process
    documents say are carried out by the IETF Executive Director.
 The IAOC's role is to direct and review, not to 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.

Austein & Wijnen Best Current Practice [Page 9] RFC 4071 Structure of IASA April 2005

 If there is no IAD or if the IAD is unavailable, the IAOC may
 temporarily assign the IAD's duties to individual members of the
 IAOC.

3.3. Relationship of the IAOC to Existing IETF Leadership

 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 major internal customers of the
 administrative support services.  The IAOC and the IAD should not
 consider their work successful unless the IESG and IAB are also
 satisfied with the administrative support that the IETF is receiving.

3.4. IAOC Decision Making

 The IAOC attempts to reach consensus on all decisions.  If the IAOC
 cannot achieve a consensus decision, then the IAOC may decide by
 voting.
 The IAOC decides the details about its decision-making rules,
 including its rules for quorum, conflict of interest, and breaking of
 ties.  These rules shall be made public.
 All IAOC decisions shall be recorded in IAOC minutes, and IAOC
 minutes shall be published in a timely fashion.

3.5. Review and Appeal of IAD and IAOC Decision

 The IAOC is directly accountable to the IETF community for the
 performance of the IASA.  In order to achieve this, the IAOC and IAD
 will ensure that guidelines are developed for regular operational
 decision making.  Where appropriate, these guidelines should be
 developed with public input.  In all cases, they must be made public.
 If a member of the IETF community questions whether a decision or
 action of the IAD or the IAOC has been undertaken in accordance with
 IETF BCPs or IASA operational guidelines, or questions whether the
 IASA has created and maintained appropriate guidelines, he or she may
 ask the IAOC for a formal review of the decision or action.
 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

Austein & Wijnen Best Current Practice [Page 10] RFC 4071 Structure of IASA April 2005

 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);

Austein & Wijnen Best Current Practice [Page 11] RFC 4071 Structure of IASA April 2005

 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

Austein & Wijnen Best Current Practice [Page 12] RFC 4071 Structure of IASA April 2005

 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.

Austein & Wijnen Best Current Practice [Page 13] RFC 4071 Structure of IASA April 2005

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

Austein & Wijnen Best Current Practice [Page 14] RFC 4071 Structure of IASA April 2005

 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.

Austein & Wijnen Best Current Practice [Page 15] RFC 4071 Structure of IASA April 2005

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.

Austein & Wijnen Best Current Practice [Page 16] RFC 4071 Structure of IASA April 2005

 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.

Austein & Wijnen Best Current Practice [Page 17] RFC 4071 Structure of IASA April 2005

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.

Austein & Wijnen Best Current Practice [Page 18] RFC 4071 Structure of IASA April 2005

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

Austein & Wijnen Best Current Practice [Page 19] RFC 4071 Structure of IASA April 2005

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.

Austein & Wijnen Best Current Practice [Page 20]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4071.txt · Last modified: 2005/04/15 15:54 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki