[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 RFC 4089

Network Working Group                                      S. Hollenbeck
Internet-Draft                                      Editor, IAB and IESG
Expires: April 18, 2005                                 October 18, 2004



   IAB and IESG Recommendation for IETF Administrative Restructuring
                  draft-iab-iesg-adminrest-rec-00.txt


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 April 18, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004).


Abstract


   This document describes a joint recommendation of the Internet
   Architecture Board and the Internet Engineering Steering Group for
   administrative restructuring of the Internet Engineering Task Force.
   This recommendation will be discussed on the IETF list
   (ietf@ietf.org), and the IETF leadership will attempt to determine if
   there is IETF consensus in going forward with this plan through a
   Last Call process.





Hollenbeck               Expires April 18, 2005                 [Page 1]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The Process That Produced This Recommendation  . . . . . . . .  3
   3.  Recommendation . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Arguments That Had Particular Weight in the Discussions  . . .  5
     4.1   Focusing on Scenarios C and O  . . . . . . . . . . . . . .  5
     4.2   Why We Chose Scenario O  . . . . . . . . . . . . . . . . .  6
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
   8.  Informative References . . . . . . . . . . . . . . . . . . . .  8
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  8
   A.  Scenario C . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   B.  Scenario O . . . . . . . . . . . . . . . . . . . . . . . . . . 36
       Intellectual Property and Copyright Statements . . . . . . . . 53




































Hollenbeck               Expires April 18, 2005                 [Page 2]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



1.  Introduction


   The Internet Engineering Task Force (IETF) has a need for
   administrative support functions.  The debate and dialogue of 2003
   and 2004 has led to the belief that the way these functions are
   provided needs to be changed.


   This document gives the recommendation of the Internet Engineering
   Steering Group (IESG) and Internet Architecture Board (IAB) on what
   the next step in that change process should be, and some of the
   background and reasoning behind this recommendation.


2.  The Process That Produced This Recommendation


   During several months of the year 2004, the Internet Architecture
   Board (IAB) and the Internet Engineering Steering Group (IESG) worked
   together to consider several different options for restructuring of
   the Internet Engineering Task Force (IETF) administrative functions.
   The goal of this effort was to produce a recommendation for
   consideration by and approval of the IETF community.  The rationale
   for this effort is described in RFC 3716 [1].  Much background work
   and several detailed proposals for community consideration are
   provided in a report prepared by a consultant titled "IETF
   Administrative Support Functions" [2].


   The consultant's report included several possible scenarios for
   administrative restructuring (named scenario A, B, C, and D).  As
   discussion took place within the IETF community, it became clear that
   some of the scenarios had features that appeared more promising than
   others, but that we did not have enough of a concrete proposal to
   crystallize opinions into a consensus for action.  Members of the
   IESG and IAB took on the task of working out more complete
   descriptions of two of the scenarios.  They were:


   o  Scenario C (section 4.4 of the report), which describes a scenario
      in which "administrative support functions for the IETF are
      legally housed in a focused, incorporated institution" with close
      ties to the Internet Society (ISOC).  This is included here as
      Appendix A.


   o  A new scenario, called "Scenario O", that includes features
      derived from scenarios A and B (sections 4.2 and 4.3 of the
      report, focusing on the formalization of the ISOC/IETF
      relationship while housing administrative support functions for
      the IETF within ISOC.  This is included here as Appendix B.


   These descriptions were not intended to close off discussion of other
   scenarios, but to focus discussion around what appeared to be two




Hollenbeck               Expires April 18, 2005                 [Page 3]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



   independent loci of support.


   Both scenarios were presented to the IETF community as mail notes
   (Scenario C [3], Scenario O [4]) sent to the IETF discussion list.
   IETF participants' opinions, while quite divided on the subject,
   seemed to indicate a preference for scenario O as a "lower risk
   operation", but some participants indicated that they felt unable to
   give an informed opinion, disagreed with the process, or declared the
   subject out of their field of competence.  This discussion garnered
   perhaps 40 participants who contributed on the list.


   The IETF Chair then requested an informal poll of IETF opinion.
   People interested in participating in the poll were directed to a web
   site where their opinions could be noted, including whether they
   wanted to state an opinion or not.  The raw poll results [5]) were
   also shared with the community via a mail note to the IETF discussion
   list.


   The poll sparked additional discussion on the list.  Not all of that
   discussion agreed with the methodology of the poll.  Taken with the
   discussion, though, the IESG and IAB members believe that there is a
   stronger indication of community support for change based on Scenario
   0 than on other scenarios.  The IESG and IAB members believe that
   Scenario O can be a workable basis of further progress, even if it is
   not the first preference for all members.  Taken together, this has
   led to the IESG/IAB recommendation given below.


3.  Recommendation


   The collective recommendation of the IAB and IESG was presented to
   the IETF community of Friday 8 October 2004 via a mail note [6] sent
   to the IETF mailing list:




















Hollenbeck               Expires April 18, 2005                 [Page 4]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



   "IETF folks,


   The IESG and IAB have been considering the input from the IETF
   community on the next steps going forward in IETF administrative
   restructuring.


   It appears clear to us that the community mostly sees scenario O
   as the lower-risk scenario, and the one that gives us the greatest
   probability of successfully doing what we have to do.


   Based on this, the IESG and the IAB make the following
   recommendation:


          We recommend that the IETF pursue scenario O, with the
          understanding that further work is needed to define the
          roles and responsibilities of the IETF, the IAOC and the
          ISOC BoT under this scenario


   The "BCP section" of the scenario O note will be pulled out and
   published as an internet-draft. We'd like to put this description
   to the IETF community for a formal Last Call before the November
   IETF meeting, if possible.


   Also, as noted in the recommendation above, there are a number of
   points where we need to work out in more detail how the system is
   going to work - who takes decisions, who accepts those decisions,
   and what conflict resolution mechanisms may be necessary, and so
   on. The IAB and IESG are drafting a document that will describe
   the finer level of detail as to the respective roles and
   responsibilities of each of the players. We will publish this as
   an internet-draft shortly.


   We will continue to work intensely on this!"


4.  Arguments That Had Particular Weight in the Discussions


4.1  Focusing on Scenarios C and O


   The IETF list was presented with four scenarios in the consultant
   report [2], which should be read for the full context.  In slogan
   form, they might be rendered as


   o  A: Leave it to ISOC


   o  B: Increase IETF control of ISOC, and use ISOC to do it


   o  C: Isolate the functions, let ISOC gather money, share control





Hollenbeck               Expires April 18, 2005                 [Page 5]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



   o  D: Cut the IETF off from ISOC and do it ourselves


   On the list, there seemed to be very few who were comfortable with
   the idea that "we" (for some version of "we") could "do it ourselves"
   as envisioned in scenario D.  There was also considerable worry about
   the risk associated with scenario C, especially with regard to
   financial stability - and that the perceived danger of problems would
   cause sponsors to withhold funding, thus precipitating problems even
   if there was no other reason for them.  Scenario C spoke strongly to
   those who worried about a possible conflict of interest between ISOC
   and the IETF community at some future date - "we don't know what ISOC
   will turn into" was the capsule summary.


   Scenario A worried people because it did not seem to acknowledge the
   IETF community's need to be able to determine if its needs were being
   met and to do something about it if they were not - the phrase
   "replace existing problematic structures by ISOC" was perhaps a
   capsule summary.  However, scenario B's list of possible mechanisms
   for involving IETF community directly in ISOC's operations was not
   viewed as acceptable or in balance with the full scope of ISOC's
   activities.  Members of the IAB & IESG developed a solution scenario
   that put the administrative activity within ISOC, but aimed to
   provide a means for the IETF to provide oversight and control of that
   specific activity within ISOC -- "scenario O" (the name is derived
   from the classification of blood types -- "neither A nor B").


   Thus the decision to focus on C and O as "alternatives to be worked
   out in detail" was made.


4.2  Why We Chose Scenario O


   Capsule summary: It might be possible to make either scenario work.
   But Scenario O could be made to work faster, and less painfully.


   The ISOC Board of Trustees was significantly worried that scenario C
   would make fundraising more difficult, which would necessarily affect
   its ability to support the IETF.


   The question of tax status for the new corporation was debated at
   some length on the list - legal counsel indicated that a corporation
   that did the IETF work (Scenario D) would probably be easy to get
   classified as 501(c)(3) (a type of non-profit corporation defined by
   U.S.  Internal Revenue Service (IRS) regulations), while a
   corporation that did only administrative support functions, as
   scenario C envisioned, would have more problems - and in all cases,
   the process of determining this would take months, and could be
   dragged out longer if we were unlucky.





Hollenbeck               Expires April 18, 2005                 [Page 6]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



   The community feedback, in addition to contributing many well-formed
   and well-argued points to the discussion, gave a powerful indication
   on where it was possible to get IETF consensus:


   o  It seemed possible to garner IETF consensus around scenario O; the
      people arguing for scenario C indicated that they "could live
      with" the alternative.


   o  It seemed much more difficult to garner IETF consensus around
      scenario C; many people arguing against it indicated that they
      were firmly convinced that it was the wrong choice for the IETF.


   The IETF is based around the idea that the consensus process, when it
   works, comes up with reasonable decisions.  We concluded that the
   apparent drift of community consensus was a reasonable basis for the
   IESG/IAB recommendations.


5.  IANA Considerations


   This document does not require any IANA actions.  However, the IETF
   administrative restructuring process is likely to affect how the
   relationship between the IETF and the IANA is managed.


