Subject: Options for IETF administrative restructuring

From: Leslie Daigle <[email-masked]>
Date: Wed, 25 Aug 2004 19:53:49 -0400

Hello, IETF community.

Attached is the document we promised you in San Diego - a report from
our consultant, Carl Malamud, which lays out a series of options and
recommendations for moving forward with the IETF administrative
restructuring process, according to the recommendations laid out
in RFC3716 (the Advisory Committee report).  It has been submitted
to the Internet Drafts repository and should be showing up there
shortly.

Some important things to note:

THIS IS NOT A DOCUMENT TO BE READ IN ISOLATION.
Minimally, reviewing the Advisory Committee report (RFC3716) is
necessary to understand the context of the proposals laid out in
this draft.

THIS IS NOT YET AN IETF DECISION.
That will be taken later, based on your input and IETF rough consensus.

THIS IS NOT THE IESG/IAB's RECOMMENDATION.
Our recommendation will come later, based on your input and the
evolution of our thinking.

THIS IS NOT AN ISOC POSITION.
The document describes potential relationships of the IETF
administrative activity and ISOC.  However, the document is written
as a proposal for IETF discussion -- the ISOC Board has not been asked
to formulate a position on supporting one or any of these proposals; we
need to have that discussion as it becomes clearer what the IETF wants
in its future.

This IS, however, the culmination of many, many hours of information
gathering and a near-infinite number of conversations by Carl Malamud,
attempting to give the best basis on which the IETF could make a
decision that he could within the timeframe given.

We encourage all interested IETF participants to read the report most
carefully, and give feedback on it - on the IETF list for public
discussion, directly to Carl or the IETF and IAB chairs if you want to
make off-list comments.

FURTHER STEPS

The next steps in this process depend on the community feedback and
whether we can gauge a consensus of the IETF on this mailing list. What
we think is reasonable so far is:

- Have a public discussion on the IETF list on the options presented in
the draft

- By early September, the IESG and IAB will attempt to distill a set of
recommendations that we think capture a reasonable consensus of the
community, and publish this as an internet-draft, which will be revised
over the next month, possibly several times, based on further
discussions

- By late September, we emit a Last Call on this set of recommendations,
if we deem that we have a reasonable consensus for the proposals

- By late October, if the IETF community still shows consensus, we will
declare that we have a decision, and will start executing based on that
decision.

In order to be able to move rapidly when we go into the "execution"
phase, we may initiate some activities of a "fact-finding" nature - such
as investigating possible suppliers of services and candidates for the
positions we envisage filling - before that, but irrevocable decisions
will await IETF consensus.

Please read the attachment - please comment - please THINK.

While this in itself should not change the IETF standards process at
all, support functions are important to the IETF.

We need to take the time to get this one right.

                    Leslie and Harald.

-- 

-------------------------------------------------------------------
"Reality:
        Yours to discover."
                                   -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------

Network Working Group                                    C. Malamud, Ed.
Internet-Draft                                       Memory Palace Press
Expires: February 23, 2005                               August 25, 2004

                 IETF Administrative Support Functions
                   draft-malamud-consultant-report-00

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February 23, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This Internet-Draft discusses the restructuring of administrative
   support functions for the IETF.  The draft begins with a discussion
   of prior steps in the process that led up to this report and
   discusses the process going forward.  The draft then examines the
   current functioning of administrative support functions, analyzes
   options for restructuring operational functions, and analyzes options
   available to provide an institutional framework for such support.

Malamud                Expires February 23, 2005                [Page 1]

Internet-Draft      Administrative Support Analysis          August 2004

   The provision of such administrative support functions is limited in
   scope with responsibility only for the administrative, fiscal, and
   legal infrastructure needed to support the IETF community.  In
   particular, issues such as defining and managing the standards-making
   process and the governance of that process are explicitly out of
   scope for this restructuring.

   This Internet-Draft is an independent consultant's report and should
   not be regarded as a consensus view or a policy statement.  The
   report contains only the author's views.

Current Status--YOU MUST READ THIS SECTION

   This is a FIRST DRAFT and DOES NOT represent a position or a
   consensus.  It should be regarded as a starting point for community
   discussion, followed by eventual decision making by the leadership
   based on a community consensus.

   In particular, the key word "we" in this document is to be
   interpreted as meaning "I, the author".  This document does not
   represent a consensus, policies, or opinions that are to be
   attributed to anything but the personal views of the author.

Intended Status and Mailing List

   This document is intended for publication as an Internet-Draft and is
   expected to undergo numerous revisions.  It is intended that this
   document be submitted for publication as an Informational RFC.

   The forum for discussion of this draft is the IETF Discussion list
   ([email-masked]).  The IETF Discussion List is defined in [RFC3005]
   and further defined in [RFC3184] and [RFC3683].

Malamud                Expires February 23, 2005                [Page 2]

Internet-Draft      Administrative Support Analysis          August 2004

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1   Goals and Non-Goals  . . . . . . . . . . . . . . . . . . .  5
       1.1.1   Goals  . . . . . . . . . . . . . . . . . . . . . . . .  5
       1.1.2   IETF Standards Process Out of Scope  . . . . . . . . .  5
       1.1.3   ISOC Role in Standards Process Out of Scope  . . . . .  6
     1.2   Previous Steps in This Process . . . . . . . . . . . . . .  7
     1.3   Decision Process . . . . . . . . . . . . . . . . . . . . .  7

     1.4   Criteria for Judging an Administrative Restructuring . . .  8
     1.5   Methodology  . . . . . . . . . . . . . . . . . . . . . . .  8
   2.  Analysis of Current Administrative Framework . . . . . . . . . 10
     2.1   Providers and Functions  . . . . . . . . . . . . . . . . . 10
     2.2   Function 1: Administration . . . . . . . . . . . . . . . . 11
     2.3   Function 2: Meetings . . . . . . . . . . . . . . . . . . . 13
     2.4   Function 3: Core Information Technology  . . . . . . . . . 16
     2.5   Function 4: Document and Information Flow  . . . . . . . . 17
   3.  Recommendations for Restructuring the Administrative
       Framework  . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     3.1   Recommendation 1: Hire An Administrative Director  . . . . 20
     3.2   Recommendation 2: Establish Contracts for Core Services  . 21
       3.2.1   Details of Potential RFP Components  . . . . . . . . . 24
     3.3   Recommendation 3: Provide Timely and Uniform Financial
           Reporting  . . . . . . . . . . . . . . . . . . . . . . . . 27
     3.4   Recommendation 4: More Focus on Archives . . . . . . . . . 28
   4.  Options for an Institutional Basis for Administrative
       Activities . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     4.1   Discussion of Organizational Form and Legal Domicile . . . 29
     4.2   Scenario A: ISOC Operating Unit  . . . . . . . . . . . . . 30
       4.2.1   Division of the Internet Society . . . . . . . . . . . 30
       4.2.2   Intended benefits  . . . . . . . . . . . . . . . . . . 31
       4.2.3   Additional Considerations  . . . . . . . . . . . . . . 31
     4.3   Scenario B: More Formalized ISOC Operating Unit  . . . . . 32
     4.4   Scenario C: Well-Defined Entity With Close Ties to ISOC  . 34
       4.4.1   How Scenario C Might Work In Practice  . . . . . . . . 34
     4.5   Scenario D: Autonomous Entity  . . . . . . . . . . . . . . 40
   5.  Future Work  . . . . . . . . . . . . . . . . . . . . . . . . . 41
     5.1   Short-Term . . . . . . . . . . . . . . . . . . . . . . . . 41
     5.2   Long-Term  . . . . . . . . . . . . . . . . . . . . . . . . 41
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 43
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 44
   8.  Acknowledgment of CNRI Contribution to the IETF Community  . . 45
   9.  Acknowledgment of Contributions and Reviews  . . . . . . . . . 46
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 47
   10.1  Normative References . . . . . . . . . . . . . . . . . . . . 47
   10.2  Informative References . . . . . . . . . . . . . . . . . . . 48
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 52
   A.  Consulting Contract  . . . . . . . . . . . . . . . . . . . . . 53

Malamud                Expires February 23, 2005                [Page 3]

Internet-Draft      Administrative Support Analysis          August 2004

   B.  IETF Financial Information . . . . . . . . . . . . . . . . . . 57
     B.1   Consolidated 3-Year Historical Income Statement  . . . . . 57
     B.2   Internet Society 2004 Budget Summary . . . . . . . . . . . 59
   C.  10-Year Meeting Attendance Summary . . . . . . . . . . . . . . 62
     C.1   Analysis of Meeting-Based Expense and Revenue Drivers  . . 64
   D.  Sample Draft Incorporating Documents for a Hypothetical
       IETF Foundation  . . . . . . . . . . . . . . . . . . . . . . . 66
     D.1   Sample Draft Articles of Incorporation . . . . . . . . . . 66
     D.2   Sample Draft Bylaws of the IETF Foundation . . . . . . . . 66
       D.2.1   Article I: Organization  . . . . . . . . . . . . . . . 66
       D.2.2   Article II: Purpose  . . . . . . . . . . . . . . . . . 66
       D.2.3   Article III: Members . . . . . . . . . . . . . . . . . 67
       D.2.4   Article IV: Offices  . . . . . . . . . . . . . . . . . 67
       D.2.5   Article V: Board of Trustees . . . . . . . . . . . . . 67
       D.2.6   Article VI: Officers . . . . . . . . . . . . . . . . . 71
       D.2.7   Article VII: Amendments  . . . . . . . . . . . . . . . 72
       D.2.8   Article VIII: Dissolution  . . . . . . . . . . . . . . 73
       D.2.9   Article IX: Miscellaneous Provisions . . . . . . . . . 73
   E.  Sample Draft Call for Applications -- IETF Administrative
       Director . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
   F.  Sample Draft Request for Proposals . . . . . . . . . . . . . . 77
     F.1   Introduction . . . . . . . . . . . . . . . . . . . . . . . 77
     F.2   General Provisions . . . . . . . . . . . . . . . . . . . . 78
     F.3   Requirement 1: Meetings  . . . . . . . . . . . . . . . . . 79
     F.4   Requirement 2: Systems and Systems Administration  . . . . 79
       F.4.1   Core Network Infrastructure  . . . . . . . . . . . . . 79
       F.4.2   Systems Administration Services  . . . . . . . . . . . 80
     F.5   Requirement 3: Postmaster of the IETF Administrative
           Entity . . . . . . . . . . . . . . . . . . . . . . . . . . 80
     F.6   Requirement 4: Clerk of the IETF Administrative Entity . . 81
     F.7   Requirement 5: Webmaster of the IETF Administrative
           Entity . . . . . . . . . . . . . . . . . . . . . . . . . . 81
     F.8   Selection Criteria and Evaluation Process  . . . . . . . . 81
       Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
       Intellectual Property and Copyright Statements . . . . . . . . 84

Malamud                Expires February 23, 2005                [Page 4]

Internet-Draft      Administrative Support Analysis          August 2004

1.  Introduction

1.1  Goals and Non-Goals

1.1.1  Goals

   Any plan for restructuring the administrative support functions of
   the IETF and for establishing an institutional foundation for those
   administrative functions must meet three goals:
   1.  The IETF process must continue to work.  The smooth and stable
       operation of the IETF is paramount.  Any changes that are made
       should be made with the goal of making that process work better.
       This means that the continuation of the current operation, the
       transition, and the future steady-state must all be carefully
       thought out and executed.
   2.  The administrative, fiscal, and legal processes--including those
       that effect this restructuring--must be transparent to the IETF
       community.  Any potential IETF administrative support
       organization must be accountable to the community.  Both the
       transition and the future steady state will require the support
       of the community, which requires that we observe the IETF
       processes for decision making and that all necessary information
       for making those decisions be made publicly available.
       Transparency of financial transactions and in the decision making
       process are of particular importance.
   3.  Any organization that provides administrative support functions
       for the IETF must be subservient to and support the existing IETF
       structures and decision-making processes.

1.1.2  IETF Standards Process Out of Scope

   This restructuring exercise is limited in scope to IETF
   administrative functions.  In particular, it does not cover areas
   including (but not limited to) the following:
   1.  The IETF technical standards-making process.
   2.  Selection of the IETF leadership and operation of the nominating
       committee.
   3.  Any other topics already covered in our existing procedure Best
       Current Practices documents unless called out specifically here.

   As will be seen in subsequent sections, we explicitly reference our
   existing purpose, governance, process, and core values as they now
   exist and as they may be changed in the future.  A new institutional
   home for the IETF administrative functions will not supplant the IETF
   technical processes, it will support them.

Malamud                Expires February 23, 2005                [Page 5]

Internet-Draft      Administrative Support Analysis          August 2004

1.1.3  ISOC Role in Standards Process Out of Scope

   The Internet Society and the IETF both have the good of the Internet
   as a primary mission goal.  The Internet Society has a broader
   mandate than the IETF.  Those mandates are organized as the "Pillars"
   of the Internet Society, and include the following activities:
   o  Pillar 1: Education & Training
   o  Pillar 2: Public Policy
   o  Pillar 3: Standards & Protocols

   In support of these pillars, the Internet Society conducts global
   conferences including INET and NDSS, and conducts or participates in
   regional meetings either directly or through its chapters.

   The IETF is focused exclusively on the standards and protocol
   activity.  The Internet Society plays a complementary and vital role
   with an active education and policy effort that allows the IETF to
   maintain a focus on protocols and standards.

   The Internet Society is an international membership organization,
   open to all organizations and individuals.  ISOC supports the IETF
   and IAB in a number of ways (as detailed below), historically raising
   funds through Organization and Individual member dues.  ISOC conducts
   and/or participates in global conferences including INET and NDSS,
   network training workshops for developing countries, topical
   tutorials, and various policy forums.  ISOC participates in many
   regional meetings either directly or through its chapters.

   While a variety of administrative functions provided by the Internet
   Society will be considered in this document, it is important to state
   at the outset that the Internet Society currently provides two
   important functions to the IETF:
   1.  *Administration Functions.* As discussed in subsequent sections,
       the Internet Society provides administrative and financial
       functions, managing the contract with the RFC Editor, providing
       insurance for selected IETF participants, and administering a
       discretionary fund for use by the IAB and the IETF Chairs.
   2.  *Standards Process Functions* The Internet Society plays a
       fundamental role in the IETF Standards Process, including
       appointment of the Nominating Committee chair, confirmation of
       IAB members, confirmation of documents that describe the
       standards processes, and acting as the last resort in the appeals
       process.  These Standards Process Functions are defined in
       [RFC2026], [RFC2028], [RFC2031], and [RFC3677] and are out of
       scope for this analysis.  No changes are proposed to these
       Standards Process Functions.

   Any changes to the *Standards Process Functions* would use the

Malamud                Expires February 23, 2005                [Page 6]

Internet-Draft      Administrative Support Analysis          August 2004

   existing procedures, which require a draft to progress through the
   process, ultimately being subject to a Last Call and a declaration of
   consensus.  In the case of modifications to existing process BCP
   RFCs, this is a high bar to cross.

1.2  Previous Steps in This Process

   A process for restructuring IETF administrative support functions as
   well as other more general IETF issues was started in 2002.  This
   process has resulted in a number of documents that have defined the
   goals of the IETF and basic principles for restructuring (see, e.g.,
   [I-D.alvestrand-ietf-mission]).  The basic outline of the
   administrative restructuring process was defined by an Advisory
   Committee to the IAB, the results of which are published in
   [RFC3716].

   This document carries out the requirements of [RFC3716] in discussing
   various options for administrative restructuring and the definition
   of relationships with institutions which support the activities of
   the IETF community.

   The specific goals of the administrative restructuring effort, as
   outlined in [I-D.daigle-adminrest], are to recognize and preserve the
   community-driven nature of the IETF technical work, and to continue
   to support that work through the formalization of a single
   administrative umbrella organization that will be openly accountable
   to that same community.

1.3  Decision Process

   Restructuring of IETF administrative support functions is a
   fundamental activity that must have the support of the IETF
   community.  This document attempts to present an "omnibus" plan,
   addressing the full scope of the requirements stated in [RFC3716].
   This document has already undergone numerous revisions, and will
   undergo subsequent revisions based on input from the IETF community.
   The first stage in reaching consensus around proposed changes include
   the following steps:
   1.  Publication of [RFC3716].
   2.  Continued deliberation and issuance of Internet-Drafts on the
        Administrative Restructuring.
   3.  A decision to "move forward" including a request for funding by
        the IETF and IAB Chairs to the Internet Society Board of
        Trustees, allocation of those funds, and the engagement of a
        consultant.
   4.  Drafting of this draft.
   5.  Initial reviews of this draft, including reviews by the IAB,
        IESG, ISOC Board, and legal counsel, and others.

Malamud                Expires February 23, 2005                [Page 7]

Internet-Draft      Administrative Support Analysis          August 2004

   6.  Briefings to the community via the IETF discussion list and at
        IETF60 about what to expect.
   7.  Publication as an Internet-Draft.
   8.  Discussion of the Internet-Draft in the IETF community.  *<----
        You Are Here.*
   9.  Reconsideration of the draft by the IAB, IESG, ISOC board, and
        IETF legal counsel and issuance of a set of specific
        recommendations by the IAB and/or IESG.
   10.  Issuance of a Last Call on this document and on the subsequent
        memorandum published by the IESG and IAB.
   11.  Determination of community consensus on the updated plan.
   12.  Publication of this draft, as revised, as an Informational RFC.
   13.  Implementation, with periodic reporting back to the community.
   At each stage, the draft will be revised as appropriate.

   In addition, portions of this document are intended to form the basis
   for one or more drafts containing new procedures or Memoranda of
   Understanding related to the IETF administrative practices; these
   would eventually be published as Best Current Practices (BCP) RFCs.
   That process would begin after the initial community consensus.

1.4  Criteria for Judging an Administrative Restructuring

   The guiding principles in the analysis of the administrative
   restructuring are the criteria specified in [RFC3716], Section 3.
   These criteria are worth restating:
   1.  Better resource management:
          1.1 Uniform budgetary responsibility.
          1.2 A uniform view of revenue sources
          1.3 Clarity in the relationship with supporting organizations.
          1.4 Flexibility to provision and reprovision services.
          1.5 Administrative efficiency.
   2.  Stewardship:
          2.1 Accountability for change.
          2.2 Persistence and accessibility of records.
   3.  A better working environment:
          3.1 More service automation where appropriate.
          3.2 Better tools.

1.5  Methodology

   Preparation of this report began on June 18, 2004 as part of a
   consulting engagement to support the IETF and IAB chairs in the
   restructuring effort, based on their request for funding
   restructuring activities which was approved by the Internet Society
   Board of Trustees.  The contract is attached as Appendix A.

   The following steps were used to gather input to this report:

Malamud                Expires February 23, 2005                [Page 8]

Internet-Draft      Administrative Support Analysis          August 2004

   o  Initial briefings and continued close coordination with the Chairs
      of the IAB and the IETF.
   o  A series of consultations with members of the IAB and IESG through
      teleconferences, one-on-one email and phone conversations, and
      face-to-face discussions at IETF60.
   o  A series of consultations with staff, officers, and board members
      of the Internet Society.
   o  Discussions, by phone, email, and in person, with the staff of
      Foretec Seminars, the Internet Society, the RFC Editor, and the
      IANA, as well as a series of discussions with management at host
      institutions including CNRI, ISI, and ICANN.
   o  A large number (over 100) of discussions by phone, email, and in
      person with members of the community, including former members of
      the leadership, and individuals known to represent a wide variety
      of views.
   o  A detailed examination of relevant finances, including the
      financial reports and tax returns of organizations providing
      various support functions to the IETF.
   o  A detailed examination of operational issues, including the
      functioning of key applications such as the Internet-Draft
      Tracker, the operational and planning aspects of meetings, and the
      functioning of the core IETF network presence.
   o  A detailed review of relevant documents, including electronic mail
      archives, plenary transcripts, and RFCs, particularly the process
      BCP RFCs.
   o  In cooperation with legal counsel, a detailed examination of the
      current contractual framework and options available for
      incorporation or otherwise providing more formalization of the
      existing administrative structures, as well as a detailed
      assessment of potential risks and liabilities of such a
      transition.

Malamud                Expires February 23, 2005                [Page 9]

Internet-Draft      Administrative Support Analysis          August 2004

2.  Analysis of Current Administrative Framework

2.1  Providers and Functions

   The IETF is an "open global community of network designers,
   operators, vendors, and researchers producing technical
   specifications for the evolution of the Internet architecture and the
   smooth operation of the Internet."[RFC3233] A variety of institutions
   provide administrative support to the IETF community:
   o  The Internet Society is "the organizational home of the Internet
      Engineering Task Force (IETF), the Internet Architecture Board
      (IAB), the Internet Engineering Steering Group (IESG), and the
      Internet Research Task Force." [www.isoc.org] [1] The Internet
      Society is a 501(c)(3) corporation with total 2002 revenues of
      $1,695,833 and expenses of $1,681,064, of which $763,423 was
      allocated as program expense to support the Standards Pillar of
      the Internet Society.[ISOC-2002] The 2004 budget for the Internet
      Society is attached in Appendix B.2.  The Internet Society and the
      IETF cooperate closely in a number of areas, as defined in
      [RFC2026], [RFC2028], [RFC2031], and [RFC3677].
   o  Since 1969, the Requests for Comments (RFC) document series and
      the office of the RFC Editor has been hosted at the Information
      Sciences Institute (ISI).  The RFC Editor's office and submission
      process is further defined in [RFC2223],
      [I-D.rfc-editor-rfc2223bis], and [RFC2555].
   o  The IETF has delegated the parameter registration function to the
      IANA, which is hosted at ICANN.  The relationship is defined in
      [RFC2860].  IANA instructions for RFC authors are defined in
      [RFC2434] and in [I-D.narten-iana-considerations-rfc2434bis].
   o  Foretec Seminars, Inc., a for-profit subsidiary of the non-profit
      Corporation for National Research Initiatives (CNRI), provides a
      variety of support services, including the planning of meetings
      three times per year, a network presence for IETF activities, and
      secretariat services such as coordination of the flow of documents
      through the IESG.  CNRI is a non-profit corporation registered
      under section 501(c)(3) of the US tax code [IRS] and has been
      providing service to the IETF since 1986 (see Section 8 for more
      details on these long-term contributions to the community).  CNRI
      owns approximately 96% of the shares of the Delaware-chartered
      Foretec Seminars, Inc.[CNRI-2002]

   For purposes of this analysis, we will examine these institutions
   using a 4-part taxonomy of functions:
   o  *Function 1: Administration.* This function includes program
      management tasks such as contract administration.  It also
      includes any legal matters and issues of financial reporting and
      transparency.

