C>> should be further investigated. In order to make progress this
C>> document recommends to make a definite choice now and go for a US
C>> based not-for-profit corporation in the state of Virginia.
C>> Further investigation would most probably delay the whole process
C>> by at least half a year.
C>>
C>> A.3 Changes to the composition of the BoT
C>>
C>> The consultant report had a proposal for Position-based Trustees,
C>> which would automatically make the IAB chair and the IETF chair
C>> voting members of the Board of Trustees (BoT) of the IETF
C>> Administrative Support Foundation. There was discussion on the
C>> IETF mailing list that those people are not selected because of
C>> their business acumen but rather for their technical leadership.
C>> We do not want to change those criteria. Another concern was
C>> that this might generate a conflict of interest as well. So this
C>> recommendation has made the IAB and IETF chairs liaisons to the
C>> BoT.
C>>
C>> Instead of making IAB and IESG chairs voting Trustees, this
C>> recommendation specifies that IAB and IESG can each select an
C>> outside (i.e. not a member of IAB or IESG) person as a voting
C>> Trustee.
C>>
C>> The selection of three (3) IETF selected Trustees has not changed
C>> in this recommendation. However, there is a concern that the
C>> current composition of the Nomcom is not tailored to selecting
C>> people for this position. So over time a different process may
C>> need to be defined for selecting those Trustees.
C>>
C>> In order to balance the ISOC and IETF people present at the BoT
C>> meetings, this recommendation also specifies that the chair and
C>>
C>> president of ISOC also function as liaisons to the BoT of the
C>> IETF Administrative Support Foundation.
C>>
C>> Appendix B. Domicile of the IETF Administrative Support Foundation
C>>
C>> A U.S. non-profit, non-member corporation is being recommended.
C>> This recommendation is based on simple considerations of
C>> expediency and pragmatism: a transition will be simplest and
C>> least risky (in the short term). The reasoning is as follows:
C>>
C>> o Administrative support for the IETF is currently enmeshed in a
C>> series of relationships with other institutions, most of which
C>> are also U.S.-chartered non-profit organizations. Any change
C>> in the institutional status of administrative support
C>> functions will require familiarity with U.S. nonprofit law.
C>> Incorporation in another country would require familiarity
C>> with those laws as well. Thus, the incorporation expenses
C>> would be higher and the process would take longer.
C>>
C>> o U.S. law has a strong concept of "nexus," which is a
C>> determination of when a foreign organization has enough
C>> relationship to U.S. law to fall under the jurisdiction of a
C>> U.S. court. Because of a long history of operating in the
C>> U.S., numerous meetings in the U.S., and the large number of
C>> U.S. residents who are participants and leaders, we feel it is
C>> likely that U.S. courts would find nexus in relation to our
C>> US-based activities, even if the IETF administrative support
C>> organization was incorporated in another country. In other
C>> words, incorporating in a country besides the U.S. does not
C>> necessarily free the support organization from any perceived
C>> vagaries of U.S. law.
C>>
C>> o Incorporating in a country other than the US may have tax
C>> implications if the Internet Society is providing funding
C>> support.
C>>
C>> o It is very likely that the IETF Administrative Support
C>> Foundation would be deemed to clearly fall under the
C>> "scientific" and "educational" grounds for classification as a
C>> tax-exempt charity under section 501(c)(3) of the IRS code, so
C>> a tax-exempt application should be quite straight-forward.
C>>
C>> o The incorporation laws of the U.S. states being considered do
C>> not require that any members of the Board of Trustees be of a
C>> certain nationality or state residency (e.g., there are no
C>> "local director" requirements). The U.S. Dept. of Commerce
C>> foreign-controlled organization reporting requirements apply
C>> only to "business enterprises", and do not apply to non-profit
C>>
C>> entities such as an IETF administrative support organization.
C>>
C>> Since this document recommends incorporating in the U.S.,
C>> Virginia is the logical pick as the state of domicile to allow
C>> the IETF administrative support organization to make use of ISOC
C>> headquarters to house its single employee (though the employee
C>> might be able to be housed at the Internet Society even if the
C>> incorporation were elsewhere, for example the ISOC Geneva
C>> office).
C>>
C>> Appendix C. Risk Analysis
C>>
C>> This scenario (as do all scenarios) has some risks. This section
C>> tries to enumerate the sort of risks that we recognize and
C>> summarizes why we think we can accept the risk or what kind of
C>> action we think we can take if the risk indeed materializes into
C>> a problem.
C>>
C>> C.1 US Domicile risks
C>>
C>> As explained in [I-D.malamud-consultant-report], incorporating in
C>> the US carries two specific risks: the perception of the IETF
C>> being a US-based organization and the potential for (or
C>> perception of) governmental interference.
C>>
C>> The IETF is an international organization. However, even now,
C>> the fact that the IETF standards processes are run in English and
C>> that many of its current support organizations are US-based
C>> leaves an impression that the IETF is too US-centric.
C>> Incorporating the new administrative entity in the US may add to
C>> that perception.
C>>
C>> Also, the IETF history is based in US federal government research
C>> and funding. Though IETF is long separated from those
C>> beginnings, even in the past few years there have been
C>> interactions between the US government and the IETF that have
C>> concerned people. Incorporating the administrative entity in the
C>> US may invite more US governmental interference in the standards
C>> activity of the IETF, or at the very least may leave the
C>> perception that the US government might get involved.
C>>
C>> Both of these are serious problems, but we think there is
C>> justification for and at least one mitigation to these risks. Of
C>> course, the primary reason to consider US incorporation is
C>> expedience (See section 4.4.1.1 of [I-D.malamud-consultant-
C>> report]). We agree that the expedience makes US incorporation
C>> worth the risk. But incorporating in multiple domiciles would
C>> significantly mitigate the risk. Assuming we go down the path of
C>>
C>> US incorporation, we would like legal counsel to advise on the
C>> possibility of incorporating in other domiciles (specifically
C>> Switzerland and The Netherlands) at a later date after US
C>> incorporation has been completed. If this is (as we suspect)
C>> indeed possible, we think this would be the best way to go
C>> forward.
C>>
C>> C.2 Non-profit status risk
C>>
C>> One of the risks pointed out to incorporation was the potential
C>> that we would not get non-profit status, and that we must
C>> therefore preserve some money in escrow for tax liability
C>> purposes. Estimates for the time it will take to get such status
C>> can be several months or even longer in some cases.
C>>
C>> It is important to point out that the tax liability is based on
C>> profits, not on gross revenues. If the IASF is only taking in
C>> enough money to cover expenses, there would be very little tax
C>> liability. However, if more revenue is brought in than is spent,
C>> for example to build up an endowment or operating reserve, that
C>> "profit" is potentially taxable if non-profit status is not
C>> granted.
C>>
C>> To mitigate this risk, the corporation could be created and non-
C>> profit status applied for first, and operation of the corporation
C>> would only begin after non-profit status was obtained. The IETF
C>> would use an interim plan for continued operations until that
C>> time. This way, no money would need to be in escrow during the
C>> process of applying for non-profit status. However, that seems
C>> an excessively cautious path to take given what appears to be the
C>> fairly clear non-profit nature of the IETF.
C>>
C>> Commencing operations while the non-profit application is being
C>> considered, but being careful about balancing revenue with
C>> expenses and keeping an appropriate escrow account seems like a
C>> prudent task. Further, any fund raising campaigns that result in
C>> shifts to the balance sheet of the IASF should be conducted
C>> cautiously until non-profit status is granted.
C>>
C>> C.3 Execution risks
C>>
C>> It is important that the execution goes well. Risks that we are
C>> aware of include:
C>>
C>> o we can’t hire a good IAD
C>>
C>> o we fail to project cash flow properly and go insolvent
C>>
C>> o we can’t cut a deal with Foretec and have no 2005 meetings
C>>
C>> o we get bad lawyers and they take too long and charge too much
C>>
C>> o isoc runs out of money and doesn’t tell us early enough
C>>
C>> In order to mitigate these problems we have a proposed work plan
C>> included in this document. It is important that we get review of
C>> this work plan by as many eyes as we can get, to make sure we
C>> have considered all the possible steps that need to be taken.
C>>
C>> C.4 Insolvency risk
C>>
C>> Improper management controls and procedures or other imprudent
C>> fiscal or administrative practices could expose the IETF to a
C>> risk of insolvency. Careful selection of trustees, a process of
C>> budget approval, and a methodical system of fiscal controls are
C>> necessary to minimize this risk.
C>>
C>> C.5 Legal risks
C>>
C>> Improper formulation of the legal framework underlying the IETF
C>> may expose the institution and individuals in leadership
C>> positions to potential legal risks. Any such risk under this
C>> plan appears to be equivalent to the risk faced by the community
C>> under the current legal framework. This risk is further
C>> mitigated by a thorough review by legal counsel, and by use of
C>> insurance coverage.
C>>
C>> The legal exposure is best minimized by a careful adherence to
C>> our procedures and processes, as defined by the Best Current
C>> Practice Series. A carefully stated process, such as the BCP
C>> documents that govern the selection of leadership positions and
C>> define the standards process are the best insurance against legal
C>> exposure, provided care is taken to stick to the process
C>> standards that have been set. Adherence to a public rule book and
C>> a fully open process are the most effective mechanisms the IETF
C>> community can use.
Appendix: Scenario O
This Appendix reproduces the contents of an Internet-Draft defining
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. Each line is
prefixed with "O>>".
O>> L. Daigle
O>> VeriSign
O>> M. Wasserman
O>> ThingMagic
O>> September 20, 2004
O>>
O>> AdminRest Scenario O: An IETF-Directed Activity Housed Under the
O>> Internet Society (ISOC) Legal Umbrella
O>>
O>> Abstract
O>>
O>> This document defines an alternative proposal for the structure
O>> of the IETF’s administrative support activity (IASA) -- an IETF-
O>> defined and directed activity that operates within the ISOC legal
O>> umbrella. It proposes the creation of an IETF Administrative
O>> Oversight Committee (IAOC) that is selected by and accountable to
O>> the IETF community. This committee would provide oversight for
O>> the IETF administrative support activity, which would be housed
O>> within the ISOC legal umbrella. In order to allow the community
O>> to properly evaluate this scenario, some draft BCP wording is
O>> included.
O>>
O>> 1. Overview of Scenario O
O>>
O>> IETF community discussions of the scenarios for administrative
O>> restructuring presented in Carl Malamud’s consultant report [I-
O>> D.malamud-consultant-report] have led to the identification of a
O>> potentially viable alternative that is not included in that
O>> report -- an IETF-defined and directed administrative support
O>> function housed under the ISOC legal umbrella (called "IASA"
O>> hereafter). This new scenario retains some properties of the
O>> original ISOC-based scenarios, Scenarios A and B. However, this
O>> new scenario aims to provide:
O>>
O>> o continued close relationship with ISOC
O>>
O>> o a clear basis from which the IETF can define (and, over time,
O>> refine) the administrative activity in terms of IETF community
O>> needs, using existing IETF/ISOC processes
O>>
O>> o an operational oversight board that is accountable to the IETF
O>> community
O>>
O>> o continued separation between the IETF standards activity and
O>> any fund-raising for standards work (within ISOC)
O>>
O>> o appropriate ISOC oversight of its standards activities funds
O>>
O>> This scenario is nicknamed "Scenario O" -- it is derived from,
O>> but does not entirely encompass, Scenario A or Scenario B.
O>>
O>> In Scenario O, the IETF administrative support function would be
O>> defined in a BCP that would be created via the IETF standards
O>> process [RFC2026] and approved by the ISOC Board of Trustees.
O>> This BCP would describe the scope of an IETF Administrative
O>> Support Activity (IASA) and would define the structure and
O>> responsibilities of the IETF Administrative Oversight Committee
O>> (IAOC), an IETF-selected body responsible for overseeing the
O>> IASA. Like the Internet Architecture Board (IAB), the IASA would
O>> be housed within the ISOC legal umbrella. The BCP would also
O>> describe ISOC’s responsibilities within this scenario, including
O>> requirements for financial accounting and transparency. A draft
O>> of this BCP is included in the next section of this document.
O>>
O>> Scenario O allows us to establish IETF control over our
O>> administrative support functions in terms of determining that
O>> they meet the community’s needs, and adjusting them from time to
O>> time using IETF processes. At the same time, it does not require
O>> that the IETF community determine, create and undertake the risks
O>> associated with an appropriate corporate structure (with similar
O>> financial infrastructure and tax-exempt status to ISOC’s) in
O>> order to solve the pressing administrative issues outlined in
O>> [RFC3716]. This proposal also defines the boundaries of the IASA
O>> so that it could be encapsulated and moved elsewhere at some
O>> future date, should that ever be desirable.
O>>
O>> 2. Draft of Administrative Support BCP
O>>
O>> This section proposes draft text for a BCP that would define the
O>> scope and structure of the IASA. Although this text would
O>> require further refinement within the IETF community, this
O>> section is intended to be clear and complete enough to allow the
O>> community to reach a well-informed opinion regarding this
O>> scenario.
O>>
O>> 2.1 Definition of the IETF Administrative Support Activity (IASA)
O>>
O>> The IETF undertakes its technical activities as an ongoing, open,
O>> consensus-based process. The Internet Society has long been a
O>> part of the IETF’s standards process, and this document does not
O>> affect the ISOC-IETF working relationship concerning standards
O>> development or communication of technical advice. The purpose of
O>> this memo is to define an administrative support activity that is
O>> responsive to the IETF technical community’s needs, as well as
O>> consistent with ISOC’s operational, financial and fiduciary
O>> requirements while supporting the IETF technical activity.
O>>
O>> The IETF Administrative Support Activity (IASA) provides
O>> administrative support for the technical work of the IETF. This
O>>
O>> includes, as appropriate, undertaking or contracting for the
O>> work described in (currently, [RFC3716] but the eventual BCP
O>> should include the detail as an appendix), covering IETF document
O>> and data management, IETF meetings, any operational agreements or
O>> contracts with the RFC Editor and IANA. This provides the
O>> administrative backdrop required to support the IETF standards
O>> process and to support the IETF organized technical activities,
O>> including the IESG, IAB and working groups. This includes the
O>> financial activities associated with such IETF support
O>> (collecting IETF meeting fees, payment of invoices, appropriate
O>> financial management, etc). The IASA is responsible for ensuring
O>> that the IETF’s administrative activities are done and done well;
O>> it is not the expectation that the IASA will undertake the work
O>> directly, but rather contract the work from others, and manage
O>> the contractual relationships in line with key operating
O>> principles such as efficiency, transparency and cost
O>> effectiveness.
O>>
O>> The IASA is distinct from other IETF-related technical functions,
O>> such as the RFC editor, the Internet Assigned Numbers Authority
O>> (IANA), and the IETF standards process itself. The IASA is not
O>> intended to have any influence on the technical decisions of the
O>> IETF or on the technical contents of IETF work.
O>>
O>> 2.1.1 Structure of the IASA
O>>
O>> The IASA will be structured to allow accountability to the IETF
O>> community. It will determine the ongoing success of the activity
O>> in meeting IETF community needs laid out in this BCP, as well as
O>> ISOC oversight of its financial and resource contributions. The
O>> supervisory body defined for this will be called the IETF
O>> Administrative Oversight Committee (IAOC). The IAOC will consist
O>> of volunteers, all chosen directly or indirectly by the IETF
O>> community, as well as appropriate ex officio appointments from
O>> ISOC and IETF leadership. The IAOC will be accountable to the
O>> IETF community for the effectiveness, efficiency and transparency
O>> of the IASA.
O>>
O>> The IASA will initially consist of a single full-time employee of
O>> ISOC, the IETF Administrative Director (IAD). The IAD will
O>> require a variety of financial, legal and administrative support,
O>> and it is expected that this support will be provided by ISOC
O>> support staff following an expense and/or allocation model TBD.
O>>
O>> Although the IAD will be a full-time ISOC employee, he will work
O>> under the direction of the IAOC. The IAD will be selected by a
O>> committee of the IAOC, consisting minimally of the ISOC President
O>> and the IETF Chair. This same committee will be responsible for
O>> periodically reviewing the performance of the IAD and determining
O>> any changes to his employment and compensation. In certain cases
O>> (to be defined clearly -- chiefly cases where the ISOC employee
O>> is determined to have contravened basic ISOC policies), the ISOC
O>> President may make summary decisions, to be reviewed by the
O>> hiring committee after the fact.
O>>
O>> The IAD will be responsible for administering the IETF finances,
O>> managing a separate bank account for the IASA, and establishing
O>> and administering the IASA budget. To perform these activities,
O>> the IAD is expected to have signing authority comparable to other
O>> ISOC director-level employees. Generally, expenses or agreements
O>> outside that authority to be approved for financial soundness as
O>> determined by ISOC policy. The joint expectation is that ISOC’s
O>> policies will be consistent with allowing the IAD to carry out
O>> IASA work effectively and efficiently. Should the IAOC have
O>> concerns about that, the IAOC and ISOC commit to working out
O>> other policies that are mutually agreeable.
O>>
O>> The IAD will also fill the role of the IETF Executive Director,
O>> as described in various IETF process BCPs. All other
O>> administrative functions will be outsourced via well-defined
O>> contracts. The IAD will be responsible for negotiating and
O>> maintaining those contracts, as well as providing any
O>> coordination that is necessary to make sure the IETF
O>> administrative support functions are properly covered.
O>>
O>> 2.1.2 IAD Responsibilities
O>>
O>> The day to day responsibilities of the IAD will focus on managing
O>> contracts with the entities providing the work supporting the
O>> IETF technical activity.
O>>
O>> The IAD will provide regular (monthly and quarterly) reports to
O>> the IAOC and ISOC.
O>>
O>> All contracts will be negotiated by the IAD (with input from any
O>> other appropriate bodies), and reviewed by the IAOC. The
O>> contracts will be executed by ISOC, on behalf of the IETF, after
O>> whatever review ISOC requires (e.g., legal, Board of Trustees).
O>>
O>> The IAD will prepare an annual budget, which will be reviewed and
O>> approved by the IAOC. The IAD will be responsible for presenting
O>> this budget to the ISOC Board of Trustees, as part of ISOC’s
O>> annual financial planning process. The partnering is such that
O>> the IAOC is responsible for ensuring the suitability of the
O>> budget for meeting the IETF community’s needs, but it does not
O>> bear fiduciary responsibility; the ISOC board needs to review and
O>>
O>> understand the budget and planned activity in have enough detail
O>> of the budget and proposed plans to properly carry out its
O>> fiduciary responsibility.
O>>
O>> 2.1.3 IAOC Responsibilities
O>>
O>> The role of the IAOC is to provide appropriate input to the IAD,
O>> and oversight of the IASA functioning. The IAOC is not expected
O>> to be regularly engaged in IASA work, but rather to provide
O>> appropriate approval and oversight.
O>>
O>> Therefore, the IAOC’s responsibilities are:
O>>
O>> o Select the IAD, as described above.
O>>
O>> o Review the IAD’s financial reports, and provide approval of
O>> the IAD’s budget proposals in terms of fitness for IETF