6.  Security Considerations


   This document does not introduce any security considerations for the
   operation of the Internet.  However, administrative restructuring
   introduces several areas of risk to the future of the IETF.  The
   risks and their mitigation strategies are described in the scenarios
   as appended to this document.


7.  Acknowledgements


   This document is a collective work of the members of the IAB and the
   IESG.  Members of the IAB at the time of this writing include Bernard
   Aboba, Harald Alvestrand, Rob Austein, Leslie Daigle, Patrik
   Faltstrom, Sally Floyd, Mark Handley, Bob Hinden, Geoff Huston,
   Jun-ichiro Itojun Hagano, Eric Rescorla, Pete Resnick, and Jonathan
   Rosenberg.  Members of the IESG at the time of this writing include
   Harald Alvestrand, Steve Bellovin, Bill Fenner, Ted Hardie, Scott
   Hollenbeck, Russ Housley, David Kessens, Allison Mankin, Thomas
   Narten, Jon Peterson, Margaret Wasserman, Bert Wijnen, and Alex
   Zinin.


   The administrative restructuring effort can not succeed without
   community support and participation.  The IAB and IESG thus wish to
   acknowledge the collective contributions of members of the IETF
   community that have participated in the discussion of this topic.




Hollenbeck               Expires April 18, 2005                 [Page 7]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



8  Informative References


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


   [2]  Malamud, C., "IETF Administrative Support Functions",
        draft-malamud-consultant-report-01 (work in progress), September
        2004.


   [3]  <http://www.ietf.org/mail-archive/web/ietf/current/msg31321.html
        >


   [4]  <http://www.ietf.org/mail-archive/web/ietf/current/msg31326.html
        >


   [5]  <http://www.ietf.org/mail-archive/web/ietf/current/msg31493.html
        >


   [6]  <http://www.ietf.org/mail-archive/web/ietf/current/msg31609.html
        >



Author's Address


   Scott Hollenbeck
   Editor, IAB and IESG


   EMail: sah at 428cobrajet.net


Appendix A.  Scenario C


   This is Scenario C as it was posted on 20 September 2004.  A table of
   contents has been removed from this copy and the text has been
   reformatted to fit within IETF publication guidelines.


   Not an Internet-Draft                                     B. Wijnen
                                                    LucentTechnologies
                                                         H. Alvestrand
                                                         Cisco Systems
                                                            P. Resnick
                                                 QUALCOMM Incorporated
                                                    September 20, 2004


    AdminRest Scenario C: An IETF Administrative Support Foundation as
                   an Independent Nonprofit Corporation


   Abstract





Hollenbeck               Expires April 18, 2005                 [Page 8]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      This document defines a proposal for an IETF Administrative
      Support Foundation (IASF) as an independent not-for-profit
      corporation as a means for providing focused support for IETF
      community activities. It proposes the creation of an IASF Board
      of Trustees (BoT) that is mainly selected by and accountable to
      the IETF community and would provide oversight for the IETF
      Administrative Support Foundation. The IASF will also establish
      and maintain a strong relationship with the Internet Society
      (ISOC) and the current relationships between IETF and ISOC will
      basically be left unchanged.


      In order to allow the community to properly evaluate this
      scenario, some draft Articles of Incorporation and draft Bylaws
      for the IASF are included.  Some draft BCP wording for the IASF,
      IETF and ISOC relationships is also included.


      1.  Overview of Scenario C


      This document follows from two previous documents.  [RFC3716]
      defined the overall parameters and criteria for an administrative
      restructuring.  [I-D.malamud-consultant-report] provided an
      analysis of the implications of several of the suggested
      strategies.  This document picks one strategy and develops it
      further.


      In order to provide the most focused and effective administrative
      support to the IETF community, this updated scenario C proposes a
      new and well-defined legal entity to support the IETF
      administrative functions.  The name of that new entity is "The
      IETF Administrative Support Foundation" (IASF).


      First, it is important to understand that the IETF has been
      organized as an Activity of the Internet Society (ISOC) and as
      such represents the "Standards and Protocols" pillar of ISOC.
      Under this proposal, the IETF would continue to be an integral
      part of the Standards and Protocols pillar of ISOC.  ISOC
      currently provides these important functions to the IETF:


      1.  Standards Process Functions. ISOC plays a fundamental role in
          the IETF Standards Process, including appointment of the
          Nominating Committee (Nomcom) 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].


      2.  IETF Fund Raising Functions. ISOC provides the fund raising
          function as one source for financial support the IETF.




Hollenbeck               Expires April 18, 2005                 [Page 9]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      3.  Administration Functions. ISOC 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.


      The administrative restructuring of the IETF proposed in this
      document keeps that basic relationship between IETF and ISOC.
      Specifically, the recommendation does not propose any changes to
      the "Standards Process Functions" or to the "IETF Fund Raising
      Functions".


      Under the "Administration Functions", ISOC both funds and
      administers some (as stated above) parts of the IETF
      Administrative Support Functions.  Some of the funds (like for
      the RFC-Editor) go directly to the contractor who executes the
      administrative function.  The streamlining of the administrative
      support for the IETF ultimately intends to put the complete
      Administrative Support Functions under the newly recommended
      IASF.  This means that we recommend that ultimately, ISOC funds
      for the IETF will be transferred to the IASF, which will then
      administer all the contracts and payments according to an
      approved yearly budget.  The details of that process will be
      documented in a Memorandum of Understanding (MoU) between ISOC,
      IETF and IASF.


      This updated AdminRest Scenario C aims to provide the following:


      o  A continued close relationship between IETF and ISOC.


      o  A well defined legal entity within which the IETF can define
         the administrative activity in terms of IETF community needs.


      o  A Board of Trustees with operational oversight that is
         accountable to the IETF community.


      o  Continued separation between the IETF standards activity and
         any fund-raising for standards work.


      o  A close and well defined relationship between IASF and ISOC,
         documented in a BCP (or MoU).


      o  Appropriate ISOC oversight of its standards activities funds
         via a yearly budget approval and open reporting of funds
         spent.


      In scenario C, it is intended that the IETF Administrative
      Support Foundation will be a tax-exempt not-for-profit




Hollenbeck               Expires April 18, 2005                [Page 10]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      corporation as defined by Articles of Incorporation and a set of
      Bylaws.  These will describe the scope and purpose of the IASF
      and they also define the structure and responsibility of the
      Board of Trustees (BoT), a body that is mainly selected by the
      IETF and which is responsible for overseeing the IASF.  A draft
      of the Articles of Incorporation and Bylaws is included in the
      next sections of this document.


      Scenario C allows us (IETF) to establish IETF control over our
      administrative support functions in terms of determining that
      they meet the community's needs, and adjusting them from time to
      time using IETF processes.  This is to address the pressing
      administrative issues outlined in [RFC3716].


      Scenario C also encourages us (the IETF) to regularly evaluate
      that we do want to continue the relationships with ISOC and the
      contracts with our services providers (contractors).  It is based
      on the premise that we prefer to actively maintain relationships
      with other organizations and service providers instead of being
      bound to such relationships based on poorly defined and poorly
      documented historical facts.  A draft BCP for the relationship
      between ISOC, IETF and IASF is included as a separate section in
      this document.


      Scenario C does however bring the burden of creating a new legal
      entity (IASF) and such an undertaking is also not without risks.
      It will need careful planning and execution.  Migration from the
      current structure to this new structure is probably also somewhat
      more costly and time and labour consuming.  The sections below
      try to show how that would be achieved and outlines what further
      steps are needed to provide more detail if this scenario is
      chosen.


   2.  Work Plan for the IETF Administrative Support Foundation


      This section gives the work plan for the IETF Administrative
      Support Foundation (IASF) for the remainder of 2004 and the year
      2005.


   2.1  Workplan goals


      The work plan below is intended to satisfy three goals:


      o  Satisfy the IETF's need for support functions in 2005


      o  Operate with a positive account balance throughout 2005


      o  Start building up a fund inside the IASF to serve as a buffer




Hollenbeck               Expires April 18, 2005                [Page 11]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



         against budgetary emergencies in later years (such as meetings
         with a severe cost overrun, or force-majeure cancellations).


      The fund target is 6 months of operating revenue, and the target
      for building up the fund is 3 years.  The budgeted set-aside for
      the fund should thus be approximately 17% of operating revenue.


   2.2  Incorporation process


      There are 3 things that need to be in place before that
      corporation can be considered viable at all:


      o  IETF consensus on the plan


      o  ISOC agreement on a reasonable support contract


      o  Assurance that the corporation will have tax-exempt status


      Once this document has been discussed in the IETF, and the IESG
      and IAB gauges that rough consensus seems reached, the IETF
      leadership will take the following actions:


      o  Publish a Last Call on this document (to determine plan
         consensus).


      o  Choose a negotiating team to negotiate the ISOC contract.


      o  Choose an executive search team to find the IASF
         Administrative Director (IAD).


      o  Consult with legal counsel to determine how best to achieve
         tax-exempt status; this will affect the bylaws and articles of
         incorporation.


      When the Last Call is over, the IESG will consider whether there
      is still consensus, and if there is, approve this document for
      publication.  Once that happens, it will take the following
      steps:


      o  As soon as negotiations conclude, publish a Last Call on the
         ISOC contract.


      o  As soon as drafting of legal documents is completed, publish a
         Last Call on the Bylaws and Articles of Incorporation, and ask
         the Nomcom to start the process of selecting Nomcom-selected
         board representatives.


      These Last Calls are "speak now" Last Calls - if someone wishes