Malamud                Expires February 23, 2005               [Page 10]

Internet-Draft      Administrative Support Analysis          August 2004

   o  *Function 2: Meeting Planning.* This function includes the
      planning and management of large events such as the IETF meetings
      held three times per year, as well as more specialized activities
      such as retreats and interim Working Group meetings.
   o  *Function 3: Core Information Technology.* This function includes
      most of the network presence of the IETF, including the basic
      provisioning of computing resources (e.g., colocation, name
      service, routing, transit), and core services such as mail, web
      site, rsync, and ftp.
   o  *Function 4: Document and Information Flow.* This function
      includes the flow of information through the IETF process.  While
      Function 3, Core Information Technology, provides the basic
      platform, Function 4 uses that platform.  For example, basic
      configuration of Apache or a mail server is a core IT function,
      while what goes on the web site and in particular email messages
      is part of the document flow.  Likewise, booking an appropriate
      venue is a meeting planning function, but deciding the specific
      agenda for a meeting is part of Function 4.

2.2  Function 1: Administration

   A prime requirement of [RFC3716] was "clarity in the relationship
   with supporting organizations." The IETF sits on, to paraphrase the
   words of Brian Carpenter, a "four-legged" stool for administrative
   support functions.  Unfortunately, not all of the legs are fully
   defined.

   The most serious undefined area is the on-going relationship with
   CNRI, which in turn subcontracts to Foretec Seminars, Inc., a
   for-profit subsidiary.  CNRI has provided secretariat services for 18
   years, but there is no contract or memorandum of understanding with
   the IETF that defines the relationship.  When the arrangement was
   first started, a few dozen people attended IETF meetings.  Over time,
   that grew to over a hundred attendees, then several hundred, and
   today well over 1,000 people attend each meeting.  The gentleman's
   agreement was perfectly appropriate 18 years ago.  But, [RFC3716] was
   quite clear that today it is not a sufficient basis for managing
   close to US$2 million in annual meeting fees collected on behalf of
   the IETF community.

   The lack of a specific contract with CNRI/Foretec is one of the items
   noted in [RFC3716], however that analysis also pointed to broader
   problems throughout the IETF community.  In general, the
   administrative and support relationships have not been defined or
   kept up to date.  That has led to a variety of issues observed in
   interviews conducted for drafting this report:
   o  A lack of financial information.

Malamud                Expires February 23, 2005               [Page 11]

Internet-Draft      Administrative Support Analysis          August 2004

   o  Confusion over intellectual property.
   o  Vague definition of the lines of authority in the contracting
      relationship.

   *Financial Information.* There is no systematic, comprehensive, or
   timely reporting of financial information to the IETF leadership by
   support organizations, nor from the IETF leadership to the IETF
   community.
   o  Budgets are prepared at a very high level, are not based on
      program goals prepared by the IETF leadership, and are not based
      on historical information, such as actual versus budgeted results
      in previous periods.  This reduces the ability of the leadership
      to participate in a meaningful budget-setting process.
   o  Financial reporting is also minimal: financial results are not
      available during the course of the year, and have been typically
      reported as late as 6 months after the close of the year.  The
      reports furnished to the IETF community are non-standard in
      format, lack sufficient detail for evaluation, and are not
      furnished to the IETF with an auditor's or accountant's statement.

   *Intellectual Property.* In conducting research for this report, the
   author noted a lack of clear definition of community intellectual
   property.  Because relationships with support organizations are
   poorly defined, there is no clear, unambiguous paper trail that shows
   that resources are held in trust for the IETF community and must be
   managed in the public interest and in a manner that is responsive to
   the IETF community.  The IETF is a public standards-making
   organization and a fundamental defining characteristic of the IETF is
   the openness of the process.[RFC3668] All data, including databases,
   correspondence, minutes, and other documentation of the IETF
   operations or deliberations are an integral part of that process.

   *Definition of the Relationship* The third effect of a lack of a
   concrete understanding has been an apparent deterioration in the
   working relationship between the IETF leadership and support
   organizations.  In particular, a review of correspondence shows
   numerous instances where requests for specific functions have led to
   discussions over who has the right to request what.

   While the lack of a formal relationship with CNRI and/or Foretec
   Seminars is the most pressing issue in the Administration Function,
   the [RFC3716] goals of "uniform budget responsibility" and "a uniform
   view of revenue sources" are not being attained.  In particular:
   o  The Internet Society provides a number of administrative functions
      that go beyond the matters specified in [RFC2031].  While that
      memorandum of understanding does cover the provision of insurance,
      in addition to that task the Internet Society also provides
      discretionary funds to the IETF and IAB Chairs, and funds the

Malamud                Expires February 23, 2005               [Page 12]

Internet-Draft      Administrative Support Analysis          August 2004

      operation of the IAB.  These expenditures are reported the IETF
      community based on totals with no detail.  In addition, the RFC
      Editor contract is not published, although the statement of work
      and total expenditures are.[RFC-SOW]
   o  The IANA provides parameter registry services to the IETF.  While
      the substance of that relationship is defined in [RFC2860], the
      host institution (ICANN) does not provide financial reporting at
      sufficient granularity for an analyst to understand how much that
      function costs and thus understand the level of resources being
      used to perform that function.  In addition, no public tracking of
      requests or announcements of new registrations are provided,
      making it difficult to estimate the workload.
   o  The IETF has no uniform reporting of overall financial results.
      While the IETF Chair has posted financial reports as they are made
      available, there is no single location where an interested member
      of the community can get a fiscal picture of the operation of the
      IETF over time, or examine a standards-compliant financial report
      for a particular time period.[FASB-117]

2.3  Function 2: Meetings

   IETF meetings revenues have traditionally funded a wide variety of
   non-meeting support functions, such as the document tracking,
   submission, and distribution systems.  Meeting revenues make up the
   largest single revenue stream for IETF support (see Appendix B.1 for
   a summary of IETF financial information over the last 3 years).

   The cost per attendee per meeting has stayed at roughly $200 and
   average revenue per attendee has been roughly $450 over the last 3
   years, though recent gross fees have been as high as $545 including
   late fees.  Note that the $200/attendee cost is only direct costs
   incurred on-site, and does not include additional personnel, travel,
   and other expenses from support organizations to plan and staff the
   meeting.  Appendix C contains a summary of meeting attendance, as
   well as a summary analysis of revenue and expense figures.

   Although the number of participants in the IETF process as a whole
   appears to have been growing, the number of attendees at IETF
   meetings has been steadily dropping from a previous peak.  From 2000
   to 2003 the drop was fairly dramatic, though the figures appear to
   have stabilized recently.  The drop in attendees from the previous
   peak means a smaller number of attendees have been funding a largely
   fixed cost of non-meeting expenses.

   The meeting business is based on several cost factors.  An
   organization will contract with a primary hotel with a guaranteed
   rental of a certain number of guest rooms.  This is known as a "hard"
   contract and requires an advance deposit of a negotiable amount of

Malamud                Expires February 23, 2005               [Page 13]

Internet-Draft      Administrative Support Analysis          August 2004

   the expected room revenue.

   These amounts can be substantial.  For example, a typical contract
   where an organization is doing a one-time event might require 50% of
   expected revenue deposited as far ahead as 90 days before the event.
   In the case of a typical IETF meeting, this might be 1,000 rooms at
   $150/night for 5 nights, or a 90-day deposit of $375,000.  Proper
   negotiation of long-term relationships can reduce these cash flow
   requirements by an order of magnitude.

   In addition, the IETF requires certain facilities provided by the
   hotel, such as audio visual equipment, electrical services, and food.
   In the U.S., meeting rooms are often provided at no charge, but only
   after matters such as food have been negotiated.  In non-U.S.
   venues, the cost for meeting rooms can be as high as $125,000.

   The planning and execution of an event such as this, particularly
   three times per year, requires experienced professionals.  There are
   a number of companies and free lance professionals that specialize in
   organizing meetings for professional groups.  Many of these companies
   have become quite adept at computer networking, and if properly
   assisted in areas such as routing and the DNS, could do a very
   credible job for the IETF.  It is important to note that IETF
   meetings have been organized quite skillfully over a number of years
   and attendees have become accustomed to this level of
   professionalism.  It is important that the IETF maintain those
   standards.

   Assistance from members of the community is an important part of
   staging an IETF meeting.  In addition to formal secretariat
   activities, at least three teams of volunteers have been active
   recently:
   o  For all unhosted meetings, and for most hosted meetings, a NOC
      team of volunteers has helped establish a wireless infrastructure,
      provisioned external lines and transit, managed DNS, and provided
      a wide variety of other core services.  At IETF60, the lead
      engineer for this activity was Jim Martin.
   o  A team of volunteers organized by the University of Oregon's Video
      Lab produces audio and video streams from IETF meetings (as well
      as NANOG and a variety of other events).
   o  A team of volunteers organized by xmpp.org [2] manages a series of
      XMPP[I-D.ietf-xmpp-core] servers which are used for general
      commentary by participants, creation of informal transcriptions
      which are archived, and for a variety of personal productivity
      enhancements.[Bingo]

   Over the years, a variety of other efforts have sprung up and
   disbanded aimed at deploying leading-edge technologies in the meeting

Malamud                Expires February 23, 2005               [Page 14]

Internet-Draft      Administrative Support Analysis          August 2004

   network for interoperability testing or to familiarize attendees with
   new protocols.  Some of these activities, such as PGP key signing
   parties, are ongoing.  Others have been organized as one-time events.
   These ad hoc activities are an important part of IETF meetings.

   These self-organized, volunteer efforts, benefit from coordination
   with formal meeting planning functions.  For example, the core
   network group requires facilities and coordination with the hotel's
   telecommunications service, while the audio/video effort requires
   coordination with the hotel's audio-visual contractors.  Currently,
   none of these volunteer efforts is linked to from meeting web pages
   which are maintained by CNRI/Foretec, and there is no IETF leadership
   policy on this subject.

   While the day-to-day operational aspects of meetings are extremely
   well coordinated, long-range planning for IETF meetings is almost
   non-existent.  For example, by IETF60 in August, 2004, planning for
   2005 meetings had not reached any apparent degree of closure.  The
   IETF leadership were unaware of any firm plans for Spring or Fall of
   2005, and while some progress had been made in identifying a general
   location for the Summer 2005 meeting, specific venues were still
   being evaluated.

   Long-range planning is absolutely essential in the meeting business.
   Booking well in advance and using techniques such as repeat visits to
   properties that are allied through common ownership or marketing
   arrangements can lead to dramatic reductions in guest room rates,
   deposit requirements, and hotel charges.  Long-range planning also
   helps IETF meeting attendees plan their own schedules.  For many
   people, the commitment to go to an IETF is a major one, requiring the
   use of vacation time, personal funds, and other resources.

   Often in the past, a "host" has volunteered to assist in a meeting, a
   task that traditionally consisted of organizing the terminal room
   effort.  The concept of a single host has, for recent meetings, been
   supplanted by a series of sponsors who furnish specific resources,
   such as bandwidth or equipment.  Terminal room efforts have become
   significantly easier as the IETF has shifted from importing hundreds
   of bulky computers and terminals for attendees (see [RFC0015] for
   more information on the concept of "terminals") to a wireless network
   for laptops.  The concept of "host" (or "primary sponsor") is
   certainly a useful one, however instead of focusing on terminal room,
   the device could be used as a way of defraying meeting room charges,
   food, or other major expenses.

   One final issue should be noted that has become apparent during the
   course of research for this report.  There appears to be no clear
   guidelines on some issues related to the conduct of meetings, which

Malamud                Expires February 23, 2005               [Page 15]

Internet-Draft      Administrative Support Analysis          August 2004

   has led to disagreements between the contractor and the IETF
   leadership.  Two situations in particular are apparent:
   1.  Signage.  All hotel signage for IETF60 was in the form of the
       "Foretec IETF Summer Meeting." While this is perhaps a small
       matter, it was brought up numerous times by meeting attendees.
       In most association meetings, signage is strictly controlled so
       that all sponsors and contractors (and in the case of the IETF,
       volunteers) receive appropriate billing.
   2.  Corollary activities.  There have been several attempts to defray
       meeting costs or increase profits through the use of trade
       exhibitions, user groups, engineering task forces, and various
       other activities affiliated loosely or closely with an IETF
       meeting.  Any policy on colocation of related events at an IETF
       meeting is a policy matter that should be under the direction of
       the IAB and IESG and ultimately the IETF community.  The IETF
       leadership should formulate such a policy.

2.4  Function 3: Core Information Technology

   While meetings provide an important part of the IETF process, it has
   always been a basic policy of the community that participation in
   meetings is not required to participate in the IETF.  Mailing lists,
   document submissions, and other aspects of a continuing network
   presence are a core part of the IETF.

   As noted above, this analysis divides that network presence between a
   core information technology function, which is discussed here, and
   the uses of that network, which is described in the next section.

   Unfortunately, the IETF does not do a very good job of providing a
   network presence for its own activities.

   There are many opinions about how "good" or "standards-compliant" or
   "well-provisioned" a network infrastructure should be for any
   particular activity.  However, by most standards, it is hard to argue
   that the IETF is using the technology effectively.  A comprehensive
   analysis of network performance is impossible simply because
   statistics and logs or any other reporting is not available.
   However, a few anecdotes will serve to illustrate the point.

   There are six Web sites that contain information important for IETF
   participants.  None of these Web sites, as of August 13, 2004, were
   compliant with the W3C Validation Service and with published HTML
   standards:
   o  http://www.iana.org/ [3]
   o  http://www.rfc-editor.org/ [4]
   o  http://www.isoc.org/ [5]

Malamud                Expires February 23, 2005               [Page 16]

Internet-Draft      Administrative Support Analysis          August 2004

   o  http://www.ietf.org/ [6]
   o  http://www.iab.org/ [7]
   o  http://www.irtf.org [8]

   Likewise, none of these sites is reachable using IPv6.  Search
   engines on all four sites are primitive at best, and are not
   operational in the case of www.iana.org and www.isoc.org.  Few
   attempts are made at authentication of information, domain names, or
   applications.  Again, these are all anecdotal examples, but they
   match the findings of [RFC3716] that the IETF does not use technology
   as effectively as it could.

   One function that appears sorely lacking on any of these systems is
   the provisioning of shared environments for use by working groups,
   directorates, the IAB, the IESG, and other groups.  Working groups,
   as part of the management of chartering activity, are able to specify
   a web site and a mailing list, but there appears to be no mechanism
   that allows a portion of the web, FTP, or other core operational
   servers to be delegated for use by a particular group.

   The result has been that working groups, teams and areas create a
   diverse plethora of unconnected sites for handling IETF functions,
   such as rtg.ietf.org, ops.ietf.org, edu.ietf.org, various issue
   trackers, WG web sites and other tools hosted at diverse private web
   sites, the availability of which is critically dependent on
   volunteers - which are usually drawn from the WG.  This is not
   necessarily a bad thing, but as will be seen in Section 3.4, some
   additional support might help meet goals such as the goal stated in
   [RFC3716] of "persistence and accessibility of records." For example,
   a systematic archiving facility can assist decentralized efforts,
   unified search facilities might prove useful to those searching for
   information, and one could certainly find many ways to improve the
   navigation, presentation, and timeliness of the current IETF network
   presence.

2.5  Function 4: Document and Information Flow

   Function 4, Document and Information Flow, is the part that directly
   supports the day-to-day functioning of the IETF.  While core
   information technology provides a web server or a mail server, this
   function populates those servers with information based on the rules
   defined in process BCP RFCs as well as various unwritten procedures
   and customs.

   A demanding part of the current IETF Secretariat is the process of
   supporting the numerous bodies that proliferate through the
   community.  The IESG, of course, requires a great deal of support,
   given their bi-weekly teleconferences, and the tremendous workload of

Malamud                Expires February 23, 2005               [Page 17]

Internet-Draft      Administrative Support Analysis          August 2004

   documents to consider, working groups to charter, and other functions
   the group performs.  The high workload of IESG members has been noted
   repeatedly.

   Many of the functions required to support a deliberative body such as
   the IESG are ideally suited for a capable administrative office, a
   task often labeled as "Clerk." In the U.S., for example, the "Clerk
   of the Court" or "County Clerk" are key tasks in their respective
   organizations.  These officers and offices facilitate the flow and
   archiving of information, providing both a human and a procedural
   interface for disseminating information among participants in a
   process.

   The tasks that are encompassed in this function include:
   o  Supporting the working group charter process, which includes
      processing the initial charter, rechartering, milestone
      management, and closing of the working group.
   o  Publication of Internet-Drafts.  It is assumed that current
      efforts to automate the submission process will be successful,
      alleviating much of the manual effort that this function currently
      has.
   o  Document tracking, including a ticket-system-based response to
      document and working group management problems, announcements of
      last calls, and a variety of other functions.
   o  Managing IESG meetings, including scheduling, creation of the
      agenda, and collecting the minutes, as well as the creation and
      long-term archiving of IETF meeting proceedings.
   o  Handling the Intellectual Property Rights disclosure process (a
      process which is presently undergoing automation).
   o  Publication of official actions, such as document approvals,
      including communication of such status to groups such as the RFC
      Editor.
   o  Registration and publication of liaison statements from other
      standards bodies and publication of liaison statements, responses
      and other communications by the IETF to Standards Development
      Organizations (SDOs).
   o  Support of the Nominating Committee.
   o  Assisting the Meeting Planners in crafting an appropriate agenda
      for the IETF meetings, a complex task that requires a fairly
      detailed knowledge of the IETF operation.

   A great deal of progress has been made in this area over the last
   year, with active participation of a new Tools group and of IESG
   members.  However, there is still substantial work to make the flow
   of information smoother and more predictable.  For example, even
   though the Internet-Draft, RFC, and IANA processes are all closely
   linked in theory, in practice each organization currently maintains
   their own tracking system.  In the case of the IANA, that tracking

Malamud                Expires February 23, 2005               [Page 18]

Internet-Draft      Administrative Support Analysis          August 2004

   system is not visible outside of the organization.  Thus, interaction
   among these three bodies often relies on personal communications, and
   there are fairly frequent issues of tokens being lost, or "customers"
   (e.g., the author of a particular draft) being unclear where in the
   process they are.

Malamud                Expires February 23, 2005               [Page 19]

Internet-Draft      Administrative Support Analysis          August 2004

3.  Recommendations for Restructuring the Administrative Framework

   This section contains recommendations for changing how the day-to-day
   support functions are provided.  Issues such as how to contract for
   services and whether or not a full-time staff member should be hired
   are dealt with in this section.  Section 4 discusses the
   institutional framework in which these activities can be housed,
   including issues such as whether to incorporate the administrative
   entity.

3.1  Recommendation 1: Hire An Administrative Director

   The deliberations of the Problem Statement Working Group made it
   clear that the IESG and IAB are both overworked with an increasingly
   large flow of technical issues.  The group also made it clear that
   the IETF Chair and the IAB Chair should continue to be picked for
   their ability to lead the IETF technical activities, not solely on
   their ability to create a conformant income statement.[RFC3774]

   One key cause of the current ambiguous management structure is the
   lack of even one full-time staff member who reports directly to the
   IETF leadership.  For example, the IETF Chair and IAB Chair attempt
   to prepare an annual budget and do financial reporting, but they do
   so without any professional help.  Among leading standards
   organizations, the IETF is alone in failing to provide any staff to
   assist the leadership in such activities.

   While zero staff is a non-standard way to run a standards body, a
   large staff would run counter to a long-established feeling
   throughout the community that the creation of a large bureaucracy
   would go against the fundamental tenets of how the IETF operates.

   In the IETF, there thus appears to be a philosophy that strongly
   favors outsourcing services whenever possible.  A first step would be
   to hire a single staff member, an Administrative Director.  This
   position would be responsible for tasks such as hiring and working
   with contractors, managing finances, and working with other
   professionals such as lawyers and auditors.  A decision on whether or
   not the ultimate size of the support staff remains at 1 or grows very
   modestly thereafter can be deferred.

   This is a fairly demanding position, as it requires a firm knowledge
   of business fundamentals, such as budgeting, contracting, logistics,
   and MIS operations.  The successful applicant for such a position
   would also have to either be already familiar with the IETF or be
   able to quickly assimilate the culture.  Prior knowledge of IETF
   politics should not be prerequisite for this position, but since an
   Administrative Director would have to work on a day-to-day basis with

Malamud                Expires February 23, 2005               [Page 20]

Internet-Draft      Administrative Support Analysis          August 2004

   a decentralized, consensus-based community, the position will require
   a certain level of political sensitivity.  The position will also
   require a certain technical cluefulness, though again, such skills
   could be acquired on the job in certain cases.

   Creation of this position should be fairly straightforward.  First, a
   job description should be created.  The position can be advertised
   using a variety of media, ranging from the IETF mailing lists to more
   formal mechanisms such as advertisements in publications such as the
   International Herald Tribune, the New York Times, the Economist, or
   the Wall Street Journal.  A yet more formal strategy would be to
   engage a professional search firm.

   Evaluation of applicants might consist of a search committee
   appointed by the IETF Chair.  The committee would conduct an initial
   review of applications, possibly solicit additional applications, and
   present a short-list for further consideration.  This short list of
   applicants could be reviewed by the IESG and IAB, possibly with
   further interviews.  The IESG and/or IAB should specify this
   procedure more fully before beginning the search.

   As part of the drafting of a call for applicants, the IETF leadership
   may want to consider what the IETF leadership groups need in the way
   of support and how they can structure the position in a way that
   attracts the best applicants.  For example, procedural mechanisms
   such as explicitly allowing the staff to be present on mailing lists,
   teleconferences, and meetings may be necessary before applicants will
   consider the position one which is doable.

   A sample draft Call for Applications is attached as Appendix E.

3.2  Recommendation 2: Establish Contracts for Core Services

   The lack of a contractual basis for present services is, as discussed
   earlier, a historical artifact of the dramatic growth of the IETF
   from a few to a few hundred to several thousand participants.

   Establishing a formal basis for such services by the close of this
   calendar year is a fundamental recommendation of this report.  A
   formal understanding for support services can take several forms,
   including contracts or memoranda of understandings.  Since the IETF
   is based on an open process, it is important that all significant
   contracts be published so they have formal standing within the
   context of the IETF community.  Such publication can be on a web
   site, or can be a republication of the contract in the RFC series.

   Just as a contract should be published as an RFC so they have formal
   standing in the community, it is important that any Memoranda of

