RFC3716 日本語訳
3716 The IETF in the Large: Administration and Execution. IAB AdvisoryCommittee. March 2004. (Format: TXT=91326 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group IAB Advisory Committee Request for Comments: 3716 IETF Category: Informational March 2004
コメントを求めるワーキンググループIAB諮問委員会要求をネットワークでつないでください: 3716年のIETFカテゴリ: 情報の2004年3月
The IETF in the Large: Administration and Execution
大きさのIETF: 政権と実行
Status of this Memo
この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.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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 Advisory Committee(AdvComm)を形成した、IETF運営機構と関係、(RFC Editor、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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 AdvComm仕事の過程と出力の概観。 . . . 3 1.2. 範囲。 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. 次に、.4 2は踏まれます。 観測. . . . . . . . . . . . . . . . . . . . . . . . 4 2.1。 現在のIETFは構造. . . . . . . . . . . . 4 2.1.1を支持します。 何、このDocument. 4 2.1.2におけるTerm IETF Includes 機能。 . . . . . . . . . . . . . . . . . . 4 2.1.3. サポート。 . . . . . . . . . . . . . . . . . . . 6 2.2. 圧力ポイント. . . . . . . . . . . . . . . . 8 2.2.1を観測しました。 圧力ポイントはIETFリーダーシップで見ました。 . . 8 2.2.2. 圧力ポイントはIETFを支持する組織で見ました。 . . . . . . . . . . . . . 10 2.3. 最終的なObservation。 . . . . . . . . . . . . . . . . . 10 3. 未来に面しながら、立ってください: うまくいっているIETF政権のための要件。 . . . . . . . . . . . . . . . . . . . . 10 3.1. 資源管理。 . . . . . . . . . . . . . . . . . 10 3.1.1. 一定の予算の責任. . . . . . . 10
IAB Advisory Committee Informational [Page 1] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[1ページ]のRFC3716IETF: 2004年の政権と実行行進
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
3.1.2. 財源の等価性. . . . . . . . . . 11 3.1.3。 組織を支持するとの関係における明快。 . . . . . . . . . . . . . . . . 11 3.1.4. 柔軟性の使用中の食糧を供給すること。 . . . . . 11 3.1.5. 管理効率。 . . . . . . . . . . 11 3.2. スチュワードの職。 . . . . . . . . . . . . . . . . . . . . . 12 3.2.1. 変化のための責任。 . . . . . . . . . . 12 3.2.2. 記録. . . 12 3.3の固執とアクセシビリティ。 環境を扱います。 . . . . . . . . . . . . . . . . . 12 3.3.1. オートメーション. . . . . . . . . . . . . . 12 3.3.2を修理してください。 ツール。 . . . . . . . . . . . . . . . . . . . . 13 4. 諮問委員会アドバイス. . . . . . . . . . . . . . . . . 13 4.1。 提案される: (単一)です。 IETFの組織的な実体. . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.1を正式にしました。 このFormalizationのNecessityのコメント。 . . . . . . . . . . . . . . . . 14 4.2. 可能な構造。 . . . . . . . . . . . . . . . . . 14 4.2.1. ISOC. . . . . . . . . . . . . . . . . . . . . 15 4.2.2。 ISOC子会社。 . . . . . . . . . . . . . . . 15 4.2.3. 完全に自治の組織的な実体。 . 16 4.3. .175について決めることができます。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . 17 6. 承認. . . . . . . . . . . . . . . . . . . . . . 17 7。 現在のIETFからの有益なReferences. . . . . . . . . . . . . . . . . . . 18A.IAB Advisory Committee憲章. . . . . . . . . . . . . . . 19B.InputとISIとIAB Chairs. . . . . . . . . 20C.Consultation: Foretec/CNRIとのRFCエディタ.21D.相談: ICANNとの事務局とミーティング計画. . . . . . . . . . . . . . . . . . . . . . . . . . 32E.相談: IANAプロトコルパラメタ課題. . . . . . . . . . . . . . . . . . . . . . . . . 35作者のアドレスの.39の完全な著作権宣言文. . . . . . . . . . . . . . . . . . 40
1. Introduction
1. 序論
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 Advisory Committee(AdvComm)を形成した、IETF運営機構と関係、(RFC Editor、IETF事務局、IANA)、提案するのはIETFの総合的な機能を改良するためにIETF管理過程か構造に変化します。 この目的はAdvCommが標準化過程自体を含まなかったのを強制するAppendix A.にコピーされたIAB Advisory Committee(AdvComm)特許で定義されました。
IAB Advisory Committee Informational [Page 2] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[2ページ]のRFC3716IETF: 2004年の政権と実行行進
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の幹部社員構造への1セットの観測と推薦です--IETFは、事実上、効率的に管理活動を行うことができるように、組織的でどう構造化されるかもしれないか(re)。 それへの必要な序文として、最新号と将来の要件の記述は提示されます。 出力はどんな意志決定や実現も表しません--フォローオンステップの議論に関してセクション1.3を見てください。
1.1. Overview of the AdvComm Work Process and Output
1.1. AdvComm仕事の過程と出力の概観
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は次の2カ月の過程にわたって2003年9月に形成されて、仕事を行いました、2003年11月のIETF58の前で。
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段階は、それらの関係に関して暗黙知のボディーを共有して、議論するのを含んでいました。 これは、Appendix Bに現在のIETFとIAB Chairsからの入力を含んで、セクション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 Editor、事務局、およびIANA)のもう一方の端からの入力を求めました。 それらの努力の出力はAppendix C、Appendix D、およびAppendix 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。
1.2. Scope
1.2. 範囲
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 PROBLEMワーキンググループとIESG提案で行われる仕事を覚えておくのは重要でした、委員会が、それらの努力の範囲を侵害しないよう努力したときさえ。 目的は適切であると考えられる今日のIETFとどんな短期間evolutionsにおいても、これらの観測と提案が関連しているべきであるということです。
IAB Advisory Committee Informational [Page 3] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[3ページ]のRFC3716IETF: 2004年の政権と実行行進
1.3. Next Steps
1.3. 次のステップ
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 Chairsによって進められる動作のための明確な提案を含んでいます。
2. Observations
2. 観測
2.1. Current IETF Support Structure
2.1. 現在のIETFサポート構造
2.1.1. What the Term IETF Includes in this Document
2.1.1. 何、このDocumentのTerm IETF Includes
RFC 3233 ([1]) provides a definition of the IETF, in terms of its work and its participation.
RFC3233([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.
このドキュメントはRFC3233で説明された努力を支持するために一緒に働いている組織の収集について議論します。 本書では、"IETF"という用語は明らかにIESG、WGs、IAB、IRTF、およびRGsを含んでいます。 この包括的な感覚は"IETF"という用語のかなりの一般的な語法と一致します。 正式に、IABとIRTFはIETFの如何にかかわらずチャーターされます。 しかしながら、「IETFとそのすべての友人」を取り囲むために新学期を思いつくよりむしろ、一般的な用法はここに従われています。
2.1.2. Functions
2.1.2. 機能
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の仕事は特定の関数群によって支持されます。 それらのサービスを提供する機能と組織を見分けるのは役に立ちます、以下のテーブルに概説されているように。 いくつかの場合、単純組織は複数のサービスを提供しますが、機能は論理的に異なっています。
IAB Advisory Committee Informational [Page 4] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[4ページ]のRFC3716IETF: 2004年の政権と実行行進
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
組織(IETFの中の)として知られている機能--------- ---------------- ------------ Foretec/CNRI WG Support事務局Foretec/CNRI Community Support事務局Foretec/CNRI IETF Meetings事務局Foretec/CNRI RFC Publication RFC Editor USC/ISI Standards Status Record RFC Editor USC/ISI ParameterレッジIESG Support事務局Foretec/CNRI IAB Support ISOC/事務局ISOC、IANA ICANN Legal、保険など (主に目に見えません)です。 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ドキュメント追跡Working文書管理(メーリングリスト、ウェブサイト、倉庫)
IAB support
IABサポート
Telechats
Communications
Working document management (mailing list, website, repository)
Telechats Communications Working文書管理(メーリングリスト、ウェブサイト、倉庫)
WG support
WGサポート
Charters
Milestone tracking
Workspace (website, mailing list)
Working document archive (mailing list archives, document
repository)
チャーターズMilestone追跡Workspace(ウェブサイト、メーリングリスト)の働くドキュメントアーカイブ(メーリングリストアーカイブ、文書収納庫)
Community Support
共同体サポート
Website
IETF mailing list
Announcements
I-D repository
ウェブサイトIETFメーリングリストAnnouncements I-D倉庫
IAB Advisory Committee Informational [Page 5] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[5ページ]のRFC3716IETF: 2004年の政権と実行行進
RFC Publication
RFC公表
Website
RFC editorial
Document publication
RFC repository management
Official standards status record
編集のウェブサイトの倉庫管理Official規格状態RFC Document公表RFC記録
IETF Meetings
IETFミーティング
Planning
Meeting Proceedings
企画ミーティング議事
Protocol parameter registration
プロトコルパラメタ登録
Creation of registries
Assignment of protocol parameters
Management of accessible registry repository
アクセスしやすい登録倉庫のプロトコルパラメタManagementの登録Assignmentの創造
Legal, insurance, etc.
法的である、保険など
Legal support
Liability insurance for IAB, IESG, WG chairs, etc.
Miscellaneous
IAB、IESG、WGいすなどのための法的なサポートLiability保険 その他
2.1.3. Support
2.1.3. サポート
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
Foretec/CNRI: National Research Initiatives(CNRI)のための社は1986年に設立されました、そして、1987年以来、事務局サービスをIETFに供給することによって、CNRIは共同体に役立っています。 CNRIは1990年代前半までIETFとIETF事務局に対する法的な支援を提供しました。 設立された後に、ISOCはIETFいすの努力を含むIETFの実質的な作業のために総合的な法的義務を仮定しました、IESG、IAB、領域
IAB Advisory Committee Informational [Page 6] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[6ページ]のRFC3716IETF: 2004年の政権と実行行進
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.
ディレクターとワーキンググループいす。 CNRIはIETF事務局の実質的な作業への操作上の責任を負いました。 1998年に事務局が活動のときに間接費を減少させるCNRIにIETF専務を含む再編成された置く事務局の従業員であった、-、利益子会社(Foretec Seminars Inc.)。 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 Editor、およびUSC/ISIの役割はRFC2555で詳細です。 RFCドキュメントシリーズは1セットのインターネット(元々のアルパネット)に関する技術的で組織的な注です、1969年から。 30年間、RFC EditorはUSC情報Sciences Institute(ISI)のNetworking事業部のジョン・ポステルと、研究専門の科学者とマネージャでした、機能が徐々に彼によって率いられたチームに発展していて。 RFC Editor活動は、ISIインフラストラクチャを使用して、現在プロジェクトとしてISIの中で組織化されて、ISOCとの契約で後押しされています。 RFC Editorは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 Support IAB Support(働く文書管理)WG Support Community Support 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公表Maintenance
IAB Advisory Committee Informational [Page 7] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[7ページ]のRFC3716IETF: 2004年の政権と実行行進
IANA/ICANN
IANA/ICANN
[Relationship defined by Memorandum of Understanding: RFC 2860]
[RFC2860年のUnderstanding:Memorandumによって定義された関係]
Protocol parameter registry
プロトコルパラメタ登録
ISOC
ISOC
IAB Support (Telechats)
Funds RFC Editor
Misc IAB/IESG expenses
Provides insurance for IAB, IESG, WG chairs, etc.
IAB Support(Telechats)はIAB、IESG、WGいすなどのためにRFC Editor Misc IAB/IESG費用Provides保険に資金を供給します。
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 Volunteers/のための規格ICANNのためのForetec ISOCメンバーの貢献によるミーティング料金、彼らの雇い主(適切であるところ):
IETF participants
WG chairs
Document editors
IETF NomCom
IESG
IAB
IAB ExecDir
IETF関係者WGはDocumentエディタIETF NomCom IESG IAB IAB ExecDirをまとめます。
2.2. Observed Stress Points
2.2. 観測された圧力ポイント
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リーダーシップの観点から注意されました。
2.2.1. Stress Points Observed by IETF Leadership
2.2.1. 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操作の要件がIETF56[2])一定であるか増加していたままで残りさえするので、IETFいすプレゼンテーションでは、詳しく述べられます。
IAB Advisory Committee Informational [Page 8] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[8ページ]のRFC3716IETF: 2004年の政権と実行行進
The result has been a budget deficit for operations which began in 2002, and is forecasted to continue until at least 2004, even after a substantial increase in meeting fees. The continuing deficits have depleted working capital, making the IETF less robust against potential future budgetary disappointments.
結果は、2002年に始まった操作のための財政赤字であり、少なくとも2004年まで続くように予測されました、ミーティング料金のかなりの増加の後にさえ。 IETFを潜在的将来の予算の当て外れに対して、より強健でなくして、継続する赤字は運転資金を使い果たしました。
The financial stress is real, but the IETF leadership has noted several other stressors that are impediments to finding and implementing solutions to the fiscal issues. Some obvious solutions are not implementable in the current IETF structure.
財政的な圧力は本当ですが、IETFリーダーシップは財政の問題のソリューションを見つけて、実現する障害である他のいくつかのストレス要因に注意しました。 いくつかの明らかな解決法は現在のIETF構造で実行可能ではありません。
The rest of the stressors listed in this section should be understood as issues for which relief is necessary, particularly in the light of needing to properly address and implement solutions to the financial stress.
このセクションで記載されたストレス要因の残りは救援が必要である問題として理解されるべきです、特に適切に財政的な圧力のソリューションを記述して、実現するのが必要であることの見地から。
The current documentation of IETF processes and structure is, in places, vague about the distribution of responsibility for management and oversight of the IETF administrative relationships. This makes it opaque to the IETF community, and sometimes leaves the leadership in a poor position to manage effectively.
場所では、IETFの過程と構造の現在のドキュメンテーションが管理への責任の分配とIETFの管理関係の見落としに関してあいまいです。 これは、それをIETF共同体に不透明にして、有効に管理する貧しい立場で時々リーダーシップを出ます。
Additionally, the informality of the relationships with some of the organizations that are carrying out key IETF functions compounds the problem of determining who has responsibility, and how IETF community consensus and desires are reflected in the activity.
さらに、主要なIETF機能を行っている組織のいくつかとの関係の非公式はだれに責任があるか、そして、IETF共同体コンセンサスと願望がどのように活動に反映されるかを決定するという問題を悪化させます。
As a separate issue, important IETF institutional memory is recorded nowhere other than peoples' minds in many cases -- which requires significant transmission of oral history for IETF leadership transition to be effective.
別個問題として、多くの場合、民族の心以外に、重要なIETF制度上のメモリはどこにも記録されません--IETF指導部の交代が有効であるようにオーラルヒストリの重大な感染を必要とするどれ。
Apart from the institutional memory, other important IETF institutional records are spread across various organizations, and searching for the set of relevant documentation (especially when this is necessary long after the recording) can be challenging.
制度上のメモリは別として、他の重要なIETF制度上の記録は様々な組織の向こう側に広げられます、そして、関連ドキュメンテーション(特にこれが録音のずっと後に必要であるときに)のセットを捜し求めるのはやりがいがある場合があります。
Another stressor relates to the need to scale support processes in terms of reducing latency for mechanical processes. That is, a decrease in the amount of manual labor required for the simpler tasks between the organizations, would make more resources available to focus on the special cases. Lack of automation in the basic request services has been known to cause undue delay or failure in processing simple, routine tasks. However, automation also requires resources and significant management in order to make sure it fulfills the community's requirements.
別のストレス要因は機械プロセスのためにレイテンシを減少させることに関してサポートの過程をスケーリングする必要性に関連します。 すなわち、手作業の量の減少が組織の間の、より簡単なタスクに必要であり、より多くのリソースを特別なケースに焦点を合わせるために利用可能にするでしょう。 基本的な要求サービスにおける、オートメーションの不足が簡単な状態で処理における不当な遅延か失敗を引き起こすのが知られています、通常のタスク。 しかしながら、また、オートメーションは、共同体の要件を実現させるのを確実にするためにリソースと重要な管理を必要とします。
IAB Advisory Committee Informational [Page 9] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[9ページ]のRFC3716IETF: 2004年の政権と実行行進
2.2.2. Stress Points Observed by Organizations Supporting the IETF
2.2.2. IETFを支持する組織によって観測された圧力ポイント
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には、サポートのために外部のボディーを当てにしますが、それがどんなサービスを望むかに関するその要件か指示に関して入力を提供するのを許容する十分明確な外部の関係がないということです。
2.3. A Final Observation
2.3. 最終的な観測
This section attempts to capture a snapshot of the current state of the IETF organization, without undue fixation on the causes for arriving at the current state. However, it seems clear from the observations that the current state does not provide an adequate structure from which to reach into the future: some changes are needed within the IETF administrative and executive structure.
このセクションは、IETF組織の現状のスナップを得るのを試みます、現状に到着する原因に対する過度の執着なしで。 しかしながら、現状が未来まで届く適切な構造を提供しないのは観測によって明確に見えます: いくつかの変化がIETF管理と幹部社員構造の中で必要です。
3. Stand Facing the Future: Requirements for a Successful IETF
Administration
3. 未来に面しながら、立ってください: うまくいっているIETF政権のための要件
This section follows the set of observations with a set of requirements for a properly-functioning IETF administrative structure. These requirements are offered as the AdvComm's description of what the IETF needs, without addressing immediately the degree to which they are available with the current environment. That is, these are "requirements", not "requirements for change".
このセクションは適切に機能しているIETF運営機構のための1セットの要件で観測のセットに続きます。 IETFが必要とするものに関するAdvCommの記述としてこれらの要件を提供します、すぐにそれらが現在の環境で利用可能である程度を記述しないで。 すなわち、これらは「変化のための要件」ではなく「要件」です。
3.1. Resource Management
3.1. 資源管理
3.1.1. Uniform Budgetary Responsibility
3.1.1. 一定の予算の責任
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リーダーシップであると信じています。
IAB Advisory Committee Informational [Page 10] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[10ページ]のRFC3716IETF: 2004年の政権と実行行進
3.1.2. Revenue Source Equivalence
3.1.2. 財源の等価性
The IETF is currently supported by money from multiple sources, including meeting fees, donations from interested corporate and non- corporate entities, and donations in kind of equipment or manpower. The IETF needs to be able to consider all sources of income, and all expenses involved in running the IETF, as pieces of one budget, to be free to adjust all items on the occasions when the income from the different sources varies, and to allocate funds as reasonably required.
IETFは現在複数のソースからお金で支持されます、関心がある法人の、そして、非法人の実体、および本質的な設備か労働力の寄付からミーティング料金、寄付を含んでいて。 IETFは、収入、およびさまざまな原因からの収入が異なる時のすべての項目を調整して、合理的に必要であるとして資金を充当するのにおいて自由になるように1つの予算の断片としてIETFを走らせるのに伴われる経費全部のすべての源を考えることができる必要があります。
The usual caveats apply: that donations not threaten the independence of the IETF, and that donations are easier when they are tax deductible.
いつもの警告は適用されます: 寄付はIETFからの独立を脅かしません、そして、それらが控除可能な税金であるときに、寄付は、より簡単です。
3.1.3. Clarity in Relationship with Supporting Organizations
3.1.3. 組織を支持するとの関係における明快
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サービスなどを含んでいて
3.1.4. Flexibility in Service Provisioning
3.1.4. 柔軟性の使用中の食糧を供給すること
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は追加サービスについて適宜金を工面して、開発に資金を供給することができる必要があります。 これは関係者のためのツール、倉庫管理などの開発を含んでいます。
3.1.5. Administrative Efficiency
3.1.5. 管理効率
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の需要はオーバーヘッドの最小限で満たされるべきです。 これは、適切であるところで仕事の努力を結合して、一般に、努力の重複を避ける可能性があるのが必要であることを含意します。
IAB Advisory Committee Informational [Page 11] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[11ページ]のRFC3716IETF: 2004年の政権と実行行進
3.2. Stewardship
3.2. スチュワードの職
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仕事のためのスチュワードの職を含んでいます。
3.2.1. Accountability for Change
3.2.1. 変化のための責任
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組織体制の中で責任がある個人と共に座る必要があるということです。
3.2.2. Persistence and Accessibility of Records
3.2.2. 記録の固執とアクセシビリティ
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労働者のために。
3.3. Working Environment
3.3. 作業環境
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を管理する仕事の一部が、進行中の活動を支持するのに必要なツールと作業環境の継続的なサポートを特定して、確実にしています。
3.3.1. Service Automation
3.3.1. サービスオートメーション
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.
人間の判断は操作を完了するのにどこで必要でなくても、サービスが、操作を完了する最も多くの摩擦の自由な経路と最小量の遅れを提供するために自動化されているべきです。
IAB Advisory Committee Informational [Page 12] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[12ページ]のRFC3716IETF: 2004年の政権と実行行進
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.
これが、すべての過程が自動化されているべきであるのを含意することを意図しないことに注意してください! むしろ、本当に、機械的なステップで被られた摩擦を減少させることによって、より多くの時間とエネルギーは適切に個々の判断を必要とするものを扱うために空くでしょう。
3.3.2. Tools
3.3.2. ツール
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によって支持された位置に収容するか、または個人拠出で提供することにかかわらず、PROBLEM WGはワーキンググループにおける、より多くのツールサポートと仕様開発の必要性を特定しました。 IETFは標準化作業を完了させるための適切に豊かで、一貫したセットのツールを特定して、開発して、支えることができる必要があります。
4. Advisory Committee Advice
4. 諮問委員会アドバイス
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.
Advisory Committeeは本書では、そして、長々と説明された材料と観測について議論しました。 AdvCommにおいて、何らかのレベルのIETF管理組織変動がストレス要因を記述して、セクション3に概説された要件のすべてに会うのが必要であるように明確に見えました。
4.1. Proposed: (Single) Formalized IETF Organizational Entity
4.1. 提案される: (単一)です。 正式にされた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は直接、財源(収入と費用)を管理するのに責任があるでしょう。
IAB Advisory Committee Informational [Page 13] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[13ページ]のRFC3716IETF: 2004年の政権と実行行進
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 それにもかかわらず、非目標のままで、単に存続する目的のために存在する組織的な実体を作成するのは残っています。 最小の堅苦しさが必要である状態でこれは、特定された要件を記述するために実行されるべきです。
4.1.1. Comments on the Necessity of this Formalization
4.1.1. このFormalizationのNecessityのコメント
An important question is: what does this proposed formalization provide that cannot be provided by the status quo? The AdvComm believes that an appropriately implemented formalization of the IETF would permit the unification of the resource management, decision making and stewardship that is imperative to providing clarity and ensuring a viable future for the IETF. The AdvComm further believes that this is simply not possible to implement within the existing distributed and informal arrangement of responsibilities.
重要な質問は以下の通りです。 現状で、提案された形式化がそれを提供するこれを何に提供できませんか? AdvCommは、IETFの適切に実行された形式化がIETFのために明快を提供して、実行可能な未来を確実にするのに必須の資源管理、意志決定、およびスチュワードの職の統一を可能にすると信じています。 AdvCommは、これが責任の既存の分配されて非公式のアレンジメントの中で実行するのにおいて絶対に可能でないとさらに信じています。
Naturally, the act of forming such an organization does not immediately satisfy the requirements outlined in Section 3. It is not a silver bullet. Changing the formal structure will not, for example, change the financial status of the IETF. However, the AdvComm believes it would provide the necessary basis from which the required decisions could be made and acted upon.
当然、そのような組織を形成する行為はすぐに、セクション3に概説された要件を満たしません。 それは特効薬ではありません。 ホルマール構造を変える場合、例えば、IETFの財政状態は変化しないでしょう。 しかしながら、AdvCommは、必要な決定をして、実行できた必要な基礎を提供すると信じています。
In short, the AdvComm believes that we first have to place the responsibility for defining the IETF's administrative environment with specific people who are accountable to the IETF community. Then these people can take the detailed decisions that will change the IETF's administrative environment to fulfill its requirements.
要するに、AdvCommは、私たちが最初にIETF共同体に責任がある特定の人々と共にIETFの管理環境を定義することへの責任を置かなければならないと信じています。 そして、これらの人々は要件を実現させるためにIETFの管理環境を変える詳細な決定を取ることができます。
4.2. Possible Structures
4.2. 可能な構造
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で広げられた要件を記述するだろうかに関するどんな実現の主要なコンポーネントにも焦点を合わせて。
IAB Advisory Committee Informational [Page 14] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[14ページ]のRFC3716IETF: 2004年の政権と実行行進
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.
それの3つの潜在的実現が以下で説明されるので、その結果、IETFのその形式化を決定したのは必要なステップ、基本的な枠組みと考えられます。 これらが完全な提案でないことに注意してください、そして、推薦するために利用可能な十分な詳細は特定の経路ではありません。 IETFリーダーシップは、詳細によりすばらしい探検して、行動するという決定をすることができるくらいの詳細で動作提案を定式化するために1つを選択するかもしれません。
4.2.1. ISOC
4.2.1. ISOC
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人員の奉納を予期して、ISOCをIETFの財源と費用のすべてに責任があるようにするでしょう。
This approach should be relatively straightforward to implement, given ISOC's existing legal relationship with the IETF activity, and its status as signatory for IETF-related contracts (e.g., RFC Editor).
このアプローチは実行するために比較的簡単であるべきです、IETF活動とのISOCの既存の法的な関係、およびそのIETF関連の契約において、同じくらい署名している状態(例えば、RFC Editor)を考えて。
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の標準化活動より広いです、そして、TrusteesのISOC Boardはそのより広い任務に会うためにリソースを分配するのに集中しているままでなければなりません。 このアプローチはセクション3で求められる責任の明確な線を許容するでしょうか?
4.2.2. ISOC Subsidiary
4.2.2. ISOC子会社
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の中央のボディーを収容する提案の変更はISOCの法的な非営利的子会社を創設することです、明確にIETFの任務に焦点を合わせられる命令で。 この子会社は、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親は法人の創造で詳しく説明されるでしょう。
IAB Advisory Committee Informational [Page 15] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[15ページ]のRFC3716IETF: 2004年の政権と実行行進
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から何らかの管理負担を取り外すのが望ましいなら、そのような子会社にはそれ自身のTrusteesのBoardがあるかもしれません、IETFとISOCによって任命されたメンバーを落ち着かせます。 そのようなBoardは活動、組織の努力が任務に沿って、適切に、経済が整然としていたということであったのを確実にして、などを見直すのに責任があるでしょう。 子会社はTrusteesのBoardに報告するでしょう。 確かに、他の支配モデルは可能です、そして、TrusteesのBoardはこのアプローチのための要件ではありません。
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活動に加えることへの保守的なアプローチ)を支持するでしょう、関係は、IETFがそのより広い任務を達成する際にISOCを支持するようにチャンネルを提供し続けているでしょうが、技術的専門知識の継続的な貢献と活動のサポートで。
This approach would require more work to create than simply housing the work at ISOC. The subsidiary would have to be created and rights/responsibilities adjusted between it and ISOC in order to ensure that both have the necessary resources and frameworks to carry out their missions.
このアプローチは単に仕事をISOCに収容するより作成する仕事を必要とするでしょう。 子会社は創設されなければならなかったでしょう、そして、権利/責任は、彼らの任務を行うために両方には必要なリソースと枠組みがあるのを確実にするためにそれとISOCの間で適応しました。
4.2.3. Completely Autonomous Organizational Entity
4.2.3. 完全に自治の組織的な実体
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の管理活動を管理する唯一の目的のために、「IETF Inc.」、または「IETF、LLC」という完全に新しい法人を作成できました。
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
例えば、IETFがわずかな最初のミーティングのために委任を扱うことができるくらいの初期の運転資金を得るのが必要でしょう。 前売りのミーティング料金から運転資金を上げるのが想像できるだろうという間、そのような資金調達計画はあまりいなくならないでしょう。
IAB Advisory Committee Informational [Page 16] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[16ページ]のRFC3716IETF: 2004年の政権と実行行進
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の生存をさらされることができるでしょうに。 経済環境を考えて、企業献金から運転資金を純粋に上げることができたとたぶん思うべきではありません、特に寄付に請求して、管理しなければならなかったスタッフが手があいていない原初期の間。
Additionally, the impact that such a move would have on ISOC's ability to carry out its mission and the IETF's standing with governmental organizations needs to be considered.
さらに、そのような移動が政府機関がある任務とIETFの地位を行うISOCの性能に持っている影響力は、考えられる必要があります。
4.3. Who Can Decide
4.3. だれが決めることができますか。
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を正式にするという推薦に影響する責任があると信じています。
5. Security Considerations
5. セキュリティ問題
This document does not describe any technical protocols and has no implications for network security.
このドキュメントは、どんな技術的なプロトコルについても説明しないで、またネットワークセキュリティのための意味を全く持っていません。
6. Acknowledgements
6. 承認
The AdvComm sincerely appreciates the time, effort and care of the RFC Editor, IANA, Secretariat and Secretariat organizations in providing input, responding to the AdvComm's questions, and reviewing/correcting the consultation text shown here in the appendixes.
AdvCommは心からここ、付属物で示された相談テキストをAdvCommの質問に応じて、批評するか、または修正して、入力された提供におけるRFC Editor、IANA、事務局、および事務局組織の時間、努力、および注意に感謝します。
The members of the IAB Advisory Committee that prepared this report were:
このレポートを作成したIAB Advisory Committeeのメンバーは以下の通りでした。
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 バーナードAboba oハラルドAlvestrand(IETF議長)oリン聖Amour(ISOC社長)oフレッド・ベイカー(議長、TrusteesのISOC Board)oブライアンCarpenter oスティーブクロッカーoレスリーDaigle(IAB議長、委員会のいす)oラスHousley oジョンKlensin
IAB Advisory Committee Informational [Page 17] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[17ページ]のRFC3716IETF: 2004年の政権と実行行進
7. Informative References
7. 有益な参照
[1] Hoffman, P. and S. Bradner, "Defining the IETF", BCP 58, RFC
3233, February 2002.
[1] ホフマンとP.とS.ブラドナー、「IETFを定義します」、BCP58、RFC3233、2002年2月。
[2] Alvestrand, H., "IETF Chair plenary presentation, http://
www.ietf.org/proceedings/03mar/slides/plenary-3/index.html",
March 2003.
2003年のH.、「IETFの議長の絶対的なプレゼンテーション、http://の絶対的なwww.ietf.org/議事/03mar/スライド/3/index.html」行進の[2]Alvestrand。
[3] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC
2223, October 1997.
[3] ポステル、J.、およびJ.レイノルズ、「指示、RFCが書く、」、RFC2223、10月1997日
[4] Reynolds, J. and B. Braden, Eds., "Instructions to Request for
Comments (RFC) Authors", Work in Progress.
[4] レイノルズとJ.とB.ブレーデン、Eds、「(RFC)が書くコメントのために要求する指示」は進行中で働いています。
IAB Advisory Committee Informational [Page 18] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[18ページ]のRFC3716IETF: 2004年の政権と実行行進
Appendix A. IAB Advisory Committee Charter
付録A.IAB諮問委員会憲章
Date: Tue, 02 Sep 2003 16:34:58 -0400 From: Leslie Daigle Subject: Formation of IAB Advisory Committee To: IETF-Announce: ;
日付: 火曜日、2003年9月2日の16:34:58 -0400From: レスリーDaigle Subject: IAB諮問委員会To:の構成 IETF発表してください: ;
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 Editor、IETF事務局など)、IETFの総合的な機能を改良するIETF管理の過程か構造変化を提案してください。 そのようなどんな提案も論評するためになることがあって、IABとIETFによる承認は絶対的です。 諮問委員会の範囲が規格開発過程(例えば、WG組織、ドキュメントかワーキンググループのIESG経営など)への変更案を含んでいないことに注意してください。
The committee is chaired by the IAB Chair, Leslie Daigle, and consists of:
委員会は、IAB議長(レスリーDaigle)によってまとめられて、以下から成ります。
o Bernard Aboba
o Harald Alvestrand (IETF Chair)
o Lynn St.Amour (ISOC President)
o Fred Baker (Chair, ISOC Board of Trustees)
o Brian Carpenter
o Steve Crocker
o Leslie Daigle (IAB Chair, chair of the committee)
o Russ Housley
o John Klensin
o バーナードAboba oハラルドAlvestrand(IETF議長)oリン聖Amour(ISOC社長)oフレッド・ベイカー(議長、TrusteesのISOC Board)oブライアンCarpenter oスティーブクロッカーoレスリーDaigle(IAB議長、委員会のいす)oラスHousley oジョンKlensin
Additional input is welcome. The committee will also make a particular effort to seek out further input as needed. --
追加入力を歓迎します。 また、委員会は必要に応じてさらなる入力を捜し出すための特定の努力をするでしょう。 --
IAB Advisory Committee Informational [Page 19] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[19ページ]のRFC3716IETF: 2004年の政権と実行行進
Appendix B. Input from the Current IETF and IAB Chairs
付録B.は現在のIETFとIABからいすを入力しました。
Input contributed by Harald Alvestrand (IETF Chair) and Leslie Daigle (IAB Chair).
ハラルドAlvestrand(IETF議長)とレスリーDaigle(IAB議長)で入力は貢献しました。
Looking at the administrative overview of the IETF activity, there are a number of things that work well:
IETF活動の管理概観を見て、うまくいく多くのものがあります:
o support organizations are committed to the work of the IETF;
o サポート組織はIETFの仕事に心がけます。
o the volunteers of the IETF WGs can (mostly) concentrate on their
engineering work, not economics;
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 Chairsによって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のためにどのように、どこで改良について議論して、作用するかを決定するのが困難になります。
IAB Advisory Committee Informational [Page 20] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[20ページ]のRFC3716IETF: 2004年の政権と実行行進
o unclear budgeting responsibilities -- the IETF leadership has to
make decisions that will impact the revenues and costs of the
supporting organizations, but the supporting organizations wear
the direct effects of revenue and cost control. Information about
the financial impact of decisions are not available to IETF
leadership;
o 不明瞭な予算責任--IETFリーダーシップはサポート組織の収入とコストに影響を与える決定をしなければなりませんが、サポート組織は収入と経費節減の直接効果を着ます。 決定の財政的な影響に関する情報はIETFリーダーシップに利用可能ではありません。
o partitioned finances -- it's not possible for the IETF to make
changes that would affect the balance of revenue and costs across
the revenue sources/expense commitments. For example, raising
meeting fees wouldn't pay for more RFC Editor resources; more
support from ISOC doesn't address any needs for IETF working group
support functions;
o 仕切られた経済--IETFが財源/費用の向こう側の収入の残額に影響する変更とコストを委任にするのは、可能ではありません。 例えば、ミーティング料金を上げるのは、より多くのRFC Editorリソースの代価を払わないでしょう。 ISOCからの、より多くのサポートはIETFワーキンググループ支援機能の少しの必要性も記述しません。
o the lack of clarity and the partitioning make it very hard for the
IETF leadership, and the community as a whole, to determine points
of accountability and implement changes for a healthy future.
o 明快の不足と仕切りの造、それ、IETFリーダーシップ、および全体で共同体に非常に困難です、ポイントの責任と道具を決定するのは健康な未来の間、変化します。
Appendix C. Consultation with ISI: RFC Editor
ISIとの付録C.相談: RFCエディタ
Note: "RFC2223bis" in the text below refers to RFC 2223bis [4], a work in progress to update RFC 2223 [3].
以下に注意してください。 以下のテキストの「RFC2223bis」はRFC 2223bis[4]、RFC2223[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) あなたのあなたが実行している機能の記述。 *RFC 2223bisで説明されて、*は、適切にその機能と、IETFとのその関係です、または追加記述*が必要ですか? 後者であるなら、あなたは何を勧めるでしょうか?
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 Editor機能の包括的な概要は以下に添付されます。 このリストにはRFC作者に指示を含むRFC 2223bisとのどんなダイレクト関係もないことに注意してください。
* * (2) What staff is being used to perform these functions and * what are their particular skills for doing so (either * individually or in the aggregate)? *
* * (2) *どんなスタッフがこれらの機能を実行するのに使用されているか、そして、そうするための彼らの特定の技能(個別か集合の*)は何ですか? *
IAB Advisory Committee Informational [Page 21] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[21ページ]のRFC3716IETF: 2004年の政権と実行行進
ANSWER:
以下に答えてください。
For 30 years, the RFC Editor was Jon Postel, a research scientist and manager in the Networking Division of the USC Information Sciences Institute (ISI). It is currently organized as a project within ISI, using the ISI infrastructure. The following ISI staff members comprise the RFC Editor project:
30年間、RFC EditorはUSC情報Sciences Institute(ISI)のNetworking事業部のジョン・ポステルと、研究専門の科学者とマネージャでした。 ISIインフラストラクチャを使用して、それは現在、プロジェクトとしてISIの中で組織化されます。 以下のISI職員はRFC Editorプロジェクトを包括します:
Joyce Reynolds 100%
Bob Braden 10%
Aaron Falk 10%
Sandy Ginoza 100%
Project Assistant 100%
Graduate Research Asst. 50%
100%の10%の10%の100%の100%のジョイスレイノルズボブブレーデンアーロンフォークサンディー宜野座プロジェクトアシスタント卒業生研究Asst。 50%
Braden and Reynolds jointly manage the RFC Editor project, with oversight of personnel and budgets.
ブレーデンとレイノルズは人員と予算の見落としで共同でRFC Editorプロジェクトを経営します。
Joyce Reynolds has been contributing her editorial and management skills to the Internet since 1979. She performed the IANA functions under Jon Postel's direction from 1983 until Postel's death in October 1998. She continued to perform the IANA protocol parameter tasks on loan from ISI to ICANN, from 1998 to 2001. She was IANA liaison to the IESG from 1998 to 2001, transitioning the role to Michelle Cotton in the 2001.
ジョイス・レイノルズは1979年以来のインターネットに彼女の社説と経営能力を寄付しています。 彼女は1998年10月にジョン・ポステルの指示に基づきIANA機能を1983年からポステルの死まで実行しました。 彼女は、1998年から2001年までISIからICANNまでのローンにIANAプロトコルパラメタタスクを実行し続けていました。 移行して、彼女は1998年から2001年までのIESGへのIANA連絡でした。2001年のミシェルCottonへの役割。
Reynolds performed the RFC Editor functions under Jon Postel's direction from 1987 until 1998. Reynolds has been a member of the IETF since 1988, and she served as User Services Area Director on the IESG for 10 years. Reynolds now serves a liaison to the IAB and IESG. She handles the final proofing and quality control on RFCs prior to publication.
レイノルズはジョン・ポステルの指示に基づきRFC Editor機能を1987年から1998年まで実行しました。 レイノルズは1988年以来のIETFのメンバーです、そして、彼女は10年間IESGの上のUser Services Areaディレクターとして勤めました。 レイノルズは現在、IABとIESGに連絡係に勤めます。 彼女は公表の前にRFCsで最終的な証と品質管理を扱います。
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年以来、ブレーデンはRFC Editorプロジェクトの共同リーダーです。 彼は個々の差出の主要な評論家です。 また、彼はRFC Editorプロジェクトに関連する専門的な問題に取り組みます。
Aaron Falk is a significant player in the IETF as a Working Group chair, in the areas of transport protocols and satellite technology. On the RFC Editor team, he assists with policy questions and handles technical development, overseeing the work of the grad student programmer.
アーロン・フォークは作業部会いすとしてのIETF、トランスポート・プロトコルと人工衛星の科学技術の領域の重要なプレーヤーです。 RFC Editorチームでは、彼は、方針質問を助けて、技術的な開発を扱います、大学院生のプログラマの仕事を監督して。
IAB Advisory Committee Informational [Page 22] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[22ページ]のRFC3716IETF: 2004年の政権と実行行進
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.
砂地の宜野座は主要な技術分野担当の編集者です。 一般に、彼女はIESGと作者との今日の日のインタフェースのRFC Editor待ち行列と多くを管理するのに責任があります。 宜野座は、メールのLOTを送って、受けます、そして、彼女は操作で中心的役割を果たします。
Two part-time Project Assistants, Mieke Van de Kamp and Alison De La Cruz, do editing, mark-up, and initial proofing of individual RFCs. Our goal is to have three pairs of eyes read every RFC word-for-word, and in most instances we are able to do so.
2パートタイムのProject Assistants、Miekeヴァン・deカンプとアリソン・デ・ラ・クルスは個々のRFCsの編集、値上げ、および初期の証をします。 私たちの目標があらゆるRFCが読まれた3組の目を遂語的にすることであり、たいていの場合私たちはそうすることができます。
A half-time USC Graduate Research Assistant provides programming support by developing, extending, and maintaining RFC Editor scripts and tools.
USC Graduate Research AssistantがRFC Editorスクリプトを開発して、広げていて、維持するのによるサポートとツールをプログラムしながら提供するハーフタイム。
* (3) What criteria do you use to determine whether you are being * successful, and how successful? Using those criteria, how * successful are you and what could be done, especially from the * IETF side, to improve that evaluation?
* (3) あなたは、あなたが*うまくいって、どれくらいうまくいっているかどうか決定するのにどんな評価基準を使用しますか? それらの評価基準を使用して、あなたとその評価を改良するために特に*IETF側からできたことは*どれくらいうまくいっていますか?
ANSWER:
以下に答えてください。
We can begin with a historical perspective on this question. When Jon Postel unexpectedly passed away 5 years ago, Reynolds and Braden took on the challenge of carrying on Postel's RFC Editor function. The publication stream continued, with a modest increase in quantity and, we believe, no loss of quality. Furthermore, the transition was largely invisible to the IETF. In addition, the new RFC Editor project has significantly defined and clarified the publication process, improved the web site, added tools to improve productivity and quality, and adapted the procedures to changing realities. We are proud of these achievements.
私たちはこの質問に関する歴史観で始めることができます。 ジョン・ポステルが続ける挑戦のときに5年前に不意に亡くなったとき、レイノルズとブレーデンはポステルのRFC Editor機能を取りました。 公表ストリームが穏やかな増加で量に続いて、私たちが信じている、いいえ。品質の損失。 その上、変遷はIETFに主に目に見えませんでした。 さらに、新しいRFC Editorプロジェクトは、公表の過程をかなり定義して、はっきりさせて、ウェブサイトを改良して、生産性と品質を改良するツールを加えて、現実を変えるのに手順を適合させました。 私たちはこれらの業績を誇りに思っています。
The three primary axes for measuring RFC Editor success are (1) quantity, (2) quality, and (3) accessibility.
測定RFC Editor成功のための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.
手荒く、量的な成功は服従率について行く能力を意味します。 服従率が、burstyである傾向があるので、長時間の遅延を避けるために、私たちはいくらか平均を超えた平均した容量を必要とします。
RFC publication is necessarily a heavily labor-intensive process.
RFC公表は必ずずっしりと労働集約的な過程です。
IAB Advisory Committee Informational [Page 23] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[23ページ]のRFC3716IETF: 2004年の政権と実行行進
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週間未満後に公表の過程を完了することです、私たちにとって手に負えないほど外部の要素を除いて--他のドキュメントへの標準の依存、作者かIESGによる遅れ、IANA遅れなど
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 Editor機能の重要な部分は関連RFCsの場所を見つけるためのデータベースを提供することです。 これは実際に非常に困難な問題です、特定の話題のRFCsの中に複雑な意味ウェブがしばしばあるので。 私たちはサーチエンジンとウェブサイトでかなりの改良をしましたが、より多くの進歩の必要が確かにこの領域にあります。 挑戦は重要な追加労働力要件を作成しないで、より良い道しるべをユーザに提供することです。
We make heavy use of our own search and access tools, and this
gives us feedback on their success and sometimes suggests
improvements.
私たちが私たち自身の検索とアクセスの重い使用をツールにして、これは、それらの成功のフィードバックを私たちに与えて、時々改良を示します。
Finally, we offer some specific suggestions to answer the question, "What can the IETF do to improve the RFC Editor's evaluation" (i.e., our service to the community)?
最終的に、私たちは、「IETFはRFC Editorの評価を改良するために何ができる」(すなわち、共同体に対する私たちのサービス)と質問に答えるためにいくつかの特定の提案を提供しますか?
IAB Advisory Committee Informational [Page 24] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[24ページ]のRFC3716IETF: 2004年の政権と実行行進
1. Give us better documents to publish. Many are well written and
organized, but some are bad and a few are very bad and need a
great deal of work to create acceptable publications. Better
input documents will improve both our quantity and our quality.
1. 発行するためには、より良いドキュメントをお願いします。 多くが上手に書かれていて、組織化されますが、或るものが悪く、いくつかは、許容できる刊行物を作成するために非常に悪く、大きな仕事を必要とします。 より良い入力ドキュメントは私たちの量と私たちの品質の両方を改良するでしょう。
The IESG has been making a large effort to improve the quality of
Internet Drafts before they become RFCs, and we are very grateful
for this.
IESGは彼らがRFCsになる前にインターネットの品質を改良するための大きい努力をDraftsにしています、そして、私たちはこれに非常に感謝しています。
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冊は非英語を話す人によって書かれたRFCsの増加する数です。 これらは多くの余分な編集の努力を消費できます。 この問題の少しの解決も知りませんが、私たちは、ワーキンググループの中で必要であるときに、編集の支援を提供するために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. 特定の領域でRFCsの意味ウェブについて説明する「道路地図」を含む一連のRFCsを用意してください。 これらは急速に詳細に時代遅れになるでしょうが、彼らはまだ非常に重要なガイドをRFC読者に提供しているでしょう。
The RFC Editor is as self-critical as any organization could be, but we believe there is no objective basis for claiming that we are not doing a good job for the Internet. We continually strive to do a better job.
RFC Editorは自己どんな組織できたのとも同じくらい重要ですが、私たちは、私たちがインターネットのための良い仕事をしていないと主張するための使途別分類が全くないと信じています。 私たちは、絶えずより良い仕事をするように努力します。
* * (4) How would you characterize the quality of your relationship * with the IETF and its leadership? Is there mutual trust and a * sense of working together on issues, or do you and your * colleagues sometimes see the relationship as adversarial? *
* * (4) あなたはどのようにIETFとそのリーダーシップとのあなたの関係*の品質を特徴付けますか? 信頼関係と問題に一緒に取り組むという*感覚がありますか、またはあなたとあなたの*同僚は、時々関係が敵であるとみなしますか? *
ANSWER:
以下に答えてください。
The RFC Editor shares with much of the rest of the Internet community a deep desire to advance the technology and practice of the Internet. We consider ourselves partners with the IETF, the IESG, and the IAB in this endeavor.
RFC Editorは技術を進める深い願望とインターネットの習慣をインターネットコミュニティの残りの多くと共有します。 私たちは、この努力で自分達がIETF、IESG、およびIABのパートナーであると考えます。
Although the major goals coincide, the IESG and the RFC Editor quite properly have somewhat different priorities. The RFC Editor's role, historically and currently, is to create and maintain the RFC document series as a high-quality and vital channel for technical communication, while the IESG is concerned with managing the Internet engineering and standards process. This difference sometimes leads to honest disagreements, but we have generally worked out mutually- satisfactory solutions to these conflicts.
主要な目標は一致しますが、IESGとRFC Editorには、いくらか異なったプライオリティが全く適切にあります。 RFC Editorの役割は、歴史的で現在技術的なコミュニケーションのための高品質でバイタリティにあふれたチャンネルとしてRFCドキュメントシリーズを作成して、維持することです、IESGはインターネット工学と標準化過程を管理するのに関係がありますが。 この違いは時々正直な不一致につながりますが、一般に、私たちはこれらの闘争の互いに満足できる解決策を考え出しました。
IAB Advisory Committee Informational [Page 25] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[25ページ]のRFC3716IETF: 2004年の政権と実行行進
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 Editorは個々の差出を受け入れるとき水準を上げて、貴重な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 Editorの法定的、そして、歴史的な責任の理解とサポートが欲しいと思います。 この公表には、いくつかの重要な目的があります。
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つは考慮と議論のための新しい技術的なアイデアを持ち出すことになっています。 私たちはインターネットの将来的な成功が新しいアイデアの注入を要求して(古い考えは生き返らせました)、RFCsのような考えの公表が重要であると信じています。
Another purpose is to build a shared literature of mature
technical discussion, to help avoid the periodic re-discussions
that take place on our mailing lists.
別の目的は私たちのメーリングリストで行われる周期的な再議論を避けるのを助けるために熟している技術面の協議の共有された文学を造ることです。
Finally, the RFC series provides a historic repository for
important ideas. We have come across a number of examples of
important suggestions and partial technology developments that
have been lost, or hard to locate, because they were not
published as RFCs. The community spends too much of our time
re-inventing many, many wheels.
最終的に、RFCシリーズは歴史的な倉庫を重要な考えに提供します。 私たちは無くなっているか、または場所を見つけにくかった重要な提案と部分的な技術開発に関する多くの例に出くわしました、それらが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
独立している服従刊行物はRFC生産の小さい方の部分だけを表します。 例えば、あまりにカレンダー2003で遠くに、私たちが178RFCsを発行するほど14の独立している差出を含んでいます。 私たちが考えるすべての草稿が、値するなら
IAB Advisory Committee Informational [Page 26] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[26ページ]のRFC3716IETF: 2004年の政権と実行行進
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.
RFCsが発行されることになっていたので保存されて、この断片は成長するでしょうが、私たちは、それが発行されたRFCsの総数の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) 米国-ASCII(UTF-8への.e.g.,)を超えて文字の組を広げることにおける、問題の調査に協力したいと思います。 主要な問題は1セットの準備と、表示と、RFC EditorとRFC消費者の両方のためにツールを捜すのがあるかどうかということです。 これらのツールは、利用可能で十分熟している遍在である必要があります。
The RFC Editor is looking for input on how we can best continue to serve the community. We are grateful for the suggestions we have received, and we have adopted as many of them as feasible; the result has been quite a long list of incremental improvements in our service over the past 5 years.
RFC Editorは私たちがどう共同体に最もよくずっと役立つことができるかに関する入力を探しています。 私たちは受領した提案に感謝しています、そして、可能であるのと同じくらい多くをそれらを採用しました。 結果は過去5年の私たちのサービスオーバーにおける増加の改良に関するかなりの長い一覧表です。
* * (6) How do you see the costs of your function evolving? If * things become more costly over time, what are the main * determiners of cost (e.g., general inflation, general IETF * growth, increase in the number of particular functions you are * carried out to perform,...). Are you doing some things that * IETF (IESG or otherwise) request that you do not consider * cost-effective and, if so, what are they? * *
* * (6) あなたは、あなたの機能のコストがどのように発展しているのを見ますか? *いろいろなことが時間がたつにつれてより高価になるなら、費用の主な*決定者は者(例えば*働くために行われて、インフレーション、一般的なIETF*成長が特定の機能の数で増大させる一般)ですか? あなたはあなたが、*が費用対効果に優れていると考えないで、そうだとすれば、それらが何であるかというその*IETF(IESGの、または、そうでない)要求をいくつかのものにしていますか? * *
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.
これは小さくて予測できる例年の増加を示しています。
IAB Advisory Committee Informational [Page 27] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[27ページ]のRFC3716IETF: 2004年の政権と実行行進
(b) The number of RFCs published.
(b) 発行されたRFCsの数。
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) タスクは直接特定のRFCsに関連しませんでした。
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連絡、ウェブページ、スクリプト、およびツールの独立している差出、開発、および維持のレビュー、RFC Onlineプロジェクト、Errataウェブページを維持することなど。 これらは、現在、私たちの費用に関する私たちの人員回、および37%の30%を必要とするように見積もられています。
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.)
少ない追加費用(しかし悠長なペースのときに)で機能の小さい方の拡大を吸収できます。 私たちはこのとき、少しの主要な機能的な拡大も提案していません。 そのような拡大は別々にcostedされなければならないでしょう。(それらに利用可能なお金でした。)
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.
ディスク格納とウェブサービスは、ISIのサポート組織によって提供されて、オーバーヘッドとして扱われます。 元々研究契約に基づきプロジェクトによって使用されたデスクトップマシンの大部分を買いました、RFC Editor予算は設備アップグレードのための非常に小さい項目を含んでいますが。
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 Editorは記録保管所のシリーズのRFC(元々の「コメントを求める要求」)ドキュメントを編集して、発表します。 RFCsはARPAnetとインターネットの技術的な歴史を記録するコンピュータコミュニケーションとパケット交換網に関するメモの記録保管所のシリーズを形成します、1969年から。 RFC Editorはインターネット協会によって資金を供給されて、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
RFC Editorはインターネットで電子的にRFCシリーズに関するRFCsとマスタインデックスを発表します、すべての一般的なアクセス・プロトコル(現在のウェブ、メール、rsync、およびFTP)で。 それは1つ以上のメーリングリストへの電子メールを通してそれぞれの新しいRFCの存在を発表します。 RFC Editorはさまざまな道具、場所を見つけるリスト、およびアクセスRFCsがある包括的なウェブサイトを維持します。 このウェブサイト
IAB Advisory Committee Informational [Page 28] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[28ページ]のRFC3716IETF: 2004年の政権と実行行進
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編集方針、公表待ち行列状態、誤字、および、よりアクセスしやすくて、RFCシリーズの、より役に立ついかなる他の情報に関しても、一般情報を含んでいます。
During the RFC editing process, the RFC Editor strives for quality, clarity, and consistency of style and format. Editorial guidelines and procedures to achieve these ends are established by the RFC Editor in consultation with the IAB and IESG (Internet Engineering Steering Group). The RFC Editor periodically publishes a revision of these its guidelines to authors.
過程を編集するRFCの間、RFC Editorはスタイルと形式の品質、明快、および一貫性を求めて努力します。 これらの終わりを達成する編集のガイドラインと手順はRFC EditorによってIABとIESG(インターネットEngineering Steering Group)との相談に確立されます。 RFC Editorは定期的にこれらの改正を発行します。作者へのそのガイドライン。
The RFC Editor coordinates closely with the IESG to carry out the Internet standards process as documented in the latest revision of "The Internet Standards Process" and later amendments. The RFC Editor also coordinates closely with the Internet Assigned Numbers Authority (IANA), to ensure that the parameters used in new and revised protocol descriptions are properly registered.
RFC Editorは、「インターネット規格は処理し」て後の修正の最新の改正に記録されるようにインターネット標準化過程を行うためにIESGと共に密接に調整します。 また、RFC Editorは、新しくて改訂されたプロトコル記述に使用されるパラメタが適切に示されるのを保証するために、密接に、インターネットAssigned民数記Authority(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) 公表の過程。 RFC2026(または、差し替え書類)とRFC 2223bisによると、RFC EditorはRFCsを編集して、発行します。 これは以下のタスクを含んでいます:
(a) Performing the final editing of the documents to maintain
consistency of style, editorial standards, and clarity.
(a) スタイル、編集基準、および明快の一貫性を維持するためにドキュメントの最終的な編集を実行します。
At minimum, the RFC Editor:
最小限、RFC Editorで:
(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
RFC 2223bisのセクション3の形式規則を実施します(ii)。
(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)は、参照と引用の一貫性について確かめて、RFCsとI-Dsの参照のコンテンツについて確かめます。
(v) Verifies that all normative dependencies have been
satisfied.
(v)は、すべての標準の依存を満たしてあることを確かめます。
IAB Advisory Committee Informational [Page 29] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[29ページ]のRFC3716IETF: 2004年の政権と実行行進
(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 Considerations)はリスト、およびRequirement-レベル単語を書きます。
(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 EditorはHTTPとFTPを通してアクセスしやすい完全なRFCシリーズの部分集合の圧縮された集合ファイルを提供します。 また、PDFファクシミリはすべての.txt RFCsのために維持されます。
(d) Publicly announcing the availability of new RFCs via a mailing
list.
(d) 公的にメーリングリストで新しいRFCsの有用性を発表すること。
(e) Coordinating with the IANA for assignment of protocol
parameter values for RFCs in the submission queue.
(e) RFCsのためのプロトコルパラメタ値の課題のために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と共に密接に調整して、RFC2026(または、交換)の規則は従われています。 RFC Editor人員はIETFミーティングに出席します。 指定されたRFC Editor人は連絡としてIABとIESGに勤めます。
(2) Individual Submission Publication
(2) 個々の服従公表
The RFC Editor publishes technically competent and useful
documents that arise outside the IETF process, in accordance with
RFC 2026. The RFC Editor makes the final determination on the
publishability of such documents, with review by the IESG and
input from knowledgeable persons.
RFC EditorはRFC2026によると、IETFの過程の外で起こる技術的に有能で役に立つドキュメントを発表します。 RFC Editorはそのようなドキュメントのpublishabilityでレビューで学のある人からの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 Editorは許容できる編集の品質と内容のためにそのようなすべてのドキュメントを再検討して、合格水準に品質を上げるのに必要であるときに、作者と共に働いています。
(3) Online RFC meta-information
(3) オンラインRFCメタ情報
The RFC editor publishes the following status information via the
Web and FTP.
RFCエディタはウェブとFTPで以下の状態情報を発表します。
IAB Advisory Committee Informational [Page 30] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[30ページ]のRFC3716IETF: 2004年の政権と実行行進
(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) 完全な図書目録の情報とドキュメント状態を含んでいて、現在発行されているすべてのRFCsのリスト。 このリストはともに人間の、そして、機械可読な(XML)フォームで発表されます。
(b) A document consisting of summaries of RFCs in each range of
100.
(b) それぞれの100の範囲でRFCsの概要から成るドキュメント。
(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 Editorウェブサイト含有
(i) A search engine for RFCs.
(ii) Information on the RFC publication process.
(iii) Links to the above published items.
(i) RFCsのためのサーチエンジン。 (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 Editorメールボックスの中に受信されたか。
II. Improved Process and Infrastructure
II。 改良された過程とインフラストラクチャ
When resources allow, the RFC Editor makes improvements to its processes and to the RFC repository infrastructure. This includes improvements and extensions to the set of scripts used by the RFC Editor: (i) to maintain its databases and web pages, and (ii) to increase the efficiency and quality of the editing process.
いつ、リソースが許容するか、RFC Editorは過程と、そして、RFC倉庫インフラストラクチャへの改良をします。 これはRFC Editorによって使用されたスクリプトのセットに改良と拡大を含めます: (i) データベースとウェブページを維持してください。そうすれば、編集の効率と品質を増加させる(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に加えてRFCsで使用される形式仕様言語を確かめるための追加ツールを採用すること。
IAB Advisory Committee Informational [Page 31] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[31ページ]のRFC3716IETF: 2004年の政権と実行行進
(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)リンク誤字の誤りからRFCインデックスまでの誤植を区別してください。
(e) Providing Web-based "enhanced" views of RFCs, including:
(e) RFCsのウェブベースの「高められた」意見を提供する含み:
(i) Links to other related RFCs and references.
(ii) Links to and from online errata pages.
(i) 他へのリンクはRFCsと参照について話しました。 (ii) ページと、そして、オンライン誤字ページからのリンク。
(3) Maintaining an online repository of the corrected values of
MIBs that have been published in RFCs.
(3) RFCsで発行されたMIBsの直っている値のオンライン倉庫を維持すること。
(4) Completing the RFC Online project, to bring online those early
RFCs that are available only in paper form.
(4) RFC Onlineプロジェクトを終了して、紙だけでオンラインでそれらの利用可能な前のRFCsを持って来るために、形成してください。
Appendix D. Consultation with Foretec/CNRI: Secretariat and Meeting
Planning
Foretec/CNRIとの付録D.相談: 事務局とミーティング計画
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.
事務局仕事は4つの部品に分割されます: Planning、WGサポート、IESGサポート、およびIETF Communityサポートを満たします。
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のための特許、重大事件、および他の情報を維持して、アップデートします。 追跡はいすで変化します。 接待と議論メーリングリストを格納します。 そして、RFCsとしてIDを発行するという処理要求。
IAB Advisory Committee Informational [Page 32] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[32ページ]のRFC3716IETF: 2004年の政権と実行行進
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電子会議に必要です(すなわち、処理は「最後に呼びます」、議題とパッケージを準備して、電子会議を加減して、議事録を準備して、承認の発表を出して、ID Trackerの情報をアップデートして)。(電子会議は、2週間毎に行われて、それぞれ最大20+ドキュメントをカバーします)。 RFCsへのI-Dsの動きを追跡します。 RFC Editorに連結します。 WG創造に関連している行政機能を実行する、「再-特許」、および閉鎖。 内部のIESGウェブページを維持します。 種々雑多なメッセージをIETF発表に送って、IESGと、それらを掲示することを代表して適切である(例えば、上告へのIESGとIESG応答に求めます)ところにウェブサイトに記載してください。 必要であるように(すなわち、電話会議を準備して、ウェブサイトを接待するか、またはアップデートする発表を送ります)サポートをNomComに供給します。 そして、IESG意志決定を支持する展開しているウェブベースのツール。
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 Communityサポートは: IETFミーティングを走らせます。 IETFウェブサイトを接待して、それがこれまで上げるウェブサイトを保管します。 IETF発表と議論を主催するのは記載します。 調査に応じるのはIETF事務局、事務局長、ミーティングRegistrar、ウェブマスター、および問題チケットシステムに発信しました。 処理Intellectual Property Rights Notices。 処理Liaison Statements。 そして、任命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人の人が行政機能を実行します。 -- 4.5の人々は技術サポートを実行します。 -- 1.5の人々は開発します。 -- 3人の人が維持します。
* (3) What criteria do you use to determine whether you are being * successful, and how successful? Using those criteria, how * successful are you and what could be done, especially from the * IETF side, to improve that evaluation?
* (3) あなたは、あなたが*うまくいって、どれくらいうまくいっているかどうか決定するのにどんな評価基準を使用しますか? それらの評価基準を使用して、あなたとその評価を改良するために特に*IETF側からできたことは*どれくらいうまくいっていますか?
The continued efficient operation and evolution of the Internet is one important goal and challenge facing the IETF, and also the IETF Secretariat. Working together to assist the IETF in performing this important function has been a motivating factor in CNRI's support for almost 15 years. The criteria followed by CNRI, and (more recently) its subsidiary Foretec, in their efforts on behalf of the entire Internet community is to provide a consistent and dependable mechanism that enables those persons interested in the many and varied issues that are raised within the IETF to perform their important work in the Internet standards process unburdened by the
インターネットの継続的な効率的な操作と発展は、IETFに面していて、またIETF事務局に面している1つの重要な目標と挑戦です。 この重要な機能を実行するのにIETFを助けるために一緒に働くのは、CNRIのおよそ15年のサポートの動機づけている要素です。 CNRIによって続かれた評価基準、およびその(より最近)補助のForetecは全体のインターネットコミュニティを代表した彼らの努力で多くに興味を持っているそれらの人々とIETFの中で提起される様々な問題が彼らの重要な仕事をするのを可能にする一貫して信頼性が高いメカニズムを重荷をおろされたインターネット標準化過程に提供することになっています。
IAB Advisory Committee Informational [Page 33] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[33ページ]のRFC3716IETF: 2004年の政権と実行行進
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.
そのような努力に関連している通常の管理業務。 私は、これが何年間もにわたってもうまくいっている活動であると思いますが、改善の余地がいつもあります。 そして、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 Communityがタスクの範囲に感謝すると信じていません。 希望をいだいて総合的なワークロードを減少させて、事務局は、より多くのタスクを自動化しています。 事務局が組立てたツールにおける新機能に関する要求の長蛇の列があります。 より多くの開発者を雇うために、お金はありません。 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*成長は特定の機能の数を増やします。
IAB Advisory Committee Informational [Page 34] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[34ページ]のRFC3716IETF: 2004年の政権と実行行進
* 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関連の活動のための総予算はおよそ2.5ドルのMでした。 かなりの嵩がIETFミーティング料金でカバーされていましたが、不足分はCNRIとForetecからの貢献でカバーされていました。
CNRI has been asked by its Board to find a solution to the problem.
CNRIが問題の解決を見つけるようにBoardによって頼まれました。
Appendix E. Consultation with ICANN: IANA protocol
Parameter Assignment
ICANNとの付録E.相談: IANAプロトコルParameter Assignment
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) あなたのあなたが実行している機能の記述。 それは、*機能と、*RFC2860(MOU)とRFC2434(IANA*問題のためのガイドライン)で適切に説明されたIETFとのその関係ですかそれとも追加記述が必要ですか? *後者であるなら、あなたは何を勧めるでしょうか?
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.
ミシェル[綿、IANA]に従って、RFC2860はたぶんIANAがIETFに供給する機能について説明するMOUとして十分なままで残っています。 すぐ有能なaマネージャ、コンサルティングベースの3人の技術事務職(4つのフルタイムの同等物)プラス半ダースの人々がIETFとRIRsのために機能を実行して、そのオフィスは成ります。 IETFパラメタ課題をサポートするその努力の部分は、およそ正規職員とソフトウェアサポートと通常の管理/雇用オーバーヘッドです。 基本的に、IETFパラメタ課題機能は広げることができるプロトコル(IPプロトコルや、PPP PIDや、TCP/UDP Portや、同様のものなどの)のプロトコル番号を求める要求を受け入れるのから成ります、登録のビジネス規則、適切な登録を特定して、およびいくつかの場合部分に従ってそれらを有効にして、数を割り当てて、結果を記録して。
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.
RFC2434はガイドとして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
1冊は「IETFコンセンサス」という用語の意味に関連します。 ドキュメントがワーキンググループなどの定義されたコンセンサスを得るためのプロセスを通り抜けたとき、これは簡単です。 要求がIANAに来る場合
IAB Advisory Committee Informational [Page 35] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[35ページ]のRFC3716IETF: 2004年の政権と実行行進
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.
それはそうしていなくて、IANAはIETF期待のときに特定の指導を必要とします。 一般に、これはAD指示かコンサルティングアドバイスのフォームに入ります。 もっとも、改良された過程は助けるでしょう。 新しい登録がいつ適切であるか、そして、例えば、どんな規則が何か与えられた登録の値の課題で適用されるべきであるかをIANAに知らせるビジネス規則が助けるでしょう。
Parameter assignment being an essentially clerical function, specific guidance to the clerical staff is absolutely mandatory, and often lacking or unclear. In IANA's dreams, every internet draft would contain an IANA Considerations section, even if all it said was "IANA need not concern itself with this draft". In the absence of such a statement, the IESG's IANA Liaison is forced to read the entire document at least twice: once when the IESG is first handed the document, to ensure that any instructions to IANA are clear, and again when the IESG hands the document on, to ensure that it can perform the requests the draft makes. This is clearly time-consuming and prone to error.
パラメタ課題が本質的には事務員の機能であり、事務職への特定の指導は、絶対に義務的であって、しばしば欠けているか、または不明瞭です。 IANAの夢では、あらゆるインターネット草稿がIANA Considerations部を含むでしょう、それが示したすべてが「IANAはこの草稿に携わる必要はありません」であったとしても。 そのような声明がないとき、IESGのIANA Liaisonは少なくとも二度やむを得ず全体のドキュメントを読みます: ドキュメントが最初にIANAへのどんな指示も明確であることを保証するためにIESGに手渡されるとき、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定義はたぶん2PIDsの課題、データ交換のためのもの、およびNCP自体のためのものを必要とするでしょう。 これらの2つの番号が4つの非常に別々の範囲から来ます: 0001..00FF、0101。7FFF、8001。BFFF、およびC001。FFFF。 範囲の選択は重要です、バイト指向の非同期伝送を使用する低速線の特に上で、メッセージの相対度数のためにデータ課題で指定されたプロトコルを使用することでトレードオフを含意して、コントロール機能PIDsがまた、仕切られるとき。 このような場合には、IANAは、しかし、「2PIDsが必要である」どんなそのその「2PPP PIDsが必要です、<d-名の$gtというデータPID」も知らない必要があります。 セクションで、範囲0001から<>を定義しました。00FF、および<c-名の$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.
設計されるべき登録の記述は、等しく明確である必要があります。 「'めちゃくちゃなCode Points'という登録は造られるべきです」と、仕様がIANA Considerations部で言うなら。 すなわち、「テーブル<名前>とIANAの初期の値は姓のイニシャルコード・ポイントと65535の間のどんな残余価値でも加算値を割り当てるかもしれない」まさに起こること。 「ワーキンググループの規定番号アドバイザーは尋ねなどにされることなど」の追加期待があるか、または「情報の、または、標準の状態のRFCですべての課題をしなければならなく」て、IANA Considerations部が同じくらいあまり指定しないと、それらは必ず会われるというわけではないでしょう。 あなたがIANA Considerations部に置くものはいうことになられることです。 それが明らかにされるべきであるので、作成者は彼らが要求したものを得ます。 また、また、明確なIANA Considerations部はIANAだけではなく、共同体を助けます。
IAB Advisory Committee Informational [Page 36] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[36ページ]のRFC3716IETF: 2004年の政権と実行行進
It makes (1) the authors think about all aspects of the creation of a registry and instructions on how to maintain but also (2) the public knows and understands the new registry instructions and how they can get assignments/registrations in that registry.
それで、(1) 作者はしかし、(2) また、公衆が新しい登録指示を知っていて、理解しているとどのように主張するか、そして、それらがその登録でどうしたら課題/登録証明書を得ることができるかに関する登録と指示の創造の全面について考えます。
Something that would materially help the IANA in its evaluation of
internet drafts is a comment tracking system on the IETF side. The
IANA's use of such a system is apparent: any comments it makes on the
draft would appear in the system, where the IESG may readily retrieve
them, and the IANA can find its comments when the draft later comes
there. To be truly helpful, it should also include at least any last
call IETF commentary and AD commentary, including agreed changes to
the document. This would permit IANA to review those notes as well,
which may in turn elicit further IANA commentary ("if you make that
change, you should also specify <> in the IANA Considerations
section") or may guide IANA's implementation.
インターネット草稿の評価で物質的にIANAを助ける何かがIETF側の上のコメントトラッキング・システムです。 そのようなシステムのIANAの使用は明らかです: それが草稿のときにするどんなコメントもシステムに現れるでしょう。そこでは、IESGが容易にそれらを検索するかもしれなくて、草稿が後でそこに来るとき、IANAはコメントを見つけることができます。 また、本当に、役立つように、少なくともどんな最後の呼び出しIETF論評とAD論評も含むべきです、ドキュメントへの同意された変化を含んでいて。 これは、IANAがまた、それらの注意を再検討することを許可するでしょう。(順番に、さらなるIANA論評(「また、その変更を行うなら、あなたはIANA Considerations部で<>を指定するべきである」)を引き出すかもしれないか、または注意は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日にこの機能に選任されたスタッフはミシェルCottonとアシスタントを入れます。 彼らはコンピュータバック・オフィスアプリケーションにもかかわらず、そうでなければ、特別な技術教育なしで詳しい本質的には知的な事務職です。 技術的な質問のために、それらは大いに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.
成功の基本対策はされた課題の数です。
IAB Advisory Committee Informational [Page 37] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[37ページ]のRFC3716IETF: 2004年の政権と実行行進
Michelle's sense is that IANA is now moderately successful, however further improvement can be made internally and externally.
ミシェルの感覚はどんなにさらに内部的に外部的に改良をすることができてもIANAが現在適度にうまくいっているということです。
Paul is defining web-based automation which should help various aspects of IANA's work, including in part the IETF IANA function. Michelle believes that this automation will materially help her timeliness. But for that to be carried out properly, clear business guidelines must be given IANA for each of the existing registries, guidelines whose application can be readily automated. This is likely an IETF effort, or at least requires serious IETF input.
ポールはIETF IANA機能を一部含むIANAの仕事の種々相を助けるべきであるウェブベースのオートメーションを定義しています。 ミシェルは、このオートメーションが物質的に彼女のタイムリーさであるのを助けると信じています。 しかし、それがそれぞれの既存の登録(容易にアプリケーションを自動化できるガイドライン)へのIANAを適切に明確なビジネスガイドラインに行わされなければなりません。 これがありそうである、IETFの努力、重大なIETF入力を少なくとも必要とします。
* (4) How would you characterize the quality of your relationship * with the IETF and its leadership? Is there mutual trust and a * sense of working together on issues, or do you and your * colleagues sometimes see the relationship as adversarial?
* (4) あなたはどのようにIETFとそのリーダーシップとのあなたの関係*の品質を特徴付けますか? 信頼関係と問題に一緒に取り組むという*感覚がありますか、またはあなたとあなたの*同僚は、時々関係が敵であるとみなしますか?
At this point, Michelle feels that IETF/IAB leadership is friendly and generally constructive. She is very cognizant of AD workload, and as such tries to focus questions and find other people to ask them of. As such, she perceives the communication level and volume to be on the light side of "about right".
ここに、ミシェルは、IETF/IABリーダーシップが好意的であって、一般に、建設的であると感じます。 彼女は、ADワークロードにおいて非常に認識力があって、質問の焦点を合わせて、そういうものとして彼らを尋ねる他の人々を見つけようとします。 そういうものとして、彼女は、コミュニケーションレベルとボリュームが「権利」に関する少し軽いと知覚します。
Again, amplified clarity of IESG/WG policy would reduce her question load, and there may be utility for an IAB liaison from the IANA such as IANA has with the IESG. That is really a question for the IAB; if it has questions for IANA, the chair should feel free to invite her comment or invite a liaison.
一方、IESG/WG方針の増幅された明快は彼女の質問負荷を減少させるでしょう、そして、IANAがIESGと共に持っているIANAからのIAB連絡係のためのユーティリティがあるかもしれません。 それは本当にIABのための質問です。 それにIANAのための質問があるなら、彼女のコメントを招待するべきであるか、またはいすは遠慮なく連絡係を招待するべきです。
* (5) Are there specific known problems you would like us to look at * and understand? If so, please describe them.
* (5) あなたが、私たちに*を見て、分かって欲しいのにおける特定の知られている問題がありますか? そうだとすれば、それらについて説明してください。
This note has made a point concerning clarity of instructions, clarity of policy, and clarity of registries. There is ongoing work at IANA to clean up registry files inherited when IANA was split out from the RFC Editor's office; in dealing with the business considerations questions already raised, it may be helpful for a tiger team from the IETF to review their registries with them and make suggestions.
この注意は指示の明快、方針の明快、および登録の明快に関して主張しました。 IANAがRFC Editorのオフィスからの外で分割されたとき引き継がれた登録ファイルを掃除するために、進行中の仕事がIANAにあります。 既に引き起こされたビジネス問題疑問に対処する際に、IETFからの虎のチームがそれらでそれらの登録を見直して、提案をするのは、役立っているかもしれません。
There is an ongoing problem with receiving announcements concerning at least some internet drafts. Michelle plans to follow up with the Secretariat on this, but in short it appears that the IANA liaison is not copied on at least some list that internet draft actions are announced on. This seems to pertain to individual submissions that the IESG advises the RFC Editor that it "has no problem" publishing.
少なくともいくつかのインターネット草稿に関して発表を受けることに関する進行中の問題があります。 ミシェルは、これで事務局で引き続くのを計画していますが、要するにそれは、IANA連絡がインターネット草稿動作が発表される少なくとも何らかのリストにコピーされないのを現れさせます。 これはIESGが、それが発行しながら「問題を全く持っていない」とRFC Editorに忠告するという個々の差出に関係するように思えます。
IAB Advisory Committee Informational [Page 38] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[38ページ]のRFC3716IETF: 2004年の政権と実行行進
* (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.
詳しく述べられるように、RFC2860で説明された機能は人およそ同等物、施設、ソフトウェアサポート、および標準のビジネス荷重を表します。 これは、5年間の少なくとも過去の大体の負荷レベルであり、もうしばらくの間はほぼ同じくらいのままで残っていると予測されます。 費用対効果問題はここで詳細である問い合せ、およびそのようなものを調査して、読み込み草稿にかかわる人間参加型の努力を中心題目とします。 感覚は有効なコメントマネージメントシステムと導入するICANNが、計画しているワークフローシステムが効率とタイムリーにおけるネットの短期間改良をもたらすべきであるということです。 そして、映し出されたIETFの成長は時間がたつにつれて、その改良を消費するべきです。
Author's Address
作者のアドレス
IAB Advisory Committee IETF
IAB諮問委員会IETF
EMail: iab@iab.org
メール: iab@iab.org
IAB Advisory Committee Informational [Page 39] RFC 3716 The IETF: Administration and Execution March 2004
IABの諮問委員会の情報[39ページ]のRFC3716IETF: 2004年の政権と実行行進
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
IAB Advisory Committee Informational [Page 40]
IAB諮問委員会情報です。[40ページ]
一覧
スポンサーリンク