Hollenbeck               Expires April 18, 2005                [Page 12]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      to challenge the IETF consensus to go ahead with these actions,
      knowing what the formal documents will look like, this is their
      last chance.


      When these Last Calls are over, the IETF chair, the IAB chair and
      the ISOC President will jointly file the articles of
      incorporation, and the IESG, IAB and ISOC will fill their board
      seats.


      Note: This document does not say when a Request for Information
      (RFI) for IETF support services such as meeting planning is sent
      out. Advice is sought on the earliest point where this can be
      done.


   2.3  Contract establishment


      The most important activity for late 2004/early 2005 is to
      finalize contracts for the support of the IETF.  This includes:


      o  Funding


      o  Technical infrastructure


      o  Meeting management


      o  Clerk's office


      o  RFC Editor


      o  IANA


      There appears to be consensus in the IETF community that these
      functions, whether they are offered for free, remunerated or
      arranged for other consideration, should be under contract.


      The contract for funding is expected to be with ISOC, and should
      be finalized before IASF is established.


      The contract for technical infrastructure is expected to be an
      RFP, published in November of 2004, with responses being
      evaluated in December 2004, and services rendered from a mutually
      agreed date early in 2005.


      The contract for meeting management will be influenced by the
      need to have stable agreements for the 2005 meetings at an early
      date.  This indicates that IASF will honor a pre-IASF agreement
      to have these meeting contracts signed by Foretec (if that can be
      achieved).




Hollenbeck               Expires April 18, 2005                [Page 13]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      It is not clear how the contract for the clerk's office is to be
      managed at the time of this writing.


      The contract for the RFC Editor is expected to be with ISI, and
      is expected to be a continuation of the current contract with
      ISOC, which runs until the end of 2005.


      The contract with IANA will replace or augment the current MoU
      between the IETF and ICANN.  In its simplest form, it would
      simply be a reconfirmation of the duties of ICANN under the MoU.


   2.4  Performance evaluation


      The second task of the IASF is to make sure the IETF gets the
      support it needs.  The IASF will work together with the IETF
      community to make an effort to identify whether or not the IETF's
      needs are being met, and to coordinate improvements with the
      contractors.  This is an ongoing activity.


   2.5  Budgeting for 2006


      In June 2005, the IASF will start the yearly budgeting process
      with ISOC, as specified in the ISOC contract, leading to a work
      plan and budget for 2006.


   2.6  Reporting


      The IASF will present monthly updates on its economic status.
      These will be delivered to ISOC as part of the ISOC contract, and
      also be made publicly available so that the IETF community can
      inspect them.


   3.  Details of the IETF Administrative Support Foundation


      This section contains details about the proposal to change how
      the day-to-day IETF administrative support functions are
      provided.  This recommendation is based on the  initial
      description of "Scenario C" in the "Administrative Support
      Analysis" [I-D.malamud-consultant-report] provided by Carl
      Malamud.  It is further based on discussion in the IESG and IAB
      and on feedback on Carl's document as received on the IETF
      mailing list.  Further justifications, reasoning and motivations
      are given in Appendix A. Risk Analysis is done in Appendix C.


      This document recommends to create a well defined and legal
      entity called "The IETF Administrative Support Foundation"
      (IASF).  The name intends to clearly express that this new legal
      entity has only one single function, namely to provide the




Hollenbeck               Expires April 18, 2005                [Page 14]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      administrative support of the IETF Standardization and Protocol
      Development activities.  This entity will ultimately manage and
      administer all the administrative functions that are needed to
      support the IETF - the Standardization and Protocol Development
      activity of ISOC.


   3.1  Organizational Form and Legal Domicile


      The consultant report [I-D.malamud-consultant-report] contains a
      writeup on various choices in terms of how and where to
      incorporate. This recommendation has made the choice to
      incorporate in the US in the state of Virginia.  Some detail can
      be found in Appendix B.


      In this scenario, administrative support functions for the IETF
      are legally housed in a focused, incorporated institution
      (although the Administrative Director might be physically housed
      within the Internet Society).


      This scenario defines a number of concrete linkages with the
      Internet Society, which supplement the current close
      interconnection of the IETF community with ISOC.  The
      relationship is to be documented in a MoU (initial text is in
      Section 4).


   3.2  Draft Core Principles


   3.2.1  Principles of Establishment and Governance


      The following principles are to be respected for the
      establishment and governance of the IETF Administrative Support
      Foundation (IASF) and are the basis for the Draft Articles of
      Incorporation as in Section 6.1 and the Draft Bylaws as in
      Section 6.2:


      1.  The IASF shall be governed by a Board of Trustees (BoT), who
          shall be responsible for the fiscal, legal, and
          administrative infrastructure that supports the activities of
          the IETF.


      2.  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 (BCP) RFC series, which will
          be explicitly referenced in the organization documents of the
          IASF.


      3.  The IASF shall be transparent and responsible to the IETF.





Hollenbeck               Expires April 18, 2005                [Page 15]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      4.  The BoT shall appoint a Secretary and a Treasurer, who need
          not be members of the BoT.  The IETF Administrative Director
          (IAD) of the IASF shall provide staff support to the BoT.


      5.  The BoT shall be composed to strike a balance between
          "outside" and "inside" directors.  The IESG and IAB will each
          select a representative to serve as a voting member of the
          BoT. Mechanisms such as the Nominating Committee (Nomcom) and
          the appointment of certain seats by the ISOC fulfill the
          outside director obligations.


      6.  IAB, IESG and ISOC will have liaisons to the BoT in order to
          have a good basis for interaction.


      The BoT will have strong governance over a limited scope of
      activities (e.g., the fiscal, legal, and administrative
      infrastructure that are the charter of the IASF) but will have no
      authority over the IETF standards process.  In this board
      composition, the ISOC and Nomcom appointments ensure 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.


      IAB and IESG representatives will serve for one year.  For other
      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 BoT selected by the IETF are subject to the
      same recall procedures in effect for the IETF leadership such as
      members of the IAB and IESG.


   3.2.2  Principles of Operation of the IETF Administrative Support
         Foundation


      The following are general principles for the operation of the
      IASF:


      1.  The IASF shall employ an IETF Administrative Director (IAD)
          of the IASF, who shall be hired by the BoT with the advice
          and consent of the IESG and IAB.


      2.  All support services shall be contracted in an open and
          transparent manner.




Hollenbeck               Expires April 18, 2005                [Page 16]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      3.  The IAD shall submit a proposed annual budget to the BoT 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 IAD shall serve on the BoT as a non-voting, ex-officio
          member.


      5.  The BoT shall select a professional audit firm and shall
          commission an audit immediately upon the close of each fiscal
          year.


      6.  The IASF 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.  Draft MoU between ISOC, IETF and IETF Administrative Support
      Foundation


   4.1  Form and Scope of the Agreement


      This section presents some principles to be incorporated in a
      draft MoU/Contract between the Internet Society (ISOC) and the
      IETF Administrative Support Foundation (IASF), detailing the work
      each is expected to perform, the responsibilities each has, and
      the means by which these functions are accomplished.  This
      MoU/Contract shall be published as an RFC.


      The MoU/Contract will specify the responsibilities of the
      Internet Society, including:


      o  Reaffirmation of the Standards Process Function that ISOC
         performs for the IETF.


      o  Continuation of the Fund Raising Function that ISOC conducts,
         in which a single, unified campaign is used to solicit
         corporate, individual,  and other organizational donations for
         funding of the 3 Pillars.


      o  Disbursement of funds to the IASF according to the agreed-upon
         budgets and processes as specified in this agreement.


      o  Verification that IASF spends these funds to support the work
         of the IETF, within the scope described in the IASF bylaws.





Hollenbeck               Expires April 18, 2005                [Page 17]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      Responsibilities of IASF:


      o  Determine, in cooperation with the IETF, the support functions
         that are needed for the IETF, and can be achieved within
         available funds.


      o  Enter into contracts for these support functions.


      o  Supervise these contracts and ensure that they are being
         performed in the best interest of the IETF, within a
         reasonable budget and with agreed-upon performance.


   4.2  Cooperation mechanism


      IASF and ISOC agree that they will perform a budgeting procedure
      each year, comprising the following steps:


      o  IASF puts together a budget proposal to ISOC, and presents it
         in June.  This will specify the functions that need to be
         performed, the cost of each, the expected revenue from IETF
         meeting participation, and how much is being requested for
         ISOC to contribute.


      o  By the end of August, ISOC will give a budget number to IASF
         that says how much ISOC is willing to contribute to support
         the functions described in the IASF budget.


      o  Before November 1, ISOC and IASF will agree on a budget, an
         ISOC contribution, and a disbursement schedule.


      o  If either party sees that there is reason to change the
         budget, they can start a negotiation to do so at any time.  On
         mutual agreement to a change, payments are modified
         accordingly.


      o  ISOC may withhold funds if IASF fails to account for its
         expenditures, if it determines that IASF has departed
         significantly from its budgeted expenditures without agreement
         with ISOC to do so, or if ISOC determines that IASF is
         spending funds in violation of its bylaws.


   4.3  Promises Not to Do Things


      This section lays out things that would constitute interference
      in each others' business, or things that are Just Plain Wrong.
      In legal terms, these are called "covenants."


      ISOC will not place requirements on how IASF does business,