Malamud                Expires February 23, 2005               [Page 21]

Internet-Draft      Administrative Support Analysis          August 2004

   Understandings published as an RFC have similar standing in the legal
   world.  It is important that such contracts or memoranda have
   adequate legal review to insure that the key elements required in
   contract law are present.

   For organizations providing support services who are not presently
   under contract, there are two broad strategies that can be used to
   move from the present administrative framework to the more formal one
   proposed here: sole source procurement or a Request for Information
   (RFI) or Request for Proposals (RFP) to solicit a variety of bids
   from multiple vendors, including the present providers.

   It is important to note that with the present granularity of
   historical financial information, an RFP will be an essential part of
   understanding the various expense models associated with different
   services levels and provisioning strategies.

   A decision also has to made whether the current services are
   monolithic or can be decomposed into separate pieces.  A case can be
   made that a single vendor for most services can provide the most
   responsive service.  Alternatively, one could argue that some
   services are specialized, such as meeting planning, and might be
   better carried out by a specialist.

   A final factor comes into play, which is the risk to continuity of
   operations caused by any transition.  There is also a financial cost
   to any transition, including capital costs (e.g., acquiring
   sufficient assets to do the job), cash flow requirements (e.g., hotel
   deposits for meetings can be substantial), and professional help
   (e.g., lawyers, accountants, and a variety of other services).

   There are thus a spectrum of options available within the extremes of
   RFP and sole source procurement.  This report recommends one of the
   following three strategies:
   o  *Strategy 1.* Issue an RFP for all core secretariat services.
      This would allow the current provider to bid and thus establish
      contract terms upon a successful bid, but would also allow other
      vendors to compete.
   o  *Strategy 2.* Attempt to negotiate a sole source procurement on
      all of the functions, but after a designated time-out period
      (e.g., 30 days), if the negotiation is not successful, issue an
      RFP.  The term of the sole source procurement could be a subject
      of the negotiation, or a fixed term (e.g., 1 year) could be
      established a priori.  The intention would be to issue an RFP for
      the subsequent contractual period.
   o  *Strategy 3.* Some combination of the two above options.  For
      example, attempt a sole source procurement on two of the three
      functions, and issue an RFP for the third.

Malamud                Expires February 23, 2005               [Page 22]

Internet-Draft      Administrative Support Analysis          August 2004

   Based on research conducted for this report, the author is of the
   opinion that meetings and the core "Clerk" functions would be the
   most difficult to transition to a new provider.  Meetings are
   difficult because of long lead times (and an RFP process would
   further delay 2005 planning unless an interim planning process can be
   established).  The "Clerk" functions have a great deal of
   institutional knowledge, much of which is not properly documented.

   Thus, the author of this report recommends that, if a hybrid strategy
   of attempting a sole source contract on two functions and an RFP is
   used for the third function, that core network services is a good
   candidate for an RFP and meeting planning and "Clerk" functions would
   be a good candidate for sole source procurement negotiations.

   Providing a computing infrastructure is an area with many qualified
   professionals and some well-established industry norms.  This
   strategy would also allow the IETF to move core archives that are
   presently decentralized into a common infrastructure, would provide
   more flexibility to provide resources to workgroups, and would allow
   non-contractor developed tools to coexist with existing resources.

   If an RFP is not issued a particular function, then a sole-source
   contract negotiation would be used.  There should be a clear
   understanding on intellectual property ownership, in particular a
   clear statement about all information flowing through the IETF
   process belonging to the IETF community, including the following:
   1.  Domain names, including iab.org, ietf.org, iesg.org, and
        irtf.org.
   2.  Content of Internet-Draft directories.
   3.  Content of Web sites.
   4.  Subscriber lists for all mailing lists (public and private).
   5.  Mailing list archives for all archived mailing lists (public and
        private).
   6.  Working group database content including charters.
   7.  Internet-Draft history database content.
   8.  Internet-Draft tracker database content.
   9.  Meeting minutes.
   10.  Meeting attendance records, including "blue sheets".
   11.  Archive of expired Internet-Drafts.
   12.  Documents relating to the creation and reporting of working
        group status.
   13.  Copies of any other IETF information including correspondence
        and historical records.

   In addition to intellectual property considerations, any contract
   negotiation should be bounded by two other parameters:
   1.  A transition clause is essential to allow for an orderly
       transition to other vendors in the future.  For example, if

Malamud                Expires February 23, 2005               [Page 23]

Internet-Draft      Administrative Support Analysis          August 2004

       meetings are provided on a one-year support contract, but meeting
       venues are being booked on a longer time scale, a clause in the
       contract would allow the transfer of venue to a new contractor.
       In addition, a fairly standard clause in many such contracts
       would allow the ability for a new contractor to issue employment
       offers to non-managerial employees of the old contractor as a
       transition mechanism.
   2.  A negotiating period time-out clause is essential in such a
       process.  This report recommends that a small team be assembled
       to negotiate such contracts under the direction of the IETF and
       IAB chairs, reporting back for the advice and consent of the IAB
       and IESG, and that any resulting contract be published.  If 30
       days lapse and no agreement is reached, the IAB and IESG should
       have the option, after reporting back to the community, of either
       extending the negotiating period for an additional 30 days, or
       issuing an RFP.

   While establishing a contract for uncontracted services is absolutely
   essential, some attention should also be paid to services provided by
   the IANA or the RFC Editor.  For example, returning to a multi-year
   contract with the RFC Editor instead of the current one-year
   extensions might provide for a larger investment in the function by
   the host institution.  Likewise, agreements with the Internet Society
   and ICANN should be kept current.

3.2.1  Details of Potential RFP Components

3.2.1.1  Provision of a Basic Computing Infrastructure

   Part of the philosophy of the IETF support process is to not make
   large organizations whose sole purpose is to support the IETF.  This
   is still a valid approach.

   In recent years, the support for the IETF has been carried out by a
   small number of organizations working on fairly unconnected tasks
   (RFC Editor at ISI, IANA at ICANN and secretariat and meeting
   services both handled at Foretec).

   Each organization has provided its own facilities for storage,
   publication, information distribution and list maintenance, as they
   saw it required for their tasks.  his is not necessarily an optimum
   distribution of resources.  One could imagine multiple models,
   including:
   o  The IETF controlling a distributed compute platform and storage
      facility, with multiple organizations using that to perform work
      under contract, and using each others' services when appropriate
      (management of the platform being of course one such contract).

Malamud                Expires February 23, 2005               [Page 24]

Internet-Draft      Administrative Support Analysis          August 2004

   o  A distribution much like the present, where suppliers bring their
      own resources, but with tasks distributed differently, with (for
      instance) meeting planning and Web presence maintenance being
      separate tasks, but with increased emphasis on information sharing
      and open access to information.
   o  An even larger concentration of roles, where one service
      organization takes on tasks that are distinct today.

   There is not sufficient information on price, performance or benefits
   of the various approaches today.  A Request for Proposals process,
   however, would generate the necessary information.  An RFP process
   where the components of the work are separated out to the largest
   extent practical will encourage the people who offer proposals in
   response to tell explain which parts of the RFP they would be willing
   to take on, how they would get synergy out of combining them, and
   what services they would be capable of using from other providers.

   The RFP is an information gathering tool, and will be followed by
   extensive negotiations and planning on how the services the IETF
   needs can be supplied.  This needs time, and because of this, sending
   out an RFP earlier rather than later in the decision process will
   provide important input used to structure the work to be performed.

   A draft RFP is contained in Appendix F and picks the following
   decomposition:
   1.  Meeting Planning
   2.  Systems Administration (support infrastructure)
   3.  Mailing list management
   4.  The Web presence
   5.  The "Clerk's Office" which would be responsible for the flow of
       information and administrative support for the IESG and WGs and
       the Internet-Draft publishing service.

   The RFP is structured so proposals may be received for one or more of
   the above requirements.  A single bidder may elect to provide all
   functions, one function, or some combination.  The RFP is structured
   to include a review process, and the selection criteria are based on
   what is best for the IETF as a whole, as opposed to a single formula
   such as lowest price.

   One important factor in all bids for supporting service will be the
   degree of continuity and accountability.  A "key person" principle is
   proposed where an individual contact is identified as responsible
   manager for the function.  It is this person who will give guarantees
   to the IETF for the services being available to the IETF with
   adequate availability and response times, and who will take charge of
   the organization that supplies the services.

Malamud                Expires February 23, 2005               [Page 25]

Internet-Draft      Administrative Support Analysis          August 2004

3.2.1.2  Core Network

   Currently, the IETF does not own any computers, colocation space, or
   transit capacity.  Indeed, the IETF does not even run a web site.
   All of these functions are contracted out, and the contracts include
   full provisioning of the underlying infrastructure.  As mentioned
   above, this is only one possible arrangement.  We do not have data
   that will allow us to know what to choose between the alternatives
   here.

   If adequate resources can be obtained at the right price, including
   servers, colocation space, and bandwidth, and if those resources meet
   the high standards needed to sustain IETF operations, the best thing
   for the IETF may be to operate on such an infrastructure.  Having an
   adequate in-house infrastructure controlled by the IETF also provides
   substantial flexibility in the case of future transitions of key
   contractors, but it also burdens the IETF with the requirement to
   maintain and replace equipment.

   An organization able to provide highly competent systems
   administration would be needed to support a solid computing platform.
   If purchased at commercial rates, this would probably be a
   significant part of the cost of this way of supporting services.  The
   RFP process will tell us what we can depend on.

   In terms of volunteer contributions for specialized areas such as
   nameservice or routing, the IETF may be able to draw upon volunteer
   help from participants.  It would make sense to have the relationship
   with the volunteer be slightly formalized, including a public
   appointment to the named task.  This impresses upon all that such a
   task is one of trust and makes the community aware that the
   individual or organization has assumed this particular
   responsibility.

3.2.1.3  Mail

   The IETF is a mail-intensive operation, with mailing lists for
   working groups, directorates, the IESG, the IAB, and a raft of other
   lists, not to mention the core IETF and announcement lists.

   Certain specialties in computing are considered an art unto
   themselves.  Mail is one of those areas.  The IETF Administrative
   Entity should simply contract the postmaster function to a vendor
   experienced in running environments characterized by high-volume mail
   servers, large numbers of lists with various access and moderation
   policies, a stringent archive requirement, and an ability to
   implement appropriate filtering policies (where the policy, of
   course, is ultimately set by the community).

Malamud                Expires February 23, 2005               [Page 26]

Internet-Draft      Administrative Support Analysis          August 2004

   This task is as much a public service position as it is a contract.
   The task of postmaster to the IETF Administrative Entity should be
   sufficiently attractive that it will attract highly capable bids.

   Since a variety of provisioning options are available for this
   service, the evaluation process should carefully consider each
   proposal for criteria such as stability of service and infrastructure
   redundancy.

3.2.1.4  Community Workspace Support and the IETF Network Presence

   The IETF needs far better support for our various groups that wish to
   maintain a network presence.  While the core document submission
   process is highly structured, currently the operation of individual
   working groups, directorates, or other groups all have very different
   styles.  A variety of styles is a Good Thing and should be supported.

   Systems administration can provide core tools such as web servers,
   FTP servers, and can allocate space to groups.  However, an effective
   network presence for the IETF involves many issues about how we
   archive our information, how we make it easy for new groups to form
   workspaces, and how we interface to our data through search and
   navigation facilities.

   Core systems administration is on a different layer of the stack than
   the applications support that is needed to help maintain a
   productive, happy community with a clueful Internet presence.

   It is proposed that the IETF Administrative Entity needs a webmaster
   to supplement the resources of the systems administrators.  The
   sysadmin can install Apache with appropriate modules, but building a
   core web site for the IETF involves other skills, including knowledge
   of CSS, HTML, XML, and a variety of scripting skills in languages
   such as PHP or PERL or TCL (pick your poison).

   At first glance, this may seem to be a development effort, not an
   ongoing operations effort.  However, we believe a more sustainable
   system can be built with a webmaster task which combines on-going
   responsibility for access to the core IETF information along with a
   support role for the broader community of working group chairs,
   directorates, and the like.

3.3  Recommendation 3: Provide Timely and Uniform Financial Reporting

   This report recommends that all available historical financial
   information be posted in a single public location, and that an
   immediate commitment to post more complete and timely financial
   information in the future be made.

Malamud                Expires February 23, 2005               [Page 27]

Internet-Draft      Administrative Support Analysis          August 2004

   In addition, the IETF leadership should begin formalizing the budget
   process in anticipation of any administrative restructuring efforts.
   Once issues of an institutional home for administrative functions
   have been decided, a full budget with program goals, including any
   relevant transition expenses and a cash flow analysis, will be
   required by any potential groups helping finance the IETF
   Administrative Entity as part of the funding group's annual budget
   planning processes.

   These functions are all envisioned to be the primary responsibility
   of the Administrative Director, with some contractor assistance for
   accounting and auditing tasks.

3.4  Recommendation 4: More Focus on Archives

   [RFC3716] stressed the importance of proper attention to the
   persistence and accessibility of records, including the requirement
   that "the IETF needs to maintain and support the archiving of all of
   its working documents in a way that continues to be accessible, for
   all current and future IETF workers." The IETF does not currently
   meet that requirement.  In particular:
   o  Although the RFC Editor maintains an "RFC-Online Project", over
      200 RFCs have yet to be put online.
   o  Archives of IETF working group mailing lists are spotty and
      sometimes unreliable.
   o  The ietf.org Web site does not include a comprehensive archive of
      all Internet-Drafts, though several volunteers in the community do
      maintain such sites on an informal basis.  It should be noted that
      this lack of a public comprehensive archive is a policy decision
      of the IESG.  A private comprehensive archive is a legal
      requirement, as the IETF is the original publisher of
      Internet-Drafts and is sometimes asked for old drafts in cases
      such as patent disputes.  Even if the archive is not available on
      a public site, regular audits of the completeness of the archive
      are necessary.
   o  On a short-term basis, there is no adequate backup for the
      www.ietf.org web site, which has led to periodic accessibility
      issues.
   o  Although videolab.uoregon.edu has an archive of past meeting audio
      and video feeds, that archive only dates back to IETF49.

   More attention to this important area is recommended as a key 2005
   goal.

Malamud                Expires February 23, 2005               [Page 28]

Internet-Draft      Administrative Support Analysis          August 2004

4.  Options for an Institutional Basis for Administrative Activities

4.1  Discussion of Organizational Form and Legal Domicile

   This report frames the question of organizational form as follows:
   o  Should the IETF administrative support organization be
      incorporated?
   o  If so, should it be now or later?
   o  If so, what domicile and specific form should be chosen?
   o  If so, what would be the specific nature of the relationship
      between any potential new organization and the Internet Society?

   As seen above, there is a close relationship between ISOC and the
   IETF that is independent of the administrative restructuring of IETF
   support.

   The requirements for the relationship between the IETF Administrative
   Entity and the IETF Community are:
   o  The process must generate the support that the IETF needs.
   o  The process must be transparent; people and organizations who
      donate money to the standards process must be able to verify that
      the funds have been spent on effective support of the standards
      process.
   o  The process must be efficient; the overhead of a large bureaucracy
      is not in the best interest of the IETF.
   o  The process must be flexible enough to allow the IETF support
      structure to adapt to changing IETF community requirements.
   o  The administrative entity must be responsible to the IETF.

   As an aide for discussion purposes, this report proposes four
   scenarios:
   o  *Scenario A.* The Internet Society role as legal home of the IETF
      is augmented to include the new administrative function.  As
      issues arise in the future, appropriate memoranda of understanding
      or other formal checks and balances can be developed.
   o  *Scenario B.* As in Scenario A, the Internet Society's role is
      augmented to include administration of IETF support functions.
      However, instead of waiting to understand what the issues are, the
      IETF takes proactive steps to take a more fundamental role in the
      Internet Society as its administrative home.  Thus, the difference
      is that in Scenario B, more time is spent up-front on formal
      definition of the relationship.  Needless to say, more up-front
      definition is sometimes a good thing, but can also lead to a great
      deal of time solving problems that don't exist.
   o  *Scenario C.* This scenario says that the IETF community is ready
      and willing to undertake the responsibilities for managing its
      administrative efforts.  A new incorporated body is formed to
      house those functions.  That body would be closely tied to the

Malamud                Expires February 23, 2005               [Page 29]

Internet-Draft      Administrative Support Analysis          August 2004

      Internet Society through a variety of mechanisms that show that
      the two entities are part of a "symbiotic whole."
   o  *Scenario D.* As in Scenario C, a new incorporated body is formed
      to house the administrative support functions.  But, instead of
      being as closely linked to the Internet Society, the entity bears
      much more of the burden of setting up an infrastructure.  In this
      scenario, the IETF community is now completely responsible for
      ensuring all aspects of its continued, long-term financial
      viability.

4.2  Scenario A: ISOC Operating Unit

   Presently, the Internet Society administers the RFC Editor contract
   under the direction of the IAB, provides the IAB and IETF
   discretionary funds, and purchases insurance to cover some people
   involved in IETF decision making.  The Internet Society also raises
   all funds need in excess of those provided by IETF meeting revenue.
   In this scenario, the Internet Society simply augments their current
   provision of services with appropriate contracts and program
   management services to manage the core IETF support contracts,
   including a significant number of large and small meetings, a fairly
   complex Clerk's Office, and a significant Internet presence.

   In this scenario, the Internet Society would employ the
   Administrative Director proposed in Section 3.1.  The job search
   would be conducted in consultation with the IAB and IESG.  That
   employee would in turn, again in consultation with the IAB and IESG,
   manage any sole source procurements or RFP processes that are
   approved by the Internet Society in consultation with the IAB and
   IESG.  The IETF activities would appear as line items in the Internet
   Society budget, with revenue and expenses clearly allocated by
   program area (as they currently are on ISOC financials).

4.2.1  Division of the Internet Society

   In this scenario, the IETF administrative activities would be
   undertaken as a Division of ISOC.  It would have as its day-to-day
   operational head a senior Administrative Director who would have
   operational responsibility for all the IETF administrative activities
   on behalf of the IETF community.  This individual would be an
   employee of ISOC, but management oversight would be structured to
   include direct IETF involvement including the IETF and IAB Chairs,
   and/or an Oversight Committee appointed by some IETF-specified
   process.

   Budgets would be established each year in consultation with the IAB
   and IESG, and approved by the ISOC Board as well as the IETF
   leadership.  The IETF Division would have its own bank account and

Malamud                Expires February 23, 2005               [Page 30]

Internet-Draft      Administrative Support Analysis          August 2004

   the Administrative Director would collect and manage all receipts
   (including revenues from ISOC destined for the IETF) and
   disbursements.  Operationally, this reserves for the IETF Division
   the ability to prioritize and re-allocate funds within the
   constraints of the approved budget as seems best and will provide
   maximum flexibility in service provisioning.  Once the budget has
   been agreed upon it would be the responsibility of the IETF
   Administrative Director to manage it.  All IETF finances would be
   separately accounted for and fully transparent.

   In particular,
   o  The IETF Administrative Director would have ISOC signatory
      authority for IETF contracts and would be responsible for managing
      all contractors/vendors to the IETF.
   o  The responsibilities that the IETF Administrative Director would
      have with respect to IETF activities would be determined by
      standard IETF processes (BCPs, RFCs, etc.)
   o  The Administrative Director would be hired (and removed) jointly
      by the IETF Chair, IAB Chair and the ISOC CEO according to a job
      description established by the IETF community.  Performance would
      be evaluated by those same individuals, and the personnel home for
      the Administrative Director would be in ISOC (benefits, pension,
      medical, etc.).
   o  The IETF Administrative Director could draw upon the other
      resources (accounting, technical infrastructure, reception, legal,
      etc.) of ISOC.

4.2.2  Intended benefits

   By hosting the IETF administrative activity within an existing
   organization, there is the possibility of cost reduction by sharing
   resources.  This proposal would give closer and more flexible access
   to a broad range of skills and competencies (e.g., sharing portions
   of employees time as needed).  Note: IT facilities is one area where
   the IETF may need separate support/facilities.

   Under this model, the IETF could continue to expect ISOC to take a
   significant fallback responsibility for any liabilities, whether
   financial or legal, that might be incurred by the IETF.

   This model also provides an unambiguous fund-raising model, in which
   the possibility of confusion between ISOC and IETF efforts is
   minimized.

4.2.3  Additional Considerations

   One of the considerations from which the IETF has long benefited is
   the current separation between corporate donations and IETF actions.

Malamud                Expires February 23, 2005               [Page 31]

Internet-Draft      Administrative Support Analysis          August 2004

   Instantiating this scenario would require continued care to ensure
   that the IETF maintains a reasonable distance from the funding
   streams (apart from meeting fees) and minimizes the potential of
   conflicts of interest with funding sources and other perceptions of
   excessive influence by particular participants or their
   organizations.

   While standards have always been an important component of ISOC's
   activities, ISOC as a whole does have a broader mandate, and its
   Board must be selected and empowered to meet that broader mandate,
   not just the IETF's needs.  Nevertheless, from ISOC's perspective, it
   is by design and in the governance structure, very complementary and
   ISOC has always seen its core responsibility as being to the IETF.
   The dedicated IETF Administrative Director and separated budget are
   seen as a means of ensuring continuous and adequate attention to IETF
   activities, and 3 IETF appointed seats on the Internet Society Board
   provides representation within the governing body.

   Under this model, the IETF administrative activity is naturally
   responsive to and part of the overall ISOC management structure and
   its evolution.  That is, the scenario described here is modeled on
   ISOC's current management and mission structure, assuming that it
   will be largely static over time.  ISOC has demonstrated several
   times in the past that it was willing and able to change its own
   governance structure in ways that benefited the IETF activity, and
   this specific proposal assumes that will continue to be the case,
   without making specific provision for ensuring it.

   As the Internet Society, and the Internet Society Board, would bear
   responsibility for making sure the continued IETF support function is
   carried out in a fashion that is responsible to and responsive to the
   IETF community, this scenario is potentially a large undertaking and
   should take careful consideration of the financial and logistical
   implications of undertaking such an operation and of the requirements
   of [RFC3716].

   (Note that careful consideration of the responsibilities and the size
   of the undertaking applies to all actors in all scenarios, and
   applies equally to the Internet Society, the IETF community, and to
   any other support organizations.)

