[要約] RFC 4844は、RFCシリーズとRFCエディターに関するガイドラインであり、RFCの作成、編集、管理のプロセスを定義しています。その目的は、RFCの品質と一貫性を確保し、技術コミュニティのニーズに応えるための枠組みを提供することです。
Network Working Group L. Daigle, Ed.
Request for Comments: 4844
Category: Informational Internet Architecture Board
(IAB)
July 2007
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).
著作権（c）The IETF Trust（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シリーズのフレームワークと、インターネットの技術コミュニティが成長するにつれて必要になった組織化されたコミュニティの関与と説明責任の原則を組み込むRFCエディター機能について説明します。
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
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）ドキュメントは、1969年4月にインターネットとして知っていることを設計および構築する取り組みの一環として公開されました。それ以来、RFCシリーズは、インターネット研究およびエンジニアリングコミュニティからの一般的な貢献と標準文書の両方を含む、インターネットの技術仕様の文書化に専念するアーカイブシリーズです。
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.
RFCSの最初の30年間の歴史（[RFC2555]）の歴史で説明されているように、RFCシリーズは、インターネットの（私たちが今知っていること）のデザインの根底にある研究と工学の考えをキャプチャする目的で作成されました。インターネットエンジニアリングタスクフォース（IETF）がインターネット標準の議論と文書を実行するために正式になったため、IETFドキュメントはRFCシリーズの大きな部分（ただし全体ではありません）になりました。
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シリーズを必要としています。
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シリーズ全体にわたる運用と進化のため（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エディターコントロールに対してコミュニティの関与がどこにあるべきかは明らかではありません。問題によっては、IAB、インターネットエンジニアリングステアリンググループ（IESG）、またはコミュニティ全体から多かれ少なかれ関与する可能性があります。RFCシリーズ全体の問題を処理することには同様の問題があります。シリーズ全体でバランスをとる方法でそれらを議論し解決する場所です。
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で生成された文書の知的財産権（IPR）に関する現在の議論がありますが、RFCシリーズの残りに関連する議論の部分をいつ、どのように抽象化するかは明確ではありません。（一般的にRFCのIETFドキュメント、またはその組み合わせ）のラベル付けの議論は、一般にRFCシリーズ全体のベースで適用するか、まったく適用する必要があります。RFCシリーズを管理するための合意されたフレームワークがなければ、これらの議論を非極性化された方法で行うことは困難です。これは、RFCシリーズの残りの現実を決定するIETF、またはRFCシリーズが過度の制限を課していることです。IETFドキュメントシリーズ。
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.
憲章の一部として（付録Aを参照）、IABにはRFCエディターの責任があります。IETFと一般的なインターネットエンジニアリングおよび研究コミュニティの進化するニーズを認めて、IABは、インターネットを説明する技術研究およびエンジニアリングの文書にアーカイブシリーズを提供するという当初の任務を引き続き満たしているRFCシリーズの未来を見たいと考えています。
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シリーズのフレームワークとRFCエディター機能を提供し、RFCシリーズの目的と今日の現実と一致する方法でRFCシリーズが維持およびサポートされることを保証するという特定の目的を提供します。インターネット調査とエンジニアリングコミュニティ。フレームワークは、RFCの既存の「ストリーム」を説明し、既に実装を定義している既存のプロセスドキュメントのロードマップを描き、ディスカッションと将来のドキュメント改訂を通じてこのフレームワークとそのサポート作品を進化させる方法の明確な方向性を提供します。
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シリーズの簡単な憲章を提供し、RFCシリーズを管理するためのフレームワークにおけるRFCエディター、IAB、およびIETF管理サポートアクティビティ（IASA）の役割を説明し、入力の流れについて説明します。それが提供するさまざまな選挙区の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シリーズは、インターネットリサーチおよびエンジニアリングコミュニティからの一般的な貢献や標準文書など、インターネットの技術仕様の文書化に専念するアーカイブシリーズです。
RFCs are available free of charge to anyone via the Internet.
RFCは、インターネットを介して誰でも無料で利用できます。
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シリーズミッションをサポートするための改訂されたフレームワークを設定しているため、このセクションでは、ミッションの継続的なサポートに関与したエンティティの更新された役割と責任をレビューします。
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シリーズ（RFCエディター）の編集者として行動する一人の人がいました。タスクが成長しており、この作業には現在、複数の専門家の組織的な活動が必要であるため、RFCエディター、またはRFCエディター組織があります。やがて、RFCシリーズで必要な作業を引き受けるために、複数の組織が協力している場合があります。簡単にするために、そして彼らの間で役割がどのように細分化されるかを予測することなく、このドキュメントは、この専門家と組織のコレクションを「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エディターは、専門家の技術編集者およびシリーズエディターであり、RFCシリーズのミッションをサポートするために行動しています。そのため、RFCエディターは、定義されたプロセスに従って、RFCシリーズの編集管理を処理する実装者です。さらに、RFCエディターは、RFCSの編集、公開、アーカイブのポリシーに関する議論において、専門家であり、主要なムーバーになることが期待されています。
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シリーズミッションが作成されたコミュニティ全体に対して適切に満たされるようにすることです。IABは、組織的には、包括的な出版または編集の専門知識を持っていません。したがって、このドキュメントで提示されたIABの役割は、原則が満たされ、適切な機関とコミュニティが正式に通知され、相談されることを保証することに焦点を当てています。彼らの任務で。
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.
IABの責任は、RFCエディターの任命を承認し、RFCエディターがそれに続く一般的なポリシーを承認することです。
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 the IAB, the IASA is tasked with providing the funding for and operational oversight of the RFC Editor.
IETF管理サポートアクティビティ（BCP 101、[BCP101]）は、IETF、IAB、およびインターネットリサーチタスクフォース（IRTF）の管理サポートを提供するために作成されました。IABのサポートの役割において、IASAはRFCエディターの資金と運用上の監視を提供することを任されています。
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管理監視委員会）はIASAの監視委員会であり、IAD（IETF管理ディレクター）はIASAの主要なアクターです。
The IAOC works with the IAB to identify suitable persons or entities to fulfill the mandate of the RFC Editor.
IAOCはIABと協力して、適切な人物またはエンティティを特定して、RFCエディターの任務を果たします。
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.
BCP 101に従って、IAOCは、確立された契約に基づいてRFCエディターアクティビティの運用を監督します。
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エディターアクティビティがこのドキュメントで参照されているように編集管理とドキュメントの出版ニーズを満たすことを保証します。深刻な不適合が発生した場合、IABは、独自のイニシアチブまたはIAOCの要求に応じて、IAOCがRFCエディターアクティビティの取り決めを変更または終了および再交渉することを要求する場合があります。
With the RFC Series mission outlined above, this document describes a framework for supporting
上記で概説したRFCシリーズミッションで、このドキュメントはサポートのフレームワークについて説明しています
o the operational implementation of the RFC Series,
o RFCシリーズの運用実装、
based on
に基づく
o public process and definition documents,
o パブリックプロセスと定義ドキュメント、
for which there are
そこにあります
o clear responsibilities and mechanisms for update and change.
o 更新と変更のための明確な責任とメカニズム。
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エディターは、RFCシリーズの運用実装を担当しています。セクション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エディターは、適切なコミュニティと連携して、プロセス文書が現在の要件を反映していることを確認します。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つのカテゴリがあり、シリーズ全体のルールとガイドラインの4番目のカテゴリがあります。これは、そのミッションをサポートするためにRFCシリーズを実装するために説明されています。
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 シリーズのルールとガイドライン。
The RFC Series mission implicitly requires that documents be reviewed and approved for acceptance into the series.
RFCシリーズミッションは、ドキュメントをレビューし、シリーズへの受け入れのために承認することを暗黙的に要求しています。
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エディターに配置されたドキュメントのさまざまなストリームについて説明します。RFCSとしてのドキュメントの承認に関する一般的なポリシーがある場合がありますが（RFCシリーズの一貫性を確保するため）、各ストリームのドキュメントの承認のために定義されたポリシーもあります。一般的に言えば、各ストリームに異なる承認機関があります。現在の定義は、セクション5.1でカタログ化されています。
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エディターは、ストリームの1つ（独立した提出ストリーム、セクション5.1.4を参照）のドキュメントの承認を担当し、他の承認機関と協力して、承認されたドキュメントの次のフェーズへの円滑な通過、最終的には公開およびアーカイブを確保することを保証します。RFCとして。
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エディター、IAB、文書の特定のストリームの原因となる機関、またはコミュニティが、RFCの承認またはストリームごとの承認プロセスについて一般的に解決すべき問題があると判断した場合に発生する可能性があります。
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エディターおよび他の関係者と協力してコミュニティの入力を取得することであり、変更がコミュニティの要件を適切に説明することを確認することです。
The existing documents describing the approval processes for each stream are detailed in Section 5.1.
各ストリームの承認プロセスを説明する既存のドキュメントについては、セクション5.1で詳しく説明しています。
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エディターのドメインです。それにもかかわらず、RFCシリーズが提供するコミュニティとRFCの個々のストリームが提供するコミュニティには、シリーズの性質を定義するのに役立つ要件があります。
General and stream-specific requirements for the RFC Series are documented in community-approved documents (catalogued in Section 5.2 below).
RFCシリーズの一般的およびストリーム固有の要件は、コミュニティが承認したドキュメントに文書化されています（以下のセクション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エディター（契約、仕事の声明、サービスレベル契約など）の間の契約の対象です。
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.
RFCエディターは、RFCの編集、処理、および公開が、適切なドキュメントに記載されている要件と一致する方法で実行されることを保証する責任があります。RFCエディターはIASAと協力して、これらの操作に関する定期的なレポートとフィードバックを提供します。
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シリーズの要件を変更する必要がある場合があります。これは、RFCエディター、IAB、特定のドキュメントストリームの承認機関、またはコミュニティが、RFCまたはストリームごとの要件について一般的に解決すべき問題があると判断した場合に発生する可能性があります。
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エディターと協力してコミュニティの入力を取得することであり、コミュニティの要件の適切な検討を検証することで変更を承認することです。
Documents describing existing requirements for the streams are detailed in Section 5.2.
ストリームの既存の要件を説明するドキュメントについては、セクション5.2で詳しく説明しています。
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シリーズのアーカイブ、インデックス作成、およびアクセス可能なアクティビティは、一般的なドキュメントシリーズ編集の特定の主題の専門知識によって通知できます。また、コミュニティ全体からの要件によって通知されることも重要です。RFCシリーズがコヒーレントを維持する限り、すべてのストリームにわたってRFCの均一なアーカイブとインデックス作成と、結果のドキュメントにアクセスする一般的な方法があるはずです。
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シリーズのアーカイブ、インデックス、アクセシビリティ要件を説明するコミュニティコンセンサス文書があるはずです。実際には、シリーズの開始以来、有能な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エディター（例：契約、仕事の声明、サービスレベル契約など）の間の契約の対象です。
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アーカイブとインデックスが適切に維持され、結果のドキュメントがインターネットを介してアクセスしたい人が利用できるようにすることを担当します。RFCエディターは、定期的なレポートとフィードバックのためにIASAと連携します。
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エディターと協力してコミュニティの入力を取得し、コミュニティの要件を適切に検討することにより変更を承認します。
There are no applicable process documents.
該当するプロセスドキュメントはありません。
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シリーズのスタイルとコンテンツは、ドキュメントシリーズ編集の主題の専門知識によって形作られます。また、使用するコミュニティによって要件によって通知されます。RFCシリーズが一貫性を保つことである限り、すべてのストリームにわたってRFCに均一なスタイルとコンテンツがあるはずです。これには、受け入れられる言語、参照の使用、および著作権ルールが含まれますが、これらに限定されません。
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シリーズのコンテンツ要件を説明するコミュニティコンセンサス文書（または一連のドキュメント）があるはずです。実際には、いくつかは存在しますが、いくつかはレビューが必要であり、時間の経過とともにそれ以上が必要になる場合があります。
The RFC Editor is responsible for ensuring that the RFC Series guidelines are upheld within the RFC Series.
RFCエディターは、RFCシリーズのガイドラインがRFCシリーズ内で支持されることを保証する責任があります。
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エディターとストリームの利害関係者と連携して、コミュニティの入力とレビューを取得します。IABは、コミュニティの要件を適切に検討することにより、変更を承認します。
Existing series-wide rules and guidelines documents include:
既存のシリーズ全体のルールとガイドライン文書には次のものがあります。
o Instructions to RFC Authors (RFC 2223 [RFC2223], [RFC2223BIS])
o RFC著者への指示（RFC 2223 [RFC2223]、[RFC2223BIS]）
o Copyright and intellectual property rules (RFC 3978 [RFC3978] and RFC 4748 [RFC4748])
o 著作権および知的財産規則（RFC 3978 [RFC3978]およびRFC 4748 [RFC4748]）
o Normative references (RFC 3967 [RFC3967] and RFC 4897 [RFC4897])
o 規範的参照（RFC 3967 [RFC3967]およびRFC 4897 [RFC4897]）
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シリーズへの入力を提供します。これらの貢献者は、いくつかの異なるコミュニティから来ており、それぞれがRFCエディターによって公開されるドキュメントを承認するための独自の定義されたプロセスを備えています。これは新しいことではありません。ただし、時間の経過とともに、さまざまなコミュニティと文書の要件が増加し、分離されています。集団の要件について議論する際に調和を促進するために、それぞれを自分のスペースで認識することが有用であり、ここでは「ストリーム」と呼ばれます。
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.
以下のサブセクションでは、今日存在するストリームを特定しています。新しいストリームが作成されるという即時の期待はなく、新しいストリームを作成しないことが望ましいです。RFCシリーズの一般的な変更を取り巻くストリームとすべてのポリシーの作成については、セクション4で説明します。
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.
各ストリームのドキュメント（または要件）の承認のためのプロセスは、ストリームを定義するコミュニティによって定義されます。IABは、適切なコミュニティ入力が求められており、変更がRFCシリーズミッションとこの全体的なフレームワークと一致していることを確認する役割で告発されています。
The RFC Editor is expected to publish all documents passed to it after appropriate review and approval in one of the identified streams.
RFCエディターは、特定されたストリームの1つで適切なレビューと承認の後、渡されたすべてのドキュメントを公開することが期待されています。
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ドキュメントストリームには、IETF WGドキュメントと、IESGエリアディレクターが後援する「個別提出」が含まれています。IETF標準プロセスの一部として公開されているドキュメントは、このストリームに従う必要があります。他のストリームは、標準トラックまたは最良の現在のプラクティス（BCP）RFCを承認することはできません。
Approval of documents in the IETF stream is defined by
IETFストリームでのドキュメントの承認は、
o the IETF standards process (RFC 2026 [RFC2026] and its successors).
o IETF標準プロセス（RFC 2026 [RFC2026]およびその後継者）。
o the IESG process for sponsoring individual submissions [SPONSOR]).
o 個々の提出物をスポンサーするためのIESGプロセス[スポンサー]）。
Changes to the approval process for this stream are made by updating the IETF standards process documents.
このストリームの承認プロセスの変更は、IETF標準プロセスドキュメントを更新することにより行われます。
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標準トラック（標準または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プロセス（RFC 4845 [RFC4845]）。
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の活動としてチャーターされています。IABの承認を得て、IRTFは、独自の非EITF標準トラックのドキュメントの公開プロセスを公開および更新できます。
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]。
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シリーズは、常に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エディターの範囲内にあり、RFCエディターはIESGからのレビューへの入力を求めています。
The process for reviewing and approving documents in the Independent Submission stream is defined by
独立した提出ストリームでドキュメントを確認および承認するプロセスは、
o Independent Submissions to the RFC Editor (RFC 4846 [RFC4846]).
o RFCエディターへの独立した提出（RFC 4846 [RFC4846]）。
o The IESG and RFC Editor Documents: Procedures (RFC 3932 [RFC3932]).
o IESGおよびRFCエディタードキュメント：手順（RFC 3932 [RFC3932]）。
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には、IETFストリームと同じIANA割り当てと同じ相互依存関係がありません。したがって、各ストリームの公開要件を成文化する必要性と、合理的な範囲でそれらを調和させるために努力する必要があります。
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エディターの監視の一環として、IABは、要件がRFCエディターアクティビティの一部として一致し、実装可能であることに同意する必要があります。
The requirements for this stream are defined in RFC 4714 [RFC4714].
このストリームの要件は、RFC 4714 [RFC4714]で定義されています。
Although they were developed for the IETF standards process, the IAB will identify the applicable requirements in RFC 4714 for its stream.
IETF標準プロセス用に開発されましたが、IABはそのストリームについてRFC 4714の該当する要件を特定します。
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つの技術的出版社によって合理的に管理されている集合的な技術的出版要件を維持するため）。
Although they were developed for the IETF standards process, the IRTF will identify the applicable requirements in RFC 4714 for its stream.
これらはIETF標準プロセスのために開発されましたが、IRTFはそのストリームについてRFC 4714の該当する要件を特定します。
If the IRTF 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).
IRTFが他の要件を定義することを選択した場合、それらはそれらから最小限に逸脱する必要があります（1つの技術出版社によって合理的に管理されている集合的な技術的出版要件を維持するため）。
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エディターは、そのストリームについてRFC 4714の該当する要件を特定します。
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エディターが他の要件を定義することを選択した場合、それらはそれらから最小限に逸脱する必要があります（1つの技術的出版社によって合理的に管理されている集合的な技術的出版要件を維持するため）。
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エディターは出版物のインデックスを維持しているため、これらの公開されたドキュメントが外部関係者によって変更されるのを防ぐために十分なセキュリティを整える必要があります。RFCドキュメントのアーカイブ、RFCドキュメントを再作成するために必要なソースドキュメント、および関連する元のドキュメント（ERRATA、ツール、および一部の初期項目の場合、非マシン読み取り可能なオリジナルなど）は、失敗に対して確保する必要があります。ストレージ媒体およびその他の同様の災害。
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
バーナード・アボバ・ロア・アンダーソン・ブライアン・カーペンター・レスリー・デイグル・エルウィン・デイヴィス・ケビン・フォール・フォール・オラフ・コルクマン・カルティス・リンドクヴィスト
[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）の構造」、RFC 4071、BCP 101、2005年4月。
[IABCHARTER] Carpenter, B., "Charter of the Internet Architecture Board (IAB)", RFC 2850, May 2000.
[Iabcharter] Carpenter、B。、「インターネットアーキテクチャボードのチャーター（IAB）」、RFC 2850、2000年5月。
[IRTF-DOCS] Falk, A., "IRTF Research Group RFCs", Work in Progress, February 2006.
[IRTF-DOCS] Falk、A。、「IRTF Research Group RFCS」、2006年2月、進行中の作業。
[RFC1358] Chapin, L., "Charter of the Internet Architecture Board (IAB)", RFC 1358, August 1992.
[RFC1358]チャピン、L。、「インターネットアーキテクチャボードのチャーター（IAB）」、RFC 1358、1992年8月。
[RFC1601] Huitema, C., "Charter of the Internet Architecture Board (IAB)", RFC 1601, March 1994.
[RFC1601] Huitema、C。、「インターネットアーキテクチャボードのチャーター（IAB）」、RFC 1601、1994年3月。
[RFC2026] Bradner, S., Ed., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996.
[RFC2026] Bradner、S.、ed。、「The Internet Standards Process- Revision 3」、RFC 2026、1996年10月。
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC2223] Postel、J。およびJ. Reynolds、「RFC著者への指示」、RFC 2223、1997年10月。
[RFC2223BIS] Reynolds, J., Ed. and R. Braden, Ed., "Instructions to Request for Comments (RFC) Authors", Work in Progress, August 2004.
[RFC2223BIS]レイノルズ、J。、編and R. Braden、ed。、「コメント要求の指示（RFC）著者」、2004年8月、Progress In Progress。
[RFC2555] Editor, RFC., "30 Years of RFCs", RFC 2555, April 1999.
[RFC2555]編集者、RFC。、「30年のRFCS」、RFC 2555、1999年4月。
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", RFC 3932, October 2004.
[RFC3932] Alvestrand、H。、「IESGおよびRFCエディタードキュメント：手順」、RFC 3932、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] Bush、R。およびT. Narten、「標準トラックドキュメントが下位レベルのドキュメントに規範を参照する可能性があることを明確にする」、RFC 3967、2004年12月。
[RFC3978] Bradner, S., Ed., "IETF Rights in Contributions", RFC 3978, March 2005.
[RFC3978] Bradner、S.、ed。、「貢献におけるIETFの権利」、RFC 3978、2005年3月。
[RFC4693] Alvestrand, H., "IETF Operational Notes", RFC 4693, October 2006.
[RFC4693] Alvestrand、H。、「IETF運用ノート」、RFC 4693、2006年10月。
[RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF Technical Publication Service", RFC 4714, October 2006.
[RFC4714] Mankin、A。およびS. Hayes、「IETF技術出版サービスの要件」、RFC 4714、2006年10月。
[RFC4748] Bradner, S., Ed., "RFC 3978 Update to Recognize the IETF Trust", RFC 4748, October 2006.
[RFC4748] Bradner、S.、ed。、「RFC 3978 IETF Trustの認識への更新」、RFC 4748、2006年10月。
[RFC4845] Daigle, L., "Process for Publication of IAB RFCs", RFC 4845, July 2007.
[RFC4845] Daigle、L。、「IAB RFCSの公開のためのプロセス」、RFC 4845、2007年7月。
[RFC4846] Klensin, J. and D. Thaler, "Independent Submissions to the RFC Editor", RFC 4846, July 2007.
[RFC4846] Klensin、J。およびD. Thaler、「RFCエディターへの独立した提出」、RFC 4846、2007年7月。
[RFC4897] Klensin, J., "Handling Normative References to Standards Track Documents", BCP 97, RFC 4897, June 2007.
[RFC4897] Klensin、J。、「標準への規範的参照の処理文書」、BCP 97、RFC 4897、2007年6月。
[SPONSOR] Arkko, J., "Guidance on Area Director Sponsoring of Documents", ION, October 2006.
[スポンサー] Arkko、J。、「ドキュメントのスポンサーのエリアディレクターに関するガイダンス」、Ion、2006年10月。
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シリーズとRFCエディターに関するIABの役割は、RFCエディターとより直接作業し、RFCシリーズミッションの原則とコミュニティの入力が適切に対処されるように監視を提供するように調整されています。
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エディターに関するIABの役割の概要を説明します。このセクションのポイントは、IABの役割が歴史的に実質的であったことです。RFCシリーズの編集管理（1992年頃、付録A.1）、またはRFCエディター組織の任命と一般ポリシーの承認（2000年頃、付録A.3）に直接責任を負うはずです。
[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の]責任には以下が含まれます。コミュニティ。
[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.
IABは、コメント要求（RFC）ドキュメントシリーズの編集管理と公開、およびさまざまなインターネットに割り当てられた番号の管理を担当しています。
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シリーズは、インターネット標準とインターネットリサーチおよびエンジニアリングコミュニティによるその他の貢献のためのアーカイブ出版チャネルを構成しています。IABは、RFCシリーズの編集管理と公開を担当するRFCエディターを選択するものとします。
[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エディターは、IETF「コメントのリクエスト」（RFC）ドキュメントシリーズの編集管理と公開を実行します。これは、IETFの永続的なドキュメントリポジトリです。RFCシリーズは、インターネット標準とインターネットリサーチおよびエンジニアリングコミュニティによるその他の貢献のためのアーカイブ出版チャネルを構成しています。RFCは、インターネットを介して誰でも無料で利用できます。IABは、RFCエディターとして行動するために組織の任命を承認し、それに続くRFCエディターがそれに続く必要があります。
Authors' Addresses
著者のアドレス
Leslie L. Daigle (editor)
レスリーL.デイグル（編集者）
EMail: ledaigle@cisco.com, leslie@thinkingcat.com
IAB
iab
EMail: iab@iab.org
URI: http://www.iab.org/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。