[要約] RFC 3716は、IETFの大規模な管理と実行に関するガイドラインです。その目的は、IETFの運営を効果的かつ効率的に行うための手順とプロセスを提供することです。
Network Working Group IAB Advisory Committee
Request for Comments: 3716 IETF
Category: Informational March 2004
The IETF in the Large: Administration and Execution
大規模なIETF：管理と実行
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（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議長はIAB諮問委員会（Advcomm）を設立し、既存のIETF管理構造と関係（RFCエディター、IETF事務局、IANA）をレビューし、IETFの変更を提案する義務があります。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議長はIAB諮問委員会（Advcomm）を設立し、既存のIETF管理構造と関係（RFCエディター、IETF事務局、IANA）をレビューし、IETFの変更を提案する義務があります。IETFの全体的な機能を改善するための管理プロセスまたは構造。この目的は、IAB諮問委員会（AdvComm）チャーターで定義され、付録Aにコピーされました。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の組織間管理関係を管理することに志願している、または志願されている個人の多くが含まれていました。したがって、委員会の作業の第1段階には、それらの関係に関する暗黙の知識の体を共有して議論することが含まれていました。これには、付録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.
最後に、委員会は、IETFが、前進するこれらの要件を満たすために管理構造を再編成することをどのように検討するかについてのいくつかのアドバイスをまとめました - セクション4。
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.
Advcommは、IETFのエグゼクティブ構造に集中するよう努めました。これは、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、WGS、IAB、IRTF、およびRGSが明示的に含まれています。この包括的な感覚は、「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 Communications IETFドキュメント追跡作業ドキュメント管理（メーリングリスト、ウェブサイト、リポジトリ）
IAB support
IABサポート
Telechats Communications Working document management (mailing list, website, repository)
Telechats Communications Working Document Management（メーリングリスト、Webサイト、リポジトリ）
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
Webサイト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：Corporation for National Research Initiatives（CNRI）は1986年に設立され、1987年以来、CNRIはIETF事務局サービスを提供することでコミュニティにサービスを提供してきました。1990年代初頭まで、CNRIはIETFおよびIETF事務局に法的支援を提供しました。ISOCが設立された後、ISOCは、IETF椅子、IESG、IAB、エリアディレクター、ワーキンググループチェアの努力を含むIETFの実質的な作業に対する全体的な法的責任を想定しました。CNRIは、IETF事務局の実質的な仕組みに対する運用責任を引き受けました。1998年、活動のオーバーヘッドコストを削減するために、事務局は、CNRI forprofit子会社（Foretec Seminars、Inc。）の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ドキュメントシリーズは、1969年から30年間から1969年から始まるインターネット（元々はArpanet）に関する技術的および組織的なメモのセットです。、RFCの編集者は、USC Information Sciences Institute（ISI）のネットワーキング部門の研究科学者兼マネージャーであるJon Postelであり、その機能は徐々に彼が率いるチームに進化しました。RFCエディターアクティビティは現在、ISIインフラストラクチャを使用してISI内のプロジェクトとして編成されており、ISOCとの契約でサポートされています。RFCエディターはRFCSの出版社であり、ドキュメントの最終編集レビュー、およびそれらのドキュメントのオンラインリポジトリとインデックスのメンテナンスを担当しています。
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）のインターネット企業は、1998年にIPアドレススペース割り当て、プロトコルパラメーターの割り当て、ドメイン名システム管理、ルートサーバーシステム管理機能の責任を負うために設立された非営利法人です。IANA（ISI）およびその他のエンティティによる米国政府契約の下で実行されました。
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）Funds RFC Editor Misc 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の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チェアプレゼンテーションで詳述されています[2]）。
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制度記憶は、多くの場合、人々の心以外には記録されていません。
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管理およびエグゼクティブ構造内では、いくつかの変更が必要です。
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は、すべての収入源を考慮し、IETFの実行に関与するすべての費用を1つの予算の断片として考慮することができる必要があります。合理的に必要な資金。
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にとって、セクション3で概説されているすべての要件を満たすために、IETF管理組織の変更が必要であることが明らかに見えました。
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 しかし、これには、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の適切に実装された形式化により、リソース管理、意思決定、スチュワードシップの統一が可能になると考えています。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のリーダーシップは、より詳細に探索するために1つを選択し、行動の決定を下すのに十分な詳細を持つアクション提案を策定する場合があります。
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の管理の形式主義を増やすための1つの潜在的な道は、その関係をさらに定義することです。このモデルは、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).
ISOCとIETFアクティビティとの既存の法的関係と、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.
それ自体が明確な法人として、子会社はその使命を達成するために独立して責任を負います。そのレベルの独立は、ISOC内のIETFをさらに正式化するという概念に直接反対する概念に対処しています。IETFミッションは、ISOCのより広いミッションの他の側面になる傾向がある組織のニーズによって混乱する可能性があります。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との関係は密接なものであり続けることです。子会社は、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に作業を収容するよりも、より多くの作業を作成する必要があります。子会社は、ミッションを実行するために必要なリソースとフレームワークの両方が確実にあることを保証するために、ITと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.
写真を完成させるには、3番目のオプションを考慮する必要があります。ISOCの子会社を別の法人として作成する代わりに、まったく新しい法人「IETF、Inc。」、または「IETF、LLC」を、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が最初の数回の会議のコミットメントを処理するのに十分な初期運転資金を取得する必要があります。事前の会議料金から運転資金を調達することは考えられるでしょうが、そのような資金調達計画は誤りの余地をあまり残しません。赤で走る最初の会議の1つ以上が、駆け出しの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.
さらに、このような動きがISOCの使命を実行する能力に与える影響と、政府組織とのIETFの地位を考慮する必要があります。
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コミュニティとISOCのアドバイスと同意を得て行動するIETFのリーダーシップは、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は、RFC編集者、IANA、事務局、および事務局の時間、労力、ケアを、入力を提供し、Advcommの質問に応答し、付録に示されている協議テキストをレビュー/修正することに心から感謝しています。
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 Bernard Aboba O Harald Alvestrand（IETF議長）O Lynn St.Amour（ISOC社長）O Fred Baker（ISOC理事会の議長）O Brian Carpenter O Steve Crocker O Leslie Daigle（IAB委員長、委員会の議長）O Russ Housleyoジョン・クレンシン
[1] Hoffman, P. and S. Bradner, "Defining the IETF", BCP 58, RFC 3233, February 2002.
[1] Hoffman、P。and S. Bradner、「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] Postel、J。およびJ. Reynolds、「RFC著者への指示」、RFC 2223、1997年10月。
[4] Reynolds, J. and B. Braden, Eds., "Instructions to Request for Comments (RFC) Authors", Work in Progress.
[4] Reynolds、J。and B. Braden、eds。、「コメントを要求する指示（RFC）著者」、Work in Progress。
Date: Tue, 02 Sep 2003 16:34:58 -0400
From: Leslie Daigle
Subject: Formation of IAB Advisory Committee
To: IETF-Announce: ;
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議長のレスリー・デイグルが議長を務めており、次のようになります。
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 Bernard Aboba O Harald Alvestrand（IETF議長）O Lynn St.Amour（ISOC社長）O Fred Baker（ISOC理事会の議長）O Brian Carpenter O Steve Crocker O Leslie Daigle（IAB委員長、委員会の議長）O Russ Housleyoジョン・クレンシン
Additional input is welcome. The committee will also make a particular effort to seek out further input as needed. --
追加の入力は大歓迎です。委員会はまた、必要に応じてさらなるインプットを探すために特別な努力をします。 -
Input contributed by Harald Alvestrand (IETF Chair) and Leslie Daigle (IAB Chair).
Harald Alvestrand（IETFチェア）とLeslie Daigle（IAB Chair）が寄稿した入力。
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;
o IETF WGSのボランティアは、経済学ではなく、エンジニアリング作業に（ほとんど）集中することができます。
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椅子と古いバージョンのチャーターのリスト、いくつかは言及しています）。
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;
o IETFのリーダーシップの責任は明確に特定されていません - 通常、IETFとIABの椅子によって処理され、IESGと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エディターリソースに支払われません。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のリーダーシップ、およびコミュニティ全体が説明責任のポイントを決定し、健全な未来のために変更を実施することが非常に困難になります。
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
RFCエディターのIABアドバイザリー委員会からの質問への回答
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)? * ANSWER:
* *（2）これらの機能を実行するためにどのスタッフが使用されているのか *そうするための特定のスキルは何ですか（個別または集合体）？* 答え：
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編集者は、USC Information Sciences Institute（ISI）のネットワーキング部門の研究科学者兼マネージャーであるJon Postelでした。現在、ISIインフラストラクチャを使用して、ISI内のプロジェクトとして編成されています。次のISIスタッフは、RFCエディタープロジェクトを構成しています。
Joyce Reynolds 100%
Bob Braden 10%
Aaron Falk 10%
Sandy Ginoza 100%
Project Assistant 100%
Graduate Research Asst. 50%
Braden and Reynolds jointly manage the RFC Editor project, with oversight of personnel and budgets.
BradenとReynoldsは、RFCエディタープロジェクトを共同で管理し、人員と予算を監視します。
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.
ジョイス・レイノルズは、1979年からインターネットに編集および管理スキルをインターネットに貢献しています。彼女は、1983年から1998年10月のポストエルの死までのジョン・ポストエルの指示の下でIANA機能を実行しました。1998年から2001年まで。彼女は1998年から2001年までIESGにイーナ連絡を取り、2001年にミシェルコットンにその役割を移行しました。
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.
Reynoldsは、1987年から1998年までJon Postelの指示の下でRFCエディター機能を実行しました。レイノルズは1988年からIETFのメンバーであり、IESGで10年間ユーザーサービスエリアディレクターを務めました。レイノルズは現在、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年以来彼のプロとしてのキャリアをインターネットに捧げてきました。彼は元のIABで13年間、約5年間エグゼクティブディレクターとして勤務しました。1998年以来、BradenはRFCエディタープロジェクトの共同リーダーを務めています。彼は個々の提出物の主要なレビュアーです。彼はまた、RFCエディタープロジェクトに関連する技術的な問題に取り組んでいます。
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エディターチームでは、ポリシーの質問を支援し、技術開発を処理し、卒業生プログラマーの作業を監督しています。
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.
Sandy Ginozaは主要な技術編集者です。彼女は一般に、RFCエディターキューとIESGおよび著者との日々のインターフェースの多くを管理する責任があります。Ginozaは多くのメールを送信して受け取り、操作において中心的な役割を果たしています。
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.
2人のパートタイムプロジェクトアシスタント、Mieke Van de KampとAlison de La Cruzは、個々のRFCの編集、マークアップ、および初期校正を行います。私たちの目標は、3つのペアの目をすべてのRFCワード用ワードごとに読むことであり、ほとんどの場合、私たちはそうすることができます。
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年前に予期せず亡くなったとき、レイノルズとブレーデンは、PostelのRFCエディター機能を引き継ぐという挑戦を引き受けました。出版物のストリームは継続され、量がわずかに増加し、品質の損失はないと考えています。さらに、遷移はIETFにはほとんど見えませんでした。さらに、新しいRFCエディタープロジェクトは、出版プロセスを大幅に定義および明確にし、Webサイトを改善し、生産性と品質を向上させるツールを追加し、現実の変化に手順を適合させました。私たちはこれらの成果を誇りに思っています。
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.
私たちの目標は、一般に、私たちの制御を超えた外部要因を除いて、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があることが多いため、これは実際には非常に難しい問題です。検索エンジンと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)? 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.
最後に、「RFCエディターの評価を改善するためにIETFが何ができるか」（つまり、コミュニティへのサービス）という質問に答えるために、いくつかの具体的な提案を提供します。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エディターは、どの組織と同じように自己批判的ですが、インターネットで良い仕事をしていないと主張する客観的な根拠はないと考えています。私たちは絶えずより良い仕事をするよう努めています。
* * (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エディターは非常に適切に異なります。RFCエディターの役割は、歴史的および現在、RFCドキュメントシリーズを技術コミュニケーションのための高品質で重要なチャネルとして作成および維持することですが、IESGはインターネットエンジニアリングと標準プロセスの管理に関心があります。この違いは、正直な意見の相違につながることがありますが、私たちは一般に、これらの紛争に対する相互に魅力的な解決策を解決しました。
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.
RFCエディターは、個々の提出物を受け入れることでバーを上げようとしており、貴重なIESG時間を無駄にしないようにし、RFCシリーズの品質を維持（または改善）しようとしています。
(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.
1つは、検討と議論のために新しい技術的なアイデアを引き出すことです。インターネットの将来の成功には、新しいアイデア（または古いアイデアが活性化された）の注入が必要であり、RFCなどのアイデアの公開が重要であると考えています。
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.
もう1つの目的は、成熟した技術的議論の共有文献を作成し、メーリングリストで行われる定期的な再議論を回避することです。
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シリーズは、重要なアイデアのための歴史的なリポジトリを提供します。rfcsとして公開されていないため、失われた、または見つけるのが難しい、または見つけるのが難しい重要な提案と部分的な技術開発の多くの例に出くわしました。コミュニティは、多くの多くの車輪を再発明するのに私たちの時間を費やしすぎています。
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）us-asciiを超えてセットを拡張する際の問題の調査に協力したいと思います。主な問題は、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エディターは、コミュニティへのサービスを最大限に活用する方法についての入力を探しています。私たちは受け取った提案に感謝しており、それらの多くを実現可能であると採用しました。その結果、過去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?
*
*
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.
これが主要なコスト要因です。編集および調整機能の大部分は、特定のドキュメントに直接起因します。現在、このコストカテゴリは人事時間の70％、コストの63％を占めていると推定しています。
(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.
これには、管理（予算と人員、ポリシーと手順の開発）、IETFリエゾン、独立した提出、Webページの開発とメンテナンスのレビュー、スクリプト、ツール、RFCオンラインプロジェクト、Errata Webページの維持、多くの機能が含まれます。など。これらは現在、当社の人事時間の30％、および当社の費用の37％を必要とすると推定されています。
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エディターの関数
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エディターは、RFC（元々は「コメントのリクエスト」）ドキュメントのアーカイブシリーズを編集および公開します。RFCSは、1969年からARPANETとインターネットの技術履歴を記録するコンピューター通信とパケットスイッチングネットワークに関するメモのアーカイブシリーズを形成します。RFCエディターはインターネット協会によって資金提供され、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エディターは、すべての一般的なアクセスプロトコル（現在、Web、電子メール、RSYNC、FTP）を介して、インターネット上でRFCとRFCシリーズのマスターインデックスを電子的に公開しています。電子メールを介して1つ以上のメーリングリストに新しいRFCの存在を発表します。RFCエディターは、RFCを見つけてアクセスするためのさまざまなツールとリストを備えた包括的なWebサイトを維持しています。このWebサイトには、RFC編集ポリシー、出版キューステータス、ERRATA、および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エディターは、スタイルとフォーマットの品質、明確さ、一貫性を目指して努力しています。これらの目的を達成するための編集ガイドラインと手順は、IABおよびIESG（インターネットエンジニアリングステアリンググループ）と相談して、RFCエディターによって確立されます。RFCエディターは、これらのガイドラインの改訂を著者に定期的に公開しています。
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エディターは、IESGと密接に調整し、「インターネット標準プロセス」および後の修正の最新の改訂に記載されているインターネット標準プロセスを実行します。RFCエディターは、インターネットが割り当てられた番号当局（IANA）と密接に調整し、新しい改訂されたプロトコルの説明で使用されるパラメーターが適切に登録されていることを確認します。
SPECIFIC TASKS
特定のタスク
I. Editing and publishing RFCs
I. RFCSの編集と公開
(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エディターは、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.
（vi）RFC 2223bisのセクション2のガイドラインが、URL、タイトル、略語、IANAの考慮事項、著者リスト、および要件レベルの単語に関して、そのガイドラインに従います。
(vii) Typesets the documents in the standard RFC style.
（vii）標準のRFCスタイルでドキュメントを入力します。
(viii) Verifies the correctness of published MIBs and ABNF fragments, using compilers.
（viii）コンパイラを使用して、公開されたMIBSおよび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アーカイブにそれらをインストールして、新しいRFCSをオンラインで公開します。RFCエディターは、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) IESGと密接に調整して、RFC 2026（または交換）のルールが守られていることを確認します。RFCエディターの人員は、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エディターは、RFC 2026に従って、IETFプロセスの外部で発生する技術的に有能で有用なドキュメントを公開しています。RFCエディターは、IESGによるレビューと知識豊富な人からの入力により、そのようなドキュメントの発行可能性に関する最終決定を行います。
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エディターは、そのようなすべてのドキュメントを受け入れ可能な編集品質とコンテンツについてレビューし、必要に応じて著者と協力して、品質を許容レベルに上げることができます。
(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) 公開されているRFCSで見つかったエラーのリスト。
(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エディターWebサイトを含む
(i) A search engine for RFCs. (ii) Information on the RFC publication process. (iii) Links to the above published items.
(i) RFCの検索エンジン。（ii）RFC出版プロセスに関する情報。（iii）上記の公開されたアイテムへのリンク。
(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エディターはそのプロセスとRFCリポジトリインフラストラクチャを改善します。これには、RFCエディターが使用するスクリプトのセットの改善と拡張機能が含まれます。（i）データベースと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.
(a) XMLエンコードのドキュメントを受け入れ、nroffマークアップを生成するツールが付随するツールがある場合。
(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) MIBS、PIBS、およびABNFに加えて、RFCで使用される正式な仕様言語を検証するための追加のツールを採用します。
(2) Database Accessibility and Quality
(2) データベースのアクセシビリティと品質
(d) Improving the usefulness of the Errata information
(d) ERRATA情報の有用性を改善します
(i) Distinguish mere typographic errors from errors of substance (ii) Link errata to RFC index on web page.
(i) 単なる誤植を、物質の誤差（ii）リンクERRATAにWebページでRFCインデックスに区別します。
(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.
(i) 他の関連RFCおよび参照へのリンク。（ii）オンラインErrataページとのリンクとリンク。
(3) Maintaining an online repository of the corrected values of MIBs that have been published in RFCs.
(3) RFCSで公開されている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
付録D. Foretec/CNRIとの相談：事務局および会議計画
Secretariat Responses to Questions from IAB Advisory Committee
IAB諮問委員会からの質問に対する事務局の回答
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 WGSのチャーター、マイルストーン、およびその他の情報の維持と更新が含まれます。椅子の変更の追跡。ディスカッションメーリングリストのホスティングとアーカイブ。IDをRFCとして公開するための処理リクエスト。
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のサポートには、IESGテレコンファレンスに必要なすべてのサポートを提供します。これは、2週間ごとに行われ、それぞれ最大20のドキュメントをカバーします（つまり、「最後の呼び出し」の処理、アジェンダとパッケージの準備、通信の緩和、議事録の準備、送信承認の発表とIDトラッカーの情報の更新）;I-DSのRFCへの移動を追跡します。RFCエディターとのインターフェース。WGの作成、充電、および閉鎖に関連する管理機能を実行します。内部IESG Webページの維持。IESGに代わってIETFアナウンスリストにその他のメッセージを送信し、該当する場合にWebサイトに投稿します（たとえば、IESGおよびIESGの応答に対する控訴に対するアピール）。必要に応じて（つまり、発表の送信、Webサイトのホスティング/更新、電話会議の手配）にサポートを提供します。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サイトをホストし、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) 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事務局に直面している重要な目標と課題の1つです。この重要な機能を実行する際にIETFを支援するために協力することは、ほぼ15年間のCNRIのサポートにおける動機付けの要因でした。ITF内で提起されている多くのさまざまな問題に関心のある人々を可能にする、インターネットコミュニティ全体に代わって彼らの努力において、CNRIと（最近では）補助的なForetecがそれに続く（最近では）補助的なForetecがそれに続く基準に従います。インターネット標準で重要な作業を実行するには、そのような努力に関連する日常的な管理タスクに負担をかけられません。これは長年にわたって成功した活動だったと思いますが、改善の余地は常にあります。また、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?
* 実行するために実行されます...）。* IETF（IESGまたはその他）が *費用対効果を考慮しないことを要求することをいくつかしていますか？
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.
昨年ForetecでのIETF関連活動の総予算は約250万ドルでした。膨大なバルクは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
付録E. ICANNとの相談：IANAプロトコルパラメーター割り当て
Responses to Questions from IAB Advisory Committee for the IANA Protocol Parameter Assignment Function
IANAプロトコルパラメーター割り当て関数に関するIABアドバイザリー委員会からの質問への回答
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.
Michelle [cotton、Iana]によると、RFC 2860は、IANAがIETFに提供する機能を説明するMOUとしておそらく十分なままです。そのオフィスは、すぐに効果的に、マネージャー、3人の技術聖職者（4人のフルタイム相当）とコンサルティングベースで半ダースの人々で構成され、IETFとRIRSの機能を実行します。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の期待に関する具体的なガイダンスを必要とします。これは通常、広告の指示やコンサルティングのアドバイスの形で行われます。ただし、改善されたプロセスは役立ちます。たとえば、新しいレジストリが適切である場合に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のIANAリエゾンは、少なくとも2回ドキュメント全体を読むことを余儀なくされます。IESGがドキュメントを最初に引き渡したときに1回、IANAへの指示が明確であることを確認し、IESGが再び渡されたときにドラフトが作成できるリクエストを実行できるように、文書化します。これは明らかに時間がかかり、エラーが発生しやすいです。
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定義には、データ交換用の1つ、NCP自体に1つは2つのPIDの割り当てが必要になる場合があります。これらの2つの数字は、0001..00ff、0101..7fff、8001..bfff、およびc001..ffffの4つの非常に個別の範囲から来ています。データ割り当てには、指定されたプロトコルを使用したメッセージの相対的な頻度に暗示されており、制御関数PIDが分割されているため、特にバイト指向の非同期伝送を使用した低速線では範囲の選択が重要です。そのような場合、IANAは「2つのPIDが必要」ではなく、「2つのPPP PIDが必要であることを知る必要があります。、および<c-name $ gt;という名前のコントロールPID;範囲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の考慮事項セクションで、「Fubarコードポイント」という名前のレジストリをビルドする必要があると仕様が記載されている場合、テーブル<Name>および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がそれらを容易に回収する可能性があり、ドラフトが後で来るとコメントを見つけることができるシステムに表示されます。本当に役立つには、少なくとも最後の電話のIETF解説と、ドキュメントの合意された変更を含む広告の解説も含める必要があります。これにより、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日にこの機能に割り当てられたスタッフには、ミシェルコットンとアシスタントが含まれています。彼らは本質的にコンピューターバックオフィスアプリケーションに精通している知的な事務スタッフですが、それ以外の場合は特別な技術トレーニングはありません。技術的な質問については、IANA内のアドバイザーに大きく依存しているか、IETFによって割り当てられています。
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.
Paulは、IETF IANA機能の一部を含め、IANAの作業のさまざまな側面に役立つはずのWebベースの自動化を定義しています。ミシェルは、この自動化が彼女の適時性に実質的に役立つと考えています。しかし、それを適切に実行するためには、既存のレジストリごとに明確なビジネスガイドラインに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のリーダーシップは友好的で一般的に建設的であると感じています。彼女は広告ワークロードを非常に認識しているため、質問に焦点を合わせて、他の人に尋ねる人を見つけようとしています。そのため、彼女はコミュニケーションレベルとボリュームが「右について」の軽い側にあると認識しています。
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ポリシーの増幅された明確性は彼女の疑問の負荷を減らし、IESGのIANAなどの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のTigerチームがレジストリをレビューして提案をすることが役立つかもしれません。
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エディターに「問題はない」公開をアドバイスすることを個々の提出物に関連しているようです。
* (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の成長、実行される特定の機能の数の増加 *を実行する、...）。IETF（IESGまたは *それ以外）が費用対効果を考慮しないことを要求することをいくつかしていますか？ *もしそうなら、それらは何ですか？
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
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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。