4.3  Scenario B: More Formalized ISOC Operating Unit

   The philosophy in Scenario A is understand the basic parameters of
   how the relationship would work, but instead of spending considerable
   time defining all possible parameters, get to work quickly on
   pressing problems and deal with longer-term institutional issues as
   they come up or after experience is gained.  Another strategy,

Malamud                Expires February 23, 2005               [Page 32]

Internet-Draft      Administrative Support Analysis          August 2004

   outlined here as Scenario B, is to lay down more of those basic
   parameters about how the relationship would work, enshrining those
   parameters in a process BCP RFC.

   Scenario B leverages the benefits of Scenario A, while providing for
   additional mechanism further define the relationship of the Internet
   Society to the IETF community and what the provision of
   administrative support functions means.  Scenario B is identical to
   Scenario A, but more up-front work is put into defining the
   relationship.

   These mechanisms are simply suggested directions to explore based on
   suggestions from early reviewers of this draft, and further
   discussions may add or remove mechanisms from this list:
   o  Mechanism 1: Modify the Internet Society bylaws and articles of
      incorporation to explicitly recognize this expanded role and to
      explicitly refer to process BCP RFCs such as [RFC2026], [RFC3777],
      [RFC2418], and their successors as the governing mechanism for the
      standards process.
   o  Mechanism 2: Re-task the three IETF appointees to the Internet
      Society Board of Trustees so that they are representatives of the
      IETF and can receive instructions from the IETF leadership on
      particular issues.  [[anchor24: Several reviewers have pointed out
      drawbacks of this mechanism, particularly the loss of independence
      of those director seats.  These reviewers have pointed out that if
      the IETF and IAB Chairs have seats on the board as ex-officio
      members, sufficient representation of IETF interests is present.]]
   o  Mechanism 3: Give the IETF and IAB Chairs ex-officio, non-voting
      seats on the Internet Society Board of Trustees.
   o  Mechanism 4: Grant the Administrative Director observer rights at
      Internet Society Board of Trustee and Executive Committee
      meetings.
   o  Mechanism 5: Create a Memorandum of Understanding between the IETF
      and the Internet Society outlining operational parameters, such as
      how contract services get managed, how financial results are
      reported, and how other services such as insurance shall function.
      [[anchor25: Reviewers have noted that this mechanism would be
      necessary under Scenario A as well.]]
   o  Mechanism 6: Require that Internet Society meeting notices also
      include notice of consideration of issues affecting the IETF.
      This mechanism allows for community feedback on those issues prior
      to any decisions.  A variant of this mechanism would allow the IAB
      and IESG to assert that a particular issue is critical to the
      functioning of the IETF, thus requiring a supra-majority of the
      Board to approve the action.
   o  Mechanism 7: Hold an open ISOC annual Board of Trustees meeting at
      an IETF plenary meeting to facilitate more community
      participation.

Malamud                Expires February 23, 2005               [Page 33]

Internet-Draft      Administrative Support Analysis          August 2004

   As noted above, these mechanisms are simply "straw-men" proposed by
   members of the community.  Any decision to pursue this Scenario, as
   with all other Scenarios, will require a careful look at the specific
   language and provisions needed to meet the overall goals set by the
   community.  As noted in Section 1.3, this would likely be in the form
   of a process BCP RFC.

   The intended benefits of this Scenario are as in Scenario A, with the
   additional intended benefit of bringing the IETF community and ISOC
   community more closely together to manage their futures.

4.4  Scenario C: Well-Defined Entity With Close Ties to ISOC

   In this scenario, administrative support functions for the IETF are
   legally housed in a focused, incorporated institution (although the
   Administrative Directory might be physically housed within the
   Internet Society).  This scenario, as well as Scenario D, raises a
   series of issues as to the form and legal domicile of such an
   organization.

   Scenario C envisions a number of concrete linkages with the Internet
   Society, which supplement the current close interconnection of the
   IETF community with ISOC.  For example, under this scenario, primary
   fund raising responsibility would be invested in the Internet
   Society, allowing ISOC to create a unified fund raising voice
   (thought the proposed IETF Foundation would still be in a position to
   accept in-kind contributions).  In addition to the fund-raising
   agreements, this Scenario envisions a variety of other linkages, such
   as continued cooperation on education and policy.

4.4.1  How Scenario C Might Work In Practice

   There are a variety of legal forms that a formal IETF administrative
   support organization could take, but the public, non-commercial
   nature of the IETF standards process points fairly clearly to the
   formation of a non-profit organization of some sort.  A non-profit
   organization, if formally recognized, has substantial benefits, such
   as exemption from income tax, relief from VAT and sales taxes when
   procuring services, and the ability for certain contributors to
   deduct donations made to the organization.

   It also seems important symbolically that any legal underpinning that
   creates an organization for administrative support functions should
   reflect the non-profit nature of the IETF as well as reflect the
   basic nature of the IETF, which has participants and not members.
   While there are numerous organizational structures available, the
   most straightforward form for the providing IETF administrative
   support is likely to be a non-profit corporation with no members and

Malamud                Expires February 23, 2005               [Page 34]

Internet-Draft      Administrative Support Analysis          August 2004

   no stockholders.

   In addition, any formal organization for administrative support needs
   to take into account some of the unique characteristics of the IETF:
   o  It is possible that none of the members of the board of the
      administrative support organization will come from the country
      that the organization is incorporated in.
   o  The IETF already has a decision making process for a large number
      of our important decisions.  The incorporating law should allow us
      to subordinate the administrative support organization to these
      already-existing processes, as they exist now and as they may
      change in the future.

4.4.1.1  Where Might the Administrative Support Organization Be
        Domiciled?

   Perhaps the most difficult question to consider is which country the
   IETF support organization should incorporate in.  A characteristic of
   the IETF is that we are individual participants.  Unlike many
   standards bodies, the participants do not represent employers and,
   unlike the most formal standards bodies, participants do not
   represent countries.

   There is a predisposition to strongly consider countries other than
   the United States, simply because the IETF is an international group
   and a large number of key Internet institutions are already in the
   United States.  Incorporation of the IETF administrative support
   organization is an important milestone, and a predisposition is to
   try to show diversity.

   Nonprofit incorporation in a number of countries with significant
   nonprofit sectors as well as a significant number of IETF
   participants was considered.  These countries include France, Japan,
   the Netherlands, Switzerland, the United Kingdom, and the United
   States.

   Several countries were initially ruled out because their nonprofit
   laws do not permit entities that are not member-based, or have local
   requirements such as conducting business in a certain language.  In
   other cases, there are difficult to meet local requirements for
   non-profits.  For example, in order for an organization to qualify
   for tax exemption in the United Kingdom, an organization has to fall
   under one of four "heads" of charity.  Three of these are
   general-purpose heads, including the relief of poverty, advancement
   of education, and the advancement of religion.  However, none of
   these three are the intended direct focus of the IETF administrative
   support organization.  The fourth category is "purposes beneficial to
   the community" and it appears that our local nexus to the country is

Malamud                Expires February 23, 2005               [Page 35]

Internet-Draft      Administrative Support Analysis          August 2004

   somewhat slim and might be viewed somewhat skeptically by the Charity
   Commissioners.

   As part of this analysis, a "flag of convenience" approach, such as
   the Bahamas, was considered and ruled out.  It does not seem that an
   off-shore registration poses substantial benefits and would certainly
   make it appear that the IETF administrative support organization
   perhaps had something to hide.  This is clearly not appropriate.

   Incorporating simultaneously in several jurisdictions to make the
   point that the IETF is not part of any one country was also
   considered.  As appealing as this is in theory, in practice it
   substantially increases the cost of incorporation, the complexity of
   on-going operations, and exposes the IETF administrative support
   organization to liability in multiple legal jurisdictions.

   After weighing a number of issues, it appears that the Netherlands,
   Switzerland, and the United States make the most sense.

   Either of these three jurisdictions would work.  The IETF has strong
   participation from the Netherlands, and a number of nonprofit
   Internet groups have thrived in this environment.  By contrast, we
   have far fewer participants from Switzerland.  However, because
   Switzerland is not part of the European Union, it does not suffer
   from the potential risks of the more activist governmental presence
   in the EU and in the US.

   A U.S.  non-profit, non-member corporation is being recommended under
   Scenario C, but with an important proviso.  This recommendation is
   based on simple considerations of expediency and pragmatism: a
   transition will be simplest and least risky (in the short term).
   Since there are enough issues on the table, it seems easiest to
   simplify the equation by taking this variable out.  The reasoning is
   as follows:
   o  Administrative support for the IETF is currently enmeshed in a
      series of relationships with other institutions, most of which are
      also U.S.-chartered non-profit organizations.  Any change in the
      institutional status of administrative support functions will
      require familiarity with U.S.  nonprofit law.  Incorporation in
      another country would require familiarity with those laws as well.
      Thus, the incorporation expenses would be higher and the process
      would take longer.
   o  U.S.  law has a strong concept of "nexus," which is a
      determination of when a foreign organization has enough
      relationship to U.S.  law to fall under the jurisdiction of a U.S.
      court.  Because of a long history of operating in the U.S.,
      numerous meetings in the U.S., and the large number of U.S.
      residents who are participants and leaders, we feel it is likely

Malamud                Expires February 23, 2005               [Page 36]

Internet-Draft      Administrative Support Analysis          August 2004

      that U.S.  courts would find nexus in relation to our US-based
      activities, even if the IETF administrative support organization
      was incorporated in another country.  In other words,
      incorporating in a country besides the U.S.  does not necessarily
      free the support organization from any perceived vagaries of U.S.
      law.
   o  Incorporating in a country other than the US may have tax
      implications if the Internet Society is providing funding support.
   o  U.S.  corporations have traditionally been large contributors to
      the development of public aspects of the Internet, a category into
      which IETF activities fall (and consequently, the activities of an
      IETF administrative support organization fall).  U.S.
      corporations are somewhat chauvinistic, and it is our experience
      in raising funds that it is easier to get a donation if the
      recipient is a duly-chartered U.S.  tax-exempt organization.  Not
      surprisingly, non-U.S.  corporations have shown more flexibility
      in this regard.  Note that under this scenario, the Internet
      Society would take primary responsibility for fund-raising,
      however deductibility of donated resources such as computers and
      bandwidth is still useful.
   o  It is very likely that an IETF administrative support organization
      would be deemed to clearly fall under the "scientific" and
      "educational" grounds for classification as a tax-exempt charity
      under section 501(c)(3) of the IRS code, so a tax-exempt
      application should be quite straight-forward.
   o  The incorporation laws of the U.S.  states being considered do not
      require that any members of the Board of Trustees be of a certain
      nationality or state residency (e.g., there are no "local
      director" requirements).  The U.S.  Dept.  of Commerce
      foreign-controlled organization reporting requirements apply only
      to "business enterprises", and do not apply to non-profit entities
      such as an IETF administrative support organization.

   That said, it should be stated very clearly that any of the three
   incorporation domiciles (Switzerland, Netherlands, and U.S.) could
   probably be made to work.  If the community feels a further in-depth
   examination of alternative domiciles is in order, and is willing to
   bear the increased costs of time and money, alternative domiciles
   could be more carefully examined.

   If incorporating in the U.S., Virginia seems a logical pick as the
   state of domicile to allow the IETF administrative support
   organization to make use of ISOC headquarters to house its single
   employee (though the employee might be able to be housed at the
   Internet Society even if the incorporation were elsewhere, for
   example the ISOC Geneva office).  A variety of other options were
   examined as states of incorporation, including [Delaware] and
   [California], but there appeared to be no significant advantages.  In

Malamud                Expires February 23, 2005               [Page 37]

Internet-Draft      Administrative Support Analysis          August 2004

   particular, there are no significant differences in issues such as
   director liability that would make incorporating outside the place of
   actual domicile attractive.

4.4.1.2  Sample Draft Core Principles

   [ed.: This section intends to state basic principles of establishment
   and governance, suitable for publication, after considerable
   discussion, as a procedural Best Current Practice document.]

4.4.1.2.1  Sample Draft Principles of Establishment and Governance

   The following principles are proposed for the establishment and
   governance of an administrative support organization in support of
   the IETF under Scenario C, and are based on the Sample Draft Articles
   of Incorporation attached in Appendix D.1 and the Sample Draft Bylaws
   attached in Appendix D.2:
   1.  The name of the organization shall be the IETF Foundation.
   2.  The IETF Foundation shall be incorporated under the laws of the
       State of the Virginia in the United States as a non-stock
       corporation with a domicile in the State of Virginia and shall
       apply for exemption from U.S.  taxation under section 501(c)(3)
       of the Internal Revenue Code of the United States.
   3.  The IETF Foundation shall have no members or shareholders.
   4.  The IETF Foundation shall be governed by a Board of Trustees, who
       shall be responsible for the fiscal, legal, and administrative
       infrastructure that support the activities of the IETF.  The
       governance of the IETF, the standards process, and all other
       aspects of how we make our standards are defined in the
       procedural Best Current Practice RFC series, which will be
       explicitly referenced in the organization documents of the IETF
       Foundation.
   5.  The Board of Trustees shall consist of a fixed, odd number of
       members, initially set at 7 members.
   6.  The annual meeting of the Board of Trustees of the IETF
       Foundation shall be announced on the IETF mailing list at least
       30 days before it occurs and must be held at a regular IETF
       meeting.  This meeting shall be open to IETF attendees and
       minutes shall be promptly posted on-line.
   7.  The Board of Trustees shall appoint a Secretary and a Treasurer,
       who need not be members of the Board of Trustees.  The
       Administrative Director of the IETF Foundation shall provide
       staff support to the Board of Trustees.
   8.  The Board of Trustees shall be composed to strike a balance
       between outside and "inside" directors.  It is proposed that the
       IETF and IAB chairs hold voting, ex-officio seats, and that
       mechanisms such as the Nominating Committee and the appointment
       of certain seats by the Internet Society fulfill the outside

Malamud                Expires February 23, 2005               [Page 38]

Internet-Draft      Administrative Support Analysis          August 2004

       director obligations.

   The Board of Trustees would have strong governance over a limited
   scope of activities (e.g., the fiscal, legal, and administrative
   infrastructure that are the charter of the IETF Foundation) but would
   have no authority over the IETF standards process.  In this board
   composition, the ISOC and Nomcom appointments insure that outside
   directors with no perceived conflicts of interest are on the board.

   All nominating bodies should make strong fiscal, legal, and
   administrative acumen essential selection criteria for this position.
   However, we should note strongly that the Chairs of the IAB and IETF
   are ex-officio members (e.g., they are full voting members who hold
   the position based on their official roles as chairs of these two
   bodies), and that it is not expected that the current criteria for
   selection of these two positions should be changed.

   For position-based appointments such as the IETF Chair, the Trustee
   would serve concurrent with their normal appointment.  For non
   position-based appointments, a term proposed for the nominated
   positions is three years with staggered appointments.  However, the
   nominating body might have the power to change their appointee during
   their term.

   All members of the Board of Trustees IETF Foundation are subject to
   the same recall procedures in effect for the IETF leadership such as
   members of the IAB and IESG.  [[anchor31: Mike St.  Johns comments
   that use of the Nomcom and the recall procedure are both
   inappropriate as they are tailored towards selection of and recall of
   technical leadership, which is not necessarily appropriate for the
   fiscal, legal, and administrative skill sets needed in a board for
   the Foundation.  --Mike St.  Johns]]

4.4.1.2.2  Sample Draft Principles of Operation of a Potential IETF
          Foundation

   [ed.: This section intends to state basic principles of establishment
   and governance, suitable for publication, after considerable
   discussion, as a procedural Best Current Practice document.  This
   section is very tentative and contains principles that are used to
   draft bylaws and articles of corporation, samples of which are shown
   in Appendix D.1 and Appendix D.2.]

   The following are some general principles for the operation of the
   IETF Foundation:
   1.  The IETF Foundation shall employ a Administrative Director of the
       IETF Foundation, who shall be hired by the Board of Trustees with
       the the advice and consent of the IESG and IAB.

Malamud                Expires February 23, 2005               [Page 39]

Internet-Draft      Administrative Support Analysis          August 2004

   2.  All support services shall be contracted in an open and
       transparent manner.
   3.  The Administrative Director shall submit a proposed annual budget
       to the Board of Trustees at least 90 days before the beginning of
       the fiscal year.  Such budget shall be developed with the advice
       and consent of the IAB and IESG.
   4.  The Administrative Director shall serve on the Board of Trustees
       as a non-voting, ex-officio member.
   5.  The Board of Trustees shall select a professional audit firm and
       shall commission an audit immediately upon the close of each
       fiscal year.
   6.  The IETF Foundation will conduct financial reporting in a fully
       transparent fashion.  Audits shall be conducted promptly and
       published.  Tax returns shall be published.  Detailed financial
       statements will be published on a regular basis, including timely
       reports on the financial results of IETF meetings.

4.5  Scenario D: Autonomous Entity

   Scenario D has much of the same analysis as for Scenario C.  However,
   in this scenario, instead of a mutually-beneficial symbiotic whole,
   the IETF Foundation sets out to ensure its own viability independent
   of the Internet Society.  For instance, the foundation might pursue
   direct contributions from industry instead of relying on a unified,
   ISOC-based fund raising effort as outlined in Scenario C.

   Needless to say, direct solicitation of funds would require great
   care to isolate the IETF standards process from funding agencies so
   that there can be no question of undue influence.  In Scenarios A
   through C, this isolation of process from funding is provided by the
   Internet Society.

Malamud                Expires February 23, 2005               [Page 40]

Internet-Draft      Administrative Support Analysis          August 2004

5.  Future Work

5.1  Short-Term

   This report outlines some fundamental decisions facing the IETF
   community about how administrative support functions should be
   procured and what institutional framework they should be housed in.
   If a consensus is reached on a direction to move on these key
   decisions, a number of short-term tasks will be required:
   1.  Formulation of a budget for 2005, including a cash flow analysis.
   2.  If formal incorporation is chosen, drafting and filing of bylaws
       and articles.  If an operating unit is chosen, drafting of any
       memoranda of understanding.
   3.  If a decision is made to negotiate a sole source contract for one
       or more functions, a negotiating team would need to be appointed.
   4.  If a decision is made to issue a Request for Proposal for one or
       more functions, a drafting team would need to be appointed and a
       process for evaluation described.
   5.  If a decision is made to appoint an Administrative Director, a
       call for applicants would need to be issued.

5.2  Long-Term

   While [RFC3716] set out principles for administrative restructuring,
   it should be remembered that administrative restructuring is just one
   of the tasks facing the IETF.  [RFC3774] set out a number of
   fundamental issues facing the community.  Any administrative
   restructuring should be performed quickly and efficiently, allowing a
   renewed focus on more important issues, such as how the IETF can
   remain and become "an open global community of network designers,
   operators, vendors, and researchers producing technical
   specifications for the evolution of the Internet architecture and the
   smooth operation of the Internet."[RFC3233]

   Much of that focus on "more important issues" is already present in
   the IETF today.  Working Groups such as [NEWTRK] and [ICAR] are
   looking hard at the basic IETF processes and how they can be made
   better.

   In considering the future, it is often worth looking at the past.
   Edwin T.  Layton, Jr., in his 1986 study of the rise (and fall) of
   standards bodies in 1900's, tells of an interesting group, the
   Institute of Radio Engineers (IRA).  Founded in 1912, the IRA was
   different from other professional bodies of the time, with a focus on
   individual instead of corporate membership, an adherence to
   engineering excellence, and, despite being a predominantly American
   body, insisting that the word "American" not be added to the IRE's
   name as a way of emphasizing the international nature of their

Malamud                Expires February 23, 2005               [Page 41]

Internet-Draft      Administrative Support Analysis          August 2004

   pursuits.[Layton] The IRA was founded in reaction to dissatisfaction
   with a more formal body of the time, the American Institute of
   Electrical Engineers (AIEE).  The IRA became known for pioneering
   work in standards area such as FM and commercial black-and-white and
   color television.  Although the IRA was one of the smaller standards
   bodies, it was one of the most effective.[Hoffman] In 1963, the IRA
   merged with the AIEE to become the IEEE.

   Layton's study of professional societies and standards bodies in the
   engineering profession from early the 1900 to the 1960s is highly
   instructive, particularly the way different groups dealt with the
   tensions between the role of participants as individuals engineers
   versus their other roles as corporate employees or representatives of
   countries.  The long-term relevance of the IETF is directly tied to
   the ability of the community to focus on core values such as "rough
   consensus and running code"[RFC1958] and an avoidance of
   entanglements at layers 8-10 of the OSI Reference Model.[OSI]

   As Thomas Huxley once commented in describing the conduct of the
   affairs of the Royal Society, "our business was (precluding matters
   of theology and state affairs) to discourse and consider of
   philosophical enquiries, and such as related thereunto."[Huxley] The
   IETF can certainly learn much from an examination of it's own guiding
   principles and by examining the history of other SDOs such as the
   Royal Society and the Institute of Radio Engineers.

Malamud                Expires February 23, 2005               [Page 42]

Internet-Draft      Administrative Support Analysis          August 2004

6.  IANA Considerations

   [RFC2434] states each Internet-Draft should contain an "IANA
   Considerations" section.  [RFC3716] noted that a frequent problem for
   the IANA is documents that do not contain such a section, thus
   requiring a full scan of the document.

   This submission contains no specific modifications to existing
   registries or creation of new registries.  However, the submission
   contains a number of sections that may impact the overall operation
   of the IANA.  A full scan of the document is thus recommended.

Malamud                Expires February 23, 2005               [Page 43]

Internet-Draft      Administrative Support Analysis          August 2004

7.  Security Considerations

   Improper formulation of the legal framework underlying the IETF may
   expose the institution and individuals in leadership positions to
   potential legal risks.  Any such risk under this plan appears to be
   equivalent to the risk faced by the community under the current legal
   framework.  This risk is further mitigated by a thorough review by
   legal counsel, and by use of insurance coverage.

   The legal exposure is best minimized by a careful adherence to our
   procedures and processes, as defined by the Best Current Practice
   Series.  A carefully stated process, such as the BCP documents that
   govern the selection of leadership positions and define the standards
   process are the best insurance against legal exposure, provided care
   is taken to stick to the process standards that have been set.
   Adherence to a public rule book and a fully open process are the most
   effective mechanisms the IETF community can use.

   Improper management controls and procedures or other imprudent fiscal
   or administrative practices could expose the IETF to a risk of
   insolvency.  Careful selection of trustees, a process of budget
   approval, and a methodical system of fiscal controls are necessary to
   minimize this risk.

Malamud                Expires February 23, 2005               [Page 44]