Hollenbeck               Expires April 18, 2005                [Page 18]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      except on reporting.  It will, for instance, not attempt to
      influence IASF choice of contractors or choice of meeting
      sponsors.  This restriction is meant to enforce the separation
      between fund raising and the actual operation of the standards
      process.


      IASF will not ask companies for money.  IASF may ask for sponsors
      for IETF events, per tradition, and may accept zero-cost provider
      contracts or in-kind donations, but ISOC is the organization
      charged with fundraising.


      Neither ISOC nor IASF will attempt to influence technical
      decisions of the IETF standards process.


   4.4  Initial contribution


      The Internet Society has already allocated $700,000 in transition
      funds.  As part of the formation process, this section sets out a
      way that a 2005 allocation of funds and an initial contribution
      for startup can be decided upon.  NOTE: This section is a GUESS!
      Its purpose is to give some sense of where we're at.


      If this plan is pursued, one of the first activities is to put
      together a detailed 2005 budget, including an analysis of cash
      flow and balance sheets to make sure that the organization is
      properly funded and will be solvent throughout the year.  This
      planning process should project out 3 years and show how the
      organization will be able to accumulate the appropriate cash
      reserve to make sure operations can continue in a stable manner.


      An initial estimate is for an on-going annual contribution of USD
      900.000 to IASF in 2005.  In addition, ISOC will contribute an
      additional USD 600.000 as an initial fund to start up IASF,
      payable after the Board of Trustees is seated and this contract
      is signed and approved by the IETF.


      ISOC commits to this ongoing level of contribution (USD 75.000
      per month) for the lifetime of this contract, unless modified by
      mutual agreement.


   4.5  Termination, law and so on


      This agreement may be terminated by either party for any reason
      on 12 months' notice.


      The parties may reach mutual agreement on a shorter termination
      period.





Hollenbeck               Expires April 18, 2005                [Page 19]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      All conflicts under this agreement are to be adjudicated under
      the laws of the United States and the State of Virginia, however
      the parties may also agree to arbitration, mediation or any other
      conflict resolution mechanisms.


   5.  Notes and Explanations


      This is where we put down why things are the way they are.


   5.1  Type of legal instrument


      This document is styled as a contract - an agreement between two
      parties, enforceable under law.  An alternate formulation would
      be a Memorandum of Understanding - but we want it to be clear to
      everyone that the parties stand behind their responsibilities
      under this document.  At the moment, the authors see no
      compelling arguments for not making it a contract.  In either
      case, the document is published as an RFC.


   5.2  Power Balance


      As written, it is designed to make it easy to do the right thing
      as long as the parties agree what that is, to make it clear that
      ISOC will continue to pay money as long as IASF does the Right
      Thing (and reports what it's doing), and that ISOC can stop the
      show quickly if it's clear that IASF is not doing the Right
      Thing.


   5.3  Budget figures


      The main purpose of the numbers is to make it clear that there
      WILL be numbers in this contract, and that it WILL represent a
      solid commitment by ISOC.  The numbers are "subject to change
      without notice" while this contract is negotiated.


   6.  Draft Incorporating Documents for the IETF Administrative
      Support Foundation


   6.1  Draft Articles of Incorporation


      This section 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'|




Hollenbeck               Expires April 18, 2005                [Page 20]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      Form SCC819, 07/ 03 [1] ------


      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 Administrative
          Support Foundation.


      2.  The corporation shall have no members.


      3.  The purpose of the corporation is to manage and administer
          all the administrative functions for the IETF - the
          Standardization and Protocol Development activity of the
          Internet Society.


      4.  The Trustees of the corporation shall be elected or appointed
          as specified in Article IV (Section 6.2.5) of the Bylaws.


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


      6.  The initial Trustees are: XXX


      7.  The incorporators are: XXX


   6.2  Draft Bylaws of the IETF Administrative Support Foundation


      As with the Draft Articles, the 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.


   6.2.1  Article I: Organization


      The name of the Corporation shall be The IETF Administrative
      Support Foundation (which is hereinafter also referred to as the
      "IASF").


   6.2.2  Article II: Purpose


      *Section 1: Purpose.* The IASF shall be operated exclusively for




Hollenbeck               Expires April 18, 2005                [Page 21]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      nonprofit educational, charitable, and scientific purposes,
      including, without limitation, the purposes stated in the IASF's
      Articles of Incorporation.


      *Section 2: Restrictions.* No part of the net earnings of the
      IASF shall inure to the benefit of, or be distributable to,
      private persons, except that the IASF 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
      IASF 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.


   6.2.3  Article III: Members


      The IASF shall have no members and no stockholders.


   6.2.4  Article IV: Offices


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


   6.2.5  Article V: Board of Trustees


      *Section 1: Authority and Responsibilities.* The power,
      authority, property, and affairs of the IASF shall at all times
      be exclusively exercised, controlled, and conducted by or under
      the authority of the Board of Trustees (BoT) 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.


         One (1) Trustee will be selected by the IAB.


         One (1) Trustee will be selected by the IESG.


         Two (2) Trustees will be selected by the Internet Society.


         Three (3) Trustees will be selected by the IETF community.





Hollenbeck               Expires April 18, 2005                [Page 22]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      The IAB chair and IETF chair will functions as liaisons from the
      IAB and IESG respectively to the Board of Trustees.  The chair
      and president of the Internet Society will function as liaisons
      from the ISOC to the Board of Trustees.


      *Section 3: Terms.* The term of office of IESG and IAB Selected
      Trustees shall be one (1) year or until their successors have
      been selected and assume office.  The term of office of otherwise
      Selected Trustees shall be three (3) years or until their
      successors have been selected and assume office.  Selected
      Trustees may be selected to serve multiple terms.


      *Section 4: Selection of the Board of Trustee*


      1.  *Selection of IESG and IAB Selected Trustees.* The IESG and
          IAB shall each select one representative Trustee, who is not
          at the same time an IESG or IAB member.


      2.  *Selection of otherwise Selected Trustees.* Three (3) IETF
          Selected Trustees shall be selected by the IETF nominations
          process (as defined in [RFC3777] or its successor) and
          confirmed by the IESG.  Two ISOC 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 IASF at its principal
          office or to the Secretary of the IASF.  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 may 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 (i.e.  fifty (50) percent plus
      one (1)) of the Trustees shall constitute a quorum for the
      transaction of business.  Unless otherwise stated in these




Hollenbeck               Expires April 18, 2005                [Page 23]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      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.  *Written notice, waiver, action.* Wherever the text below
          speaks of "written" it is also permitted to use e-mail.


      2.  *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.


      3.  *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.


      4.  *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




Hollenbeck               Expires April 18, 2005                [Page 24]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



          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
          Administrative Support Foundation (IASF) 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 IASF 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 IASF are likely to have an impact on 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 IASF 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
          IASF in a transaction with the IASF shall not invalidate the
          IASF'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 IASF and the
          Trustee's interest in the transaction with the IASF are fully
          disclosed to the Board of Trustees of the IASF, either by the
          Trustee having a direct or indirect personal interest in the




Hollenbeck               Expires April 18, 2005                [Page 25]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



          transaction with the IASF, or are brought to the attention of
          the Board by a third party; or (ii) the BoT of the IASF, by a
          vote of the Trustees (without a conflict of interest) of the
          IASF vote to authorize, approve, or ratify a transaction with
          the IASF; or (iii) the transaction with the IASF in which the
          direct or indirect personal interest of a IASF Trustee was
          disclosed to the BoT of The IASF and was determined by the
          BoT of the IASF entitled to vote on the matter is determined
          by the BoT voting to be in the IASF's interests,
          notwithstanding the personal interest of the non-voting
          Trustee.


      3.  In determining whether a conflict of interest exists, the BoT
          of the IASF 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 BoT 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 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 BoT of
      the IASF must be approved by a procedure adopted by the board and
      published on the IASF web site.


   6.2.6  Article VI: Officers


      *Section 1: Number.* The officers of the IASF shall consist of a
      Chairman of the Board, a Treasurer and a Secretary, and such
      other inferior officers as the BoT 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 IASF.




Hollenbeck               Expires April 18, 2005                [Page 26]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      *Section 3: Resignation.* An officer may resign by delivering his
      written resignation to the IASF 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 BoT 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 BoT 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 BoT.


      *Section 5: Vacancies.* In case any elected officer position of
      the IASF 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 BoT, 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 BoT of the
      IASF.  If the Chairman is not available to preside over a
      meeting, the majority of the Trustees present shall select
      another Trustee to preside at that meeting only.


      *Section 7: Treasurer.* The Treasurer shall have the custody of
      all funds, property, and securities of the IASF, 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 BoT
      may require or as required by law, whichever is greater.  When
      necessary or proper, he or she may endorse on behalf of the IASF
      for collection, checks, notes and other obligations, and shall
      deposit same to the credit of the IASF at such bank or banks or
      depository as the BoT 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 IASF.  He or she shall enter or cause to
      be entered regularly on the books of the IASF 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 IASF, and shall exhibit such books at all
      reasonable times to any Trustee on application at the offices of
      the IASF incident to the Office of Treasurer, subject to the
      control of the BoT.  Certain duties of the Treasurer as may be
      specified by the BoT may be delegated by the Treasurer.




Hollenbeck               Expires April 18, 2005                [Page 27]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      *Section 8: Secretary.* The Secretary shall have charge of such
      books, records, documents, and papers as the BoT 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 BoT.  The Secretary may sign, with the Chairman, in the name
      and on behalf of the IASF, any contracts or agreements, and he or
      she may affix the corporate seal of the IASF.  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 BoT or the Chairman of the BoT.
      Certain duties of the Secretary as may be specified by the BoT
      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.


   6.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 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 IASF may be amended by an affirmative vote
      of two-thirds of the BoT 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.


   6.2.8  Article VIII: Dissolution


      Upon the dissolution of the IASF, the IASF, after paying or
      making provisions for the payment of all of the liabilities of
      the IASF, dispose of all of the assets of the IASF exclusively
      for the exempt purposes of the IASF 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




Hollenbeck               Expires April 18, 2005                [Page 28]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      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.


   6.2.9  Article IX: Miscellaneous Provisions


      *Section 1: Fiscal Year.* The fiscal year of the IASF 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 IASF 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 BoT 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 IASF, as amended and in
      effect from time to time.


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


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


   7.  Acknowledgment of Contributions and Reviews


      A lot of text was taken from the report from Carl Malamud.




Hollenbeck               Expires April 18, 2005                [Page 29]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      Further review was done by various IESG and IAB members.  Carl
      Malamud also reviewed this document and helped with making the
      text better English and easier to read.


      This document was created with "xml2rfc"
      <http://xml.resource.org/> using the format specified
      in [RFC2629].


   8.  IANA Considerations


      This documents requires no action from IANA.


   9.  Security Considerations


      This document describes a scenario for the structure of the
      IETF's administrative support activities.  It introduces no
      security considerations for the Internet.


      Safety considerations for the integrity of the standards process
      are outlined in Appendix C.


   10.  References


   10.1  Normative References


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


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


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


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


      [Virginia] State of Virginia, "Title 13.1: Corporations, Limited
              Liability Companies, Business Trusts", Undated,




Hollenbeck               Expires April 18, 2005                [Page 30]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



              <http://leg1.state.va.us/cgi-
              bin/legp504.exe?000+cod+TOC1301000> .


   10.2  Informative References


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


      [I-D.malamud-consultant-report] Malamud, C., "IETF Administrative
              Support Functions", draft-malamud-consultant-report-01
              (work in progress), September 2004.


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


   URIs


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


   Authors' Addresses


      Bert Wijnen
      Lucent Technologies
      Schagen 33
      3461 GL Linschoten
      Netherlands
      Phone: +31-348-407-775
      EMail: bwijnen at lucent.com


      Harald Tveit Alvestrand
      Cisco Systems
      Weidemanns vei 27
      Trondheim 7043
      Norway
      EMail: harald at alvestrand.no


      Peter W. Resnick
      QUALCOMM Incorporated
      5775 Morehouse Drive
      San Diego, CA 92121-1714
      US
      EMail: presnick at qualcomm.com


   Appendix A.  Justification, Reasoning and Motivations





Hollenbeck               Expires April 18, 2005                [Page 31]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      Quite a bit of the proposals from the consultant report have been
      incorporated in this recommendation.  However, a number of
      changes have been made.  In this section we try to explain which
      changes were made and why.


   A.1  Changes to the name of the administrative entity


      In order to make it very clear that the new and legal
      administrative entity is separate from the ISOC IETF activity
      that deals with standardization and protocol development, this
      recommendation uses "The IETF Administrative Support Foundation"
      as the name for the corporation to be created.


   A.2  Domicile


      Various questions have been raised if the choice of Domicile
      should be further investigated.  In order to make progress this
      document recommends to make a definite choice now and go for a US
      based not-for-profit corporation in the state of Virginia.
      Further investigation would most probably delay the whole process
      by at least half a year.


   A.3  Changes to the composition of the BoT


      The consultant report had a proposal for Position-based Trustees,
      which would automatically make the IAB chair and the IETF chair
      voting members of the Board of Trustees (BoT) of the IETF
      Administrative Support Foundation.  There was discussion on the
      IETF mailing list that those people are not selected because of
      their business acumen but rather for their technical leadership.
      We do not want to change those criteria.  Another concern was
      that this might generate a conflict of interest as well.  So this
      recommendation has made the IAB and IETF chairs liaisons to the
      BoT.


      Instead of making IAB and IESG chairs voting Trustees, this
      recommendation specifies that IAB and IESG can each select an
      outside (i.e.  not a member of IAB or IESG) person as a voting
      Trustee.


      The selection of three (3) IETF selected Trustees has not changed
      in this recommendation.  However, there is a concern that the
      current composition of the Nomcom is not tailored to selecting
      people for this position.  So over time a different process may
      need to be defined for selecting those Trustees.


      In order to balance the ISOC and IETF people present at the BoT
      meetings, this recommendation also specifies that the chair and




Hollenbeck               Expires April 18, 2005                [Page 32]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      president of ISOC also function as liaisons to the BoT of the
      IETF Administrative Support Foundation.


   Appendix B.  Domicile of the IETF Administrative Support Foundation


      A U.S.  non-profit, non-member corporation is being recommended.
      This recommendation is based on simple considerations of
      expediency and pragmatism: a transition will be simplest and
      least risky (in the short term).  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 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  It is very likely that the IETF Administrative Support
         Foundation 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




Hollenbeck               Expires April 18, 2005                [Page 33]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



         entities such as an IETF administrative support organization.


      Since this document recommends incorporating in the U.S.,
      Virginia is the 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).


   Appendix C.  Risk Analysis


      This scenario (as do all scenarios) has some risks.  This section
      tries to enumerate the sort of risks that we recognize and
      summarizes why we think we can accept the risk or what kind of
      action we think we can take if the risk indeed materializes into
      a problem.


   C.1  US Domicile risks


      As explained in [I-D.malamud-consultant-report], incorporating in
      the US carries two specific risks: the perception of the IETF
      being a US-based organization and the potential for (or
      perception of) governmental interference.


      The IETF is an international organization.  However, even now,
      the fact that the IETF standards processes are run in English and
      that many of its current support organizations are US-based
      leaves an impression that the IETF is too US-centric.
      Incorporating the new administrative entity in the US may add to
      that perception.


      Also, the IETF history is based in US federal government research
      and funding.  Though IETF is long separated from those
      beginnings, even in the past few years there have been
      interactions between the US government and the IETF that have
      concerned people.  Incorporating the administrative entity in the
      US may invite more US governmental interference in the standards
      activity of the IETF, or at the very least may leave the
      perception that the US government might get involved.


      Both of these are serious problems, but we think there is
      justification for and at least one mitigation to these risks.  Of
      course, the primary reason to consider US incorporation is
      expedience (See section 4.4.1.1 of [I-D.malamud-consultant-
      report]).  We agree that the expedience makes US incorporation
      worth the risk.  But incorporating in multiple domiciles would
      significantly mitigate the risk.  Assuming we go down the path of




