RFC4844 日本語訳
4844 The RFC Series and RFC Editor. L. Daigle, Ed., InternetArchitecture Board. July 2007. (Format: TXT=38752 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Daigle, Ed.
Request for Comments: 4844
Category: Informational Internet Architecture Board
(IAB)
July 2007
ワーキンググループL.Daigle、エドをネットワークでつないでください。コメントのために以下を要求してください。 4844年のカテゴリ: 情報のインターネット・アーキテクチャ委員会(IAB)2007年7月
The RFC Series and RFC Editor
RFCシリーズとRFCエディタ
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate.
このドキュメントはインターネット技術団体が発展したとき組織化された地域社会参加と必要になった責任の原則を取り入れるRFC SeriesとRFC Editor機能のために枠組みについて説明します、その結果、RFC Seriesが、命令を実現させ続けているのを可能にします。
Daigle & IAB Informational [Page 1] RFC 4844 The RFC Series and RFC Editor July 2007
Daigle&IABの情報[1ページ]のRFC4844のRFCシリーズとRFCエディタ2007年7月
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. RFC Series Mission . . . . . . . . . . . . . . . . . . . . . . 4
3. Roles and Responsibilities . . . . . . . . . . . . . . . . . . 5
3.1. RFC Editor . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. IAB . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Operational Oversight . . . . . . . . . . . . . . . . . . 5
3.4. Policy Oversight . . . . . . . . . . . . . . . . . . . . . 6
4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Document Approval . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Definition . . . . . . . . . . . . . . . . . . . . . . 7
4.1.2. Operational Implementation . . . . . . . . . . . . . . 7
4.1.3. Process Change . . . . . . . . . . . . . . . . . . . . 8
4.1.4. Existing Approval Process Documents . . . . . . . . . 8
4.2. Editing, Processing, and Publication of Documents . . . . 8
4.2.1. Definition . . . . . . . . . . . . . . . . . . . . . . 8
4.2.2. Operational Implementation . . . . . . . . . . . . . . 8
4.2.3. Process Change . . . . . . . . . . . . . . . . . . . . 9
4.2.4. Existing Process Documents . . . . . . . . . . . . . . 9
4.3. Archiving, Indexing, and Accessibility . . . . . . . . . . 9
4.3.1. Definition . . . . . . . . . . . . . . . . . . . . . . 9
4.3.2. Operational Implementation . . . . . . . . . . . . . . 9
4.3.3. Process Change . . . . . . . . . . . . . . . . . . . . 10
4.3.4. Existing Process Documents . . . . . . . . . . . . . . 10
4.4. Series-Wide Guidelines and Rules . . . . . . . . . . . . . 10
4.4.1. Definition . . . . . . . . . . . . . . . . . . . . . . 10
4.4.2. Operational Implementation . . . . . . . . . . . . . . 10
4.4.3. Process Change . . . . . . . . . . . . . . . . . . . . 10
4.4.4. Existing Process Documents . . . . . . . . . . . . . . 10
5. RFC Streams . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. RFC Approval Processes . . . . . . . . . . . . . . . . . . 11
5.1.1. IETF Document Stream . . . . . . . . . . . . . . . . . 11
5.1.2. IAB Document Stream . . . . . . . . . . . . . . . . . 12
5.1.3. IRTF Document Stream . . . . . . . . . . . . . . . . . 12
5.1.4. Independent Submission Stream . . . . . . . . . . . . 12
5.2. RFC Technical Publication Requirements . . . . . . . . . . 13
5.2.1. IETF Documents . . . . . . . . . . . . . . . . . . . . 13
5.2.2. IAB Documents . . . . . . . . . . . . . . . . . . . . 13
5.2.3. IRTF Documents . . . . . . . . . . . . . . . . . . . . 13
5.2.4. Independent Submissions . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IAB Members at the Time of Approval . . . . . . . . . . . . . 14
8. Informative References . . . . . . . . . . . . . . . . . . . . 15
Appendix A. A Retrospective of IAB Charters and RFC Editor . . . 17
A.1. 1992 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
A.2. 1994 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
A.3. 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 RFCシリーズ任務. . . . . . . . . . . . . . . . . . . . . . 4 3。 役割と責任. . . . . . . . . . . . . . . . . . 5 3.1。 RFCエディタ. . . . . . . . . . . . . . . . . . . . . . . . 5 3.2。 IAB. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3。 操作上の見落とし. . . . . . . . . . . . . . . . . . 5 3.4。 方針見落とし. . . . . . . . . . . . . . . . . . . . . 6 4。 枠組み. . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1。 承認. . . . . . . . . . . . . . . . . . . . 7 4.1の.1を記録してください。 定義. . . . . . . . . . . . . . . . . . . . . . 7 4.1.2。 操作上の実現. . . . . . . . . . . . . . 7 4.1.3。 変化. . . . . . . . . . . . . . . . . . . . 8 4.1.4を処理してください。 既存の承認審査方式は.84.2を記録します。 ドキュメント. . . . 8 4.2.1の編集、処理、および公表。 定義. . . . . . . . . . . . . . . . . . . . . . 8 4.2.2。 操作上の実現. . . . . . . . . . . . . . 8 4.2.3。 変化. . . . . . . . . . . . . . . . . . . . 9 4.2.4を処理してください。 既存の過程は.94.3を記録します。 格納、インデックス、およびアクセシビリティ. . . . . . . . . . 9 4.3.1。 定義. . . . . . . . . . . . . . . . . . . . . . 9 4.3.2。 操作上の実現. . . . . . . . . . . . . . 9 4.3.3。 変化. . . . . . . . . . . . . . . . . . . . 10 4.3.4を処理してください。 既存の過程は.104.4を記録します。 シリーズ全体のガイドラインと規則. . . . . . . . . . . . . 10 4.4.1。 定義. . . . . . . . . . . . . . . . . . . . . . 10 4.4.2。 操作上の実現. . . . . . . . . . . . . . 10 4.4.3。 変化. . . . . . . . . . . . . . . . . . . . 10 4.4.4を処理してください。 既存の過程は.105を記録します。 RFCは.115.1を流します。 RFC承認審査方式. . . . . . . . . . . . . . . . . . 11 5.1.1。 IETFは流れ. . . . . . . . . . . . . . . . . 11 5.1の.2を記録します。 IABは流れ. . . . . . . . . . . . . . . . . 12 5.1の.3を記録します。 IRTFは流れ. . . . . . . . . . . . . . . . . 12 5.1の.4を記録します。 独立している服従の流れ. . . . . . . . . . . . 12 5.2。 RFC技術刊行物要件. . . . . . . . . . 13 5.2.1。 IETFドキュメント. . . . . . . . . . . . . . . . . . . . 13 5.2.2。 IABドキュメント. . . . . . . . . . . . . . . . . . . . 13 5.2.3。 IRTFドキュメント. . . . . . . . . . . . . . . . . . . . 13 5.2.4。 独立している差出. . . . . . . . . . . . . . . 14 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 14 7。 承認. . . . . . . . . . . . . 14 8時点のIABメンバー。 IABの回顧展がチャーターする有益な参照. . . . . . . . . . . . . . . . . . . . 15付録A.とRFCエディタ.17A.1。 1992 .17 A.2。 1994 .18 A.3。 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Daigle & IAB Informational [Page 2] RFC 4844 The RFC Series and RFC Editor July 2007
Daigle&IABの情報[2ページ]のRFC4844のRFCシリーズとRFCエディタ2007年7月
1. Introduction
1. 序論
The first Request for Comments (RFC) document was published in April of 1969 as part of the effort to design and build what we now know of as the Internet. Since then, the RFC Series has been the archival series dedicated to documenting Internet technical specifications, including both general contributions from the Internet research and engineering community as well as standards documents.
(RFC)が記録するCommentsのための最初のRequestは1969年4月に私たちが今インターネットとして知っていることを設計して、築き上げるための努力の一部として発行されました。 それ以来、RFC Seriesはインターネット技術仕様書を記録するのに捧げられた記録保管所のシリーズです、インターネット研究と工学共同体からの一般的な貢献と規格文書の両方を含んでいて。
As described in the history of the first 30 years of RFCs ([RFC2555]), the RFC Series was created for the purpose of capturing the research and engineering thought that underlie the design of (what we now know of as) the Internet. As the Internet Engineering Task Force (IETF) was formalized to carry out the discussion and documentation of Internet standards, IETF documents have become a large part (but not the entirety) of the RFC Series.
RFC Seriesがそれがデザインの基礎となる研究と工学考えを得る目的のためにRFCs([RFC2555])の最初の30年の歴史で説明されるように作成された、(私たちが今知っていること、)、インターネット。 インターネット・エンジニアリング・タスク・フォース(IETF)がインターネット標準の議論とドキュメンテーションを行うために正式にされたとき、IETFドキュメントはRFC Seriesのかなりの部分(しかし、全体でない)になりました。
As the IETF has grown up and celebrated its own 20 years of history, its requirements for archival publication of its output have changed and become more rigorous. Perhaps most significantly, the IETF must be able to define (based on its own open consensus discussion processes and leadership directions) and implement adjustments to its publication processes.
IETFが成長して、それ自身の20年間の歴史を祝ったとき、出力の記録保管所の公表のための要件は、変化して、より厳しくなりました。 IETFは公表の過程に調整を定義して(それ自身の開いているコンセンサス議論の過程とリーダーシップ方向に基づいています)、恐らく最もかなり、実行できなければなりません。
At the same time, the Internet engineering and research community as a whole has grown and come to require more openness and accountability in all organizations supporting it. More than ever, this community needs an RFC Series that is supported (operationally and in terms of its principles) such that there is a balance of:
同時に、全体でインターネット工学と研究団体は、それを支持するすべての組織で、より多くの風通しの良さと責任を必要とするように成長して、なります。 ますます、この共同体は以下のバランスがあるように支持される(操作上とその原則に関して)RFC Seriesを必要とします。
o expert implementation;
o 専門の実現。
o clear management and direction -- for operations and evolution
across the whole RFC Series (whether originating in the IETF or
not); and
o 操作と発展のために全体のRFC Seriesの向こう側に管理と指示をきれいにしてください(IETFで起こるか否かに関係なく)。 そして
o appropriate community input into and review of activities.
o 活動の共同体入力とレビューを当ててください。
Today, there is confusion and therefore sometimes tension over where and how to address RFC issues that are particular to contributing groups (e.g., the IETF, the Internet Architecture Board (IAB), or independent individuals). It isn't clear where there should be community involvement versus RFC Editor control; depending on the issue, there might be more or less involvement from the IAB, the Internet Engineering Steering Group (IESG), or the community at large. There are similar issues with handling RFC Series-wide issues -- where to discuss and resolve them in a way that is balanced across the whole series.
今日、どことどうグループ(例えば、IETF、インターネット・アーキテクチャ委員会(IAB)、または自立した個人)を寄付するのに特定のRFC問題を記述するかの上の混乱としたがって、時々緊張があります。 地域社会参加がどこにRFC Editorコントロールに反対しているべきであるかは、明確ではありません。 問題によって、IAB、インターネットEngineering Steering Group(IESG)、または一般社会からのかかわり合いが多少あるかもしれません。 RFC Series全体の問題を扱う同様の問題があります--方法でそれらについて議論して、決議するために、それが全シリーズの向こう側にバランスをとっているところで。
Daigle & IAB Informational [Page 3] RFC 4844 The RFC Series and RFC Editor July 2007
Daigle&IABの情報[3ページ]のRFC4844のRFCシリーズとRFCエディタ2007年7月
For example, there are current discussions about Intellectual Property Rights (IPR) for IETF-generated documents, but it's not clear when or how to abstract the portions of those discussions that are relevant to the rest of the RFC Series. Discussions of labeling (of RFCs in general, IETF documents in particular, or some combination thereof) generally must be applied on an RFC Series-wide basis or not at all. Without an agreed-on framework for managing the RFC Series, it is difficult to have those discussions in a non- polarized fashion -- either the IETF dictating the reality of the rest of the RFC Series, or the RFC Series imposing undue restrictions on the IETF document series.
例えば、IETFが発生しているドキュメントのためのIntellectual Property Rights(IPR)についての現在の議論がありますが、それはいつをクリアしないかことであるか要約へのどのようにがRFC Seriesの残りに関連しているそれらの議論の部分であるか。 一般に、ラベリング(一般に、RFCs、特にIETFドキュメント、またはそれの何らかの組み合わせの)の議論をRFC Series全体のベースか全く適用してはいけません。 RFC Seriesを管理するための同意している枠組みがなければ、非分極しているファッションでそれらの議論をするのは難しいです--RFC Seriesの残りの現実を書き取るIETFかIETFドキュメントシリーズに過度の制限を課すRFC Seriesのどちらか。
As part of its charter (see Appendix A), the IAB has a responsibility for the RFC Editor. Acknowledging the IETF's and the general Internet engineering and research community's evolving needs, the IAB would like to see a future for the RFC Series that continues to meet its original mandate of providing the archival series for the technical research and engineering documentation that describes the Internet.
特許(Appendix Aを見る)の一部として、IABには、RFC Editorへの責任があります。 IETF、一般的なインターネット工学、および研究団体が必要性を発展すると認めて、IABはインターネットについて説明する技術研究と技術文書に記録保管所のシリーズを提供するオリジナルの命令を満たし続けているRFC Seriesに関して未来に遭遇したがっています。
With this document, the IAB provides the framework for the RFC Series and an RFC Editor function with the specific purpose of ensuring that the RFC Series is maintained and supported in ways that are consistent with the stated purpose of the RFC Series and the realities of today's Internet research and engineering community. The framework describes the existing "streams" of RFCs, draws a roadmap of existing process documents already defining the implementation, and provides clear direction of how to evolve this framework and its supporting pieces through discussion and future document revision.
このドキュメントで、IABはRFC SeriesがRFC Seriesの述べられた目的と今日のインターネット研究と工学共同体の現実と一致した方法で維持されて、支持されるのを確実にする明確な目標と共にRFC SeriesとRFC Editor機能に枠組みを供給します。 枠組みは、RFCsの既存の「流れ」について説明して、既に実現を定義する既存の過程ドキュメントの道路地図を作成して、この枠組みと断片を支持するのをどう議論と今後のドキュメント改正で発展するかに関する明確な指示を提供します。
Specifically, this document provides a brief charter for the RFC Series, describes the role of the RFC Editor, the IAB, and the IETF Administrative Support Activity (IASA) in a framework for managing the RFC Series, and discusses the streams of input to the RFC Series from the various constituencies it serves.
明確に、このドキュメントは、簡潔な特許をRFC Seriesに供給して、RFC Seriesを管理するために枠組みでRFC Editor、IAB、およびIETF Administrative Support Activity(IASA)の役割について説明して、それが役立つ様々な選挙民からRFC Seriesと入力のストリームについて議論します。
2. RFC Series Mission
2. RFCシリーズ任務
The RFC Series is the archival series dedicated to documenting Internet technical specifications, including general contributions from the Internet research and engineering community as well as standards documents.
RFC Seriesはインターネット技術仕様書を記録するのに捧げられた記録保管所のシリーズです、規格文書と同様にインターネット研究と工学共同体からの一般的な貢献を含んでいて。
RFCs are available free of charge to anyone via the Internet.
だれにはも、RFCsはインターネットを通して無料で利用可能です。
Daigle & IAB Informational [Page 4] RFC 4844 The RFC Series and RFC Editor July 2007
Daigle&IABの情報[4ページ]のRFC4844のRFCシリーズとRFCエディタ2007年7月
3. Roles and Responsibilities
3. 役割と責任
As this document sets out a revised framework for supporting the RFC Series mission, this section reviews the updated roles and responsibilities of the entities that have had, and will have, involvement in continued support of the mission.
そうした実体の責任はそうしました、そして、このドキュメントがRFC Series任務を支持するために改訂された枠組みを出すとき、このセクションはアップデートされた役割を見直します、そして、そうしてしまうでしょう、任務の継続的なサポートにおけるかかわり合い。
3.1. RFC Editor
3.1. RFCエディタ
Originally, there was a single person acting as editor of the RFC Series (the RFC Editor). The task has grown, and the work now requires the organized activity of several experts, so there are RFC Editors, or an RFC Editor organization. In time, there may be multiple organizations working together to undertake the work required by the RFC Series. For simplicity's sake, and without attempting to predict how the role might be subdivided among them, this document refers to this collection of experts and organizations as the "RFC Editor".
元々、RFC Series(RFC Editor)のエディタとして務める1人の人がいました。 タスクは成長して、仕事が現在数人の専門家の組織的活動を必要とするので、RFCエディターズ、またはRFC Editor組織があります。 時間内に、RFC Seriesによって必要とされた仕事を引き受けるために一緒に働いている複数の組織があるかもしれません。 簡単さの目的と、役割がそれらの中でどう細分されるかもしれないかを予測するのを試みない、このドキュメントは専門家と組織のこの収集を「RFCエディタ」と呼びます。
The RFC Editor is an expert technical editor and series editor, acting to support the mission of the RFC Series. As such, the RFC Editor is the implementer handling the editorial management of the RFC Series, in accordance with the defined processes. In addition, the RFC Editor is expected to be the expert and prime mover in discussions about policies for editing, publishing, and archiving RFCs.
RFC Seriesの任務を支持するために行動して、RFC Editorは専門の技術分野担当の編集者とシリーズエディタです。 そういうものとして、RFC EditorはRFC Seriesの編集管理を扱うimplementerです、定義された過程に従って。 さらに、RFC EditorはRFCsを編集して、発行して、格納するための方針についての議論における専門家と原動力であると予想されます。
3.2. IAB
3.2. IAB
In this model, the role of the IAB is to ensure that the RFC Series mission is being appropriately fulfilled for the whole community for which it was created. The IAB does not, organizationally, have comprehensive publishing or editorial expertise. Therefore, the role of the IAB as put forward in this document is focused on ensuring that principles are met, the appropriate bodies and communities are duly informed and consulted, and the RFC Editor has what it needs in order to execute on the material that is in their mandate.
このモデルでは、IABの役割はRFC Series任務がそれが作成された共同体全体のために適切に実現しているのを保証することです。 IABは組織的に包括的な出版か編集の専門的技術を持っていません。 したがって、本書では進められるIABの役割は焦点を合わせられて、原則が満たされます、適切なボディー、共同体が正しく知らされて、相談されて、RFC Editorが相談されたのを確実にするときそれが材料の上でそれを実行するために何を必要とするかが、彼らの命令中であるということです。
It is the responsibility of the IAB to approve the appointment of the RFC Editor and to approve the general policy followed by the RFC Editor.
RFC Editorのアポイントメントを承認して、RFC Editorによって従われた全般的執行方針を承認するのは、IABの責任です。
3.3. Operational Oversight
3.3. 操作上の見落とし
The IETF Administrative Support Activity (BCP 101, [BCP101]) was created to provide administrative support for the IETF, the IAB, and the Internet Research Task Force (IRTF). In its role of supporting
IETF Administrative Support Activity(BCP101、[BCP101])は、IETF、IAB、およびインターネットResearch Task Force(IRTF)の管理サポートを提供するために作成されました。 支持の役割で
Daigle & IAB Informational [Page 5] RFC 4844 The RFC Series and RFC Editor July 2007
Daigle&IABの情報[5ページ]のRFC4844のRFCシリーズとRFCエディタ2007年7月
the IAB, the IASA is tasked with providing the funding for and operational oversight of the RFC Editor.
IABであり、IASAはRFC Editorの基金と操作上の見落としを提供するのに仕事を課されます。
The IAOC (IETF Administrative Oversight Committee) is the oversight board of the IASA, and the IAD (IETF Administrative Director) is the chief actor for the IASA.
IAOC(IETF Administrative Oversight Committee)はIASAの見落とし板です、そして、IAD(IETF Administrativeディレクター)はIASAの主要な俳優です。
The IAOC works with the IAB to identify suitable persons or entities to fulfill the mandate of the RFC Editor.
IAOCは、RFC Editorの命令を実現させるためにしかるべき人物か実体を特定するためにIABと共に働いています。
The IAOC establishes appropriate contractual agreements with the selected persons or entities to carry out the work that will satisfy the technical publication requirements defined for the various RFC input streams (see Section 5.2). The IAOC may define additional operational requirements and policies for management purposes to meet the requirements defined by the various communities.
IAOCは、様々なRFC入力ストリームのために定義された技術刊行物要件を満たす仕事を行うために選択された人々か実体との適切な契約上の合意を確立します(セクション5.2を見てください)。 管理目的が様々な共同体によって定義された必要条件を満たすように、IAOCは追加操作上の要件と方針を定義するかもしれません。
In accordance with BCP 101, the IAOC provides oversight of the operation of the RFC Editor activity based on the established agreements.
BCP101によると、IAOCは確立した協定に基づくRFC Editor活動の操作の見落としを提供します。
3.4. Policy Oversight
3.4. 方針見落とし
The IAB monitors the effectiveness of the policies in force and their implementation to ensure that the RFC Editor activity meets the editorial management and document publication needs as referenced in this document. In the event of serious non-conformance, the IAB, either on its own initiative or at the request of the IAOC, may require the IAOC to vary or terminate and renegotiate the arrangements for the RFC Editor activity.
IABは大挙して方針の有効性をモニターします、そして、RFC Editor活動が編集管理とドキュメント公表を満たすのを保証する彼らの実現は参照をつけられたコネとしてこのドキュメントを必要とします。 重大な非順応の場合、それ自身のイニシアチブかIAOCの依頼で、IABは、IAOCがRFC Editor活動のためのアレンジメントを変えるか、終えて、または再交渉するのを必要とするかもしれません。
4. Framework
4. 枠組み
With the RFC Series mission outlined above, this document describes a framework for supporting
RFC Series任務が上に概説されている状態で、このドキュメントは支持のために枠組みについて説明します。
o the operational implementation of the RFC Series,
o RFC Seriesの操作上の実現
based on
ベース
o public process and definition documents,
o 公共の過程と定義ドキュメント
for which there are
あります。
o clear responsibilities and mechanisms for update and change.
o アップデートと変化のために責任とメカニズムをきれいにしてください。
Daigle & IAB Informational [Page 6] RFC 4844 The RFC Series and RFC Editor July 2007
Daigle&IABの情報[6ページ]のRFC4844のRFCシリーズとRFCエディタ2007年7月
Generally speaking, the RFC Editor is responsible for the operational implementation of the RFC Series. As outlined in Section 3.3, the IAD provides the oversight of this operational role.
概して、RFC EditorはRFC Seriesの操作上の実現に責任があります。 セクション3.3に概説されているように、IADはこの操作上の役割の見落としを提供します。
The process and definition documents are detailed below, including responsibility for the individual process documents (maintenance and update). The RFC Editor works with the appropriate community to ensure that the process documents reflect current requirements. The IAB is charged with the role of verifying that appropriate community input has been sought and that any changes appropriately account for community requirements.
個々の過程ドキュメント(維持とアップデート)への責任を含んでいて、過程と定義ドキュメントは以下で詳細です。 RFC Editorは、過程ドキュメントが現在の要件を反映するのを保証するために適切な共同体と共に働いています。 適切な共同体入力が求められて、どんな変化も適切に共同体要件を説明することを確かめる役割でIABを告発します。
There are 3 categories of activity, and a 4th category of series-wide rules and guidelines, described for implementing the RFC Series to support its mission:
活動の3つのカテゴリ、およびシリーズ全体の規則と任務を支持するためにRFC Seriesを実行するために説明されたガイドラインの4番目のカテゴリがあります:
o Approval of documents.
o ドキュメントの承認。
o Editing, processing, and publication of documents.
o ドキュメントの編集、処理、および公表。
o Archiving and indexing the documents and making them accessible.
o 格納して、ドキュメントに索引をつけて、それらをアクセスしやすくします。
o Series rules and guidelines.
o シリーズ規則とガイドライン。
4.1. Document Approval
4.1. ドキュメント承認
The RFC Series mission implicitly requires that documents be reviewed and approved for acceptance into the series.
RFC Series任務は、ドキュメントが承認のためにシリーズに再検討されて、承認されるのをそれとなく必要とします。
4.1.1. Definition
4.1.1. 定義
Section 5.1 describes the different streams of documents that are put to the RFC Editor for publication as RFCs today. While there may be general policies for approval of documents as RFCs (to ensure the coherence of the RFC Series), there are also policies defined for the approval of documents in each stream. Generally speaking, there is a different approving body for each stream. The current definitions are catalogued in Section 5.1.
セクション5.1は今日公表のためにRFCsとしてRFC Editorにつけられるドキュメントの異なったストリームについて説明します。 RFCs(RFC Seriesの一貫性を確実にする)としてドキュメントの承認のための全般的執行方針があるかもしれませんが、各流れにおける、ドキュメントの承認のために定義された方針もあります。 概して、各流れのための異なった承認しているボディーがあります。 現在の定義はセクション5.1でカタログに載せられます。
4.1.2. Operational Implementation
4.1.2. 操作上の実現
Each stream has its own documented approval process. The RFC Editor is responsible for the approval of documents in one of the streams (Independent Submission stream, see Section 5.1.4) and works with the other approving bodies to ensure smooth passage of approved documents into the next phases, ultimately to publication and archiving as an RFC.
各流れには、それ自身の記録された承認審査方式があります。 RFC Editorは流れ(独立しているSubmissionは流れます、とセクション5.1.4は見る)の1つにおける、ドキュメントの承認に責任があって、もう片方が結局承認されたドキュメントの穏やかな航海を次のフェーズに確実にするためにボディーを承認していて、RFCとしての公表と格納に取り組みます。
Daigle & IAB Informational [Page 7] RFC 4844 The RFC Series and RFC Editor July 2007
Daigle&IABの情報[7ページ]のRFC4844のRFCシリーズとRFCエディタ2007年7月
4.1.3. Process Change
4.1.3. 過程変化
From time to time, it may be necessary to change the approval processes for any given stream, or even add or remove streams. This may occur when the RFC Editor, the IAB, the body responsible for a given stream of documents, or the community determines that there are issues to be resolved in general for RFC approval or for per-stream approval processes.
時々、流れをどんな与えられた流れのための承認審査方式も変えるか、加えるか、または取り除くのさえ必要であるかもしれません。RFC Editor、IAB、ドキュメントの与えられたストリームに原因となるボディー、または共同体が、一般に、RFC承認か1流れあたりの承認審査方式のために決議されるために問題があることを決定すると、これは起こるかもしれません。
In this framework, the general approach is that the IAB will work with the RFC Editor and other parties to get community input and it will verify that any changes appropriately account for community requirements.
この枠組みでは、一般的方法はIABが共同体入力を得るためにRFC Editorと相手と共に働くということです、そして、それはどんな変化も適切に共同体要件を説明することを確かめるでしょう。
4.1.4. Existing Approval Process Documents
4.1.4. 既存の承認審査方式ドキュメント
The existing documents describing the approval processes for each stream are detailed in Section 5.1.
各流れのための承認審査方式を説明する既存のドキュメントはセクション5.1で詳細です。
4.2. Editing, Processing, and Publication of Documents
4.2. ドキュメントの編集、処理、および公表
Producing and maintaining a coherent, well-edited document series requires specialized skills and subject matter expertise. This is the domain of the RFC Editor. Nevertheless, the community served by the RFC Series and the communities served by the individual streams of RFCs have requirements that help define the nature of the series.
一貫性を持っていて、よく編集されたドキュメントシリーズを生産して、維持するのは専門的能力と内容専門的技術を必要とします。 これはRFC Editorのドメインです。 それにもかかわらず、RFC Seriesによって役立たれた共同体とRFCsの個々の流れで役立たれる共同体はシリーズの本質を定義するのを助ける要件を持っています。
4.2.1. Definition
4.2.1. 定義
General and stream-specific requirements for the RFC Series are documented in community-approved documents (catalogued in Section 5.2 below).
RFC Seriesのための一般と流れ決められた一定の要求は共同体によって承認されたドキュメント(以下のセクション5.2では、カタログに載せられる)に記録されます。
Any specific interfaces, numbers, or concrete values required to make the requirements operational are the subject of agreements between the IASA and the RFC Editor (e.g., contracts, statements of work, service level agreements, etc).
要件を操作上にするのに必要であるどんな特定のインタフェース、数、または具体的な値もIASAとRFC Editor(例えば、契約、仕事の声明、サービスレベル協定など)との協定の対象です。
4.2.2. Operational Implementation
4.2.2. 操作上の実現
The RFC Editor is responsible for ensuring that editing, processing, and publication of RFCs are carried out in a way that is consistent with the requirements laid out in the appropriate documents. The RFC Editor works with the IASA to provide regular reporting and feedback on these operations.
RFCsの編集、処理、および公表が適切なドキュメントで広げられる要件と一致した方法で行われるのを確実にするのにRFC Editorは責任があります。 RFC Editorは、これらの操作の定期的な報告とフィードバックを提供するためにIASAと共に働いています。
Daigle & IAB Informational [Page 8] RFC 4844 The RFC Series and RFC Editor July 2007
Daigle&IABの情報[8ページ]のRFC4844のRFCシリーズとRFCエディタ2007年7月
4.2.3. Process Change
4.2.3. 過程変化
From time to time, it may be necessary to change the requirements for any given stream, or the RFC Series in general. This may occur when the RFC Editor, the IAB, the approval body for a given stream of documents, or the community determines that there are issues to be resolved in general for RFCs or for per-stream requirements.
時々、どんな与えられた流れのための要件、または一般に、RFC Seriesも変えるのが必要であるかもしれません。 RFC Editor、IAB、ドキュメントの与えられたストリームのための承認の本体、または共同体が、一般に、RFCsか1流れあたりの要件のために決議されるために問題があることを決定すると、これは起こるかもしれません。
In this model, the general approach is that the IAB will work with the RFC Editor to get community input and it will approve changes by validating appropriate consideration of community requirements.
このモデルでは、一般的方法はIABが共同体入力を得るためにRFC Editorと共に働いて、共同体要件の適切な考慮を有効にすることによって変化を承認するということです。
4.2.4. Existing Process Documents
4.2.4. 既存の過程ドキュメント
Documents describing existing requirements for the streams are detailed in Section 5.2.
流れのための既存の要件について説明するドキュメントはセクション5.2で詳細です。
4.3. Archiving, Indexing, and Accessibility
4.3. 格納、インデックス、およびアクセシビリティ
The activities of archiving, indexing, and making accessible the RFC Series can be informed by specific subject matter expertise in general document series editing. It is also important that they are informed by requirements from the whole community. As long as the RFC Series is to remain coherent, there should be uniform archiving and indexing of RFCs across all streams and a common method of accessing the resulting documents.
活動、知らされて、一般に、特定の内容専門的技術がシリーズ編集を記録するというRFC Series缶にアクセスしやすく格納して、索引をつけて、することでは、ことになってください。 また、それらが要件によって共同体全体から知らされるのも、重要です。 RFC Seriesが一貫性を持っていたままで残ることになっている限り、結果として起こるドキュメントにアクセスするすべての流れと共通方法の向こう側にRFCsを格納して、索引をつけるユニフォームは、あるはずです。
4.3.1. Definition
4.3.1. 定義
In principle, there should be a community consensus document describing the archiving, indexing, and accessibility requirements for the RFC Series. In practice, we continue with the archive as built by the capable RFC Editors since the series' inception.
原則として、RFC Seriesのための格納、インデックス、およびアクセシビリティ要件について説明する共同体コンセンサスドキュメントがあるはずです。 実際には、私たちはシリーズの始まり以来できるRFCエディターズによって建てられるようにアーカイブを続行します。
Any specific concrete requirements for the archive, index, and accessibility operations are the subject of agreements between the IASA and the RFC Editor (e.g., contracts, statements of work, service level agreements, etc).
アーカイブ、インデックス、およびアクセシビリティ操作のためのどんな特定の具体的な要件もIASAとRFC Editor(例えば、契約、仕事の声明、サービスレベル協定など)との協定の対象です。
4.3.2. Operational Implementation
4.3.2. 操作上の実現
The RFC Editor is responsible for ensuring that the RFC archive and index are maintained appropriately and that the resulting documents are made available to anybody wishing to access them via the Internet. The RFC Editor works with the IASA for regular reporting and feedback.
適切にRFCアーカイブとインデックスを維持して、結果として起こるドキュメントをインターネットを通してそれらにアクセスしたがっているだれにとっても利用可能にするのを確実にするのにRFC Editorは責任があります。 RFC Editorは定期的な報告とフィードバックのためにIASAと共に働いています。
Daigle & IAB Informational [Page 9] RFC 4844 The RFC Series and RFC Editor July 2007
Daigle&IABの情報[9ページ]のRFC4844のRFCシリーズとRFCエディタ2007年7月
4.3.3. Process Change
4.3.3. 過程変化
Should there be a community move to propose changes to the requirements for the RFC archive and index or accessibility, the IAB will work with the RFC Editor to get community input and it will approve changes by validating appropriate consideration of community requirements.
RFCアーカイブとインデックスのための要件への変化を提案する共同体移動かアクセシビリティがあると、IABは共同体入力を得るためにRFC Editorと共に働くでしょう、そして、それは共同体要件の適切な考慮を有効にすることによって、変化を承認するでしょう。
4.3.4. Existing Process Documents
4.3.4. 既存の過程ドキュメント
There are no applicable process documents.
どんな適切な過程ドキュメントもありません。
4.4. Series-Wide Guidelines and Rules
4.4. シリーズ全体のガイドラインと規則
The RFC Series style and content can be shaped by subject matter expertise in document series editing. They are also informed by requirements by the using community. As long as the RFC Series is to remain coherent, there should be uniform style and content for RFCs across all streams. This includes, but is not limited to, acceptable language, use of references, and copyright rules.
ドキュメントシリーズ編集における内容専門的技術はRFC Seriesスタイルと内容を形成できます。 また、それらは要件によって使用共同体によって知らされます。 RFC Seriesが一貫性を持っていたままで残ることになっている限り、RFCsのための一定のスタイルと内容が含んでいますが、流れこれが制限されないすべて、ふさわしい言葉、参照の使用、および著作権規則のむこうにあるべきです。
4.4.1. Definition
4.4.1. 定義
In principle, there should be a community consensus document (or set of documents) describing the content requirements for the RFC Series. In practice, some do exist, though some need reviewing and more may be needed over time.
原則として、RFC Seriesのための満足している要件について説明する共同体コンセンサスドキュメント(または、ドキュメントのセット)があるはずです。 実際には、或るものは、論評する必要がありますが、或るものは存在しています、そして、以上が時間がたつにつれて、必要であるかもしれません。
4.4.2. Operational Implementation
4.4.2. 操作上の実現
The RFC Editor is responsible for ensuring that the RFC Series guidelines are upheld within the RFC Series.
RFC SeriesガイドラインがRFC Seriesの中で是認されるのを確実にするのにRFC Editorは責任があります。
4.4.3. Process Change
4.4.3. 過程変化
When additions or changes are needed to series-wide definitions, the IAB will work with the RFC Editor and stream stakeholders to get community input and review. The IAB will approve changes by validating appropriate consideration of community requirements.
追加か変化がシリーズ全体の定義に必要であるときに、IABは、共同体入力とレビューを得るためにRFC Editorと流れの利害関係者と共に働くでしょう。 IABは、共同体要件の適切な考慮を有効にすることによって、変化を承認するでしょう。
4.4.4. Existing Process Documents
4.4.4. 既存の過程ドキュメント
Existing series-wide rules and guidelines documents include:
既存のシリーズ全体の規則とガイドラインドキュメントは:
o Instructions to RFC Authors (RFC 2223 [RFC2223], [RFC2223BIS])
o RFC作者への指示(RFC2223[RFC2223]、[RFC2223BIS])
o Copyright and intellectual property rules (RFC 3978 [RFC3978] and
RFC 4748 [RFC4748])
o 著作権と知的所有権規則(RFC3978[RFC3978]とRFC4748[RFC4748])
Daigle & IAB Informational [Page 10] RFC 4844 The RFC Series and RFC Editor July 2007
Daigle&IABの情報[10ページ]のRFC4844のRFCシリーズとRFCエディタ2007年7月
o Normative references (RFC 3967 [RFC3967] and RFC 4897 [RFC4897])
o 引用規格(RFC3967[RFC3967]とRFC4897[RFC4897])
5. RFC Streams
5. RFCの流れ
Various contributors provide input to the RFC Series. These contributors come from several different communities, each with its own defined process for approving documents that will be published by the RFC Editor. This is nothing new; however, over time the various communities and document requirements have grown and separated. In order to promote harmony in discussing the collective set of requirements, it is useful to recognize each in their own space -- and they are referred to here as "streams".
様々な貢献者は入力をRFC Seriesに供給します。 これらの貢献者はいくつかの異なった共同体(RFC Editorによって発表される承認しているドキュメントのためのそれ自身の定義された過程があるそれぞれ)から来ます。 これは何も新しくないものです。 しかしながら、時間がたつにつれて、様々な共同体とドキュメント要件は、成長して、分離しました。 それら自身のスペースでそれぞれを認識するのが集合的なセットの要件について議論する際に調和を促進するために役に立って、それらは「流れ」としてここと呼ばれます。
Note that by identifying separate streams, there is no intention of dividing them or undermining their management as one series. Rather, the opposite is true -- by clarifying the constituent parts, it is easier to make them work together without the friction that sometimes arises when discussing various requirements.
別々の流れを特定することによって、1つのシリーズとしてそれらを分割するか、または彼らの管理をひそかに害するという意志が全くないことに注意してください。 むしろ、正反対は本当です--構成している部品をはっきりさせることによって、様々な要件について議論するとき時々起こる摩擦なしで一緒に働かせるのは、より簡単です。
The subsections below identify the streams that exist today. There is no immediate expectation of new streams being created and it is preferable that new streams NOT be created. Creation of streams and all policies surrounding general changes to the RFC Series are discussed above in Section 4.
以下の小区分は今日存在する流れを特定します。 作成される新しい流れへのどんな即座の期待もありません、そして、新しい流れが作成されないのは、望ましいです。 セクション4で上でRFC Seriesへの一般的な変化を囲む流れの創造とすべての方針について議論します。
5.1. RFC Approval Processes
5.1. RFC承認審査方式
Processes for approval of documents (or requirements) for each stream are defined by the community that defines the stream. The IAB is charged with the role of verifying that appropriate community input has been sought and that the changes are consistent with the RFC Series mission and this overall framework.
各流れのためのドキュメント(または、要件)の承認のための過程は流れを定義する共同体によって定義されます。 適切な共同体入力が求められて、変化がRFC Series任務とこの総合的な枠組みと一致していることを確かめる役割でIABを告発します。
The RFC Editor is expected to publish all documents passed to it after appropriate review and approval in one of the identified streams.
RFC Editorが適切なレビューと承認の後に特定された流れの1つでそれに渡されたすべてのドキュメントを発表すると予想されます。
5.1.1. IETF Document Stream
5.1.1. IETFドキュメントストリーム
The IETF document stream includes IETF WG documents as well as "individual submissions" sponsored by an IESG area director. Any document being published as part of the IETF standards process must follow this stream -- no other stream can approve Standards-Track or Best Current Practice (BCP) RFCs.
IETFドキュメントストリームはIESG領域ディレクターによって後援された「個々の差出」と同様にIETF WGドキュメントを含んでいます。 IETF標準化過程の一部がこの流れに続かなければならなくて発表されるどんなドキュメントも--他のどんな流れもStandards-道かBest Current Practice(BCP)RFCsを承認できません。
Daigle & IAB Informational [Page 11] RFC 4844 The RFC Series and RFC Editor July 2007
Daigle&IABの情報[11ページ]のRFC4844のRFCシリーズとRFCエディタ2007年7月
Approval of documents in the IETF stream is defined by
流れが定義されるIETFでのドキュメントの承認
o the IETF standards process (RFC 2026 [RFC2026] and its
successors).
o IETF規格は(RFC2026[RFC2026]とその後継者)を処理します。
o the IESG process for sponsoring individual submissions [SPONSOR]).
o IESGは、個々の差出[SPONSOR)を後援するために処理します。
Changes to the approval process for this stream are made by updating the IETF standards process documents.
この流れのための承認審査方式への変更は、IETF標準化過程ドキュメントをアップデートすることによって、行われます。
5.1.2. IAB Document Stream
5.1.2. IABドキュメントストリーム
The IAB defines the processes by which it approves documents in its stream. Consistent with the above, any documents that the IAB wishes to publish as part of the IETF Standards Track (Standards or BCPs) are subject to the approval processes referred to in Section 5.1.1.
IABはそれが流れでドキュメントを承認する過程を定義します。 上記で一貫しています、IABがIETF Standards Track(規格かBCPs)の一部として発表したがっているどんなドキュメントもセクション5.1.1で示された承認審査方式を受けることがあります。
The review and approval process for documents in the IAB stream is described in
IABの流れのドキュメントのための過程が説明されるレビューと承認
o the IAB process for review and approval of its documents (RFC 4845
[RFC4845]).
o IABはドキュメント(RFC4845[RFC4845])のレビューと承認のために処理します。
5.1.3. IRTF Document Stream
5.1.3. IRTFドキュメントストリーム
The IRTF is chartered as an activity of the IAB. With the approval of the IAB, the IRTF may publish and update a process for publication of its own, non-IETF Standards-Track, documents.
IRTFはIABの活動としてチャーターされます。 IRTFはそれ自身の公表のためにIABの承認をもって、過程を発行して、アップデートするかもしれません、非IETF Standardsは追跡しています、ドキュメント。
The review and approval process for documents in the IRTF stream is described in
IRTFの流れのドキュメントのための過程が説明されるレビューと承認
o IRTF Research Group RFCs [IRTF-DOCS].
o IRTFはグループRFCs[IRTF-DOCS]について研究します。
5.1.4. Independent Submission Stream
5.1.4. 独立している服従の流れ
The RFC Series has always served a broader Internet technical community than the IETF. The "Independent Submission" stream is defined to provide review and (possible) approval of documents that are outside the scope of the streams identified above.
RFC SeriesはいつもIETFより広いインターネット技術団体に役立っていました。 「独立している服従」の流れは、上で特定された流れの範囲の外にあるドキュメントのレビューと(可能)の承認を提供するために定義されます。
Generally speaking, approval of documents in this stream falls under the purview of the RFC Editor, and the RFC Editor seeks input to its review from the IESG.
概して、この流れにおける、ドキュメントの承認はRFC Editorの範囲の下で落ちます、そして、RFC EditorはIESGからのレビューに入力を求めます。
Daigle & IAB Informational [Page 12] RFC 4844 The RFC Series and RFC Editor July 2007
Daigle&IABの情報[12ページ]のRFC4844のRFCシリーズとRFCエディタ2007年7月
The process for reviewing and approving documents in the Independent Submission stream is defined by
審査して承認するための無党派Submissionの流れのドキュメントが定義される過程
o Independent Submissions to the RFC Editor (RFC 4846 [RFC4846]).
o RFCエディタ(RFC4846[RFC4846])への独立している差出。
o The IESG and RFC Editor Documents: Procedures (RFC 3932
[RFC3932]).
o IESGとRFCエディタドキュメント: 手順(RFC3932[RFC3932])。
5.2. RFC Technical Publication Requirements
5.2. RFC技術刊行物要件
The Internet engineering and research community has not only grown, it has become more diverse, and sometimes more demanding. The IETF, as a standards-developing organization, has publication requirements that extend beyond those of an academic journal. The IAB does not have the same interdependence with IANA assignments as the IETF stream does. Therefore, there is the need to both codify the publishing requirements of each stream, and endeavor to harmonize them to the extent that is reasonable.
インターネット工学と研究団体は発展しているだけではなくて、それは、よりさまざまで、時々より過酷になりました。 IETFには、規格を開発する組織として、学術誌のもので広がる公表要件があります。 IABにはIANA課題による同じ相互依存がIETFの流れが持っているようにありません。 したがって、ともにそれぞれの流れの出版要件を成文化する必要性、および妥当な範囲にそれらを調和させる努力があります。
Therefore, it is expected that the community of effort behind each document stream will outline their technical publication requirements.
したがって、それぞれのドキュメントストリームの後ろの努力の共同体がそれらの技術刊行物要件について概説すると予想されます。
As part of the RFC Editor oversight, the IAB must agree that the requirements are consistent with and implementable as part of the RFC Editor activity.
RFC Editor見落としの一部として、IABはRFC Editor活動の一部として要件が一貫していると同意して、実行可能しなければなりません。
5.2.1. IETF Documents
5.2.1. IETFドキュメント
The requirements for this stream are defined in RFC 4714 [RFC4714].
この流れのための要件はRFC4714[RFC4714]で定義されます。
5.2.2. IAB Documents
5.2.2. IABドキュメント
Although they were developed for the IETF standards process, the IAB will identify the applicable requirements in RFC 4714 for its stream.
それらはIETF標準化過程のために開発されましたが、IABは流れのためにRFC4714で規定の要件を特定するでしょう。
If the IAB elects to define other requirements, they should deviate minimally from those (in an effort to keep the collective technical publication requirements reasonably managed by one technical publisher).
IABが、他の要件を定義するのを選ぶなら、それらはそれら(1つの技術的な出版社が合理的に集合的な技術刊行物要件を管理し続けるための努力における)から最少量で逸れるべきです。
5.2.3. IRTF Documents
5.2.3. IRTFドキュメント
Although they were developed for the IETF standards process, the IRTF will identify the applicable requirements in RFC 4714 for its stream.
それらはIETF標準化過程のために開発されましたが、IRTFは流れのためにRFC4714で規定の要件を特定するでしょう。
If the IRTF elects to define other requirements, they should deviate minimally from those (in an effort to keep the collective technical
IRTFが、他の要件を定義するのを選ぶなら、それらから最少量で逸れるべきである、(技術的に集合体を維持するための努力
Daigle & IAB Informational [Page 13] RFC 4844 The RFC Series and RFC Editor July 2007
Daigle&IABの情報[13ページ]のRFC4844のRFCシリーズとRFCエディタ2007年7月
publication requirements reasonably managed by one technical publisher).
1つの技術的な出版社によって合理的に管理された公表要件)
5.2.4. Independent Submissions
5.2.4. 独立している差出
Although they were developed for the IETF standards process, the RFC Editor will identify the applicable requirements in RFC 4714 for its stream.
それらはIETF標準化過程のために開発されましたが、RFC Editorは流れのためにRFC4714で規定の要件を特定するでしょう。
If the RFC Editor elects to define other requirements, they should deviate minimally from those (in an effort to keep the collective technical publication requirements reasonably managed by one technical publisher).
RFC Editorが、他の要件を定義するのを選ぶなら、それらはそれら(1つの技術的な出版社が合理的に集合的な技術刊行物要件を管理し続けるための努力における)から最少量で逸れるべきです。
6. Security Considerations
6. セキュリティ問題
The processes for the publication of documents must prevent the introduction of unapproved changes. Since the RFC Editor maintains the index of publications, sufficient security must be in place to prevent these published documents from being changed by external parties. The archive of RFC documents, any source documents needed to recreate the RFC documents, and any associated original documents (such as lists of errata, tools, and, for some early items, non- machine readable originals) need to be secured against failure of the storage medium and other similar disasters.
ドキュメントの公表のための過程は承認していない変化の導入を防がなければなりません。 RFC Editorが刊行物のインデックスを維持するので、これらの公表された文書が外部のパーティーによって変えられるのを防ぐために、十分なセキュリティは適所にあるに違いありません。 RFCドキュメントのアーカイブ、どんなソースドキュメントもRFCドキュメントを再作成する必要がありました、そして、どんな関連正本(誤字、ツール、および数個の早めの項目のための非マシンの読み込み可能なオリジナルのリストなどの)も記憶媒体と他の同様の災害の失敗に対して安全にされる必要があります。
7. IAB Members at the Time of Approval
7. 承認時点のIABメンバー
Bernard Aboba Loa Andersson Brian Carpenter Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman Kurtis Lindqvist David Meyer David Oran Eric Rescorla Dave Thaler Lixia Zhang
バーナードAboba Loaアンデションブライアン大工レスリーDaigle ElwynデイヴィースケビンFallオラフ・Kolkmanカーティス・リンクヴィスト・デヴィッド・マイヤー・デヴィッド・オラン・エリック・レスコラ・デーヴ・ターレルLixiaチャン
Daigle & IAB Informational [Page 14] RFC 4844 The RFC Series and RFC Editor July 2007
Daigle&IABの情報[14ページ]のRFC4844のRFCシリーズとRFCエディタ2007年7月
8. Informative References
8. 有益な参照
[BCP101] Austein, R. and B. Wijnen, "Structure of the IETF
Administrative Support Activity (IASA)", RFC 4071,
BCP 101, April 2005.
[BCP101] AusteinとR.とB.Wijnen、「IETFの管理サポート活動(IASA)の構造」、RFC4071、BCP101、2005年4月。
[IABCHARTER] Carpenter, B., "Charter of the Internet Architecture
Board (IAB)", RFC 2850, May 2000.
[IABCHARTER]は大工仕事をして、B.(「インターネット・アーキテクチャ委員会(IAB)の憲章」、RFC2850)は2000がそうするかもしれません。
[IRTF-DOCS] Falk, A., "IRTF Research Group RFCs", Work in Progress,
February 2006.
「IRTF研究グループRFCs」という[IRTF-DOCS]フォーク、A.は進歩、2006年2月に働いています。
[RFC1358] Chapin, L., "Charter of the Internet Architecture Board
(IAB)", RFC 1358, August 1992.
[RFC1358] チェーピン、L.、「インターネット・アーキテクチャ委員会(IAB)の憲章」、RFC1358、1992年8月。
[RFC1601] Huitema, C., "Charter of the Internet Architecture
Board (IAB)", RFC 1601, March 1994.
[RFC1601] Huitema、C.、「インターネット・アーキテクチャ委員会(IAB)の憲章」、RFC1601、1994年3月。
[RFC2026] Bradner, S., Ed., "The Internet Standards Process --
Revision 3", RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、エド、「インターネット規格は処理されます--改正3インチ、RFC2026、1996年10月。」
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC
Authors", RFC 2223, October 1997.
[RFC2223] ポステル、J.、およびJ.レイノルズ、「指示、RFCが書く、」、RFC2223、10月1997日
[RFC2223BIS] Reynolds, J., Ed. and R. Braden, Ed., "Instructions to
Request for Comments (RFC) Authors", Work in Progress,
August 2004.
エド[RFC2223BIS]レイノルズ、J.、R.ブレーデン、エド、8月2004、「(RFC)が書くコメントのために要求する指示」は進行中で働いています。
[RFC2555] Editor, RFC., "30 Years of RFCs", RFC 2555, April 1999.
[RFC2555] エディタ、RFC、「30年間のRFCs」、RFC2555、4月1999日
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents:
Procedures", RFC 3932, October 2004.
[RFC3932] Alvestrand、H.、「IESGとRFCエディタは以下を記録します」。 「手順」、RFC3932、2004年10月。
[RFC3967] Bush, R. and T. Narten, "Clarifying when Standards
Track Documents may Refer Normatively to Documents at a
Lower Level", RFC 3967, December 2004.
[RFC3967] ブッシュ、R.、およびT.Narten、「Standards Track Documentsがそうするときのはっきりさせる、Lower LevelのDocumentsへのRefer Normatively、」、RFC3967(2004年12月)
[RFC3978] Bradner, S., Ed., "IETF Rights in Contributions",
RFC 3978, March 2005.
[RFC3978] ブラドナー、S.、エド、「貢献におけるIETF権利」、RFC3978、3月2005日
[RFC4693] Alvestrand, H., "IETF Operational Notes", RFC 4693,
October 2006.
[RFC4693] Alvestrand、H.、「IETFの操作上の注意」、RFC4693、2006年10月。
Daigle & IAB Informational [Page 15] RFC 4844 The RFC Series and RFC Editor July 2007
Daigle&IABの情報[15ページ]のRFC4844のRFCシリーズとRFCエディタ2007年7月
[RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF
Technical Publication Service", RFC 4714, October 2006.
[RFC4714] マンキンとA.とS.ヘイズ、「IETF技術刊行物サービスのための要件」、RFC4714、2006年10月。
[RFC4748] Bradner, S., Ed., "RFC 3978 Update to Recognize the
IETF Trust", RFC 4748, October 2006.
[RFC4748] ブラドナー、S.、エド、「RFC3978は、IETF信用を認識するのをアップデートする」RFC4748、10月2006日
[RFC4845] Daigle, L., "Process for Publication of IAB RFCs",
RFC 4845, July 2007.
Daigle(L.)が「IAB RFCsの公表のために処理する」[RFC4845]、RFC4845、2007年7月。
[RFC4846] Klensin, J. and D. Thaler, "Independent Submissions to
the RFC Editor", RFC 4846, July 2007.
[RFC4846] Klensin、J.、およびD.ターレル、「独立している差出、RFCエディタ、」、RFC4846、7月2007日
[RFC4897] Klensin, J., "Handling Normative References to
Standards Track Documents", BCP 97, RFC 4897,
June 2007.
[RFC4897] Klensin、J.、「標準化過程ドキュメントの取り扱い引用規格」、BCP97、RFC4897、2007年6月。
[SPONSOR] Arkko, J., "Guidance on Area Director Sponsoring of
Documents", ION, October 2006.
[スポンサー]Arkko、J.、「ドキュメントの領域ディレクター後援の指導」、イオン、2006年10月。
Daigle & IAB Informational [Page 16] RFC 4844 The RFC Series and RFC Editor July 2007
Daigle&IABの情報[16ページ]のRFC4844のRFCシリーズとRFCエディタ2007年7月
Appendix A. A Retrospective of IAB Charters and RFC Editor
IABの回顧展がチャーターする付録A.とRFCエディタ
With this document, the IAB's role with respect to the RFC Series and the RFC Editor is being adjusted to work more directly with the RFC Editor and provide oversight to ensure the RFC Series mission principles and communities' input are addressed appropriately.
このドキュメントで、RFC SeriesとRFC Editorに関するIABの役割は、より直接RFC Editorと共に働いて、RFC Series任務原則と共同体の入力が適切に記述されるのを保証するために見落としを提供するように調整されています。
This section provides an overview of the role of the IAB with respect to the RFC Editor as it has been presented in IAB Charter RFCs dating back to 1992. The point of this section is that the IAB's role has historically been substantive -- whether it is supposed to be directly responsible for the RFC Series' editorial management (circa 1992, Appendix A.1), or appointment of the RFC Editor organization and approval of general policy (circa 2000, Appendix A.3).
それが1992までさかのぼりながらIAB憲章RFCsに提示されたとき、このセクションはRFC Editorに関してIABの役割の概観を提供します。 このセクションの先はそれが直接RFC Seriesの編集管理(1992年頃のAppendix A.1)か、RFC Editor組織のアポイントメントと全般的執行方針の承認(2000年頃のAppendix A.3)に責任があるべきであるか否かに関係なく、IABの役割が歴史的に実質的であるということです。
A.1. 1992
A.1。 1992
[RFC1358] says:
[RFC1358] 言います:
[The IAB's] responsibilities shall include:
[...]
(2) The editorial management and publication of the Request for
Comments (RFC) document series, which constitutes the
archival publication series for Internet Standards and
related contributions by the Internet research and
engineering community.
[IAB]の責任は以下を含んでいるものとします。 [...] (2) Comments(RFC)のためのRequestの編集管理と公表はシリーズを記録します。(シリーズはインターネット研究と工学共同体によるインターネットStandardsと関連する貢献のために記録保管所の公表シリーズを構成します)。
Daigle & IAB Informational [Page 17] RFC 4844 The RFC Series and RFC Editor July 2007
Daigle&IABの情報[17ページ]のRFC4844のRFCシリーズとRFCエディタ2007年7月
A.2. 1994
A.2。 1994
[RFC1601] says:
[RFC1601] 言います:
[The IAB's] responsibilities under this charter include:
この特許の下における[IAB]の責任は:
(d) RFC Series and IANA
(d) RFCシリーズとIANA
The IAB is responsible for editorial management and publication of
the Request for Comments (RFC) document series, and for
administration of the various Internet assigned numbers.
Comments(RFC)ドキュメントシリーズ、および様々なインターネット規定番号の管理において、IABはRequestの編集管理と公表に責任があります。
which it elaborates as
どれとして、それは詳述しますか。
2.4 RFC Series and Assigned Numbers
2.4 RFCシリーズと規定番号
The RFC Series constitutes the archival publication channel for
Internet Standards and for other contributions by the Internet
research and engineering community. The IAB shall select an RFC
Editor, who shall be responsible for the editorial management and
publication of the RFC Series.
RFC SeriesはインターネットStandardsと他の貢献のためのインターネット研究と工学共同体のそばの記録保管所の公開チャネルを構成します。 IABはRFC Editorを選択するものとします。(RFC EditorはRFC Seriesの編集管理と公表に責任があるでしょう)。
A.3. 2000
A.3。 2000
[IABCHARTER], which is the most recent IAB Charter document, says:
[IABCHARTER](最新のIAB憲章ドキュメントである)は言います:
(d) RFC Series and IANA
(d) RFCシリーズとIANA
The RFC Editor executes editorial management and publication of the IETF "Request for Comment" (RFC) document series, which is the permanent document repository of the IETF. The RFC Series constitutes the archival publication channel for Internet Standards and for other contributions by the Internet research and engineering community. RFCs are available free of charge to anyone via the Internet. The IAB must approve the appointment of an organization to act as RFC Editor and the general policy followed by the RFC Editor.
RFC EditorはIETFの管理と公表が、(RFC)がシリーズを記録するよう「コメントのために、要求する」という社説を実行します。シリーズはIETFの永久証書倉庫です。 RFC SeriesはインターネットStandardsと他の貢献のためのインターネット研究と工学共同体のそばの記録保管所の公開チャネルを構成します。 だれにはも、RFCsはインターネットを通して無料で利用可能です。 IABは、RFC Editorと全般的執行方針がRFC Editorで従って行動するために組織のアポイントメントを承認しなければなりません。
Daigle & IAB Informational [Page 18] RFC 4844 The RFC Series and RFC Editor July 2007
Daigle&IABの情報[18ページ]のRFC4844のRFCシリーズとRFCエディタ2007年7月
Authors' Addresses
作者のアドレス
Leslie L. Daigle (editor)
レスリーL.Daigle(エディタ)
EMail: ledaigle@cisco.com, leslie@thinkingcat.com
メール: ledaigle@cisco.com 、leslie@thinkingcat.com
IAB
IAB
EMail: iab@iab.org URI: http://www.iab.org/
メール: iab@iab.org ユリ: http://www.iab.org/
Daigle & IAB Informational [Page 19] RFC 4844 The RFC Series and RFC Editor July 2007
Daigle&IABの情報[19ページ]のRFC4844のRFCシリーズとRFCエディタ2007年7月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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.
このドキュメントは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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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機能のための基金は現在、インターネット協会によって提供されます。
Daigle & IAB Informational [Page 20]
Daigle&IAB情報です。[20ページ]
一覧
スポンサーリンク