Internet-Draft      Administrative Support Analysis          August 2004

8.  Acknowledgment of CNRI Contribution to the IETF Community

   As this plan proposes a transition from the past to the future, the
   author feel it is essential to acknowledge the enormous contributions
   made to the IETF and the Internet by the Corporation for National
   Research Initiatives (CNRI) and their Chairman, CEO, and President,
   Dr.  Robert E.  Kahn.

   Dr.  Kahn's pioneering early leadership in the evolution of the
   Internet is well-known, including the seminal paper on the
   Transmission Control Protocol,[Cerf and Kahn] his key operational
   role in engineering the early Internet (see, e.g., [RFC0371]), and
   his leadership of the vastly influential DARPA Information Processing
   Techniques Office (IPTO), where he initiated a billion-dollar
   Strategic Computing Program which was responsible for funding,
   guiding, and encouraging technology that makes up much of today's
   infrastructure.

   Perhaps less well-known or appreciated is the contribution that Dr.
   Kahn and CNRI have made to the evolution of the IETF.  Since 1987,
   CNRI has housed the IETF Secretariat, supporting 56 IETF meetings
   with over 55,000 total attendees, not to mention over 30,000
   Internet-Drafts processed, several thousand teleconferences hosted,
   and a theoretically finite but practically uncountable number of
   cookies consumed.

   CNRI's support allowed the IETF community to evolve in the way it
   has.  Many of the values we have created as a community were possible
   only possible because we had a professional secretariat to provide
   support.  For example, the IETF takes very seriously the idea that
   individuals, not institutions or countries, are the participants (not
   members) in the process.  A stable secretariat has allowed us to
   preserve those values without worrying about pesky issues such as
   corporate sponsorship or membership fees.

   A number of CNRI and Foretec staff have formed the secretariat over
   the years.  These people have all worked long and hard and, for many
   IETF participants, these staff have been instrumental in making the
   IETF an effective forum for the development of Internet standards and
   technology.  They deserve our sincere and continuing thanks.

   As the IETF has scaled, we have continued to rely on CNRI to provide
   a base of stability.  As the IETF passes the age of 18, it is time
   for the IETF to take responsibility for its own affairs.

Malamud                Expires February 23, 2005               [Page 45]

Internet-Draft      Administrative Support Analysis          August 2004

9.  Acknowledgment of Contributions and Reviews

   A number of people contributed their time in telephone interviews,
   email exchanges, and reviews of the draft.  These exchanges resulted
   in many useful suggestions.  Needless to say, our acknowledgment of
   their contribution should not in any way be used to necessarily infer
   support for anything contained herein.  These individuals include:
   Bernard Aboba, Harald Alvestrand, Fred Baker, Bob Braden, Scott
   Bradner, Brian Carpenter, David Clark, Jorge Contreras, Dave Crocker,
   Steve Crocker, Joao Damas, Leslie Daigle, Lynn DuVal, Patrik
   Falstrom, Bill Fenner, Ted Hardie, Bob Hinden, Paul Hoffman, Geoff
   Huston, Mike St.  Johns, David Kessens, Robert Kahn, Daniel
   Karrenberg, John Klensin, Rebecca Malamud, Allison Mankin, Thomas
   Narten, Jun Murai, Thomas Narten, Eric Rescorla, Pete Resnick, Joyce
   Reynolds, Lynn St.  Amour, Mike St.  Johns, Paul Vixie, Margaret
   Wasserman, and Bert Wijnen.  The author apologizes for any names
   inadvertently omitted.

   This document was created with "xml2rfc" as specified in [RFC2629].

Malamud                Expires February 23, 2005               [Page 46]

Internet-Draft      Administrative Support Analysis          August 2004

10.  References

10.1  Normative References

   [RFC1958]  Carpenter, B., "Architectural Principles of the Internet",
              RFC 1958, June 1996.

   [RFC2014]  Weinrib, A. and J. Postel, "IRTF Research Group Guidelines
              and Procedures", BCP 8, RFC 2014, October 1996.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC2028]  Hovey, R. and S. Bradner, "The Organizations Involved in
              the IETF Standards Process", BCP 11, RFC 2028, October
              1996.

   [RFC2031]  Huizer, E., "IETF-ISOC relationship", RFC 2031, October
              1996.

   [RFC2223]  Postel, J. and J. Reynolds, "Instructions to RFC Authors",
              RFC 2223, October 1997.

   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
              Procedures", BCP 25, RFC 2418, September 1998.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2555]  Braden, R., Reynolds, J., Crocker, S., Cerf, V., Feinler,
              J. and C. Anderson, "30 Years of RFCs", RFC 2555, April
              1999.

   [RFC2850]  Internet Architecture Board and B. Carpenter, "Charter of
              the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
              May 2000.

   [RFC2860]  Carpenter, B., Baker, F. and M. Roberts, "Memorandum of
              Understanding Concerning the Technical Work of the
              Internet Assigned Numbers Authority", RFC 2860, June 2000.

   [RFC3005]  Harris, S., "IETF Discussion List Charter", BCP 45, RFC
              3005, November 2000.

   [RFC3184]  Harris, S., "IETF Guidelines for Conduct", BCP 54, RFC
              3184, October 2001.

Malamud                Expires February 23, 2005               [Page 47]

Internet-Draft      Administrative Support Analysis          August 2004

   [RFC3233]  Hoffman, P. and S. Bradner, "Defining the IETF", BCP 58,
              RFC 3233, February 2002.

   [RFC3667]  Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
              3667, February 2004.

   [RFC3668]  Bradner, S., "Intellectual Property Rights in IETF
              Technology", BCP 79, RFC 3668, February 2004.

   [RFC3677]  Daigle, L. and Internet Architecture Board, "IETF ISOC
              Board of Trustee Appointment Procedures", BCP 77, RFC
              3677, December 2003.

   [RFC3683]  Rose, M., "A Practice for Revoking Posting Rights to IETF
              mailing lists", BCP 83, RFC 3683, February 2004.

   [RFC3710]  Alvestrand, H., "An IESG charter", RFC 3710, February
              2004.

   [RFC3716]  Advisory, IAB., "The IETF in the Large: Administration and
              Execution", RFC 3716, March 2004.

   [RFC3774]  Davies, E., "IETF Problem Statement", RFC 3774, May 2004.

   [RFC3777]  Galvin, J., "IAB and IESG Selection, Confirmation, and
              Recall Process: Operation of the Nominating and Recall
              Committees", BCP 10, RFC 3777, June 2004.

10.2  Informative References

   [.]        Malamud, C., Ed., "IETF Administrative Support Functions",
              draft-malamud-consultant-report-00 (work in progress),
              August 2004, <http://public.resource.org/adminrest/>.

   [Bingo]    Anonymous, "Buzzword Bingo", 1996,
              <http://hacks.mit.edu/Hacks/by_year/1996/gore/>.

   [CNRI-2002]
              CNRI, "Form 990 - Return of Organization Exempt from
              Income Tax - 2002", EIN 52-1447747, November 2003.

   [California]
              State of California, "California Corporations Code",
              Undated,
              <http://www.leginfo.ca.gov/cgi-bin/calawquery?codesection=corp>
              .

   [Cerf and Kahn]

Malamud                Expires February 23, 2005               [Page 48]

Internet-Draft      Administrative Support Analysis          August 2004

              Cerf, V. and R. Kahn, "A Protocol for Packet Network
              Intercommunication", IEEE Trans. on Comm., Vol. COM-23,
              pp. 637-648, May 1974.

   [Delaware]
              State of Delaware, "Title 8. Corporations -- Chapter 1.
              General Corporation Law -- Subchapter 1. Formation",
              Undated,
              <http://www.delcode.state.de.us/title8/c001/sc01/index.htm#TopOfPage>
              .

   [FASB-117]
              FASB, "Financial Statements of Not-For-Profit
              Organizations", FASB 117, June 1993,
              <htttp://www.fasb.org/st/summary/stsum117.shtml>.

   [Hoffman]  IEEE Center for the History of Electrical Engineering,
              "The Origins of the IEEE", 1984,
              <http://www.ieee.org/organizations/history_center/historical_articles/history_of_ieee.html>
              .

   [Huxley]   Huxley, T., "On the Advisableness of Improving Natural
              Knowledge (A Lay Sermon Delivered in St. Martin's Hall)",
              Project Gutenberg THX1410, Fortnightly Review 3 (1866):
              626-37, January 1866,
              <http://etext.library.adelaide.edu.au/cgi-bin/pg-html/mirror/pg/etext01/thx1410.txt>
              .

   [I-D.alvestrand-ietf-mission]
              Alvestrand, H., "A Mission Statement for the IETF",
              draft-alvestrand-ietf-mission-02 (work in progress), June
              2004.

   [I-D.daigle-adminrest]
              Daigle, L., "A Proposal for IETF Administrative
              Restructuring", draft-daigle-adminrest-00 (work in
              progress), February 2004.

   [I-D.ietf-problem-process]
              Davies, E. and J. Hofmann, "IETF Problem Resolution
              Process", draft-ietf-problem-process-04 (work in
              progress), January 2004.

   [I-D.ietf-xmpp-core]
              Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Core", draft-ietf-xmpp-core-24 (work in
              progress), May 2004.

Malamud                Expires February 23, 2005               [Page 49]

Internet-Draft      Administrative Support Analysis          August 2004

   [I-D.narten-iana-considerations-rfc2434bis]
              Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs",
              draft-narten-iana-considerations-rfc2434bis-00 (work in
              progress), August 2004.

   [I-D.rfc-editor-rfc2223bis]
              Reynolds, J. and R. Braden, "Instructions to Request for
              Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-07
              (work in progress - do not cite as a normative reference),
              August 2003,
              <http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-07.txt>
              .

   [ICAR]     The IETF, "Charter of the Improved Cross-Area Review
              (icar) Working Group", June 2004,
              <http://www.ietf.org/html.charters/icar-charter.html>.

   [IETF-2001]
              Alvestrand, H., "The Financials of the IETF -- 2001",
              February 2003,
              <http://www.alvestrand.no/ietf/chair/financials.html>.

   [IETF-2002]
              Alvestrand, H., "The Financials of the IETF -- 2002", July
              2003,
              <http://www.alvestrand.no/ietf/chair/financials-2002.html>.

   [IETF-2003]
              Alvestrand, H., "The Financials of the IETF -- 2003", May
              2004,
              <http://www.alvestrand.no/ietf/chair/financials-2003.html>.

   [IETF-2004]
              Alvestrand, H., "The IETF Budget -- 2004", May 2004,
              <http://www.alvestrand.no/ietf/chair/budget-2004.html>.

   [IRS]      U.S. Code, "Title 26, Sec. 501: Exemption from tax on
              corporations, certain trusts, etc.", Undated,
              <http://www4.law.cornell.edu/uscode/26/501.html>.

   [ISOC-2002]
              Internet Society, "Form 990 - Return of Organization
              Exempt from Income Tax - 2002", EIN 52-1650477, October
              2003.

   [ISOC-2004]
              Internet Society, "37th Board of Trustees meeting of the

Malamud                Expires February 23, 2005               [Page 50]

Internet-Draft      Administrative Support Analysis          August 2004

              Internet Society", Resolution 3-20, December 2003, <http:/
              /www.isoc.org/isoc/general/trustees/mtg37.shtml>.

   [Layton]   Layton, E., "The Revolt of the Engineers", The John
              Hopkins University Press, ISBN 0-8018-3287-X, 1986.

   [NEWTRK]   The IETF, "Charter of the New IETF Standards Track
              Discussion (newtrk) Working Group", June 2004,
              <http://www.ietf.org/html.charters/newtrk-charter.html>.

   [OSI]      Wikepedia, "Open Systems Interconnection Reference Model",
              ISO/IEC 7498-1, August 2004,
              <http://en.wikipedia.org/wiki/OSI_seven-layer_model>.

   [RFC-SOW]  Internet Society, "Statement of Work--RFC Editor",
              Undated,
              <http://www.isoc.org/standards/rfceditor/sow.shtml>.

   [RFC0015]  Carr, C., "Network subsystem for time sharing hosts", RFC
              15, September 1969.

   [RFC0371]  Kahn, R., "Demonstration at International Computer
              Communications Conference", RFC 371, July 1972.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [Virginia]
              State of Virginia, "Title 13.1: Corporations, Limited
              Liability Companies, Business Trusts", Undated,
              <http://leg1.state.va.us/cgi-bin/legp504.exe?000+cod+TOC1301000>
              .

Malamud                Expires February 23, 2005               [Page 51]

Internet-Draft      Administrative Support Analysis          August 2004

URIs

   [1]   <http://www.isoc.org/standards>

   [2]   <http://www.xmpp.org/>

   [3]   <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.iana.org%2F&charset=%28detect+automatically%29&doctype=%28detect+automatically%29>

   [4]   <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.rfc-editor.org%2F&charset=%28detect+automatically%29&doctype=%28detect+automatically%29>

   [5]   <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.isoc.org%2F&charset=%28detect+automatically%29&doctype=%28detect+automatically%29>

   [6]   <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.ietf.org%2F&charset=%28detect+automatically%29&doctype=%28detect+automatically%29>

   [7]   <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.iab.org%2F>

   [8]   <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.irtf.org%2F&charset=%28detect+automatically%29&doctype=%28detect+automatically%29>

   [9]   <http://www.ietf.org/PASTMEETINGS/IETF-60b.html>

   [10]  <http://www.ietf.org/PASTMEETINGS/IETF-59b.html>

   [11]  <http://www.ietf.org/PASTMEETINGS/IETF-58b.html>

   [12]  <http://www.ietf.org/PASTMEETINGS/IETF-57b.html>

   [13]  <http://www.ietf.org/PASTMEETINGS/IETF-56B.html>

   [14]  <http://www.state.va.us/cgi-bin/scc-clerkdl.pl?scc819&Articles_of_Incorporation_-_Nonstock_Corporation>

Author's Address

   Carl Malamud (editor)
   Memory Palace Press
   PO Box 300
   Sixes, OR  97476
   US

   EMail: [email-masked]

Malamud                Expires February 23, 2005               [Page 52]

Internet-Draft      Administrative Support Analysis          August 2004

Appendix A.  Consulting Contract

   AGREEMENT FOR CONSULTING SERVICES
   Contract between CARL MALAMUD AND THE INTERNET SOCIETY

   *Contract:*

   Carl Malamud (hereafter known as the Consultant) agrees to provide
   consulting services to the Internet Engineering Task Force (IETF),
   the Internet Architecture Board (IAB) and the Internet Society (ISOC)
   subject to the terms and conditions specified below.  Under this
   agreement, the Consultant is acting as an independent contractor and
   assumes all responsibilities for federal and state income taxes,
   social security and medicare tax, medical insurance, and other
   applicable filings associated with his status.

   *Scope:*

   The Consultant will provide the following services outlined in
   Appendix I.  It is anticipated that the responsibilities will require
   20 days per month to accomplish the objectives for which said
   Consultant was engaged.

   Consultant understands and agrees that this Contract is being
   executed with a view to supporting the IETF/IAB as it considers
   whether, and if so, how, it might wish to restructure for purposes of
   future IETF/IAB endeavors.  In the performance of this Contract,
   Consultant agrees to exercise fair and professional judgment for the
   benefit of the IETF/IAB and to treat all existing and/or potential
   partners of the IETF/IAB in a fair manner while protecting any
   business confidences that each might have.

   *Contract Term:*

   The contract will begin on 21 June 2004 and end on 21 December 2004.
   For services rendered under this contract the Consultant will be paid
   a fee of $16,000 per month due and payable at the end of each month
   upon receipt of an invoice.  Consultant will be required to submit a
   monthly accounting of days worked.  Should the days worked in any
   month exceed 20, no additional fees are due.  The contract may only
   be extended by written agreement specifying new services, terms, and
   conditions as mutually agreed to by both parties.

   *Expenses:*

   All expenses incurred on behalf of the IETF/IAB or ISOC shall be
   billed to ISOC in addition to charges for services provided above.
   Such expenses shall include travel, long distance telephone, business

Malamud                Expires February 23, 2005               [Page 53]

Internet-Draft      Administrative Support Analysis          August 2004

   meals, and other customary expenses as appropriate.  Such expenses
   should be authorized by ISOC, after consultation with the IETF and
   the IAB Chairs, and in advance of the expenditure.

   *Invoicing:*

   Consultant shall submit invoices at the end of each month (pro-rated
   for June and December).  The Internet Society will make best efforts
   to make payment within one week of receipt.  If consultant worked
   less than 20 days, then ISOC may reduce the monthly fee due by 1/20th
   of such fee for each day less than 20.  Invoices may be submitted
   electronically or by mail.  The invoices should be addressed to the
   Internet Society's Finance Director, Lynn DuVal at the Reston office
   (1775 Wiehle Avenue, Suite 102, Reston, VA 20190) or by e-mail at
   [email-masked].

   *Termination:*

   Either party may terminate this Contract by providing ten (10) days
   prior written notice sent by e-mail to the addresses noted below.

   In addition, should the subject matter addressed in this Contract
   become, in whole or in part, the subject matter of any filed or
   threatened litigation then either party may terminate this Contract
   by providing five (5) days prior written notice sent as per the above
   paragraph.

   The days of prior written notice above shall be measured from the
   date sent.

   The Internet Society will be responsible for all fees properly
   incurred under this Contract prior to the effective date of
   termination.

   If such a termination should occur other than at a month-end, then
   payment for services shall be paid pro rata, up to 100% of the
   monthly rate, at the rate of 1/20th of the monthly services fee per
   day worked to termination

   *Miscellaneous:*

   ISOC does not wish for itself or others to receive any confidential,
   proprietary information of any other party without proper permission.
   Consequently, Consultant agrees not to use or divulge, in his efforts
   relating to this contract, any information in any form, tangible or
   intangible, that is the confidential information of any third party,
   whether IETF/IAB, any contractor or partner of IETF/IAB, or any other
   party, to ISOC or any other party without the express written

Malamud                Expires February 23, 2005               [Page 54]

Internet-Draft      Administrative Support Analysis          August 2004

   permission of the party or parties who own or control such
   confidential material and without first disclosing such written
   permission to ISOC.

   Consultant agrees that any tangible or intangible work product that
   results from Consultant's efforts under this Contract (whether by
   Consultant or a contractor to Consultant) shall be the exclusive
   property of ISOC or the IETF/IAB, as appropriate, and this includes,
   without limitation, any invention, product, business process, code or
   other device or discovery that might now or hereafter be entitled to
   protection, registration or ownership under intellectual property
   rights regimens such as, but not only, trade secret, patent,
   copyright, and trademark.

   ISOC may disclose the terms of this Contract to the IETF/IAB or any
   other party having an interest in the subject matter hereof that ISOC
   deems reasonable.

   *Warranties and Indemnities:*

   This written agreement constitutes the full agreement between the
   parties.  No warranties or indemnities are explicitly included or
   implied.

   *Amendments:*

   Amendments to this agreement must be in writing and executed by both
   parties.

   +---------------------------------+---------------------------------+
   |    Executed on behalf of The    |    Executed on behalf of the    |
   |         Internet Society        |            Consultant           |
   +---------------------------------+---------------------------------+
   |          Lynn St. Amour         |           Carl Malamud          |
   |                                 |                                 |
   |         President & CEO         |                                 |
   |                                 |                                 |
   |        [email-masked]        |          [email-masked]         |
   |                                 |                                 |
   |              Date:              |              Date:              |
   +---------------------------------+---------------------------------+

   *Appendix I: Statement of Work*

   The IETF/IAB is considering an Administrative restructuring and has
   asked ISOC to support their efforts.  The contract to which this is
   attached is in furtherance of this endeavor.

Malamud                Expires February 23, 2005               [Page 55]

Internet-Draft      Administrative Support Analysis          August 2004

   Consultant shall become familiar with RFC 3716 as the basis for these
   efforts and shall use such RFC as a reference point in these efforts
   except to the extent that this Contract or any guidance supplied to
   Consultant by IETF/IAB or ISOC under this contract supercedes such
   RFC.

   The types of activities Consultant shall undertake are:
   o  Assist in researching, recommending and ultimately drafting the
      proposed structure/bylaws for the IETF administrative entity;
   o  Revising proposed structure and/or bylaws based on the public
      review, including reviews by counsel;
   o  Negotiate appropriate contract(s) for RFC Editor and/or other
      contractors as a model for eventual use by the IETF administrative
      entity;
   o  Conduct appropriate liaison with the RFC Editor, IANA and
      Secretariat to determine the requirements for inter-organizational
      document flow matched to overall IETF/IAB process needs.
   o  Others as reasonably directed by ISOC, IETF and or IAB

   Deliverables hereunder shall include:
   o  Data Flow: a comprehensive set of requirements for implementing
      appropriate tracking of IETF/IAB documents and reporting of status
      across support organizations.
   o  Negotiated contracts, per the above, that are acceptable to all
      concerned parties and are ready for execution.
   o  Administrative restructuring: documentation and support, as
      appropriate, to the continued evolution of the restructuring
      effort, which shall be periodically reviewed by the IAB, IESG and
      other appropriate parts of the IETF community of interest.

Malamud                Expires February 23, 2005               [Page 56]

Internet-Draft      Administrative Support Analysis          August 2004

Appendix B.  IETF Financial Information

B.1  Consolidated 3-Year Historical Income Statement

   (US$)

   +------------------+------------+-----------+-----------+-----------+
   |                  |   2001 [1] |  2002 [2] |  2003 [3] |  2004 [4] |
   +------------------+------------+-----------+-----------+-----------+
   | REVENUE          |            |           |           |           |
   |                  |            |           |           |           |
   | CNRI/Foretec     |  2,699,239 | 2,350,666 | 2,060,747 | 1,728,125 |
   | Meeting Revenue  |            |           |           |           |
   |                  |            |           |           |           |
   | Less Bank Fees   |     81,365 |    70,309 |    62,826 |    51,844 |
   |                  |            |           |           |           |
   | Net Meeting      |  2,617,874 | 2,280,357 | 1,997,921 | 1,676,281 |
   | Revenue          |            |           |           |           |
   |                  |            |           |           |           |
   | Contribution By  |    535,535 |   550,881 |   614,691 |   663,570 |
   | The Internet     |            |           |           |           |
   | Society [5]      |            |           |           |           |
   |                  |            |           |           |           |
   | Provision of the |         -- |        -- |        -- |        -- |
   | IANA function by |            |           |           |           |
   | ICANN [6]        |            |           |           |           |
   |                  |            |           |           |           |
   | Other            |         -- |        -- |        -- |   150,000 |
   | Contributions    |            |           |           |           |
   |                  |            |           |           |           |
   | TOTAL FUNDS      |  3,153,409 | 2,831,238 | 2,612,612 | 2,489,851 |
   |                  |            |           |           |           |
   |                  |            |           |           |           |
   | EXPENSE          |            |           |           |           |
   |                  |            |           |           |           |
   | ISOC             |            |           |           |           |
   | Expenditures     |            |           |           |           |
   |                  |            |           |           |           |
   | RFC Editor       |    428,300 |   462,368 |   516,460 |   574,570 |
   |                  |            |           |           |           |
   | IETF Chair       |     73,748 |    52,137 |    51,460 |    48,500 |
   | Discretionary    |            |           |           |           |
   | Fund             |            |           |           |           |
   |                  |            |           |           |           |
   | IAB Support      |     13,287 |    14,446 |    37,270 |    24,500 |
   |                  |            |           |           |           |
   | Insurance        |     20,000 |    21,930 |    13,685 |    16,000 |
   |                  |            |           |           |           |