Hollenbeck               Expires April 18, 2005                [Page 34]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      US incorporation, we would like legal counsel to advise on the
      possibility of incorporating in other domiciles (specifically
      Switzerland and The Netherlands) at a later date after US
      incorporation has been completed.  If this is (as we suspect)
      indeed possible, we think this would be the best way to go
      forward.


   C.2  Non-profit status risk


      One of the risks pointed out to incorporation was the potential
      that we would not get non-profit status, and that we must
      therefore preserve some money in escrow for tax liability
      purposes.  Estimates for the time it will take to get such status
      can be several months or even longer in some cases.


      It is important to point out that the tax liability is based on
      profits, not on gross revenues.  If the IASF is only taking in
      enough money to cover expenses, there would be very little tax
      liability. However, if more revenue is brought in than is spent,
      for example to build up an endowment or operating reserve, that
      "profit" is potentially taxable if non-profit status is not
      granted.


      To mitigate this risk, the corporation could be created and non-
      profit status applied for first, and operation of the corporation
      would only begin after non-profit status was obtained.  The IETF
      would use an interim plan for continued operations until that
      time. This way, no money would need to be in escrow during the
      process of applying for non-profit status.  However, that seems
      an excessively cautious path to take given what appears to be the
      fairly clear non-profit nature of the IETF.


      Commencing operations while the non-profit application is being
      considered, but being careful about balancing revenue with
      expenses and keeping an appropriate escrow account seems like a
      prudent task. Further, any fund raising campaigns that result in
      shifts to the balance sheet of the IASF should be conducted
      cautiously until non-profit status is granted.


   C.3  Execution risks


      It is important that the execution goes well.  Risks that we are
      aware of include:


      o  we can't hire a good IAD


      o  we fail to project cash flow properly and go insolvent





Hollenbeck               Expires April 18, 2005                [Page 35]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      o  we can't cut a deal with Foretec and have no 2005 meetings


      o  we get bad lawyers and they take too long and charge too much


      o  isoc runs out of money and doesn't tell us early enough


      In order to mitigate these problems we have a proposed work plan
      included in this document.  It is important that we get review of
      this work plan by as many eyes as we can get, to make sure we
      have considered all the possible steps that need to be taken.


   C.4  Insolvency risk


      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.


   C.5  Legal risks


      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.



Appendix B.  Scenario O


   This is Scenario O as it was posted on 20 September 2004.  A table of
   contents has been removed from this copy and the text has been
   reformatted to fit within IETF publication guidelines.


   Not an Internet-Draft                                      L. Daigle
                                                               VeriSign




