Network Working Group S. Hollenbeck, Ed.
Request for Comments: 4089 IAB and IESG
Category: Informational May 2005
Network Working Group S. Hollenbeck, Ed.
Request for Comments: 4089 IAB and IESG
Category: Informational May 2005
IAB and IESG Recommendation for IETF Administrative Restructuring
IAB和IESG关于IETF行政重组的建议
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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. The IETF Chair declared that the IETF had consensus to follow this recommendation on November 11, 2004. Further work has been done to revise and refine the structures proposed. The recommendation is being published for the record.
本文件描述了互联网架构委员会和互联网工程指导小组就互联网工程工作队的行政重组提出的联合建议。IETF主席宣布IETF已于2004年11月11日达成共识，同意遵循该建议。已开展进一步工作，修订和完善拟议结构。该建议正在公布备案。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Process That Produced This Recommendation . . . . . . . . 2
3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Arguments That Had Particular Weight in the Discussions . . . 4
4.1. Focusing on Scenarios C and O . . . . . . . . . . . . . 4
4.2. Why We Chose Scenario O . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
Appendix: Scenario C . . . . . . . . . . . . . . . . . . . . . . . 7
Appendix: Scenario O . . . . . . . . . . . . . . . . . . . . . . . 37
Informative References . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Process That Produced This Recommendation . . . . . . . . 2
3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Arguments That Had Particular Weight in the Discussions . . . 4
4.1. Focusing on Scenarios C and O . . . . . . . . . . . . . 4
4.2. Why We Chose Scenario O . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
Appendix: Scenario C . . . . . . . . . . . . . . . . . . . . . . . 7
Appendix: Scenario O . . . . . . . . . . . . . . . . . . . . . . . 37
Informative References . . . . . . . . . . . . . . . . . . . . . . 54
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.
互联网工程任务组（IETF）需要行政支持功能。2003年和2004年的辩论和对话使人们相信，提供这些职能的方式需要改变。
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.
本文件给出了互联网工程指导小组（IESG）和互联网体系结构委员会（IAB）关于变更过程下一步应采取的措施的建议，以及本建议背后的一些背景和理由。
During several months in 2004, the Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG) worked together to consider several different options for restructuring 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].
在2004的几个月内，互联网架构委员会（IAB）和互联网工程指导小组（IESG）共同考虑了几种不同的选项来重组互联网工程任务组（IETF）的管理功能。这项工作的目标是提出建议，供IETF社区考虑和批准。RFC 3716[1]中描述了这项工作的基本原理。由一位名为“IETF行政支持功能”的顾问编写的报告中提供了许多背景工作和一些供社区考虑的详细建议[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:
顾问的报告包括了几种可能的行政重组方案（称为方案A、B、C和D）。随着IETF社区内的讨论，很明显，一些场景的特点似乎比其他场景更有希望，但我们没有足够的具体建议将意见具体化为行动共识。IESG和IAB的成员承担了对其中两个场景进行更完整描述的任务。他们是：
o Scenario C (section 4.4 of the report) describes when "administrative support functions for the IETF are legally housed in a focused, incorporated institution" with close ties to the Internet Society (ISOC). Scenario C is included here as the first appendix.
o 场景C（本报告第4.4节）描述了“IETF的行政支持职能合法地安置在一个与互联网协会（ISOC）有密切联系的重点、法人机构中”的情况。场景C作为第一个附录包含在这里。
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. Scenario O is included here as the second appendix.
o 一种称为场景O的新场景，包括从场景A和场景B（本报告第4.2节和第4.3节）衍生的功能，重点是ISOC/IETF关系的形式化，同时在ISOC中包含IETF的行政支持功能。场景O作为第二个附录包含在这里。
These descriptions were not intended to close off discussion of other scenarios, but to focus discussion on what appeared to be two 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.
这两个场景都以邮件形式呈现给IETF社区（场景C[3]，场景O[4]），并发送给IETF讨论列表。IETF参与者的意见虽然在这一问题上存在很大分歧，但似乎表明他们倾向于将场景O作为“低风险操作”，但一些参与者表示，他们觉得无法给出知情的意见，不同意该过程，或宣布该主题超出其能力范围。这次讨论吸引了大约40名与会者，他们在名单上做出了贡献。
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.
IETF主席随后要求对IETF的意见进行非正式投票。有兴趣参与调查的人被引导到一个网站上，在那里可以看到他们的意见，包括他们是否想陈述意见。原始民意调查结果[5]也通过发送至IETF讨论列表的邮件通知与社区共享。
The poll sparked additional discussion on the list, and not all participants 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 O than on other scenarios. The IESG and IAB members believe that Scenario O can be a workable basis for 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.
这项调查引发了名单上的更多讨论，并非所有参与者都同意调查方法。尽管如此，IESG和IAB成员认为，与其他情景相比，基于情景O的社区支持变革的迹象更为强烈。IESG和IAB成员认为，方案O可以成为进一步进展的可行基础，即使它不是所有成员的首选方案。综上所述，这导致了以下IESG/IAB建议。
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:
IAB和IESG的集体建议于2004年10月8日星期五通过发送至IETF邮件列表的邮件通知[6]提交给IETF社区：
"IETF folks,
“IETF各位，
The IESG and IAB have been considering the input from the IETF community on the next steps going forward in IETF administrative restructuring.
IESG和IAB一直在考虑IETF社区对IETF行政重组下一步工作的投入。
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.
我们似乎清楚地看到，社区大多将情景O视为风险较低的情景，而这种情景使我们成功完成我们必须做的事情的可能性最大。
Based on this, the IESG and the IAB make the following recommendation:
基于此，IESG和IAB提出以下建议：
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.
我们建议IETF继续实施方案O，并理解需要进一步的工作来定义IETF、IAOC和ISOC机器人在该方案下的角色和责任。
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.
场景O说明的“BCP部分”将被抽出并作为互联网草稿发布。如果可能的话，我们希望在11月IETF会议之前，向IETF社区提供这一描述，以便进行正式的最后一次通话。
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.
此外，正如上面的建议所指出的，我们需要更详细地确定系统将如何运作——谁作出决定，谁接受这些决定，以及可能需要什么样的冲突解决机制，等等。IAB和IESG正在起草一份文件，详细描述每个参与者各自的角色和责任。我们将很快在互联网上发布这一草案。
We will continue to work intensely on this!"
我们将继续为此而努力！"
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
IETF列表在顾问报告[2]中给出了四种场景，应在完整上下文中阅读。在标语形式中，它们可能被呈现为
o A: Leave it to ISOC.
o A:交给ISOC吧。
o B: Increase IETF control of ISOC, and use ISOC to do it.
o B：增加IETF对ISOC的控制，并使用ISOC来实现。
o C: Isolate the functions, let ISOC gather money, share control.
o C：隔离功能，让ISOC集资，分享控制权。
o D: Cut the IETF off from ISOC and do it ourselves.
o D：切断ISOC的IETF，我们自己做。
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.
在名单上，似乎很少有人对情景D中设想的“我们”（对于“我们”的某些版本）可以“自己做”的想法感到满意。也有人对情景C相关的风险感到相当担忧，特别是在金融稳定方面，人们意识到的问题的危险会导致赞助者扣留资金，从而引发问题，即使没有其他原因。场景C向那些担心ISOC和IETF社区在未来某个日期可能存在利益冲突的人发出了强烈的声音——“我们不知道ISOC会变成什么”是胶囊摘要。
Scenario A worried people because it did not seem to acknowledge the IETF community's ability to determine if its needs were being met and what could be done 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 Scenario O, 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. Its name is derived from the classification of blood types -- "neither A nor B".
场景A让人们感到担忧，因为它似乎没有承认IETF社区有能力确定其需求是否得到满足，如果没有得到满足，可以做些什么。“用ISOC替换现有的有问题的结构”这句话也许是一个总结。然而，场景B中IETF社区直接参与ISOC运作的可能机制列表被认为是不可接受的，或者与ISOC的全部活动范围不平衡。IAB和IESG的成员开发了场景O，这是一种将管理活动置于ISOC内的解决方案场景，但旨在为IETF提供一种手段，以监督和控制ISOC内的具体活动。它的名字来源于血型分类——“既不是A也不是B”。
Thus, the decision to focus on C and O as "alternatives to be worked out in detail" was made.
因此，决定将重点放在C和O上，作为“有待详细制定的备选方案”。
Capsule summary: It might be possible to make either scenario work. But Scenario O could be made to work faster, and less painfully.
胶囊概述：这两种方案都可能奏效。但场景O可以更快、更轻松地工作。
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.
ISOC董事会非常担心情景C会使筹资更加困难，这必然会影响其支持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). However, a corporation that did only administrative support functions, as scenario C envisioned, would have more problems. In all cases, the process of determining this would take months, and could be dragged out longer if we were unlucky.
名单上对新公司的税务地位问题进行了长时间的辩论；法律顾问指出，开展IETF工作的公司（场景D）很容易被归类为501（c）（3）（美国国税局（IRS）条例定义的非营利公司类型）。然而，如场景C所设想的那样，一家只执行管理支持功能的公司将面临更多的问题。在所有情况下，确定这一点的过程都需要几个月，如果我们运气不好，可能会拖得更长。
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:
社区反馈除了为讨论提供了许多结构合理、论证充分的观点外，还有力地表明了在何处可以达成IETF共识：
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 似乎有可能获得IETF对场景O的共识；支持方案C的人表示，他们“可以接受”替代方案。
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.
o 围绕场景C达成IETF共识似乎要困难得多；许多反对它的人表示，他们坚信这是IETF的错误选择。
The IETF is based on 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.
IETF基于这样一个理念，即协商一致的过程在起作用时会做出合理的决定。我们得出结论，社区共识的明显漂移是IESG/IAB建议的合理基础。
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.
本文件不要求IANA采取任何行动。然而，IETF行政重组过程可能会影响IETF与IANA之间关系的管理方式。
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.
本文件未介绍互联网运行的任何安全注意事项。然而，行政重组给IETF的未来带来了几个方面的风险。本文件所附情景中描述了风险及其缓解策略。
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.
本文件是IAB和IESG成员的集体工作。撰写本文时，IAB的成员包括伯纳德·阿博巴、哈拉尔·阿尔韦斯特朗、罗布·奥斯汀、莱斯利·戴格尔、帕特里克·法茨特罗姆、萨利·弗洛伊德、马克·汉德利、鲍勃·欣登、杰夫·休斯顿、伊藤俊一郎·哈加诺、埃里克·雷索拉、皮特·雷斯尼克和乔纳森·罗森伯格。撰写本文时，IESG的成员包括哈拉尔·阿尔维斯特朗、史蒂夫·贝洛文、比尔·芬纳、特德·哈代、斯科特·霍伦贝克、罗斯·霍斯利、大卫·凯森斯、艾利森·曼金、托马斯·纳腾、乔恩·彼得森、玛格丽特·瓦瑟曼、伯特·维恩和亚历克斯·齐宁。
The administrative restructuring effort cannot succeed without community support and participation. Thus, the IAB and IESG wish to acknowledge the collective contributions of members of the IETF community who have participated in the discussion of this topic.
没有社区的支持和参与，行政结构改革的努力就不可能成功。因此，IAB和IESG希望感谢参与本主题讨论的IETF社区成员的集体贡献。
Appendix: Scenario C
附录：情景C
This Appendix reproduces the contents of an Internet-Draft defining 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. Each line is prefixed with "C>>".
本附录复制了2004年9月20日发布的定义情景C的互联网草案的内容。已从该副本中删除目录，并对文本进行了重新格式化，以符合IETF出版指南的要求。每行的前缀都是“C>>”。
C>> B. Wijnen
C>> LucentTechnologies
C>> H. Alvestrand
C>> Cisco Systems
C>> P. Resnick
C>> QUALCOMM Incorporated
C>> September 20, 2004
C>>
C>> AdminRest Scenario C: An IETF Administrative Support Foundation as
C>> an Independent Nonprofit Corporation
C>>
C>> Abstract
C>>
C>> This document defines a proposal for an IETF Administrative
C>> Support Foundation (IASF) as an independent not-for-profit
C>> corporation as a means for providing focused support for IETF
C>> community activities. It proposes the creation of an IASF Board
C>> of Trustees (BoT) that is mainly selected by and accountable to
C>> the IETF community and would provide oversight for the IETF
C>> Administrative Support Foundation. The IASF will also establish
C>> and maintain a strong relationship with the Internet Society
C>> (ISOC) and the current relationships between IETF and ISOC will
C>> basically be left unchanged.
C>>
C>> In order to allow the community to properly evaluate this
C>> scenario, some draft Articles of Incorporation and draft Bylaws
C>> for the IASF are included. Some draft BCP wording for the IASF,
C>> IETF and ISOC relationships is also included.
C>>
C>> 1. Overview of Scenario C
C>>
C>> This document follows from two previous documents. [RFC3716]
C>> defined the overall parameters and criteria for an administrative
C>> restructuring. [I-D.malamud-consultant-report] provided an
C>> analysis of the implications of several of the suggested
C>> strategies. This document picks one strategy and develops it
C>> further.
C>>
C>> B. Wijnen
C>> LucentTechnologies
C>> H. Alvestrand
C>> Cisco Systems
C>> P. Resnick
C>> QUALCOMM Incorporated
C>> September 20, 2004
C>>
C>> AdminRest Scenario C: An IETF Administrative Support Foundation as
C>> an Independent Nonprofit Corporation
C>>
C>> Abstract
C>>
C>> This document defines a proposal for an IETF Administrative
C>> Support Foundation (IASF) as an independent not-for-profit
C>> corporation as a means for providing focused support for IETF
C>> community activities. It proposes the creation of an IASF Board
C>> of Trustees (BoT) that is mainly selected by and accountable to
C>> the IETF community and would provide oversight for the IETF
C>> Administrative Support Foundation. The IASF will also establish
C>> and maintain a strong relationship with the Internet Society
C>> (ISOC) and the current relationships between IETF and ISOC will
C>> basically be left unchanged.
C>>
C>> In order to allow the community to properly evaluate this
C>> scenario, some draft Articles of Incorporation and draft Bylaws
C>> for the IASF are included. Some draft BCP wording for the IASF,
C>> IETF and ISOC relationships is also included.
C>>
C>> 1. Overview of Scenario C
C>>
C>> This document follows from two previous documents. [RFC3716]
C>> defined the overall parameters and criteria for an administrative
C>> restructuring. [I-D.malamud-consultant-report] provided an
C>> analysis of the implications of several of the suggested
C>> strategies. This document picks one strategy and develops it
C>> further.
C>>
C>> In order to provide the most focused and effective administrative
C>> support to the IETF community, this updated scenario C proposes a
C>> new and well-defined legal entity to support the IETF
C>> administrative functions. The name of that new entity is "The
C>> IETF Administrative Support Foundation" (IASF).
C>>
C>> First, it is important to understand that the IETF has been
C>> organized as an Activity of the Internet Society (ISOC) and as
C>> such represents the "Standards and Protocols" pillar of ISOC.
C>> Under this proposal, the IETF would continue to be an integral
C>> part of the Standards and Protocols pillar of ISOC. ISOC
C>> currently provides these important functions to the IETF:
C>>
C>> 1. Standards Process Functions. ISOC plays a fundamental role in
C>> the IETF Standards Process, including appointment of the
C>> Nominating Committee (Nomcom) chair, confirmation of IAB
C>> members, confirmation of documents that describe the
C>> standards processes, and acting as the last resort in the
C>> appeals process. These Standards Process Functions are
C>> defined in [RFC2026], [RFC2028], [RFC2031], and [RFC3677].
C>>
C>> 2. IETF Fund Raising Functions. ISOC provides the fund raising
C>> function as one source for financial support the IETF.
C>>
C>> 3. Administration Functions. ISOC provides administrative and
C>> financial functions, managing the contract with the RFC
C>> Editor, providing insurance for selected IETF participants,
C>> and administering a discretionary fund for use by the IAB and
C>> the IETF Chairs.
C>>
C>> The administrative restructuring of the IETF proposed in this
C>> document keeps that basic relationship between IETF and ISOC.
C>> Specifically, the recommendation does not propose any changes to
C>> the "Standards Process Functions" or to the "IETF Fund Raising
C>> Functions".
C>>
C>> Under the "Administration Functions", ISOC both funds and
C>> administers some (as stated above) parts of the IETF
C>> Administrative Support Functions. Some of the funds (like for
C>> the RFC-Editor) go directly to the contractor who executes the
C>> administrative function. The streamlining of the administrative
C>> support for the IETF ultimately intends to put the complete
C>> Administrative Support Functions under the newly recommended
C>> IASF. This means that we recommend that ultimately, ISOC funds
C>> for the IETF will be transferred to the IASF, which will then
C>> administer all the contracts and payments according to an
C>> In order to provide the most focused and effective administrative
C>> support to the IETF community, this updated scenario C proposes a
C>> new and well-defined legal entity to support the IETF
C>> administrative functions. The name of that new entity is "The
C>> IETF Administrative Support Foundation" (IASF).
C>>
C>> First, it is important to understand that the IETF has been
C>> organized as an Activity of the Internet Society (ISOC) and as
C>> such represents the "Standards and Protocols" pillar of ISOC.
C>> Under this proposal, the IETF would continue to be an integral
C>> part of the Standards and Protocols pillar of ISOC. ISOC
C>> currently provides these important functions to the IETF:
C>>
C>> 1. Standards Process Functions. ISOC plays a fundamental role in
C>> the IETF Standards Process, including appointment of the
C>> Nominating Committee (Nomcom) chair, confirmation of IAB
C>> members, confirmation of documents that describe the
C>> standards processes, and acting as the last resort in the
C>> appeals process. These Standards Process Functions are
C>> defined in [RFC2026], [RFC2028], [RFC2031], and [RFC3677].
C>>
C>> 2. IETF Fund Raising Functions. ISOC provides the fund raising
C>> function as one source for financial support the IETF.
C>>
C>> 3. Administration Functions. ISOC provides administrative and
C>> financial functions, managing the contract with the RFC
C>> Editor, providing insurance for selected IETF participants,
C>> and administering a discretionary fund for use by the IAB and
C>> the IETF Chairs.
C>>
C>> The administrative restructuring of the IETF proposed in this
C>> document keeps that basic relationship between IETF and ISOC.
C>> Specifically, the recommendation does not propose any changes to
C>> the "Standards Process Functions" or to the "IETF Fund Raising
C>> Functions".
C>>
C>> Under the "Administration Functions", ISOC both funds and
C>> administers some (as stated above) parts of the IETF
C>> Administrative Support Functions. Some of the funds (like for
C>> the RFC-Editor) go directly to the contractor who executes the
C>> administrative function. The streamlining of the administrative
C>> support for the IETF ultimately intends to put the complete
C>> Administrative Support Functions under the newly recommended
C>> IASF. This means that we recommend that ultimately, ISOC funds
C>> for the IETF will be transferred to the IASF, which will then
C>> administer all the contracts and payments according to an
C>> approved yearly budget. The details of that process will be
C>> documented in a Memorandum of Understanding (MoU) between ISOC,
C>> IETF and IASF.
C>>
C>> This updated AdminRest Scenario C aims to provide the following:
C>>
C>> o A continued close relationship between IETF and ISOC.
C>>
C>> o A well defined legal entity within which the IETF can define
C>> the administrative activity in terms of IETF community needs.
C>>
C>> o A Board of Trustees with operational oversight that is
C>> accountable to the IETF community.
C>>
C>> o Continued separation between the IETF standards activity and
C>> any fund-raising for standards work.
C>>
C>> o A close and well defined relationship between IASF and ISOC,
C>> documented in a BCP (or MoU).
C>>
C>> o Appropriate ISOC oversight of its standards activities funds
C>> via a yearly budget approval and open reporting of funds
C>> spent.
C>>
C>> In scenario C, it is intended that the IETF Administrative
C>> Support Foundation will be a tax-exempt not-for-profit
C>> corporation as defined by Articles of Incorporation and a set of
C>> Bylaws. These will describe the scope and purpose of the IASF
C>> and they also define the structure and responsibility of the
C>> Board of Trustees (BoT), a body that is mainly selected by the
C>> IETF and which is responsible for overseeing the IASF. A draft
C>> of the Articles of Incorporation and Bylaws is included in the
C>> next sections of this document.
C>>
C>> Scenario C allows us (IETF) to establish IETF control over our
C>> administrative support functions in terms of determining that
C>> they meet the community's needs, and adjusting them from time to
C>> time using IETF processes. This is to address the pressing
C>> administrative issues outlined in [RFC3716].
C>>
C>> Scenario C also encourages us (the IETF) to regularly evaluate
C>> that we do want to continue the relationships with ISOC and the
C>> contracts with our services providers (contractors). It is based
C>> on the premise that we prefer to actively maintain relationships
C>> with other organizations and service providers instead of being
C>> bound to such relationships based on poorly defined and poorly
C>> approved yearly budget. The details of that process will be
C>> documented in a Memorandum of Understanding (MoU) between ISOC,
C>> IETF and IASF.
C>>
C>> This updated AdminRest Scenario C aims to provide the following:
C>>
C>> o A continued close relationship between IETF and ISOC.
C>>
C>> o A well defined legal entity within which the IETF can define
C>> the administrative activity in terms of IETF community needs.
C>>
C>> o A Board of Trustees with operational oversight that is
C>> accountable to the IETF community.
C>>
C>> o Continued separation between the IETF standards activity and
C>> any fund-raising for standards work.
C>>
C>> o A close and well defined relationship between IASF and ISOC,
C>> documented in a BCP (or MoU).
C>>
C>> o Appropriate ISOC oversight of its standards activities funds
C>> via a yearly budget approval and open reporting of funds
C>> spent.
C>>
C>> In scenario C, it is intended that the IETF Administrative
C>> Support Foundation will be a tax-exempt not-for-profit
C>> corporation as defined by Articles of Incorporation and a set of
C>> Bylaws. These will describe the scope and purpose of the IASF
C>> and they also define the structure and responsibility of the
C>> Board of Trustees (BoT), a body that is mainly selected by the
C>> IETF and which is responsible for overseeing the IASF. A draft
C>> of the Articles of Incorporation and Bylaws is included in the
C>> next sections of this document.
C>>
C>> Scenario C allows us (IETF) to establish IETF control over our
C>> administrative support functions in terms of determining that
C>> they meet the community's needs, and adjusting them from time to
C>> time using IETF processes. This is to address the pressing
C>> administrative issues outlined in [RFC3716].
C>>
C>> Scenario C also encourages us (the IETF) to regularly evaluate
C>> that we do want to continue the relationships with ISOC and the
C>> contracts with our services providers (contractors). It is based
C>> on the premise that we prefer to actively maintain relationships
C>> with other organizations and service providers instead of being
C>> bound to such relationships based on poorly defined and poorly
C>> documented historical facts. A draft BCP for the relationship
C>> between ISOC, IETF and IASF is included as a separate section in
C>> this document.
C>>
C>> Scenario C does however bring the burden of creating a new legal
C>> entity (IASF) and such an undertaking is also not without risks.
C>> It will need careful planning and execution. Migration from the
C>> current structure to this new structure is probably also somewhat
C>> more costly and time and labour consuming. The sections below
C>> try to show how that would be achieved and outlines what further
C>> steps are needed to provide more detail if this scenario is
C>> chosen.
C>>
C>> 2. Work Plan for the IETF Administrative Support Foundation
C>>
C>> This section gives the work plan for the IETF Administrative
C>> Support Foundation (IASF) for the remainder of 2004 and the year
C>> 2005.
C>>
C>> 2.1 Workplan goals
C>>
C>> The work plan below is intended to satisfy three goals:
C>>
C>> o Satisfy the IETF's need for support functions in 2005
C>>
C>> o Operate with a positive account balance throughout 2005
C>>
C>> o Start building up a fund inside the IASF to serve as a buffer
C>> against budgetary emergencies in later years (such as meetings
C>> with a severe cost overrun, or force-majeure cancellations).
C>>
C>> The fund target is 6 months of operating revenue, and the target
C>> for building up the fund is 3 years. The budgeted set-aside for
C>> the fund should thus be approximately 17% of operating revenue.
C>>
C>> 2.2 Incorporation process
C>>
C>> There are 3 things that need to be in place before that
C>> corporation can be considered viable at all:
C>>
C>> o IETF consensus on the plan
C>>
C>> o ISOC agreement on a reasonable support contract
C>>
C>> o Assurance that the corporation will have tax-exempt status
C>>
C>> documented historical facts. A draft BCP for the relationship
C>> between ISOC, IETF and IASF is included as a separate section in
C>> this document.
C>>
C>> Scenario C does however bring the burden of creating a new legal
C>> entity (IASF) and such an undertaking is also not without risks.
C>> It will need careful planning and execution. Migration from the
C>> current structure to this new structure is probably also somewhat
C>> more costly and time and labour consuming. The sections below
C>> try to show how that would be achieved and outlines what further
C>> steps are needed to provide more detail if this scenario is
C>> chosen.
C>>
C>> 2. Work Plan for the IETF Administrative Support Foundation
C>>
C>> This section gives the work plan for the IETF Administrative
C>> Support Foundation (IASF) for the remainder of 2004 and the year
C>> 2005.
C>>
C>> 2.1 Workplan goals
C>>
C>> The work plan below is intended to satisfy three goals:
C>>
C>> o Satisfy the IETF's need for support functions in 2005
C>>
C>> o Operate with a positive account balance throughout 2005
C>>
C>> o Start building up a fund inside the IASF to serve as a buffer
C>> against budgetary emergencies in later years (such as meetings
C>> with a severe cost overrun, or force-majeure cancellations).
C>>
C>> The fund target is 6 months of operating revenue, and the target
C>> for building up the fund is 3 years. The budgeted set-aside for
C>> the fund should thus be approximately 17% of operating revenue.
C>>
C>> 2.2 Incorporation process
C>>
C>> There are 3 things that need to be in place before that
C>> corporation can be considered viable at all:
C>>
C>> o IETF consensus on the plan
C>>
C>> o ISOC agreement on a reasonable support contract
C>>
C>> o Assurance that the corporation will have tax-exempt status
C>>
C>> Once this document has been discussed in the IETF, and the IESG
C>> and IAB gauges that rough consensus seems reached, the IETF
C>> leadership will take the following actions:
C>>
C>> o Publish a Last Call on this document (to determine plan
C>> consensus).
C>>
C>> o Choose a negotiating team to negotiate the ISOC contract.
C>>
C>> o Choose an executive search team to find the IASF
C>> Administrative Director (IAD).
C>>
C>> o Consult with legal counsel to determine how best to achieve
C>> tax-exempt status; this will affect the bylaws and articles of
C>> incorporation.
C>>
C>> When the Last Call is over, the IESG will consider whether there
C>> is still consensus, and if there is, approve this document for
C>> publication. Once that happens, it will take the following
C>> steps:
C>>
C>> o As soon as negotiations conclude, publish a Last Call on the
C>> ISOC contract.
C>>
C>> o As soon as drafting of legal documents is completed, publish a
C>> Last Call on the Bylaws and Articles of Incorporation, and ask
C>> the Nomcom to start the process of selecting Nomcom-selected
C>> board representatives.
C>>
C>>
C>> These Last Calls are "speak now" Last Calls - if someone wishes
C>> to challenge the IETF consensus to go ahead with these actions,
C>> knowing what the formal documents will look like, this is their
C>> last chance.
C>>
C>> When these Last Calls are over, the IETF chair, the IAB chair and
C>> the ISOC President will jointly file the articles of
C>> incorporation, and the IESG, IAB and ISOC will fill their board
C>> seats.
C>>
C>> Note: This document does not say when a Request for Information
C>> (RFI) for IETF support services such as meeting planning is sent
C>> out. Advice is sought on the earliest point where this can be
C>> done.
C>>
C>> Once this document has been discussed in the IETF, and the IESG
C>> and IAB gauges that rough consensus seems reached, the IETF
C>> leadership will take the following actions:
C>>
C>> o Publish a Last Call on this document (to determine plan
C>> consensus).
C>>
C>> o Choose a negotiating team to negotiate the ISOC contract.
C>>
C>> o Choose an executive search team to find the IASF
C>> Administrative Director (IAD).
C>>
C>> o Consult with legal counsel to determine how best to achieve
C>> tax-exempt status; this will affect the bylaws and articles of
C>> incorporation.
C>>
C>> When the Last Call is over, the IESG will consider whether there
C>> is still consensus, and if there is, approve this document for
C>> publication. Once that happens, it will take the following
C>> steps:
C>>
C>> o As soon as negotiations conclude, publish a Last Call on the
C>> ISOC contract.
C>>
C>> o As soon as drafting of legal documents is completed, publish a
C>> Last Call on the Bylaws and Articles of Incorporation, and ask
C>> the Nomcom to start the process of selecting Nomcom-selected
C>> board representatives.
C>>
C>>
C>> These Last Calls are "speak now" Last Calls - if someone wishes
C>> to challenge the IETF consensus to go ahead with these actions,
C>> knowing what the formal documents will look like, this is their
C>> last chance.
C>>
C>> When these Last Calls are over, the IETF chair, the IAB chair and
C>> the ISOC President will jointly file the articles of
C>> incorporation, and the IESG, IAB and ISOC will fill their board
C>> seats.
C>>
C>> Note: This document does not say when a Request for Information
C>> (RFI) for IETF support services such as meeting planning is sent
C>> out. Advice is sought on the earliest point where this can be
C>> done.
C>>
C>> 2.3 Contract establishment
C>>
C>> The most important activity for late 2004/early 2005 is to
C>> finalize contracts for the support of the IETF. This includes:
C>>
C>> o Funding
C>>
C>> o Technical infrastructure
C>>
C>> o Meeting management
C>>
C>> o Clerk's office
C>>
C>> o RFC Editor
C>>
C>> o IANA
C>>
C>> There appears to be consensus in the IETF community that these
C>> functions, whether they are offered for free, remunerated or
C>> arranged for other consideration, should be under contract.
C>>
C>> The contract for funding is expected to be with ISOC, and should
C>> be finalized before IASF is established.
C>>
C>> The contract for technical infrastructure is expected to be an
C>> RFP, published in November of 2004, with responses being
C>> evaluated in December 2004, and services rendered from a mutually
C>> agreed date early in 2005.
C>>
C>> The contract for meeting management will be influenced by the
C>> need to have stable agreements for the 2005 meetings at an early
C>> date. This indicates that IASF will honor a pre-IASF agreement
C>> to have these meeting contracts signed by Foretec (if that can be
C>> achieved).
C>>
C>> It is not clear how the contract for the clerk's office is to be
C>> managed at the time of this writing.
C>>
C>> The contract for the RFC Editor is expected to be with ISI, and
C>> is expected to be a continuation of the current contract with
C>> ISOC, which runs until the end of 2005.
C>>
C>> The contract with IANA will replace or augment the current MoU
C>> between the IETF and ICANN. In its simplest form, it would
C>> simply be a reconfirmation of the duties of ICANN under the MoU.
C>>
C>> 2.3 Contract establishment
C>>
C>> The most important activity for late 2004/early 2005 is to
C>> finalize contracts for the support of the IETF. This includes:
C>>
C>> o Funding
C>>
C>> o Technical infrastructure
C>>
C>> o Meeting management
C>>
C>> o Clerk's office
C>>
C>> o RFC Editor
C>>
C>> o IANA
C>>
C>> There appears to be consensus in the IETF community that these
C>> functions, whether they are offered for free, remunerated or
C>> arranged for other consideration, should be under contract.
C>>
C>> The contract for funding is expected to be with ISOC, and should
C>> be finalized before IASF is established.
C>>
C>> The contract for technical infrastructure is expected to be an
C>> RFP, published in November of 2004, with responses being
C>> evaluated in December 2004, and services rendered from a mutually
C>> agreed date early in 2005.
C>>
C>> The contract for meeting management will be influenced by the
C>> need to have stable agreements for the 2005 meetings at an early
C>> date. This indicates that IASF will honor a pre-IASF agreement
C>> to have these meeting contracts signed by Foretec (if that can be
C>> achieved).
C>>
C>> It is not clear how the contract for the clerk's office is to be
C>> managed at the time of this writing.
C>>
C>> The contract for the RFC Editor is expected to be with ISI, and
C>> is expected to be a continuation of the current contract with
C>> ISOC, which runs until the end of 2005.
C>>
C>> The contract with IANA will replace or augment the current MoU
C>> between the IETF and ICANN. In its simplest form, it would
C>> simply be a reconfirmation of the duties of ICANN under the MoU.
C>>
C>> 2.4 Performance evaluation
C>>
C>> The second task of the IASF is to make sure the IETF gets the
C>> support it needs. The IASF will work together with the IETF
C>> community to make an effort to identify whether or not the IETF's
C>> needs are being met, and to coordinate improvements with the
C>> contractors. This is an ongoing activity.
C>>
C>> 2.5 Budgeting for 2006
C>>
C>> In June 2005, the IASF will start the yearly budgeting process
C>> with ISOC, as specified in the ISOC contract, leading to a work
C>> plan and budget for 2006.
C>>
C>> 2.6 Reporting
C>>
C>> The IASF will present monthly updates on its economic status.
C>> These will be delivered to ISOC as part of the ISOC contract, and
C>> also be made publicly available so that the IETF community can
C>> inspect them.
C>>
C>> 3. Details of the IETF Administrative Support Foundation
C>>
C>> This section contains details about the proposal to change how
C>> the day-to-day IETF administrative support functions are
C>> provided. This recommendation is based on the initial
C>> description of "Scenario C" in the "Administrative Support
C>> Analysis" [I-D.malamud-consultant-report] provided by Carl
C>> Malamud. It is further based on discussion in the IESG and IAB
C>> and on feedback on Carl's document as received on the IETF
C>> mailing list. Further justifications, reasoning and motivations
C>> are given in Appendix A. Risk Analysis is done in Appendix C.
C>>
C>> This document recommends to create a well defined and legal
C>> entity called "The IETF Administrative Support Foundation"
C>>
C>> (IASF). The name intends to clearly express that this new legal
C>> entity has only one single function, namely to provide the
C>> administrative support of the IETF Standardization and Protocol
C>> Development activities. This entity will ultimately manage and
C>> administer all the administrative functions that are needed to
C>> support the IETF - the Standardization and Protocol Development
C>> activity of ISOC.
C>>
C>> 2.4 Performance evaluation
C>>
C>> The second task of the IASF is to make sure the IETF gets the
C>> support it needs. The IASF will work together with the IETF
C>> community to make an effort to identify whether or not the IETF's
C>> needs are being met, and to coordinate improvements with the
C>> contractors. This is an ongoing activity.
C>>
C>> 2.5 Budgeting for 2006
C>>
C>> In June 2005, the IASF will start the yearly budgeting process
C>> with ISOC, as specified in the ISOC contract, leading to a work
C>> plan and budget for 2006.
C>>
C>> 2.6 Reporting
C>>
C>> The IASF will present monthly updates on its economic status.
C>> These will be delivered to ISOC as part of the ISOC contract, and
C>> also be made publicly available so that the IETF community can
C>> inspect them.
C>>
C>> 3. Details of the IETF Administrative Support Foundation
C>>
C>> This section contains details about the proposal to change how
C>> the day-to-day IETF administrative support functions are
C>> provided. This recommendation is based on the initial
C>> description of "Scenario C" in the "Administrative Support
C>> Analysis" [I-D.malamud-consultant-report] provided by Carl
C>> Malamud. It is further based on discussion in the IESG and IAB
C>> and on feedback on Carl's document as received on the IETF
C>> mailing list. Further justifications, reasoning and motivations
C>> are given in Appendix A. Risk Analysis is done in Appendix C.
C>>
C>> This document recommends to create a well defined and legal
C>> entity called "The IETF Administrative Support Foundation"
C>>
C>> (IASF). The name intends to clearly express that this new legal
C>> entity has only one single function, namely to provide the
C>> administrative support of the IETF Standardization and Protocol
C>> Development activities. This entity will ultimately manage and
C>> administer all the administrative functions that are needed to
C>> support the IETF - the Standardization and Protocol Development
C>> activity of ISOC.
C>>
C>> 3.1 Organizational Form and Legal Domicile
C>>
C>> The consultant report [I-D.malamud-consultant-report] contains a
C>> writeup on various choices in terms of how and where to
C>> incorporate. This recommendation has made the choice to
C>> incorporate in the US in the state of Virginia. Some detail can
C>> be found in Appendix B.
C>>
C>> In this scenario, administrative support functions for the IETF
C>> are legally housed in a focused, incorporated institution
C>> (although the Administrative Director might be physically housed
C>> within the Internet Society).
C>>
C>> This scenario defines a number of concrete linkages with the
C>> Internet Society, which supplement the current close
C>> interconnection of the IETF community with ISOC. The
C>> relationship is to be documented in a MoU (initial text is in
C>> Section 4).
C>>
C>> 3.2 Draft Core Principles
C>>
C>> 3.2.1 Principles of Establishment and Governance
C>>
C>> The following principles are to be respected for the
C>> establishment and governance of the IETF Administrative Support
C>> Foundation (IASF) and are the basis for the Draft Articles of
C>> Incorporation as in Section 6.1 and the Draft Bylaws as in
C>> Section 6.2:
C>>
C>> 1. The IASF shall be governed by a Board of Trustees (BoT), who
C>> shall be responsible for the fiscal, legal, and
C>> administrative infrastructure that supports the activities of
C>> the IETF.
C>>
C>> 2. The governance of the IETF, the standards process, and all
C>> other aspects of how we make our standards are defined in the
C>> procedural Best Current Practice (BCP) RFC series, which will
C>> be explicitly referenced in the organization documents of the
C>> IASF.
C>>
C>> 3. The IASF shall be transparent and responsible to the IETF.
C>>
C>> 4. The BoT shall appoint a Secretary and a Treasurer, who need
C>> not be members of the BoT. The IETF Administrative Director
C>> (IAD) of the IASF shall provide staff support to the BoT.
C>>
C>> 3.1 Organizational Form and Legal Domicile
C>>
C>> The consultant report [I-D.malamud-consultant-report] contains a
C>> writeup on various choices in terms of how and where to
C>> incorporate. This recommendation has made the choice to
C>> incorporate in the US in the state of Virginia. Some detail can
C>> be found in Appendix B.
C>>
C>> In this scenario, administrative support functions for the IETF
C>> are legally housed in a focused, incorporated institution
C>> (although the Administrative Director might be physically housed
C>> within the Internet Society).
C>>
C>> This scenario defines a number of concrete linkages with the
C>> Internet Society, which supplement the current close
C>> interconnection of the IETF community with ISOC. The
C>> relationship is to be documented in a MoU (initial text is in
C>> Section 4).
C>>
C>> 3.2 Draft Core Principles
C>>
C>> 3.2.1 Principles of Establishment and Governance
C>>
C>> The following principles are to be respected for the
C>> establishment and governance of the IETF Administrative Support
C>> Foundation (IASF) and are the basis for the Draft Articles of
C>> Incorporation as in Section 6.1 and the Draft Bylaws as in
C>> Section 6.2:
C>>
C>> 1. The IASF shall be governed by a Board of Trustees (BoT), who
C>> shall be responsible for the fiscal, legal, and
C>> administrative infrastructure that supports the activities of
C>> the IETF.
C>>
C>> 2. The governance of the IETF, the standards process, and all
C>> other aspects of how we make our standards are defined in the
C>> procedural Best Current Practice (BCP) RFC series, which will
C>> be explicitly referenced in the organization documents of the
C>> IASF.
C>>
C>> 3. The IASF shall be transparent and responsible to the IETF.
C>>
C>> 4. The BoT shall appoint a Secretary and a Treasurer, who need
C>> not be members of the BoT. The IETF Administrative Director
C>> (IAD) of the IASF shall provide staff support to the BoT.
C>>
C>> 5. The BoT shall be composed to strike a balance between
C>> "outside" and "inside" directors. The IESG and IAB will each
C>> select a representative to serve as a voting member of the
C>> BoT. Mechanisms such as the Nominating Committee (Nomcom) and
C>> the appointment of certain seats by the ISOC fulfill the
C>> outside director obligations.
C>>
C>> 6. IAB, IESG and ISOC will have liaisons to the BoT in order to
C>> have a good basis for interaction.
C>>
C>> The BoT will have strong governance over a limited scope of
C>> activities (e.g., the fiscal, legal, and administrative
C>> infrastructure that are the charter of the IASF) but will have no
C>> authority over the IETF standards process. In this board
C>> composition, the ISOC and Nomcom appointments ensure that outside
C>> directors with no perceived conflicts of interest are on the
C>> board.
C>>
C>> All nominating bodies should make strong fiscal, legal, and
C>> administrative acumen essential selection criteria for this
C>> position.
C>>
C>> IAB and IESG representatives will serve for one year. For other
C>> appointments, a term proposed for the nominated positions is
C>> three years with staggered appointments. However, the nominating
C>> body might have the power to change their appointee during their
C>> term.
C>>
C>> All members of the BoT selected by the IETF are subject to the
C>> same recall procedures in effect for the IETF leadership such as
C>> members of the IAB and IESG.
C>>
C>> 3.2.2 Principles of Operation of the IETF Administrative Support
C>> Foundation
C>>
C>> The following are general principles for the operation of the
C>> IASF:
C>>
C>> 1. The IASF shall employ an IETF Administrative Director (IAD)
C>> of the IASF, who shall be hired by the BoT with the advice
C>> and consent of the IESG and IAB.
C>>
C>> 2. All support services shall be contracted in an open and
C>> transparent manner.
C>>
C>> 5. The BoT shall be composed to strike a balance between
C>> "outside" and "inside" directors. The IESG and IAB will each
C>> select a representative to serve as a voting member of the
C>> BoT. Mechanisms such as the Nominating Committee (Nomcom) and
C>> the appointment of certain seats by the ISOC fulfill the
C>> outside director obligations.
C>>
C>> 6. IAB, IESG and ISOC will have liaisons to the BoT in order to
C>> have a good basis for interaction.
C>>
C>> The BoT will have strong governance over a limited scope of
C>> activities (e.g., the fiscal, legal, and administrative
C>> infrastructure that are the charter of the IASF) but will have no
C>> authority over the IETF standards process. In this board
C>> composition, the ISOC and Nomcom appointments ensure that outside
C>> directors with no perceived conflicts of interest are on the
C>> board.
C>>
C>> All nominating bodies should make strong fiscal, legal, and
C>> administrative acumen essential selection criteria for this
C>> position.
C>>
C>> IAB and IESG representatives will serve for one year. For other
C>> appointments, a term proposed for the nominated positions is
C>> three years with staggered appointments. However, the nominating
C>> body might have the power to change their appointee during their
C>> term.
C>>
C>> All members of the BoT selected by the IETF are subject to the
C>> same recall procedures in effect for the IETF leadership such as
C>> members of the IAB and IESG.
C>>
C>> 3.2.2 Principles of Operation of the IETF Administrative Support
C>> Foundation
C>>
C>> The following are general principles for the operation of the
C>> IASF:
C>>
C>> 1. The IASF shall employ an IETF Administrative Director (IAD)
C>> of the IASF, who shall be hired by the BoT with the advice
C>> and consent of the IESG and IAB.
C>>
C>> 2. All support services shall be contracted in an open and
C>> transparent manner.
C>>
C>> 3. The IAD shall submit a proposed annual budget to the BoT at
C>> least 90 days before the beginning of the fiscal year. Such
C>> budget shall be developed with the advice and consent of the
C>> IAB and IESG.
C>>
C>> 4. The IAD shall serve on the BoT as a non-voting, ex-officio
C>> member.
C>>
C>> 5. The BoT shall select a professional audit firm and shall
C>> commission an audit immediately upon the close of each fiscal
C>> year.
C>>
C>> 6. The IASF will conduct financial reporting in a fully
C>> transparent fashion. Audits shall be conducted promptly and
C>> published. Tax returns shall be published. Detailed
C>> financial statements will be published on a regular basis,
C>> including timely reports on the financial results of IETF
C>> meetings.
C>>
C>> 4. Draft MoU between ISOC, IETF and IETF Administrative Support
C>> Foundation
C>>
C>> 4.1 Form and Scope of the Agreement
C>>
C>> This section presents some principles to be incorporated in a
C>> draft MoU/Contract between the Internet Society (ISOC) and the
C>> IETF Administrative Support Foundation (IASF), detailing the work
C>> each is expected to perform, the responsibilities each has, and
C>> the means by which these functions are accomplished. This
C>> MoU/Contract shall be published as an RFC.
C>>
C>> The MoU/Contract will specify the responsibilities of the
C>> Internet Society, including:
C>>
C>> o Reaffirmation of the Standards Process Function that ISOC
C>> performs for the IETF.
C>>
C>> o Continuation of the Fund Raising Function that ISOC conducts,
C>> in which a single, unified campaign is used to solicit
C>> corporate, individual, and other organizational donations for
C>> funding of the 3 Pillars.
C>>
C>> o Disbursement of funds to the IASF according to the agreed-upon
C>> budgets and processes as specified in this agreement.
C>>
C>> o Verification that IASF spends these funds to support the work
C>> of the IETF, within the scope described in the IASF bylaws.
C>>
C>> 3. The IAD shall submit a proposed annual budget to the BoT at
C>> least 90 days before the beginning of the fiscal year. Such
C>> budget shall be developed with the advice and consent of the
C>> IAB and IESG.
C>>
C>> 4. The IAD shall serve on the BoT as a non-voting, ex-officio
C>> member.
C>>
C>> 5. The BoT shall select a professional audit firm and shall
C>> commission an audit immediately upon the close of each fiscal
C>> year.
C>>
C>> 6. The IASF will conduct financial reporting in a fully
C>> transparent fashion. Audits shall be conducted promptly and
C>> published. Tax returns shall be published. Detailed
C>> financial statements will be published on a regular basis,
C>> including timely reports on the financial results of IETF
C>> meetings.
C>>
C>> 4. Draft MoU between ISOC, IETF and IETF Administrative Support
C>> Foundation
C>>
C>> 4.1 Form and Scope of the Agreement
C>>
C>> This section presents some principles to be incorporated in a
C>> draft MoU/Contract between the Internet Society (ISOC) and the
C>> IETF Administrative Support Foundation (IASF), detailing the work
C>> each is expected to perform, the responsibilities each has, and
C>> the means by which these functions are accomplished. This
C>> MoU/Contract shall be published as an RFC.
C>>
C>> The MoU/Contract will specify the responsibilities of the
C>> Internet Society, including:
C>>
C>> o Reaffirmation of the Standards Process Function that ISOC
C>> performs for the IETF.
C>>
C>> o Continuation of the Fund Raising Function that ISOC conducts,
C>> in which a single, unified campaign is used to solicit
C>> corporate, individual, and other organizational donations for
C>> funding of the 3 Pillars.
C>>
C>> o Disbursement of funds to the IASF according to the agreed-upon
C>> budgets and processes as specified in this agreement.
C>>
C>> o Verification that IASF spends these funds to support the work
C>> of the IETF, within the scope described in the IASF bylaws.
C>>
C>> Responsibilities of IASF:
C>>
C>> o Determine, in cooperation with the IETF, the support functions
C>> that are needed for the IETF, and can be achieved within
C>> available funds.
C>>
C>> o Enter into contracts for these support functions.
C>>
C>> o Supervise these contracts and ensure that they are being
C>> performed in the best interest of the IETF, within a
C>> reasonable budget and with agreed-upon performance.
C>>
C>> 4.2 Cooperation mechanism
C>>
C>> IASF and ISOC agree that they will perform a budgeting procedure
C>> each year, comprising the following steps:
C>>
C>> o IASF puts together a budget proposal to ISOC, and presents it
C>> in June. This will specify the functions that need to be
C>> performed, the cost of each, the expected revenue from IETF
C>> meeting participation, and how much is being requested for
C>> ISOC to contribute.
C>>
C>> o By the end of August, ISOC will give a budget number to IASF
C>> that says how much ISOC is willing to contribute to support
C>> the functions described in the IASF budget.
C>>
C>> o Before November 1, ISOC and IASF will agree on a budget, an
C>> ISOC contribution, and a disbursement schedule.
C>>
C>> o If either party sees that there is reason to change the
C>> budget, they can start a negotiation to do so at any time. On
C>> mutual agreement to a change, payments are modified
C>> accordingly.
C>>
C>> o ISOC may withhold funds if IASF fails to account for its
C>> expenditures, if it determines that IASF has departed
C>> significantly from its budgeted expenditures without agreement
C>> with ISOC to do so, or if ISOC determines that IASF is
C>> spending funds in violation of its bylaws.
C>>
C>> Responsibilities of IASF:
C>>
C>> o Determine, in cooperation with the IETF, the support functions
C>> that are needed for the IETF, and can be achieved within
C>> available funds.
C>>
C>> o Enter into contracts for these support functions.
C>>
C>> o Supervise these contracts and ensure that they are being
C>> performed in the best interest of the IETF, within a
C>> reasonable budget and with agreed-upon performance.
C>>
C>> 4.2 Cooperation mechanism
C>>
C>> IASF and ISOC agree that they will perform a budgeting procedure
C>> each year, comprising the following steps:
C>>
C>> o IASF puts together a budget proposal to ISOC, and presents it
C>> in June. This will specify the functions that need to be
C>> performed, the cost of each, the expected revenue from IETF
C>> meeting participation, and how much is being requested for
C>> ISOC to contribute.
C>>
C>> o By the end of August, ISOC will give a budget number to IASF
C>> that says how much ISOC is willing to contribute to support
C>> the functions described in the IASF budget.
C>>
C>> o Before November 1, ISOC and IASF will agree on a budget, an
C>> ISOC contribution, and a disbursement schedule.
C>>
C>> o If either party sees that there is reason to change the
C>> budget, they can start a negotiation to do so at any time. On
C>> mutual agreement to a change, payments are modified
C>> accordingly.
C>>
C>> o ISOC may withhold funds if IASF fails to account for its
C>> expenditures, if it determines that IASF has departed
C>> significantly from its budgeted expenditures without agreement
C>> with ISOC to do so, or if ISOC determines that IASF is
C>> spending funds in violation of its bylaws.
C>>
C>> 4.3 Promises Not to Do Things
C>>
C>> This section lays out things that would constitute interference
C>> in each others' business, or things that are Just Plain Wrong.
C>>
C>> In legal terms, these are called "covenants."
C>>
C>> ISOC will not place requirements on how IASF does business,
C>> except on reporting. It will, for instance, not attempt to
C>> influence IASF choice of contractors or choice of meeting
C>> sponsors. This restriction is meant to enforce the separation
C>> between fund raising and the actual operation of the standards
C>> process.
C>>
C>> IASF will not ask companies for money. IASF may ask for sponsors
C>> for IETF events, per tradition, and may accept zero-cost provider
C>> contracts or in-kind donations, but ISOC is the organization
C>> charged with fundraising.
C>>
C>> Neither ISOC nor IASF will attempt to influence technical
C>> decisions of the IETF standards process.
C>>
C>> 4.4 Initial contribution
C>>
C>> The Internet Society has already allocated $700,000 in transition
C>> funds. As part of the formation process, this section sets out a
C>> way that a 2005 allocation of funds and an initial contribution
C>> for startup can be decided upon. NOTE: This section is a GUESS!
C>> Its purpose is to give some sense of where we're at.
C>>
C>> If this plan is pursued, one of the first activities is to put
C>> together a detailed 2005 budget, including an analysis of cash
C>> flow and balance sheets to make sure that the organization is
C>> properly funded and will be solvent throughout the year. This
C>> planning process should project out 3 years and show how the
C>> organization will be able to accumulate the appropriate cash
C>> reserve to make sure operations can continue in a stable manner.
C>>
C>> An initial estimate is for an on-going annual contribution of USD
C>> 900.000 to IASF in 2005. In addition, ISOC will contribute an
C>> additional USD 600.000 as an initial fund to start up IASF,
C>> payable after the Board of Trustees is seated and this contract
C>> is signed and approved by the IETF.
C>>
C>> ISOC commits to this ongoing level of contribution (USD 75.000
C>> per month) for the lifetime of this contract, unless modified by
C>> mutual agreement.
C>>
C>> 4.3 Promises Not to Do Things
C>>
C>> This section lays out things that would constitute interference
C>> in each others' business, or things that are Just Plain Wrong.
C>>
C>> In legal terms, these are called "covenants."
C>>
C>> ISOC will not place requirements on how IASF does business,
C>> except on reporting. It will, for instance, not attempt to
C>> influence IASF choice of contractors or choice of meeting
C>> sponsors. This restriction is meant to enforce the separation
C>> between fund raising and the actual operation of the standards
C>> process.
C>>
C>> IASF will not ask companies for money. IASF may ask for sponsors
C>> for IETF events, per tradition, and may accept zero-cost provider
C>> contracts or in-kind donations, but ISOC is the organization
C>> charged with fundraising.
C>>
C>> Neither ISOC nor IASF will attempt to influence technical
C>> decisions of the IETF standards process.
C>>
C>> 4.4 Initial contribution
C>>
C>> The Internet Society has already allocated $700,000 in transition
C>> funds. As part of the formation process, this section sets out a
C>> way that a 2005 allocation of funds and an initial contribution
C>> for startup can be decided upon. NOTE: This section is a GUESS!
C>> Its purpose is to give some sense of where we're at.
C>>
C>> If this plan is pursued, one of the first activities is to put
C>> together a detailed 2005 budget, including an analysis of cash
C>> flow and balance sheets to make sure that the organization is
C>> properly funded and will be solvent throughout the year. This
C>> planning process should project out 3 years and show how the
C>> organization will be able to accumulate the appropriate cash
C>> reserve to make sure operations can continue in a stable manner.
C>>
C>> An initial estimate is for an on-going annual contribution of USD
C>> 900.000 to IASF in 2005. In addition, ISOC will contribute an
C>> additional USD 600.000 as an initial fund to start up IASF,
C>> payable after the Board of Trustees is seated and this contract
C>> is signed and approved by the IETF.
C>>
C>> ISOC commits to this ongoing level of contribution (USD 75.000
C>> per month) for the lifetime of this contract, unless modified by
C>> mutual agreement.
C>>
C>> 4.5 Termination, law and so on
C>>
C>> This agreement may be terminated by either party for any reason
C>> on 12 months' notice.
C>>
C>> The parties may reach mutual agreement on a shorter termination
C>> period.
C>>
C>> All conflicts under this agreement are to be adjudicated under
C>> the laws of the United States and the State of Virginia, however
C>> the parties may also agree to arbitration, mediation or any other
C>> conflict resolution mechanisms.
C>>
C>> 5. Notes and Explanations
C>>
C>> This is where we put down why things are the way they are.
C>>
C>> 5.1 Type of legal instrument
C>>
C>> This document is styled as a contract - an agreement between two
C>> parties, enforceable under law. An alternate formulation would
C>> be a Memorandum of Understanding - but we want it to be clear to
C>> everyone that the parties stand behind their responsibilities
C>> under this document. At the moment, the authors see no
C>> compelling arguments for not making it a contract. In either
C>> case, the document is published as an RFC.
C>>
C>> 5.2 Power Balance
C>>
C>> As written, it is designed to make it easy to do the right thing
C>> as long as the parties agree what that is, to make it clear that
C>> ISOC will continue to pay money as long as IASF does the Right
C>> Thing (and reports what it's doing), and that ISOC can stop the
C>> show quickly if it's clear that IASF is not doing the Right
C>> Thing.
C>>
C>> 5.3 Budget figures
C>>
C>> The main purpose of the numbers is to make it clear that there
C>> WILL be numbers in this contract, and that it WILL represent a
C>> solid commitment by ISOC. The numbers are "subject to change
C>> without notice" while this contract is negotiated.
C>>
C>> 4.5 Termination, law and so on
C>>
C>> This agreement may be terminated by either party for any reason
C>> on 12 months' notice.
C>>
C>> The parties may reach mutual agreement on a shorter termination
C>> period.
C>>
C>> All conflicts under this agreement are to be adjudicated under
C>> the laws of the United States and the State of Virginia, however
C>> the parties may also agree to arbitration, mediation or any other
C>> conflict resolution mechanisms.
C>>
C>> 5. Notes and Explanations
C>>
C>> This is where we put down why things are the way they are.
C>>
C>> 5.1 Type of legal instrument
C>>
C>> This document is styled as a contract - an agreement between two
C>> parties, enforceable under law. An alternate formulation would
C>> be a Memorandum of Understanding - but we want it to be clear to
C>> everyone that the parties stand behind their responsibilities
C>> under this document. At the moment, the authors see no
C>> compelling arguments for not making it a contract. In either
C>> case, the document is published as an RFC.
C>>
C>> 5.2 Power Balance
C>>
C>> As written, it is designed to make it easy to do the right thing
C>> as long as the parties agree what that is, to make it clear that
C>> ISOC will continue to pay money as long as IASF does the Right
C>> Thing (and reports what it's doing), and that ISOC can stop the
C>> show quickly if it's clear that IASF is not doing the Right
C>> Thing.
C>>
C>> 5.3 Budget figures
C>>
C>> The main purpose of the numbers is to make it clear that there
C>> WILL be numbers in this contract, and that it WILL represent a
C>> solid commitment by ISOC. The numbers are "subject to change
C>> without notice" while this contract is negotiated.
C>>
C>> 6. Draft Incorporating Documents for the IETF Administrative
C>> Support Foundation
C>>
C>> 6.1 Draft Articles of Incorporation
C>>
C>> This section contains standard, pro-forma Articles of
C>> Incorporation. Note well that tax lawyers often make significant
C>> alterations to standard Articles as they consider a 501(c)(3)
C>> application. They are included here merely as a sample for
C>> illustrative purposes only.
C>>
C>> 'Commonwealth of Virginia -- State Corporation Commission'|
C>> 'Articles of Incorporation -- Virginia Nonstock Corporation'|
C>> Form SCC819, 07/ 03 [1] ------
C>>
C>> The undersigned, pursuant to Chapter 10 of Title 13.1 of the Code
C>> of Virginia, [Virginia] state(s) as follows:
C>>
C>> 1. The name of the corporation is The IETF Administrative
C>> Support Foundation.
C>>
C>> 2. The corporation shall have no members.
C>>
C>> 3. The purpose of the corporation is to manage and administer
C>> all the administrative functions for the IETF - the
C>> Standardization and Protocol Development activity of the
C>> Internet Society.
C>>
C>> 4. The Trustees of the corporation shall be elected or appointed
C>> as specified in Article IV (Section 6.2.5) of the Bylaws.
C>>
C>> 5. Name and agent:
C>>
C>> A. The name of the corporation's initial registered agent
C>> is: XXX
C>>
C>> B. The initial registered agent is a domestic or foreign
C>> stock or nonstock corporation, limited liability company,
C>> or registered limited liability partnership authorized to
C>> transact business in Virginia.
C>>
C>> 6. The initial Trustees are: XXX
C>>
C>> 7. The incorporators are: XXX
C>>
C>> 6. Draft Incorporating Documents for the IETF Administrative
C>> Support Foundation
C>>
C>> 6.1 Draft Articles of Incorporation
C>>
C>> This section contains standard, pro-forma Articles of
C>> Incorporation. Note well that tax lawyers often make significant
C>> alterations to standard Articles as they consider a 501(c)(3)
C>> application. They are included here merely as a sample for
C>> illustrative purposes only.
C>>
C>> 'Commonwealth of Virginia -- State Corporation Commission'|
C>> 'Articles of Incorporation -- Virginia Nonstock Corporation'|
C>> Form SCC819, 07/ 03 [1] ------
C>>
C>> The undersigned, pursuant to Chapter 10 of Title 13.1 of the Code
C>> of Virginia, [Virginia] state(s) as follows:
C>>
C>> 1. The name of the corporation is The IETF Administrative
C>> Support Foundation.
C>>
C>> 2. The corporation shall have no members.
C>>
C>> 3. The purpose of the corporation is to manage and administer
C>> all the administrative functions for the IETF - the
C>> Standardization and Protocol Development activity of the
C>> Internet Society.
C>>
C>> 4. The Trustees of the corporation shall be elected or appointed
C>> as specified in Article IV (Section 6.2.5) of the Bylaws.
C>>
C>> 5. Name and agent:
C>>
C>> A. The name of the corporation's initial registered agent
C>> is: XXX
C>>
C>> B. The initial registered agent is a domestic or foreign
C>> stock or nonstock corporation, limited liability company,
C>> or registered limited liability partnership authorized to
C>> transact business in Virginia.
C>>
C>> 6. The initial Trustees are: XXX
C>>
C>> 7. The incorporators are: XXX
C>>
C>> 6.2 Draft Bylaws of the IETF Administrative Support Foundation
C>>
C>> As with the Draft Articles, the Draft Bylaws included here are a
C>> pro-forma, standard version. Substantial alteration may be
C>> required as legal counsel reviews the specific nature of an
C>> incorporation.
C>>
C>> 6.2.1 Article I: Organization
C>>
C>> The name of the Corporation shall be The IETF Administrative
C>> Support Foundation (which is hereinafter also referred to as the
C>> "IASF").
C>>
C>> 6.2.2 Article II: Purpose
C>>
C>> *Section 1: Purpose.* The IASF shall be operated exclusively for
C>> nonprofit educational, charitable, and scientific purposes,
C>> including, without limitation, the purposes stated in the IASF's
C>> Articles of Incorporation.
C>>
C>> *Section 2: Restrictions.* No part of the net earnings of the
C>> IASF shall inure to the benefit of, or be distributable to,
C>> private persons, except that the IASF shall be authorized and
C>> empowered to pay reasonable compensation for services rendered,
C>> and to make payments and distributions in furtherance of the
C>> purposes set forth in Article II, Section 1 hereof. Any other
C>> provision of these Bylaws to the contrary notwithstanding, the
C>> IASF shall not carry on any activities not permitted to be
C>> carried on by a corporation exempt from Federal Income Tax under
C>> Section 501(a) and Section 501(c)(3) of the Code. These Bylaws
C>> shall not be altered or amended in derogation of the provisions
C>> of this Section.
C>>
C>> 6.2.3 Article III: Members
C>>
C>> The IASF shall have no members and no stockholders.
C>>
C>> 6.2.4 Article IV: Offices
C>>
C>> The office of the IASF shall be as determined from time to time
C>> by the Board of Trustees (BoT) within or outside of the State of
C>> Virginia.
C>>
C>> 6.2.5 Article V: Board of Trustees
C>>
C>> *Section 1: Authority and Responsibilities.* The power,
C>> authority, property, and affairs of the IASF shall at all times
C>> be exclusively exercised, controlled, and conducted by or under
C>> 6.2 Draft Bylaws of the IETF Administrative Support Foundation
C>>
C>> As with the Draft Articles, the Draft Bylaws included here are a
C>> pro-forma, standard version. Substantial alteration may be
C>> required as legal counsel reviews the specific nature of an
C>> incorporation.
C>>
C>> 6.2.1 Article I: Organization
C>>
C>> The name of the Corporation shall be The IETF Administrative
C>> Support Foundation (which is hereinafter also referred to as the
C>> "IASF").
C>>
C>> 6.2.2 Article II: Purpose
C>>
C>> *Section 1: Purpose.* The IASF shall be operated exclusively for
C>> nonprofit educational, charitable, and scientific purposes,
C>> including, without limitation, the purposes stated in the IASF's
C>> Articles of Incorporation.
C>>
C>> *Section 2: Restrictions.* No part of the net earnings of the
C>> IASF shall inure to the benefit of, or be distributable to,
C>> private persons, except that the IASF shall be authorized and
C>> empowered to pay reasonable compensation for services rendered,
C>> and to make payments and distributions in furtherance of the
C>> purposes set forth in Article II, Section 1 hereof. Any other
C>> provision of these Bylaws to the contrary notwithstanding, the
C>> IASF shall not carry on any activities not permitted to be
C>> carried on by a corporation exempt from Federal Income Tax under
C>> Section 501(a) and Section 501(c)(3) of the Code. These Bylaws
C>> shall not be altered or amended in derogation of the provisions
C>> of this Section.
C>>
C>> 6.2.3 Article III: Members
C>>
C>> The IASF shall have no members and no stockholders.
C>>
C>> 6.2.4 Article IV: Offices
C>>
C>> The office of the IASF shall be as determined from time to time
C>> by the Board of Trustees (BoT) within or outside of the State of
C>> Virginia.
C>>
C>> 6.2.5 Article V: Board of Trustees
C>>
C>> *Section 1: Authority and Responsibilities.* The power,
C>> authority, property, and affairs of the IASF shall at all times
C>> be exclusively exercised, controlled, and conducted by or under
C>> the authority of the Board of Trustees (BoT) subject to any
C>> limitations set forth in the Articles of Incorporation and in
C>> accordance with the Virginia Nonstock Corporation Act as it now
C>> exists or hereafter may be amended.
C>>
C>> *Section 2: Board of Trustees Composition.* The Board of Trustees
C>> shall consist of seven (7) Trustees.
C>>
C>> One (1) Trustee will be selected by the IAB.
C>>
C>> One (1) Trustee will be selected by the IESG.
C>>
C>> Two (2) Trustees will be selected by the Internet Society.
C>>
C>> Three (3) Trustees will be selected by the IETF community.
C>>
C>> The IAB chair and IETF chair will functions as liaisons from the
C>> IAB and IESG respectively to the Board of Trustees. The chair
C>> and president of the Internet Society will function as liaisons
C>> from the ISOC to the Board of Trustees.
C>>
C>> *Section 3: Terms.* The term of office of IESG and IAB Selected
C>> Trustees shall be one (1) year or until their successors have
C>> been selected and assume office. The term of office of otherwise
C>> Selected Trustees shall be three (3) years or until their
C>> successors have been selected and assume office. Selected
C>> Trustees may be selected to serve multiple terms.
C>>
C>> *Section 4: Selection of the Board of Trustee*
C>>
C>> 1. *Selection of IESG and IAB Selected Trustees.* The IESG and
C>> IAB shall each select one representative Trustee, who is not
C>> at the same time an IESG or IAB member.
C>>
C>> 2. *Selection of otherwise Selected Trustees.* Three (3) IETF
C>> Selected Trustees shall be selected by the IETF nominations
C>> process (as defined in [RFC3777] or its successor) and
C>> confirmed by the IESG. Two ISOC Selected Trustees shall be
C>> selected by the Internet Society using means of their own
C>> choosing.
C>>
C>> 3. *Resignation.* A Selected Trustee may resign by delivering
C>> his resignation in writing to the IASF at its principal
C>> office or to the Secretary of the IASF. Such resignation
C>> shall be effective upon its receipt or upon such date (if
C>> any) as is stated in such resignation, unless otherwise
C>> determined by the Board.
C>>
C>> the authority of the Board of Trustees (BoT) subject to any
C>> limitations set forth in the Articles of Incorporation and in
C>> accordance with the Virginia Nonstock Corporation Act as it now
C>> exists or hereafter may be amended.
C>>
C>> *Section 2: Board of Trustees Composition.* The Board of Trustees
C>> shall consist of seven (7) Trustees.
C>>
C>> One (1) Trustee will be selected by the IAB.
C>>
C>> One (1) Trustee will be selected by the IESG.
C>>
C>> Two (2) Trustees will be selected by the Internet Society.
C>>
C>> Three (3) Trustees will be selected by the IETF community.
C>>
C>> The IAB chair and IETF chair will functions as liaisons from the
C>> IAB and IESG respectively to the Board of Trustees. The chair
C>> and president of the Internet Society will function as liaisons
C>> from the ISOC to the Board of Trustees.
C>>
C>> *Section 3: Terms.* The term of office of IESG and IAB Selected
C>> Trustees shall be one (1) year or until their successors have
C>> been selected and assume office. The term of office of otherwise
C>> Selected Trustees shall be three (3) years or until their
C>> successors have been selected and assume office. Selected
C>> Trustees may be selected to serve multiple terms.
C>>
C>> *Section 4: Selection of the Board of Trustee*
C>>
C>> 1. *Selection of IESG and IAB Selected Trustees.* The IESG and
C>> IAB shall each select one representative Trustee, who is not
C>> at the same time an IESG or IAB member.
C>>
C>> 2. *Selection of otherwise Selected Trustees.* Three (3) IETF
C>> Selected Trustees shall be selected by the IETF nominations
C>> process (as defined in [RFC3777] or its successor) and
C>> confirmed by the IESG. Two ISOC Selected Trustees shall be
C>> selected by the Internet Society using means of their own
C>> choosing.
C>>
C>> 3. *Resignation.* A Selected Trustee may resign by delivering
C>> his resignation in writing to the IASF at its principal
C>> office or to the Secretary of the IASF. Such resignation
C>> shall be effective upon its receipt or upon such date (if
C>> any) as is stated in such resignation, unless otherwise
C>> determined by the Board.
C>>
C>> 4. *Removal.* A Selected Trustee selected by the IETF
C>> nominations process may be removed from office at any time
C>> using the procedures specified in [RFC3777] or its successor.
C>> A Selected Trustee selected by the Internet Society may be
C>> removed by the Internet Society using means of their own
C>> choosing.
C>>
C>> 5. *Vacancies.* Any vacancy in the Board of Trustees shall be
C>> filled using the procedures set forth above on the
C>> composition of the Board of Trustees. The Trustees shall
C>> have and may exercise all of their powers notwithstanding the
C>> existence of one or more vacancies in their number.
C>>
C>> *Section 5: Quorum.* A majority (i.e. fifty (50) percent plus
C>> one (1)) of the Trustees shall constitute a quorum for the
C>> transaction of business. Unless otherwise stated in these
C>>
C>> Bylaws, decisions of the Board of Trustees shall be made by the
C>> concurrence of a majority of members of the Board of Trustees
C>> present and voting. If at any meeting there is no quorum
C>> present, the Board must not transact business.
C>>
C>> *Section 6: Compensation and Reimbursement.* No member of the
C>> Board of Trustees may receive compensation for his or her
C>> services as a Trustee. A Trustee shall, at their request, be
C>> reimbursed for actual, necessary and reasonable travel and
C>> subsistence expenses incurred by them in performance of their
C>> duties.
C>>
C>> *Section 7: Meetings.* The Board of Trustees shall meet at least
C>> twice annually.
C>>
C>> 1. *Written notice, waiver, action.* Wherever the text below
C>> speaks of "written" it is also permitted to use e-mail.
C>>
C>> 2. *Annual Meeting.* The Board of Trustees shall hold a public
C>> Annual Meeting at a time and place associated with the first
C>> IETF meeting each year. This Annual meeting shall be open to
C>> all IETF attendees except that the parts of the meeting
C>> dealing with personnel issues may be held in executive
C>> session.
C>>
C>> 3. *Meeting Types, Methods, and Notice.* Meetings of the Board
C>> may be held from time to time at such intervals and at such
C>> places as may be fixed by the Board. Meetings of the Board
C>> may be held only in person or via teleconference. Notice of
C>> all regular meetings of the Board shall be delivered to each
C>> Trustee by e-mail or by postal mail and announced on the
C>> 4. *Removal.* A Selected Trustee selected by the IETF
C>> nominations process may be removed from office at any time
C>> using the procedures specified in [RFC3777] or its successor.
C>> A Selected Trustee selected by the Internet Society may be
C>> removed by the Internet Society using means of their own
C>> choosing.
C>>
C>> 5. *Vacancies.* Any vacancy in the Board of Trustees shall be
C>> filled using the procedures set forth above on the
C>> composition of the Board of Trustees. The Trustees shall
C>> have and may exercise all of their powers notwithstanding the
C>> existence of one or more vacancies in their number.
C>>
C>> *Section 5: Quorum.* A majority (i.e. fifty (50) percent plus
C>> one (1)) of the Trustees shall constitute a quorum for the
C>> transaction of business. Unless otherwise stated in these
C>>
C>> Bylaws, decisions of the Board of Trustees shall be made by the
C>> concurrence of a majority of members of the Board of Trustees
C>> present and voting. If at any meeting there is no quorum
C>> present, the Board must not transact business.
C>>
C>> *Section 6: Compensation and Reimbursement.* No member of the
C>> Board of Trustees may receive compensation for his or her
C>> services as a Trustee. A Trustee shall, at their request, be
C>> reimbursed for actual, necessary and reasonable travel and
C>> subsistence expenses incurred by them in performance of their
C>> duties.
C>>
C>> *Section 7: Meetings.* The Board of Trustees shall meet at least
C>> twice annually.
C>>
C>> 1. *Written notice, waiver, action.* Wherever the text below
C>> speaks of "written" it is also permitted to use e-mail.
C>>
C>> 2. *Annual Meeting.* The Board of Trustees shall hold a public
C>> Annual Meeting at a time and place associated with the first
C>> IETF meeting each year. This Annual meeting shall be open to
C>> all IETF attendees except that the parts of the meeting
C>> dealing with personnel issues may be held in executive
C>> session.
C>>
C>> 3. *Meeting Types, Methods, and Notice.* Meetings of the Board
C>> may be held from time to time at such intervals and at such
C>> places as may be fixed by the Board. Meetings of the Board
C>> may be held only in person or via teleconference. Notice of
C>> all regular meetings of the Board shall be delivered to each
C>> Trustee by e-mail or by postal mail and announced on the
C>> IETF-Announce list at least ten (10) calendar days before the
C>> meeting. Special meetings of the Board may be called for any
C>> purpose at any time by the Chairman of the Board or by any
C>> three (3) Trustees. Notice of any special meeting shall state
C>> the purpose of the meeting. A Trustee may waive notice of a
C>> meeting of the Board of Trustees by submitting a signed,
C>> written waiver of notice, either before or after the meeting.
C>> A Trustee's attendance at or participation in a meeting
C>> waives any required notice of the meeting unless at the start
C>> of such meeting or promptly upon arrival the Trustee objects
C>> to holding the meeting or transacting business at the
C>> meeting, and does not thereafter vote for or assent to action
C>> taken at the meeting.
C>>
C>> 4. *Actions Taken By the Board of Trustees Without Meeting.* Any
C>> action required or permitted to be taken at any meeting of
C>> the Board of Trustees may be taken without a meeting if all
C>>
C>> Trustees consent in writing to such action. Such action
C>> shall be evidenced by written consents approving the lack of
C>> a meeting, signed by each Trustee.
C>>
C>> *Section 8: Board Committees.* The Trustees may elect or appoint
C>> one or more committees (including but not limited to an Executive
C>> Committee) and may delegate to any such committee or committees
C>> any or all of their powers, provided that any committee to which
C>> the powers of the Trustees are delegated shall consist solely of
C>> Trustees. Committees shall conduct their affairs in the same
C>> manner as is provided in these By Laws for the Trustees. The
C>> members of any committee shall remain in office at the pleasure
C>> of the Board of Trustees.
C>>
C>> *Section 9: Trustee Member Conflict of Interest.*
C>>
C>> 1. As set forth in Section 9(3) below, a Trustee of the IETF
C>> Administrative Support Foundation (IASF) who has a personal
C>> interest in a transaction, as defined below, may not
C>> participate in any discussion of that transaction by the
C>> Trustees of The IASF and may not vote to determine whether to
C>> authorize, approve, or ratify that transaction except as
C>> specifically described below. For purposes of these Bylaws, a
C>> "personal interest" is defined as any act that will provide,
C>> directly or indirectly, a financial benefit or a disparate
C>> benefit individually to the Trustee, or to a company he or
C>> she is employed by, has a significant financial interest in,
C>> or represents in any fashion. However, policies under
C>> consideration by the IASF are likely to have an impact on the
C>> business of every Trustee. It is expected that most policy
C>> IETF-Announce list at least ten (10) calendar days before the
C>> meeting. Special meetings of the Board may be called for any
C>> purpose at any time by the Chairman of the Board or by any
C>> three (3) Trustees. Notice of any special meeting shall state
C>> the purpose of the meeting. A Trustee may waive notice of a
C>> meeting of the Board of Trustees by submitting a signed,
C>> written waiver of notice, either before or after the meeting.
C>> A Trustee's attendance at or participation in a meeting
C>> waives any required notice of the meeting unless at the start
C>> of such meeting or promptly upon arrival the Trustee objects
C>> to holding the meeting or transacting business at the
C>> meeting, and does not thereafter vote for or assent to action
C>> taken at the meeting.
C>>
C>> 4. *Actions Taken By the Board of Trustees Without Meeting.* Any
C>> action required or permitted to be taken at any meeting of
C>> the Board of Trustees may be taken without a meeting if all
C>>
C>> Trustees consent in writing to such action. Such action
C>> shall be evidenced by written consents approving the lack of
C>> a meeting, signed by each Trustee.
C>>
C>> *Section 8: Board Committees.* The Trustees may elect or appoint
C>> one or more committees (including but not limited to an Executive
C>> Committee) and may delegate to any such committee or committees
C>> any or all of their powers, provided that any committee to which
C>> the powers of the Trustees are delegated shall consist solely of
C>> Trustees. Committees shall conduct their affairs in the same
C>> manner as is provided in these By Laws for the Trustees. The
C>> members of any committee shall remain in office at the pleasure
C>> of the Board of Trustees.
C>>
C>> *Section 9: Trustee Member Conflict of Interest.*
C>>
C>> 1. As set forth in Section 9(3) below, a Trustee of the IETF
C>> Administrative Support Foundation (IASF) who has a personal
C>> interest in a transaction, as defined below, may not
C>> participate in any discussion of that transaction by the
C>> Trustees of The IASF and may not vote to determine whether to
C>> authorize, approve, or ratify that transaction except as
C>> specifically described below. For purposes of these Bylaws, a
C>> "personal interest" is defined as any act that will provide,
C>> directly or indirectly, a financial benefit or a disparate
C>> benefit individually to the Trustee, or to a company he or
C>> she is employed by, has a significant financial interest in,
C>> or represents in any fashion. However, policies under
C>> consideration by the IASF are likely to have an impact on the
C>> business of every Trustee. It is expected that most policy
C>> decisions will have a direct or indirect impact on the
C>> Trustee's company, but such a non-individualized interest
C>> does not constitute a "personal interest" as used in these
C>> Bylaws. A "transaction" with The IASF for purposes of these
C>> Bylaws is a contract or consultancy in which the Trustee has
C>> a direct or indirect financial benefit, or a policy under
C>> consideration that will have a disparate and unusual impact
C>> on a business with which the Trustee is directly or
C>> indirectly associated.
C>>
C>> 2. The mere existence of a personal interest by a Trustee of The
C>> IASF in a transaction with the IASF shall not invalidate the
C>> IASF's ability to enter that transaction so long as the
C>> following conditions are met: (i) the material facts of the
C>> personal nature of the transaction with The IASF and the
C>> Trustee's interest in the transaction with the IASF are fully
C>> disclosed to the Board of Trustees of the IASF, either by the
C>> Trustee having a direct or indirect personal interest in the
C>>
C>> transaction with the IASF, or are brought to the attention of
C>> the Board by a third party; or (ii) the BoT of the IASF, by a
C>> vote of the Trustees (without a conflict of interest) of the
C>> IASF vote to authorize, approve, or ratify a transaction with
C>> the IASF; or (iii) the transaction with the IASF in which the
C>> direct or indirect personal interest of a IASF Trustee was
C>> disclosed to the BoT of The IASF and was determined by the
C>> BoT of the IASF entitled to vote on the matter is determined
C>> by the BoT voting to be in the IASF's interests,
C>> notwithstanding the personal interest of the non-voting
C>> Trustee.
C>>
C>> 3. In determining whether a conflict of interest exists, the BoT
C>> of the IASF has the prerogative, upon review of all facts and
C>> circumstances, to make its own determination of whether a
C>> conflict of interest exists and how it is appropriate to
C>> proceed. A Trustee who perceives the possibility of a
C>> conflict of interest for him or herself, or for another Board
C>> member, may raise this issue at any point prior to a vote on
C>> any issue. Any Trustee who perceives a possible conflict of
C>> interest may present justification with respect to whether or
C>> not a conflict of interest exists, but the entire Board, with
C>> the exception of the Trustee having the potential conflict of
C>> interest, shall make the final determination to proceed in
C>> such a matter. If the BoT finds there is a conflict of
C>> interest, the Trustee with the conflict may be excluded by
C>> the Chair of the Board from that portion of any meeting where
C>> a substantive discussion or decision to engage or not in such
C>> decisions will have a direct or indirect impact on the
C>> Trustee's company, but such a non-individualized interest
C>> does not constitute a "personal interest" as used in these
C>> Bylaws. A "transaction" with The IASF for purposes of these
C>> Bylaws is a contract or consultancy in which the Trustee has
C>> a direct or indirect financial benefit, or a policy under
C>> consideration that will have a disparate and unusual impact
C>> on a business with which the Trustee is directly or
C>> indirectly associated.
C>>
C>> 2. The mere existence of a personal interest by a Trustee of The
C>> IASF in a transaction with the IASF shall not invalidate the
C>> IASF's ability to enter that transaction so long as the
C>> following conditions are met: (i) the material facts of the
C>> personal nature of the transaction with The IASF and the
C>> Trustee's interest in the transaction with the IASF are fully
C>> disclosed to the Board of Trustees of the IASF, either by the
C>> Trustee having a direct or indirect personal interest in the
C>>
C>> transaction with the IASF, or are brought to the attention of
C>> the Board by a third party; or (ii) the BoT of the IASF, by a
C>> vote of the Trustees (without a conflict of interest) of the
C>> IASF vote to authorize, approve, or ratify a transaction with
C>> the IASF; or (iii) the transaction with the IASF in which the
C>> direct or indirect personal interest of a IASF Trustee was
C>> disclosed to the BoT of The IASF and was determined by the
C>> BoT of the IASF entitled to vote on the matter is determined
C>> by the BoT voting to be in the IASF's interests,
C>> notwithstanding the personal interest of the non-voting
C>> Trustee.
C>>
C>> 3. In determining whether a conflict of interest exists, the BoT
C>> of the IASF has the prerogative, upon review of all facts and
C>> circumstances, to make its own determination of whether a
C>> conflict of interest exists and how it is appropriate to
C>> proceed. A Trustee who perceives the possibility of a
C>> conflict of interest for him or herself, or for another Board
C>> member, may raise this issue at any point prior to a vote on
C>> any issue. Any Trustee who perceives a possible conflict of
C>> interest may present justification with respect to whether or
C>> not a conflict of interest exists, but the entire Board, with
C>> the exception of the Trustee having the potential conflict of
C>> interest, shall make the final determination to proceed in
C>> such a matter. If the BoT finds there is a conflict of
C>> interest, the Trustee with the conflict may be excluded by
C>> the Chair of the Board from that portion of any meeting where
C>> a substantive discussion or decision to engage or not in such
C>> a transaction is made, except that he or she may provide any C>> information that will assist the Trustees in such a matter C>> before leaving such a meeting. C>> C>> *Section 10. Approval of Meeting Minutes.* Minutes of the BoT of C>> the IASF must be approved by a procedure adopted by the board and C>> published on the IASF web site. C>> C>> 6.2.6 Article VI: Officers C>> C>> *Section 1: Number.* The officers of the IASF shall consist of a C>> Chairman of the Board, a Treasurer and a Secretary, and such C>> other inferior officers as the BoT may determine. C>> C>> *Section 2: Election Term of Office and Qualifications.* All C>> officers shall be elected annually by the vote of a majority of C>> the Board of Trustees present and voting (excluding abstentions) C>> at the Annual Meeting. The Treasurer and Secretary need not be C>> members of the Board. The Chair of the IETF nor the chair of the C>> IAB shall be the Chairman of the Board of the IASF. C>> C>> *Section 3: Resignation.* An officer may resign by delivering his C>> written resignation to the IASF at its principal office or to the C>> Chair or Secretary. Such resignation shall be effective upon C>> receipt or upon such date (if any) as is stated in such C>> resignation, unless otherwise determined by the Board. C>> C>> *Section 4: Removal.* The BoT may remove any officer with or C>> without cause by a vote of a majority of the entire number of C>> Trustees then in office, at a meeting of the BoT called for that C>> purpose. An officer may be removed for cause only if notice of C>> such action shall have been given to all of the Trustees prior to C>> the meeting at which such action is to be taken and if the C>> officer so to be removed shall have been given reasonable notice C>> and opportunity to be heard by the BoT. C>> C>> *Section 5: Vacancies.* In case any elected officer position of C>> the IASF becomes vacant, the majority of the Trustees in office, C>> although less than a quorum, may elect an officer to fill such C>> vacancy at the next meeting of the BoT, and the officer so C>> elected shall hold office and serve until the next Annual C>> Meeting. C>> C>> *Section 6: Chairman of the Board.* The Chairman of the Board C>> shall, when present, preside at all meetings of the BoT of the C>> IASF. If the Chairman is not available to preside over a C>> meeting, the majority of the Trustees present shall select C>> another Trustee to preside at that meeting only.
C> >进行交易，但他或她可以在离开此类会议之前提供任何有助于受托人处理此类事宜的信息。C> >C>>*第10节。批准会议记录。*国际会计准则理事会的BoT会议记录必须通过董事会通过的程序批准，并在国际会计准则理事会网站上公布。C> >C>>6.2.6第六条：高级职员C>>C>>*第1节：人数。*国际会计准则理事会的高级职员应包括一名C>>董事长、一名司库和一名秘书，以及BoT可能确定的其他低级职员。C> >C>>*第2节：选举任期和资格。*所有C>>高级管理人员应每年由出席年会并在年会上投票（不包括弃权）的董事会以C>>过半数票选出。司库和秘书不必是董事会的C>>成员。IETF主席或C>>IAB主席应为IASF董事会主席。C> >C>>*第3节：辞职。*高级职员可以通过向国际会计准则理事会总部或其主席或秘书递交其C>>书面辞职书的方式辞职。除非董事会另有决定，否则该辞职应在收到C>>或C>>辞职中规定的日期（如有）生效。C> >C>>*第4节：免职。*BoT可在为该目的召开的BoT会议上，通过当时在任的全体C>>受托人的过半数投票，免职任何有理由或无理由的高级职员。只有在采取此类行动的会议召开之前，已向所有受托人发出此类行动的通知，且已向被免职的高级管理人员发出合理的通知，且BoT有机会听取其意见，才可因故免职高级管理人员。C> >C>>*第5节：空缺。*如果国际会计准则理事会的任何选举产生的高级职员职位空缺，大多数在任受托人（C>>虽然未达到法定人数）可以在BoT的下一次会议上选举一名高级职员来填补该等C>>空缺，并且如此选举产生的高级职员应任职至下一次年度C>>会议。C> >C>>*第6节：董事会主席。*董事会主席在出席会议时，应主持国际会计准则理事会的所有会议。如果主席无法主持C>>会议，出席会议的大多数受托人应选择另一名受托人主持该会议。
C>>
C>> *Section 7: Treasurer.* The Treasurer shall have the custody of
C>> all funds, property, and securities of the IASF, subject to such
C>> regulations as may be imposed by the Board of Trustees. He or
C>> she may be required to give bond for the faithful performance of
C>> his or her duties, in such sum and with such sureties as the BoT
C>> may require or as required by law, whichever is greater. When
C>> necessary or proper, he or she may endorse on behalf of the IASF
C>> for collection, checks, notes and other obligations, and shall
C>> deposit same to the credit of the IASF at such bank or banks or
C>> depository as the BoT may designate. He or she shall make or
C>> cause to be made such payments as may be necessary or proper to
C>> be made on behalf of the IASF. He or she shall enter or cause to
C>> be entered regularly on the books of the IASF to be kept by him
C>> or her for that purpose, full and accurate account of all monies
C>> and obligations received and paid or incurred by him or her for
C>> or on account of the IASF, and shall exhibit such books at all
C>> reasonable times to any Trustee on application at the offices of
C>> the IASF incident to the Office of Treasurer, subject to the
C>> control of the BoT. Certain duties of the Treasurer as may be
C>> specified by the BoT may be delegated by the Treasurer.
C>>
C>> *Section 8: Secretary.* The Secretary shall have charge of such
C>> books, records, documents, and papers as the BoT may determine,
C>> and shall have custody of the corporate seal. The Secretary
C>> shall keep, or cause to be kept the minutes of all meetings of
C>> the BoT. The Secretary may sign, with the Chairman, in the name
C>> and on behalf of the IASF, any contracts or agreements, and he or
C>> she may affix the corporate seal of the IASF. He or she, in
C>> general, performs all the duties incident to the Office of
C>> Secretary, subject to the supervision and control of the Board of
C>> Trustees, and shall do and perform such other duties as may be
C>> assigned to him or her by the BoT or the Chairman of the BoT.
C>> Certain duties of the Secretary as may be specified by the BoT
C>> may be delegated by the Secretary.
C>>
C>> *Section 9: Other Powers and Duties.* Each officer shall have in
C>> addition to the duties and powers specifically set forth in these
C>> By Laws, such duties and powers as are customarily incident to
C>> his office, and such duties and powers as the Trustees may from
C>> time to time designate.
C>>
C>>
C>> *Section 7: Treasurer.* The Treasurer shall have the custody of
C>> all funds, property, and securities of the IASF, subject to such
C>> regulations as may be imposed by the Board of Trustees. He or
C>> she may be required to give bond for the faithful performance of
C>> his or her duties, in such sum and with such sureties as the BoT
C>> may require or as required by law, whichever is greater. When
C>> necessary or proper, he or she may endorse on behalf of the IASF
C>> for collection, checks, notes and other obligations, and shall
C>> deposit same to the credit of the IASF at such bank or banks or
C>> depository as the BoT may designate. He or she shall make or
C>> cause to be made such payments as may be necessary or proper to
C>> be made on behalf of the IASF. He or she shall enter or cause to
C>> be entered regularly on the books of the IASF to be kept by him
C>> or her for that purpose, full and accurate account of all monies
C>> and obligations received and paid or incurred by him or her for
C>> or on account of the IASF, and shall exhibit such books at all
C>> reasonable times to any Trustee on application at the offices of
C>> the IASF incident to the Office of Treasurer, subject to the
C>> control of the BoT. Certain duties of the Treasurer as may be
C>> specified by the BoT may be delegated by the Treasurer.
C>>
C>> *Section 8: Secretary.* The Secretary shall have charge of such
C>> books, records, documents, and papers as the BoT may determine,
C>> and shall have custody of the corporate seal. The Secretary
C>> shall keep, or cause to be kept the minutes of all meetings of
C>> the BoT. The Secretary may sign, with the Chairman, in the name
C>> and on behalf of the IASF, any contracts or agreements, and he or
C>> she may affix the corporate seal of the IASF. He or she, in
C>> general, performs all the duties incident to the Office of
C>> Secretary, subject to the supervision and control of the Board of
C>> Trustees, and shall do and perform such other duties as may be
C>> assigned to him or her by the BoT or the Chairman of the BoT.
C>> Certain duties of the Secretary as may be specified by the BoT
C>> may be delegated by the Secretary.
C>>
C>> *Section 9: Other Powers and Duties.* Each officer shall have in
C>> addition to the duties and powers specifically set forth in these
C>> By Laws, such duties and powers as are customarily incident to
C>> his office, and such duties and powers as the Trustees may from
C>> time to time designate.
C>>
C>> 6.2.7 Article VII: Amendments
C>>
C>> *Section 1: By Laws.* These By Laws may be amended by an
C>> affirmative vote of a majority of the Trustees then in office
C>> (excluding abstentions) at a regular meeting of the board or a
C>> meeting of the board called for that purpose as long as the
C>> proposed changes are made available to all trustees and posted to
C>> the IETF Announce list at least 30 days before any such meeting.
C>>
C>> *Section 2: Articles of Incorporation.* The Articles of
C>> Incorporation of the IASF may be amended by an affirmative vote
C>> of two-thirds of the BoT then in office at a regular meeting of
C>> the board or a meeting of the board called for that purpose as
C>> long as the proposed changes are made available to all trustees
C>> and posted to the IETF Announce list at least 30 days before any
C>> such meeting.
C>>
C>> 6.2.8 Article VIII: Dissolution
C>>
C>> Upon the dissolution of the IASF, the IASF, after paying or
C>> making provisions for the payment of all of the liabilities of
C>> the IASF, dispose of all of the assets of the IASF exclusively
C>> for the exempt purposes of the IASF in such manner or to such
C>> organization or organizations operated exclusively for social
C>> welfare or charitable purposes. Any such assets not so disposed
C>> of shall be disposed of by a court of competent jurisdiction of
C>> the county in which the principal office of the organization is
C>> then located, exclusively for such purposes. In the event of a
C>>
C>> sale or dissolution of the corporation, the surplus funds of the
C>> corporation shall not inure to the benefit of, or be
C>> distributable to, its Trustees, officers, or other private
C>> persons.
C>>
C>> 6.2.9 Article IX: Miscellaneous Provisions
C>>
C>> *Section 1: Fiscal Year.* The fiscal year of the IASF shall be
C>> from January 1 to December 31 of each year.
C>>
C>> *Section 2: Execution of Instruments.* All checks, deeds, leases,
C>> transfers, contracts, bonds, notes and other obligations
C>> authorized to be executed by an officer of the IASF in its behalf
C>> shall be signed by the Chairman of the Board or the Treasurer, or
C>> as the Trustees otherwise determine. A certificate by the
C>> Secretary as to any action taken by the BoT shall as to all
C>> persons who rely thereon in good faith be conclusive evidence of
C>> such action.
C>>
C>> 6.2.7 Article VII: Amendments
C>>
C>> *Section 1: By Laws.* These By Laws may be amended by an
C>> affirmative vote of a majority of the Trustees then in office
C>> (excluding abstentions) at a regular meeting of the board or a
C>> meeting of the board called for that purpose as long as the
C>> proposed changes are made available to all trustees and posted to
C>> the IETF Announce list at least 30 days before any such meeting.
C>>
C>> *Section 2: Articles of Incorporation.* The Articles of
C>> Incorporation of the IASF may be amended by an affirmative vote
C>> of two-thirds of the BoT then in office at a regular meeting of
C>> the board or a meeting of the board called for that purpose as
C>> long as the proposed changes are made available to all trustees
C>> and posted to the IETF Announce list at least 30 days before any
C>> such meeting.
C>>
C>> 6.2.8 Article VIII: Dissolution
C>>
C>> Upon the dissolution of the IASF, the IASF, after paying or
C>> making provisions for the payment of all of the liabilities of
C>> the IASF, dispose of all of the assets of the IASF exclusively
C>> for the exempt purposes of the IASF in such manner or to such
C>> organization or organizations operated exclusively for social
C>> welfare or charitable purposes. Any such assets not so disposed
C>> of shall be disposed of by a court of competent jurisdiction of
C>> the county in which the principal office of the organization is
C>> then located, exclusively for such purposes. In the event of a
C>>
C>> sale or dissolution of the corporation, the surplus funds of the
C>> corporation shall not inure to the benefit of, or be
C>> distributable to, its Trustees, officers, or other private
C>> persons.
C>>
C>> 6.2.9 Article IX: Miscellaneous Provisions
C>>
C>> *Section 1: Fiscal Year.* The fiscal year of the IASF shall be
C>> from January 1 to December 31 of each year.
C>>
C>> *Section 2: Execution of Instruments.* All checks, deeds, leases,
C>> transfers, contracts, bonds, notes and other obligations
C>> authorized to be executed by an officer of the IASF in its behalf
C>> shall be signed by the Chairman of the Board or the Treasurer, or
C>> as the Trustees otherwise determine. A certificate by the
C>> Secretary as to any action taken by the BoT shall as to all
C>> persons who rely thereon in good faith be conclusive evidence of
C>> such action.
C>>
C>> *Section 3: Severability.* Any determination that any provision
C>> of these By-Laws is for any reason inapplicable, illegal or
C>> ineffective shall not affect or invalidate any other provision of
C>> these By-Laws.
C>>
C>> *Section 4: Articles of Incorporation.* All references in these
C>> By Laws to the Articles of Incorporation shall be deemed to refer
C>> to the Articles of Incorporation of the IASF, as amended and in
C>> effect from time to time.
C>>
C>> *Section 5: Gender.* Whenever used herein, the singular number
C>> shall include the plural, the plural shall include the singular,
C>> and the use of any gender shall include all genders.
C>>
C>> *Section 6: Successor Provisions.* All references herein: (1) to
C>> the Internal Revenue Code shall be deemed to refer to the
C>> Internal Revenue Code of 1986, as now in force or hereafter
C>> amended; (2) to the Code of the State of Virginia, or any Chapter
C>> thereof, shall be deemed to refer to such Code or Chapter as now
C>> in force or hereafter amended; (3) the particular sections of the
C>> Internal Revenue Code or such Code shall be deemed to refer to
C>> similar or successor provisions hereafter adopted; and (4) to the
C>> Request for Comment Series shall be deemed to refer to the
C>> Request for Comment Series as they are now in force or hereafter
C>> amended.
C>>
C>> 7. Acknowledgment of Contributions and Reviews
C>>
C>> A lot of text was taken from the report from Carl Malamud.
C>>
C>> Further review was done by various IESG and IAB members. Carl
C>> Malamud also reviewed this document and helped with making the
C>> text better English and easier to read.
C>>
C>> This document was created with "xml2rfc"
C>> <http://xml.resource.org/> using the format specified
C>> in [RFC2629].
C>>
C>> 8. IANA Considerations
C>>
C>> This documents requires no action from IANA.
C>>
C>> *Section 3: Severability.* Any determination that any provision
C>> of these By-Laws is for any reason inapplicable, illegal or
C>> ineffective shall not affect or invalidate any other provision of
C>> these By-Laws.
C>>
C>> *Section 4: Articles of Incorporation.* All references in these
C>> By Laws to the Articles of Incorporation shall be deemed to refer
C>> to the Articles of Incorporation of the IASF, as amended and in
C>> effect from time to time.
C>>
C>> *Section 5: Gender.* Whenever used herein, the singular number
C>> shall include the plural, the plural shall include the singular,
C>> and the use of any gender shall include all genders.
C>>
C>> *Section 6: Successor Provisions.* All references herein: (1) to
C>> the Internal Revenue Code shall be deemed to refer to the
C>> Internal Revenue Code of 1986, as now in force or hereafter
C>> amended; (2) to the Code of the State of Virginia, or any Chapter
C>> thereof, shall be deemed to refer to such Code or Chapter as now
C>> in force or hereafter amended; (3) the particular sections of the
C>> Internal Revenue Code or such Code shall be deemed to refer to
C>> similar or successor provisions hereafter adopted; and (4) to the
C>> Request for Comment Series shall be deemed to refer to the
C>> Request for Comment Series as they are now in force or hereafter
C>> amended.
C>>
C>> 7. Acknowledgment of Contributions and Reviews
C>>
C>> A lot of text was taken from the report from Carl Malamud.
C>>
C>> Further review was done by various IESG and IAB members. Carl
C>> Malamud also reviewed this document and helped with making the
C>> text better English and easier to read.
C>>
C>> This document was created with "xml2rfc"
C>> <http://xml.resource.org/> using the format specified
C>> in [RFC2629].
C>>
C>> 8. IANA Considerations
C>>
C>> This documents requires no action from IANA.
C>>
C>> 9. Security Considerations
C>>
C>> This document describes a scenario for the structure of the
C>> IETF's administrative support activities. It introduces no
C>> security considerations for the Internet.
C>>
C>> Safety considerations for the integrity of the standards process
C>> are outlined in Appendix C.
C>>
C>> 10. References
C>>
C>> 10.1 Normative References
C>>
C>> [RFC2026] Bradner, S., "The Internet Standards Process --
C>> Revision 3", BCP 9, RFC 2026, October 1996.
C>>
C>> [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved
C>> in the IETF Standards Process", BCP 11, RFC 2028,
C>> October 1996.
C>>
C>> [RFC2031] Huizer, E., "IETF-ISOC relationship", RFC 2031,
C>> October 1996.
C>>
C>> [RFC3677] Daigle, L. and Internet Architecture Board, "IETF ISOC
C>> Board of Trustee Appointment Procedures", BCP 77, RFC
C>> 3677, December 2003.
C>>
C>> [RFC3716] Advisory, IAB., "The IETF in the Large: Administration
C>> and Execution", RFC 3716, March 2004.
C>>
C>> [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and
C>> Recall Process: Operation of the Nominating and Recall
C>> Committees", BCP 10, RFC 3777, June 2004.
C>>
C>> [Virginia] State of Virginia, "Title 13.1: Corporations, Limited
C>> Liability Companies, Business Trusts", Undated,
C>>
C>> <http://leg1.state.va.us/cgi-
C>> bin/legp504.exe?000+cod+TOC1301000> .
C>>
C>> 10.2 Informative References
C>>
C>> [I-D.ietf-xmpp-core] Saint-Andre, P., "Extensible Messaging and
C>> Presence Protocol (XMPP): Core", draft-ietf-xmpp-
C>> core-24 (work in progress), May 2004.
C>>
C>> 9. Security Considerations
C>>
C>> This document describes a scenario for the structure of the
C>> IETF's administrative support activities. It introduces no
C>> security considerations for the Internet.
C>>
C>> Safety considerations for the integrity of the standards process
C>> are outlined in Appendix C.
C>>
C>> 10. References
C>>
C>> 10.1 Normative References
C>>
C>> [RFC2026] Bradner, S., "The Internet Standards Process --
C>> Revision 3", BCP 9, RFC 2026, October 1996.
C>>
C>> [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved
C>> in the IETF Standards Process", BCP 11, RFC 2028,
C>> October 1996.
C>>
C>> [RFC2031] Huizer, E., "IETF-ISOC relationship", RFC 2031,
C>> October 1996.
C>>
C>> [RFC3677] Daigle, L. and Internet Architecture Board, "IETF ISOC
C>> Board of Trustee Appointment Procedures", BCP 77, RFC
C>> 3677, December 2003.
C>>
C>> [RFC3716] Advisory, IAB., "The IETF in the Large: Administration
C>> and Execution", RFC 3716, March 2004.
C>>
C>> [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and
C>> Recall Process: Operation of the Nominating and Recall
C>> Committees", BCP 10, RFC 3777, June 2004.
C>>
C>> [Virginia] State of Virginia, "Title 13.1: Corporations, Limited
C>> Liability Companies, Business Trusts", Undated,
C>>
C>> <http://leg1.state.va.us/cgi-
C>> bin/legp504.exe?000+cod+TOC1301000> .
C>>
C>> 10.2 Informative References
C>>
C>> [I-D.ietf-xmpp-core] Saint-Andre, P., "Extensible Messaging and
C>> Presence Protocol (XMPP): Core", draft-ietf-xmpp-
C>> core-24 (work in progress), May 2004.
C>>
C>> [I-D.malamud-consultant-report] Malamud, C., "IETF Administrative
C>> Support Functions", draft-malamud-consultant-report-01
C>> (work in progress), September 2004.
C>>
C>> [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
C>> June 1999.
C>>
C>> URIs
C>>
C>> [1] <http://www.state.va.us/cgi-bin/scc-
C>> clerkdl.pl?scc819&Articles_of_Incorporation_-_Nonstock_Corpo
C>> ration>
C>>
C>> Authors' Addresses
C>>
C>> Bert Wijnen
C>> Lucent Technologies
C>> Schagen 33
C>> 3461 GL Linschoten
C>> Netherlands
C>> Phone: +31-348-407-775
C>> EMail: bwijnen at lucent.com
C>>
C>> Harald Tveit Alvestrand
C>> Cisco Systems
C>> Weidemanns vei 27
C>> Trondheim 7043
C>> Norway
C>> EMail: harald at alvestrand.no
C>>
C>> Peter W. Resnick
C>> QUALCOMM Incorporated
C>> 5775 Morehouse Drive
C>> San Diego, CA 92121-1714
C>> US
C>> EMail: presnick at qualcomm.com
C>>
C>> [I-D.malamud-consultant-report] Malamud, C., "IETF Administrative
C>> Support Functions", draft-malamud-consultant-report-01
C>> (work in progress), September 2004.
C>>
C>> [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
C>> June 1999.
C>>
C>> URIs
C>>
C>> [1] <http://www.state.va.us/cgi-bin/scc-
C>> clerkdl.pl?scc819&Articles_of_Incorporation_-_Nonstock_Corpo
C>> ration>
C>>
C>> Authors' Addresses
C>>
C>> Bert Wijnen
C>> Lucent Technologies
C>> Schagen 33
C>> 3461 GL Linschoten
C>> Netherlands
C>> Phone: +31-348-407-775
C>> EMail: bwijnen at lucent.com
C>>
C>> Harald Tveit Alvestrand
C>> Cisco Systems
C>> Weidemanns vei 27
C>> Trondheim 7043
C>> Norway
C>> EMail: harald at alvestrand.no
C>>
C>> Peter W. Resnick
C>> QUALCOMM Incorporated
C>> 5775 Morehouse Drive
C>> San Diego, CA 92121-1714
C>> US
C>> EMail: presnick at qualcomm.com
C>>
C>> Appendix A. Justification, Reasoning and Motivations C>> C>> C>> Quite a bit of the proposals from the consultant report have been C>> incorporated in this recommendation. However, a number of C>> changes have been made. In this section we try to explain which C>> changes were made and why. C>> C>> A.1 Changes to the name of the administrative entity C>> C>> In order to make it very clear that the new and legal C>> administrative entity is separate from the ISOC IETF activity C>> that deals with standardization and protocol development, this C>> recommendation uses "The IETF Administrative Support Foundation" C>> as the name for the corporation to be created. C>> C>> A.2 Domicile C>> C>> Various questions have been raised if the choice of Domicile 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> >附录A.理由、推理和动机C>>C>>C>>顾问报告中的许多建议已纳入本建议中。但是，C>>做了一些更改。在本节中，我们试图解释进行了哪些C>>更改以及原因。C> >C>>A.1更改管理实体的名称C>>C>>为了明确新的合法C>>管理实体与处理标准化和协议开发的ISOC IETF活动C>>分开，本C>>建议使用“IETF管理支持基金会”C>>作为要创建的公司的名称。C> >C>>A.2住所C>>C>>如果住所C>>的选择需要进一步调查，则会提出各种问题。为了取得进展，本C>>文件建议立即做出明确选择，在弗吉尼亚州成立一家总部位于美国C>>的非营利公司。C> >进一步的调查很可能会将整个过程推迟至少半年。C>＞A.3对BOT C>＞C>的构成有一定的改变。咨询报告提出了基于位置的受托人的建议，C> >，这将自动使IAB主席和IETF主席CIETF的董事会成员（IET）的IETF C>行政支持基金会的投票成员。在C>>IETF邮件列表上讨论过，这些人不是因为C>>他们的商业敏锐性而被选中的，而是因为他们的技术领导力。C> >我们不想改变这些标准。另一个担忧是C>>这也可能产生利益冲突。因此，该C>>建议已使IAB和IETF主持与C>>机器人的联络。C> >C>>本C>>建议规定，IAB和IESG可各自选择一名外部C>>人士（即非IAB或IESG成员）作为投票C>>受托人，而不是由IAB和IESG担任投票受托人。C> >C>>三（3）名IETF选定受托人的选择并未改变本建议中的C>>。然而，有一个问题是，Nomcom的C>>当前组成并不是专门为该职位选择C>>人员。因此，随着时间的推移，可能需要定义一个不同的过程来选择这些受托人。
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>>
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>> 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>> 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.
C> >C.3执行风险C>>C>>执行顺利非常重要。我们意识到的风险包括：C>>C>>o我们不能雇佣一个好的IAD C>>C>>o我们不能正确预测现金流，破产C>>C>>o我们不能与Foretec达成协议，没有2005年的会议C>>C>>o我们有糟糕的律师，他们花的时间太长，收费太高C>>C>>o isoc没有钱了，也没有提前告诉我们C> >C>>为了缓解这些问题，我们在本文件中包含了一份拟议的工作计划C>>。重要的是，我们要尽可能多地审查C>>这个工作计划，以确保我们C>>已经考虑了所有可能需要采取的步骤。C> >C>>C.4破产风险C>>C>>不当的管理控制和程序或其他不谨慎的C>>财政或行政做法可能使IETF面临破产风险。谨慎选择受托人、预算审批流程和有条不紊的财政控制系统是将这一风险降至最低的必要条件。C> >C>>C.5法律风险C>>C>>IETF C>>基础法律框架的不当制定可能会使处于领导地位的机构和个人面临潜在的法律风险。本C>>计划下的任何此类风险似乎等同于社区C>>在当前法律框架下面临的风险。通过法律顾问的彻底审查，并使用C>>保险范围，进一步降低了该风险。C> >C>>按照当前最佳C>>实践系列的定义，通过仔细遵守C>>我们的程序和流程，将法律风险降至最低。如果谨慎遵守已设定的流程C>>标准，则精心制定的流程（如管理领导职位选择的BCP C>>文件和C>>定义标准流程）是防范法律C>>风险的最佳保险。遵守公共规则手册和完全开放的过程是IETF C>>社区可以使用的最有效的机制。
Appendix: Scenario O
附录：场景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>>".
本附录复制了2004年9月20日发布的定义情景O的互联网草案的内容。已从该副本中删除目录，并对文本进行了重新格式化，以符合IETF出版指南的要求。每行的前缀都是“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>> 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>> 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>> 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>> 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
O>> purposes.
O>>
O>> o Review IASA functioning with respect to meeting the IETF
O>> community's working needs.
O>>
O>> The IAOC's role is to review, not carry out the work of, the IAD
O>> and IASA. As such, it is expected the IAOC will have monthly
O>> teleconferences and periodic face to face meetings, probably
O>> coincident with IETF plenary meetings, consistent with ensuring
O>> an efficient and effective operation.
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
O>> purposes.
O>>
O>> o Review IASA functioning with respect to meeting the IETF
O>> community's working needs.
O>>
O>> The IAOC's role is to review, not carry out the work of, the IAD
O>> and IASA. As such, it is expected the IAOC will have monthly
O>> teleconferences and periodic face to face meetings, probably
O>> coincident with IETF plenary meetings, consistent with ensuring
O>> an efficient and effective operation.
O>>
O>> 2.1.4 IASA Funding
O>>
O>> The IASA is supported financially in 3 ways:
O>>
O>> 1. IETF meeting revenues. The IAD, in consultation with the
O>> IAOC, sets the meeting fees as part of the budgeting process.
O>> All meeting revenues go to the IASA.
O>>
O>> 2. Designated ISOC donations. The IETF and IASA do no specific
O>> fund raising activities; this maintains separation between
O>> fundraising and standards activities. Any organization
O>> interested in supporting the IETF activity will continue to
O>> be directed to ISOC, and any funds ISOC receives specifically
O>> for IETF activities (as part of an ISOC program that allows
O>> for specific designation) will be put in the IASA bank
O>> account for IASA management.
O>>
O>> 3. Other ISOC support. ISOC will deposit in the IASA account,
O>> each quarter, the funds committed to providing as part of the
O>> IASA budget (where the meeting revenues and specific
O>>
O>> donations do not cover the budget). These funds may come
O>> from member fees or from other revenue streams ISOC may
O>> create.
O>>
O>> Note that the goal is to achieve and maintain a viable IETF
O>> support function based on meeting fees and specified donations,
O>> and the IAOC and ISOC are expected to work together to attain
O>> that goal. (I.e., dropping the meeting fees to $0 and expecting
O>> ISOC to pick up the slack is not desirable; nor is raising the
O>> meeting fees to prohibitive levels to fund all non-meeting-
O>> related activities!).
O>>
O>> Also, in normal operating circumstances, the IASA would look to
O>> have a 6 month operating reserve for its activities. Rather than
O>> having the IASA attempt to accrue that in its bank account, the
O>> IASA looks to ISOC to build and provide that operational reserve
O>> (through whatever mechanism instrument ISOC deems appropriate --
O>> line of credit, financial reserves, etc). Such reserves do not
O>> appear instantaneously; the goal is to reach that level of
O>> reserve by 3 years after the creation of the IASA. It is not
O>> expected that any funds associated with such reserve will be held
O>> in the IASA bank account.
O>>
O>> 2.1.4 IASA Funding
O>>
O>> The IASA is supported financially in 3 ways:
O>>
O>> 1. IETF meeting revenues. The IAD, in consultation with the
O>> IAOC, sets the meeting fees as part of the budgeting process.
O>> All meeting revenues go to the IASA.
O>>
O>> 2. Designated ISOC donations. The IETF and IASA do no specific
O>> fund raising activities; this maintains separation between
O>> fundraising and standards activities. Any organization
O>> interested in supporting the IETF activity will continue to
O>> be directed to ISOC, and any funds ISOC receives specifically
O>> for IETF activities (as part of an ISOC program that allows
O>> for specific designation) will be put in the IASA bank
O>> account for IASA management.
O>>
O>> 3. Other ISOC support. ISOC will deposit in the IASA account,
O>> each quarter, the funds committed to providing as part of the
O>> IASA budget (where the meeting revenues and specific
O>>
O>> donations do not cover the budget). These funds may come
O>> from member fees or from other revenue streams ISOC may
O>> create.
O>>
O>> Note that the goal is to achieve and maintain a viable IETF
O>> support function based on meeting fees and specified donations,
O>> and the IAOC and ISOC are expected to work together to attain
O>> that goal. (I.e., dropping the meeting fees to $0 and expecting
O>> ISOC to pick up the slack is not desirable; nor is raising the
O>> meeting fees to prohibitive levels to fund all non-meeting-
O>> related activities!).
O>>
O>> Also, in normal operating circumstances, the IASA would look to
O>> have a 6 month operating reserve for its activities. Rather than
O>> having the IASA attempt to accrue that in its bank account, the
O>> IASA looks to ISOC to build and provide that operational reserve
O>> (through whatever mechanism instrument ISOC deems appropriate --
O>> line of credit, financial reserves, etc). Such reserves do not
O>> appear instantaneously; the goal is to reach that level of
O>> reserve by 3 years after the creation of the IASA. It is not
O>> expected that any funds associated with such reserve will be held
O>> in the IASA bank account.
O>>
O>> 2.2 IAOC Membership, Selection and Accountability O>> O>> Note: This section is particularly subject to change as we work O>> to find the best way to achieve the key principles. The key O>> principles being adhered to are that while this should be O>> reasonably separate from IETF Standards process management: O>> O>> o the IETF and IAB Chairs need to be involved to a level that O>> permits them to be involved in and oversee the aspects O>> pertinent to their roles in managing the technical work (e.g., O>> the IAB looks after the RFC Editor relationship) O>> O>> o the IETF and IAB Chairs must not be critical path to getting O>> decisions to and through the IASA. O>> O>> The current draft, below, therefore makes the IETF Chair ex O>> officio voting member of the IAOC, and the IAB Chair a non-voting O>> liaison. Future versions may change either or both, depending on O>> what makes sense to the IETF community in its deliberations. O>> O>> The IAOC will consist of seven voting members who will be O>> selected as follows: O>> O>> o 2 members chosen by the IETF Nominations Committee (NomCom) O>> O>> o 1 member chosen by the IESG O>> O>> o 1 member chosen by the IAB O>> O>> o 1 member chosen by the ISOC Board of Trustees O>> O>> o The IETF Chair (ex officio) O>> O>> o The ISOC President/CEO (ex officio) O>> O>> There will also be two non-voting, ex officio liaisons: O>> O>> o The IAB Chair O>> O>> o The IETF Administrative Director O>> O>> The voting members of the IAOC will choose their own chair each O>> year using a consensus mechanism of its choosing. Any appointed O>> voting member of the IAOC may serve as the IAOC Chair (i.e., not O>> the IETF Chair or the ISOC President/CEO). The role of the IAOC O>> Chair is to organize the IAOC. The IAOC Chair has no formal O>> duties for representing the IAOC, except as directed by IAOC O>> consensus.
O> >2.2 IAOC成员资格、选择和责任O>>O>>注：在我们努力寻找实现关键原则的最佳方式时，本节尤其可能会发生变化。所遵循的关键原则是，虽然这应该与IETF标准过程管理合理地分开：IETF和IAB主席需要参与到一个允许他们参与并监督与其在管理技术工作中的角色相关的方面的水平（例如，O>>IAB负责处理RFC编辑器关系）O>>O>>O IETF和IAB主席不得成为通过IASA做出O>>决定的关键途径。因此，以下草案使IETF主席成为IAOC的当然投票成员，IAB主席成为无投票权的O>>联络人。未来的版本可能会改变其中一个或两个，取决于O>>对IET有意义的内容O>>O>>社区在其审议中。O>>O>>IAOC将由七名有投票权的成员组成，这些成员将按如下方式选出：O>>O>>O 2名成员由IETF提名委员会（NomCom）选出O>>O>>O 1由IESG选择的成员O>>O>>O 1由IAB选择的成员O>>O>>O 1由ISOC董事会选择的成员O>>O IETF主席（当然）O>>O>>O ISOC主席/首席执行官（当然）O>>O>>还将有两个无投票权的当然联络人：O>>O IAB主席O>>O>>IETF行政总监O>>O>>IAOC的有投票权成员将使用其选择的协商一致机制，每年选择自己的主席。IAOC的任何指定O>>有投票权成员均可担任IAOC主席（即，不是IETF主席或ISOC主席/首席执行官）。IAOC O>>主席的职责是组织IAOC。IAOC主席没有代表IAOC的正式O>>职责，除非按照IAOC O>>共识的指示。
O>>
O>> The members of the IAOC will typically serve two year terms.
O>> Initially, the IESG and ISOC Board will make one-year
O>> appointments, the IAB will make a two-year appointment, and the
O>> Nomcom will make one one-year appointment and one two-year
O>> appointment to establish a pattern where approximately half of
O>> the IAOC is selected each term.
O>>
O>> The two NomCom selected members will be selected using the
O>> procedures described in RFC 3777. For the initial selection, the
O>> IESG will provide the list of desired qualifications for these
O>> positions. In later years, this list will be provided by the
O>> IAOC.
O>>
O>> While there are no hard rules regarding how the IAB and the IESG
O>> should select members of the IAOC, it is not expected that they
O>> will typically choose current IAB or IESG members, if only to
O>> avoid overloading existing leadership. However, they should
O>> choose people who are familiar with the administrative support
O>> needs of the IAB, the IESG and/or the IETF standards process. It
O>> is suggested that a fairly open process be followed for these
O>> selections, perhaps with an open call for nominations and/or a
O>> period of public comment on the candidates. The IAB and IESG are
O>> encouraged to look at the procedure for IAB selection of ISOC
O>> Trustees for an example of how this might work.
O>>
O>> Although the IAB and IESG will choose some members of the IAOC,
O>> those members will not directly represent the bodies that chose
O>> them. All members of the IAOC are accountable directly to the
O>> IETF community. To receive direct feedback from the community,
O>> the IAOC will hold an open meeting at least once per year at an
O>> IETF meeting. This may take the form of an open IAOC plenary or
O>> a working meeting held during an IETF meeting slot. The form and
O>> contents of this meeting are left to the discretion of the IAOC
O>> Chair.
O>>
O>> Decisions of IAOC members or the entire IAOC are subject to
O>> appeal using the procedures described in RFC 2026. The initial
O>> appeal of an individual decision will go to the full IAOC.
O>> Appeals of IAOC decisions will go to the IESG and continue up the
O>> chain as necessary (to the IAB and the ISOC Board). The IAOC
O>> will play no role (aside from possible administrative support) in
O>> appeals of WG Chair, IESG or IAB decisions.
O>>
O>>
O>> The members of the IAOC will typically serve two year terms.
O>> Initially, the IESG and ISOC Board will make one-year
O>> appointments, the IAB will make a two-year appointment, and the
O>> Nomcom will make one one-year appointment and one two-year
O>> appointment to establish a pattern where approximately half of
O>> the IAOC is selected each term.
O>>
O>> The two NomCom selected members will be selected using the
O>> procedures described in RFC 3777. For the initial selection, the
O>> IESG will provide the list of desired qualifications for these
O>> positions. In later years, this list will be provided by the
O>> IAOC.
O>>
O>> While there are no hard rules regarding how the IAB and the IESG
O>> should select members of the IAOC, it is not expected that they
O>> will typically choose current IAB or IESG members, if only to
O>> avoid overloading existing leadership. However, they should
O>> choose people who are familiar with the administrative support
O>> needs of the IAB, the IESG and/or the IETF standards process. It
O>> is suggested that a fairly open process be followed for these
O>> selections, perhaps with an open call for nominations and/or a
O>> period of public comment on the candidates. The IAB and IESG are
O>> encouraged to look at the procedure for IAB selection of ISOC
O>> Trustees for an example of how this might work.
O>>
O>> Although the IAB and IESG will choose some members of the IAOC,
O>> those members will not directly represent the bodies that chose
O>> them. All members of the IAOC are accountable directly to the
O>> IETF community. To receive direct feedback from the community,
O>> the IAOC will hold an open meeting at least once per year at an
O>> IETF meeting. This may take the form of an open IAOC plenary or
O>> a working meeting held during an IETF meeting slot. The form and
O>> contents of this meeting are left to the discretion of the IAOC
O>> Chair.
O>>
O>> Decisions of IAOC members or the entire IAOC are subject to
O>> appeal using the procedures described in RFC 2026. The initial
O>> appeal of an individual decision will go to the full IAOC.
O>> Appeals of IAOC decisions will go to the IESG and continue up the
O>> chain as necessary (to the IAB and the ISOC Board). The IAOC
O>> will play no role (aside from possible administrative support) in
O>> appeals of WG Chair, IESG or IAB decisions.
O>>
O>> In the event that an IAOC member abrogates his duties or acts
O>> against the bests interests of the IETF community, IAOC members
O>> are subject to recall using the recall procedure defined in RFC
O>> 3777. IAB and IESG-appointed members of the IAOC are not subject
O>> to recall by their appointing bodies.
O>>
O>> 2.3 IASA Budget Process
O>>
O>> While the IASA sets a budget for the IETF's administrative needs,
O>> its budget process clearly needs to be closely coordinated with
O>> ISOC's. The specific timeline will be established each year,
O>> before the second IETF meeting. A general annual timeline for
O>> budgeting will be:
O>>
O>> July 1 The IAD presents a budget proposal (for the following
O>> fiscal year, with 3 year projections) to the IAOC.
O>>
O>> August 1 The IAOC approves the budget proposal for IETF purposes,
O>> after any appropriate revisions. As the ISOC President is
O>> part of the IAOC, the IAOC should have a preliminary
O>> indication of how the budget will fit with ISOC's own
O>> budgetary expectations. The budget proposal is passed to the
O>> ISOC Board of Trustees for review in accordance with their
O>> fiduciary duty.
O>>
O>> September 1 The ISOC Board of Trustees approves the budget
O>> proposal provisionally. During the next 2 months, the budget
O>> may be revised to be integrated in ISOC's overall budgeting
O>> process.
O>>
O>>
O>> November 1 Final budget to the ISOC Board for approval.
O>>
O>> The IAD will provide monthly accountings of expenses, and will
O>> update forecasts of expenditures quarterly. This may necessitate
O>> the adjustment of the IASA budget. The revised budget will need
O>> to be approved by the IAOC and ISOC Board of Trustees.
O>>
O>> 2.4 Relationship of the IAOC to Existing IETF Leadership
O>>
O>> The IAOC will be directly accountable to the IETF Community.
O>> However, the nature of the IAOC's work will involve treating the
O>> IESG and IAB as internal customers. The IAOC should not consider
O>> its work successful unless the IESG and IAB are satisfied with
O>> the administrative support that they are receiving.
O>>
O>> In the event that an IAOC member abrogates his duties or acts
O>> against the bests interests of the IETF community, IAOC members
O>> are subject to recall using the recall procedure defined in RFC
O>> 3777. IAB and IESG-appointed members of the IAOC are not subject
O>> to recall by their appointing bodies.
O>>
O>> 2.3 IASA Budget Process
O>>
O>> While the IASA sets a budget for the IETF's administrative needs,
O>> its budget process clearly needs to be closely coordinated with
O>> ISOC's. The specific timeline will be established each year,
O>> before the second IETF meeting. A general annual timeline for
O>> budgeting will be:
O>>
O>> July 1 The IAD presents a budget proposal (for the following
O>> fiscal year, with 3 year projections) to the IAOC.
O>>
O>> August 1 The IAOC approves the budget proposal for IETF purposes,
O>> after any appropriate revisions. As the ISOC President is
O>> part of the IAOC, the IAOC should have a preliminary
O>> indication of how the budget will fit with ISOC's own
O>> budgetary expectations. The budget proposal is passed to the
O>> ISOC Board of Trustees for review in accordance with their
O>> fiduciary duty.
O>>
O>> September 1 The ISOC Board of Trustees approves the budget
O>> proposal provisionally. During the next 2 months, the budget
O>> may be revised to be integrated in ISOC's overall budgeting
O>> process.
O>>
O>>
O>> November 1 Final budget to the ISOC Board for approval.
O>>
O>> The IAD will provide monthly accountings of expenses, and will
O>> update forecasts of expenditures quarterly. This may necessitate
O>> the adjustment of the IASA budget. The revised budget will need
O>> to be approved by the IAOC and ISOC Board of Trustees.
O>>
O>> 2.4 Relationship of the IAOC to Existing IETF Leadership
O>>
O>> The IAOC will be directly accountable to the IETF Community.
O>> However, the nature of the IAOC's work will involve treating the
O>> IESG and IAB as internal customers. The IAOC should not consider
O>> its work successful unless the IESG and IAB are satisfied with
O>> the administrative support that they are receiving.
O>>
O>> 2.5 ISOC Responsibilities for IASA
O>>
O>> Within ISOC, support for the IASA should be structured to meet
O>> the following goals:
O>>
O>> Transparency: The IETF community should have complete visibility
O>> into the financial and legal structure of the ISOC standards
O>> activity. In particular, the IETF community should have access
O>> to a detailed budget for the entire standards activity,
O>> quarterly financial reports and audited annual financials. In
O>> addition, key contract material and MOUs should be publicly
O>> available. Most of these goals are already met by ISOC today.
O>> The IAOC will be responsible for providing the IETF community
O>> with regular overviews of the state of affairs.
O>>
O>> Unification: As part of this arrangement, ISOC's sponsorship of
O>> the RFC Editor, IAB and IESG, as well as insurance coverage
O>> for the IETF will be managed as part of the IASA under the
O>> IAOC.
O>>
O>> Independence: The IASA should be financially and legally distinct
O>> from other ISOC activities. IETF meeting fees should be
O>> deposited in a separate IETF-specific bank account and used to
O>> fund the IASA under the direction and oversight of the IAOC.
O>> Any fees or payments collected from IETF meeting sponsors
O>> should also be deposited into this account. This account will
O>> be administered by the IAD and used to fund the IASA in
O>> accordance with a budget and policies that are developed as
O>> described above.
O>>
O>> Support: ISOC may, from time to time, choose to transfer other
O>> funds into this account to fund IETF administrative projects
O>> or to cover IETF meeting revenue shortfalls. There may also
O>>
O>> be cases where ISOC chooses to loan money to the IASA to help
O>> with temporary cash flow issues. These cases should be
O>> carefully documented and tracked on both sides. ISOC will
O>> work to provide the 6 month operational reserve for IASA
O>> functioning described above.
O>>
O>> Removability: While there is no current plan to transfer the
O>> legal and financial home of the IASA to another corporation,
O>> the IASA should be structured to enable a clean transition in
O>> the event that the IETF community decides, through BCP
O>> publication, that such a transition is required. In that
O>> case, the IAOC will give ISOC a minimum six months notice
O>> before the transition formally occurs. During that period,
O>> the IAOC and ISOC will work together to create a smooth
O>> 2.5 ISOC Responsibilities for IASA
O>>
O>> Within ISOC, support for the IASA should be structured to meet
O>> the following goals:
O>>
O>> Transparency: The IETF community should have complete visibility
O>> into the financial and legal structure of the ISOC standards
O>> activity. In particular, the IETF community should have access
O>> to a detailed budget for the entire standards activity,
O>> quarterly financial reports and audited annual financials. In
O>> addition, key contract material and MOUs should be publicly
O>> available. Most of these goals are already met by ISOC today.
O>> The IAOC will be responsible for providing the IETF community
O>> with regular overviews of the state of affairs.
O>>
O>> Unification: As part of this arrangement, ISOC's sponsorship of
O>> the RFC Editor, IAB and IESG, as well as insurance coverage
O>> for the IETF will be managed as part of the IASA under the
O>> IAOC.
O>>
O>> Independence: The IASA should be financially and legally distinct
O>> from other ISOC activities. IETF meeting fees should be
O>> deposited in a separate IETF-specific bank account and used to
O>> fund the IASA under the direction and oversight of the IAOC.
O>> Any fees or payments collected from IETF meeting sponsors
O>> should also be deposited into this account. This account will
O>> be administered by the IAD and used to fund the IASA in
O>> accordance with a budget and policies that are developed as
O>> described above.
O>>
O>> Support: ISOC may, from time to time, choose to transfer other
O>> funds into this account to fund IETF administrative projects
O>> or to cover IETF meeting revenue shortfalls. There may also
O>>
O>> be cases where ISOC chooses to loan money to the IASA to help
O>> with temporary cash flow issues. These cases should be
O>> carefully documented and tracked on both sides. ISOC will
O>> work to provide the 6 month operational reserve for IASA
O>> functioning described above.
O>>
O>> Removability: While there is no current plan to transfer the
O>> legal and financial home of the IASA to another corporation,
O>> the IASA should be structured to enable a clean transition in
O>> the event that the IETF community decides, through BCP
O>> publication, that such a transition is required. In that
O>> case, the IAOC will give ISOC a minimum six months notice
O>> before the transition formally occurs. During that period,
O>> the IAOC and ISOC will work together to create a smooth
O>> transition that does not result in any significant service
O>> outages or missed IETF meetings. All contracts that are
O>> executed by ISOC as part of the IASA should either include a
O>> clause allowing termination or transfer by ISOC with six
O>> months notice, or should be transferrable to another
O>> corporation in the event that the IASA is transitioned away
O>> from ISOC in the future. Any accrued funds, and IETF-specific
O>> intellectual property rights (concerning administrative data
O>> and/ or tools) would also be expected to be transitioned to
O>> any new entity, as well.
O>>
O>> Within the constraints outlined above, all other details of how
O>> to structure this activity within ISOC (as a cost center, a
O>> department or a formal subsidiary) should be determined by ISOC
O>> in consultation with the IAOC.
O>>
O>> 3. Workplan for Formalizing the IETF Administrative Support
O>> Activity
O>>
O>> This section proposes a workplan and schedule for formalizing the
O>> IETF administrative support activity (IASA) for the remainder of
O>> 2004 and 2005.
O>>
O>> 3.1 Workplan Goals
O>>
O>> This workplan is intended to satisfy four goals:
O>>
O>> o Satisfy the IETF's need for support functions through 2005,
O>> with a careful transition that minimizes the risk of
O>> substantial disruption to the IETF standards process.
O>>
O>> o Establish IETF community consensus and ISOC approval of a BCP
O>> formalizing the IASA as described in this scenario before any
O>> actions are taken that will have long term effects (hiring,
O>>
O>> contacts, etc.)
O>>
O>> o Make sure that decisions with long term impact, such as hiring
O>> the IAD and establishing contracts for administrative support,
O>> are made by people chosen for that purpose who will be
O>> responsible to the community for the effectiveness of this
O>> effort (the IAD and members of the IAOC) -- not by our already
O>> overloaded technical leadership.
O>>
O>> o Within the above constraints, move as quickly as possible
O>> towards a well-defined administrative support structure that
O>> is transparent and accountable to the IETF community.
O>>
O>> transition that does not result in any significant service
O>> outages or missed IETF meetings. All contracts that are
O>> executed by ISOC as part of the IASA should either include a
O>> clause allowing termination or transfer by ISOC with six
O>> months notice, or should be transferrable to another
O>> corporation in the event that the IASA is transitioned away
O>> from ISOC in the future. Any accrued funds, and IETF-specific
O>> intellectual property rights (concerning administrative data
O>> and/ or tools) would also be expected to be transitioned to
O>> any new entity, as well.
O>>
O>> Within the constraints outlined above, all other details of how
O>> to structure this activity within ISOC (as a cost center, a
O>> department or a formal subsidiary) should be determined by ISOC
O>> in consultation with the IAOC.
O>>
O>> 3. Workplan for Formalizing the IETF Administrative Support
O>> Activity
O>>
O>> This section proposes a workplan and schedule for formalizing the
O>> IETF administrative support activity (IASA) for the remainder of
O>> 2004 and 2005.
O>>
O>> 3.1 Workplan Goals
O>>
O>> This workplan is intended to satisfy four goals:
O>>
O>> o Satisfy the IETF's need for support functions through 2005,
O>> with a careful transition that minimizes the risk of
O>> substantial disruption to the IETF standards process.
O>>
O>> o Establish IETF community consensus and ISOC approval of a BCP
O>> formalizing the IASA as described in this scenario before any
O>> actions are taken that will have long term effects (hiring,
O>>
O>> contacts, etc.)
O>>
O>> o Make sure that decisions with long term impact, such as hiring
O>> the IAD and establishing contracts for administrative support,
O>> are made by people chosen for that purpose who will be
O>> responsible to the community for the effectiveness of this
O>> effort (the IAD and members of the IAOC) -- not by our already
O>> overloaded technical leadership.
O>>
O>> o Within the above constraints, move as quickly as possible
O>> towards a well-defined administrative support structure that
O>> is transparent and accountable to the IETF community.
O>>
O>> 3.2 Workplan Overview O>> O>> There are three major elements to this workplan which can, to O>> some degree, take place in parallel after we establish IETF O>> community consensus to pursue Scenario O: O>> O>> o Finalizing the BCP text and getting it approved by the IETF O>> community and ISOC. O>> O>> o Selecting IASA leadership. This includes appointing an O>> interim IAOC, recruiting the IAD, and eventually appointing O>> the full IAOC. O>> O>> o Negotiating agreements with service providers. This includes O>> determining the structure and work flow of the IASA, deciding O>> which portions of the IASA should be staffed via an open O>> request for proposals (RFP) process, and issuing a RFP for O>> those portions, as well as establishing sole source contracts O>> or MOUs for other portions of the IASA. O>> O>> Each of the three items listed above is described in more detail O>> in the following sections. O>> O>> 3.3 Approval by the IETF Community and ISOC O>> O>> In scenario O, the IASA is formalized in a BCP that is approved O>> by the IETF community and accepted by the ISOC Board of Trustees. O>> There are three steps in this process: O>> O>> 1. Establishment of IETF community consensus that we should O>> pursue Scenario O as defined in a joint IAB/IESG O>> recommendation based on this proposal. This consensus will O>> be established through community discussion and a formal two-O>> week consensus call issued by the IETF chair on the IETF O>> mailing list. O>> O>> 2. Establishment of IETF community consensus on a BCP that O>> formalizes the IASA as described. This consensus would be O>> established through public discussion, a four week IETF Last O>> Call and IESG review and approval. O>> O>> 3. ISOC approval of the BCP and acceptance of ISOC's O>> responsibilities as described therein. This approval and O>> acceptance would be signified by an ISOC Board resolution. O>> O>> The timeline for these three stages is rather long, but there is O>> significant progress that can be made in other areas once we have O>> established IETF community consensus to pursue this scenario.
O> >3.2工作计划概述O>>O>>在我们建立IETF O>>社区共识以追求场景O:O>>O>>O>>O最终确定BCP文本并获得IETF O>>社区和ISOC批准后，本工作计划的三个主要元素在一定程度上可以并行进行。O> >O>>O选择IASA领导层。这包括任命一名O>>临时IAOC，招募IAD，并最终任命O>>正式IAOC。O> >O>>O与服务提供商协商协议。这包括O>>确定IASA的结构和工作流程，决定O>>应通过开放的O>>征求建议书（RFP）流程为IASA的哪些部分配备人员，为O>>这些部分发布RFP，以及为IASA的其他部分建立唯一来源合同O>>或MOU。O> >O>>以上列出的三项中的每一项都将在以下章节中进行更详细的描述。O> >O>>3.3 IETF社区和ISOC的批准在场景O中，IASA在BCP中正式化，该BCP由IETF社区批准，并由ISOC董事会接受。O> >此过程有三个步骤：O>>O>>1。建立IETF社区共识，即我们应根据本提案执行IAB/IESG O>>联合建议中定义的场景O。该共识将通过社区讨论和IETF主席在IETF O>>邮件列表上发布的为期两周的正式共识电话来建立。O> >O>>2。建立IETF社区对BCP的共识，使IASA正式化，如所述。这一共识将通过公开讨论、为期四周的IETF Last O>>电话会议以及IESG审查和批准而确立。O> >O>>3。ISOC批准BCP并接受ISOC的O>>职责，如其中所述。此批准和接受将通过ISOC委员会决议表示。O> >O>>这三个阶段的时间表相当长，但一旦我们建立了IETF社区共识来追求这一情景，就可以在其他领域取得重大进展。
O>>
O>> 3.4 Selecting IASA Leadership
O>>
O>> Once we have IETF consensus to pursue this scenario, we can
O>> appoint an interim IAOC to begin working on the IASA transition.
O>> The interim IAOC could do substantial work on non-binding tasks,
O>> such as beginning the recruitment process for an IAD, determining
O>> the structure of the IASA work, issuing RFPs and negotiating
O>> potential agreements with service providers. The interim IAOC
O>> would not be empowered to make binding agreements, but could work
O>> appropriate consultants and advisors to make a lot of progress
O>> towards determining the initial structure and work flow of the
O>> IASA.
O>>
O>> Because the IETF Nominations Commitee (NomCom) process for new
O>> positions will consume a lot of resources and take a long time to
O>> complete, we propose that the interim IAOC consist of:
O>>
O>> o 1 IESG selected member
O>>
O>> o 1 IAB selected member
O>>
O>> o 1 ISOC selected member
O>>
O>> o The IETF Chair
O>>
O>> o The ISOC President/CEO
O>>
O>> The IAB chair will serve as a liaison, as described above.
O>>
O>> The IESG and ISOC Board appointments will be expected to serve
O>> until the first IETF meeting of 2006, and the IAB appointment
O>> will be expected to serve until the first IETF meeting of 2007,
O>> assuming that the BCP is approved and the IAOC continues to have
O>> appointed members from these bodies.
O>>
O>>
O>> After all of the interim IAOC members are selected, they will
O>> choose an interim IAOC chair from among the appointed members.
O>>
O>> When the BCP is approved, if the BCP indicates that there will be
O>> NomCom selected IAOC members they will be chosen at that time.
O>> Any adjustments to appointed members based on the BCP contents
O>> will also be made at that time. The IAOC will transition from
O>> interim to non-interim status when all non-interim members are
O>> seated. A new, non-interim chair selection process will then
O>> commence.
O>>
O>>
O>> 3.4 Selecting IASA Leadership
O>>
O>> Once we have IETF consensus to pursue this scenario, we can
O>> appoint an interim IAOC to begin working on the IASA transition.
O>> The interim IAOC could do substantial work on non-binding tasks,
O>> such as beginning the recruitment process for an IAD, determining
O>> the structure of the IASA work, issuing RFPs and negotiating
O>> potential agreements with service providers. The interim IAOC
O>> would not be empowered to make binding agreements, but could work
O>> appropriate consultants and advisors to make a lot of progress
O>> towards determining the initial structure and work flow of the
O>> IASA.
O>>
O>> Because the IETF Nominations Commitee (NomCom) process for new
O>> positions will consume a lot of resources and take a long time to
O>> complete, we propose that the interim IAOC consist of:
O>>
O>> o 1 IESG selected member
O>>
O>> o 1 IAB selected member
O>>
O>> o 1 ISOC selected member
O>>
O>> o The IETF Chair
O>>
O>> o The ISOC President/CEO
O>>
O>> The IAB chair will serve as a liaison, as described above.
O>>
O>> The IESG and ISOC Board appointments will be expected to serve
O>> until the first IETF meeting of 2006, and the IAB appointment
O>> will be expected to serve until the first IETF meeting of 2007,
O>> assuming that the BCP is approved and the IAOC continues to have
O>> appointed members from these bodies.
O>>
O>>
O>> After all of the interim IAOC members are selected, they will
O>> choose an interim IAOC chair from among the appointed members.
O>>
O>> When the BCP is approved, if the BCP indicates that there will be
O>> NomCom selected IAOC members they will be chosen at that time.
O>> Any adjustments to appointed members based on the BCP contents
O>> will also be made at that time. The IAOC will transition from
O>> interim to non-interim status when all non-interim members are
O>> seated. A new, non-interim chair selection process will then
O>> commence.
O>>
O>> 3.5 Recruiting the IETF Administrative Director O>> O>> The interim IAOC should appoint an IAD selection committee to O>> recruit and select the IETF Administrative Director. This O>> committee will consist entirely of IAOC members or liaisons, and O>> will, at minimum, include the IETF chair and the ISOC President. O>> If the IAOC chooses, this committee could include the entire O>> IAOC. O>> O>> The IAD selection committee should determine a job description O>> for the IAD, in consultation with other IETF leaders and the IETF O>> community. Once the job description is established, the IAD O>> selection committee should recruiting candidates for the O>> position. O>> O>> Although the interim IAOC is not empowered to hire the IAD as a O>> full-time employee, it might be possible for the IAOC to ask ISOC O>> to engage the potential IAD as a consultant to help with other O>> tasks during the interim period. O>> O>> 3.6 Establishing Agreement with Service Providers O>> O>> The most important activity of the IAOC during late 2004 and O>> early 2005 will be to determine the structure and work flow of O>> the IASA and to establish contracts or other agreements with O>> service providers to do the required work. This work includes O>> the following functions as defined in the consultant's report: O>> O>> o Technical infrastructure O>> O>> o Meeting management O>> O>> o Clerk's office O>> O>> o RFC Editor services to support IETF standards publication O>> O>> o IANA services to support IETF standards publication O>> O>> The interim IAOC should work with IETF leaders and other O>> knowledgeable members of the community to determine the structure O>> and work flow required for the IASA activity and make O>> corresponding adjustments to the above list, if necessary. The O>> interim IAOC can also identify which areas of IASA work should O>> continue to be provided by existing IETF service providers, and O>> work with those providers to establish proposed contracts or O>> agreements for later approval by the non-interim IAOC. The IAOC O>> can also choose to start an RFP process for any services that O>> they believe should be filled through an open RFP process.
O> >3.5招募IETF行政总监O>>O>>临时IAOC应任命一个IAD遴选委员会来招募和遴选IETF行政总监。该O>>委员会将完全由IAOC成员或联络人组成，并且O>>将至少包括IETF主席和ISOC主席。O> >如果IAOC选择，该委员会可以包括整个O>>IAOC。O> >O>>IAD遴选委员会应与其他IETF领导人和IETF O>>社区协商，确定IAD的工作描述。一旦职位描述确定，IAD O>>选拔委员会应为O>>职位招聘候选人。O> >O>>尽管临时IAOC无权雇佣IAD作为O>>全职员工，但IAOC可能会要求ISOC O>>聘请潜在IAD作为顾问，在临时期间帮助其他O>>任务。O> >O>>3.6与服务提供商签订协议O>>O>>IAOC在2004年末和2005年初最重要的活动是确定IASA的结构和工作流程，并与O>>服务提供商签订合同或其他协议，以完成所需工作。这项工作包括顾问报告中定义的以下功能：O>>O>>O技术基础设施O>>O会议管理O>>O办事员办公室O>>O支持IETF标准发布的RFC编辑器服务O>>O支持IETF标准发布的IANA服务O>>O临时IAOC应与IETF领导人和社区其他知识渊博的成员确定IASA活动所需的结构和工作流程，并在必要时对上述列表进行相应调整。O>>临时IAOC还可以确定现有IETF服务提供商应继续提供O>>的IASA工作的哪些领域，并且O>>与这些提供商合作，建立拟定合同或O>>协议，以供非临时IAOC稍后批准。IAOC O>>还可以选择对其认为应通过开放式RFP流程填写的任何服务启动RFP流程。
O>> O>> 3.7 Establishing a 2005 Operating Budget O>> O>> Because the ISOC 2005 budgeting process will be finalized before O>> the non-interim IAOC is seated, the interim IAOC should work with O>> the ISOC staff and President to establish a proposed 2005 O>> operating budget for the IASA. Since this will happen in advance O>> of full knowledge regarding the costs of 2005 operations, it may O>> be subject to significant adjustment later. O>> O>> 3.8 Proposed Schedule for IASA Transition O>> O>> As described above, the three stages of the IETF community and O>> ISOC approval process will take some time. If the community O>> chooses scenario O and we reach quick consensus on the details, O>> an optimistic schedule for this approval would be: O>> O>> 1. IETF discussion of this proposal and other scenarios through O>> 1-Oct-2005. IAB/IESG discusses this proposal with ISOC O>> Board. O>> O>> 2. IAB/IESG joint recommendation issued on 8-Oct-04, including O>> full BCP proposal. O>> O>> 3. Community discussion of the joint IAB/IESG recommendation O>> through 22-Oct-04. O>> O>> 4. Two-week community consensus call issued on the IETF list on O>> 23-Oct-04 regarding rough community consensus to pursue this O>> direction and appoint an interim IAOC -- extends through O>> IETF 61. IAOC selecting bodies begin search, based on O>> expected community consensus. O>> O>> 5. Rough community consensus declared on 8-Nov-04 to pursue O>> Scenario O and appoint the interim IAOC. O>> O>> 6. Interim IAOC seated on 15-Nov-04. Interim IAOC begins O>> interim work outlined above, including establishment of O>> O>> estimated 2005 budget and IAD recruitment. O>> O>> 7. BCP text discussed by community, IETF leadership and ISOC O>> Board until we have something that represents rough O>> community consensus that is acceptable to all. We hope that O>> this could be completed by 6-Dec-04. O>> O>> 8. Four week IETF Last Call issued for BCP on 6-Dec-04 -- O>> extends through 3-Jan-04.
O> >O>>3.7制定2005年运营预算O>>O>>由于ISO 2005预算流程将在非临时IAOC就任之前完成，临时IAOC应与O>>ISO员工和总裁合作，为IASA制定拟议的2005年运营预算。由于这将在完全了解2005年运营成本的情况下提前发生，因此可能会在以后进行重大调整。O> 如上文所述，IETF社区的三个阶段和ISOC批准流程将需要一些时间。如果社区O>>选择方案O，并且我们就细节达成快速共识，O>>此批准的乐观时间表将是：O>>O>>1。IETF通过O>>2005年10月1日对本提案和其他场景的讨论。IAB/IESG与ISOC O>>委员会讨论了该提案。O> >O>>2。IAB/IESG于2004年10月8日发布的联合建议，包括完整的BCP提案。O> >O>>3。社区讨论IAB/IESG联合建议O>>至2004年10月22日。O> >O>>4。2004年10月23日在IETF名单上发布了为期两周的社区共识呼吁，内容是关于社区达成大致共识，以追求这一方向，并任命临时IAOC——通过IETF 61扩展。IAOC选择机构开始搜索，基于O>>预期的社区共识。O> >O>>5。2004年11月8日，社区大致达成共识，以实施O>>方案O并任命临时IAOC。O> 6。临时IAOC于2004年11月15日就座。临时IAOC开始上述临时工作，包括制定2005年预算和IAD招聘。O> >O>>7。社区、IETF领导层和ISOC O>>委员会讨论BCP文本，直到我们有了一些代表所有人都能接受的粗略的O>>社区共识。我们希望这项工作能在2004年12月6日前完成。O> >O>>8。2004年12月6日为BCP发布的为期四周的IETF最后一次呼叫--O>>将持续到2004年1月3日。
O>>
O>> 9. Simultaneous IESG and ISOC Board approvals by 17-Jan-04.
O>>
O>> 10. IAD officially hired in Jan 2005.
O>>
O>> 11. NomCom seats IAOC members at the first IETF of 2005, moving
O>> the IAOC from interim to non-interim status.
O>>
O>> 12. Formal agreements with all service providers in-place by
O>> June 2005.
O>>
O>> 4. Security Considerations
O>>
O>> This document describes a scenario for the structure of the
O>> IETF's administrative support activities. It introduces no
O>> security considerations for the Internet.
O>>
O>> 5. IANA Considerations
O>>
O>> This document has no IANA considerations in the traditional
O>> sense. As part of the extended IETF family, though, IANA may be
O>> interested in the contents.
O>>
O>> 6. Acknowledgements
O>>
O>> Most of the ideas in this document are not new, and many of them
O>> did not originate with the authors. This scenario represents a
O>> combination of ideas discussed within the IAB, the IESG and the
O>> IETF Community.
O>>
O>> This document was written using the xml2rfc tool described in RFC
O>> 2629 [RFC2629].
O>>
O>> 7. References
O>>
O>> 7.1 Normative References
O>>
O>> [I-D.malamud-consultant-report] Malamud, C., "IETF Administrative
O>> Support Functions", draft-malamud-consultant-report-01
O>>
O>> (work in progress), September 2004.
O>>
O>> [RFC2026] Bradner, S., "The Internet Standards Process --
O>> Revision 3", BCP 9, RFC 2026, October 1996.
O>>
O>> [RFC3716] Advisory, IAB., "The IETF in the Large: Administration
O>> and Execution", RFC 3716, March 2004.
O>>
O>>
O>> 9. Simultaneous IESG and ISOC Board approvals by 17-Jan-04.
O>>
O>> 10. IAD officially hired in Jan 2005.
O>>
O>> 11. NomCom seats IAOC members at the first IETF of 2005, moving
O>> the IAOC from interim to non-interim status.
O>>
O>> 12. Formal agreements with all service providers in-place by
O>> June 2005.
O>>
O>> 4. Security Considerations
O>>
O>> This document describes a scenario for the structure of the
O>> IETF's administrative support activities. It introduces no
O>> security considerations for the Internet.
O>>
O>> 5. IANA Considerations
O>>
O>> This document has no IANA considerations in the traditional
O>> sense. As part of the extended IETF family, though, IANA may be
O>> interested in the contents.
O>>
O>> 6. Acknowledgements
O>>
O>> Most of the ideas in this document are not new, and many of them
O>> did not originate with the authors. This scenario represents a
O>> combination of ideas discussed within the IAB, the IESG and the
O>> IETF Community.
O>>
O>> This document was written using the xml2rfc tool described in RFC
O>> 2629 [RFC2629].
O>>
O>> 7. References
O>>
O>> 7.1 Normative References
O>>
O>> [I-D.malamud-consultant-report] Malamud, C., "IETF Administrative
O>> Support Functions", draft-malamud-consultant-report-01
O>>
O>> (work in progress), September 2004.
O>>
O>> [RFC2026] Bradner, S., "The Internet Standards Process --
O>> Revision 3", BCP 9, RFC 2026, October 1996.
O>>
O>> [RFC3716] Advisory, IAB., "The IETF in the Large: Administration
O>> and Execution", RFC 3716, March 2004.
O>>
O>> 7.2 Informative References
O>>
O>> [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
O>> June 1999.
O>>
O>> [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
O>> RFC 3667, February 2004.
O>>
O>> [RFC3668] Bradner, S., "Intellectual Property Rights in IETF
O>> Technology", BCP 79, RFC 3668, February 2004.
O>>
O>> Authors' Addresses
O>>
O>> Leslie Daigle
O>> VeriSign
O>> EMail: leslie at verisignlabs.com, leslie at thinkingcat.com
O>>
O>> Margaret Wasserman
O>> ThingMagic
O>> One Broadway, 14th Floor
O>> Cambridge, MA 02142 USA
O>>
O>> Phone: +1 617 758-4177
O>> EMail: margaret at thingmagic.com
O>> URI: http://www.thingmagic.com
O>> 7.2 Informative References
O>>
O>> [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
O>> June 1999.
O>>
O>> [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
O>> RFC 3667, February 2004.
O>>
O>> [RFC3668] Bradner, S., "Intellectual Property Rights in IETF
O>> Technology", BCP 79, RFC 3668, February 2004.
O>>
O>> Authors' Addresses
O>>
O>> Leslie Daigle
O>> VeriSign
O>> EMail: leslie at verisignlabs.com, leslie at thinkingcat.com
O>>
O>> Margaret Wasserman
O>> ThingMagic
O>> One Broadway, 14th Floor
O>> Cambridge, MA 02142 USA
O>>
O>> Phone: +1 617 758-4177
O>> EMail: margaret at thingmagic.com
O>> URI: http://www.thingmagic.com
Informative References
资料性引用
[1] IAB Advisory Committee, "The IETF in the Large: Administration and Execution", RFC 3716, March 2004.
[1] IAB咨询委员会，“整体IETF：管理和执行”，RFC 37162004年3月。
[2] Malamud, C., "IETF Administrative Support Functions", Work in Progress, September 2004.
[2] Malamud，C.，“IETF行政支持职能”，正在进行的工作，2004年9月。
[3] <http://www.ietf.org/mail-archive/web/ietf/current/
msg31321.html>
[3] <http://www.ietf.org/mail-archive/web/ietf/current/
msg31321.html>
[4] <http://www.ietf.org/mail-archive/web/ietf/current/
msg31326.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>
[5] <http://www.ietf.org/mail-archive/web/ietf/current/
msg31493.html>
[6] <http://www.ietf.org/mail-archive/web/ietf/current/
msg31609.html>
[6] <http://www.ietf.org/mail-archive/web/ietf/current/
msg31609.html>
Author's Address
作者地址
Scott Hollenbeck, Editor IAB and IESG
斯科特·霍伦贝克，IAB和IESG编辑
EMail: sah@428cobrajet.net
EMail: sah@428cobrajet.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。