Malamud                Expires February 23, 2005               [Page 57]

Internet-Draft      Administrative Support Analysis          August 2004

   | Total ISOC       |    535,535 |   550,881 |   614,691 |   663,570 |
   | Expenditures     |            |           |           |           |
   |                  |            |           |           |           |
   |                  |            |           |           |           |
   | CNRI/Foretec     |            |           |           |           |
   | Expenditures     |            |           |           |           |
   |                  |            |           |           |           |
   | Secretariat      |    504,584 |   625,124 |   532,936 |   478,000 |
   | Labor            |            |           |           |           |
   |                  |            |           |           |           |
   | IETF Meeting     |            |           |           |           |
   | Costs            |            |           |           |           |
   |                  |            |           |           |           |
   | Food & Beverage  |    862,500 |   705,610 |   513,081 |   487,500 |
   |                  |            |           |           |           |
   | Audio/Visual     |    127,337 |    83,239 |    96,902 |    60,000 |
   |                  |            |           |           |           |
   | Room Rental      |    190,265 |   172,907 |   125,187 |   170,000 |
   |                  |            |           |           |           |
   | Terminal Room    |         -- |        -- |    66,294 |    25,000 |
   |                  |            |           |           |           |
   | Other Meeting    |      1,925 |     8,340 |    13,367 |     6,000 |
   | Costs            |            |           |           |           |
   |                  |            |           |           |           |
   | Total IETF       |  1,182,027 |   970,096 |   814,831 |   748,500 |
   | Meeting Costs    |            |           |           |           |
   |                  |            |           |           |           |
   |                  |            |           |           |           |
   | Non-Meeting      |            |           |           |           |
   | Costs            |            |           |           |           |
   |                  |            |           |           |           |
   | Travel           |     39,122 |    53,838 |    78,947 |    75,000 |
   |                  |            |           |           |           |
   | Materials        |      7,318 |    11,724 |     9,706 |    10,700 |
   |                  |            |           |           |           |
   | Printing &       |     59,431 |    31,459 |    14,266 |    12,000 |
   | Publication      |            |           |           |           |
   |                  |            |           |           |           |
   | Professional     |     24,581 |    61,105 |    12,288 |     9,000 |
   | Services         |            |           |           |           |
   |                  |            |           |           |           |
   | Telecommunicatio |     54,400 |    82,210 |    32,582 |    42,000 |
   | ns               |            |           |           |           |
   |                  |            |           |           |           |
   | Misc.            |     12,003 |       577 |        -- |     4,000 |
   |                  |            |           |           |           |
   | Equipment Rental |      4,668 |       736 |     1,630 |     2,500 |
   |                  |            |           |           |           |

Malamud                Expires February 23, 2005               [Page 58]

Internet-Draft      Administrative Support Analysis          August 2004

   | Total            |    201,523 |   241,650 |   149,419 |   155,200 |
   | Non-Meeting      |            |           |           |           |
   | Costs            |            |           |           |           |
   |                  |            |           |           |           |
   |                  |            |           |           |           |
   | Total            |  1,888,134 | 1,836,870 | 1,497,186 | 1,381,700 |
   | CNRI/Foretec     |            |           |           |           |
   | "Direct"         |            |           |           |           |
   | Expenses         |            |           |           |           |
   |                  |            |           |           |           |
   |                  |            |           |           |           |
   | CNRI/Foretec     |    604,990 |   608,805 |   641,939 |   504,560 |
   | Overhead Charge  |            |           |           |           |
   |                  |            |           |           |           |
   | CNRI/Foretec     |     30,000 |        -- |        -- |        -- |
   | "Performance     |            |           |           |           |
   | Bonus"           |            |           |           |           |
   |                  |            |           |           |           |
   |                  |            |           |           |           |
   | Total            |  2,124,523 | 2,445,675 | 2,139,125 | 1,886,260 |
   | CNRI/Foretec     |            |           |           |           |
   | Expenses         |            |           |           |           |
   |                  |            |           |           |           |
   |                  |            |           |           |           |
   | TOTAL EXPENSES   |  2,660,058 | 2,996,556 | 2,753,816 | 2,549,830 |
   | (ISOC and CNRI)  |            |           |           |           |
   |                  |            |           |           |           |
   |                  |            |           |           |           |
   | SURPLUS/DEFICIT  |     94,750 | (165,318) | (141,204) |  (59,979) |
   +------------------+------------+-----------+-----------+-----------+

   Notes:
   [1] Actual results based on unaudited reports.  Source: [IETF-2001]
   [2] Actual results based on unaudited reports.  Source: [IETF-2002]
   [3] Actual results based on unaudited reports.  Source: [IETF-2003]
   [4] Budgeted.  Source: [IETF-2004]
   [5] ISOC manages expenditures directly.  The revenue line here
      represents funds allocated by the ISOC Board of Trustees for the
      purpose of IETF support.  The figures in this line equal their
      corresponding cells for Total ISOC Expenditures.
   [6] ICANN does not report expenses broken down by functional area,
      nor are the direct and indirect costs associated with the IETF
      parameter registries available.  We thus value this contribution
      as "priceless" for purposes of this analysis.

B.2  Internet Society 2004 Budget Summary

   The Internet Society 2004 Budget was approved at a Special

Malamud                Expires February 23, 2005               [Page 59]