Hollenbeck               Expires April 18, 2005                [Page 36]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



                                                           M. Wasserman
                                                             ThingMagic
                                                     September 20, 2004


       AdminRest Scenario O: An IETF-Directed Activity Housed Under the
                 Internet Society (ISOC) Legal Umbrella


   Abstract


      This document defines an alternative proposal for the structure
      of the IETF's administrative support activity (IASA) -- an IETF-
      defined and directed activity that operates within the ISOC legal
      umbrella. It proposes the creation of an IETF Administrative
      Oversight Committee (IAOC) that is selected by and accountable to
      the IETF community.  This committee would provide oversight for
      the IETF administrative support activity, which would be housed
      within the ISOC legal umbrella.  In order to allow the community
      to properly evaluate this scenario, some draft BCP wording is
      included.


      1.  Overview of Scenario O


      IETF community discussions of the scenarios for administrative
      restructuring presented in Carl Malamud's consultant report [I-
      D.malamud-consultant-report] have led to the identification of a
      potentially viable alternative that is not included in that
      report -- an IETF-defined and directed administrative support
      function housed under the ISOC legal umbrella (called "IASA"
      hereafter).  This new scenario retains some properties of the
      original ISOC-based scenarios, Scenarios A and B.  However, this
      new scenario aims to provide:


      o  continued close relationship with ISOC


      o  a clear basis from which the IETF can define (and, over time,
         refine) the administrative activity in terms of IETF community
         needs, using existing IETF/ISOC processes


      o  an operational oversight board that is accountable to the IETF
         community


      o  continued separation between the IETF standards activity and
         any fund-raising for standards work (within ISOC)


      o  appropriate ISOC oversight of its standards activities funds


      This scenario is nicknamed "Scenario O" -- it is derived from,
      but does not entirely encompass, Scenario A or Scenario B.




