Network Working Group IAB Advisory Committee
Request for Comments: 3716 IETF
Category: Informational March 2004
The IETF in the Large: Administration and Execution
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 (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
In the fall of 2003, the IETF Chair and the IAB Chair formed an IAB Advisory Committee (AdvComm), with a mandate to review the existing IETF administrative structure and relationships (RFC Editor, IETF Secretariat, IANA) and to propose changes to the IETF management process or structure to improve the overall functioning of the IETF. The AdvComm mandate did not include the standards process itself.
2003年の秋には、IETF議長とIAB議長は、既存のIETF行政構造との関係（RFC編集者、IETF事務局、IANA）を確認し、IETFへの変更を提案することを使命と、IAB諮問委員会（AdvComm）を形成しましたIETFの全体的な機能を改善するための管理プロセスや構造。 AdvCommの任務は、標準化プロセス自体は含まれていませんでした。
This memo documents the AdvComm's findings and proposals.
このメモはAdvCommの調査結果と提言を文書化します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview of the AdvComm Work Process and Output. . . . 3
1.2. Scope. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Next Steps . . . . . . . . . . . . . . . . . . . . . . 4
2. Observations . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Current IETF Support Structure . . . . . . . . . . . . 4
2.1.1. What the Term IETF Includes in this Document . 4
2.1.2. Functions. . . . . . . . . . . . . . . . . . . 4
2.1.3. Support. . . . . . . . . . . . . . . . . . . . 6
2.2. Observed Stress Points . . . . . . . . . . . . . . . . 8
2.2.1. Stress Points Observed by IETF Leadership. . . 8
2.2.2. Stress Points Observed by Organizations
Supporting the IETF. . . . . . . . . . . . . . 10
2.3. A final Observation. . . . . . . . . . . . . . . . . . 10
3. Stand Facing the Future: Requirements for a Successful
IETF Administration. . . . . . . . . . . . . . . . . . . . . 10
3.1. Resource Management. . . . . . . . . . . . . . . . . . 10
3.1.1. Uniform Budgetary Responsibility . . . . . . . 10
3.1.2. Revenue Source Equivalence . . . . . . . . . . 11
3.1.3. Clarity in Relationship with Supporting
Organizations. . . . . . . . . . . . . . . . . 11
3.1.4. Flexibility in Service Provisioning. . . . . . 11
3.1.5. Administrative Efficiency. . . . . . . . . . . 11
3.2. Stewardship. . . . . . . . . . . . . . . . . . . . . . 12
3.2.1. Accountability for Change. . . . . . . . . . . 12
3.2.2. Persistence and Accessibility of Records . . . 12
3.3. Working Environment. . . . . . . . . . . . . . . . . . 12
3.3.1. Service Automation . . . . . . . . . . . . . . 12
3.3.2. Tools. . . . . . . . . . . . . . . . . . . . . 13
4. Advisory Committee Advice . . . . . . . . . . . . . . . . . 13
4.1. Proposed: (Single) Formalized IETF Organizational
Entity . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. Comments on the Necessity of this
Formalization. . . . . . . . . . . . . . . . . 14
4.2. Possible Structures. . . . . . . . . . . . . . . . . . 14
4.2.1. ISOC . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. ISOC Subsidiary. . . . . . . . . . . . . . . . 15
4.2.3. Completely Autonomous Organizational Entity. . 16
4.3. Who Can Decide . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations. . . . . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
7. Informative References . . . . . . . . . . . . . . . . . . . 18
A. IAB Advisory Committee Charter . . . . . . . . . . . . . . . 19
B. Input from the current IETF and IAB Chairs . . . . . . . . . 20
C. Consultation with ISI: RFC Editor . . . . . . . . . . . . . 21
D. Consultation with Foretec/CNRI: Secretariat and Meeting
Planning . . . . . . . . . . . . . . . . . . . . . . . . . . 32
E. Consultation with ICANN: IANA Protocol Parameter
Assignment . . . . . . . . . . . . . . . . . . . . . . . . . 35
Author's Address . . . . . . . . . . . . . . . . . . . . . . 39
Full Copyright Statement . . . . . . . . . . . . . . . . . . 40
In the fall of 2003, the IETF Chair and the IAB Chair formed an IAB Advisory Committee (AdvComm), with a mandate to review the existing IETF administrative structure and relationships (RFC Editor, IETF Secretariat, IANA) and to propose changes to the IETF management process or structure to improve the overall functioning of the IETF. This purpose was defined in the IAB Advisory Committee (AdvComm) charter, copied in Appendix A. The AdvComm mandate did not include the standards process itself.
2003年の秋には、IETF議長とIAB議長は、既存のIETF行政構造との関係（RFC編集者、IETF事務局、IANA）を確認し、IETFへの変更を提案することを使命と、IAB諮問委員会（AdvComm）を形成しましたIETFの全体的な機能を改善するための管理プロセスや構造。この目的は、標準化プロセス自体は含まれていませんでした付録A.ザ・AdvCommの任務にコピーし、IAB諮問委員会（AdvComm）憲章に規定されました。
The tangible output of this committee is a set of observations and recommendations for the IETF's executive structure - how the IETF might be organizationally (re)structured so that it can effectively and efficiently carry out its administrative activities. As a necessary preamble to that, a description of the current issues and future requirements is presented. The output does not represent any decision-making or implementation -- see Section 1.3 for a discussion of follow-on steps.
この委員会の具体的な出力は、IETFのエグゼクティブ構造のための所見と勧告のセットです - それは効果的かつ効率的な管理活動を行うことができるようにIETFが組織的に（再）にどのように構成されますか。そのために必要な前提として、現在の課題や将来の要件の説明が提示されます。出力は、任意の意思決定や実装を表すものではありません - 後続のステップの議論については、セクション1.3を参照してください。
The AdvComm was formed in September 2003, and carried out its work over the course of the following 2 months, prior to the IETF58 in November of 2003.
AdvCommは2003年9月に形成されており、2003年の11月に前IETF58に、以下の2カ月間にわたってその作業を行いました。
The AdvComm's membership included many of the individuals who are, or have been, volunteered to manage the IETF's inter-organization administrative relationships in recent years. The first phase of the committee's work, therefore, included sharing and discussing the body of tacit knowledge about those relationships. This included the input from the current IETF and IAB Chairs in Appendix B, and yielded the IETF organizational structure information in Section 2.1.
AdvCommの会員がいる、またはされている個人の多くが含まれ、近年ではIETFの組織間管理の関係を管理するために志願しました。委員会の作業の第一段階は、それゆえ、共有し、それらの関係についての暗黙知の身体を議論含まれていました。この付録Bに現在IETFとIAB議長からの入力を含めて、2.1項におけるIETF組織構造の情報が得られました。
The committee also sought input from the other end of the key existing administrative relationships (RFC Editor, Secretariat, and IANA). The output of those efforts is included in Appendix C, Appendix D, and Appendix E, and these were also used as the basis for the observations in Section 2.
委員会はまた、主要な既存の管理の関係（RFC編集者、事務局、およびIANA）のもう一方の端からの入力を求めました。これらの努力の出力は、付録C、付録D、および付録Eに含まれ、そしてこれらはまた、第2の観測のための基礎として使用しました。
From these inputs, the committee drew together a list of requirements for successful future IETF administration, documented in Section 3.
これらの入力から、委員会は、第3節で文書化、将来の成功IETF投与のための要件のリストを一緒に描きました。
Finally, the committee put together some advice for how the IETF might consider reorganizing its administrative structure to meet those requirements moving forward -- Section 4.
第4節を - 最後に、委員会は、IETFが前進これらの要件を満たすためにその管理構造の再編成を検討する方法について、いくつかのアドバイスをまとめます。
The AdvComm endeavored to stay focused on the IETF executive structure -- the collection of organizations that work together to bring the IETF's work to reality. However, by virtue of the very fact that those relationships exist to get the work done, it was important to bear in mind the work being done in the IETF PROBLEM working group and IESG proposals for change, even as the committee endeavored not to infringe on the scope of those efforts. The objective is that these observations and proposals should be relevant for today's IETF and any near-term evolutions that are deemed appropriate.
現実にIETFの仕事を持って来るために協力組織のコレクション - AdvCommは、IETFのエグゼクティブ構造に集中して取り組みました。しかし、それらの関係は、仕事を成し遂げるために存在するという事実のおかげで、委員会が上侵害しないように努力したとしても、心に留めて変化するためIETF問題ワーキンググループとIESGの提案で行われている作業が重要でしたこれらの努力の範囲。目的は、これらの観察や提案は、今日のIETFおよび適切であると判断されているすべての短期的な進化のために適切でなければならないということです。
This documents the state of the AdvComm's thinking at the end of a two month process, and brings the currently-chartered work of the AdvComm to a close.
これは、2月のプロセスの最後にAdvCommの思考の状態を文書化し、近くにAdvCommの現在チャーター作業をもたらします。
Next steps include review of this material by the community, and specific proposals for action that will be put forward by the IAB and IETF Chairs.
次のステップは、コミュニティによって、この材料の見直し、およびIABとIETF議長によって提唱されるアクションのための具体的な提案が含まれています。
RFC 3233 ([1]) provides a definition of the IETF, in terms of its work and its participation.
RFC 3233（[1]）、その作業とその参加の点で、IETFの定義を提供します。
This document discusses the collection of organizations that work together to support the effort described in RFC 3233. In this document, the term "IETF" explicitly includes the IESG, WGs, IAB, IRTF, and RGs. This inclusive sense accords with considerable common usage of the term "IETF". Formally, the IAB and IRTF are chartered independently of the IETF. However, rather than coming up with a new term to encompass "the IETF and all its friends", the common usage is followed here.
この文書では、このドキュメントではRFC 3233で説明の努力を支援するために協力団体の集まりを説明し、用語「IETF」明示的IESG、のWG、IAB、IRTF、とのRGが含まれています。この包括的な意味は、用語「IETF」のかなり一般的な使用法に応じました。正式には、IABおよびIRTFは独立してIETFのチャーターです。しかし、むしろ「IETFとそのすべての友人を」包含する新しい用語を考え出すよりも、一般的な使用法がここに続いています。
The work of the IETF is supported by a specific set of functions. It is useful to distinguish between the functions and the organizations which provide those services, as outlined in the table below. In some cases a single organization provides multiple services, but the functions are logically distinct.
IETFの作業は、機能の特定のセットによってサポートされています。以下の表に示すように、機能およびそれらのサービスを提供する組織を区別するのに便利です。いくつかのケースでは、単一の組織が複数のサービスを提供していますが、機能は、論理的に別個のものです。
Function Known as Organization
(within the IETF)
--------- ---------------- ------------
IESG Support Secretariat Foretec/CNRI
IAB Support ISOC/Secretariat ISOC, Foretec/CNRI
WG Support Secretariat Foretec/CNRI
Community Support Secretariat Foretec/CNRI
IETF Meetings Secretariat Foretec/CNRI
RFC Publication RFC Editor USC/ISI
Standards Status Record RFC Editor USC/ISI
Parameter Reg. IANA ICANN
Legal, insurance, etc. (largely invisible) Provided by ISOC
Table 1. IETF functions, labels and organizations
表1. IETF機能、ラベルや団体
In more detail, the functions can be broken down as follows:
次のように具体的には、機能が破壊することができます。
IESG Support
IESGサポート
Telechats Communications IETF document tracking Working document management (mailing list, website, repository)
TelechatsコミュニケーションズIETF文書の追跡の作業文書管理（メーリングリスト、ウェブサイト、リポジトリ）
IAB support
IABのサポート
Telechats Communications Working document management (mailing list, website, repository)
Telechatsコミュニケーションワーキングドキュメント管理（メーリングリスト、ウェブサイト、リポジトリ）
WG support
WGのサポート
Charters Milestone tracking Workspace (website, mailing list) Working document archive (mailing list archives, document repository)
チャーターマイルストーンワークスペース（ウェブサイト、メーリングリストを）追跡の作業文書のアーカイブ（メーリングリストのアーカイブ、ドキュメントリポジトリ）
Community Support
コミュニティサポート
Website IETF mailing list Announcements I-D repository
ウェブサイトのIETFメーリングリストのお知らせI-Dリポジトリ
RFC Publication
RFC公報
Website RFC editorial Document publication RFC repository management Official standards status record
ウェブサイトのRFCの編集文書公開RFCリポジトリ管理の公式の標準状態記録
IETF Meetings
IETFミーティング
Planning Meeting Proceedings
企画会議議事録
Protocol parameter registration
プロトコルパラメータ登録
Creation of registries Assignment of protocol parameters Management of accessible registry repository
アクセスできるレジストリのリポジトリのプロトコルパラメータの管理のレジストリの割り当ての作成
Legal, insurance, etc.
法務、保険、など
Legal support Liability insurance for IAB, IESG, WG chairs, etc. Miscellaneous
などIAB、IESG、WGチェア、その他のための法的支援の損害賠償保険
A presentation of the scope and depth of support that created the IETF and has allowed it to continue to contribute would require a discussion of history that is rich, vibrant, and completely beyond the scope of this document. However, a very brief introduction to some of the current pillars is needed to understand where the IETF is today.
IETFを作成し、それが貢献し続けることを許可されたサポートの範囲と深さのプレゼンテーションは、豊かな活気に満ちた、そして完全にこのドキュメントの範囲を超えて歴史の議論が必要であろう。しかし、現在の柱の一部に非常に簡単な紹介は、IETFが今日であるかを理解するために必要とされます。
ISOC: Since 1992, ISOC has been the organizational home of the IETF. This activity is part of its more general mission of serving as the international organization for global coordination and cooperation on the Internet, promoting and maintaining a broad spectrum of activities focused on the Internet's development, availability, and associated technologies.
ISOC：1992年以来、ISOCはIETFの組織のホームとなっています。この活動は、世界的な協調とインターネットに関する協力のための国際機関として推進し、インターネットの発展、可用性、および関連する技術に焦点を当てた活動の広いスペクトルを維持し、そのより一般的な使命の一部です。
Foretec/CNRI: The Corporation for National Research Initiatives (CNRI) was founded in 1986, and since 1987, CNRI has served the community by providing IETF Secretariat services. Until the early 1990s, CNRI provided legal assistance to the IETF and the IETF Secretariat. After ISOC was founded, ISOC assumed overall legal responsibility for the substantive workings of the IETF including the efforts of the IETF chair, the IESG, the IAB, the area directors and the working group chairs. CNRI assumed operational responsibility for the substantive workings of the IETF Secretariat. In 1998, in order to decrease overhead costs on the activities, the Secretariat was reorganized placing Secretariat employees including the IETF Executive Director in a CNRI for-profit subsidiary (Foretec Seminars, Inc.). Foretec was founded in 1997, in anticipation of the Secretariat becoming self-supporting. CNRI and its subsidiary have continued to improve the operation of the Secretariat, as appropriate, and maintain a trained staff.
Foretec / CNRI：国立研究イニシアティブ株式会社（CNRI）は1986年に設立され、1987年以来、CNRIは、IETF事務局のサービスを提供することで、コミュニティを務めています。 1990年代初頭までは、CNRIはIETFとIETF事務局に法的支援を提供します。 ISOCが設立された後、ISOCはIETFの椅子の努力、IESG、IAB、地域ディレクターとワーキンググループの議長を含むIETFの実質的な働きのための総合的な法的責任を引き受けました。 CNRIは、IETF事務局の実質的な仕組みの運用責任を引き受けました。 1998年には、活動の間接費を削減するために、事務局は、CNRI非営利法人（Foretecセミナー社）にIETFのエグゼクティブ・ディレクターを含む事務局の職員を置く再編されました。 Foretecは、自立型になって事務局を見越して、1997年に設立されました。 CNRIとその子会社は、必要に応じて、事務局の動作を改善し、訓練を受けたスタッフを維持し続けてきました。
USC/ISI: The role of the RFC Editor, and USC/ISI, is detailed in RFC 2555. The RFC document series is a set of technical and organizational notes about the Internet (originally the ARPANET), beginning in 1969. For 30 years, the RFC Editor was Jon Postel, a research scientist and manager in the Networking Division of the USC Information Sciences Institute (ISI), with the function gradually evolving into a team headed by him. The RFC Editor activity is currently organized as a project within ISI, using the ISI infrastructure, and supported by a contract with ISOC. The RFC Editor is the publisher of RFCs and is responsible for the final editorial review of the documents, as well as the maintenance of the online repository and index of those documents.
USC / ISI：RFC編集者の役割、およびUSC / ISIは、RFC 2555に詳述されているRFCドキュメントシリーズは30年間、1969年に始まり、インターネットに関する技術的および組織ノートのセット（元々はARPANET）であります、RFC Editorはジョンポステル、機能が徐々に彼が率いるチームへと進化してUSC情報科学研究所（ISI）のネットワーキング部門の研究者やマネージャーでした。 RFC Editorの活動は、現在ISIインフラストラクチャを使用して、ISI内のプロジェクトとして組織され、ISOCとの契約によってサポートされています。 RFC EditorはRFCの発行者であるとの文書の最終編集見直しだけでなく、それらの文書のオンラインリポジトリとインデックスのメンテナンスを担当しています。
ICANN: The Internet Corporation for Assigned Names and Numbers (ICANN) is the non-profit corporation that was formed in 1998 to assume responsibility for the IP address space allocation, protocol parameter assignment, domain name system management, and root server system management functions previously performed under U.S. Government contract by IANA (at ISI) and other entities.
ICANN：割り当てられた名前と番号のためのインターネットコーポレーション（ICANN）は、以前にIPアドレス空間の割り当て、プロトコルパラメータの割り当て、ドメインネームシステム管理、およびルートサーバシステム管理機能の責任を負うために1998年に結成された非営利法人であります（ISIの）IANAと他のエンティティによって米国政府の契約の下で行いました。
The support picture (who does what) can be described as follows:
次のようにサポート画像は（何をする人）に記述することができます。
Secretariat at Foretec/CNRI
Foretec / CNRIで事務局
IESG Support IAB Support (working document management) WG Support Community Support IETF meetings
IESGサポートIABのサポート（作業文書管理）WGサポートコミュニティサポートIETFミーティング
RFC Editor at USC/ISI
USC / ISIでRFCエディタ
[Supported by ISOC, based on a contract between USC/ISI and ISOC]
[USC / ISIとISOCとの間の契約に基づいて、ISOCによってサポート]
RFC publication Maintenance of standards status record
標準状態レコードのRFC公開メンテナンス
IANA/ICANN
IANA / ICANN
[Relationship defined by Memorandum of Understanding: RFC 2860]
[覚書によって定義された関係：RFC 2860]
Protocol parameter registry
プロトコル・パラメータのレジストリ
ISOC
ISOC
IAB Support (Telechats) Funds RFC Editor Misc IAB/IESG expenses Provides insurance for IAB, IESG, WG chairs, etc.
IABのサポート（Telechats）ファンドRFC Editorのその他IAB / IESG費等IAB、IESG、WGチェア、のために保険を提供します
The available resources to support these activities are:
これらの活動を支援するための利用可能なリソースは以下のとおりです。
Meeting fees -- through Foretec ISOC members' contributions for standards ICANN for IANA Volunteers/their employers (where applicable):
手数料会議 - IANAボランティアのための基準ICANNのためForetec ISOCのメンバーの貢献を通じて/雇用者（該当する場合）：
IETF participants WG chairs Document editors IETF NomCom IESG IAB IAB ExecDir
IETFの参加者WGチェアドキュメントエディタIETF NomCom IESG IAB IAB EXECDIR
The AdvComm noted several properties of the current IETF organizational environment that cause stress in the system. These have been noted both from the point of view of the IETF leadership as well as that of organizations supporting the IETF.
AdvCommは、システム内のストレスを引き起こし、現在IETF組織環境のいくつかの性質を指摘しました。これらは、IETFリーダーシップの観点からだけでなく、IETFを支援する組織の両方の注目されています。
The current IETF funding and operational structure is dependent on IETF meeting attendance. Therefore, the most obvious stressor that has emerged within the last two years is the decline in that attendance. This trend, which has continued unabated, has resulted in a decline in IETF revenue (detailed in the IETF chair presentation at IETF 56 [2]), even as the requirements of the IETF operation are remaining constant or increasing.
現在IETFの資金調達と運用の構造は、IETF会議の出席に依存しています。そのため、最後の2年以内に登場した最も明白なストレッサーは、その出席者の減少です。衰えることなく続けているこの傾向は、IETF操作の要件は一定に維持または増加されてもとして、（IETF 56 [2]でIETF椅子プレゼンテーションに詳述）IETF収益の減少をもたらしました。
The result has been a budget deficit for operations which began in 2002, and is forecasted to continue until at least 2004, even after a substantial increase in meeting fees. The continuing deficits have depleted working capital, making the IETF less robust against potential future budgetary disappointments.
結果は、2002年に始まった操作のための財政赤字となっている、とさえ手数料を満たすことが大幅に増加した後、少なくとも2004年まで継続することが予想されます。継続的な赤字は将来の予算失望に対するIETFが少ない堅牢な作り、運転資金を枯渇しています。
The financial stress is real, but the IETF leadership has noted several other stressors that are impediments to finding and implementing solutions to the fiscal issues. Some obvious solutions are not implementable in the current IETF structure.
金融ストレスは本当ですが、IETFリーダーシップは財政問題への解決策を見出すと実施に障害されている他のいくつかのストレス要因を指摘しています。いくつかの明白な解決策は、現在IETF構造で実現可能ではありません。
The rest of the stressors listed in this section should be understood as issues for which relief is necessary, particularly in the light of needing to properly address and implement solutions to the financial stress.
このセクションに記載されているストレスの残りの部分はレリーフは、特に適切な金融ストレスの解決策に対処し、実装するために必要に照らして、必要となるため問題として理解されるべきです。
The current documentation of IETF processes and structure is, in places, vague about the distribution of responsibility for management and oversight of the IETF administrative relationships. This makes it opaque to the IETF community, and sometimes leaves the leadership in a poor position to manage effectively.
IETFのプロセスと構造の現在のドキュメントは、場所では、IETF行政関係の管理・監督責任の分布に関するあいまいです。これは、IETFコミュニティにそれが不透明になり、時には効果的に管理するために、貧しい立場にリーダーシップを残します。
Additionally, the informality of the relationships with some of the organizations that are carrying out key IETF functions compounds the problem of determining who has responsibility, and how IETF community consensus and desires are reflected in the activity.
また、キーIETF機能を実行している組織の一部との関係の非公式は責任を持って、そしてどのようにIETFコミュニティのコンセンサスや欲望を活動に反映している者を決定する問題を悪化します。
As a separate issue, important IETF institutional memory is recorded nowhere other than peoples' minds in many cases -- which requires significant transmission of oral history for IETF leadership transition to be effective.
有効であるためにIETFリーダーシップの移行のためのオーラルヒストリーの重要な伝送を必要とする - 別の問題として、重要なIETF制度上のメモリは、多くの場合、人々の心以外どこにも他の記録されています。
Apart from the institutional memory, other important IETF institutional records are spread across various organizations, and searching for the set of relevant documentation (especially when this is necessary long after the recording) can be challenging.
（これは、記録後に長い必要がある場合は特に）以外の機関のメモリから、他の重要なIETF制度上のレコードがさまざまな組織にまたがって、及び関連文書のセットを探して挑戦することができます。
Another stressor relates to the need to scale support processes in terms of reducing latency for mechanical processes. That is, a decrease in the amount of manual labor required for the simpler tasks between the organizations, would make more resources available to focus on the special cases. Lack of automation in the basic request services has been known to cause undue delay or failure in processing simple, routine tasks. However, automation also requires resources and significant management in order to make sure it fulfills the community's requirements.
別のストレッサーは、機械的プロセスのための待ち時間を短縮という点でサポートプロセスを拡張する必要性に関するものです。それは、組織間の単純なタスクのために必要な手作業の量の減少である、特殊なケースに集中するより多くのリソースが利用可能になるだろう。基本的な要求サービスにおける自動化の欠如は、簡単な、日常的なタスクを処理中に過度の遅延や故障を引き起こすことが知られています。しかし、自動化はまた、コミュニティの要件を満たしてことを確認するために、資源と重要な管理が必要です。
Supporting organizations report difficulties in determining authoritative channels for directions -- either too many inputs, or no clear authority for resolution of change requests.
あまりにも多くの入力、または変更要求の解決のための明確な権限のいずれかを - サポートする組織は、方向性のために権威のチャネルを決定する際に困難を報告しています。
In the absence of written agreements, supporting organizations may not be clear from whom to take direction. Even where agreements exist, the authority to provide direction may not be clear. The genesis of both problems is that the IETF relies on external bodies for support, but does not have sufficiently clear external relationships to allow it to provide input as to its requirements or direction on what services it desires.
書面による合意がない場合には、支援団体は方向性を取るために誰からも明らかではないかもしれません。契約が存在する場合であっても、方向性を提供するために、権限が明確でないかもしれません。両方の問題の起源は、IETFは、サポートのため、外部機関に依存しているが、それはその要件またはそれが希望するサービスをどのように方向として入力を提供できるようにするために十分に明確な外部の関係を持っていないということです。
This section attempts to capture a snapshot of the current state of the IETF organization, without undue fixation on the causes for arriving at the current state. However, it seems clear from the observations that the current state does not provide an adequate structure from which to reach into the future: some changes are needed within the IETF administrative and executive structure.
このセクションでは、現在の状態に到着の原因に過度固定せずに、IETF組織の現在の状態のスナップショットをキャプチャしようとします。いくつかの変更は、IETF管理および執行構造内で必要とされています。しかし、現在の状態が将来に到達するから、適切な構造を提供しないことを観測から明らかなようです。
3. Stand Facing the Future: Requirements for a Successful IETF Administration
3.今後に直面スタンド：成功IETF管理するための要件
This section follows the set of observations with a set of requirements for a properly-functioning IETF administrative structure. These requirements are offered as the AdvComm's description of what the IETF needs, without addressing immediately the degree to which they are available with the current environment. That is, these are "requirements", not "requirements for change".
このセクションでは、適切に機能するIETF行政構造のための要件のセットとの観測のセットに従います。これらの要件は、すぐに彼らは現在の環境で利用できる度合いに対処せず、どのようなIETFニーズのAdvCommの説明として提供されています。つまり、これらは、「要件」ではなく、「変更の要件」している、です。
The IETF has operated in times of financial wealth and times of economic cutbacks in the industry. It is reasonable to expect that the future holds similarly variable trends. Therefore, it is important that the IETF organization has the ability to make the decisions to match its needs at a given point in time, i.e., budgetary autonomy. At this particular moment, there are hard choices to make, and the AdvComm believes that it is the IETF leadership, with the advice and consent of the IETF community, that needs to make them.
IETFは、金融資産および業界の経済削減の倍の倍で動作していました。将来も同様に、変数の傾向を保持していることを期待するのは合理的です。したがって、IETF組織は、所与の時点、すなわち、予算の自治でそのニーズに合うように意思決定を行う能力を持っていることが重要です。この特定の瞬間、そこにハードの選択肢が作ることであり、AdvCommはそれがそれらを作る必要があるIETFコミュニティの助言と同意、で、IETFのリーダーシップであると考えています。
The IETF is currently supported by money from multiple sources, including meeting fees, donations from interested corporate and non-corporate entities, and donations in kind of equipment or manpower. The IETF needs to be able to consider all sources of income, and all expenses involved in running the IETF, as pieces of one budget, to be free to adjust all items on the occasions when the income from the different sources varies, and to allocate funds as reasonably required.
IETFは現在、会議費、興味を持って企業と非法人からの寄付、および機器や人員の現物寄付を含め、複数のソースからの資金によってサポートされています。 IETFは、異なるソースからの収入が変動した場合の機会のすべての項目を調整して自由になり、そして割り当てるために、1つの予算の作品として、収入のすべてのソース、およびIETFの実行に関連するすべての費用を考慮できるようにする必要があります資金は、のように合理的に必要。
The usual caveats apply: that donations not threaten the independence of the IETF, and that donations are easier when they are tax deductible.
寄付金は、IETFの独立性を脅かすていないことを、彼らは税控除の対象としているときの寄付が容易であることを：通常の注意事項が適用されます。
While the IETF needs to be able to manage its revenue streams against its expense expectations, it also needs to respect the needs of supporting organizations to manage their own affairs. That is, the text above does not suggest that the IETF should micro-manage the financial affairs of supporting organizations.
IETFは、その費用の期待に対して、その収益源を管理できるようにする必要がありますが、それはまた、独自の事務を管理する組織を支援する必要性を尊重する必要があります。すなわち、上記のテキストは、IETFが支援団体の財務をマイクロ管理する必要があることを示唆していない、です。
However, the very clear requirement is for clarity in the distribution of rights, responsibilities, and accountability in those relationships. The usual mechanism for documenting such clarity is in contract form. Thus, the IETF needs to have clear contractual relationships with the organizations supporting basic services, including meeting organization, secretarial services, IT services, etc.
しかし、非常に明確な要件は、それらの関係における権利、責任、および説明責任の分布に明確にするためです。そのような明瞭さを文書化するための通常のメカニズムは、契約形態です。このように、IETF等、ITサービス会議組織、秘書サービス、などの基本的なサービスを支える組織と明確な契約関係を持っている必要があります
The IETF needs to be able to raise money for, and fund the development of, additional services as appropriate. This includes the development of tools for participants, repository management, etc.
IETFはのための資金を調達し、必要に応じて、追加的なサービスの開発に資金を供給できるようにする必要があります。これは、参加者のためのツールの開発、リポジトリ管理などが含まれます
The IETF's needs should be met with the minimum of overhead. This implies that there needs to be the possibility of combining work efforts where appropriate, and generally avoiding duplication of effort.
IETFのニーズは、オーバーヘッドを最小限に抑えて満たされる必要があります。これは、適切な場合には、作業の努力を組み合わせることで、一般的に作業の重複を回避する可能性があることが必要であることを意味します。
The requirements described below focus primarily on the needs of the IETF administration on a day-to-day basis. However, responsible management includes stewardship for future IETF work.
要件は、主に日々のIETF管理のニーズに焦点後述します。しかし、責任ある経営者は、将来のIETFの作業のための責務を含んでいます。
The IETF needs to be responsible for changing its administrative structure to meet the community's evolving needs. As such, the administration needs to remain uniquely accountable to the IETF community.
IETFは、コミュニティの進化するニーズを満たすためにその管理構造を変更するための責任にする必要があります。そのため、投与は、IETFコミュニティに独自に説明責任を維持する必要があります。
This also means that the distribution of responsibilities must be clear to the IETF community, in order to permit it to comment on current actions or future plans, and also to allow it to take action when its needs are not being adequately addressed.
また、これは責任の分布が現在のアクションや将来の計画についてコメントすることを可能にするために、そしてまたそのニーズが適切に対処されていないとき、それは行動を取ることができるようにするために、IETFコミュニティに明確でなければならないことを意味しています。
An implication of this is that responsibility for financial management within the IETF needs to sit with individuals who are accountable within the IETF organizational structure.
これの意味するところは、IETF内の財務管理の責任は、IETFの組織構造内で責任ある個人に座るする必要があるということです。
Much of the work of the IETF is focused on reaching decisions and declaring closure. However, responsibility does not stop with the declaration of completion. There are any number of reasons that history must be adequately documented so that future work can review substantive records, and not rely on oral history.
IETFの作業の多くは、意思決定に到達し、閉鎖を宣言するに焦点を当てています。しかし、責任は完了の宣言で停止しません。今後の作業は、オーラル・ヒストリーに依存している実質的な記録を確認し、できないように、歴史は適切に文書化されなければならないことの理由の任意の数があります。
Therefore, the IETF needs to maintain and support the archiving of all of its working documents in a way that continues to be accessible, for all current and future IETF workers.
そのため、IETFは維持し、現在および将来のすべてのIETFの労働者のために、アクセス可能であり続けるように、その作業文書のすべてのアーカイブをサポートする必要があります。
Part of the job of administering the IETF is identifying and ensuring the continued support of the tools and working environment necessary to support the ongoing activity.
継続的な活動をサポートするために必要な環境を識別しているIETFの管理とツールの継続的な支援を確保し、作業の仕事の一部。
Wherever human judgment is not required in order to complete an action, services should be automated to provide the most friction-free path and minimal delay in completing the action.
人間の判断がアクションを完了するために必要とされていない場合はいつでも、サービスはアクションを完了した中で最も摩擦フリーパスと最小の遅延を提供するために、自動化されなければなりません。
More processes could be accomplished without requiring human judgment. Wherever possible, these processes should be identified, clarified, and automated.
以上のプロセスは、人間の判断を必要とせずに達成することができます。可能な限り、これらのプロセスは、特定され明確化、および自動化されなければなりません。
Note that this is not intended to imply ALL processes should be automated! Rather, by reducing the friction incurred in steps that are truly mechanical, more time and energy will be available to properly treat those that require individual judgment.
これはすべてのプロセスが自動化されなければならない意味するように意図されていないことに注意してください！むしろ、本当に機械的なステップで発生した摩擦を減らすことによって、より多くの時間とエネルギーが適切に個々の判断を必要とするものを治療するために利用できるようになります。
Whether housed in an IETF-supported location or offered by individual contribution, the PROBLEM WG has identified the need for more tool support for working groups and specification development. The IETF needs to be able to identify, develop and support an adequately rich, consistent set of tools for getting the standards work done.
IETF-サポート場所に収納され、または個々の貢献によって提供されるかどうかは、問題WGは、ワーキンググループや仕様開発のためのより多くのツールのサポートの必要性を特定しました。 IETFは、識別することができる開発して行われる標準化作業を取得するためのツールの適切豊富な、一貫性のあるセットをサポートする必要があります。
The Advisory Committee discussed the material and observations, described in this document, at great length. To the AdvComm, it appeared clear that some level of IETF administration organizational change is needed to address the stressors and meet all of the requirements outlined in Section 3.
諮問委員会は、大きな長さで、この文書に記載されている材料と観察を、議論しました。 AdvCommに、IETF行政組織変更のいくつかのレベルがストレスに対処し、第3節で概説した要件のすべてを満たすために必要とされることが明らかに現われました。
In order to ensure an IETF structure that is capable of meeting the requirements outlined above, the AdvComm recommends that the IETF be more formally organized. This would allow the IETF to take full responsibility for, and management of, the resources required to accomplish its work (as described in Section 3.1), provide and maintain the necessary work environment for current work (as described in Section 3.3), and provide appropriate stewardship of the institutional information required for all aspects of current and future work of the organization (as described in Section 3.2).
上記で概説した要件を満たすことが可能であるIETF構造を確保するために、AdvCommは、IETFがより正式に編成することをお勧めします。これは、IETFが全責任を取ることができるように、との管理、その作業を達成するために必要なリソース（3.1節で説明したように）、（セクション3.3で説明したように）現在の仕事のために必要な作業環境を提供し、維持し、提供することになります組織の現在及び将来の作業のすべての側面のために必要な制度的な情報の適切な責務（セクション3.2で説明したように）。
Some proposed models for establishing such a formalized effort are described in the following sections. Some of the key expectations, irrespective of the final implementation of formalism, are:
そのような正式な努力を確立するためのいくつかの提案モデルは、次のセクションで説明されています。キー期待のいくつかは、関係なく、形式主義の最終的な実装の、以下のとおりです。
o the administration of the IETF would remain accountable to the IETF leadership and community; the goal would be to ensure that lines of responsibility and accountability were clearer;
O IETFの投与は、IETFリーダーシップと社会への説明責任を残ります。目標は、責任と説明責任のラインが明確にされたことを確認することです。
o this formalized IETF would be responsible for managing financial resources (revenue and expenses) directly;
Oこの正式にIETFは財源（収入と支出）を直接管理するための責任を負うことになります。
o this formalized IETF would be directly signatory to agreements with other organizations, and would therefore be able to negotiate and administer any appropriate contracts;
Oこの正式IETFは、直接、他の機関との契約に署名することになるので、任意の適切な契約を交渉し、管理することができるであろう。
o however implemented, this would require a small staff complement (e.g., one full-time person) responsible to no other organization than the one chartered with the IETF's mission;
Oが実装され、これは小さなスタッフの補完を必要とする（例えば、1フルタイムの人）IETFの使命でチャーター1を超えない他の組織に責任を負います。
o nevertheless, it remains a non-goal to create an organizational entity that exists simply for the purpose of continuing to exist. This should be executed with the minimum formality needed in order to address the identified requirements.
Oそれにもかかわらず、それが存在し続けることを目的として、単に存在する組織エンティティを作成するために、非目標のまま。これは、特定された要件に対処するために必要な最低限の形式で実行する必要があります。
An important question is: what does this proposed formalization provide that cannot be provided by the status quo? The AdvComm believes that an appropriately implemented formalization of the IETF would permit the unification of the resource management, decision making and stewardship that is imperative to providing clarity and ensuring a viable future for the IETF. The AdvComm further believes that this is simply not possible to implement within the existing distributed and informal arrangement of responsibilities.
重要な問題は、この提案された形式化は、それは現状では提供できないものを提供していますか？ AdvCommは、IETFの適切に実施形式化は明快さを提供し、IETFのための実行可能な未来を確保することが不可欠である資源管理の一元化、意思決定と責務を可能にするだろうと考えています。 AdvCommはさらに、これは責任の既存の分散と非公式の配列の中に実装するだけでは不可能であると考えています。
Naturally, the act of forming such an organization does not immediately satisfy the requirements outlined in Section 3. It is not a silver bullet. Changing the formal structure will not, for example, change the financial status of the IETF. However, the AdvComm believes it would provide the necessary basis from which the required decisions could be made and acted upon.
当然のことながら、このような組織を形成する行為はすぐにそれは銀の弾丸ではありません3章で概説要件を満たしていません。正式な構造を変更すると、例えば、IETFの財務状況は変更されません。しかし、AdvCommは、それが必要な意思決定が行われ、作用することができ、そこから必要な基盤を提供するだろうと考えています。
In short, the AdvComm believes that we first have to place the responsibility for defining the IETF's administrative environment with specific people who are accountable to the IETF community. Then these people can take the detailed decisions that will change the IETF's administrative environment to fulfill its requirements.
要するに、AdvCommは、我々が最初にIETFコミュニティに責任がある特定のユーザーとIETFの管理環境を定義するための責任を配置する必要があると考えています。そして、これらの人々は、その要件を満たすためにIETFの管理環境を変更します詳細な決定を下すことができます。
Section 4.1 was deliberately vague on the nature of the formal organizational entity that might provide the proper environment, focusing instead on the key components of any implementation of such a formalization, and how the formalization activity would address the requirements laid out in Section 3.
4.1節では、このような形式化のいずれかの実装の主要コンポーネントに代わりに焦点を当て、適切な環境を提供するかもしれない正式な組織エンティティの性質上、意図的に曖昧で、どのように形式化活性は、セクション3にレイアウト要件に対応します。
Having thus determined that formalization of the IETF is seen as a necessary step, the basic framework for 3 potential implementations of it are described below. Note that these are not complete proposals, nor is enough detail available to recommend a particular path. The IETF leadership might select one to explore in greater detail, to formulate an action proposal with sufficient detail to make a decision to act.
このように必要な工程として見られているIETFの定式化を決定した、それの3潜在的な実装のための基本的な枠組みを以下に記載します。これらは完全な提案ではない、また十分な詳細は、特定のパスを推奨するために利用可能であることに注意してください。 IETFリーダーシップは行動する決断をするのに十分なディテールとアクション案を策定するために、詳細に探索するものを選択することがあります。
The IETF is organized as an activity of the Internet Society. One potential path for increased formalism of the IETF's administration would be to further define that relationship. This model anticipates dedication of ISOC personnel to form the "small staff complement", and would make ISOC responsible for all of the IETF's financial resources and expenses.
IETFは、インターネット協会の活動として編成されています。 IETF政権の増加形式主義のための一つの潜在的パスは、さらにその関係を定義することです。このモデルは、「小さなスタッフの補数」を形成するためにISOC要員の献身を予想し、IETFの財源と費用のすべてのためのISOCの責任になるだろう。
This approach should be relatively straightforward to implement, given ISOC's existing legal relationship with the IETF activity, and its status as signatory for IETF-related contracts (e.g., RFC Editor).
このアプローチは、実装が比較的簡単であるべき、IETF活性を有する与えられたISOCの既存の法的関係、およびIETF関連の契約の調印としての地位（例えば、RFC編集者）。
This proposal is consistent with the goal of minimizing the amount of formalization needed to meet the requirements of the IETF.
この提案は、IETFの要件を満たすために必要な形式化の量を最小限に抑えることを目標と一致しています。
However, the general mission of ISOC is broader than the standardization activity of the IETF, and the ISOC Board of Trustees must stay focused on apportioning resources to meet that broader mission. Would this approach allow the clear lines of responsibility that are called for in Section 3?
しかし、ISOCの一般的な使命は、IETFの標準化活動よりも広い、そして評議員のISOC理事会は、より広範な使命を満たすためにリソースを配分に集中しなければなりません。このアプローチは、3章でのために呼ばれている責任の明確なラインを許可しますか？
A modification of the proposal of housing the IETF central body within ISOC is to create a legal not-for-profit subsidiary of ISOC, with a mandate that is specifically focused on the IETF's mission. This subsidiary would become the legal entity responsible for managing the IETF's resources and expenses, and would become signatory to any other legal instruments on the IETF's behalf.
住宅の提案の修正は、ISOC内IETF中心体は、特にIETFの使命に焦点を当てている任務で、ISOCの法的な非営利法人を作成することです。この子会社は、IETFの資源や経費の管理を担当する法人になるだろう、とIETFの代行する他の法律文書への署名になります。
As a distinct legal entity in its own right, the subsidiary would be independently responsible for achieving its mission. That level of independence addresses the concern raised against the notion of further formalizing the IETF within ISOC directly -- that the IETF mission might be disrupted by the organization's need to tend to other aspects of ISOC's broader mission. The role of the IETF community, and the ISOC parent, in defining and supporting that mission would be spelled out in the creation of the legal body.
独自の権利で個別の法人として、子会社は、その使命を達成するために独立して責任を負うことになります。 IETFの使命は、ISOCのより広範なミッションの他の側面に傾向があるために、組織のニーズによって破壊されるかもしれないこと - 独立性のレベルはさらに直接ISOC内IETFを形式の概念に対して惹起された懸念に対処しています。その使命を定義し、支援にIETFコミュニティの役割、およびISOCの親は、法的な身体づくりにスペルアウトされるだろう。
The IETF might additionally consider what the most appropriate governance model would be for this approach. If it is desirable to remove some of the administrative burden from the IESG and IAB, such a subsidiary might have its own Board of Trustees, composed of members appointed by IETF and ISOC. Such a Board would be responsible for reviewing activities and ensuring that the organization's efforts were adequately in line with its mission, its finances were in order, and so on. The subsidiary would report to its Board of Trustees. Other governance models are certainly possible, and a Board of Trustees is not a requirement for this approach.
IETFは、さらに、最も適切なガバナンス・モデルは、このアプローチのためになるものを考えるかもしれません。それはIESGとIABからの管理負担の一部を除去することが望ましい場合には、そのような子会社は、IETFとISOCによって任命されたメンバーで構成評議独自のボードを持っているかもしれません。このような委員会が活動を見直し、組織の努力はその使命に沿って適切にいたことを保証する責任を負うことになる、その財政はこれに順であった、と。子会社は、理事の理事会に報告します。その他のガバナンスモデルは確かに可能であり、理事会は、このアプローチの要件ではありません。
At the same time, as a subsidiary organization, the expectation is that the relationship with ISOC would remain a close one: the subsidiary would benefit from ISOC's existing infrastructure and support (a conservative approach to adding formalism and structural overhead to the IETF activity), while the relationship would continue to provide a channel for the IETF to support ISOC in achieving that broader mission, with continued contribution of technical expertise and support of activities.
同時に、補助組織として、期待はISOCとの関係が密接1残るということである。子会社はISOCの既存のインフラストラクチャとサポート（IETF活動に形式化および構造オーバーヘッドを追加する保守的なアプローチ）から利益を得ます、関係は、技術的な専門知識や活動の支援の継続的な貢献と、その広い使命を達成するためにISOCをサポートするIETFのためのチャネルを提供し続けるでしょうが。
This approach would require more work to create than simply housing the work at ISOC. The subsidiary would have to be created and rights/responsibilities adjusted between it and ISOC in order to ensure that both have the necessary resources and frameworks to carry out their missions.
このアプローチは、単純にISOCで仕事を収容するよりも、作成するために多くの作業が必要になります。子会社は、両方が彼らの任務を遂行するために必要なリソースとフレームワークを持っていることを保証するために作成され、権利/責任それとISOCの間で調整しなければならないであろう。
To complete the picture, a third option has to be considered. Instead of creating a subsidiary of ISOC as a separate legal entity, an entirely new legal entity, "IETF, Inc.", or "IETF, LLC", could be created for the sole purpose of managing IETF administrative activities.
絵を完成させるために、第三の選択肢を考慮しなければなりません。代わりに、独立した法人、全く新しい法人、「IETF社」、または「IETF、LLC」としてISOCの子会社を作成する、IETF管理活動を管理するための唯一の目的のために作成することができます。
This would offer the IETF complete autonomy with all the attendant rights and responsibilities. In particular, an independent IETF would at a minimum, need to operate much like a startup for the first few years of its existence, with all the related financing and growth issues, and survival risks. Given all the organizational change taking place within the IETF during the same period, the AdvComm believes that the financial and political risks of such an approach should not be under-estimated.
これは、すべてのアテンダントの権利と責任を持つIETF完全な自律性を提供するであろう。具体的には、独立したIETFは最低でも、すべての関連の資金調達と成長の問題、および生存リスクと、その存在の最初の数年間は、スタートアップのような多くを操作する必要があります。同期間中にIETF内で行わすべての組織の変化を考えると、AdvCommは、このようなアプローチの金融と政治的リスクが過小推定すべきではないと考えています。
For example, it would be necessary for the IETF to obtain initial working capital sufficient to handle the commitments for the first few meetings. While it would be conceivable to raise working capital from advance meeting fees, such a financing plan would not leave much margin for error; were one or more of the initial meetings to run in the red, the survival of a fledgling IETF could be in jeopardy. Given the economic environment, it probably should not be assumed that working capital could be raised purely from corporate donations, especially during an initial period in which staff required to solicit and manage donations would not be available.
IETFは、最初のいくつかのミーティングのための約束を処理するのに十分な初期運転資金を得るためにするために例えば、それは必要であろう。それは事前のミーティング料から運転資金を調達することも考えられるが、このような資金調達計画はエラーのために多くのマージンを残していないだろう。赤で実行する最初のミーティングの一つ以上、IETFが危険にさらさ可能性が駆け出しの生存率でした。経済環境を考えると、おそらく運転資本は、特にスタッフが募集して寄付が利用できないでしょう管理するために必要れた初期期間中、企業の寄付金から純粋に上げることができることを前提とすべきではありません。
Additionally, the impact that such a move would have on ISOC's ability to carry out its mission and the IETF's standing with governmental organizations needs to be considered.
さらに、このような動きは、その使命や政府機関とIETFの地位を実行するISOCの能力になければならないことの影響を考慮する必要があります。
The AdvComm believes that the IETF leadership, acting with the advice and consent of the IETF community and ISOC, have the ability and the responsibility to act on the recommendation to formalize the IETF.
AdvCommがIETFリーダーシップと信じている、IETFコミュニティとISOCの助言と同意を得て演技、IETFを正式にする勧告に作用する能力と責任を持っています。
This document does not describe any technical protocols and has no implications for network security.
このドキュメントは、技術的なプロトコルを記述し、ネットワークセキュリティのための意味を持っていません。
The AdvComm sincerely appreciates the time, effort and care of the RFC Editor, IANA, Secretariat and Secretariat organizations in providing input, responding to the AdvComm's questions, and reviewing/correcting the consultation text shown here in the appendixes.
AdvCommは心から、入力を提供AdvCommの質問への対応、および見直し/付録にここに示した相談のテキストを修正するのにRFC編集者、IANA、事務局及び事務局の組織の時間、労力とケアを高く評価しています。
The members of the IAB Advisory Committee that prepared this report were:
この報告書を作成IAB諮問委員会のメンバーは以下の通りでした。
o Bernard Aboba o Harald Alvestrand (IETF Chair) o Lynn St.Amour (ISOC President) o Fred Baker (Chair, ISOC Board of Trustees) o Brian Carpenter o Steve Crocker o Leslie Daigle (IAB Chair, chair of the committee) o Russ Housley o John Klensin
ラスOレスリーDaigle氏（IAB議長、委員会の議長）OスティーブクロッカーOブライアン・カーペンターOフレッド・ベイカー（議長、理事のISOC会）OリンSt.Amour（ISOC社長）OハラルドAlvestrand（IETF議長）OバーナードAboba Oジョン・クレンシンO Housley氏
[1] Hoffman, P. and S. Bradner, "Defining the IETF", BCP 58, RFC 3233, February 2002.
[1]ホフマン、P.とS.ブラドナーの、 "IETFの定義"、BCP 58、RFC 3233、2002年2月。
[2] Alvestrand, H., "IETF Chair plenary presentation, http:// www.ietf.org/proceedings/03mar/slides/plenary-3/index.html", March 2003.
[2] Alvestrand、H.、 "IETF議長の本会議のプレゼンテーションは、http：// www.ietf.org/proceedings/03mar/slides/plenary-3/index.html"、2003年3月。
[3] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[3]ポステル、J.、およびJ.レイノルズ、 "RFC作者への指示"、RFC 2223、1997年10月。
[4] Reynolds, J. and B. Braden, Eds., "Instructions to Request for Comments (RFC) Authors", Work in Progress.
[4]レイノルズ、J.及びB.ブレーデン、編、 "コメント（RFC）作者を要求する命令"、ProgressのWork。
Appendix A. IAB Advisory Committee Charter
付録A. IAB諮問委員会憲章
Date: Tue, 02 Sep 2003 16:34:58 -0400 From: Leslie Daigle Subject: Formation of IAB Advisory Committee To: IETF-Announce: ;
日付：火曜、2003年9月2日午前16時34分58秒-0400から：レスリーDaigle氏件名：IETF-発表：：へIAB諮問委員会の形成;
I would like to announce the formation of an IAB advisory committee, as described below.
私は、以下に説明するように、IAB諮問委員会の形成を発表したいと思います。
Thanks, Leslie, for the IAB.
IABのおかげで、レスリー、。
=================
IAB Advisory Committee on IETF Administration Relationships
IETF管理の関係上IAB諮問委員会
The purpose of the committee is to review the existing IETF administration relationships (RFC Editor, IETF Secretariat, etc.) and propose IETF management process or structural changes that would improve the overall functioning of the IETF. Any such proposal will be subject to review and acceptance by the IAB and IETF plenary. Note that the scope of the advisory committee does NOT include proposed changes to the standards development processes (e.g., WG organization, IESG management of documents or working groups, etc.).
委員会の目的は、既存のIETFの管理関係（RFC編集者、IETF事務局など）を見直し、IETFの全体の機能を改善するIETF管理プロセスや構造変化を提案することです。任意のこのような提案は、IABとIETF本会議で検討し、受諾の対象となります。諮問委員会のスコープは、規格開発プロセスへの変更案が含まれていないことに注意してください（例えば、WGの組織、文書やワーキンググループのIESG管理、など）。
The committee is chaired by the IAB Chair, Leslie Daigle, and consists of:
委員会はIAB議長、レスリーDaigle氏が議長を務め、とで構成されています。
o Bernard Aboba
o Harald Alvestrand (IETF Chair)
o Lynn St.Amour (ISOC President)
o Fred Baker (Chair, ISOC Board of Trustees)
o Brian Carpenter
o Steve Crocker
o Leslie Daigle (IAB Chair, chair of the committee)
o Russ Housley
o John Klensin
Additional input is welcome. The committee will also make a particular effort to seek out further input as needed. --
追加の入力は大歓迎です。委員会はまた、必要に応じてさらに入力を模索するために、特定の努力をします。 -
Appendix B. Input from the Current IETF and IAB Chairs
現在IETFとIAB議長から付録B.入力
Input contributed by Harald Alvestrand (IETF Chair) and Leslie Daigle (IAB Chair).
ハラルドAlvestrand（IETF議長）およびレスリーDaigle氏（IAB議長）によって寄与入力。
Looking at the administrative overview of the IETF activity, there are a number of things that work well:
IETF活動の管理の概要を見てみると、うまくいくものがいくつかあります：
o support organizations are committed to the work of the IETF;
Oサポート組織は、IETFの仕事にコミットしています。
o the volunteers of the IETF WGs can (mostly) concentrate on their engineering work, not economics;
IETFのWGのボランティアO（主に）自分のエンジニアリング作業ではなく、経済学に専念することができます。
o money has (so far) been sufficient to cover the costs.
Oお金は（今のところ）の費用をカバーするのに十分なされています。
However, there are also a number of challenges:
しかし、多くの課題もあります。
o lack of persistent records of the whole organization's efforts -- of working documents, meeting materials, communications. Also,
組織全体の努力の永続的なレコードのO不足 - 作業文書、会議資料、コミュニケーションの。また、
* lack of organization of records -- even when data is stored, it can be hard or impossible to access when no longer current (e.g., it may reside on some former WG chair's hard drive)
*レコードの組織の欠如 - データが格納されている場合でも、とき、もはや現在のアクセスが困難または不可能である（例えば、それはいくつかの以前のWGの議長のハードドライブ上に存在することができます）
* history records are kept spottily (lists of wg chairs and old versions of charters, to mention some);
*履歴レコードは、（WG椅子と憲章の旧バージョンのリストは、いくつかを言及する）spottily保持されます。
o few safeguards against the "hit by a bus" problem -- much information about relationships is not documented, and must be transferred as oral tradition. This means that significant overlap is needed when personnel changes;
「バスでヒット」問題に対するO数セーフガード - 関係について多くの情報が文書化されていない、と口承として転送する必要があります。これは時に人事異動かなりの重複が必要であることを意味します。
o IETF leadership responsibilities are not clearly identified -- typically handled by IETF and IAB Chairs, with some advice and consent from IESG and IAB, but that makes it possible to challenge every change decision;
IETFリーダーシップの責任が明確に特定されていないoを - 通常、IESGとIABからいくつかのアドバイスや同意を得て、IETFおよびIAB議長で扱うが、それはすべての変更の決定に挑戦することが可能となります。
o contracts do not clearly identify responsibility for executive direction. Some contractual relationships are not documented, or are not visible to the IETF leadership;
Oの契約は明らかに執行方向の責任を識別しません。いくつかの契約関係が記載されていない、またはIETFリーダーシップには見えません。
o variable, and often unclear, documentation of responsibilities between IETF leadership and other organizations. This makes it hard to determine how and where to discuss and effect improvements for the IETF that affect one or more support organization's activity;
O変数、およびしばしば不明瞭、IETFリーダーシップと他の組織間の責任の文書化。これは、ハード1つの以上の支持組織の活動に影響を与えるIETFための方法と議論すると効果の改善を決定することを可能にします。
o unclear budgeting responsibilities -- the IETF leadership has to make decisions that will impact the revenues and costs of the supporting organizations, but the supporting organizations wear the direct effects of revenue and cost control. Information about the financial impact of decisions are not available to IETF leadership;
O不明瞭な予算編成の責任は - IETFリーダーシップは、支持団体の収入とコストに影響を与える決定を行うために持っていますが、支援団体は、収益とコストコントロールの直接の影響を着用してください。意思決定の財務的影響に関する情報は、IETFリーダーシップには使用できません。
o partitioned finances -- it's not possible for the IETF to make changes that would affect the balance of revenue and costs across the revenue sources/expense commitments. For example, raising meeting fees wouldn't pay for more RFC Editor resources; more support from ISOC doesn't address any needs for IETF working group support functions;
O財政を分割 - それは収入源/費用の約束を越え収入とコストのバランスに影響を与える変更を加えることがIETFのためにことはできません。例えば、会議の手数料を上げると、よりRFC Editorのリソースのために払っていないでしょう。 ISOCからのより多くのサポートは、IETFワーキンググループの支援機能のためのあらゆるニーズに対応していません。
o the lack of clarity and the partitioning make it very hard for the IETF leadership, and the community as a whole, to determine points of accountability and implement changes for a healthy future.
明確さの欠如とパーティショニングoを説明責任の点を決定し、健全な未来のための変更を実装するために、全体としてIETFリーダーシップ、そして地域社会のために非常に懸命にそれを作ります。
Appendix C. Consultation with ISI: RFC Editor
RFC編集者：ISIと付録C.相談
Note: "RFC2223bis" in the text below refers to RFC 2223bis [4], a work in progress to update RFC 2223 [3].
注：以下のテキストにおける "RFC2223bis" のRFC 2223bisを指す[4]、RFC 2223を更新するために進行中の作業[3]。
Responses to Questions from IAB Advisory Committee
for the RFC Editor
October 6, 2003
2003年10月6日
* * (1) Your description of the function you are performing. Is * that function, and its relationship to the IETF, adequately * described in RFC 2223bis, or is additional description * required? If the latter, what would you suggest?
* *（1）あなたが実行している機能のご説明。 *その関数であり、IETFとの関係、十分* RFC 2223bisで説明した、または追加の説明が必要*ですか？後者の場合、あなたは何を示唆していますか？
ANSWER:
回答：
A comprehensive summary of current RFC Editor functions is attached below. Note that this list has no direct relation to RFC 2223bis, which contains instructions to RFC authors.
現在のRFCエディタ機能の包括的な概要は以下に添付されます。このリストはRFC作者への指示が含まれているRFCの2223bis、とは直接関係がないことに注意してください。
* * (2) What staff is being used to perform these functions and * what are their particular skills for doing so (either * individually or in the aggregate)? *
* *（2）どのようなスタッフがこれらの機能を実行するために使用されていると*そうするための彼らの特定のスキルは何ですか（どちらか*個別に、または集計中）？ *
ANSWER:
回答：
For 30 years, the RFC Editor was Jon Postel, a research scientist and manager in the Networking Division of the USC Information Sciences Institute (ISI). It is currently organized as a project within ISI, using the ISI infrastructure. The following ISI staff members comprise the RFC Editor project:
30年については、RFC Editorはジョンポステル、USC情報科学研究所（ISI）のネットワーキング部門の研究者やマネージャーでした。現在では、ISIのインフラストラクチャを使用して、ISI内のプロジェクトとして編成されています。以下のISIの職員は、RFC Editorプロジェクトを構成します：
Joyce Reynolds 100% Bob Braden 10% Aaron Falk 10% Sandy Ginoza 100% Project Assistant 100% Graduate Research Asst. 50%
ジョイスレイノルズ100％ボブブレーデン10％アーロンフォーク10％サンディ宜野座100％プロジェクトアシスタント100％大学院研究ASST。 50％
Braden and Reynolds jointly manage the RFC Editor project, with oversight of personnel and budgets.
ブレーデンとレイノルズは共同で人員と予算の監督で、RFC Editorのプロジェクトを管理します。
Joyce Reynolds has been contributing her editorial and management skills to the Internet since 1979. She performed the IANA functions under Jon Postel's direction from 1983 until Postel's death in October 1998. She continued to perform the IANA protocol parameter tasks on loan from ISI to ICANN, from 1998 to 2001. She was IANA liaison to the IESG from 1998 to 2001, transitioning the role to Michelle Cotton in the 2001.
ジョイスレイノルズは彼女は、彼女はISIからICANNへの融資にIANAプロトコルパラメータのタスクを実行し続け1998年10月におけるポステルの死まで1983年からジョン・ポステルの指示の下IANAの機能を実行し、1979年以来、インターネットへの彼女の編集と管理能力を貢献しています1998年から2001年に彼女は2001年にミシェル・コットンの役割を移行、1998年から2001年までIESGにIANA連絡でした。
Reynolds performed the RFC Editor functions under Jon Postel's direction from 1987 until 1998. Reynolds has been a member of the IETF since 1988, and she served as User Services Area Director on the IESG for 10 years. Reynolds now serves a liaison to the IAB and IESG. She handles the final proofing and quality control on RFCs prior to publication.
レイノルズは、ジョン・ポステルの指示の下RFCエディタの機能を実行し1987年から1998年まで、レイノルズは1988年以来、IETFのメンバーとなっている、と彼女は10年間、IESGにユーザーとしてサービスエリアディレクターを務めました。レイノルズは現在、IABとIESGへのリエゾンを提供しています。彼女は出版に先立ってのRFCの最終校正と品質管理を処理します。
Bob Braden has made many contributions to the Internet protocol technology and community. He helped design TCP/IP during the original research period beginning in 1978, and he has devoted his professional career since 1978 to the Internet. He served for 13 years on the original IAB and as its Executive Director for about 5 years. Since 1998 Braden has been co-leader of the RFC Editor project. He is the principal reviewer of individual submissions. He also works on technical issues related to the RFC Editor project.
ボブブレーデンは、インターネットプロトコル技術とコミュニティに多くの貢献をしてきました。彼は1978年に始まり、元の研究期間中に設計TCP / IPを助け、彼はインターネットに1978年以来、彼のプロとしてのキャリアを捧げました。彼は約5年前から、元のIAB上、そのエグゼクティブディレクターとして13年間務めました。 1998年以来ブレーデンは、RFC Editorプロジェクトの共同リードしてきました。彼は、個々の提出の主な審査です。彼はまた、RFC Editorプロジェクトに関連する技術的な問題に取り組んでいます。
Aaron Falk is a significant player in the IETF as a Working Group chair, in the areas of transport protocols and satellite technology. On the RFC Editor team, he assists with policy questions and handles technical development, overseeing the work of the grad student programmer.
アーロンフォークは、トランスポートプロトコルと衛星技術の分野では、作業部会の議長としてIETFにおける重要なプレーヤーです。 RFC Editorのチームでは、彼は政策の問題を支援し、大学院生プログラマの仕事を監督し、技術開発を担当します。
Sandy Ginoza is the principal technical editor. She is generally responsible for managing the RFC Editor queue and much of the day-to-day interface with the IESG and authors. Ginoza sends and receives a LOT of email, and she plays a central role in the operation.
サンディ宜野座は主要テクニカルエディターです。彼女は、RFC EditorのキューとIESGと著者との日々のインタフェースの多くを管理するための一般的責任があります。宜野座は送信した電子メールのLOTを受け、彼女は運転中に中心的な役割を果たしています。
Two part-time Project Assistants, Mieke Van de Kamp and Alison De La Cruz, do editing, mark-up, and initial proofing of individual RFCs. Our goal is to have three pairs of eyes read every RFC word-for-word, and in most instances we are able to do so.
二つのパートタイムのプロジェクトアシスタント、Miekeヴァン・デ・カンプとアリソン・デ・ラ・クルスは、編集、マークアップ、および個々のRFCの初期校正を行います。私たちの目標は、すべてのRFCの逐語を読んで、目の3組を持っていることであり、ほとんどの場合、我々はそうすることができます。
A half-time USC Graduate Research Assistant provides programming support by developing, extending, and maintaining RFC Editor scripts and tools.
ハーフタイムUSC大学院リサーチアシスタントは、開発拡張、およびRFCエディタのスクリプトやツールを維持することによって、プログラミング・サポートを提供します。
* (3) What criteria do you use to determine whether you are being * successful, and how successful? Using those criteria, how * successful are you and what could be done, especially from the * IETF side, to improve that evaluation?
*（3）どのような基準あなたは*成功している、そしてどのように成功しているかどうかを判断するために使うのですか？これらの基準を使用して、あなたはどのように*成功していると何がその評価を向上させるために、特に* IETF側から、行うことができますか？
ANSWER:
回答：
We can begin with a historical perspective on this question. When Jon Postel unexpectedly passed away 5 years ago, Reynolds and Braden took on the challenge of carrying on Postel's RFC Editor function. The publication stream continued, with a modest increase in quantity and, we believe, no loss of quality. Furthermore, the transition was largely invisible to the IETF. In addition, the new RFC Editor project has significantly defined and clarified the publication process, improved the web site, added tools to improve productivity and quality, and adapted the procedures to changing realities. We are proud of these achievements.
私たちは、この質問に歴史的な視点で始めることができます。ジョンポステルが予期せず5年前に亡くなったとき、レイノルズとブレーデンはポステルのRFCエディタの機能に運ぶの挑戦を引き受けました。出版物の流れは、量の適度な増加と、私たちは信じて、品質を損なうことなく、続けました。さらに、移行はIETFへの大部分は見えませんでした。また、新しいRFC Editorのプロジェクトが大幅に定義され、公開プロセスを明らかにした、ウェブサイトを改善し、生産性と品質を改善するためのツールを追加し、変化する現実に手続きを適応。我々は、これらの成果を誇りに思っています。
The three primary axes for measuring RFC Editor success are (1) quantity, (2) quality, and (3) accessibility.
RFCエディタの成功を測定するための3つの主要軸（1）の量、（2）品質、及び（3）アクセス可能性です。
1. Quantity
1.数量
Roughly, quantitative success means the ability to keep up with the submission rate. Since the submission rate tends to be bursty, to avoid long delays we need an average capacity somewhat in excess of the average.
大雑把に、定量的な成功は、送信速度に追いつくために能力を意味します。以来提出率は、我々はやや平均以上の平均容量を必要とする長い遅延を回避するために、バースト的になる傾向があります。
RFC publication is necessarily a heavily labor-intensive process.
RFCの出版物は、必ずしも多額の労働集約的なプロセスです。
Our goal is generally to complete the publication process in less than 4 weeks, exclusive of external factors beyond our control -- normative dependence upon other documents, delays by authors or the IESG, IANA delays, etc.
他の文書の際に規範的な依存、著者またはIESG、IANAの遅延によって遅延など - 私たちの目標は、私たちのコントロールを超えた外部要因の排他的な4週間未満、で公開プロセスを完了するために、一般的です
2. Quality
2.品質
Publication quality is harder to measure, but "we know it when we see it." Considering quality as the absence of faults, by noting faults we can observe lack of quality.
出版品質は「私たちはそれを見たとき、我々はそれを知っている。」を測定するのは難しいですが、障害の有無などの品質を考慮すると、障害に注目することによって、私たちは、品質の欠如を観察することができます。
One measure of faults is the number of errata that appear after publication. In addition, there may be faults apparent to a reader, such as a meaningless title, confusing organization, useless Abstract, inadequate introduction, confusing formatting, bad sentences, or bad grammar. There are of course limits to our ability to repair bad writing; ultimately, quality depends upon the authors as well as the editing process.
障害の1つの尺度は、出版後に表示され正誤表の数です。加えて、そのような無意味なタイトル、混乱組織、無駄な抽象的、不十分な導入、混乱フォーマッティング、悪い文、または悪い文法として読者には明らかで障害があってもよいです。悪い書き込みを修復するために我々の能力にもちろん制限であります。最終的には、品質が作家としてだけでなく、編集プロセスに依存します。
The only way to maintain quality is to continually monitor our work internally, to track external complaints, and to adjust our practice to correct frequent faults. Specific faults have sometimes led us to create new tools for checking consistency, to avoid clerical errors. Sometimes they have led to new user guidelines (e.g., on abbreviations or on Abstract sections.)
品質を維持する唯一の方法は、継続的に、内部的に私たちの仕事を監視するために、外部の苦情を追跡するために、そして頻繁に障害を修正するために私たちの練習を調整することです。具体的な障害は時々事務エラーを回避するために、一貫性をチェックするための新しいツールを作成するために私たちを導いてきました。時には彼らは、新しいユーザーガイドラインにつながっている（例えば、略語のか抽象セクションで。）
3. Accessibility
3.アクセシビリティ
An important part of the RFC Editor function is to provide a database for locating relevant RFCs. This is actually a very hard problem, because there is often a complex semantic web among RFCs on a particular topic. We have made great improvements in our search engine and web site, but there is undoubtedly a need for more progress in this area. The challenge is to provide better guideposts to users without creating a significant additional manpower requirement.
RFCエディタ機能の重要な部分は、関連するRFCを配置するためのデータベースを提供することです。多くの場合、特定のトピックに関するRFCの間の複雑なセマンティックWebがあるので、これは、実際には非常に難しい問題です。私たちは、検索エンジンやウェブサイトでの大きな改良を加えているが、この分野で多くの進展の必要性は間違いなくあります。課題は、重要な追加人員の要件を作成することなく、ユーザーへのより良い道しるべを提供することです。
We make heavy use of our own search and access tools, and this gives us feedback on their success and sometimes suggests improvements.
我々は独自の検索やアクセスツールを多用するが、これは彼らの成功に私達にフィードバックを与え、時には改善を示唆しています。
Finally, we offer some specific suggestions to answer the question, "What can the IETF do to improve the RFC Editor's evaluation" (i.e., our service to the community)?
最後に、我々は質問に答えるためにいくつかの具体的な提案は、「何IETFは、RFC編集者の評価を向上させるために行うことができます」を提供（すなわち、地域社会への私たちのサービス）？
1. Give us better documents to publish. Many are well written and organized, but some are bad and a few are very bad and need a great deal of work to create acceptable publications. Better input documents will improve both our quantity and our quality.
1.私たちに公開するためのよりよい文書を与えます。多くはよく書かれており、組織化が、一部は悪いですし、いくつかは非常に悪いですし、許容可能な出版物を作成するために多くの作業を必要としています。より良い入力文書は、当社の数量と私たちの品質の両方を改善します。
The IESG has been making a large effort to improve the quality of Internet Drafts before they become RFCs, and we are very grateful for this.
IESGは、彼らがRFCになる前に、インターネットドラフトの品質を向上させるために大きな努力をしてきた、と私たちは、このために非常に感謝しています。
One issue of particular concern is the increasing number of RFCs authored by non-English speakers. These can consume much extra editorial effort. We don't know any solution to this problem, but we know that the IESG is aware of it and working with them to provide editorial assistance when necessary within working groups.
特に懸念の1つの問題は、非英語話者が執筆したRFCの数の増加です。これらは、多くの余分な社説労力を消費することができます。私たちは、この問題への解決策を知りませんが、我々はIESGはそれを認識していることを知っているし、彼らと一緒に作業する作業グループ内で必要な編集の援助を提供します。
2. Prepare a series of RFCs containing "road maps" that describe the semantic web of RFCs in a particular area. Although these would rapidly become out-dated in detail, they would still provide very important guides to RFC readers.
2.特定のエリアにRFCのセマンティックウェブを記述する「ロードマップ」を含むRFCのシリーズを準備します。これらは急速に詳細に時代遅れになるだろうが、彼らはまだRFCの読者にとって非常に重要なガイドを提供することになります。
The RFC Editor is as self-critical as any organization could be, but we believe there is no objective basis for claiming that we are not doing a good job for the Internet. We continually strive to do a better job.
RFC Editorは自己批判任意の組織は可能性としてとしてですが、我々は、インターネットのために良い仕事をしていないことを主張のための客観的根拠がないと考えています。我々は継続的に、より良い仕事をするために努力しています。
* * (4) How would you characterize the quality of your relationship * with the IETF and its leadership? Is there mutual trust and a * sense of working together on issues, or do you and your * colleagues sometimes see the relationship as adversarial? *
* *（4）どのようにIETFやその指導者との関係*の品質を特徴づけるでしょうか？相互の信頼と問題に一緒に仕事の*の感があり、またはあなたとあなたの*同僚が、時には敵対としての関係を見ていますか？ *
ANSWER:
回答：
The RFC Editor shares with much of the rest of the Internet community a deep desire to advance the technology and practice of the Internet. We consider ourselves partners with the IETF, the IESG, and the IAB in this endeavor.
インターネットコミュニティの残りの多くとRFCエディタの株式は、深い欲望が、インターネットの技術と実践を進めるために。私たちは自分自身IETF、IESG、およびこの努力でIABとの提携を検討してください。
Although the major goals coincide, the IESG and the RFC Editor quite properly have somewhat different priorities. The RFC Editor's role, historically and currently, is to create and maintain the RFC document series as a high-quality and vital channel for technical communication, while the IESG is concerned with managing the Internet engineering and standards process. This difference sometimes leads to honest disagreements, but we have generally worked out mutually-satisfactory solutions to these conflicts.
主要な目標は一致しますが、IESGとRFC Editorはかなり適切に多少異なる優先順位を持っています。 IESGは、インターネット技術と標準化のプロセスを管理すると懸念している間、RFC編集者の役割は、歴史的に、現在、技術的な通信のための高品質で重要なチャネルとしてRFCドキュメントシリーズを作成し、維持することです。この違いは、時には正直な意見の相違につながるが、我々は、一般的に、これらの紛争に相互に満足のいく解決策を打ち出してきました。
The word "adversarial" seems completely inappropriate, and we are struggling to understand what could have led to its appearance here.
「敵対的」という言葉は、完全に不適切と思われる、と我々はここで、その外観につながったかもしれないかを理解するために苦労しています。
* (5) Are there specific known problems you would like us to look * at and understand? If so, please describe them.
*（5）あなたは私たちがで*見て、理解したいと思いますが、特定の既知の問題はありますか？もしそうなら、それを説明してください。
ANSWER:
回答：
(A) The length of time for IESG review and recommendations on individual submissions has sometimes become excessive. We understand the load of IESG members, but we would like to ask their help in keeping response to a few months.
（A）IESGレビューと個々の提出に関する勧告のための時間の長さは、時には過剰になっています。私たちは、IESGメンバーの負荷を理解するが、我々は数ヶ月に応答を維持するのに彼らの助けをお願いしたいと思います。
The RFC Editor has been attempting to raise the bar on accepting
individual submissions, to avoid wasting valuable IESG time as
well as to maintain (or improve) the quality of the RFC series.
(B) We would like understanding and support of the RFC Editor's statutory and historic responsibility to publish significant technical documents about networking that originate outside the IETF standards process. This publication has several important purposes.
（B）私たちは、IETF標準化プロセスの外に発信ネットワーキングに関する重要な技術文書を公開するRFC編集者の法定や歴史的責任の理解と支援をしたいと思います。この刊行物は、いくつかの重要な目的があります。
One is to bring out new technical ideas for consideration and
discussion. We believe that the future success of the Internet
demands an infusion of new ideas (or old ideas revitalized), and
that the publication of such ideas as RFCs is important.
Another purpose is to build a shared literature of mature technical discussion, to help avoid the periodic re-discussions that take place on our mailing lists.
もう一つの目的は、私たちのメーリングリストで行われ、定期的に再議論を避けるために、成熟した技術的な議論の共有文学を構築することです。
Finally, the RFC series provides a historic repository for important ideas. We have come across a number of examples of important suggestions and partial technology developments that have been lost, or hard to locate, because they were not published as RFCs. The community spends too much of our time re-inventing many, many wheels.
最後に、RFCシリーズは重要なアイデアのための歴史的なリポジトリを提供します。これらはRFCとして公表されていなかったので、私たちは、重要な提案や紛失、または見つけるのは難しいされている部分の技術開発の多くの例に遭遇してきました。コミュニティは、私たちの時間を再発明し、多くの、多くの車輪のあまりを費やしています。
Our ultimate goal is to publish more high-quality submissions, so we can raise the bar for publication.
私たちの究極の目標は、より高品質の提出を公開することであるので、我々は出版のためのバーを上げることができます。
Independent submission publications represent only a minor fraction of the RFC production. For example, so far in calendar 2003 we have published 178 RFCs, including 14 independent submissions. If all the drafts that we think deserve to be preserved as RFCs were to be published, this fraction would grow, but we would not expect it to grow beyond 25% of the total number of published RFCs.
独立した提出資料は、RFC生産のわずかな割合を表します。例えば、これまでのカレンダー2003年には14点の独立した応募作品を含む178のRFCを、公開しています。我々はRFCとして保存されるに値すると思うすべてのドラフトが公開されることはしていた場合は、この割合は育つだろうが、我々はそれが公表されたRFCの総数の25％を超えて成長するために期待していません。
(C) We would like to work with the IAB/IESG in re-examining the issue of normative references. We believe that the current definition of normative is ambiguous and unclear, and that as a result some publications may be unnecessarily held up for normative references where these are unnecessary.
（C）私たちは、引用規格の問題を再検討してIAB / IESGで仕事をしたいと思います。私たちは、規範の現在の定義が曖昧で不明瞭、その結果として、いくつかの出版物が不必要にこれらが不要な規範的な参照用に保持してもよいということであると信じています。
(D) We would like to cooperate in an investigation of the issues in extending the character set beyond US-ASCII, .e.g., to UTF-8. A major issue is whether there is a set of preparation, display, and searching tools for both the RFC Editor and the RFC consumers. These tools need to be ubiquitously available and mature enough.
（D）私たちは、UTF-8に、US-ASCIIを超えて文字セットを、.e.g。拡張に問題の調査に協力したいと思います。大きな問題は、RFCエディタおよびRFC消費者の両方のための準備、ディスプレイ、および検索ツールのセットがあるかどうかです。これらのツールは、普遍的に利用可能と十分に成熟する必要があります。
The RFC Editor is looking for input on how we can best continue to serve the community. We are grateful for the suggestions we have received, and we have adopted as many of them as feasible; the result has been quite a long list of incremental improvements in our service over the past 5 years.
RFC Editorは、我々は最高の地域社会に奉仕し続けることができますどのように入力を探しています。私たちは、私たちが受けているの提案に感謝していて、我々として実現可能なそれらの多くが採用しています。その結果、過去5年間に当社のサービスにおける漸進的な改善のかなり長いリストとなっています。
* * (6) How do you see the costs of your function evolving? If * things become more costly over time, what are the main * determiners of cost (e.g., general inflation, general IETF * growth, increase in the number of particular functions you are * carried out to perform,...). Are you doing some things that * IETF (IESG or otherwise) request that you do not consider * cost-effective and, if so, what are they? * *
* *（6）どのようにあなたの機能が進化のコストを見ていますか？ *物事が時間をかけてより高価になる場合は、費用（あなたが*実行するために行われている特定の機能の数は、例えば、一般的なインフレ、一般的なIETF *成長、増加、...）の主な*詞は何ですか。そうならば、あなたは、*費用対効果を検討していない要求を（そうでない場合はIESGまたは）IETFの*いくつかのことをやっている、彼らは何ですか？ * *
ANSWER:
回答：
The major cost factor is the number of documents submitted and published. This has grown relatively slowly over time. It appears to us that the IETF process has (perhaps fortunately) been the bottleneck that has kept the rate of RFC production from growing exponentially. We do not expect that to change dramatically.
主要なコスト要因は、提出され、公表された文書の数です。これは、時間をかけて、比較的ゆっくりと成長してきました。 IETFプロセスが（おそらく幸い）指数関数的に成長しているからRFC生成の速度を維持していますボトルネックになっていることを私たちに表示されます。私たちは、それが劇的に変化することを期待しないでください。
In more detail, the cost factors are:
より詳細には、コスト要因は以下のとおりです。
(a) Inflation (on salaries)
（給与上）（a）のインフレ
This shows a small and predictable annual increase.
これは小さく、予測可能な年次増加を示しています。
(b) The number of RFCs published.
（b）に発表されたRFCの数。
This is the primary cost factor. The bulk of the editorial
and coordinating functions are directly attributable to
specific documents. At present, we estimate that this cost
category represents 70% of our personnel time, and 63% of our
cost.
(c) Tasks not directly related to specific RFCs.
（C）タスクは、直接特定のRFCに関連していません。
This includes many functions: management (budget and personnel
as well as policy and procedure development), IETF liaison,
reviews of independent submissions, development and
maintenance of web pages, scripts, and tools, the RFC Online
project, maintaining the Errata web page, etc. These are
currently estimated to require 30% of our personnel time, and
37% of our cost.
Minor extensions of function can be absorbed with little extra cost (but at a leisurely pace). We are not proposing any major functional extensions at this time; such extensions would have to be costed separately (were money available for them.)
機能のマイナーな機能拡張は、少し余分なコストで（しかし、のんびりペースで）吸収することができます。私たちは、この時点ですべての主要な機能拡張を提案されていません。そのような拡張は、個別原価計算されなければならない（そのために利用可能なお金でした。）
Disk storage and web services are provided by ISI's support organization and are treated as overhead. Most of the desktop machines used by the project were originally bought under research contracts, although the RFC Editor budget includes a very small item for equipment upgrades.
ディスクストレージやWebサービスは、ISIのサポート組織によって提供され、オーバーヘッドとして扱われます。 RFCエディタの予算は、機器のアップグレードのための非常に小さなアイテムを備えているが、プロジェクトで使用するデスクトップマシンの大半はもともと、研究契約の下で購入されました。
APPENDIX -- FUNCTIONS OF RFC EDITOR
付録 - RFC EDITORの機能
OVERVIEW
概要
The RFC Editor edits and publishes the archival series of RFC (originally "Request for Comment") documents. The RFCs form an archival series of memos about computer communication and packet switching networks that records the technical history of the ARPAnet and the Internet, beginning in 1969. The RFC Editor is funded by the Internet Society and operates under the general direction of the IAB (Internet Architecture Board).
RFC Editorの編集およびRFCのアーカイブ、一連のドキュメント（本来は「要求のコメント」）を発行しています。 RFCは、インターネット協会によって運営されている1969年ザ・RFCエディタで始まり、ARPAnetの、インターネットの技術的な履歴を記録し、（IABの一般的な方向の下で動作するコンピュータ通信とパケット交換ネットワークに関するメモのアーカイブシリーズを形成しますインターネットアーキテクチャ委員会）。
The RFC Editor publishes RFCs and a master index of the RFC series electronically on the Internet, via all common access protocols (currently, the Web, email, rsync, and FTP). It announces the existence of each new RFC via electronic mail to one or more mailing lists. The RFC Editor maintains a comprehensive web site with a variety of tools and lists to locate and access RFCs. This website also contains general information about RFC editorial policies, publication queue status, errata, and any other information that will make the RFC series more accessible and more useful.
RFC Editorはすべての一般的なアクセスプロトコル（現在は、ウェブ、電子メール、rsyncを、およびFTP）を介して、インターネット上で電子的にRFCおよびRFCシリーズのマスターインデックスを発行しています。これは、1つのまたは複数のメーリングリストに電子メールを介して新しいRFCの存在を発表しました。 RFC EditorはRFCを検索し、アクセスするためのツールやリストの様々な包括的なウェブサイトを維持します。このウェブサイトでは、RFC編集方針、出版キューの状態、正誤表、およびRFCシリーズはよりアクセスし、より使いやすくなり、他の情報に関する一般的な情報が含まれています。
During the RFC editing process, the RFC Editor strives for quality, clarity, and consistency of style and format. Editorial guidelines and procedures to achieve these ends are established by the RFC Editor in consultation with the IAB and IESG (Internet Engineering Steering Group). The RFC Editor periodically publishes a revision of these its guidelines to authors.
RFC編集処理中に、RFC Editorはスタイルとフォーマットの品質、明瞭性、および一貫性のために努力しています。編集ガイドラインおよびこれらの目的を達成するための手順は、IABとIESG（インターネットエンジニアリング運営グループ）と協議してRFC編集者によって確立されています。 RFC Editorは定期的に作者にこれらのガイドラインの改訂を公表しています。
The RFC Editor coordinates closely with the IESG to carry out the Internet standards process as documented in the latest revision of "The Internet Standards Process" and later amendments. The RFC Editor also coordinates closely with the Internet Assigned Numbers Authority (IANA), to ensure that the parameters used in new and revised protocol descriptions are properly registered.
RFC Editorは、「インターネット標準プロセス」と、後に改正の最新版に記載されているように、インターネットの標準化プロセスを実行するためにIESGと緊密に調整します。 RFCエディタはまた、新規および改訂されたプロトコルの説明で使用されるパラメータが正しく登録されていることを確認するために、インターネット割り当て番号機関（IANA）と密接に調整します。
SPECIFIC TASKS
特定のタスク
I. Editing and publishing RFCs
I.編集と出版のRFC
(1) Publication process. The RFC Editor edits and publishes RFCs in accordance with RFC 2026 (or replacement documents) and RFC 2223bis. This includes the following tasks:
（1）公開プロセス。 RFC Editorは編集およびRFC 2026（または交換文書）とのRFC 2223bisに従ってRFCを発行しています。これは、次のタスクが含まれます。
(a) Performing the final editing of the documents to maintain consistency of style, editorial standards, and clarity.
（a）のスタイル、編集基準、及び明確性の一貫性を維持するために、文書の最後の編集を行います。
At minimum, the RFC Editor:
最低でも、RFC編集者：
(i) Copy-edits the documents, including the correction of spelling and grammar, and some checking for inconsistent notation. Ambiguous sentences are resolved with the authors.
（i）は、スペルや文法の修正、および一貫性のない表記のためのいくつかのチェックを含む文書を、コピー、編集します。あいまいな文章は、著者で解決されています。
(ii) Enforces the formatting rules of Section 3 of RFC 2223bis
（II）のRFC 2223bisの第3のフォーマットルールを強制
(iii) Ensures that sections follow guidelines and rules of Section 4 of RFC 2223bis.
（iii）のセクションでは、ガイドラインとのRFC 2223bisのセクション4の規則に従うことを保証します。
(iv) Verifies the consistency of references and citations, and verifies contents of references to RFCs and I-Ds.
（IV）参照および引用の整合性を検証し、RFCおよびI-DSへの参照の内容を検証します。
(v) Verifies that all normative dependencies have been satisfied.
（v）のすべての規定の依存関係が満たされていることを確認します。
(vi) Verifies that guidelines from Section 2 of RFC 2223bis are followed, with respect to: URLs, titles, abbreviations, IANA Considerations, author lists, and Requirement-Level words.
URL、タイトル、略語、IANAの考慮事項、著者リスト、および要件レベルの単語：（VI）のRFC 2223bisの第2節から指針がに関して、従っていることを確認します。
(vii) Typesets the documents in the standard RFC style.
（VII）の標準RFCのスタイルで文書を植字。
(viii) Verifies the correctness of published MIBs and ABNF fragments, using compilers.
（VIII）コンパイラを使用して、公表MIBとABNF断片の正しさを検証します。
(b) Providing authors with a review period of no less than 48 hours to approve the document.
（b）は、文書を承認するために劣らず48時間以上の審査期間と著者を提供します。
(c) Publishing new RFCs online by installing them in the official RFC archive, which is accessible via HTTP, FTP, and SMTP. The RFC Editor also provides compressed aggregate files of subsets of the complete RFC series, accessible via HTTP and FTP. PDF facsimiles are also maintained for all .txt RFCs.
（C）HTTP、FTP、およびSMTP経由でアクセス可能であり、公式RFCアーカイブ、それらをインストールすることで、オンラインで新しいRFCを公開。 RFC Editorはまた、HTTPやFTP経由でアクセス可能完全なRFCシリーズのサブセットの圧縮されたファイルを集合し、提供します。 PDFのファクシミリは、すべての.txtのRFCのために維持されています。
(d) Publicly announcing the availability of new RFCs via a mailing list.
（d）の公的メーリングリストを通じて新しいRFCの可用性を発表。
(e) Coordinating with the IANA for assignment of protocol parameter values for RFCs in the submission queue.
（E）送信キューにRFCのプロトコルパラメータ値の割り当てのためのIANAと連携。
(f) Coordinating closely with the IESG to ensure that the rules of RFC 2026 (or replacement) are followed. RFC Editor personnel attend IETF meetings. A designated RFC Editor person serves as liaison to the IAB and IESG.
（F）RFC 2026（または交換）のルールに従っていることを確実にするためにIESGと密接にコーディネート。 RFC Editorの担当者は、IETF会合に出席します。指定されたRFCエディタ人はIABとIESGへの連絡係として機能します。
(2) Individual Submission Publication
（2）個別提出公報
The RFC Editor publishes technically competent and useful documents that arise outside the IETF process, in accordance with RFC 2026. The RFC Editor makes the final determination on the publishability of such documents, with review by the IESG and input from knowledgeable persons.
RFC EditorはIETFプロセス外で生じる技術的有能で有用な文書を発行し、RFC 2026に従って、RFC EditorはIESGによって検討および有識者からの入力と、そのような文書のpublishabilityの最終決意をします。
The RFC Editor reviews all such documents for acceptable editorial quality and for content, and works with the authors when necessary to raise the quality to an acceptable level.
RFC Editorは許容編集品質のためとコンテンツのすべてのそのような文書をレビューし、許容可能なレベルにまで品質を高めるために、必要なときに、著者で動作します。
(3) Online RFC meta-information
（3）オンラインRFCメタ情報
The RFC editor publishes the following status information via the Web and FTP.
RFCエディタは、WebやFTPを経由して、次のステータス情報を公開しています。
(a) A list of all RFCs currently published, including complete bibliographic information and document status. This list is published both in human and machine-readable (XML) forms.
（a）は、完全な書誌情報や文書のステータスを含め、現在公開されているすべてのRFCのリストを。このリストは、人間と機械可読（XML）形式の両方で公開されています。
(b) A document consisting of summaries of RFCs in each range of 100.
（b）は、文書100の各範囲内のRFCの要約からなります。
(c) A list of errors found in published RFCs.
（c）の公表のRFCで見つかったエラーのリスト。
(d) An "RFC Editor Queue" specifying the stage of every document in the process of editing, review, and publication.
（D）「RFCエディタキュー」編集、レビュー、および出版物のプロセスにおけるすべての文書の段階を指定します。
(e) An RFC Editor web site containing
含む（e）はRFC EditorのWebサイト
(i) A search engine for RFCs.
(ii) Information on the RFC publication process.
(iii) Links to the above published items.
(4) Public Queries
（4）公共のクエリ
Responding to, and when appropriate, redirecting, a wide range of email queries received in the RFC Editor mailbox.
対応、および適切な場合、リダイレクト、RFCエディタのメールボックスに受信した電子メールの問い合わせの広い範囲。
II. Improved Process and Infrastructure
II。改善されたプロセスとインフラストラクチャ
When resources allow, the RFC Editor makes improvements to its processes and to the RFC repository infrastructure. This includes improvements and extensions to the set of scripts used by the RFC Editor: (i) to maintain its databases and web pages, and (ii) to increase the efficiency and quality of the editing process.
リソースが許可すると、RFC EditorはそのプロセスにおよびRFCリポジトリインフラストラクチャに改善を行います。これは、RFC編集者によって使用されるスクリプトのセットの改良と拡張が含まれています。（ⅰ）そのデータベースやWebページを維持するため、および（ii）編集プロセスの効率と品質を向上させます。
Changes in procedure are often suggested by IETF members as well as by the IESG. Here are some examples of changes that are either in process or have been suggested for possible action in the future.
手順の変更は、多くの場合、IETFメンバーによってだけでなく、IESGによって提案されています。ここでは、プロセスのいずれかであるか、将来的に可能なアクションのために提案された変更のいくつかの例があります。
(1) Publication process
（1）公開プロセス
(a) Accepting documents in XML encoding when there is an
accompanying tool that will produce nroff markup.
(b) Studying the feasibility of editing the XML form of submitted documents, prior to producing the final nroff and .txt versions.
（b）の前に、最終のnroffと.txtのバージョンを生成することに提出された文書のXML形式を編集する可能性を研究。
(c) Adopting additional tools for verifying formal specification languages used in RFCs in addition to MIBs, PIBs, and ABNF.
（c）は、MIBのに加えて、RFCで使用され、正式な仕様記述言語を検証するための追加ツールを採用のPIB、およびABNF。
(2) Database Accessibility and Quality
（2）データベースのアクセシビリティと品質
(d) Improving the usefulness of the Errata information
（D）正誤表情報の有用性を改善
(i) Distinguish mere typographic errors from errors of
substance
(ii) Link errata to RFC index on web page.
(e) Providing Web-based "enhanced" views of RFCs, including:
：（E）を含むRFCのWebベースの「強化」のビューを提供
(i) Links to other related RFCs and references.
(ii) Links to and from online errata pages.
(3) Maintaining an online repository of the corrected values of MIBs that have been published in RFCs.
（3）RFCで公表されているのMIBの補正された値のオンラインリポジトリを維持します。
(4) Completing the RFC Online project, to bring online those early RFCs that are available only in paper form.
（4）オンラインのみ紙のフォームで利用可能なこれらの初期のRFCをもたらすために、RFCオンラインプロジェクトを完了。
Appendix D. Consultation with Foretec/CNRI: Secretariat and Meeting Planning
事務局とミーティング企画：Foretec / CNRIと付録D.相談
Secretariat Responses to Questions from
IAB Advisory Committee
November 7, 2003
2003年11月7日
* (1) Your description of the function you are performing. Is that * function, and its relationship to the IETF, adequately * understood for working purposes, or is additional description * required? If the latter, what would you suggest?
*（1）あなたが実行している機能のご説明を。 *機能を、とIETFとの関係、適切に*作業の目的のために理解し、または追加の説明が必要*であることを？後者の場合、あなたは何を示唆していますか？
The Secretariat work is divided into four parts: Meeting Planning, WG support, IESG support, and IETF Community support.
会議の企画、WGのサポート、IESGのサポート、およびIETFコミュニティのサポート：事務局の仕事は、4つの部分に分かれています。
IETF meeting planning includes: identifying venues; negotiating contracts; working closely with the WG chairs and the IESG to schedule events and avoid conflicts; preparing the agendas for the WG sessions; arranging for F&B and AV; handling registration; seeking and signing up hosts; providing Internet access, a terminal room, and a wireless network when a host is not available; providing on-site support; and preparing the proceedings. Meeting planning also may include organizing the IESG retreat.
IETF会議の計画が含まれています：特定の会場を。契約交渉。イベントをスケジュールして競合を避けるために、WGチェアとIESGと緊密に協力し、 WGセッションの議題を準備します。 F＆BとAVのための配置。登録を取り扱います。求めているとホストを申し込みます。ホストが利用できない場合、インターネットアクセス、端末室、無線ネットワークを提供します。オンサイトサポートを提供します。そして、手続きを準備します。ミーティングの計画もIESGの隠れ家を整理挙げられます。
WG support includes: maintaining and updating charters, milestones, and other information for the 140+ WGs; tracking changes in chairs; hosting and archiving the discussion mailing lists; and processing requests to publish IDs as RFCs.
WGサポートが含ま：140+のWGのための維持及び更新チャーターを、マイルストーン、およびその他の情報。椅子の変化を追跡します。ホスティングやディスカッションメーリングリストのアーカイブ。およびRFCなどのIDを発行する要求を処理します。
IESG support includes: providing all support required for IESG teleconferences, which take place every two weeks and cover as many as 20+ documents each (i.e., processing "Last Calls", preparing the agenda and package, moderating the teleconference, preparing the minutes, sending out approval announcements, and updating the information in the ID Tracker); tracking the movement of I-Ds to RFCs; interfacing with the RFC Editor; performing administrative functions associated with WG creation, rechartering, and closing; maintaining the internal IESG Web pages; sending miscellaneous message to the IETF announcement list on behalf of the IESG, and posting them to the Web site, where applicable (e.g., appeals to the IESG and IESG responses to appeals); providing support to the NomCom, as needed (i.e., sending announcements, hosting/updating the Web site, arranging for conference calls); and developing Web-based tools to support IESG decision-making.
IESGサポートが含まれています：2週間毎に場所を取るし、できるだけ多く20+などの文書の各（すなわち、処理「ラストコール」をカバーしIESGのテレビ会議のために必要なすべてのサポートを提供する分を準備し、会議を緩和、議題やパッケージを準備し、承認のアナウンスを送出し、IDトラッカーの情報）を更新。 RFCにI-DSの動きを追跡します。 RFC編集者とのインタフェース。 WGの作成、rechartering、および閉鎖に関連する管理機能を実行します。内部IESG Webページを維持します。 IESGに代わってIETFアナウンスメントリストにその他のメッセージを送信し、Webサイト、それらを掲示該当する場合（例えば、控訴へIESGとIESG回答への控訴）。必要に応じて（すなわち、アナウンスを送信するホスティング/ Webサイトを更新し、電話会議の手配）、NomComへのサポートを提供します。そして、IESGの意思決定をサポートするためのWebベースのツールを開発。
IETF Community support includes: running the IETF meetings; hosting the IETF Web site, and keeping the web site it up to date; hosting the IETF announcement and discussion lists; responding to enquiries sent to the IETF Secretariat, the Executive Director, the meeting Registrar, the Webmaster, and the trouble-ticket systems; processing Intellectual Property Rights Notices; processing Liaison Statements; and posting I-Ds.
IETFコミュニティのサポートが含まれています：IETFミーティングを実行しています。 IETFのWebサイトをホスティングし、これまでにウェブサイト、それを最新の状態に保ちます。 IETF発表とディスカッションリストをホスティングしています。 IETF事務局、エグゼクティブディレクター、会議の登録、ウェブマスター、トラブルチケットシステムに送信された問い合わせに対応。処理知的財産権に関するご注意。リエゾンステートメントを処理します。そして、I-DSを掲示します。
* (2) What staff is being used to perform these functions and * what are their particular skills for doing so (either * individually or in the aggregate)?
*（2）どのようなスタッフがこれらの機能を実行するために使用されていると*（いずれか*個別にまたは集約で）そのようにするための彼らの特定のスキルは何ですか？
-- Three people perform administrative functions. -- Four-and-a-half people perform technical support. -- One-and-a-half people do development. -- Three people do maintenance.
- 3人は管理機能を実行します。 - 四半の人々は、技術的なサポートを行います。 - ワン半の人々は、開発を行います。 - 3人は、メンテナンスを行います。
* (3) What criteria do you use to determine whether you are being * successful, and how successful? Using those criteria, how * successful are you and what could be done, especially from the * IETF side, to improve that evaluation?
*（3）どのような基準あなたは*成功している、そしてどのように成功しているかどうかを判断するために使うのですか？これらの基準を使用して、あなたはどのように*成功していると何がその評価を向上させるために、特に* IETF側から、行うことができますか？
The continued efficient operation and evolution of the Internet is one important goal and challenge facing the IETF, and also the IETF Secretariat. Working together to assist the IETF in performing this important function has been a motivating factor in CNRI's support for almost 15 years. The criteria followed by CNRI, and (more recently) its subsidiary Foretec, in their efforts on behalf of the entire Internet community is to provide a consistent and dependable mechanism that enables those persons interested in the many and varied issues that are raised within the IETF to perform their important work in the Internet standards process unburdened by the routine administrative tasks associated with such endeavors. While I think this has been a successful activity over many years, there is always room for improvement; and a continuing dialogue between CNRI, ISOC, and the IETF leadership is useful for this purpose. High on my list of suggestions would be finding a way to increase the funds available to meet the increasing demands placed on the Secretariat. We can no longer depend only on attendance fees at meetings for this purpose.
インターネットの継続的な効率的な運用と進化はIETF、また、IETF事務局が直面している一つの重要な目標と課題です。この重要な機能を実行する際にIETFを支援するために一緒に働くことは、ほぼ15年間、CNRIの支援における動機づけ要因となっています。 （最近で）CNRI続い基準、及びその子会社Foretecは、インターネットコミュニティ全体の代わりに彼らの努力にIETF内提起されている多種多様な問題に興味のある人の人物を可能に一貫して信頼性のメカニズムを提供することですこのような努力に関連した日常的な管理タスクで打ち明けたインターネット標準化過程で彼らの重要な仕事を実行します。私はこれが長年にわたり成功を収めてきた活動だと思いますが、常に改善の余地があります。そしてCNRI、ISOC、およびIETFリーダーシップとの継続的な対話は、この目的のために有用です。提案の私のリストの上位には、事務局に置か増加需要を満たすために利用可能な資金を増やすための方法を見つけることになります。私たちは、もはやこの目的のための会議で参加費用にのみ依存することはできません。
* (4) How would you characterize the quality of your relationship * with the IETF and its leadership? Is there mutual trust and a * sense of working together on issues, or do you and your * colleagues sometimes see the relationship as adversarial?
*（4）どのようにIETFやその指導者との関係*の品質を特徴づけるでしょうか？相互の信頼と問題に一緒に仕事の*の感があり、またはあなたとあなたの*同僚が、時には敵対としての関係を見ていますか？
While the Foretec management may have issues arising from day to day workflow demands on limited resources, CNRI values the trusted relationship we have had with the IETF community. The issue is cooperating in the development of new funding sources, and learning to live within the available resources. There is also an issue about effective lines of authority for the purpose of carrying out certain aspects of the overall standards process. There are many demands and pressures on the IESG and hence on the Secretariat. These workflow demands need to be addressed in a more systematic way for the benefit of all.
Foretec管理は限られたリソース上で一日のワークフローの要求に日から生じる問題を有していてもよいが、CNRIは、私たちがIETFコミュニティと持っていた、信頼関係を値。問題は、新たな資金調達源の開発に協力し、利用可能な資源の中に生きることを学んでいます。全体的な標準化プロセスの特定の側面を実行する目的のための権限の有効ラインについての問題もあります。 IESG上、したがって、事務局には多くの要求と圧力があります。これらのワークフローの要求は、すべての利益のために、より体系的な方法で対処する必要があります。
* (5) Are there specific known problems you would like us to look * at and understand? If so, please describe them.
*（5）あなたは私たちがで*見て、理解したいと思いますが、特定の既知の問題はありますか？もしそうなら、それを説明してください。
Workload is high. Given the budgetary constraints that the Secretariat is under, there are no resources to take on additional work. The staff supporting all areas are working overtime just to keep up with the current workload.
ワークロードが高いです。事務局は、下にある予算の制約を考えると、追加作業を取るために何のリソースはありません。すべての領域をサポートするスタッフは、ちょうど現在のワークロードに追いつくために残業しています。
The Secretariat does not believe that the IETF Community appreciates the scope of the tasks. The Secretariat is automating more tasks, hopefully reducing the overall workload. There is a long queue of requests for new features in the tools that the Secretariat has built. There is not money to hire more developers. The IETF Executive Director is documenting processes. This has naturally caused discussion about whether the processes are what everyone wants the processes to be. While expected, it also increases workload.
事務局は、IETFコミュニティは、タスクの範囲を高く評価していることを信じていません。事務局は、うまくいけば、全体の作業負荷を軽減、より多くのタスクを自動化しています。事務局が組み込まれているツールの新機能のリクエストの長蛇の列があります。より多くの開発者を雇うためにお金がありません。 IETFのエグゼクティブ・ディレクターは、プロセスを文書化しています。これは、自然のプロセスは、誰もがプロセスがあることを望んでいるかどうかについての議論を引き起こしました。予想されるが、それはまた、ワークロードが増加します。
* (6) How do you see the costs of your function evolving? If * things become more costly over time, what are the main * determiners of cost (e.g., general inflation, general IETF * growth, increase in the number of particular functions you are
*（6）どのようにあなたの機能が進化のコストを見ていますか？ *物事が時間をかけてより高価になっている場合、コスト（例えば、一般的なインフレ、特定の機能の数の一般的なIETF *成長、増加の主な*詞は何をしているあります
* carried out to perform,...). Are you doing some things that * IETF (IESG or otherwise) request that you do not consider * cost-effective and, if so, what are they?
*実行するために行われ、...）。そうならば、あなたは、*費用対効果を検討していない要求を（そうでない場合はIESGまたは）IETFの*いくつかのことをやっている、彼らは何ですか？
The total budget for IETF-related activities at Foretec last year was about $2.5M. The vast bulk was covered by IETF meeting fees, but the shortfall was covered by contributions from CNRI and Foretec.
IETFに関連する活動のための予算総額はForetecで、昨年はおよそ$ 2.5Mでした。広大なバルクは、IETFミーティング料で覆われていたが、不足分はCNRIとForetecからの寄付によって覆われていました。
CNRI has been asked by its Board to find a solution to the problem.
CNRIは、問題の解決策を見つけるために、その理事会に頼まれました。
Appendix E. Consultation with ICANN: IANA protocol Parameter Assignment
ICANNとの付録E.相談：IANAプロトコルのパラメータ割り付け
Responses to Questions from IAB Advisory Committee
for the IANA Protocol Parameter Assignment Function
November 7, 2003
2003年11月7日
* (1) Your description of the function you are performing. Is that * function, and its relationship to the IETF, adequately described in * RFC 2860 (the MOU) and RFC 2434 (Guidelines for IANA * considerations), or is additional description required? If the * latter, what would you suggest?
*（1）あなたが実行している機能のご説明を。 *機能を、とIETFとの関係が、十分* RFC 2860（MOU）に記載されており、RFC 2434（IANAのためのガイドライン*注意事項）、または追加の説明が必要であることですか？ *後者の場合、あなたは何を示唆していますか？
Per Michelle [Cotton, IANA], RFC 2860 probably remains sufficient as an MOU describing the functions that the IANA provides to the IETF. That office consists of, effective soon, a manager, three technical clerical staff (four full-time equivalents) plus half a dozen people on a consulting basis, performing functions for the IETF and the RIRs. The portion of that effort supporting IETF parameter assignment is roughly a full-time-equivalent plus software support and normal management/employment overheads. Fundamentally, the IETF parameter assignment function consists of accepting requests for protocol numbers for extensible protocols (such as IP Protocol, PPP PID, TCP/UDP Port, and the like), validating them according to business rules, identifying the appropriate registry, and in some cases portion of a registry, assigning the number, and documenting the result.
MOUは、IANAはIETFに提供する機能を説明するように当たりミシェル[綿、IANA]は、RFC 2860は、おそらく十分なままです。その事務所はIETFとのRIRのための機能を実行する、コンサルティング基づいて、効果的なやがて、マネージャー、3人の技術事務職員（4フルタイム換算）を加えた半ダースの人々で構成されています。 IETFパラメータの割り当てをサポートしているその努力の部分は大体フルタイムと同等のプラスソフトウェアのサポートと通常の管理/雇用のオーバーヘッドです。基本的に、IETFパラメータ割り付け機能は、適切なレジストリを識別する、ビジネスルールに従ってそれらを検証する、（例えばIPプロトコル、PPP PID、TCP / UDPポートなどの）拡張可能なプロトコルのプロトコル番号の要求を受け付けるから成り、そしてレジストリのいくつかのケース部分、番号を割り当て、その結果を文書化。
RFC 2434 has served the IANA staff well as a guide, but is now in need of updating. Specific concerns with the document relate to the meaning of terms and the specificity of the information provided to the IANA in internet drafts.
RFC 2434は、IANAのスタッフだけでなく、ガイドを務めますが、更新の必要性に今あるしています。文書での具体的な懸念は、用語の意味とインターネットドラフトにIANAに提供される情報の特異性に関係します。
One issue relates to the meaning of the term "IETF consensus". When a document has passed through a defined consensus process, such as a working group, this is straightforward. When requests come to IANA that have not done so, IANA needs specific guidance on IETF expectations. This generally comes in the form of AD direction or consulting advice. An improved process would help, though; business rules that inform the IANA when a new registry is appropriate, and what rules should be applied in assignment of values in any given registry, for example, would help.
1つの問題は、用語「IETFコンセンサス」の意味に関連します。文書は、そのようなワーキング・グループとして、定義された合意プロセスを通過したときに、これは簡単です。要求はしていないIANAに来たとき、IANAはIETFの期待に具体的な指針が必要です。これは、一般的にADの方向やコンサルティングアドバイスの形で提供されます。改良されたプロセスは、しかし、役立つだろう。新しいレジストリが適切である、そしてどのようなルールは、任意のレジストリの値の割り当てに適用されなければならないとき、IANAに通知するビジネスルールは、例えば、役立つだろう。
Parameter assignment being an essentially clerical function, specific guidance to the clerical staff is absolutely mandatory, and often lacking or unclear. In IANA's dreams, every internet draft would contain an IANA Considerations section, even if all it said was "IANA need not concern itself with this draft". In the absence of such a statement, the IESG's IANA Liaison is forced to read the entire document at least twice: once when the IESG is first handed the document, to ensure that any instructions to IANA are clear, and again when the IESG hands the document on, to ensure that it can perform the requests the draft makes. This is clearly time-consuming and prone to error.
パラメータの割り当ては、基本的に事務関数で、事務職員への具体的なガイダンスは絶対に必須であり、しばしば欠けているかは不明。 IANAの夢では、すべてのインターネットドラフトは、「IANAはこのドラフトで自身を心配する必要はありません」と言ったとしても、すべての場合には、IANAの考慮事項のセクションが含まれます。再びときIESG手IESGは最初のIANAへの指示が明確であることを保証するために、文書を渡され、一度とき、および：そのような記述がない場合には、IESGのIANAの連絡は、少なくとも二回、文書全体を読むことを余儀なくされますそれはドラフトが作る要求を実行できることを保証するために、上のドキュメント。これは明らかに時間がかかり、エラーを起こしやすいです。
IANA is now receiving a certain level of instruction in internet drafts, which is good. However, even the present level of advice is frequently lacking in clarity. For example, a PPP NCP definition might well require the assignment of two PIDs, one for the data exchange and one for the NCP itself. These two numbers come from four very separate ranges: 0001..00FF, 0101..7FFF, 8001..BFFF, and C001..FFFF. The choice of range is important, especially on low speed lines using byte-oriented asynchronous transmission, as the data assignment has a trade-off implied for the relative frequency of messages using the specified protocol, and the control function PIDs are partitioned as well. In such a case, IANA needs to know not that "two PIDs are required", but that "two PPP PIDs are required, the data PID named <d-name$gt; defined in section <> from the range 0001..00FF, and the control PID named <c-name$gt; defined in section <> from the range 8001..BFFF".
IANAは今良いですインターネットドラフトでの命令の一定のレベルを、受信しています。しかし、アドバイスのも、現在のレベルは、頻繁に明快に欠けています。例えば、PPP NCPの定義はよく2つのPID、NCP自体のデータ交換のために1つずつの割り当てが必要な場合があります。 0001..00FF、0101..7FFF、8001..BFFF、およびC001..FFFF：これらの2つの数字が4つの非常に別々の範囲から来ます。データの割り当てが指定されたプロトコルを使用してメッセージの相対的な周波数に対して暗黙トレードオフを有し、制御機能のPIDが同様に分配される範囲の選択は、特に、バイト指向の非同期送信を使用して、低速回線上で重要です。このような場合には、IANA「は、2つのPIDが必要である」ことはない知っている必要があるが、二つのPPP PIDが必要である」こと、データPID名前<D-名$ GT;範囲0001..00FFからセクション<>で定義されています、および制御PID名前<C-名$ GT;範囲8001..BFFFからセクション<>で定義されています」。
Descriptions of registries to be designed need to be equally clear. If the specification says in its IANA Considerations section that "a registry named 'Fubar Code Points' should be built; the initial values in a table <name> and IANA may assign additional values in any remaining value between the last initial code point and 65535", that is exactly what will happen. If there are additional expectations, such as "the working group's assigned number advisor will be asked" or "all assignments must be made in an RFC of informational or standard status", they won't necessarily be met - unless the IANA Considerations section specifies as much. What you put in the IANA Considerations section is what will be followed. It should be made clear so that the implementors get what they requested. Also, clear IANA Considerations sections also help the community, not only IANA.
設計するレジストリの説明は、同様に明確にする必要があります。仕様は 『めちゃくちゃコードポイント』という名前のレジストリを構築しなければならない」というそのIANAの考慮事項のセクションで述べている場合は、初期値を表に<名前>とIANAは、最後の最初のコードポイントと65535の間の任意の残りの値に追加の値を割り当てることができ」、それは何が起こるかを正確です。ある場合など、追加の期待、「ワーキンググループに割り当てられた番号の顧問が求められます」または「すべての割り当ては、情報または標準状態のRFCになされなければならない」、彼らは必ずしも満たされることはありません - IANAの考慮事項のセクションを指定しない限り、できるだけ多く。あなたはIANAの考慮事項のセクションに置かは続くされるものです。実装者は、彼らが要求したものを手に入れるように、それは明らかにされなければなりません。また、明確なIANAの考慮事項のセクションでは、まただけでなく、コミュニティを支援IANA。
It makes (1) the authors think about all aspects of the creation of a registry and instructions on how to maintain but also (2) the public knows and understands the new registry instructions and how they can get assignments/registrations in that registry.
それは、（1）著者は維持する方法については、レジストリおよび命令の創造のすべての側面を考えるだけでなく、（2）国民が知っていると理解して、新しいレジストリ命令をし、どのように彼らはそのレジストリ内の割り当て/登録を取得することができます。
Something that would materially help the IANA in its evaluation of internet drafts is a comment tracking system on the IETF side. The IANA's use of such a system is apparent: any comments it makes on the draft would appear in the system, where the IESG may readily retrieve them, and the IANA can find its comments when the draft later comes there. To be truly helpful, it should also include at least any last call IETF commentary and AD commentary, including agreed changes to the document. This would permit IANA to review those notes as well, which may in turn elicit further IANA commentary ("if you make that change, you should also specify <> in the IANA Considerations section") or may guide IANA's implementation.
実質のインターネットドラフトのその評価にIANAを助ける何かがIETF側のコメント追跡システムです。このようなシステムのIANAの使用は明らかである：それはドラフトにする任意のコメントはIESGが容易にそれらを検索することができるシステム、に現れる、とドラフトが後が来るとき、IANAは、そのコメントを見つけることができます。真に有用であるために、それはまた、文書に同意した変更を含む、少なくともいずれかの最後の呼び出しIETF解説とADの解説を、含むべきです。これは、順番に、さらにIANAの解説を引き出す可能性があるだけでなく、それらのノートを確認するためにIANAを可能にする（「あなたがその変更を行った場合、あなたはまた、IANAの考慮事項のセクションで> <指定してください」）またはIANAの実装を案内することができます。
Normative references apply to IANA considerations as well as to other parts of the specification. Recently, the IESG started passing documents along prior to other documents normative for them, allowing them to sit in later queues to synchronize with their normative documents. In the special case where the normative document defines a registry and the draft under discussion assigns a value from that registry, this case needs to be handled in queue and in process like any other normative reference.
引用規格は、IANAの考慮にだけでなく、明細書の他の部分に適用されます。最近、IESGは彼らの規範文書と同期するように、後でキューに座ってできるように、事前にそれらのための規範的な他の文書に沿って文書を渡し始めました。規範文書は、レジストリを定義し、検討中の草案は、そのレジストリから値を割り当てる特別な場合には、この場合は、他の規範的基準のようなキューに、プロセスで処理する必要があります。
* (2) What staff is being used to perform these functions and what * are their particular skills for doing so (either individually or * in the aggregate)?
*（2）どのようなスタッフがこれらの機能を実行するために使用されているとどのような*は（総額で個別に、または*のいずれか）そうするために彼らの特定のスキルですか！
The staff assigned to this function, on 4 November 2003, includes Michelle Cotton and an assistant. They are essentially intelligent clerical staff familiar with computer back office applications, but otherwise with no special technical training. For technical questions, they depend heavily on advisors within IANA or assigned by the IETF.
この機能に割り当てられているスタッフは、2003年11月4日に、ミシェル・コットンとアシスタントが含まれています。彼らは基本的にコンピュータのバックオフィスアプリケーションに精通したインテリジェント事務職員ですが、それ以外は特別な技術的な訓練を受けました。技術的な質問については、彼らがIETFによって割り当てられたIANAまたは内の顧問に大きく依存しています。
It should be kept in mind that it is not the IANA's job to understand how every protocol works that is being defined in a new registry. The IANA needs to know how to create and maintain the registry administratively.
新しいレジストリで定義されているか、すべてのプロトコルの動作を理解するためにIANAの仕事ではないことを心に留めておくべきです。 IANAが管理上のレジストリを作成し、維持する方法を知っている必要があります。
* (3) What criteria do you use to determine whether you are being * successful, and how successful? Using those criteria, how * successful are you and what could be done, especially from the IETF * side, to improve that evaluation?
*（3）どのような基準あなたは*成功している、そしてどのように成功しているかどうかを判断するために使うのですか？これらの基準を使用して、あなたはどのように*成功していると何がその評価を向上させるために、特にIETF *側から、行うことができますか？
The basic measure of success is the number of assignments made.
成功の基本的な尺度は作ら割り当て数です。
Michelle's sense is that IANA is now moderately successful, however further improvement can be made internally and externally.
ミシェルの感覚は、IANAが今適度に成功した、しかし、さらなる改善が内部と外部行うことが可能であるということです。
Paul is defining web-based automation which should help various aspects of IANA's work, including in part the IETF IANA function. Michelle believes that this automation will materially help her timeliness. But for that to be carried out properly, clear business guidelines must be given IANA for each of the existing registries, guidelines whose application can be readily automated. This is likely an IETF effort, or at least requires serious IETF input.
ポールはIETF IANAの機能を一部に含むIANAの仕事のさまざまな側面を、助けるべきウェブベースの自動化を定義しています。ミシェルは、この自動化が著しく、彼女の適時性を助けると考えています。それが適切に実施されるために。しかし、明確なビジネスのガイドラインは、そのアプリケーションに容易に自動化することができ、既存のレジストリ、ガイドラインのそれぞれについて、IANAが与えられなければなりません。これはおそらく、IETFの努力で、または少なくとも重大なIETFの入力が必要です。
* (4) How would you characterize the quality of your relationship * with the IETF and its leadership? Is there mutual trust and a * sense of working together on issues, or do you and your * colleagues sometimes see the relationship as adversarial?
*（4）どのようにIETFやその指導者との関係*の品質を特徴づけるでしょうか？相互の信頼と問題に一緒に仕事の*の感があり、またはあなたとあなたの*同僚が、時には敵対としての関係を見ていますか？
At this point, Michelle feels that IETF/IAB leadership is friendly and generally constructive. She is very cognizant of AD workload, and as such tries to focus questions and find other people to ask them of. As such, she perceives the communication level and volume to be on the light side of "about right".
この時点で、ミシェルは、IETF / IABのリーダーシップはフレンドリーで、一般的に建設的であると感じています。彼女は非常にADのワークロードを認識し、そして、そのような試みが質問に焦点を当てるとのそれらを求めるために他の人を見つけるようです。このように、彼女は、「約右」の光側になるように、通信レベル及び音量を知覚します。
Again, amplified clarity of IESG/WG policy would reduce her question load, and there may be utility for an IAB liaison from the IANA such as IANA has with the IESG. That is really a question for the IAB; if it has questions for IANA, the chair should feel free to invite her comment or invite a liaison.
再び、IESG / WGポリシーの増幅された透明度は彼女の質問の負荷を減少させるであろう、そしてそのようなIANAはIESGで有するとしてIANAからIABの連絡のための有用性があるかもしれません。それは本当にIABについて質問です。それはIANAのための質問を持っている場合、椅子は彼女のコメントを招待するか、リエゾンを招待して自由に感じるはずです。
* (5) Are there specific known problems you would like us to look at * and understand? If so, please describe them.
*（5）あなたは私たちが*を見て、理解したいと思いますが、特定の既知の問題はありますか？もしそうなら、それを説明してください。
This note has made a point concerning clarity of instructions, clarity of policy, and clarity of registries. There is ongoing work at IANA to clean up registry files inherited when IANA was split out from the RFC Editor's office; in dealing with the business considerations questions already raised, it may be helpful for a tiger team from the IETF to review their registries with them and make suggestions.
このノートでは、レジストリの説明書の明確性、政策の明確さ、および明瞭に関わるポイントを作っています。 IANAがRFCエディタのオフィスから出て分割された時に継承されたレジストリファイルをクリーンアップするIANAで進行中の作業があります。すでに調達ビジネス上の考慮事項の質問に対処する上で、それは彼らと彼らのレジストリを検討し、提案を行うためにIETFから虎のチームのために役に立つかもしれません。
There is an ongoing problem with receiving announcements concerning at least some internet drafts. Michelle plans to follow up with the Secretariat on this, but in short it appears that the IANA liaison is not copied on at least some list that internet draft actions are announced on. This seems to pertain to individual submissions that the IESG advises the RFC Editor that it "has no problem" publishing.
少なくともいくつかのインターネットドラフトに関するアナウンスを受けるとの継続的な問題があります。ミシェルは、この上で、事務局をフォローアップする予定ですが、要するにIANAのリエゾンは、インターネットドラフトアクションが上に発表された少なくともいくつかのリストにコピーされていないことが表示されます。これは、IESGはそれが出版「問題がない」というRFC Editorをアドバイスし、個々の提出に関連しているようです。
* (6) How do you see the costs of your function evolving? If things * become more costly over time, what are the main determiners of * cost (e.g., general inflation, general IETF growth, increase in the * number of particular functions you are carried out to * perform,...). Are you doing some things that IETF (IESG or * otherwise) request that you do not consider cost-effective and, * if so, what are they?
*（6）どのようにあなたの機能が進化のコストを見ていますか？物事が時間をかけてより高価になる*場合は、*コスト（例えば、一般的なインフレ、一般IETF成長、あなたが*実行するために行われている特定の機能の*数の増加、...）の主な詞は何ですか。あなたは（それ以外の場合はIESGまたは*）もしそうなら、あなたが費用対効果の高いと、*を考慮していない要求をいくつかのものIETFをやっている、彼らは何ですか？
As detailed, the function described in RFC 2860 represents approximately a person-equivalent, plus facilities, software support, and standard business loading. This has been the approximate load level for at least the past five years, and is projected to remain about the same for the near future. The cost-effectiveness issues revolve around human-in-the-loop effort involved in reading drafts, investigating inquiries, and such that have been detailed here. The sense is that an effective comment management system plus the work flow systems ICANN is planning to implement should result in a net near term improvement in efficiency and timeliness; projected IETF growth should then consume that improvement over time.
詳述したように、RFC 2860に記述されている関数は、およそ人相当、プラスの設備、ソフトウェアのサポート、および標準的なビジネスの負荷を表しています。これは、少なくとも過去5年間のおおよその負荷レベルとなっており、近い将来のためにほぼ同じままと予測されています。費用対効果の問題は、お問い合わせを調査し、読み取りドラフトに関わる人間・イン・ザ・ループの努力を中心に展開し、ここでは詳述されているように。センスが効果的なコメント管理システムに加えてワークフローシステムは、ICANNは、効率性と適時性の純短期的な改善をもたらすべきで実装することを計画しているということです。投影IETFの成長は、時間の経過とともにその改善を消費する必要があります。
Author's Address
著者のアドレス
IAB Advisory Committee IETF
IAB諮問委員会IETF
EMail: iab@iab.org
メールアドレス：iab@iab.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。