Internet-Draft      Administrative Support Analysis          August 2004

   Teleconference Meeting of the Internet Society Board of
   Trustees.[ISOC-2004] All figures are in U.S.  dollars.

   +------------------+------------+-----------+-----------+-----------+
   |                  |  Standards | Education |    Public |     Total |
   |                  |     Pillar |    Pillar |    Policy |           |
   |                  |            |           |    Pillar |           |
   +------------------+------------+-----------+-----------+-----------+
   | REVENUE          |            |           |           |           |
   |                  |            |           |           |           |
   | Organizational   |  1,050,000 |   242,000 |   200,000 | 1,492,000 |
   | and Platinum     |            |           |           |           |
   | Membership       |            |           |           |           |
   |                  |            |           |           |           |
   | Individual       |            |           |    52,500 |    52,500 |
   | Membership       |            |           |           |           |
   |                  |            |           |           |           |
   | Conferences      |            |   145,000 |           |   145,000 |
   | (INET, NDSS)     |            |           |           |           |
   |                  |            |           |           |           |
   | .org Program     |    900,000 |   450,000 |   550,000 | 1,900,000 |
   | Revenue          |            |           |           |           |
   |                  |            |           |           |           |
   | Other            |    155,000 |           |           |   155,000 |
   | (Contributions   |            |           |           |           |
   | and Security     |            |           |           |           |
   | Expert           |            |           |           |           |
   | Initiative       |            |           |           |           |
   |                  |            |           |           |           |
   | TOTAL REVENUE    |  2,105,000 |   837,000 |   802,500 | 3,744,500 |
   |                  |            |           |           |           |
   |                  |            |           |           |           |
   | EXPENSE          |            |           |           |           |
   |                  |            |           |           |           |
   | ISOC Salaries    |    371,337 |   364,623 |   458,128 | 1,194,088 |
   | and Related      |            |           |           |           |
   | Costs            |            |           |           |           |
   |                  |            |           |           |           |
   | IETF Staff       |     10,000 |           |           |    10,000 |
   | Travel           |            |           |           |           |
   |                  |            |           |           |           |
   | RFC Editor       |    574,570 |           |           |   574,570 |
   |                  |            |           |           |           |
   | IETF and IAB     |     89,000 |           |           |    89,000 |
   | Support and      |            |           |           |           |
   | Insurance        |            |           |           |           |
   |                  |            |           |           |           |
   | IETF             |    709,000 |           |           |   709,000 |

Malamud                Expires February 23, 2005               [Page 60]

Internet-Draft      Administrative Support Analysis          August 2004

   | Restructuring    |            |           |           |           |
   | Project          |            |           |           |           |
   |                  |            |           |           |           |
   | Conference       |            |   100,000 |           |   100,000 |
   | Expense          |            |           |           |           |
   |                  |            |           |           |           |
   | Professional     |     12,500 |    20,000 |     4,000 |    36,500 |
   | Services,        |            |           |           |           |
   | Travel, Misc.    |            |           |           |           |
   |                  |            |           |           |           |
   | External Costs:  |     40,000 |    89,400 |    70,000 |   199,400 |
   | .org             |            |           |           |           |
   |                  |            |           |           |           |
   | External Costs:  |     70,000 |    42,181 |           |   112,181 |
   | SEINIT & Sida    |            |           |           |           |
   |                  |            |           |           |           |
   |                  |            |           |           |           |
   | TOTAL DIRECT     |  1,876,407 |   616,204 |   532,128 | 3,024,739 |
   | EXPENSE          |            |           |           |           |
   |                  |            |           |           |           |
   | G&A/GOVERNANCE   |    192,026 |   188,555 |   236,908 |   617,489 |
   |                  |            |           |           |           |
   | TOTAL EXPENSE    |  2,068,433 |   804,759 |   769,036 | 3,642,228 |
   |                  |            |           |           |           |
   |                  |            |           |           |           |
   | SURPLUS          |     36,567 |    32,241 |    33,464 |   102,272 |
   +------------------+------------+-----------+-----------+-----------+

Malamud                Expires February 23, 2005               [Page 61]

Internet-Draft      Administrative Support Analysis          August 2004

Appendix C.  10-Year Meeting Attendance Summary

   +------------+------------+-------------+-------------+-------------+
   | IETF       | DATE       | Location    | Host        |   Attendees |
   +------------+------------+-------------+-------------+-------------+
   | 60th IETF  | 01/08/2004 | San Diego,  | --          |        1511 |
   | [9]        |            | CA, USA     |             |             |
   |            |            |             |             |             |
   | 59th IETF  | 29/02/2004 | Seoul,      | --          |        1390 |
   | [10]       |            | South Korea |             |             |
   |            |            |             |             |             |
   | 58th IETF  | 09/11/2003 | Minneapolis | --          |        1233 |
   | [11]       |            | , MN, USA   |             |             |
   |            |            |             |             |             |
   | 57th IETF  | 13/07/2003 | Vienna,     | --          |        1304 |
   | [12]       |            | Austria     |             |             |
   |            |            |             |             |             |
   | 56th IETF  | 16/03/2003 | San         | --          |        1679 |
   | [13]       |            | Francisco,  |             |             |
   |            |            | California, |             |             |
   |            |            | USA         |             |             |
   |            |            |             |             |             |
   | 55th IETF  | 17/11/2002 | Atlanta,    | Nokia       |        1570 |
   |            |            | Georgia,    |             |             |
   |            |            | USA         |             |             |
   |            |            |             |             |             |
   | 54th IETF  | 14/07/2002 | Yokohama,   | Fujitsu;    |        1885 |
   |            |            | Japan       | The WIDE    |             |
   |            |            |             | Project     |             |
   |            |            |             |             |             |
   | 53rd IETF  | 17/03/2002 | Minneapolis | Cable &     |        1656 |
   |            |            | ,           | Wireless    |             |
   |            |            | Minnesota,  |             |             |
   |            |            | USA         |             |             |
   |            |            |             |             |             |
   | 52nd IETF  | 09/12/2001 | Salt Lake   | Novell      |        1691 |
   |            |            | City, Utah, |             |             |
   |            |            | USA         |             |             |
   |            |            |             |             |             |
   | 51st IETF  | 05/08/2001 | London,     | BTexact     |        2226 |
   |            |            | England     | Technologie |             |
   |            |            |             | s           |             |
   |            |            |             |             |             |
   | 50th IETF  | 18/03/2001 | Minneapolis | Lucent      |        1822 |
   |            |            | , MN, USA   | Technologie |             |
   |            |            |             | s           |             |
   |            |            |             |             |             |
   | 49th IETF  | 10/12/2000 | San Diego,  | Cisco       |        2810 |

Malamud                Expires February 23, 2005               [Page 62]

Internet-Draft      Administrative Support Analysis          August 2004

   |            |            | CA, USA     | Systems;    |             |
   |            |            |             | Qualcomm    |             |
   |            |            |             |             |             |
   | 48th IETF  | 31/07/2000 | Pittsburgh, | Marconi     |        2344 |
   |            |            | PA, USA     |             |             |
   |            |            |             |             |             |
   | 47th IETF  | 26/03/2000 | Adelaide,   | connect.com |        1431 |
   |            |            | Australia   | .au         |             |
   |            |            |             |             |             |
   | 46th IETF  | 07/11/1999 | Washington, | Nortel      |        2379 |
   |            |            | DC, USA     | Networks,   |             |
   |            |            |             | Inc         |             |
   |            |            |             |             |             |
   | 45th IETF  | 11/07/1999 | Oslo,       | Uninett     |        1710 |
   |            |            | Norway      |             |             |
   |            |            |             |             |             |
   | 44th IETF  | 14/03/1999 | Minneapolis | Ascend      |        1705 |
   |            |            | , MN, USA   | Communicati |             |
   |            |            |             | ons         |             |
   |            |            |             |             |             |
   | 43rd IETF  | 07/12/1998 | Orlando,    | Microsoft   |        2124 |
   |            |            | FL, USA     | Corporation |             |
   |            |            |             |             |             |
   | 42nd IETF  | 24/08/1998 | Chicago,    | Motorola    |        2106 |
   |            |            | IL, USA     |             |             |
   |            |            |             |             |             |
   | 41st IETF  | 30/03/1998 | Los         | --          |        1775 |
   |            |            | Angeles,    |             |             |
   |            |            | CA, USA     |             |             |
   |            |            |             |             |             |
   | 40th IETF  | 08/12/1997 | Washington, | Newbridge   |        1897 |
   |            |            | DC, USA     | Networks,   |             |
   |            |            |             | Inc         |             |
   |            |            |             |             |             |
   | 39th IETF  | 11/08/1997 | Munich,     | ISOC-German |        1308 |
   |            |            | Germany     | y Chapter   |             |
   |            |            |             |             |             |
   | 38th IETF  | 07/04/1997 | Memphis,    | Federal     |        1321 |
   |            |            | Tennessee,  | Express     |             |
   |            |            | USA         |             |             |
   |            |            |             |             |             |
   | 37th IETF  | 09/12/1996 | San Jose,   | Cisco       |        1993 |
   |            |            | California, | Systems     |             |
   |            |            | USA         |             |             |
   |            |            |             |             |             |
   | 36th IETF  | 24/06/1996 | Montreal,   | --          |        1283 |
   |            |            | Quebec,     |             |             |
   |            |            | CANADA      |             |             |

Malamud                Expires February 23, 2005               [Page 63]

Internet-Draft      Administrative Support Analysis          August 2004

   |            |            |             |             |             |
   | 35th IETF  | 04/03/1996 | Los         | --          |        1038 |
   |            |            | Angeles,    |             |             |
   |            |            | California, |             |             |
   |            |            | USA         |             |             |
   |            |            |             |             |             |
   | 34th IETF  | 04/12/1995 | Dallas,     | MCI         |        1007 |
   |            |            | Texas, USA  |             |             |
   |            |            |             |             |             |
   | 33rd IETF  | 17/07/1995 | Stockholm,  | the Royal   |         617 |
   |            |            | Sweden      | Institute   |             |
   |            |            |             | of          |             |
   |            |            |             | Technology; |             |
   |            |            |             | NORDUnet    |             |
   |            |            |             |             |             |
   | 32nd IETF  | 03/04/1995 | Danvers,    | FTP         |         983 |
   |            |            | Massachuset | Software;   |             |
   |            |            | ts, USA     | NEARnet     |             |
   |            |            |             |             |             |
   | 31st IETF  | 05/12/1994 | San Jose,   | Sun         |        1079 |
   |            |            | California, | Microsystem |             |
   |            |            | USA         | s           |             |
   |            |            |             |             |             |
   | 30th IETF  | 25/07/1994 | Toronto,    | University  |         710 |
   |            |            | Ontario,    | of Toronto  |             |
   |            |            | CANADA      |             |             |
   |            |            |             |             |             |
   | 29th IETF  | 28/03/1994 | Seattle,    | NorthWestNe |         785 |
   |            |            | Washington, | t           |             |
   |            |            | USA         |             |             |
   +------------+------------+-------------+-------------+-------------+

C.1  Analysis of Meeting-Based Expense and Revenue Drivers

   +----------------+----------------+----------------+----------------+
   | Category       |           2001 |           2002 |           2003 |
   +----------------+----------------+----------------+----------------+
   | Total          |          5,739 |          5,111 |          4,216 |
   | Attendees      |                |                |                |
   |                |                |                |                |
   | Net Meeting    |           $456 |           $446 |           $489 |
   | Revenue Per    |                |                |                |
   | Attendee       |                |                |                |
   |                |                |                |                |
   | Average Food & |           $150 |           $138 |           $122 |
   | Beverage Per   |                |                |                |
   | Attendee       |                |                |                |

Malamud                Expires February 23, 2005               [Page 64]

Internet-Draft      Administrative Support Analysis          August 2004

   |                |                |                |                |
   | Average Total  |           $206 |           $190 |           $193 |
   | Direct Meeting |                |                |                |
   | Cost Per       |                |                |                |
   | Attendee [1]   |                |                |                |
   |                |                |                |                |
   | Total          |           $370 |           $479 |           $507 |
   | CNRI/Foretec   |                |                |                |
   | Secretariat    |                |                |                |
   | Expenses       |                |                |                |
   | Divided by     |                |                |                |
   | Number of      |                |                |                |
   | Meeting        |                |                |                |
   | Attendees      |                |                |                |
   +----------------+----------------+----------------+----------------+

   Notes:
   [1] Room rental fees are typical for non-U.S.  meetings.  Average
      total direct costs will thus be influenced by the choice of
      location of meetings.

Malamud                Expires February 23, 2005               [Page 65]

Internet-Draft      Administrative Support Analysis          August 2004

Appendix D.  Sample Draft Incorporating Documents for a Hypothetical
            IETF Foundation

D.1  Sample Draft Articles of Incorporation

   This appendix contains standard, pro-forma Articles of Incorporation.
   Note well that tax lawyers often make significant alterations to
   standard Articles as they consider a 501(c)(3) application.  They are
   included here merely as a sample for illustrative purposes only.

   'Commonwealth of Virginia -- State Corporation Commission'| 'Articles
   of Incorporation -- Virginia Nonstock Corporation'| Form SCC819, 07/
   03 [14]
   ------

   The undersigned, pursuant to Chapter 10 of Title 13.1 of the Code of
   Virginia, [Virginia] state(s) as follows:
   1.  The name of the corporation is The IETF Foundation.
   2.  The corporation shall have no members.
   3.  The Trustees of the corporation shall be elected or appointed as
       specified in Article IV (Appendix D.2.5) of the Bylaws.
   4.  Name and agent:
       A.  The name of the corporation's initial registered agent is:
           XXX
       B.  The initial registered agent is a domestic or foreign stock
           or nonstock corporation, limited liability company, or
           registered limited liability partnership authorized to
           transact business in Virginia.
   5.  The initial Trustees are: XXX
   6.  The incorporators are: XXX

D.2  Sample Draft Bylaws of the IETF Foundation

   As with the Sample Draft Articles, the Sample Draft Bylaws included
   here are a pro-forma, standard version.  Substantial alteration may
   be required as legal counsel reviews the specific nature of an
   incorporation.

D.2.1  Article I: Organization

   The name of the Corporation shall be The IETF Foundation (which shall
   hereinafter be referred to as the "Foundation").

D.2.2  Article II: Purpose

   *Section 1: Purpose.* The IETF Foundation shall be operated
   exclusively for nonprofit educational, charitable, and scientific
   purposes, including, without limitation, the purposes stated in the

Malamud                Expires February 23, 2005               [Page 66]

Internet-Draft      Administrative Support Analysis          August 2004

   Foundation's Articles of Incorporation.

   *Section 2: Restrictions.* No part of the net earnings of the IETF
   Foundation shall inure to the benefit of, or be distributable to,
   private persons, except that the Foundation shall be authorized and
   empowered to pay reasonable compensation for services rendered, and
   to make payments and distributions in furtherance of the purposes set
   forth in Article II, Section 1 hereof.  Any other provision of these
   Bylaws to the contrary notwithstanding, the IETF Foundation shall not
   carry on any activities not permitted to be carried on by a
   corporation exempt from Federal Income Tax under Section 501(a) and
   Section 501(c)(3) of the Code.  These Bylaws shall not be altered or
   amended in derogation of the provisions of this Section.

D.2.3  Article III: Members

   The Foundation shall have no members and no stockholders.

D.2.4  Article IV: Offices

   The office of the Foundation shall be as determined from time to time
   by the Board of Trustees within or outside of the State of Virginia.

D.2.5  Article V: Board of Trustees

   *Section 1: Authority and Responsibilities.* The power, authority,
   property, and affairs of the Foundation shall at all times be
   exclusively exercised, controlled, and conducted by or under the
   authority of the Board of Trustees subject to any limitations set
   forth in the Articles of Incorporation and in accordance with the
   Virginia Nonstock Corporation Act as it now exists or hereafter may
   be amended.

   *Section 2: Board of Trustees Composition.* The Board of Trustees
   shall consist of seven (7) Trustees.

   *Section 3: Types.* There shall be two types of Trustees based on the
   reason for their selection: Position-Based Trustees, who are trustees
   because they hold some other office (for example IETF Chair) and
   Selected Trustees, who are not Position-Based Trustees.

   *Section 3: Terms.* The term of office of Position-Based Trustees
   shall be co-terminious with the term of the office that qualifies the
   individual to be a board member.  The term of office of Selected
   Trustees shall be three (3) years or until their successors have been
   selected and assume office.  Selected Trustees may be selected to
   serve multiple terms.

Malamud                Expires February 23, 2005               [Page 67]

Internet-Draft      Administrative Support Analysis          August 2004

   *Section 4: Selection of the Board of Trustee*
   1.  *Selection of Position-Based Trustees.* The Chairs of the IETF
       and IAB shall be the two Position-Based Trustees.  These
       individuals are selected by IETF participants using the
       procedures set forth in [RFC3777] or its successor.
   2.  *Selection of Selected Trustees.* Three Selected Trustees shall
       be selected by the IETF nominations process (as defined in
       [RFC3777] or its successor) and confirmed by the IESG.  Two
       Selected Trustees shall be selected by the internet Society using
       means of their own choosing.
   3.  *Resignation.* A Selected Trustee may resign by delivering his
       resignation in writing to the Foundation at its principal office
       or to the Secretary of the Foundation.  Such resignation shall be
       effective upon its receipt or upon such date (if any) as is
       stated in such resignation, unless otherwise determined by the
       Board.
   4.  *Removal.* A Selected Trustee selected by the IETF nominations
       process may be removed from office at any time using the
       procedures specified in [RFC3777] or its successor.  A Selected
       Trustee selected by the Internet Society my be removed by the
       Internet Society using means of their own choosing.
   5.  *Vacancies.* Any vacancy in the Board of Trustees shall be filled
       using the procedures set forth above on the composition of the
       Board of Trustees.  The Trustees shall have and may exercise all
       of their powers notwithstanding the existence of one or more
       vacancies in their number.

   *Section 5: Quorum.* A majority of the Trustees shall constitute a
   quorum for the transaction of business.  Unless otherwise stated in
   these Bylaws, decisions of the Board of Trustees shall be made by the
   concurrence of a majority of members of the Board of Trustees present
   and voting.  If at any meeting there is no quorum present, the Board
   must not transact business.

   *Section 6: Compensation and Reimbursement.* No member of the Board
   of Trustees may receive compensation for his or her services as a
   Trustee.  A Trustee shall, at their request, be reimbursed for
   actual, necessary and reasonable travel and subsistence expenses
   incurred by them in performance of their duties.

   *Section 7: Meetings.* The Board of Trustees shall meet at least
   twice annually.
   1.  *Annual Meeting.* The Board of Trustees shall hold a public
       Annual Meeting at a time and place associated with the first IETF
       meeting each year.  This Annual meeting shall be open to all IETF
       attendees except that the parts of the meeting dealing with
       personnel issues may be held in executive session.

Malamud                Expires February 23, 2005               [Page 68]

Internet-Draft      Administrative Support Analysis          August 2004

   2.  *Meeting Types, Methods, and Notice.* Meetings of the Board may
       be held from time to time at such intervals and at such places as
       may be fixed by the Board.  Meetings of the Board may be held
       only in person or via teleconference.  Notice of all regular
       meetings of the Board shall be delivered to each Trustee by
       e-mail or by postal mail and announced on the IETF-Announce list
       at least ten (10) calendar days before the meeting.  Special
       meetings of the Board may be called for any purpose at any time
       by the Chairman of the Board or by any three (3) Trustees.
       Notice of any special meeting shall state the purpose of the
       meeting.  A Trustee may waive notice of a meeting of the Board of
       Trustees by submitting a signed, written waiver of notice, either
       before or after the meeting.  A Trustee's attendance at or
       participation in a meeting waives any required notice of the
       meeting unless at the start of such meeting or promptly upon
       arrival the Trustee objects to holding the meeting or transacting
       business at the meeting, and does not thereafter vote for or
       assent to action taken at the meeting.
   3.  *Actions Taken By the Board of Trustees Without Meeting.* Any
       action required or permitted to be taken at any meeting of the
       Board of Trustees may be taken without a meeting if all Trustees
       consent in writing to such action.  Such action shall be
       evidenced by written consents approving the lack of a meeting,
       signed by each Trustee.

   *Section 8: Board Committees.* The Trustees may elect or appoint one
   or more committees (including but not limited to an Executive
   Committee) and may delegate to any such committee or committees any
   or all of their powers, provided that any committee to which the
   powers of the Trustees are delegated shall consist solely of
   Trustees.  Committees shall conduct their affairs in the same manner
   as is provided in these By Laws for the Trustees.  The members of any
   committee shall remain in office at the pleasure of the Board of
   Trustees.

   *Section 9: Trustee Member Conflict of Interest.*
   1.  As set forth in Section 9(3) below, a Trustee of the IETF
       Foundation who has a personal interest in a transaction, as
       defined below, may not participate in any discussion of that
       transaction by the Trustees of The IETF Foundation and may not
       vote to determine whether to authorize, approve, or ratify that
       transaction except as specifically described below.  For purposes
       of these Bylaws, a "personal interest" is defined as any act that
       will provide, directly or indirectly, a financial benefit or a
       disparate benefit individually to the Trustee, or to a company he
       or she is employed by, has a significant financial interest in,
       or represents in any fashion.  However, policies under
       consideration by the Foundation are likely to have an impact on

Malamud                Expires February 23, 2005               [Page 69]

Internet-Draft      Administrative Support Analysis          August 2004

       the business of every Trustee.  It is expected that most policy
       decisions will have a direct or indirect impact on the Trustee's
       company, but such a non-individualized interest does not
       constitute a "personal interest" as used in these Bylaws.  A
       "transaction" with The IETF Foundation for purposes of these
       Bylaws is a contract or consultancy in which the Trustee has a
       direct or indirect financial benefit, or a policy under
       consideration that will have a disparate and unusual impact on a
       business with which the Trustee is directly or indirectly
       associated.
   2.  The mere existence of a personal interest by a Trustee of The
       IETF Foundation in a transaction with The IETF Foundation shall
       not invalidate The IETF Foundation's ability to enter that
       transaction so long as the following conditions are met: (i) the
       material facts of the personal nature of the transaction with The
       IETF Foundation and the Trustee's interest in the transaction
       with The IETF Foundation are fully disclosed to the Board of
       Trustees of The IETF Foundation, either by the Trustee having a
       direct or indirect personal interest in the transaction with The
       IETF Foundation, or are brought to the attention of the Board by
       a third party; or (ii) the Board of Trustees of The IETF
       Foundation, by a vote of the disinterested Trustees of The IETF
       Foundation vote to authorize, approve, or ratify a transaction
       with The IETF Foundation; or (iii) the transaction with The IETF
       Foundation in which the direct or indirect personal interest of
       an The IETF Foundation Trustee was disclosed to the Board of
       Trustees of The IETF Foundation and was determined by the Board
       of Trustees of The IETF Foundation entitled to vote on the matter
       is determined by the Board of Trustees voting to be in The IETF
       Foundation's interests, notwithstanding the personal interest of
       the non-voting Trustee.
   3.  In determining whether a conflict of interest exists, the Board
       of Trustees of The IETF Foundation has the prerogative, upon
       review of all facts and circumstances, to make its own
       determination of whether a conflict of interest exists and how it
       is appropriate to proceed.  A Trustee who perceives the
       possibility of a conflict of interest for him or herself, or for
       another Board member, may raise this issue at any point prior to
       a vote on any issue.  Any Trustee who perceives a possible
       conflict of interest may present justification with respect to
       whether or not a conflict of interest exists, but the entire
       Board, with the exception of the Trustee having the potential
       conflict of interest, shall make the final determination to
       proceed in such a matter.  If the Board of Trustees finds there
       is a conflict of interest, the Trustee with the conflict may be
       excluded by the Chair of the Board from that portion of any
       meeting where a substantive discussion or decision to engage or
       not in such a transaction is made, except that he or she may

Malamud                Expires February 23, 2005               [Page 70]

Internet-Draft      Administrative Support Analysis          August 2004

       provide any information that will assist the Trustees in such a
       matter before leaving such a meeting.

   *Section 10.  Approval of Meeting Minutes.* Minutes of the Board of
   the IETF Foundation must be approved by a procedure adopted by the
   board and published on the IETF Foundation web site.

D.2.6  Article VI: Officers

   *Section 1: Number.* The officers of the IETF Foundation shall
   consist of a Chairman of the Board, a Treasurer and a Secretary, and
   such other inferior officers as the Board of Trustees may determine.

   *Section 2: Election Term of Office and Qualifications.* All officers
   shall be elected annually by the vote of a majority of the Board of
   Trustees present and voting (excluding abstentions) at the Annual
   Meeting.  The Treasurer and Secretary need not be members of the
   Board.  The Chair of the IETF nor the chair of the IAB shall be the
   Chairman of the Board of the IETF Foundation.

   *Section 3: Resignation.* An officer may resign by delivering his
   written resignation to the Foundation at its principal office or to
   the Chair or Secretary.  Such resignation shall be effective upon
   receipt or upon such date (if any) as is stated in such resignation,
   unless otherwise determined by the Board.

   *Section 4: Removal.* The Board of Trustees may remove any officer
   with or without cause by a vote of a majority of the entire number of
   Trustees then in office, at a meeting of the Board of Trustees called
   for that purpose.  An officer may be removed for cause only if notice
   of such action shall have been given to all of the Trustees prior to
   the meeting at which such action is to be taken and if the officer so
   to be removed shall have been given reasonable notice and opportunity
   to be heard by the Board of Trustees.

   *Section 5: Vacancies.* In case any elected officer position of the
   IETF Foundation becomes vacant, the majority of the Trustees in
   office, although less than a quorum, may elect an officer to fill
   such vacancy at the next meeting of the Board of Trustees, and the
   officer so elected shall hold office and serve until the next Annual
   Meeting.

   *Section 6: Chairman of the Board.* The Chairman of the Board shall,
   when present, preside at all meetings of the Board of Trustees of
   IETF Foundation.  If the Chairman is not available to preside over a
   meeting, the majority of the Trustees present shall select another
   Trustee to preside at that meeting only.

Malamud                Expires February 23, 2005               [Page 71]

Internet-Draft      Administrative Support Analysis          August 2004

   *Section 7: Treasurer.* The Treasurer shall have the custody of all
   funds, property, and securities of the IETF Foundation, subject to
   such regulations as may be imposed by the Board of Trustees.  He or
   she may be required to give bond for the faithful performance of his
   or her duties, in such sum and with such sureties as the Board of
   Trustees may require or as required by law, whichever is greater.
   When necessary or proper, he or she may endorse on behalf of the IETF
   Foundation for collection, checks, notes and other obligations, and
   shall deposit same to the credit of the IETF Foundation at such bank
   or banks or depository as the Board of Trustees may designate.  He or
   she shall make or cause to be made such payments as may be necessary
   or proper to be made on behalf of the IETF Foundation.  He or she
   shall enter or cause to be entered regularly on the books of the IETF
   Foundation to be kept by him or her for that purpose, full and
   accurate account of all monies and obligations received and paid or
   incurred by him or her for or on account of the IETF Foundation, and
   shall exhibit such books at all reasonable times to any Trustee on
   application at the offices of the IETF Foundation incident to the
   Office of Treasurer, subject to the control of the Board of Trustees.
   Certain duties of the Treasurer as may be specified by the Board of
   Trustees may be delegated by the Treasurer.

   *Section 8: Secretary.* The Secretary shall have charge of such
   books, records, documents, and papers as the Board of Trustees may
   determine, and shall have custody of the corporate seal.  The
   Secretary shall keep, or cause to be kept the minutes of all meetings
   of the Board of Trustees.  The Secretary may sign, with the Chairman,
   in the name and on behalf of the IETF Foundation, any contracts or
   agreements, and he or she may affix the corporate seal of the IETF
   Foundation.  He or she, in general, performs all the duties incident
   to the Office of Secretary, subject to the supervision and control of
   the Board of Trustees, and shall do and perform such other duties as
   may be assigned to him or her by the Board of Trustees or the
   Chairman of the Board of Trustees.  Certain duties of the Secretary
   as may be specified by the Board of Trustees may be delegated by the
   Secretary.

   *Section 9: Other Powers and Duties.* Each officer shall have in
   addition to the duties and powers specifically set forth in these By
   Laws, such duties and powers as are customarily incident to his
   office, and such duties and powers as the Trustees may from time to
   time designate.

D.2.7  Article VII: Amendments

   *Section 1: By Laws.* These By Laws may be amended by an affirmative
   vote of a majority of the Trustees then in office (excluding
   abstentions) at a regular meeting of the board or a meeting of the

Malamud                Expires February 23, 2005               [Page 72]

Internet-Draft      Administrative Support Analysis          August 2004

   board called for that purpose as long as the proposed changes are
   made available to all trustees and posted to the IETF Announce list
   at least 30 days before any such meeting.

   *Section 2: Articles of Incorporation.* The Articles of Incorporation
   of the IETF Foundation may amended by an affirmative vote of
   two-thirds vote of the Board of Trustees then in office at a regular
   meeting of the board or a meeting of the board called for that
   purpose as long as the proposed changes are made available to all
   trustees and posted to the IETF Announce list at least 30 days before
   any such meeting.

D.2.8  Article VIII: Dissolution

   Upon the dissolution of the IETF Foundation, the IETF Foundation
   shall, after paying or making provisions for the payment of all of
   the liabilities of the Foundation, dispose of all of the assets of
   the IETF Foundation exclusively for the exempt purposes of the IETF
   Foundation in such manner or to such organization or organizations
   operated exclusively for social welfare or charitable purposes.  Any
   such assets not so disposed of shall be disposed of by a court of
   competent jurisdiction of the county in which the principal office of
   the organization is then located, exclusively for such purposes.  In
   the event of a sale or dissolution of the corporation, the surplus
   funds of the corporation shall not inure to the benefit of, or be
   distributable to, its Trustees, officers, or other private persons.

D.2.9  Article IX: Miscellaneous Provisions

   *Section 1: Fiscal Year.* The fiscal year of the IETF Foundation
   shall be from January 1 to December 31 of each year.

   *Section 2: Execution of Instruments.* All checks, deeds, leases,
   transfers, contracts, bonds, notes and other obligations authorized
   to be executed by an officer of the Foundation in its behalf shall be
   signed by the Chairman of the Board or the Treasurer, or as the
   Trustees otherwise determine.  A certificate by the Secretary as to
   any action taken by the Board of Trustees shall as to all persons who
   rely thereon in good faith be conclusive evidence of such action.

   *Section 3: Severability.* Any determination that any provision of
   these By-Laws is for any reason inapplicable, illegal or ineffective
   shall not affect or invalidate any other provision of these By-Laws.

   *Section 4: Articles of Incorporation.* All references in these By
   Laws to the Articles of Incorporation shall be deemed to refer to the
   Articles of Incorporation of the IETF Foundation, as amended and in
   effect from time to time.

Malamud                Expires February 23, 2005               [Page 73]

Internet-Draft      Administrative Support Analysis          August 2004

   *Section 5: Gender.* Whenever used herein, the singular number shall
   include the plural, the plural shall include the singular, and the
   use of any gender shall include all genders.

   *Section 6: Successor Provisions.* All references herein: (1) to the
   Internal Revenue Code shall be deemed to refer to the Internal
   Revenue Code of 1986, as now in force or hereafter amended; (2) to
   the Code of the State of Virginia, or any Chapter thereof, shall be
   deemed to refer to such Code or Chapter as now in force or hereafter
   amended; (3) the particular sections of the Internal Revenue Code or
   such Code shall be deemed to refer to similar or successor provisions
   hereafter adopted; and (4) to the Request for Comment Series shall be
   deemed to refer to the Request for Comment Series as they are now in
   force or hereafter amended.

Malamud                Expires February 23, 2005               [Page 74]

Internet-Draft      Administrative Support Analysis          August 2004

Appendix E.  Sample Draft Call for Applications -- IETF Administrative
            Director

   The IETF is seeking a highly capable individual to serve as
   Administrative Director.  You will report to the IETF Chair and be
   accountable to IETF Community.  This is a highly visible and very
   demanding job.  You will be expected to:
   o  Serve as the day-to-day chief operating officer of the IETF,
      managing a number of contractors and working with a number of
      volunteers.
   o  Provide primary support for budgeting and financial reporting
      processes.
   o  Serve as the primary staff resource for the governing body of the
      administrative entity for the IETF.
   o  Work with your contractors and members of the IETF community to
      provide adequate support and planning for 3 IETF meetings
      annually, and for frequent meetings and teleconferences of the
      IAB, IESG, and other bodies that support the IETF.
   o  Work with our liaison organizations, such as the RFC Editor and
      the IANA.
   o  Coordinate the standards-making support process, in particular the
      periodic meetings of the IESG.

   The following characteristics are necessary for this job:
   o  This job is public service.  You should be able to work
      successfully with large numbers of people.  This requires a high
      clock rate, a large stack, and the ability to listen carefully.
   o  This is an operations job.  IETF meetings are large and complex,
      and the day-to-day activities of the standards-making process is
      demanding.  You should be adept at getting real results and
      helping large groups work together towards common goals and
      deadlines.
   o  This job requires a financially astute individual.  The IETF is a
      $2-$3 million/year operation.  IETF funds are tight and we expect
      you to take leadership in establishing our budgetary procedures,
      our procurement standards, and understanding our revenue sources.

   In-depth familiarity with the IETF prior to assuming this position is
   not required, but you must be able to quickly get up to speed and
   learn the unique culture and requirements of the organization.
   Likewise, long-term technical experience is not required, but you
   must be a quick learner and adept at using the Internet effectively.

   You may work out of a home office as a telecommuter, or use the
   Internet Society facilities in Virginia.  In either case, you should
   be prepared to travel to Virginia, IETF meetings, and the locations
   where the IETF has contractors.

Malamud                Expires February 23, 2005               [Page 75]

Internet-Draft      Administrative Support Analysis          August 2004

   Applicants should forward a resume, references, and any other
   relevant materials, with a cover letter explaining why they feel they
   are the right person for this position to:
      URL

   Applications are due no later than XXX, however the IETF
   Administrative Entity reserves the right to make a decision prior to
   this date or to extend this date in its sole discretion.
   Applications will be reviewed by an evaluation committee consisting
   of members of the IAB, IESG, and the community, and a decision shall
   be made by the Chairs of the IETF and the IAB with the advice and
   consent of the IESG and the IAB.

   The list of applicants will not be posted publicly, but will be
   reviewed in confidence by members of the evaluation committee, the
   IAB, and the IESG.

Malamud                Expires February 23, 2005               [Page 76]

Internet-Draft      Administrative Support Analysis          August 2004

Appendix F.  Sample Draft Request for Proposals

F.1  Introduction

   The IETF Administrative Entity is soliciting proposals for the
   provision of five requirements, as detailed in this Request for
   Proposals ("Proposals").  Proposals from any individual person or
   persons or commercial or non-commercial vendor ("Vendor") are
   welcome.

   Proposals must be received in written electronic form no later than
   [date].  Extensions may be granted solely in the discretion of the
   IETF Administrative Entity.  Each Proposal, together with all
   supporting documentation, should be delivered to the following
   address:

   [URI/ADDRESS]

   Any inquiries regarding this Request must be submitted in written
   electronic form to the address listed above.  Other than such
   inquiries, vendors are prohibited from contacting any person or
   institution involved in the selection process concerning this
   Request.

   Each Proposal must specifically address each of the selection
   criteria listed below in a format corresponding to this Request.
   Each Proposal should also be accompanied by any technical or product
   literature that the Vendor wishes the IETF Administrative Entity to
   consider.  If additional information is required by the IETF
   Administrative Entity to make a determination, such information may
   be requested, and shall be submitted in writing in the manner set
   forth above.  Information other than the written Proposal and any
   information submitted in response to a request by the IETF
   Administrative Entity will not be considered by the IETF
   Administrative Entity.

   The IETF Administrative Entity reserves the right to cancel this
   Request, in whole or in part, at any time.  The IETF Administrative
   Entity may reject any or all Proposals received in response to this
   Request in its sole discretion.  The IETF Administrative Entity makes
   no guarantee or commitment to purchase, license or procure any goods
   or services resulting from this Request.

   Any Proposal which is selected by the IETF Administrative Entity
   shall be subject to execution of a binding agreement between the IETF
   Administrative Entity and the Vendor, which agreement shall be
   prepared by the IETF Administrative Entity and shall reflect the
   requirements outlined below and any additional provisions that are

Malamud                Expires February 23, 2005               [Page 77]

Internet-Draft      Administrative Support Analysis          August 2004

   agreed upon in discussions between the IETF Administrative Entity and
   the Vendor.  Selection may be conditioned upon acceptance of specific
   contractual terms and conditions, which may be provided to the Vendor
   during the selection process.

   Each Vendor is responsible for its own costs and expenses involved in
   preparing and submitting its Proposal and any supplemental
   information requested by the IETF Administrative Entity.  The IETF
   Administrative Entity shall not reimburse any such costs or expenses.

   All Proposals submitted in accordance with this Request will be
   reviewed by a panel of experts drawn from the IETF community.  A list
   of reviewers will be made available.  The IETF Administrative Entity
   will notify Vendors of their selection following receipt and
   consideration of all Proposals.  The IETF Administrative Entity will
   attempt to make its selection(s) by [date], but shall have full
   discretion to make a decision earlier or later than this date.

F.2  General Provisions

   The following provisions apply to all bidders:
   1.  A response may be submitted for one or more of the 5 listed
       support requirements.  If response addresses more than one of the
       listed support requirements, the proposal should be written to
       clearly separate costs by area.  The IETF Administrative Entity
       reserves the right to accept only a partial proposal.
   2.  Key Person Principle: Each requirement requires the designation
       of one individual as the "Key Person" in your response.  That
       person will be the individual accountable to the IETF.  The IETF
       Administrative Entity will require a binding key personnel clause
       in the contract.  Any change in the Key Person will require prior
       approval.  The IETF Administrative Entity will also require a
       written process that describes procedures for backing up the key
       person when that person is not available.  The IETF
       Administrative Entity will also require that the bidder obtain
       and maintain key person insurance for dealing with the
       possibility that the designated key person becomes unavailable.
   3.  The IETF Administrative Entity encourages zero-cost or zero-cost
       plus materials bids, but will insist on a binding agreement.
   4.  The IETF Administrative Entity encourages bids from individuals
       as well as public and private institutions as long as the above
       conditions are met.  You should submit a detailed work history of
       each individual, personal references, and a detailed description
       of any sub-contractual arrangements you have put in place to
       assist you.
   5.  Appropriate insurance and other mechanisms to minimize the
       liability of the IETF Administrative Entity should be discussed
       in your proposal.

Malamud                Expires February 23, 2005               [Page 78]

Internet-Draft      Administrative Support Analysis          August 2004

F.3  Requirement 1: Meetings

   We are looking for creative proposals from experienced professionals
   to organize and support the meetings of the IETF.

   You will work with the Administrative Director of the IETF and the
   IETF leadership to organize the three annual meetings of the IETF.
   Based on current practice, you should expect 1-2 of those meetings to
   be in the United States and 1-2 of those meetings to be in other
   countries, though this may change based on the requirements of the
   IETF.  We expect approximately 1500 attendees per meeting, though in
   the past this number has approached 3,000 based on the location of
   the meeting and the state of the economy.

   You should have very strong experience in meeting planning,
   particularly working meetings with large numbers of participants.
   You should be intimately familiar with the details of booking
   appropriate venues, working with hotel and conference center staff,
   and providing clear and concise communications with meeting
   attendees.

   Your proposal should detail the mechanisms you would use to provide a
   simple registration and payment procedure for attendees.  You will be
   able to draw on webmaster and sysadmin support for the IETF, for
   example, if you would like to provide a secure payment mechanism on
   the IETF web site.  Your proposal should also detail how you will
   provide additional resources on-site (e.g., staffing a registration
   desk and other requirements that require additional people).

   As part of this function, you will work with Local Hosts (when
   available), who provide a sophisticated network infrastructure to
   support the meeting, as well as a team of volunteers who provide
   additional terminal room support, real-time audio and video streaming
   from the meeting and other functions.

F.4  Requirement 2: Systems and Systems Administration

   This requirement consists of two functions.  You may bid on one or
   both of these functions, which include:
   1.  Provision of a core network infrastructure.
   2.  Systems Administration.

F.4.1  Core Network Infrastructure

   [Ed.  This section will contain service level specifications.  E.g.,
   core bandwidth requirements, CPU capacity, disk space, and other
   variables.  It will also contain core specifications, such as
   routing, DNS, and other services.]

Malamud                Expires February 23, 2005               [Page 79]

Internet-Draft      Administrative Support Analysis          August 2004

F.4.2  Systems Administration Services

   [Ed.  This section will contain the description for the Systems
   Administration function, including such tasks as keeping key software
   subsystems such as Apache installed and up-to-date and support for
   users.]

F.5  Requirement 3: Postmaster of the IETF Administrative Entity

   The Postmaster of the IETF Administrative Entity is responsible for
   the functioning and archiving of numerous mailing lists maintained by
   the IETF and for archiving specific IETF-related mailing lists
   maintained by others.  Note that the archives of most IETF mailing
   lists are public and the bidder must describe how such archives will
   be accessed by the public.

   The core mailing is described in [RFC3005], and a policy with regards
   to posting rights may be found in [RFC3683].  You will find
   additional information on IETF mailing lists at:
      <http://www.ietf.org/maillist.html>

   In addition, the IETF maintains several dozen members-only lists in
   support of bodies such as the IAB, the IESG, and certain IRTF task
   forces (see [RFC2014], [RFC2850], and [RFC3710] for more details on
   these bodies).  IETF administrators and chairs of various groups
   typically will form ad hoc lists which they administer for various
   tasks.

   Familiarity and expertise in administering high-volume lists and in
   maintaining large numbers of archived lists is necessary.  The
   ability to provide administrative facilities that allow the IETF to
   delegate authority for moderation and creation of lists is also
   necessary.  Finally, you should be experienced in the very latest
   spam fighting technologies.

   You may propose to provide service in one of two ways:
   o  Move the IETF mail handling onto an existing well-provisioned
      infrastructure that you are responsible for.
   o  Provide mail services on machines that are maintained by the IETF.

   Your bid should clearly explain what tools you will use, the types of
   interfaces you will provide to list maintainers and participants, and
   you would handle issues such as spam.  You should also be very clear
   in your proposal about your understanding of the role and duties of
   the postmaster.

Malamud                Expires February 23, 2005               [Page 80]

Internet-Draft      Administrative Support Analysis          August 2004

F.6  Requirement 4: Clerk of the IETF Administrative Entity

   This requirement is for general high-level administrative support for
   the day-to-day functioning of the IETF.  A specialized subfunction in
   the Clerk's office is the processing of the Internet-Draft submission
   queue.  Such documents must conform to requirements for
   Internet-Drafts as defined by the IETF.

   In addition to processing the Internet-Draft queue, you will work
   with the Administrative Director of the IETF to help make the
   organization function smoothly on a day-to-day basis.

   [Ed.  More detail to be filled in here by a transition team.]

F.7  Requirement 5: Webmaster of the IETF Administrative Entity

   This task has the responsibility for the look and feel of the IETF
   network presence, particularly the web site.  A series of support
   contracts will be available to help support this function.

   In addition, this task has responsibility to provide overall support,
   in cooperation with the sysadmin and other contractors, to a variety
   of working groups, directorates, and other activities that require a
   workspace.

   Your proposal must demonstrate that you are experienced at producing
   highly standards-conformant and functional network presences and
   supporting a large and diverse community of users.  This is a highly
   hands-on task.

F.8  Selection Criteria and Evaluation Process

   All proposals will be evaluated using a process that consists of the
   following steps:
   1.  An evaluation committee will be formed by the IETF and IAB
       Chairs, and will include the Administrative Director of the IETF
       Administrative Entity.
   2.  The evaluation committee will perform an initial evaluation of
       submitted responses.
   3.  A dialogue will be started with selected responses.
   4.  The IETF will decide on the initial best candidate.
   5.  The A further dialogue will ensue with that candidate.
   6.  A contract may be signed or the discussion may continue with
       other candidates.

   The IETF Administrative Entity will consider price, experience,
   technical smarts, and a variety of other factors.  Note well that the
   IETF Administrative Entity will not decide on price alone.  Overall

Malamud                Expires February 23, 2005               [Page 81]

Internet-Draft      Administrative Support Analysis          August 2004

   benefit to the IETF community will be the prime consideration.

Malamud                Expires February 23, 2005               [Page 82]

Internet-Draft      Administrative Support Analysis          August 2004

Index

F
   functions  6, 6, 10, 11, 13, 16, 17

M
   mechanisms  33, 33, 33, 33, 33, 33, 33

O
   opinions  16, 23
   options  1, 7, 9, 22, 22, 24, 27, 37

P
   pillars  6, 6, 6

R
   recommendations  8, 20, 21, 21, 27, 28, 36

S
   strategies  22, 22, 22

Malamud                Expires February 23, 2005               [Page 83]

Internet-Draft      Administrative Support Analysis          August 2004

Intellectual Property Statement

   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
   [email-masked].

Disclaimer of Validity

   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 Statement

   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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Malamud                Expires February 23, 2005               [Page 84]


_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Sat, 28 Aug 2004 15:35:34 +1000

Hi,

In general I agree with the document and the analysis.

Follow my inputs regarding my personal experience or views.

Regarding 2.3 (meetings), I think one of the problems is that the information regarding the meetings is not clear in the IETF site, and moreover, the decision about where a meeting is being organized and why (or why not) is not an open process (even for candidate hosts !). I already mention a couple of times in this list that I've been offering myself to host a meeting in Madrid and another one in Barcelona, and after 3 (_THREE_) years the Madrid proposed venue was visited by the secretariat and initially qualified as excellent ("the best property even seen" according to the secretariat words after the visit, if I recall correctly), but afterwards, the decision was that was not convenient not being in downtown and not having "other" facilities nearby (what is not correct), but the most interesting thing is quite contradictory is this with the organization of the IETF60 in San Diego, where the problems where even bigger than compared to the Madrid proposal. This is probably c!
 onsequence of the not open and democratic decision process and lack of information on the venue selection.

Consequently is also not correct that there are no "single" host offering to organize everything ... on the other way around, for some reasons have not been sufficiently considered, or may be unfairly decided to host the meeting in US having a better chance in Europe and with less security troubles for non-US attendees, but that is probably part of another discussion. Not really sure if this aspect should be considered in the organization of the meetings and standardized somehow, that only those countries that don't restrict (or set high levels of difficulties) for the attendance of participants of all around the world, being accepted as candidates.

In fact, my proposal was organizing the event in Madrid the week after another big event (Madrid Global IPv6 Summit) that I organize there every year (since 3 already, next one in March 2005), in order to take advantage of the network deployment and some other facilities and also have a better chance for negotiating a lower price with the hotel, and even take advantage of sponsorships for both events, or even having some attendees/speakers the chance to lower their traveling expenses (in case they are participating in both events).

I agree that the organization of IETF meetings is being done with not enough long term planning, regarding the host/venue decision (my own event is usually organized almost 1 year ahead and agreed with the venue at that time), and that usually means higher cost and lower number of probably venues.

Just to clarify, my comments in this case aren't a critic, but hopefully serve as real example case inputs to the document ;-)

Regarding the possible repetition of visits to allied properties, I'm not convinced is always possible, because the IETF is usually a to big meeting to have hotel chains or alliances that could have the correct venues in all the locations where we can find host. If this is done in US, it may be possible, but if we compare the normal size and number of the meeting rooms available in US hotels versus Europe, I don't think is realistic, at least not to be considered as a generic rule. The alternative is then to decide if we only organize the meetings on those chains (and restrict the possible candidate locations), or if we try both ways ... depending on the location.

Regarding the advanced payment cash flow needs, this could be negotiated usually, and even provide bank warranties instead of the actual payment, in case this help. Those bank warrantees could come from the supporting organizations instead of the IETF itself, if required.

I think is also important to balance the cost of the meeting for the IETF and the attendees, as this could be a factor for the number of participants. One additional consideration could be to choose locations that could be tied to vacations of some of the participants. I think for example this could be an ingredient if arranging a meeting in Spain (and sure in other locations), because the cost for the participants is lower than in US, and they can enjoy nice vacations after (or before) the meeting, probably helping to increase the participation and consequently the financing of the IETF costs.

An interesting question here will be if we are really looking for big meetings in terms of number of participants, that non necessarily "contribute", but increase the financial support for the IETF costs in general, or in the other way around, the extra costs and difficulties of organizing such big meetings doesn't compensate for those extra revenues. I will ask myself if we need in that case a way setup a bar to allow the participation of only those that really contribute ... another difficult debate.

Regarding the recommendations (3.1), I wonder if in addition to the single staff member, is more convenient to have a minimum own-staff, who can take care of all the different required activities including the long-term meeting planning. Usually the cost of the outsourcing, not just in terms of money, but also of training different people instead of having long term "IETF experienced" personal, can make a big difference looking into the productivity and actual support provided to the community. I will seriously prefer to consider this option instead of the RFP, and issue only RFP for specific task if required, when the own personnel can't take care of some of the activities because is not financially convenient only.

Regarding the basic computing infrastructure (3.2.1.1), based on customers experience in similar situations, I will much prefer a single distributed but unified platform, as a way to ensure common tools like search, information flow, archive, etc. A larger concentration of roles could be very appropriate, if correctly managed.

For some of the RPF components, we could consider sponsors or volunteers, of course, contractually bound. For example, I offered several times to mirror the IETF sites in order to provide IPv6 access.

Regarding the options for an Institutional Basis for Administrative Activities (4), I think it will be quite appropriate, considering the relation with ISOC and avoiding unnecessary expenses, going for Scenario A, but probably as a quick approach while we work on the Scenario B. May be is required in the document to look with much more detail into a comparison about possible drawbacks/pros/cons for every model to take a more consequent decision ? Foe example, I understand that the advantages of Scenario C, in terms of taxes, VAT, etc., are also applicable under the ISOC umbrella ? Are we considering for the incorporation country only those mention in the document? (it may be the case that what is described for Scenario C is not necessarily completely applicable everywhere, but may be some other advantages are available in some countries, including incorporation expenses, legal cost for yearly requirements as registered auditors, etc.). Are we considering the impact, in the s!
 ense of the credit rating of a new entity, compared to an existing one ? Is more convenient to have a higher tax refunding than more freedom, if that's the case depending on the incorporation place ? Possibly all this questions need to be considered only if we go for Scenario C, but the decision to go to Scenario C could also depend on this answers ...

I don't think Scenario D is realistic, unless there is some "hidden" and insolvable issue with ISOC ?

Section 9. Ack. Mike St. Johns is duplicated.

Regards,
Jordi

----- Original Message ----- 
From: "Leslie Daigle" <[email-masked]>
To: <[email-masked]>
Cc: "Harald Tveit Alvestrand" <[email-masked]>
Sent: Thursday, August 26, 2004 7:53 AM
Subject: Options for IETF administrative restructuring

> We need to take the time to get this one right.

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 30 Aug 2004 09:29:27 +0200

Thanks for your comments, Jordi!

I'm replying to part of your note, and changing the subject line to get 
different topics on different threads..... I do think we need some kind of 
IETF consensus on the criteria for venue selection - and once we have that 
documented consensus, we need to evaluate how well we follow them...

This is not trivial, nor is it easy to get everything in line; for 
instance, one of our requirements is fairly large (and expensive) offsite 
Internet bandwidth; one potential US site was able to deliver that 
bandwidth as part of the conference package - BUT insisted that it be able 
to perform its usual packet filtering on the traffic, and refused to allow 
alternate bandwidth provisioning on site.

Not something we expected five years ago. Foretec declined the offer - 
wisely, in my opinion.

The subject of continent selection is, BTW, one of the real touchy ones; my 
statistics show that in the North American contingent, the attendance is 
cut in half when we meet outside North America; in the Asian contingent, 
the attendance from the host country quadruples or more when we meet in 
their country, while Europeans show more steady attendance statistics.

Fred Baker formulated a principle of IETF meeting placement as "if you 
contribute to the IETF, the IETF sometimes holds a meeting near you". 
Measuring contribution is a difficult thing - it's certainly not the same 
as attendance! - but I think the principle is not unreasonable.

And after having picked a continent, we need to pick a venue - which can 
depend on the wishes of the sponsor, cost of doing business, availability 
of reasonable venues (I have been told by Foretec that the sensible 
Vancouver venues are booked solid on the dates we want for the next 2 
years, for instance). And that sometimes interferes with the selection of 
continent - for a while, I was told that Foretec was looking at Europe in 
spring 2005; now I'm told it's looking at summer 2005 - because venues 
worked better for August.

I think the organizer needs to be able to make these tradeoffs in real 
time, and without going back to the IETF for a consensus process on 
individual meetings - but we do need to have our criteria right out in the 
open.

I would prefer to split the process into two rather independent parts: One 
(open) that sets the criteria, and one (subcontracted) that attempts to 
find sites that fulfil the criteria. Then we can evaluate the result - for 
economics, for venue performance, for sponsor satisfaction (that too 
matters!), and for "fairness".

As to how to achieve all that.... I'm not at all sure.

A long note about a subject that is a small part of the "reorg" issue...... 
hope this makes sense to you!

                       Harald

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 30 Aug 2004 10:58:14 +0200

On 30-aug-04, at 9:29, Harald Tveit Alvestrand wrote:

> The subject of continent selection is, BTW, one of the real touchy 
> ones; my statistics show that in the North American contingent, the 
> attendance is cut in half when we meet outside North America; in the 
> Asian contingent, the attendance from the host country quadruples or 
> more when we meet in their country, while Europeans show more steady 
> attendance statistics.

Are you sure about this? The number of attendees in Vienna was a bit 
higher than in Minneapolis last year. I also ran into a much larger 
contingent of fellow countrymen in Vienna. (Don't look too far in the 
past as you can't compare the 2000+ attendees of a few years ago with 
the 1500- ones now, I'd assume the people who still come are more 
loyal.)

Also, it's not just about the continent. I find the US somewhat 
visitor-unfriendly in places like Minneapolis, and very much so on the 
international airports of larger cities. I would very much like to see 
a meeting in North America but outside the US.

> individual meetings - but we do need to have our criteria right out in 
> the open.

> I would prefer to split the process into two rather independent parts: 
> One (open) that sets the criteria, and one (subcontracted) that 
> attempts to find sites that fulfil the criteria. Then we can evaluate 
> the result - for economics, for venue performance, for sponsor 
> satisfaction (that too matters!), and for "fairness".

> As to how to achieve all that.... I'm not at all sure.

Speaking as someone who has to pay for going to IETF meetings out of 
his own pocket and as someone who has been trying to muster up some 
enthusiasm to host a meeting, I'm not all that happy about the way 
things are going now. I'll concentrate on the second role for now.

First of all, I'm not surprised it has been getting harder to find 
sponsors. There are two main reasons for that: the duties of the 
sponsor are solely defined by what's convenient for the people who 
organize the meetings on behalf of the IETF (I'm assuming Foretec and 
the secretariat but I can't be sure). This means the prospective host 
is left with a plethora of duties, some of which are easily solved with 
money (which some sponsors have), others with manpower (which some 
sponsors have) and others with some very specific knowledge (which some 
sponsors have). However, few sponsors are going to have all three.

Also, the process is completely un-transparent both from the view of 
the attendee and from the view of the would-be host.

Last but not least, the people who handle this on the IETF side really 
don't seem to care. For instance, for the past year I've been trying to 
get an answer to the following questions:

> Can you provide me with the current numbers that are relevant to 
> hosting the terminal room (and the social event) for an IETF meeting? 
> And which are the upcoming meetings for which there is no location 
> determined yet?

(Ok, I've only sent four or so messages, but still.) All of this makes 
it hard to create enthusiasm within prospective host organizations.

I think it's essential to start publishing the following information on 
a regular basis:

- meeting status: decided, under consideration, open
- date specific constraints, such as the continent that has been 
selected
- up to date numbers for hotel rooms, meeting rooms, terminal room and 
so on

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Mon, 30 Aug 2004 22:30:09 +1200

Hi Harald,

See my comments below, in-line.

Regards,
Jordi

---- Original Message ----
From: "Harald Tveit Alvestrand" <[email-masked]>
To: "JORDI PALET MARTINEZ" <[email-masked]>; <[email-masked]>
Sent: Monday, August 30, 2004 7:29 PM
Subject: Venue selection (Re: Options for IETF administrative restructuring)

> alternate bandwidth provisioning on site.

Clearly we should not accept that site ;-)

> The subject of continent selection is, BTW, one of the real touchy ones;
> my statistics show that in the North American contingent, the attendance
> is cut in half when we meet outside North America; in the Asian
> contingent, the attendance from the host country quadruples or more when
> we meet in their country, while Europeans show more steady attendance
> statistics. 

I'm not sure that's correct, but probably you have the right figures ;-)

But the point probably is not if the figures show that you're right or not ... The point is to be fair with the participants, independently from where they come.

Why participants from continent X have less possibilities to attend IETF ? Why they should spend more money to attend the IETF meetings in comparison with participants from continent Y ?

Are we considering in the meeting cost, the extra (or lower) cost that organizing the meeting in place A or place B means for the attendees ?

And being clear, is time may be for the Asian to have more IETFs there, and what about Latin America, or even Europe ? We should now start balancing and having more IETFs there and less in NA !

Is the IETF a competition in the number of attendees from continent A or B or C ?

Just food for though ...

> as attendance! - but I think the principle is not unreasonable.

I also thought this could be reasonable, but after years attending, I don't think anymore this is correct, neither fair. Probably on the other way around. I feel that holding meetings where there is less contribution, can help to increase it.

In any case, the issue comes back to the original point: We need a clear definition about what are the requirements. San Diego didn't meet the "requirements" (those that we feel, because aren't clearly written anywhere), and it was not that bad, so probably those requirements are wrong.