Hollenbeck               Expires April 18, 2005                [Page 37]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      In Scenario O, the IETF administrative support function would be
      defined in a BCP that would be created via the IETF standards
      process [RFC2026] and approved by the ISOC Board of Trustees.
      This BCP would describe the scope of an IETF Administrative
      Support Activity (IASA) and would define the structure and
      responsibilities of the IETF Administrative Oversight Committee
      (IAOC), an IETF-selected body responsible for overseeing the
      IASA.  Like the Internet Architecture Board (IAB), the IASA would
      be housed within the ISOC legal umbrella. The BCP would also
      describe ISOC's responsibilities within this scenario, including
      requirements for financial accounting and transparency.  A draft
      of this BCP is included in the next section of this document.


      Scenario O allows us to establish IETF control over our
      administrative support functions in terms of determining that
      they meet the community's needs,  and adjusting them from time to
      time using IETF processes.  At the same time, it does not require
      that the IETF community determine, create and undertake the risks
      associated with an appropriate corporate structure (with similar
      financial infrastructure and tax-exempt status to ISOC's) in
      order to solve the pressing administrative issues outlined in
      [RFC3716].  This proposal also defines the boundaries of the IASA
      so that it could be encapsulated and moved elsewhere at some
      future date, should that ever be desirable.


   2.  Draft of Administrative Support BCP


      This section proposes draft text for a BCP that would define the
      scope and structure of the IASA.  Although this text would
      require further refinement within the IETF community, this
      section is intended to be clear and complete enough to allow the
      community to reach a well-informed opinion regarding this
      scenario.


   2.1  Definition of the IETF Administrative Support Activity (IASA)


      The IETF undertakes its technical activities as an ongoing, open,
      consensus-based process.  The Internet Society has long been a
      part of the IETF's standards process, and this document does not
      affect the ISOC-IETF working relationship concerning standards
      development or communication of technical advice.  The purpose of
      this memo is to define an administrative support activity that is
      responsive to the IETF technical community's needs, as well as
      consistent with ISOC's operational, financial and fiduciary
      requirements while supporting the IETF technical activity.


      The IETF Administrative Support Activity (IASA) provides
      administrative support for the technical work of the IETF.  This




Hollenbeck               Expires April 18, 2005                [Page 38]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      includes, as appropriate,  undertaking or contracting for the
      work described in (currently, [RFC3716] but the eventual BCP
      should include the detail as an appendix), covering IETF document
      and data management, IETF meetings, any operational agreements or
      contracts with the RFC Editor and IANA.  This provides the
      administrative backdrop required to support the IETF standards
      process and to support the IETF organized technical activities,
      including the IESG, IAB and working groups.  This includes the
      financial activities associated with such IETF support
      (collecting IETF meeting fees, payment of invoices, appropriate
      financial management, etc).  The IASA is responsible for ensuring
      that the IETF's administrative activities are done and done well;
      it is not the expectation that the IASA will undertake the work
      directly, but rather contract the work from others, and manage
      the contractual relationships in line with key operating
      principles such as efficiency, transparency and cost
      effectiveness.


      The IASA is distinct from other IETF-related technical functions,
      such as the RFC editor, the Internet Assigned Numbers Authority
      (IANA), and the IETF standards process itself.  The IASA is not
      intended to have any influence on the technical decisions of the
      IETF or on the technical contents of IETF work.


   2.1.1  Structure of the IASA


      The IASA will be structured to allow accountability to the IETF
      community.  It will determine the ongoing success of the activity
      in meeting IETF community needs laid out in this BCP, as well as
      ISOC oversight of its financial and resource contributions.  The
      supervisory body defined for this will be called the IETF
      Administrative Oversight Committee (IAOC).  The IAOC will consist
      of volunteers, all chosen directly or indirectly by the IETF
      community, as well as appropriate ex officio appointments from
      ISOC and IETF leadership.  The IAOC will be accountable to the
      IETF community for the effectiveness, efficiency and transparency
      of the IASA.


      The IASA will initially consist of a single full-time employee of
      ISOC, the IETF Administrative Director (IAD).  The IAD will
      require a variety of financial, legal and administrative support,
      and it is expected that this support will be provided by ISOC
      support staff following an expense and/or allocation model TBD.


      Although the IAD will be a full-time ISOC employee, he will work
      under the direction of the IAOC.  The IAD will be selected by a
      committee of the IAOC, consisting minimally of the ISOC President
      and the IETF Chair.  This same committee will be responsible for




Hollenbeck               Expires April 18, 2005                [Page 39]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      periodically reviewing the performance of the IAD and determining
      any changes to his employment and compensation.  In certain cases
      (to be defined clearly -- chiefly cases where the ISOC employee
      is determined to have contravened basic ISOC policies), the ISOC
      President may make summary decisions, to be reviewed by the
      hiring committee after the fact.


      The IAD will be responsible for administering the IETF finances,
      managing a separate bank account for the IASA, and establishing
      and administering the IASA budget.  To perform these activities,
      the IAD is expected to have signing authority comparable to other
      ISOC director-level employees.  Generally, expenses or agreements
      outside that authority to be approved for financial soundness as
      determined by ISOC policy.  The joint expectation is that ISOC's
      policies will be consistent with allowing the IAD to carry out
      IASA work effectively and efficiently.  Should the IAOC have
      concerns about that, the IAOC and ISOC commit to working out
      other policies that are mutually agreeable.


      The IAD will also fill the role of the IETF Executive Director,
      as described in various IETF process BCPs.  All other
      administrative functions will be outsourced via well-defined
      contracts.  The IAD will be responsible for negotiating and
      maintaining those contracts, as well as providing any
      coordination that is necessary to make sure the IETF
      administrative support functions are properly covered.


   2.1.2  IAD Responsibilities


      The day to day responsibilities of the IAD will focus on managing
      contracts with the entities providing the work supporting the
      IETF technical activity.


      The IAD will provide regular (monthly and quarterly) reports to
      the IAOC and ISOC.


      All contracts will be negotiated by the IAD (with input from any
      other appropriate bodies), and reviewed by the IAOC.  The
      contracts will be executed by ISOC, on behalf of the IETF, after
      whatever review ISOC requires (e.g., legal, Board of Trustees).


      The IAD will prepare an annual budget, which will be reviewed and
      approved by the IAOC.  The IAD will be responsible for presenting
      this budget to the ISOC Board of Trustees, as part of ISOC's
      annual financial planning process.  The partnering is such that
      the IAOC is responsible for ensuring the suitability of the
      budget for meeting the IETF community's needs, but it does not
      bear fiduciary responsibility; the ISOC board needs to review and




Hollenbeck               Expires April 18, 2005                [Page 40]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      understand the budget and planned activity in have enough detail
      of the budget and proposed plans to properly carry out its
      fiduciary responsibility.


   2.1.3  IAOC Responsibilities


      The role of the IAOC is to provide appropriate input to the IAD,
      and oversight of the IASA functioning.  The IAOC is not expected
      to be regularly engaged in IASA work, but rather to provide
      appropriate approval and oversight.


      Therefore, the IAOC's responsibilities are:


      o  Select the IAD, as described above.


      o  Review the IAD's financial reports, and provide approval of
         the IAD's budget proposals in terms of fitness for IETF
         purposes.


      o  Review IASA functioning with respect to meeting the IETF
         community's working needs.


      The IAOC's role is to review, not carry out the work of,  the IAD
      and IASA.  As such, it is expected the IAOC will have monthly
      teleconferences and periodic face to face meetings, probably
      coincident with IETF plenary meetings, consistent with ensuring
      an efficient and effective operation.


   2.1.4  IASA Funding


      The IASA is supported financially in 3 ways:


      1.  IETF meeting revenues.  The IAD, in consultation with the
          IAOC, sets the meeting fees as part of the budgeting process.
          All meeting revenues go to the IASA.


      2.  Designated ISOC donations.  The IETF and IASA do no specific
          fund raising activities; this maintains separation between
          fundraising and standards activities.  Any organization
          interested in supporting the IETF activity will continue to
          be directed to ISOC, and any funds ISOC receives specifically
          for IETF activities (as part of an ISOC program that allows
          for specific designation) will be put in the IASA bank
          account for IASA management.


      3.  Other ISOC support.  ISOC will deposit in the IASA account,
          each quarter, the funds committed to providing as part of the
          IASA budget (where the meeting revenues and specific




Hollenbeck               Expires April 18, 2005                [Page 41]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



          donations do not cover the budget).  These funds may come
          from member fees or from other revenue streams ISOC may
          create.


      Note that the goal is to achieve and maintain a viable IETF
      support function based on meeting fees and specified donations,
      and the IAOC and ISOC are expected to work together to attain
      that goal.  (I.e., dropping the meeting fees to $0 and expecting
      ISOC to pick up the slack is not desirable; nor is raising the
      meeting fees to prohibitive levels to fund all non-meeting-
      related activities!).


      Also, in normal operating circumstances, the IASA would look to
      have a 6 month operating reserve for its activities.  Rather than
      having the IASA attempt to accrue that in its bank account, the
      IASA looks to ISOC to build and provide that operational reserve
      (through whatever mechanism instrument ISOC deems appropriate --
      line of credit, financial reserves, etc).  Such reserves do not
      appear instantaneously; the goal is to reach that level of
      reserve by 3 years after the creation of the IASA.  It is not
      expected that any funds associated with such reserve will be held
      in the IASA bank account.


   2.2  IAOC Membership, Selection and Accountability


      Note:  This section is particularly subject to change as we work
      to find the best way to achieve the key principles.  The key
      principles being adhered to are that while this should be
      reasonably separate from IETF Standards process management:


      o  the IETF and IAB Chairs need to be involved to a level that
         permits them to be involved in and oversee the aspects
         pertinent to their roles in managing the technical work (e.g.,
         the IAB looks after the RFC Editor relationship)


      o  the IETF and IAB Chairs must not be critical path to getting
         decisions to and through the IASA.


      The current draft, below, therefore makes the IETF Chair ex
      officio voting member of the IAOC, and the IAB Chair a non-voting
      liaison. Future versions may change either or both, depending on
      what makes sense to the IETF community in its deliberations.


      The IAOC will consist of seven voting members who will be
      selected as follows:


      o  2 members chosen by the IETF Nominations Committee (NomCom)





Hollenbeck               Expires April 18, 2005                [Page 42]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      o  1 member chosen by the IESG


      o  1 member chosen by the IAB


      o  1 member chosen by the ISOC Board of Trustees


      o  The IETF Chair (ex officio)


      o  The ISOC President/CEO (ex officio)


      There will also be two non-voting, ex officio liaisons:


      o  The IAB Chair


      o  The IETF Administrative Director


      The voting members of the IAOC will choose their own chair each
      year using a consensus mechanism of its choosing.  Any appointed
      voting member of the IAOC may serve as the IAOC Chair (i.e., not
      the IETF Chair or the ISOC President/CEO).  The role of the IAOC
      Chair is to organize the IAOC.  The IAOC Chair has no formal
      duties for representing the IAOC, except as directed by IAOC
      consensus.


      The members of the IAOC will typically serve two year terms.
      Initially, the IESG and ISOC Board will make one-year
      appointments, the IAB will make a two-year appointment, and the
      Nomcom will make one one-year appointment and one two-year
      appointment to establish a pattern where approximately half of
      the IAOC is selected each term.


      The two NomCom selected members will be selected using the
      procedures described in RFC 3777.  For the initial selection, the
      IESG will provide the list of desired qualifications for these
      positions.  In later years, this list will be provided by the
      IAOC.


      While there are no hard rules regarding how the IAB and the IESG
      should select members of the IAOC, it is not expected that they
      will typically choose current IAB or IESG members, if only to
      avoid overloading existing leadership.  However, they should
      choose people who are familiar with the administrative support
      needs of the IAB, the IESG and/or the IETF standards process.  It
      is suggested that a fairly open process be followed for these
      selections, perhaps with an open call for nominations and/or a
      period of public comment on the candidates.  The IAB and IESG are
      encouraged to look at the procedure for IAB selection of ISOC
      Trustees for an example of how this might work.




Hollenbeck               Expires April 18, 2005                [Page 43]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      Although the IAB and IESG will choose some members of the IAOC,
      those members will not directly represent the bodies that chose
      them.  All members of the IAOC are accountable directly to the
      IETF community. To receive direct feedback from the community,
      the IAOC will hold an open meeting at least once per year at an
      IETF meeting.  This may take the form of an open IAOC plenary or
      a working meeting held during an IETF meeting slot.  The form and
      contents of this meeting are left to the discretion of the IAOC
      Chair.


      Decisions of IAOC members or the entire IAOC are subject to
      appeal using the procedures described in RFC 2026.  The initial
      appeal of an individual decision will go to the full IAOC.
      Appeals of IAOC decisions will go to the IESG and continue up the
      chain as necessary (to the IAB and the ISOC Board).  The IAOC
      will play no role (aside from possible administrative support) in
      appeals of WG Chair, IESG or IAB decisions.


      In the event that an IAOC member abrogates his duties or acts
      against the bests interests of the IETF community, IAOC members
      are subject to recall using the recall procedure defined in RFC
      3777.  IAB and IESG-appointed members of the IAOC are not subject
      to recall by their appointing bodies.


   2.3  IASA Budget Process


      While the IASA sets a budget for the IETF's administrative needs,
      its budget process clearly needs to be closely coordinated with
      ISOC's. The specific timeline will be established each year,
      before the second IETF meeting.  A general annual timeline for
      budgeting will be:


      July 1 The IAD presents a budget proposal (for the following
         fiscal year, with 3 year projections) to the IAOC.


      August 1 The IAOC approves the budget proposal for IETF purposes,
         after any appropriate revisions.  As the ISOC President is
         part of the IAOC, the IAOC should have a preliminary
         indication of how the budget will fit with ISOC's own
         budgetary expectations.  The budget proposal is passed to the
         ISOC Board of Trustees for review in accordance with their
         fiduciary duty.


      September 1 The ISOC Board of Trustees approves the budget
         proposal provisionally.  During the next 2 months, the budget
         may be revised to be integrated in ISOC's overall budgeting
         process.





Hollenbeck               Expires April 18, 2005                [Page 44]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      November 1 Final budget to the ISOC Board for approval.


      The IAD will provide monthly accountings of expenses, and will
      update forecasts of expenditures quarterly.  This may necessitate
      the adjustment of the IASA budget.  The revised budget will need
      to be approved by the IAOC and ISOC Board of Trustees.


   2.4  Relationship of the IAOC to Existing IETF Leadership


      The IAOC will be directly accountable to the IETF Community.
      However, the nature of the IAOC's work will involve treating the
      IESG and IAB as internal customers.  The IAOC should not consider
      its work successful unless the IESG and IAB are satisfied with
      the administrative support that they are receiving.


   2.5  ISOC Responsibilities for IASA


      Within ISOC, support for the IASA should be structured to meet
      the following goals:


      Transparency: The IETF community should have complete visibility
         into the financial and legal structure of the ISOC standards
         activity. In particular, the IETF community should have access
         to a detailed budget for the entire standards activity,
         quarterly financial reports and audited annual financials.  In
         addition, key contract material and MOUs should be publicly
         available.  Most of these goals are already met by ISOC today.
         The IAOC will be responsible for providing the IETF community
         with regular overviews of the state of affairs.


      Unification: As part of this arrangement, ISOC's sponsorship of
         the RFC Editor, IAB and IESG, as well as insurance coverage
         for the IETF will be managed as part of the IASA under the
         IAOC.


      Independence: The IASA should be financially and legally distinct
         from other ISOC activities.  IETF meeting fees should be
         deposited in a separate IETF-specific bank account and used to
         fund the IASA under the direction and oversight of the IAOC.
         Any fees or payments collected from IETF meeting sponsors
         should also be deposited into this account.  This account will
         be administered by the IAD and used to fund the IASA in
         accordance with a budget and policies that are developed as
         described above.


      Support: ISOC may, from time to time, choose to transfer other
         funds into this account to fund IETF administrative projects
         or to cover IETF meeting revenue shortfalls.  There may also




Hollenbeck               Expires April 18, 2005                [Page 45]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



         be cases where ISOC chooses to loan money to the IASA to help
         with temporary cash flow issues.  These cases should be
         carefully documented and tracked on both sides.  ISOC will
         work to provide the 6 month operational reserve for IASA
         functioning described above.


      Removability: While there is no current plan to transfer the
         legal and financial home of the IASA to another corporation,
         the IASA should be structured to enable a clean transition in
         the event that the IETF community decides, through BCP
         publication, that such a transition is required.  In that
         case, the IAOC will give ISOC a minimum six months notice
         before the transition formally occurs.  During that period,
         the IAOC and ISOC will work together to create a smooth
         transition that does not result in any significant service
         outages or missed IETF meetings.  All contracts that are
         executed by ISOC as part of the IASA should either include a
         clause allowing termination or transfer by ISOC with six
         months notice, or should be transferrable to another
         corporation in the event that the IASA is transitioned away
         from ISOC in the future.  Any accrued funds, and IETF-specific
         intellectual property rights (concerning administrative data
         and/ or tools) would also be expected to be transitioned to
         any new entity, as well.


      Within the constraints outlined above, all other details of how
      to structure this activity within ISOC (as a cost center, a
      department or a formal subsidiary) should be determined by ISOC
      in consultation with the IAOC.


   3.  Workplan for Formalizing the IETF Administrative Support
   Activity


      This section proposes a workplan and schedule for formalizing the
      IETF administrative support activity (IASA) for the remainder of
      2004 and 2005.


   3.1  Workplan Goals


      This workplan is intended to satisfy four goals:


      o  Satisfy the IETF's need for support functions through 2005,
         with a careful transition that minimizes the risk of
         substantial disruption to the IETF standards process.


      o  Establish IETF community consensus and ISOC approval of a BCP
         formalizing the IASA as described in this scenario before any
         actions are taken that will have long term effects (hiring,




Hollenbeck               Expires April 18, 2005                [Page 46]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



         contacts, etc.)


      o  Make sure that decisions with long term impact, such as hiring
         the IAD and establishing contracts for administrative support,
         are made by people chosen for that purpose who will be
         responsible to the community for the effectiveness of this
         effort (the IAD and members of the IAOC) -- not by our already
         overloaded technical leadership.


      o  Within the above constraints, move as quickly as possible
         towards a well-defined administrative support structure that
         is transparent and accountable to the IETF community.


   3.2  Workplan Overview


      There are three major elements to this workplan which can, to
      some degree, take place in parallel after we establish IETF
      community consensus to pursue Scenario O:


      o  Finalizing the BCP text and getting it approved by the IETF
         community and ISOC.


      o  Selecting IASA leadership.  This includes appointing an
         interim IAOC, recruiting the IAD, and eventually appointing
         the full IAOC.


      o  Negotiating agreements with service providers.  This includes
         determining the structure and work flow of the IASA, deciding
         which portions of the IASA should be staffed via an open
         request for proposals (RFP) process, and issuing a RFP for
         those portions, as well as establishing sole source contracts
         or MOUs for other portions of the IASA.


      Each of the three items listed above is described in more detail
      in the following sections.


   3.3  Approval by the IETF Community and ISOC


      In scenario O, the IASA is formalized in a BCP that is approved
      by the IETF community and accepted by the ISOC Board of Trustees.
      There are three steps in this process:


      1.  Establishment of IETF community consensus that we should
          pursue Scenario O as defined in a joint IAB/IESG
          recommendation based on this proposal.  This consensus will
          be established through community discussion and a formal two-
          week consensus call issued by the IETF chair on the IETF
          mailing list.




Hollenbeck               Expires April 18, 2005                [Page 47]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      2.  Establishment of IETF community consensus on a BCP that
          formalizes the IASA as described.  This consensus would be
          established through public discussion, a four week IETF Last
          Call and IESG review and approval.


      3.  ISOC approval of the BCP and acceptance of ISOC's
          responsibilities as described therein.  This approval and
          acceptance would be signified by an ISOC Board resolution.


      The timeline for these three stages is rather long, but there is
      significant progress that can be made in other areas once we have
      established IETF community consensus to pursue this scenario.


   3.4  Selecting IASA Leadership


      Once we have IETF consensus to pursue this scenario, we can
      appoint an interim IAOC to begin working on the IASA transition.
      The interim IAOC could do substantial work on non-binding tasks,
      such as beginning the recruitment process for an IAD, determining
      the structure of the IASA work, issuing RFPs and negotiating
      potential agreements with service providers.  The interim IAOC
      would not be empowered to make binding agreements, but could work
      appropriate consultants and advisors to make a lot of progress
      towards determining the initial structure and work flow of the
      IASA.


      Because the IETF Nominations Commitee (NomCom) process for new
      positions will consume a lot of resources and take a long time to
      complete, we propose that the interim IAOC consist of:


      o  1 IESG selected member


      o  1 IAB selected member


      o  1 ISOC selected member


      o  The IETF Chair


      o  The ISOC President/CEO


      The IAB chair will serve as a liaison, as described above.


      The IESG and ISOC Board appointments will be expected to serve
      until the first IETF meeting of 2006, and the IAB appointment
      will be expected to serve until the first IETF meeting of 2007,
      assuming that the BCP is approved and the IAOC continues to have
      appointed members from these bodies.





Hollenbeck               Expires April 18, 2005                [Page 48]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      After all of the interim IAOC members are selected, they will
      choose an interim IAOC chair from among the appointed members.


      When the BCP is approved, if the BCP indicates that there will be
      NomCom selected IAOC members they will be chosen at that time.
      Any adjustments to appointed members based on the BCP contents
      will also be made at that time.  The IAOC will transition from
      interim to non-interim status when all non-interim members are
      seated.  A new, non-interim chair selection process will then
      commence.


   3.5  Recruiting the IETF Administrative Director


      The interim IAOC should appoint an IAD selection committee to
      recruit and select the IETF Administrative Director.  This
      committee will consist entirely of IAOC members or liaisons, and
      will, at minimum, include the IETF chair and the ISOC President.
      If the IAOC chooses, this committee could include the entire
      IAOC.


      The IAD selection committee should determine a job description
      for the IAD, in consultation with other IETF leaders and the IETF
      community.  Once the job description is established, the IAD
      selection committee should recruiting candidates for the
      position.


      Although the interim IAOC is not empowered to hire the IAD as a
      full-time employee, it might be possible for the IAOC to ask ISOC
      to engage the potential IAD as a consultant to help with other
      tasks during the interim period.


   3.6  Establishing Agreement with Service Providers


      The most important activity of the IAOC during late 2004 and
      early 2005 will be to determine the structure and work flow of
      the IASA and to establish contracts or other agreements with
      service providers to do the required work.  This work includes
      the following functions as defined in the consultant's report:


      o  Technical infrastructure


      o  Meeting management


      o  Clerk's office


      o  RFC Editor services to support  IETF standards publication


      o  IANA services to support IETF standards publication




Hollenbeck               Expires April 18, 2005                [Page 49]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



      The interim IAOC should work with IETF leaders and other
      knowledgeable members of the community to determine the structure
      and work flow required for the IASA activity and make
      corresponding adjustments to the above list, if necessary.  The
      interim IAOC can also identify which areas of IASA work should
      continue to be provided by existing IETF service providers, and
      work with those providers to establish proposed contracts or
      agreements for later approval by the non-interim IAOC.  The IAOC
      can also choose to start an RFP process for any services that
      they believe should be filled through an open RFP process.


   3.7  Establishing a 2005 Operating Budget


      Because the ISOC 2005 budgeting process will be finalized before
      the non-interim IAOC is seated, the interim IAOC should work with
      the ISOC staff and President to establish a proposed 2005
      operating budget for the IASA.  Since this will happen in advance
      of full knowledge regarding the costs of 2005 operations, it may
      be subject to significant adjustment later.


   3.8  Proposed Schedule for IASA Transition


      As described above, the three stages of the IETF community and
      ISOC approval process will take some time.  If the community
      chooses scenario O and we reach quick consensus on the details,
      an optimistic schedule for this approval would be:


      1.  IETF discussion of this proposal and other scenarios through
        1-Oct-2005.  IAB/IESG discusses this proposal with ISOC
        Board.


      2.  IAB/IESG joint recommendation issued on 8-Oct-04, including
        full BCP proposal.


      3.  Community discussion of the joint IAB/IESG recommendation
        through 22-Oct-04.


      4.  Two-week community consensus call issued on the IETF list on
        23-Oct-04 regarding rough community consensus to pursue this
        direction and appoint an interim IAOC -- extends through
        IETF 61.  IAOC selecting bodies begin search, based on
        expected community consensus.


      5.  Rough community consensus declared on 8-Nov-04 to pursue
        Scenario O and appoint the interim IAOC.


      6.  Interim IAOC seated on 15-Nov-04.  Interim IAOC begins
        interim work outlined above, including establishment of




Hollenbeck               Expires April 18, 2005                [Page 50]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



        estimated 2005 budget and IAD recruitment.


      7.  BCP text  discussed by community, IETF leadership and ISOC
        Board until we have something that represents rough
        community consensus that is acceptable to all.  We hope that
        this could be completed by 6-Dec-04.


      8.  Four week IETF Last Call issued for BCP on 6-Dec-04 --
        extends through 3-Jan-04.


      9.  Simultaneous IESG and ISOC Board approvals by 17-Jan-04.


      10.  IAD officially hired in Jan 2005.


      11.  NomCom seats IAOC members at the first IETF of 2005, moving
        the IAOC from interim to non-interim status.


      12.  Formal agreements with all service providers in-place by
        June 2005.


   4.  Security Considerations


      This document describes a scenario for the structure of the
      IETF's administrative support activities.  It introduces no
      security considerations for the Internet.


   5.  IANA Considerations


      This document has no IANA considerations in the traditional
      sense. As part of the extended IETF family, though, IANA may be
      interested in the contents.


   6.  Acknowledgements


      Most of the ideas in this document are not new, and many of them
      did not originate with the authors.  This scenario represents a
      combination of ideas discussed within the IAB, the IESG and the
      IETF Community.


      This document was written using the xml2rfc tool described in RFC
      2629 [RFC2629].


   7.  References


   7.1  Normative References


      [I-D.malamud-consultant-report] Malamud, C., "IETF Administrative
              Support Functions", draft-malamud-consultant-report-01




Hollenbeck               Expires April 18, 2005                [Page 51]

Internet-Draft           IAB-IESG AdminRest Rec             October 2004



              (work in progress), September 2004.


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


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


   7.2  Informative References


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


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


   Authors' Addresses


      Leslie Daigle
      VeriSign
      EMail: leslie at verisignlabs.com, leslie at thinkingcat.com


      Margaret Wasserman
      ThingMagic
      One Broadway, 14th Floor
      Cambridge, MA 02142 USA


      Phone: +1 617 758-4177
      EMail: margaret at thingmagic.com
      URI: http://www.thingmagic.com



















Hollenbeck               Expires April 18, 2005                [Page 52]

Internet-Draft           IAB-IESG AdminRest Rec             October 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
   ietf-ipr@ietf.org.



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.




Hollenbeck               Expires April 18, 2005                [Page 53]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/