Network Working Group                                          L. Daigle
Internet-Draft                              Thinking Cat Enterprises LLC
Intended status: Informational                              June 5, 2017
Expires: December 7, 2017

               After the first decade: IASA Retrospective


   The IETF Administrative Support Activity was formally established and
   undertaken as a project of the Internet Society in 2005.  In the
   following 10+ years, the IETF has grown and changed, as have the
   responsibilities that fall to the IASA.

   This document reflects on some of those changes and the implications
   within the IASA structure, providing some areas for further
   discussion to consider evolving the IASA and the IETF/ISOC

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

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

   This Internet-Draft will expire on December 7, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Daigle                  Expires December 7, 2017                [Page 1]

Internet-Draft             IASA Retrospective                  June 2017

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Forming the IASA  . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Evolution of IASA breadth . . . . . . . . . . . . . . . . . .   4
     3.1.  IASA coverage in 2005 . . . . . . . . . . . . . . . . . .   4
     3.2.  IASA coverage in 2017 . . . . . . . . . . . . . . . . . .   5
   4.  Evolution of Internet Society Partnership . . . . . . . . . .   8
   5.  Issues and Potential Next Steps for the IASA structure  . . .   9
   6.  Closing remarks . . . . . . . . . . . . . . . . . . . . . . .  12
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   In April 2005, BCP 101 ([RFC4071]) was published, formally creating
   the IETF Administrative Support Activity (IASA).  At the end of an
   intense community discussion, the IASA was formed as an activity
   housed within the Internet Society (ISOC), and BCP 101 defined the
   roles of the IETF Administrative Oversight Committee (IAOC), and the
   IETF Administrative Director (IAD).  Together, these roles have
   defined responsibilities for IETF's fiscal and administrative

   With the newly established IASA, the IETF was in a position to
   formalize several activities that had been undertaken by other
   organizations, on behalf of the IETF.  This allowed the IETF take
   responsibility of those operations.  Through the 10+ years since the
   inception of IASA, the operations and responsibilities have, however,
   grown and requirements have evolved.  Nor has the world stood still
   -- at the same time, the Internet Society has grown and taken on a
   broader role in Internet governance discussions and global

   This document reflects on some of those changes and the implications
   within the IASA structure, providing some areas for further
   discussion to consider evolvingthe IASA and the IETF/ISOC

Daigle                  Expires December 7, 2017                [Page 2]

Internet-Draft             IASA Retrospective                  June 2017

2.  Forming the IASA

   In 2003, the IETF and IAB Chairs formed an IAB Advisory Committee
   (AdvComm) to "review the existing IETF administration relationships
   (RFC Editor, IETF Secretariat, etc.) and propose IETF management
   process or structural changes that would improve the overall
   functioning of the IETF" ([RFC3716]).  The AdvComm identified several
   stressors to the efficient and effective operation of the IETF
   related to financial support, informality of relationships, and
   opaqueness of decision making in administrative matters.

   To address the identified stressors, the AdvComm developed a set of
   requirements for any eventual solution:

   o  Resource Management

      *  Uniform Budgetary Responsibility (autonomy)

      *  Revenue Source Equivalence (ability to consider all sources of
         income and apply them as appropriate across all functions,
         which was not possible when the Internet Society was funding
         the RFC Editor function and CNRI/Foretec was supporting the
         Secretariat function

      *  Clarity in Relationship with Supporting Organizations (clear
         contractual relationships between the IETF and each supporting

      *  Flexibility in Service Provisioning (ability to make choices)

      *  Administrative Efficiency (avoiding duplicate overhead across
         multiple organizations)

   o  Stewardship (looking after the future as well as the present)

      *  Accountability for Change (i.e., accountability to the IETF

      *  Persistence and Accessibility of Records

   o  Working Environment

      *  Service Automation (for administrative tasks and IETF
         information flow management)

      *  Tools (development of more tools for IETF support)

Daigle                  Expires December 7, 2017                [Page 3]

Internet-Draft             IASA Retrospective                  June 2017

   The IETF followed up the AdvComm recommendations with discussions of
   possible administrative structures to support the IETF and ensure its
   continued ability to focus on its mission of making the Internet work
   better.  The eventual result was the IETF Administrative Support
   Activity (IASA), defined in BCP101 ([RFC4071]) and formed in 2005.

   The selected form of the IASA (as "an activity of the Internet
   Society") meant that the IETF could focus on building out the pieces
   of administration necessary to carry out its standards activities,
   without having to instantly build general corporate overhead.  That
   is, the Internet Society was specifically tasked with providing any
   additional needed clerical or financial support, and was identified
   as solely responsible for obtaining sponsors for the IETF.  The
   latter also was intended to provide arms-length distance between
   corporate donors and direction of the IETF's activities: the IETF
   could not be "bought".

3.  Evolution of IASA breadth

3.1.  IASA coverage in 2005

   In order to understand the evolution of the IASA, it is important to
   describe the baseline -- what the IASA was when it was first formed.

   o  Secretariat -- the IETF Secretariat function was carried out by an
      organization that had been a subsidiary of CNRI (which had
      collected meeting fees and provided Secretariat services until the
      creation of the IASA).  In 2005, key personnel migrated to Neustar
      to carry out the Secretariat function under contract with the
      Internet Society (for IASA).  This gave the IETF full control and
      responsibility for picking meeting locations, as well as setting
      and collecting meeting fees.

   o  Meeting planning -- A first priority was to establish meeting
      dates, locations and contracts more than a year in advance, to
      improve contract negotiating positions, costs, and provide clarity
      for attendee planning.  (Historical data point: the early 2004
      Seoul IETF meeting did not have a hotel contract booked in
      December of 2003).

   o  RFC Editor -- The RFC Editor function had been handled at USC/ISI
      for many years (since Jon Postel moved to USC/ISI from UCLA in
      1978).  In the years leading up to the formation of the IASA, The
      Internet Society had provided funding to ISI in the form of a
      contract to carry out the work.  With the creation of the IASA,
      this contract was folded into the ISOC/IASA support.  See
      [RFC5540] for more details.

Daigle                  Expires December 7, 2017                [Page 4]

Internet-Draft             IASA Retrospective                  June 2017

   o  IANA -- by the time the IASA was created in 2005, ICANN was well-
      established and had been carrying out the Internet Assigned Names
      Activity since 1998.  The IETF had agreed on a Memorandum of
      Understanding with ICANN on the handling of protocol parameters
      for IETF standards ([RFC2860]), but it did not specify levels of
      service or practical terms of agreement.  (See more IANA detail at ).

   o  Tools -- the Secretariat had developers on staff who had built
      tools to support the workflow of the IETF (e.g., liaison manager).
      The software was proprietary, and IETF community programmers had
      no access or insight.  At the same time, the IETF community being
      what it is, there were community-driven tools that were built up
      in an open source fashion.  These were completely separate and
      separately maintained.

   o  Meeting network support -- in 2005, standard meeting hosting
      agreements included providing network connectivity to the meeting
      hotel.  This might have extended to include a terminal room for

   o  Staff -- the IASA established that the IETF would have one full-
      time employee (officially an employee of ISOC, as part of the
      administrative arrangements).  That one employee was the IETF
      Administrative Director.

   o  The IAOC -- established as an administrative oversight body, the
      IAOC was established with 3 voting and one non-voting ex officio
      members (IETF Chair, IAB Chair, ISOC CEO and IAD, respectively),
      one member appointed by the ISOC Board, and 4 appointees from the
      community (2 from NomCom, 1 each appointed by the IESG and IAB).

3.2.  IASA coverage in 2017

   A little more than a decade later, things have changed substantially
   in terms of the coverage of the responsibilities of the IASA.

   o  Secretariat -- the IASA put the Secretariat contract out for
      competitive bid in 2007, establishing a contract with professional
      association management company (Association Management Services)
      in 2008, with key personnel moving to AMS.

   o  Meeting planning -- IETF meeting locations are now mostly
      contracted two to three years in advance.  At the same time, IETF
      leadership and participants' expectations of meeting locations and
      venues have evolved.  The IETF now aims to meet regularly in Asia,
      as well as Europe and North America.  Meeting layout requirements
      have evolved.  The topic is sufficiently complex that the MTGVENUE

Daigle                  Expires December 7, 2017                [Page 5]

Internet-Draft             IASA Retrospective                  June 2017

      working group was created in 2016 to develop an IETF consensus
      document on meeting venue requirements.

   o  RFC Editor -- the IAB split the RFC Editor function into separate
      functions and these have been contracted out -- RFC Series Editor;
      RFC Production, Independent Series Editor.  These are collectively
      overseen by an IAB-based, community-populated advisory board
      (RSOC).  The RFC Series continues to grow in terms of number of
      documents published, and new features (e.g., ISSNs) and other
      formats supported for the documents.  (N.B.: The IASA is not
      responsible for defining or driving any of that growth -- the IASA
      role is limited to writing and managing the contracts for the work
      defined by the IAB and RSOC).

   o  IETF Trust -- the IETF Trust was formed to hold IETF-related IPR
      (marks, copyright, domain name registrations) after the IASA was
      established.  It was created in late 2005, by agreement between
      the Corporation for National Research Initiatives (CNRI) and the
      Internet Society (ISOC) as the Settlors, the IETF and the initial
      trustees (IAOC members at the time).  One provision of the Trust
      Agreement was that, prior to July 1, 2010, the Trust could be
      amended only by unanimous written consent of both the Settlors and
      two-thirds of the Trustees.  The Trust Agreement includes a list
      of the initial assets contributed to the Trust, and they generally
      included the IETF and IETF SECRETARIAT marks, relevant domain
      names, and the content of the databases used to do the IETF's work
      (including then-current Internet-Drafts).  RFC 4371 ([RFC4371])
      updated RFC 4071 (BCP 101) to reflect the fact that there would be
      an IETF Trust to hold the rights to IETF-relevant intellectual
      property.  Additionally, RFC 4748 updated RFC 3798 (the first
      organization of IETF rights in contributions), and that RFC was
      updated by RFC 5378 ([RFC5378]) to unify the IETF rights
      definitions and Trust structure.

   o  IANA -- the IETF Trust holds the IANA IPR (IANA trademark and and related domain name registrations).  We now formally
      contract with ICANN to do the work (which is an update over the
      SLA that was established in the intervening decade)

   o  Tools -- the IETF's software tools are still a mix of things
      developed spontaneously by community members and specific work put
      out for hire.  The latter is now handled through RFPs, and care is
      made to ensure that tools upon which the community is dependent
      can be maintained and supported for as long as needed.

   o  Meeting network support -- network support for IETF meetings has
      grown in scope and expectation of uniformity of services in
      meetings across the globe.  This now encompasses a large scale

Daigle                  Expires December 7, 2017                [Page 6]

Internet-Draft             IASA Retrospective                  June 2017

      combination of NOC volunteers, hired support, in-kind donations of
      equipment and specialized support for remote participation.  The
      following list of current meeting network support expectations
      highlights not only the complexity of the support, but also the
      increased issues in funding, contract management, and implications
      for hotel contracts that land on the IASA plate:

      *  Support for pre/post events (ISOC BOT, Hackathon, etc.)

      *  Ubiquitous wireless with multiple SSIDS

      *  Hotel wireless with IETF SSIDs -- sometimes multiple venues

      *  V6 enabled throughout

      *  Increasing remote participation support

      *  Support for experiments

      *  Bits and Bites

      *  Core network management (ASN/ip addresses/DNS/monitoring/etc.)

      *  Storage, management and shipping of IETF-owned equipment (in-
         kind donations)

   o  Comms -- Beyond simply having a reliable website, the IETF's use
      of "communications" has extended in recent years.  This ranges
      from updates in the website itself, to work with social and
      industry media and messaging to position the IETF in relevant
      global discussions.  Of late, the IETF has used the services of
      ISOC's professional communications staff, helping deal with some
      of the publicly visible issues such as the impacts of surveillance
      revelations or the IANA transition.  Starting from 2017, this
      support is for the first time part of the IETF budget, whereas
      previously the activity and its funding not visible at that level

   o  Sponsorship and funding -- even as the IETF retains its basic
      operational structure, the industry around it changes.  The last
      decade has seen increased costs of meetings and productions, and a
      greater reliance on corporate funding.  Where once the IETF relied
      on individual community members convincing their companies to step
      up for the next meeting, the IETF now plans its meetings several
      years in advance and needs to align funding expectations
      accordingly.  It takes expertise to update funding models, build
      and implement programs for securing industry sponsorship.  BCP 101
      formally identifies that the IETF is not to fundraise on its own;
      indeed, the IASA is not responsible for the sponsorship

Daigle                  Expires December 7, 2017                [Page 7]

Internet-Draft             IASA Retrospective                  June 2017

      development (just managing its impact on the IASA budget).  The
      IETF sponsorship models have evolved, and in 2017 they consist of
      ISOC memberships, the Global Host program, meeting hosts and other
      meeting sponsors, the Hackathon and Bits-n-Bites sponsorships, and
      the IETF Endowment.  The team helping with sponsors involves a
      primary sponsorship person at ISOC, the IAD, the Secretariat, as
      well as frequent help from the IETF leadership and their

   o  Staff -- the IASA still has exactly one permanent employee -- the
      IETF Administrative Director.

   o  IAOC -- the structure of the IAOC remains unchanged since the
      IASA's inception.

   o  IAOC Committees -- recognizing the need for more eyes and
      specialized attention for different branches of work requiring
      IAOC oversight, the IAOC expanded its support by creating
      committees.  Committees are dynamic -- formed and closed as needed
      to focus on key areas of the moment, and often include members
      from outside the IAOC.  The committees do the heavy lifting on
      background work for IAOC decisions.  The IAOC is nonetheless
      responsible for its decisions based on committee output and
      recommendations.  Example committees include:

      *  Finance Committee: reviews financial reports prepared by the
         IAD (with support from ISOC Accounting staff), discusses budget
         proposals before going to the whole IAOC.

      *  Meetings Committee: reviews candidate IETF meeting venues and
         proposes selections for approval by the IAOC.

   Further details about IAOC Committees, including the current list of
   committees and membership, is available from
   committees.html .

4.  Evolution of Internet Society Partnership

   When the IASA was formally created, the Internet Society had only
   recently established a substantial and steady financial basis
   (through its Public Interest Registry project).  "Internet
   Governance" was a relatively new global policy discussion topic, and
   the Internet Society provided a much needed voice from the Internet
   technical community.  It had a very small staff (10 staff listed in
   the 2004 annual report), a broad footprint of Chapters around the
   globe, and a few, focused projects undertaken by staff.

Daigle                  Expires December 7, 2017                [Page 8]

Internet-Draft             IASA Retrospective                  June 2017

   Since 2005, the Internet Society has expanded significantly,
   organizationally (reaching 90+ staff) and in its presence on the
   world stage of Internet policy, development and technology.  While it
   remains committed to its role of support of the IETF, it becomes
   increasingly challenging to maintain (and explain) the reality that
   the Internet Society and the IETF are two separate organizations,
   with independent roles and perspectives, while everything from the
   hotel contracts to the MoU with ICANN (for IANA services) is signed
   by the Internet Society (as the legal entity for the IETF).

5.  Issues and Potential Next Steps for the IASA structure

   Here are some issues that could use addressing in updates to the IASA

   o  The most general question: the effort involved in IASA-related
      tasks has considerably risen during its existence, and the current
      organisational arrangements may no longer be the perfect match for
      the task.  Are changes needed in the organisation?

   o  The 2017 IETF is more diverse and more international than it was
      previously.  Arranging meetings is a particular area that today
      demands more work.  In addition, the IETF community periodically
      raises new requirements that must be met by venues.  Local
      conditions, invitation and visa processes, and hotel and network
      facilities demand effort.  While the IAOC has made some changes
      regarding site selection, and ongoing IETF working group efforts
      will help specify requirements more clearly, this remains a
      sensitive and critical area.

   o  Sponsorship and hosting issues in particular are increasingly
      difficult for meetings.  While some operational changes are being
      made to the sponsorship opportunities for the IETF, the IETF would
      probably be served well by moving more towards a funding model
      that is independent of the meetings.

   o  In the last couple of years, the IAOC and ISOC have worked to
      ensure that contributions such as staff time and other support are
      properly accounted for in the IETF budget.  This increases
      transparency and awareness.  However, even with this progress, the
      actual work is still organised within two separate organisations,
      which makes it hard to have one decision point regarding where and
      how to spend resources.

   o  Clarity of IETF representative communications: who is responsible
      for determining the structure and message of the IETF's place on
      the world stage, to potential sponsors, etc.  The IASA role is to
      ensure there are appropriate resources (expertise, materials), but

Daigle                  Expires December 7, 2017                [Page 9]

Internet-Draft             IASA Retrospective                  June 2017

      it is not currently clear to whom those should be provided, and
      therefore, what the specification of the task is.

   o  Representation for sponsorship: The Internet Society is formally
      responsible for IETF fund raising (per BCP101).  The IASA is
      responsible for aligning promised sponsor benefits with meeting
      realities, and tracking the overall budget.  Currently, the IASA
      relies on the IETF Chair to take responsibility for managing
      discussions required to vet any possible changes in
      representation, but perhaps there are other models that would
      scale more effectively.

   o  Clarity of role in the IETF Endowment: related to the question of
      determining the shape of representative communications materials,
      potential IETF Endowment contributors ask for a perspective of
      where the IETF is going in the next decade, and how Endowment
      money might be used.  The future of the IETF is not for the IASA
      to decide, but the IAOC's role in building and managing the IETF
      budget make it a natural place to look for some of these answers.
      This highlights three problems:

      *  It is ISOC that is pitching the IETF Endowment (because ISOC is
         a legal organization; because the IETF is not supposed to do
         fundraising, per BCP 101) and potential funders can be confused
         why the IETF is not speaking directly.

      *  The obvious question, "Why doesn't ISOC just pay for it?" --
         which stems from a lack of perception of the different world
         roles of the two organizations.

      *  In preparing the pitch for the IETF Endowment, ISOC naturally
         turns to the "money manager" of the IETF to get answers to
         questions, and it is confusing when the IAOC can neither
         provide answers or identify the suitably responsible part of
         the organization.

      A better plan would be to have clarity about who the IETF thinks
      is responsible for such discussions, and messaging that more
      clearly to the rest of the world.

   o  Clarifying, and as necessary, updating the relationship between
      the IETF and the Internet Society: in establishing the IASA in
      2005, the IETF and the Internet Society determined the best
      relationship was to have the IASA homed as an Internet Society
      project.  Is that still the best arrangement for all concerned?

   o  Staffing: The IASA was created with one full-time IETF staff
      person -- the IETF Administrative Director.  Some questioned

Daigle                  Expires December 7, 2017               [Page 10]

Internet-Draft             IASA Retrospective                  June 2017

      whether it would even be a full-time job.  It always has been at
      least a full-time job, and over the years the shortfall of
      resources has been at least partially addressed by contributions
      of Internet Society staff resources that are available (e.g., see
      notes above about the IETF Communications plans, etc).  The
      problems are mismatch of talent, (lack of) resources for the IETF,
      and unplanned impact on resources for the Internet Society that
      has its own projects to pursue.  It would be better that the IETF
      should just manage its own staffing needs

   o  IAOC membership: The IAOC has 4 ex officio members (IETF Chair,
      IAB Chair, ISOC CEO, IETF Administrative Director (non-voting)),
      and 5 appointed members.  One of 5 members is appointed by the
      ISOC Board of Trustees, and is traditionally expected not to stand
      for IAOC Chair.  That leaves a small pool from which to select the
      IAOC Chair (and the IETF Trust Chair, usually a different person),
      and very few (2, by the time you've appointed Chairs) "worker
      bees" for the IAOC.  This is a functional model for handling those
      review issues that can be put to the IAOC by the IAD and the
      Committees and addressed in the IAOC monthly teleconference.
      There is zero bandwidth for deep review or engagement on any
      topic.  Whle the IAOC was intended only ever to be oversight, and
      the IAD does not need a huge flock of "bosses", the fact that this
      shallowness has become a friction point suggests that something
      structural needs to change, either within the IAOC or the IASA

   o  IETF Trust Trustees: Since its inception, the Trustees of the IETF
      Trust have been defined as the current sitting IAOC members.
      While the Trust was being established, there was value in keeping
      the process of identifying Trustees simple, especially if the
      Trust did not persist beyond its minimum lifespan (July 1, 2010).
      The Trust has become an integral part of the IETF support system
      and seems to be here to stay.  It could be useful to appoint
      Trustees through some process independent of appointing IAOC
      members, to reduce the level of role and committee overload
      described elsewhere, and also to make the separation between the
      Trust and the IETF clearer and better formalized.

   o  IETF participant engagement in IASA: Most participants in the IETF
      demonstrate little interest in the work done by IASA, including
      how things are administered and paid for, unless something goes
      "wrong".  (Consider the consistent lack of interest and short
      volunteer lists for open IAOC positions, contrasted against the
      e-mail evaluations of meeting venues at each and every IETF
      meeting.  Hmmm.  Perhaps the latter dissuades potential
      volunteers?!).  This makes it difficult for the IAOC to identify,
      pursue, or suggest changes that might ultimately be in the

Daigle                  Expires December 7, 2017               [Page 11]

Internet-Draft             IASA Retrospective                  June 2017

      organizations long term (or, sometimes, even short term) interest.
      More consistent engagement might help.

6.  Closing remarks

   The creation of the IETF was a step in formalizing discussions among
   engineers who were interested in the development of the
   specifications of the technology to drive the Internet.  Creating the
   IASA was a logical step in bringing together the various
   administrative functions that had been first offered by different
   organizations involved in the work.  As the world continues to evolve
   around the IETF and the Internet, perhaps it is time for another
   review of where we are and whether our administrative formalizations
   fit the needs of the work at hand.

7.  Acknowledgements

   Special thanks to Harald Alvestrand, Brian Carpenter, Dave Crocker,
   Lucy Lynch and Greg Wood for review and comments on an earlier
   version of the document.

8.  References

8.1.  Normative References

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

   [RFC4071]  Austein, R., Ed. and B. Wijnen, Ed., "Structure of the
              IETF Administrative Support Activity (IASA)", BCP 101,
              RFC 4071, DOI 10.17487/RFC4071, April 2005,

   [RFC5378]  Bradner, S., Ed. and J. Contreras, Ed., "Rights
              Contributors Provide to the IETF Trust", BCP 78, RFC 5378,
              DOI 10.17487/RFC5378, November 2008,

8.2.  Informative References

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

Daigle                  Expires December 7, 2017               [Page 12]

Internet-Draft             IASA Retrospective                  June 2017

   [RFC4371]  Carpenter, B., Ed. and L. Lynch, Ed., "BCP 101 Update for
              IPR Trust", BCP 101, RFC 4371, DOI 10.17487/RFC4371,
              January 2006, <>.

   [RFC5540]  Editor, RFC., "40 Years of RFCs", RFC 5540,
              DOI 10.17487/RFC5540, April 2009,

Author's Address

   Leslie Daigle
   Thinking Cat Enterprises LLC


Daigle                  Expires December 7, 2017               [Page 13]