We also need to ask what is the reason for attending, and if that reason is in the benefit of the IETF process, or on the other way around. How much cost have attendees not actually participating ? Or may be in the other way around, they finance the meeting for those that contribute ?

> worked better for August.

I know about this very well, I need to book one year in advance, at least, and is my own city ... But I can tell you also that this is part of the miss-planning. I offered during 3 years ... and the venue was visited only in Summer 2003. We had good chances at that time to block the venue for end of 2004 or spring/summer 2005, but the decision didn't come !

> individual meetings - but we do need to have our criteria right out in the

Exactly. Let's start working on it ? Do we need an I-D ?

We can start with the known issues and keep adding what we believe is not working, or wrong or whatever. We should have this clear by the next meeting. The plenary is a good place to present this and get the last feedback and go for the last call ;-)

> matters!), and for "fairness".

Agree, but if we don't have the criteria, then is difficult.

Anyway, the subcontracting cost money, and is subjected to persons, so this means that could always be (perceived) as a subjective applications of the criteria (once agreed), and that means that it need to be also open and subjected to feedback. This is actually probably the most difficult part, but should be part of the process.

> A long note about a subject that is a small part of the "reorg"
> issue...... hope this makes sense to you!

A lot of sense if we start with the I-D !

---

From: "Christian de Larrinaga" <[email-masked]>
Date: Mon, 30 Aug 2004 12:26:15 +0100

Firstly congratulations to all those involved in compiling this work.

I have three questions before being able to comment in more detail.

1/ Has a decision been made not to sub contract out (under formal
agreements) the tasks currently being managed fairly informally by
Foretec/CNRI to professional adminstration organisations?

2/ What funding requirement is expected from ISOC and ISOC members to manage
the IETF functions outlined?

3/ Do we have an analysis of the policy implications in bringing
responsibility for the administration of Internet Standards negotiation into
the same body that is responsible for their oversight (via appointment of
IAB and Trustee appeal role)?

Christian

Christian de Larrinaga

------------------------------------------------------------------
Deploying Internet services?
You need to participate in the UK IPv6 Deployment Conference
Manchester September 24th 2004
www.uk.ipv6tf.org
alongside RIPE  49, 21st to 24th Sept 2004
------------------------------------------------------------------

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Leslie Daigle
Sent: 26 August 2004 00:54
To: [email-masked]
Cc: Harald Tveit Alvestrand
Subject: Options for IETF administrative restructuring

Hello, IETF community.

FURTHER STEPS

                    Leslie and Harald.

--

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Aug 2004 13:32:00 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Iljitsch" == Iljitsch van Beijnum <[email-masked]> writes:
    Iljitsch> - meeting status: decided, under consideration, open -
    Iljitsch> date specific constraints, such as the continent that has
    Iljitsch> been selected - up to date numbers for hotel rooms,
    Iljitsch> meeting rooms, terminal room and so on

  I second this.
  I also welcome the information that Vancouver was booked. That's
important to understand.

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [