[要約] RFC 9280はRFC Editor Modelの第3版を定めており、RFCシリーズに関連する2つの主要なタスクを定義しています。その目的は、ポリシーの定義と実装を効果的に管理することです。
Internet Architecture Board (IAB) P. Saint-Andre, Ed.
Request for Comments: 9280 June 2022
Obsoletes: 8728
Updates: 7841, 8729, 8730
Category: Informational
ISSN: 2070-1721
RFC Editor Model (Version 3)
RFCエディターモデル（バージョン3）
Abstract
概要
This document specifies version 3 of the RFC Editor Model. The model defines two high-level tasks related to the RFC Series. First, policy definition is the joint responsibility of the RFC Series Working Group (RSWG), which produces policy proposals, and the RFC Series Approval Board (RSAB), which approves such proposals. Second, policy implementation is primarily the responsibility of the RFC Production Center (RPC) as contractually overseen by the IETF Administration Limited Liability Company (IETF LLC). In addition, various responsibilities of the RFC Editor function are now performed alone or in combination by the RSWG, RSAB, RPC, RFC Series Consulting Editor (RSCE), and IETF LLC. Finally, this document establishes the Editorial Stream for publication of future policy definition documents produced through the processes defined herein.
このドキュメントは、RFCエディターモデルのバージョン3を指定します。このモデルは、RFCシリーズに関連する2つの高レベルのタスクを定義します。まず、ポリシーの定義は、ポリシー提案を作成するRFCシリーズワーキンググループ（RSWG）の共同責任と、そのような提案を承認するRFCシリーズ承認委員会（RSAB）です。第二に、政策の実施は、主にIETF Administration Limited Liability Company（IETF LLC）によって契約上監督されているRFC生産センター（RPC）の責任です。さらに、RWC、RSAB、RPC、RFCシリーズコンサルティングエディター（RSCE）、およびIETF LLCによって単独または組み合わせて、RFCエディター関数のさまざまな責任が単独で実行されています。最後に、このドキュメントは、本明細書で定義されているプロセスを通じて作成された将来のポリシー定義文書を公開するための編集ストリームを確立します。
This document obsoletes RFC 8728. This document updates RFCs 7841, 8729, and 8730.
このドキュメントはRFC8728を廃止します。このドキュメントは、RFCS 7841、8729、および8730を更新します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供する価値があるとみなした情報を表しています。インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。IABによって公開されることが承認された文書は、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9280.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9280で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction
2. Overview of the Model
3. Policy Definition
3.1. Structure and Roles
3.1.1. RFC Series Working Group (RSWG)
3.1.2. RFC Series Approval Board (RSAB)
3.2. Process
3.2.1. Intent
3.2.2. Workflow
3.2.3. Community Calls for Comment
3.2.4. Appeals
3.2.5. Anti-Harassment Policy
3.2.6. RFC Boilerplates
4. Policy Implementation
4.1. Roles and Processes
4.2. Working Practices
4.3. RPC Responsibilities
4.4. Resolution of Disagreements between Authors and the RPC
4.5. Point of Contact
4.6. Administrative Implementation
4.6.1. Vendor Selection for the RPC
4.6.2. Budget
5. RFC Series Consulting Editor (RSCE)
5.1. RSCE Selection
5.2. RSCE Performance Evaluation
5.3. Temporary RSCE Appointment
5.4. Conflict of Interest
6. Editorial Stream
6.1. Procedures Request of the IETF Trust
6.2. Patent and Trademark Rules for the Editorial Stream
6.3. Editorial Stream Boilerplate
7. Historical Properties of the RFC Series
7.1. Availability
7.2. Accessibility
7.3. Language
7.4. Diversity
7.5. Quality
7.6. Stability
7.7. Longevity
8. Updates to This Document
9. Changes from Version 2 of the RFC Editor Model
9.1. RFC Editor Function
9.2. RFC Series Editor
9.3. RFC Publisher
9.4. IAB
9.5. RFC Series Oversight Committee (RSOC)
9.6. RFC Series Advisory Group (RSAG)
9.7. Editorial Stream
10. Security Considerations
11. IANA Considerations
12. References
12.1. Normative References
12.2. Informative References
IAB Members at the Time of Approval
Acknowledgments
Author's Address
The Request for Comments (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. RFCs are available free of charge to anyone via the Internet. As described in [RFC8700], RFCs have been published continually since 1969.
コメントのリクエスト（RFC）シリーズは、インターネット調査およびエンジニアリングコミュニティからの一般的な貢献や標準文書など、インターネットの技術仕様を文書化することに専念するアーカイブシリーズです。RFCは、インターネットを介して誰でも無料で利用できます。[RFC8700]で説明されているように、RFCは1969年以来継続的に公開されています。
RFCs are generated and approved by multiple document streams. Whereas the stream approving body [RFC8729] for each stream is responsible for the content of that stream, the RFC Editor function is responsible for the production and distribution of all RFCs. The four existing streams are described in [RFC8729]. This document adds a fifth stream, the Editorial Stream, for publication of policies governing the RFC Series as a whole.
RFCは、複数のドキュメントストリームによって生成および承認されます。各ストリームのストリーム承認機関[RFC8729]はそのストリームのコンテンツの原因ですが、RFCエディター機能はすべてのRFCの生産と分布を担当します。4つの既存のストリームは[RFC8729]で説明されています。このドキュメントには、RFCシリーズ全体を管理するポリシーを公開するための5番目のストリーム、編集ストリームが追加されています。
The overall framework for the RFC Series and the RFC Editor function is described in [RFC8729] and is updated by this document, which defines version 3 of the RFC Editor Model. Under this version, various responsibilities of the RFC Editor function are performed alone or in combination by the RFC Series Working Group (RSWG), RFC Series Advisory Board (RSAB), RFC Production Center (RPC), RFC Series Consulting Editor (RSCE), and IETF Administration Limited Liability Company (IETF LLC) [RFC8711], which collectively comprise the RFC Editor function. The intent is to ensure sustainable maintenance and support of the RFC Series based on the principles of expert implementation, clear management and direction, and appropriate community input [RFC8729].
RFCシリーズとRFCエディター関数の全体的なフレームワークは[RFC8729]で説明されており、RFCエディターモデルのバージョン3を定義するこのドキュメントで更新されます。このバージョンでは、RFCエディター関数のさまざまな責任は、RFCシリーズワーキンググループ（RSWG）、RFCシリーズアドバイザリーボード（RSAB）、RFCプロダクションセンター（RPC）、RFCシリーズコンサルティングエディター（RSCE）によって単独または組み合わせて実行されます。IETF Administration Limited Liability Company（IETF LLC）[RFC8711]。これは、RFCエディター機能を集合的に構成しています。目的は、専門家の実装、明確な管理と方向、適切なコミュニティ入力の原則に基づいて、RFCシリーズの持続可能なメンテナンスとサポートを確保することです[RFC8729]。
This document obsoletes [RFC8728] by defining version 3 of the RFC Editor Model. This document updates [RFC7841] by defining boilerplate text for the Editorial Stream. This document updates [RFC8729] by replacing the RFC Editor role with the RSWG, RSAB, and RSCE. This document updates [RFC8730] by removing the dependency on certain policies specified by the IAB and RFC Series Editor (RSE). More detailed information about changes from version 2 of the RFC Editor Model can be found in Section 9.
このドキュメントは、RFCエディターモデルのバージョン3を定義することにより、[RFC8728]を廃止します。このドキュメントは、編集ストリームのボイラープレートテキストを定義することにより、[RFC7841]を更新します。このドキュメントは、RFCエディターの役割をRSWG、RSAB、およびRSCEに置き換えることにより、[RFC8729]を更新します。このドキュメントは、IABおよびRFCシリーズエディター（RSE）によって指定された特定のポリシーへの依存関係を削除することにより、[RFC8730]を更新します。RFCエディターモデルのバージョン2からの変更に関する詳細情報は、セクション9にあります。
This document divides the responsibilities for the RFC Series into two high-level tasks:
このドキュメントは、RFCシリーズの責任を2つの高レベルのタスクに分割します。
1. Policy definition governing the RFC Series as a whole. This is the joint responsibility of two entities. First, the RFC Series Working Group (RSWG) is an open working group independent of the IETF that generates policy proposals. Second, the RFC Series Approval Board (RSAB) is an appointed body that approves such proposals for publication in the Editorial Stream. The RSAB includes representatives of the streams [RFC8729] as well as an expert in technical publishing, the RFC Series Consulting Editor (RSCE).
1. RFCシリーズ全体を管理するポリシー定義。これは、2つのエンティティの共同責任です。まず、RFCシリーズワーキンググループ（RSWG）は、ポリシー提案を生成するIETFとは無関係にオープンワーキンググループです。第二に、RFCシリーズ承認委員会（RSAB）は、編集ストリームに掲載するためのそのような提案を承認する任命された機関です。RSABには、ストリーム[RFC8729]の代表者と、RFCシリーズコンサルティングエディター（RSCE）の専門家が含まれています。
2. Policy implementation through publication of RFCs in all of the streams that form the RFC Series. This is primarily the responsibility of the RFC Production Center (RPC) as contractually overseen by the IETF Administration Limited Liability Company (IETF LLC) [RFC8711].
2. RFCシリーズを形成するすべてのストリームでのRFCの公開によるポリシーの実装。これは主に、IETF Administration Limited Liability Company（IETF LLC）[RFC8711]によって契約上監督されたRFC生産センター（RPC）の責任です。
As described more fully in the remainder of this document, the core activities and responsibilities are as follows:
この文書の残りの部分でより完全に説明されているように、コアの活動と責任は次のとおりです。
* The RSWG proposes policies that govern the RFC Series as a whole, with input from the community, the RSAB, and the RSCE.
* RSWGは、コミュニティ、RSAB、およびRSCEからの意見で、RFCシリーズ全体を支配するポリシーを提案しています。
* The RSAB considers those proposals and either approves them or returns them to the RSWG, which may make further changes or remove them from further consideration.
* RSABはこれらの提案を考慮し、それらを承認するか、RSWGに返送します。
* If approved, such proposals are published as RFCs in the Editorial Stream and thus define the policies to be followed by the RSWG, RSAB, RSCE, and RPC.
* 承認された場合、そのような提案は編集ストリームのRFCとして公開されているため、RSWG、RSAB、RSCE、およびRPCが従うべきポリシーを定義します。
* The RSCE provides expert advice to the RPC and RSAB on how to implement established policies on an ongoing and operational basis, which can include raising issues or initiating proposed policy changes within the RSWG.
* RSCEは、RPCとRSABに、継続的かつ運用上の確立されたポリシーを実装する方法について専門家にアドバイスを提供します。これには、RSWG内で問題を提起したり、提案されたポリシー変更を開始したりできます。
* The RPC implements the policies defined by the Editorial Stream in its day-to-day editing and publication of RFCs from all of the streams.
* RPCは、すべてのストリームからのRFCの日々の編集と公開で編集ストリームによって定義されたポリシーを実装しています。
* If issues arise with the implementation of particular policies, the RPC brings those issues to the RSAB, which interprets the policies and provides interim guidance to the RPC, informing the RSWG of those interpretations.
* 特定のポリシーの実装で問題が発生した場合、RPCはこれらの問題をRSABにもたらし、ポリシーを解釈し、RPCに暫定ガイダンスを提供し、RSWGにそれらの解釈を通知します。
This model is designed to ensure public processes and policy documents, clear lines of responsibility and authority, transparent mechanisms for updates and changes to policies governing the RFC Series as a whole, and effective operational implementation of the RFC Series, thus meeting the requirements specified in Section 4 of [RFC8729].
このモデルは、パブリックプロセスとポリシー文書、責任と権限の明確なライン、RFCシリーズ全体を管理するポリシーの更新と変更のための透明なメカニズム、およびRFCシリーズの効果的な運用実装を確保するように設計されています。[RFC8729]のセクション4。
The remainder of this document describes the model in greater detail.
このドキュメントの残りの部分では、モデルをより詳細に説明しています。
Policies governing the RFC Series as a whole are defined through the following high-level process:
RFCシリーズ全体を管理するポリシー全体は、次の高レベルプロセスを通じて定義されています。
1. Proposals must be submitted to, adopted by, and discussed within the RFC Series Working Group (RSWG).
1. 提案は、RFCシリーズワーキンググループ（RSWG）に提出され、採用され、議論される必要があります。
2. Proposals must pass a Last Call for comments in the working group and a community call for comments (see Section 3.2.3).
2. 提案は、ワーキンググループでのコメントの最後のコメントとコメントの呼び出しを渡す必要があります（セクション3.2.3を参照）。
3. Proposals must be approved by the RFC Series Approval Board (RSAB).
3. 提案は、RFCシリーズ承認委員会（RSAB）によって承認されなければなりません。
Policies under the purview of the RSWG and RSAB might include, but are not limited to, document formats, processes for publication and dissemination of RFCs, and overall management of the RFC Series.
RSWGおよびRSABの範囲に基づくポリシーには、ドキュメント形式、RFCの公開および普及のためのプロセス、およびRFCシリーズの全体的な管理が含まれる場合がありますが、これらに限定されません。
The RFC Series Working Group (RSWG) is the primary venue in which members of the community collaborate regarding the policies that govern the RFC Series.
RFCシリーズワーキンググループ（RSWG）は、RFCシリーズを支配するポリシーに関してコミュニティのメンバーが協力する主要な会場です。
All interested individuals are welcome to participate in the RSWG; participants are subject to anti-harassment policies as described in Section 3.2.5. This includes but is not limited to participants in the IETF and IRTF, members of the IAB and IESG, developers of software or hardware systems that implement RFCs, authors of RFCs and Internet-Drafts, developers of tools used to author or edit RFCs and Internet-Drafts, individuals who use RFCs in procurement decisions, scholarly researchers, and representatives of standards development organizations other than the IETF and IRTF. The IETF LLC Board members, staff and contractors (especially representatives of the RFC Production Center), and the IETF Executive Director are invited to participate as community members in the RSWG to the extent permitted by any relevant IETF LLC policies. Members of the RSAB are also expected to participate actively.
関心のあるすべての人は、RSWGに参加することを歓迎します。参加者は、セクション3.2.5で説明されているように、ハラスメント防止ポリシーの対象となります。これには、IETFとIRTFの参加者、IABおよびIESGのメンバー、RFCS、RFCSおよびInternet-Draftsの著者、RFCSおよびインターネットの編集に使用されるツールの開発者を実装するソフトウェアまたはハードウェアシステムの開発者、IESGのメンバーの参加者が含まれますが、これらに限定されません。-Drafts、調達決定でRFCを使用する個人、学術研究者、およびIETFおよびIRTF以外の標準開発組織の代表者。IETF LLCの理事会メンバー、スタッフおよび請負業者（特にRFC生産センターの代表）、およびIETFエグゼクティブディレクターは、関連するIETF LLCポリシーで許可されている範囲でRSWGのコミュニティメンバーとして参加するよう招待されています。RSABのメンバーも積極的に参加することが期待されています。
The RSWG shall have two chairs, one appointed by the IESG and the other appointed by the IAB. When the RSWG is formed, the chair appointed by the IESG shall serve for a term of one (1) year and the chair appointed by the IAB shall serve for a term of two (2) years; thereafter, chairs shall serve for a term of two (2) years, with no term limits on renewal. The IESG and IAB shall determine their own processes for making these appointments, making sure to take account of any potential conflicts of interest. Community members who have concerns about the performance of an RSWG Chair should direct their feedback to the appropriate appointing body via mechanisms such bodies shall specify at the time that the RSWG is formed. The IESG and IAB shall have the power to remove their appointed chairs at their discretion at any time and to name a replacement who shall serve the remainder of the original chair's term.
RSWGには2つの椅子があり、1つはIESGによって任命され、もう1つはIABによって任命されます。RSWGが形成されると、IESGによって任命された椅子は1年間の任期を務め、IABによって任命された椅子は2年間任命されます。その後、椅子は2年間、更新の期間制限はありません。IESGとIABは、これらの任命を行うための独自のプロセスを決定し、潜在的な利益相反を考慮してください。RSWG椅子のパフォーマンスについて懸念を抱いているコミュニティメンバーは、そのような機関がRSWGが形成された時点で指定するメカニズムを介して適切な任命機関にフィードバックを向ける必要があります。IESGとIABは、任命された椅子をいつでも裁量で削除し、元の椅子の任期の残りを務める代替品に名前を付ける権限を持っているものとします。
It is the responsibility of the chairs to encourage rough consensus within the RSWG and to follow that consensus in their decision making, for instance, regarding acceptance of new proposals and advancement of proposals to the RSAB.
RSWG内の大まかなコンセンサスを奨励し、たとえば新しい提案の受け入れやRSABへの提案の進歩に関する意思決定におけるそのコンセンサスに従うことは椅子の責任です。
The intent is that the RSWG shall operate in a way similar to that of working groups in the IETF. Therefore, all RSWG meetings and discussion venues shall be open to all interested individuals, and all RSWG contributions shall be subject to intellectual property policies, which must be consistent with those of the IETF as specified in [BCP78] and [BCP79].
意図は、RSWGがIETFのワーキンググループと同様の方法で動作することです。したがって、すべてのRSWG会議とディスカッション会場は、関心のあるすべての個人に開かれ、すべてのRSWGの貢献は、[BCP78]および[BCP79]で指定されているIETFのものと一致する必要がある知的財産ポリシーの対象となります。
When the RSWG is formed, all discussions shall take place on an open email discussion list, which shall be publicly archived.
RSWGが形成されると、すべてのディスカッションは、公開されたメールディスカッションリストで行われ、公開されます。
The RSWG is empowered to hold in-person, online-only, or hybrid meetings, which should be announced with sufficient notice to enable broad participation; the IESG Guidance on Face-to-Face and Virtual Interim Meetings (https://www.ietf.org/about/groups/iesg/statements/ interim-meetings-guidance-2016-01-16/) provides a reasonable baseline. In-person meetings should include provision for effective online participation for those unable to attend in person.
RSWGは、対面、オンラインのみ、またはハイブリッド会議を開催する権限を与えられています。これは、幅広い参加を可能にするための十分な通知で発表されるべきです。対面および仮想暫定会議に関するIESGガイダンス（https://www.ietf.org/about/groups/isg/statements/ Interim-Meetings-guidance-2016-01-16/）は、合理的なベースラインを提供します。対面会議には、直接参加できない人のための効果的なオンライン参加の提供を含める必要があります。
The RSWG shall operate by rough consensus, a mode of operation informally described in [RFC2418].
RSWGは、[RFC2418]で非公式に説明されている操作のモードである大まかなコンセンサスによって動作するものとします。
The RSWG may decide by rough consensus to use additional tooling (e.g., GitHub as specified in [RFC8874]), forms of communication, and working methods (e.g., design teams) as long as they are consistent with this document and with [RFC2418] or its successors.
RSWGは、大まかなコンセンサスで、このドキュメントと[RFC2418]と一致している限り、追加のツール（[RFC8874]で指定されているGitHub）、コミュニケーションの形式、および作業方法（デザインチーム）を使用することを決定する場合があります。またはその後継者。
Absent specific guidance in this document regarding the operation of the RSWG, the general guidance provided in Section 6 of [RFC2418] should be considered appropriate.
RSWGの操作に関するこのドキュメントには具体的なガイダンスがないため、[RFC2418]のセクション6で規定されている一般的なガイダンスは適切と見なされるべきです。
The IETF LLC is requested to provide necessary tooling to support RSWG communication, decision processes, and policies.
IETF LLCは、RSWGのコミュニケーション、決定プロセス、およびポリシーをサポートするために必要なツールを提供するように要求されています。
The IAB is requested to convene the RSWG when it is first formed in order to formalize the IAB's transfer of authority over the RFC Editor Model.
IABは、RSWGがRFCエディターモデルを介した権限の移転を正式化するために、RSWGを最初に形成するときに招集するように要求されます。
The RFC Series Approval Board (RSAB), which includes representatives of all of the streams, shall act as the approving body for proposals generated within the RSWG, thus providing an appropriate set of checks and balances on the output of the RSWG. The only policy-making role of the RSAB is to review policy proposals generated by the RSWG; it shall have no independent authority to formulate policy on its own. It is expected that the RSAB will respect the rough consensus of the RSWG wherever possible, without ceding its responsibility to review RSWG proposals, as further described in Section 3.2.2.
すべてのストリームの代表者を含むRFCシリーズ承認委員会（RSAB）は、RSWG内で生成された提案の承認機関として機能するため、RSWGの出力に関する適切なチェックとバランスのセットを提供します。RSABの唯一の政策決定の役割は、RSWGによって生成されたポリシー提案を確認することです。それは、それ自体で政策を策定する独立した権限を持たないものとします。RSABは、セクション3.2.2でさらに説明されているように、RSWGの提案をレビューする責任を負うことなく、可能な限りRSWGの大まかなコンセンサスを尊重することが期待されています。
The RSAB consists primarily of the following voting members:
RSABは、主に次の投票メンバーで構成されています。
* A stream representative for the IETF Stream: either an IESG member or someone appointed by the IESG
* IETFストリームのストリーム代表者：IESGメンバーまたはIESGによって任命された誰かのいずれか
* A stream representative for the IAB Stream: either an IAB member or someone appointed by the IAB
* IABストリームのストリーム代表者：IABメンバーまたはIABによって任命された誰かのいずれか
* A stream representative for the IRTF Stream: either the IRTF Chair or someone appointed by the IRTF Chair
* IRTFストリームのストリーム代表：IRTF椅子またはIRTF椅子によって任命された誰かのいずれか
* A stream representative for the Independent Stream: either the Independent Submissions Editor (ISE) [RFC8730] or someone appointed by the ISE
* 独立ストリームのストリーム代表：独立した提出エディター（ISE）[RFC8730]またはISEによって任命された誰かのいずれか
* The RFC Series Consulting Editor (RSCE)
* RFCシリーズコンサルティングエディター（RSCE）
If and when a new stream is created, the document that creates the stream shall specify if a voting member representing that stream shall also be added to the RSAB, along with any rules and processes related to that representative (e.g., whether the representative is a member of the body responsible for the stream or an appointed delegate thereof).
新しいストリームが作成された場合、ストリームを作成するドキュメントは、そのストリームを表す投票メンバーがRSABにも追加されるかどうかを指定するものとします。ストリームまたはその任命された代表者の責任者団体のメンバー）。
The RFC Series Consulting Editor (RSCE) is a voting member of the RSAB but does not act as a representative of the Editorial Stream.
RFCシリーズコンサルティングエディター（RSCE）は、RSABの投票メンバーですが、編集ストリームの代表としては機能しません。
To ensure the smooth operation of the RFC Series, the RSAB shall include the following non-voting, ex officio members:
RFCシリーズのスムーズな動作を確保するために、RSABには次の非投票、Ex Officioメンバーが含まれます。
* The IETF Executive Director or their delegate (the rationale is that the IETF LLC is accountable for implementation of policies governing the RFC Series)
* IETFエグゼクティブディレクターまたはその代表者（IETF LLCはRFCシリーズを管理するポリシーの実施に責任があるという理論的根拠です）
* A representative of the RPC, named by the RPC (the rationale is that the RPC is responsible for implementation of policies governing the RFC Series)
* RPCによって名付けられたRPCの代表者（RPCがRFCシリーズを管理するポリシーの実装に責任があるという理由）
In addition, the RSAB may include other non-voting members at its discretion; these non-voting members may be ex officio members or liaisons from groups or organizations with which the RSAB deems it necessary to formally collaborate or coordinate.
さらに、RSABには、その裁量で他の非投票メンバーが含まれる場合があります。これらの非投票メンバーは、RSABが正式に協力または調整する必要があると考えるグループまたは組織からの職員または連絡先である場合があります。
The appointing bodies (i.e., IESG, IAB, IRTF Chair, and ISE) shall determine their own processes for appointing RSAB members (note that processes related to the RSCE are described in Section 5). Each appointing body shall have the power to remove its appointed RSAB member at its discretion at any time. Appointing bodies should ensure that voting members are seated at all times and should fill any vacancies with all due speed, if necessary on a temporary basis.
任命団体（つまり、IESG、IAB、IRTF議長、ISE）は、RSABメンバーを任命するための独自のプロセスを決定するものとします（RSCEに関連するプロセスはセクション5で説明されていることに注意してください）。各任命機関は、いつでも任命されたRSABメンバーをその裁量で削除する権限を持っているものとします。任命団体は、投票メンバーが常に座っていることを保証し、必要に応じて一時的に必要に応じて、すべての期限の速度で空席を埋める必要があります。
In the case that the IRTF Chair or ISE is incapacitated or otherwise unable to appoint another person to serve as a delegate, the IAB (as the appointing body for the IRTF Chair and ISE) shall act as the temporary appointing body for those streams and shall appoint a temporary member of the RSAB until the IAB has appointed an IRTF Chair or ISE, who can then act as an RSAB member or appoint a delegate through normal processes.
IRTFの椅子またはISEが代表者として役立つように他の人を任命することができない場合、またはそうでなければIAB（IRTF椅子およびISEの任命機関として）は、それらのストリームの一時的な任命機関として行動するものとし、IABがIRTFの椅子またはISEを任命するまで、RSABの一時的なメンバーを任命します。
In the case of vacancies by voting members, the RSAB shall operate as follows:
投票メンバーによる空席の場合、RSABは次のように動作するものとします。
* Activities related to implementation of policies already in force shall continue as normal.
* すでに有効なポリシーの実装に関連する活動は、通常どおり継続するものとします。
* Voting on approval of policy documents produced by the RSWG shall be delayed until the vacancy or vacancies have been filled, up to a maximum of three (3) months. If a further vacancy arises during this three-month period, the delay should be extended by up to another three months. After the delay period expires, the RSAB should continue to process documents as described below. Note that this method of handling vacancies does not apply to a vacancy of the RSCE role; it only applies to vacancies of the stream representatives enumerated in Section 3.1.2.2.
* RSWGによって作成されたポリシー文書の承認に投票することは、最大3か月まで、空室または空室が満たされるまで遅延するものとします。この3か月間にさらに空室が発生した場合、遅延はさらに3か月まで延長する必要があります。遅延期間が切れた後、RSABは以下で説明するようにドキュメントを処理し続ける必要があります。空室を処理するこの方法は、RSCEの役割の空室には適用されないことに注意してください。セクション3.1.2.2で列挙されたストリーム代表者の空室にのみ適用されます。
The RSAB shall annually choose a chair from among its members using a method of its choosing. If the chair position is vacated during the chair's term, the RSAB chooses a new chair from among its members.
RSABは、選択方法を使用して、メンバーの中から毎年椅子を選択するものとします。椅子の任期中に椅子の位置が空いた場合、RSABはメンバーの中から新しい椅子を選択します。
The RSAB is expected to operate via an email discussion list, in-person meetings, teleconferencing systems, and any additional tooling it deems necessary.
RSABは、電子メールディスカッションリスト、対面会議、通信システム、および必要と思われる追加のツールを介して運用されることが期待されています。
The RSAB shall keep a public record of its proceedings, including minutes of all meetings and a record of all decisions. The primary email discussion list used by the RSAB shall be publicly archived, although topics that require confidentiality (e.g., personnel matters) may be omitted from such archives or discussed in private. Similarly, meeting minutes may exclude detailed information about topics discussed under executive session but should note that such topics were discussed.
RSABは、すべての会議の議事録やすべての決定の記録を含む、訴訟の公的記録を保持するものとします。RSABが使用する主要な電子メールディスカッションリストは公開されますが、機密性（人員事項など）を必要とするトピックは、そのようなアーカイブから省略したり、プライベートで議論されたりする場合があります。同様に、会議議事録は、エグゼクティブセッションで議論されているトピックに関する詳細な情報を除外する場合がありますが、そのようなトピックが議論されたことに注意する必要があります。
The RSAB shall announce plans and agendas for their meetings on the RFC Editor website and by email to the RSWG at least a week before such meetings. The meetings shall be open for public attendance, and the RSAB may consider allowing open participation. If the RSAB needs to discuss a confidential matter in executive session, that part of the meeting shall be private to the RSAB, but it must be noted on the agenda and documented in the minutes with as much detail as confidentiality requirements permit.
RSABは、RFCエディターWebサイトでの会議の計画とアジェンダを、少なくともそのような会議の少なくとも1週間前にRSWGにメールで発表するものとします。会議は一般の出席のために開かれ、RSABはオープンな参加を許可することを検討する場合があります。RSABがエグゼクティブセッションで機密事項について議論する必要がある場合、会議の一部はRSABに非公開でなければなりませんが、アジェンダに記載され、秘密保持要件が許す限り詳細で議事録に文書化する必要があります。
The IETF LLC is requested to provide necessary tooling and staff to support RSAB communication, decision processes, and policies.
IETF LLCは、RSAB通信、決定プロセス、およびポリシーをサポートするために必要なツールとスタッフを提供するように要求されています。
The IAB is requested to convene the RSAB when it is first formed in order to formalize the IAB's transfer of authority over the RFC Editor Model.
IABは、RSABがRFCエディターモデルを介した権限の移転を正式化するために、最初に形成されたときにRSABを招集するように要求されます。
This section specifies the RFC Series Policy Definition Process, which shall be followed in producing all Editorial Stream RFCs.
このセクションでは、RFCシリーズポリシー定義プロセスを指定します。これは、すべての編集ストリームRFCの生産に従うものとします。
The intent is to provide an open forum by which policies related to the RFC Series are defined and evolved. The general expectation is that all interested parties will participate in the RSWG and that only under extreme circumstances should RSAB members need to hold CONCERN positions (as described in Section 3.2.2).
意図は、RFCシリーズに関連するポリシーが定義および進化するオープンフォーラムを提供することです。一般的な期待は、すべての利害関係者がRSWGに参加し、極端な状況下でのみRSABメンバーが懸念ポジションを保持する必要があるということです（セクション3.2.2で説明されているように）。
Because policy issues can be difficult and contentious, RSWG participants and RSAB members are strongly encouraged to work together in a spirit of good faith and mutual understanding to achieve rough consensus (see [RFC2418]). In particular, RSWG members are encouraged to take RSAB concerns seriously, and RSAB members are encouraged to clearly express their concerns early in the process and to be responsive to the community. All parties are encouraged to respect the value of each stream and the long-term health and viability of the RFC Series.
政策の問題は困難で議論の余地がある可能性があるため、RSWGの参加者とRSABメンバーは、誠実さと相互理解の精神で協力して大まかなコンセンサスを達成することを強く奨励されています（[RFC2418を参照]）。特に、RSWGメンバーはRSABの懸念を真剣に受け止めることをお勧めし、RSABメンバーはプロセスの早い段階で懸念を明確に表明し、コミュニティに対応することを奨励されています。すべての当事者は、各ストリームの価値とRFCシリーズの長期的な健康と実行可能性を尊重することが奨励されています。
This process is intended to be one of continuous consultation. RSAB members should consult with their constituent stakeholders (e.g., authors, editors, tool developers, and consumers of RFCs) on an ongoing basis, so that when the time comes to consider the approval of a proposal, there should be no surprises. Appointing bodies are expected to establish whatever processes they deem appropriate to facilitate this goal.
このプロセスは、継続的な相談の1つであることを目的としています。RSABメンバーは、継続的に継続的に構成要素の利害関係者（著者、編集者、ツール開発者、およびRFCの消費者）と相談する必要があります。そのため、提案の承認を検討する時が来たら、驚きはありません。この目標を促進するために適切と思われるプロセスを確立することが期待されています。
The following process shall be used to formulate or modify policies related to the RFC Series:
次のプロセスは、RFCシリーズに関連するポリシーを策定または変更するために使用するものとします。
1. An individual or set of individuals generates a proposal in the form of an Internet-Draft (which must be submitted in full conformance with the provisions of [BCP78] and [BCP79]) and asks the RSWG to adopt the proposal as a working group item.
1. 個人または個人のセットは、インターネットドラフトの形で提案を生成します（[BCP78]および[BCP79]の規定に完全に適合して提出する必要があります）。。
2. The RSWG may adopt the proposal as a working group item if the chairs determine (by following working group procedures for rough consensus) that there is sufficient interest in the proposal; this is similar to the way a working group of the IETF would operate (see [RFC2418]).
2. RSWGは、提案に十分な関心があると椅子が（大まかなコンセンサスのためにワーキンググループの手順に従うことにより）決定した場合、ワーキンググループ項目として提案を採用することができます。これは、IETFのワーキンググループが動作する方法に似ています（[RFC2418]を参照）。
3. The RSWG shall then further discuss and develop the proposal. All participants, but especially RSAB members, should pay special attention to any aspects of the proposal that have the potential to significantly modify long-standing policies or historical characteristics of the RFC Series as described in Section 7. Members of the RSAB are expected to participate as individuals in all discussions relating to RSWG proposals. This should help to ensure that they are fully aware of proposals early in the RFC Series Policy Definition Process. It should also help to ensure that RSAB members will raise any issues or concerns during the development of the proposal and not wait until the RSAB review period. The RSWG Chairs are also expected to participate as individuals.
3. その後、RSWGはさらに提案について議論し、開発するものとします。すべての参加者、特にRSABメンバーは、セクション7で説明されているように、RFCシリーズの長年のポリシーまたは歴史的特性を大幅に変更する可能性のある提案のあらゆる側面に特別な注意を払う必要があります。RSWGの提案に関連するすべての議論の個人として。これは、RFCシリーズのポリシー定義プロセスの初期に提案を完全に認識していることを確認するのに役立つはずです。また、RSABメンバーが提案の開発中に問題や懸念を提起し、RSABのレビュー期間まで待たないようにするのに役立つはずです。RSWGの椅子も個人として参加することが期待されています。
4. At some point, if the RSWG Chairs believe there may be rough consensus for the proposal to advance, they will issue a Last Call for comments within the working group.
4. ある時点で、RSWGの椅子が提案が前進するための大まかなコンセンサスがあるかもしれないと信じている場合、彼らはワーキンググループ内で最後のコメントの呼びかけを発行します。
5. After a comment period of suitable length, the RSWG Chairs will determine whether rough consensus for the proposal exists (taking their own feedback as individuals into account along with feedback from other participants). If comments have been received and substantial changes have been made, additional Last Calls may be necessary. Once the chairs determine that consensus has been reached, they shall announce their determination on the RSWG email discussion list and forward the document to the RSAB.
5. 適切な長さのコメント期間の後、RSWGチェアは、提案の大まかなコンセンサスが存在するかどうかを判断します（他の参加者からのフィードバックとともに個人としての独自のフィードバックを考慮して）。コメントが受け取られ、実質的な変更が加えられている場合、追加の最後の呼び出しが必要になる場合があります。椅子がコンセンサスに達したと判断したら、RSWGの電子メールディスカッションリストに対する決定を発表し、ドキュメントをRSABに転送するものとします。
6. Once consensus is established in the RSWG, the RSAB shall issue a community call for comments as further described in Section 3.2.3. If substantial comments are received in response to the community call for comments, the RSAB may return the proposal to the RSWG to consider those comments and make revisions to address the feedback received. In parallel with the community call for comments, the RSAB itself shall also consider the proposal.
6. RSWGでコンセンサスが確立されると、RSABはセクション3.2.3でさらに説明されているように、コメントのコミュニティコールを発行するものとします。コミュニティのコメントの呼びかけに応じて実質的なコメントを受け取った場合、RSABはRSWGに提案を返して、それらのコメントを検討し、受信したフィードバックに対処するために改訂を行うことができます。コメントを求めるコミュニティの呼びかけと並行して、RSAB自体も提案を検討するものとします。
7. If the scope of the revisions made in the previous step is substantial, an additional community call for comments should be issued by the RSAB, and the feedback received should be considered by the RSWG.
7. 前のステップで行われた改訂の範囲が大幅にある場合、RSABがコメントの追加のコミュニティコールを発行する必要があり、RSWGが受け取ったフィードバックを考慮する必要があります。
8. Once the RSWG Chairs confirm that concerns received during the community call(s) for comments have been addressed, they shall inform the RSAB that the document is ready for balloting by the RSAB.
8. RSWGの椅子が、コメントのコミュニティコール中に受け取った懸念がコメントの懸念を確認したことを確認したら、RSABがRSABによる投票の準備ができていることをRSABに通知するものとします。
9. Within a reasonable period of time, the RSAB will poll its members for their positions on the proposal. Positions may be as follows:
9. 合理的な期間内に、RSABは提案に関する立場についてメンバーを投票します。ポジションは次のとおりです。
* YES: the proposal should be approved
* はい：提案は承認されるべきです
* CONCERN: the proposal raises substantial concerns that must be addressed
* 懸念：提案は、対処しなければならないかなりの懸念を提起します
* RECUSE: the person holding the position has a conflict of interest
* 拒否：立場を保持している人は利益相反を持っています
Any RSAB member holding a CONCERN position must explain their concern to the community in detail. Nevertheless, the RSWG might not be able to come to consensus on modifications that will address the RSAB member's concern.
懸念事項を保持しているRSABメンバーは、コミュニティに懸念を詳細に説明する必要があります。それにもかかわらず、RSWGは、RSABメンバーの懸念に対処する修正に関するコンセンサスに達することができないかもしれません。
There are three reasons why an RSAB member may file a position of CONCERN:
RSABメンバーが懸念のある地位を提出する理由は3つあります。
* The RSAB member believes that the proposal represents a serious problem for one or more of the individual streams.
* RSABメンバーは、この提案は1つ以上の個々のストリームにとって深刻な問題を表していると考えています。
* The RSAB member believes that the proposal would cause serious harm to the overall RFC Series, including harm to the long-term health and viability of the Series.
* RSABメンバーは、この提案は、長期的な健康とシリーズの生存可能性への害を含む、RFCシリーズ全体に深刻な害を及ぼすと考えています。
* The RSAB member believes, based on the results of the community call(s) for comments (Section 3.2.3), that rough consensus to advance the proposal is lacking.
* RSABメンバーは、コメント（セクション3.2.3）のコミュニティコールの結果に基づいて、提案を進めるための大まかなコンセンサスが不足していると考えています。
Because RSAB members are expected to participate in the discussions within the RSWG and to raise any concerns and issues during those discussions, most CONCERN positions should not come as a surprise to the RSWG. Notwithstanding, late CONCERN positions are always possible if issues are identified during RSAB review or the community call(s) for comments.
RSABメンバーは、RSWG内の議論に参加し、それらの議論中に懸念や問題を提起することが期待されるため、ほとんどの懸念の立場はRSWGにとって驚きではありません。それにもかかわらず、RSABレビュー中に問題が特定されたり、コメントのコミュニティコールが特定されたりした場合、遅い懸念ポジションは常に可能です。
10. If a CONCERN exists, discussion will take place within the RSWG. Again, all RSAB members are expected to participate. If substantial changes are made in order to address CONCERN positions, an additional community call for comments might be needed.
10. 懸念が存在する場合、RSWG内で議論が行われます。繰り返しますが、すべてのRSABメンバーが参加することが期待されています。懸念の立場に対処するために大幅な変更が行われた場合、コメントの追加のコミュニティコールが必要になる場合があります。
11. A proposal without any CONCERN positions is approved.
11. 懸念のない提案が承認されます。
12. If, after a suitable period of time, any CONCERN positions remain, a vote of the RSAB is taken. If at least three voting members vote YES, the proposal is approved.
12. 適切な期間が経過した後、懸念ポジションが残っている場合、RSABの投票が行われます。少なくとも3人の投票メンバーが「はい」と投票した場合、提案は承認されます。
13. If the proposal is not approved, it is returned to the RSWG. The RSWG can then consider making further changes.
13. 提案が承認されていない場合、RSWGに返されます。RSWGは、さらなる変更を行うことを検討できます。
14. If the proposal is approved, a notification is sent to the community, and the document enters the queue for publication as an RFC within the Editorial Stream.
14. 提案が承認された場合、通知がコミュニティに送信され、ドキュメントは編集ストリーム内のRFCとして公開のキューに入ります。
15. Policies may take effect immediately upon approval by the RSAB and before publication of the relevant RFC, unless they are delayed while the IETF LLC resolves pending resource or contract issues.
15. IETF LLCが保留中のリソースまたは契約の問題を解決している間に遅延が発生しない限り、ポリシーはRSABによる承認と関連するRFCの公開前にすぐに有効になる場合があります。
The RSAB is responsible for initiating and managing community calls for comments on proposals that have gained consensus within the RSWG. The RSAB should actively seek a wide range of input. The RSAB seeks such input by, at a minimum, sending a notice to the rfc-interest@rfc-editor.org (mailto:rfc-interest@rfc-editor.org) email discussion list or to its successor or future equivalent. RSAB members should also send a notice to the communities they directly represent (e.g., the IETF and IRTF). Notices are also to be made available and archived on the RFC Editor website. In addition, other communication channels can be established for notices (e.g., via an RSS feed or by posting to social media venues).
RSABは、RSWG内でコンセンサスを獲得した提案に関するコメントを求めるコミュニティの呼び出しを開始および管理する責任があります。RSABは、幅広い入力を積極的に求める必要があります。RSABは、少なくともrfc-interest@rfc-editor.org（mailto：rfc-interest@rfc-editor.org）のメールディスカッションリストまたはその後継者または将来の同等物に通知を送信することにより、そのような入力を求めています。また、RSABメンバーは、直接代表するコミュニティ（IETFやIRTFなど）に通知を送信する必要があります。また、通知を利用可能にし、RFCエディターWebサイトでアーカイブされます。さらに、他の通信チャネルは、通知のために確立できます（たとえば、RSSフィードを介して、またはソーシャルメディア会場に投稿することで）。
In cases where a proposal has the potential to significantly modify long-standing policies or historical characteristics of the RFC Series as described in Section 7, the RSAB should take extra care to reach out to a very wide range of communities that make use of RFCs (as described in Section 3.1.1.2) since such communities might not be actively engaged in the RSWG directly. The RSAB should work with the stream approving bodies and the IETF LLC to identify and establish contacts in such communities, assisted by the RSCE in particular.
セクション7で説明されているように、提案がRFCシリーズの長年のポリシーまたは歴史的特性を大幅に変更する可能性がある場合、RSABはRFCを使用する非常に広範なコミュニティに手を差し伸べるように注意する必要があります（セクション3.1.1.2で説明されているように）そのようなコミュニティはRSWGに直接積極的に関与していない可能性があるため。RSABは、特にRSCEの支援を受けて、そのようなコミュニティの連絡先を特定して確立するために、ストリーム承認機関とIETF LLCと連携する必要があります。
The RSAB should maintain a public list of communities that are contacted during calls for comments.
RSABは、コメントの呼び出し中に連絡されたコミュニティの公開リストを維持する必要があります。
A notice of a community call for comments contains the following:
コメントのコミュニティコールの通知には、以下が含まれています。
* A subject line beginning with 'Call for Comments:'
* 「コメントの呼びかけ」から始まる件名：」
* A clear, concise summary of the proposal
* 提案の明確で簡潔な要約
* A URL pointing to the Internet-Draft that defines the proposal
* 提案を定義するインターネットドラフトを指すURL
* Any explanations or questions for the community that the RSAB deems necessary (using their usual decision-making procedures)
* RSABが必要とみなすコミュニティに対する説明や質問（通常の意思決定手順を使用）
* Clear instructions on how to provide public comments
* パブリックコメントを提供する方法に関する明確な指示
* A deadline for comments
* コメントの締め切り
A comment period will last not less than two weeks and should be longer if wide outreach is required. Comments will be publicly archived on the RFC Editor website.
コメント期間は2週間以上続き、広いアウトリーチが必要な場合は長くなるはずです。コメントは、RFCエディターWebサイトに公開されます。
The RSAB is responsible for considering comments received during a community call for comments. If RSAB members conclude that such comments raise important issues that need to be addressed, they should do so by discussing those issues within the RSWG or (if the issues meet the criteria specified in Step 9 of Section 3.2.2) lodging a position of CONCERN during RSAB balloting.
RSABは、コミュニティのコメントを求めて受け取ったコメントを検討する責任があります。RSABメンバーが、そのようなコメントに対処する必要がある重要な問題を提起すると結論付けた場合、RSWG内のこれらの問題について議論することにより、または（セクション3.2.2のステップ9で指定された基準を満たしている場合）懸念事項を提出することにより、そうする必要があります。RSAB投票中。
Appeals of RSWG Chair decisions shall be made to the RSAB. Decisions of the RSWG Chairs can be appealed only on grounds of failure to follow the correct process. Appeals should be made within thirty (30) days of any action or, in the case of failure to act, of notice having been given to the RSWG Chairs. The RSAB will then decide if the process was followed and will direct the RSWG Chairs as to what procedural actions are required.
RSWG議長の決定の控訴は、RSABに行われるものとします。RSWGの椅子の決定は、正しいプロセスに従わないという理由でのみ控訴することができます。控訴は、あらゆる行動から30日以内に、またはRSWGの椅子に与えられた通知が行われなかった場合に30日以内に行われるべきです。その後、RSABはプロセスに従っているかどうかを決定し、RSWGの椅子に必要な手続きアクションについて指示します。
Decisions of the RSAB can be appealed on grounds of failure to follow the correct process. In addition, if the RSAB makes a decision in order to resolve a disagreement between authors and the RPC (as described in Section 4.4), appeals can be filed on the basis that the RSAB misinterpreted an approved policy. Aside from these two cases, disagreements about the conduct of the RSAB are not subject to appeal. Appeals of RSAB decisions shall be made to the IAB and should be made within thirty (30) days of public notice of the relevant RSAB decision (typically, when minutes are posted). The IAB shall decide whether a process failure occurred and what (if any) corrective action should take place.
RSABの決定は、正しいプロセスに従わなかったことを理由に上訴することができます。さらに、RSABが著者とRPC（セクション4.4で説明されているように）の間の意見の相違を解決するために決定を下す場合、RSABが承認されたポリシーを誤って解釈したことに基づいて控訴を提出することができます。これら2つのケースとは別に、RSABの行為に関する意見の相違は控訴の対象ではありません。RSABの決定の控訴はIABに行われ、関連するRSAB決定の公的通知から30日以内に行われるべきです（通常、議事録が投稿された場合）。IABは、プロセスの障害が発生したかどうか、および（もしあれば）是正措置が行われるべきかどうかを決定するものとします。
The IETF anti-harassment policy (https://www.ietf.org/about/groups/iesg/statements/anti-harassment-policy/) also applies to the RSWG and RSAB, which strive to create and maintain an environment in which people of many different backgrounds are treated with dignity, decency, and respect. Participants are expected to behave according to professional standards and to demonstrate appropriate workplace behavior. For further information about these policies, see [RFC7154], [RFC7776], and [RFC8716].
IETFアンチハラスメントポリシー（https://www.ietf.org/about/groups/iesg/statements/anti-harassment-policy/）もRSWGとRSABに適用されます。さまざまな背景を持つ人々は、尊厳、品位、尊敬をもって扱われます。参加者は、専門的な基準に従って行動し、適切な職場行動を実証することが期待されています。これらのポリシーの詳細については、[RFC7154]、[RFC7776]、および[RFC8716]を参照してください。
RFC boilerplates (see [RFC7841]) are part of the RFC Style Guide, as defined in Section 4.2. New or modified boilerplates considered under version 3 of the RFC Editor Model must be approved by the following parties, each of which has a separate area of responsibility with respect to boilerplates:
RFCボイラープレート（[RFC7841]を参照）は、セクション4.2で定義されているRFCスタイルガイドの一部です。RFCエディターモデルのバージョン3で検討されている新しいまたは修正されたボイラープレートは、次の当事者によって承認されなければなりません。それぞれは、ボイラープレートに関して別の責任領域を持っています。
* The applicable stream, which approves that the boilerplate meets its needs
* ボイラープレートがそのニーズを満たしていることを承認する該当するストリーム
* The RSAB, which approves that the boilerplate is not in conflict with the boilerplate used in the other streams
* ボイラープレートが他のストリームで使用されているボイラープレートと競合していないことを承認するRSAB
* The RPC, which approves that the language of the boilerplate is consistent with the RFC Style Guide
* ボイラープレートの言語がRFCスタイルガイドと一致していることを承認するRPC
* The IETF Trust, which approves that the boilerplate correctly states the Trust's position regarding rights and ownership
* IETFトラストは、ボイラープレートが権利と所有権に関する信託の立場を正しく述べていることを承認します
Publication of RFCs is handled by the RFC Production Center (RPC).
RFCSの公開は、RFC生産センター（RPC）によって処理されます。
A few general considerations apply:
いくつかの一般的な考慮事項が適用されます。
* The general roles and responsibilities of the RPC are defined by RFCs published in the Editorial Stream (i.e., not directly by the RSWG, RSAB, or RSCE), by existing RFCs that apply to the RPC and have not yet been superseded by Editorial Stream RFCs, and by the requisite contracts.
* RPCの一般的な役割と責任は、編集ストリームで公開されているRFC（つまり、RSWG、RSAB、またはRSCEによって直接ではなく）、RPCに適用されていない既存のRFCによって定義されており、編集ストリームRFCによってまだ装飾されていません。、および必要な契約によって。
* The RPC is advised by the RSCE and RSAB, and it has a duty to consult with them under specific circumstances, such as those relating to disagreements between authors and the RPC as described in Section 4.4.
* RPCはRSCEとRSABからアドバイスされており、セクション4.4で説明されているように、著者とRPCの間の意見の相違に関連するものなど、特定の状況下でそれらと相談する義務があります。
* The RPC is overseen by the IETF LLC to ensure that it performs in accordance with contracts in place.
* RPCは、IETF LLCによって監督されており、実施されている契約に従って実行することを確認しています。
All matters of budget, timetable, and impact on its performance targets are between the RPC and IETF LLC.
予算、時刻表、およびそのパフォーマンス目標への影響に関するすべての問題は、RPCとIETF LLCの間です。
The RPC shall regularly provide reports to the IETF LLC, RSAB, RSWG, and broader community regarding its activities and any key risks or issues affecting it.
RPCは、IETF LLC、RSAB、RSWG、およびより広範なコミュニティに、その活動とそれに影響を与える重要なリスクまたは問題に関して、定期的にレポートを提供するものとします。
In the event that the RPC is required to make a decision without consultation that would normally deserve consultation, or makes a decision against the advice of the RSAB, the RPC must notify the RSAB.
RPCが通常協議に値する協議なしに決定を下す必要がある場合、またはRSABのアドバイスに反して決定を下す場合、RPCはRSABに通知する必要があります。
This document does not specify the exact relationship between the IETF LLC and the RPC; for example, the work of the RPC could be performed by a separate corporate entity under contract to the IETF LLC, it could be performed by employees of the IETF LLC, or the IETF LLC could engage with independent contractors for some or all aspects of such work. The exact relationship is a matter for the IETF LLC to determine.
このドキュメントでは、IETF LLCとRPCの正確な関係は指定されていません。たとえば、RPCの作業は、IETF LLCとの契約に基づいて別の企業エンティティによって実行される可能性があります。IETFLLCの従業員によって実行されることができます。仕事。正確な関係は、IETF LLCが決定する問題です。
The IETF LLC is responsible for the method and management of the engagement of the RPC. Therefore, the IETF LLC has authority over negotiating performance targets for the RPC and also has responsibility for ensuring that those targets are met. Such performance targets are set based on the RPC's publication load and additional efforts required to implement policies specified in Editorial Stream RFCs, in existing RFCs that apply to the RPC and have not yet been superseded by Editorial Stream RFCs, and in the requisite contracts. The IETF LLC may consult with the community regarding these targets. The IETF LLC is empowered to appoint a manager or to convene a committee to complete these activities.
IETF LLCは、RPCのエンゲージメントの方法と管理を担当しています。したがって、IETF LLCは、RPCのパフォーマンス目標の交渉に対する権限を持ち、それらのターゲットが満たされることを保証する責任もあります。このようなパフォーマンス目標は、RPCの公開負荷と、編集ストリームRFCSで指定されたポリシー、RPCに適用され、編集ストリームRFCSおよび必要な契約に取って代わられていない既存のRFCで指定されたポリシーを実装するために必要な追加の取り組みに基づいて設定されています。IETF LLCは、これらのターゲットに関してコミュニティと相談する場合があります。IETF LLCは、これらの活動を完了するためにマネージャーを任命するか、委員会を招集する権限を与えられています。
If individuals or groups within the community have concerns about the performance of the RPC, they can request that the matter be investigated by the IETF LLC Board, the IETF Executive Director, or a point of contact designated by the IETF LLC Board. Even if the IETF LLC opts to delegate this activity, concerns should be raised with the IETF LLC. The IETF LLC is ultimately answerable to the community via the mechanisms outlined in [RFC8711].
コミュニティ内の個人またはグループがRPCのパフォーマンスについて懸念を持っている場合、IETF LLC委員会、IETFエグゼクティブディレクター、またはIETF LLC委員会によって指定された連絡先によって問題を調査することを要求できます。IETF LLCがこのアクティビティを委任することを選択したとしても、IETF LLCに懸念を提起する必要があります。IETF LLCは、[RFC8711]で概説されているメカニズムを介して、最終的にコミュニティに対して回答可能です。
In the absence of a high-level policy documented in an RFC or in the interest of specifying the detail of its implementation of such policies, the RPC can document working practices regarding the editorial preparation, final publication, and dissemination of RFCs. Examples include:
RFCで文書化された高レベルのポリシーがない場合、またはそのようなポリシーの実装の詳細を指定するために、RPCは、編集の準備、最終出版、およびRFCの普及に関する実務慣行を文書化できます。例は次のとおりです。
* Maintenance of a style guide that defines editorial standards for RFCs; specifically, the RFC Style Guide consists of [RFC7322] and the other documents and resources listed at [STYLEGUIDE].
* RFCの編集基準を定義するスタイルガイドのメンテナンス。具体的には、RFCスタイルガイドは[RFC7322]と[StyleGuide]にリストされている他のドキュメントとリソースで構成されています。
* Instructions regarding the file formats that are accepted as input to the editing and publication process.
* 編集および公開プロセスへの入力として受け入れられるファイル形式に関する指示。
* Guidelines regarding the final structure and layout of published documents. In the context of the XML vocabulary [RFC7991], such guidelines could include clarifications regarding the preferred XML elements and attributes used to capture the semantic content of RFCs.
* 公開されたドキュメントの最終構造とレイアウトに関するガイドライン。XML語彙[RFC7991]のコンテキストでは、このようなガイドラインには、RFCのセマンティックコンテンツをキャプチャするために使用される好ましいXML要素と属性に関する明確化が含まれる場合があります。
The core responsibility of the RPC is the implementation of RFC Series policies through publication of RFCs (including the dimensions of document quality, timeliness of publication, and accessibility of results), while taking into account issues raised by the community through the RSWG and by the stream approving bodies. More specifically, the RPC's responsibilities at the time of writing include the following:
RPCの中心的な責任は、RFCの公開（ドキュメントの品質の次元、出版の適時性、結果のアクセシビリティを含む）を通じてRFCシリーズポリシーの実装です。承認装置をストリーミングします。より具体的には、執筆時点でのRPCの責任には以下が含まれます。
1. Editing documents originating from all RFC streams to ensure that they are consistent with the editorial standards specified in the RFC Style Guide.
1. すべてのRFCストリームから発信されるドキュメントを編集して、RFCスタイルガイドで指定された編集基準と一致するようにします。
2. Creating and preserving records of edits performed on documents.
2. ドキュメントで実行された編集の記録の作成と保存。
3. Identifying where editorial changes might have technical impact and seeking necessary clarification.
3. 編集上の変更が技術的な影響を与える可能性があることを特定し、必要な明確化を求めます。
4. Establishing the publication readiness of each document through communication with the authors, IANA, or stream-specific contacts, supplemented if needed by the RSAB and RSCE.
4. 著者、IANA、またはストリーム固有の連絡先との通信を通じて、各ドキュメントの出版準備の準備を確立し、RSABおよびRSCEで必要に応じて補足されます。
5. Creating and preserving records of dialogue with document authors.
5. 文書著者との対話の記録を作成および保存します。
6. Requesting advice from the RSAB and RSCE as needed.
6. 必要に応じてRSABとRSCEからアドバイスを要求します。
7. Providing suggestions to the RSAB and RSCE as needed.
7. 必要に応じてRSABとRSCEに提案を提供します。
8. Participating within the RSWG in the creation of new Editorial Stream RFCs that impact the RPC, specifically with respect to any challenges the RPC might foresee with regard to implementation of proposed policies.
8. 特にRPCが提案されたポリシーの実装に関して、RPCが予測する可能性のある課題に関して、RPCに影響を与える新しい編集ストリームRFCの作成にRSWGに参加します。
9. Identifying topics and issues while processing documents or carrying out other responsibilities on this list for which they lack sufficient expertise, and identifying and conferring with relevant experts as needed.
9. ドキュメントの処理中にトピックと問題を特定したり、十分な専門知識が不足しているこのリストで他の責任を実行したり、必要に応じて関連する専門家を特定したり授与したりします。
10. Providing reports to the community on its performance and plans.
10. パフォーマンスと計画について、コミュニティにレポートを提供します。
11. Consulting with the community on its plans.
11. その計画についてコミュニティと相談します。
12. Negotiating its specific plans and resources with the IETF LLC.
12. IETF LLCで特定の計画とリソースを交渉します。
13. Providing sufficient resources to support reviews of RPC performance by the IETF LLC.
13. IETF LLCによるRPCパフォーマンスのレビューをサポートするのに十分なリソースを提供します。
14. Coordinating with IANA to ensure that RFCs accurately document registration processes and assigned values for IANA registries.
14. IANAと調整して、RFCが登録プロセスを正確に文書化し、IANAレジストリの値を割り当てたことを確認します。
15. Assigning RFC numbers.
15. RFC番号の割り当て。
16. Liaising with stream approving bodies and other representatives of the streams as needed.
16. 必要に応じて、ストリーム承認機関やストリームの他の代表者との連携。
17. Publishing RFCs, which includes:
17. RFCSを公開します。
* posting copies to the RFC Editor site both individually and in collections
* コピーをRFCエディターサイトに個別にもコレクションも投稿しています
* depositing copies with external archives
* 外部アーカイブにコピーを預けます
* creating catalogs and catalog entries
* カタログとカタログエントリの作成
* announcing the publication to interested parties
* 関心のある関係者に出版物を発表します
18. Providing online access to RFCs.
18. RFCへのオンラインアクセスを提供します。
19. Providing an online system to facilitate the submission, management, and display of errata to RFCs.
19. RFCへの正誤表の提出、管理、および表示を容易にするためのオンラインシステムを提供します。
20. Maintaining the RFC Editor website.
20. RFCエディターWebサイトの維持。
21. Providing for the backup of RFCs.
21. RFCのバックアップを提供します。
22. Ensuring the storage and preservation of records.
22. 記録の保存と保存の確保。
23. Authenticating RFCs for legal proceedings.
23. 法的手続きのためのRFCの認証。
During the process of editorial preparation and publication, disagreements can arise between the authors of an RFC-to-be and the RPC. Where an existing policy clearly applies, typically such disagreements are handled in a straightforward manner through direct consultation between the authors and the RPC, sometimes in collaboration with stream-specific contacts.
編集の準備と出版の過程で、RFCとRPCの著者との間で意見の相違が生じる可能性があります。既存のポリシーが明確に適用される場合、通常、そのような意見の相違は、著者とRPCの間の直接的な相談を通じて、時にはストリーム固有の連絡先と共同で処理されます。
However, if it is unclear whether an existing policy applies or if it is unclear how to interpret an existing policy, the parties may need to consult with additional individuals or bodies (e.g., RSAB, IESG, IRSG, or stream approving bodies) to help achieve a resolution. The following points are intended to provide more specific guidance.
ただし、既存のポリシーが適用されるかどうか、または既存のポリシーを解釈する方法が不明な場合は不明な場合、当事者は、追加の個人または団体（RSAB、IESG、IRSG、または承認装置のストリームを追加する必要がある場合があります。解決策を達成します。次のポイントは、より具体的なガイダンスを提供することを目的としています。
* If there is a conflict with a policy for a particular stream, to help achieve a resolution, the RPC should consult with the relevant stream approving body (such as the IESG or IRSG) and other representatives of the relevant stream as appropriate.
* 特定のストリームのポリシーとの競合がある場合、解決を達成するために、RPCは、必要に応じて、関連するストリーム承認機関（IESGやIRSGなど）および関連するストリームの他の代表者と相談する必要があります。
* If there is a conflict with a cross-stream policy, the RPC should consult with the RSAB to achieve a resolution.
* クロスストリームポリシーとの競合がある場合、RPCはRSABに相談して解決を達成する必要があります。
* The disagreement might raise a new issue that is not covered by an existing policy or that cannot be resolved through consultation between the RPC and other relevant individuals and bodies, as described above. In this case, the RSAB is responsible for (a) resolving the disagreement in a timely manner if necessary so that the relevant stream document(s) can be published before a new policy is defined and (b) bringing the issue to the RSWG so that a new policy can be defined.
* 意見の相違は、上記のように、既存のポリシーでカバーされていない、またはRPCと他の関連する個人および団体の間の協議を通じて解決できない新しい問題を提起する可能性があります。この場合、RSABは、（a）必要に応じて不一致を解決するために責任があります。これにより、新しいポリシーが定義される前に関連するストリームドキュメントを公開し、（b）RSWGに問題をもたらすことができます。新しいポリシーを定義できること。
From time to time, individuals or organizations external to the IETF and the broader RFC Series community may have questions about the RFC Series. Such inquiries should be directed to the rfc-editor@rfc-editor.org (mailto:rfc-editor@rfc-editor.org) email alias or to its successor or future equivalent and then handled by the appropriate bodies (e.g., RSAB and RPC) or individuals (e.g., RSWG Chairs and RSCE).
IETFおよびより広範なRFCシリーズコミュニティの外部の個人または組織は、RFCシリーズについて質問がある場合があります。このような問い合わせは、rfc-editor@rfc-editor.org（mailto：rfc-editor@rfc-editor.org）の電子メールエイリアス、またはその後継者または将来の同等物に送信する必要があります。RPC）または個人（例：RSWGの椅子やRSCE）。
The exact implementation of the administrative and contractual activities described here are a responsibility of the IETF LLC. This section provides general guidance regarding several aspects of such activities.
ここで説明する管理および契約上の活動の正確な実装は、IETF LLCの責任です。このセクションでは、そのような活動のいくつかの側面に関する一般的なガイダンスを提供します。
Vendor selection is done in cooperation with the streams and under the final authority of the IETF LLC.
ベンダーの選択は、IETF LLCの最終的な権限の下で、ストリームと協力して行われます。
The IETF LLC develops the work definition (the Statement of Work) for the RPC and manages the vendor-selection process. The work definition is created within the IETF LLC budget and takes into account the RPC responsibilities (as described in Section 4.3), the needs of the streams, and community input.
IETF LLCは、RPCの作業定義（作業ステートメント）を開発し、ベンダー選択プロセスを管理します。作業定義はIETF LLC予算内で作成され、RPCの責任（セクション4.3で説明されている）、ストリームのニーズ、およびコミュニティ入力を考慮しています。
The process to select and contract for the RPC and other RFC-related services is as follows:
RPCおよびその他のRFC関連サービスを選択して契約するプロセスは次のとおりです。
* The IETF LLC establishes the contract process, including the steps necessary to issue a Request for Proposal (RFP) when necessary, the timing, and the contracting procedures.
* IETF LLCは、必要に応じて提案要求（RFP）を発行するために必要な手順、タイミング、契約手順を含む契約プロセスを確立します。
* The IETF LLC establishes a selection committee, which will consist of the IETF Executive Director and other members selected by the IETF LLC in consultation with the stream approving bodies. The committee shall select a chair from among its members.
* IETF LLCは、IETFエグゼクティブディレクターとIETF LLCが選択した他のメンバーで構成される選択委員会を設立し、Stream Appoding Bodiesと相談します。委員会は、そのメンバーの中から椅子を選択するものとします。
* The selection committee selects the vendor, subject to the successful negotiation of a contract approved by the IETF LLC. In the event that a contract cannot be signed, the matter shall be referred to the selection committee for further action.
* 選択委員会は、IETF LLCによって承認された契約の交渉の成功を条件として、ベンダーを選択します。契約に署名できない場合、問題はさらなる行動のために選考委員会に照会されなければならない。
Most expenses discussed in this document are not new expenses. They have been and remain part of the IETF LLC budget.
この文書で議論されているほとんどの費用は、新しい費用ではありません。彼らはIETF LLC予算の一部であり、その一部であり続けています。
The RFC Series portion of the IETF LLC budget shall include funding to support the RSCE, the RFC Production Center, and the Independent Stream.
IETF LLC予算のRFCシリーズ部分には、RSCE、RFC生産センター、および独立ストリームをサポートするための資金が含まれます。
The IETF LLC has the responsibility to approve the total RFC Editor budget (and the authority to deny it). All relevant parties must work within the IETF LLC budgetary process.
IETF LLCには、RFCエディターの合計予算（およびそれを拒否する権限）を承認する責任があります。すべての関連当事者は、IETF LLC予算プロセス内で作業する必要があります。
The RFC Series Consulting Editor (RSCE) is a senior technical publishing professional who will apply their deep knowledge of technical publishing processes to the RFC Series.
RFCシリーズコンサルティングエディター（RSCE）は、技術出版プロセスに関する深い知識をRFCシリーズに適用するシニアテクニカルパブリッシングの専門家です。
The primary responsibilities of the RSCE are as follows:
RSCEの主な責任は次のとおりです。
* Serve as a voting member on the RSAB
* RSABの投票メンバーを務めます
* Identify problems with the RFC publication process and opportunities for improvement
* RFCの出版プロセスと改善の機会に関する問題を特定する
* Provide expert advice within the RSWG regarding policy proposals
* ポリシー提案に関してRSWG内で専門家のアドバイスを提供します
* Provide expert advice to the RPC and IETF LLC
* RPCおよびIETF LLCに専門家のアドバイスを提供します
Matters on which the RSCE might provide guidance could include the following (see also Section 4 of [RFC8729]):
RSCEがガイダンスを提供する可能性のある問題には、以下を含めることができます（[RFC8729]のセクション4も参照）：
* Editing, processing, and publication of RFCs
* RFCSの編集、処理、および公開
* Publication formats for the RFC Series
* RFCシリーズの出版形式
* Changes to the RFC Style Guide
* RFCスタイルガイドの変更
* Series-wide guidelines regarding document content and quality
* ドキュメントの内容と品質に関するシリーズ全体のガイドライン
* Web presence for the RFC Series
* RFCシリーズのWebプレゼンス
* Copyright matters related to the RFC Series
* RFCシリーズに関連する著作権の問題
* Archiving, indexing, and accessibility of RFCs
* RFCのアーカイブ、インデックス作成、およびアクセシビリティ
The IETF LLC is responsible for the method and management of the engagement of the RSCE, including selection, evaluation, and the timely filling of any vacancy. Therefore, whether the RSCE role is structured as a contractual or employee relationship is a matter for the IETF LLC to determine.
IETF LLCは、選択、評価、空席のタイムリーな充填など、RSCEの関与の方法と管理を担当しています。したがって、RSCEの役割が契約上の関係として構成されているか、従業員の関係として構成されているかは、IETF LLCが決定する問題です。
Responsibility for making a recommendation to the IETF LLC regarding the RSCE role will lie with a selection committee. The IETF LLC should propose an initial slate of members for this committee, making sure to include community members with diverse perspectives, and consult with the stream representatives regarding the final membership of the committee. In making its recommendation for the role of RSCE, the selection committee will take into account the definition of the role as well as any other information that the committee deems necessary or helpful in making its decision. The IETF LLC is responsible for contracting or employment of the RSCE.
RSCEの役割に関するIETF LLCに推奨する責任は、選択委員会にあります。IETF LLCは、この委員会の最初のメンバーのスレートを提案し、多様な視点を持つコミュニティメンバーを確実に含め、委員会の最終メンバーシップに関してStreamの代表者に相談する必要があります。RSCEの役割について勧告する際、選択委員会は、その決定を決定するのに必要または有用であると判断したその他の情報と同様に、役割の定義を考慮します。IETF LLCは、RSCEの契約または雇用を担当しています。
Periodically, the IETF LLC will evaluate the performance of the RSCE, including a call for confidential input from the community. The IETF LLC will produce a draft evaluation of the RSCE's performance for review by RSAB members (other than the RSCE), who will provide feedback to the IETF LLC.
定期的に、IETF LLCは、コミュニティからの機密入力の呼び出しを含む、RSCEのパフォーマンスを評価します。IETF LLCは、IETF LLCにフィードバックを提供するRSABメンバー（RSCE以外）によるRSCEのパフォーマンスのドラフト評価を作成します。
In the case that the currently appointed RSCE is expected to be unavailable for an extended period, the IETF LLC may appoint a Temporary RSCE through whatever recruitment process it considers appropriate. A Temporary RSCE acts as the RSCE in all aspects during their term of appointment.
現在任命されているRSCEが長期にわたって利用できないと予想される場合、IETF LLCは、適切と考える募集プロセスを通じて一時的なRSCEを任命することができます。一時的なRSCEは、任命中にあらゆる面でRSCEとして機能します。
The RSCE is expected to avoid even the appearance of conflict of interest or judgment in performing their role. To ensure this, the RSCE will be subject to a conflict-of-interest policy established by the IETF LLC.
RSCEは、利益相反の出現やその役割の実行における判断の出現さえ回避することが期待されています。これを確実にするために、RSCEはIETF LLCによって確立された利益相反ポリシーの対象となります。
The RPC service provider may contract services from the RSCE service provider, and vice versa, including services provided to the IETF LLC. All contracts between the two must be disclosed to the IETF LLC. Where those services are related to services provided to the IETF LLC, IETF LLC policies shall apply, including publication of relevant parts of the contract.
RPCサービスプロバイダーは、RSCEサービスプロバイダーからサービスを契約することができ、その逆も同様で、IETF LLCに提供されるサービスを含めます。2つの間のすべての契約は、IETF LLCに開示する必要があります。これらのサービスがIETF LLCに提供されるサービスに関連している場合、IETF LLCポリシーは、契約の関連部分の公開を含めて適用されます。
This document creates the Editorial Stream as a separate space for publication of policies, procedures, guidelines, rules, and related information regarding the RFC Series as a whole.
このドキュメントでは、RFCシリーズ全体に関するポリシー、手順、ガイドライン、ルール、および関連情報を公開するための別のスペースとして編集ストリームを作成します。
The Editorial Stream shall be used only to specify and update policies, procedures, guidelines, rules, and related information regarding the RFC Series as a whole; no other use of the Editorial Stream is authorized by this memo, and no other streams are so authorized. This policy may be changed only by agreement of the IAB, IESG, and IETF LLC.
編集ストリームは、RFCシリーズ全体に関するポリシー、手順、ガイドライン、ルール、および関連情報を指定および更新するためにのみ使用するものとします。編集ストリームの他の使用はこのメモによって承認されておらず、他のストリームはそれほど承認されていません。このポリシーは、IAB、IESG、およびIETF LLCの合意によってのみ変更される場合があります。
All documents produced by the RSWG and approved by the RSAB shall be published as RFCs in the Editorial Stream with a status of Informational. (Note that the Editorial Stream is not authorized to publish RFCs that are Standards Track or Best Current Practice, since such RFCs are reserved for the IETF Stream [RFC8729].) Notwithstanding the status of Informational, it should be understood that documents published in the Editorial Stream define policies for the RFC Series as a whole.
RSWGによって作成され、RSABによって承認されたすべての文書は、情報のステータスを持つ編集ストリームのRFCとして公開されるものとします。（編集ストリームは、そのようなRFCはIETFストリーム[RFC8729]に予約されているため、標準の追跡または最良の現在の実践であるRFCを公開することを許可されていないことに注意してください。）編集ストリームは、RFCシリーズ全体のポリシーを定義しています。
The requirements and process for creating any additional RFC streams are outside the scope of this document.
追加のRFCストリームを作成するための要件とプロセスは、このドキュメントの範囲外です。
The IAB requests that the IETF Trust and its Trustees assist in meeting the goals and procedures set forth in this document.
IABは、IETFトラストとその受託者が、このドキュメントに記載されている目標と手順を満たすのを支援することを要求します。
The Trustees are requested to publicly confirm their willingness and ability to accept responsibility for the Intellectual Property Rights (IPR) for the Editorial Stream.
受託者は、編集ストリームの知的財産権（IPR）に対する責任を受け入れる意欲と能力を公に確認するよう求められています。
Specifically, the Trustees are asked to develop the necessary boilerplate to enable the suitable marking of documents so that the IETF Trust receives the rights as specified in [BCP78]. These procedures need to also allow authors to indicate either no rights to make derivative works or, preferentially, the right to make unlimited derivative works from the documents. It is left to the Trust to specify exactly how this shall be clearly indicated in each document.
具体的には、受託者は、[BCP78]で指定されているように、IETFトラストが権利を受け取るように、文書の適切なマーキングを有効にするために必要なボイラープレートを開発するよう求められます。これらの手順は、著者が派生物の作品を作成する権利を示さないか、優先的に文書から無制限の派生物を作る権利を示すことを許可する必要があります。各ドキュメントでこれが明確に示される方法を正確に指定することは、信頼に任されています。
As specified above, contributors of documents for the Editorial Stream are expected to use the IETF Internet-Draft process, complying therein with the rules specified in [BCP9]. This includes the disclosure of patent and trademark issues that are known, or can be reasonably expected to be known, to the contributor.
上記で指定されたように、編集ストリームのドキュメントの貢献者は、[BCP9]で指定されたルールを遵守するIETFインターネットドラフトプロセスを使用することが期待されています。これには、貢献者に既知の、または合理的に知られることが期待される特許および商標問題の開示が含まれます。
Disclosure of license terms for patents is also requested, as specified in [BCP79]. The Editorial Stream has chosen to use the IETF's IPR disclosure mechanism (https://www.ietf.org/ipr/) for this purpose. The IAB would prefer that the most liberal terms possible be made available for Editorial Stream documents. Terms that do not require fees or licensing are preferable. Non-discriminatory terms are strongly preferred over those that discriminate among users. However, although disclosure is required and the RSWG and the RSAB may consider disclosures and terms in making a decision as to whether to submit a document for publication, there are no specific requirements on the licensing terms for intellectual property related to Editorial Stream publication.
[BCP79]で指定されているように、特許のライセンス条件の開示も要求されます。編集ストリームは、この目的のためにIETFのIPR開示メカニズム（https://www.ietf.org/ipr/）を使用することを選択しました。IABは、編集ストリーム文書で可能な最もリベラルな用語を利用できるようにすることを好みます。料金またはライセンスを必要としない条件が望ましい。非差別的な用語は、ユーザーを差別するものよりも強く好まれます。ただし、開示が必要であり、RSWGとRSABは、公開のために文書を提出するかどうかを決定する際に開示と条件を検討する場合がありますが、編集ストリームの出版に関連する知的財産のライセンス条件に関する特定の要件はありません。
This document specifies the following text for the "Status of This Memo" section of RFCs published in the Editorial Stream. Any changes to this boilerplate must be made through the RFC Series Policy Definition Process specified in Section 3 of this document.
このドキュメントは、編集ストリームで公開されているRFCSの「このメモのステータス」セクションの次のテキストを指定します。このボイラープレートの変更は、このドキュメントのセクション3で指定されたRFCシリーズポリシー定義プロセスを通じて行う必要があります。
Because all Editorial Stream RFCs have a status of Informational, the first paragraph of the "Status of This Memo" section shall be as specified in Appendix A.2.1 of [RFC7841].
すべての編集ストリームRFCには情報のステータスがあるため、[このメモのステータス]セクションの最初の段落は、[RFC7841]の付録A.2.1で指定されているとおりです。
The second paragraph of the "Status of This Memo" section shall be as follows:
「このメモのステータス」セクションの2番目の段落は次のとおりです。
This document is a product of the RFC Series Policy Definition Process. It represents the consensus of the RFC Series Working Group approved by the RFC Series Approval Board. Such documents are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、RFCシリーズポリシー定義プロセスの製品です。これは、RFCシリーズ承認委員会によって承認されたRFCシリーズワーキンググループのコンセンサスを表しています。このような文書は、インターネット標準のレベルの候補ではありません。RFC 7841のセクション2を参照してください。
The third paragraph of the "Status of This Memo" section shall be as specified in Section 3.5 of [RFC7841].
[このメモのステータス]セクションの3番目の段落は、[RFC7841]のセクション3.5で指定されているとおりです。
This section lists some of the properties that have been historically regarded as important to the RFC Series. Proposals that affect these properties are possible within the processes defined in this document. As described in Sections 3.2.2 and 3.2.3, proposals that might have a detrimental effect on these properties should receive heightened scrutiny during RSWG discussion and RSAB review. The purpose of this scrutiny is to ensure that all changes are deliberate and that the consequences of a proposal, as far as they can be identified, have been carefully considered.
このセクションには、RFCシリーズにとって歴史的に重要と見なされてきたプロパティの一部をリストします。これらのプロパティに影響を与える提案は、このドキュメントで定義されているプロセス内で可能です。セクション3.2.2および3.2.3で説明されているように、これらのプロパティに有害な影響を与える可能性のある提案は、RSWGの議論とRSABレビュー中に強化された精査を受けるはずです。この精査の目的は、すべての変更が意図的であり、提案の結果が特定できる限り、慎重に検討されていることを保証することです。
Documents in the RFC Series have been available for many decades, with no restrictions on access or distribution.
RFCシリーズのドキュメントは何十年もの間利用可能であり、アクセスや配布に制限はありませんでした。
RFC Series documents have been published in a format that was intended to be as accessible as possible to people with disabilities, e.g., people with impaired sight.
RFCシリーズドキュメントは、障害のある人、たとえば視力障害のある人が可能な限りアクセスできることを意図した形式で公開されています。
All existing RFC Series documents have been published in English. However, since the beginning of the RFC Series, documents have been published under terms that explicitly allow translation into languages other than English without asking for permission.
既存のすべてのRFCシリーズドキュメントは英語で公開されています。ただし、RFCシリーズの開始以来、ドキュメントは、許可を求めることなく英語以外の言語への翻訳を明示的に許可する条件の下で公開されています。
The RFC Series has included many types of documents including standards for the Internet, procedural and informational documents, thought experiments, speculative ideas, research papers, histories, humor, and even eulogies.
RFCシリーズには、インターネットの標準、手続き的および情報文書、思考実験、投機的なアイデア、研究論文、歴史、ユーモア、さらにはeulogyを含む多くの種類のドキュメントが含まれています。
RFC Series documents have been reviewed for subject matter quality and edited by professionals with a goal of ensuring that documents are clear, consistent, and readable [RFC7322].
RFCシリーズドキュメントは、主題の品質についてレビューされ、ドキュメントが明確で一貫性があり、読みやすいことを確認することを目的として専門家によって編集されています[RFC7322]。
Once published, RFC Series documents are not changed.
公開されると、RFCシリーズドキュメントは変更されません。
RFC Series documents have been published in a form intended to be comprehensible to humans for decades or longer.
RFCシリーズドキュメントは、数十年以上にわたって人間が理解できることを目的とした形式で公開されています。
Updates, amendments, and refinements to this document can be produced using the process documented herein but shall be published and operative only after (a) obtaining the agreement of the IAB and the IESG and (b) ensuring that the IETF LLC has no objections regarding its ability to implement any proposed changes.
このドキュメントの更新、修正、および改良は、本明細書で文書化されたプロセスを使用して作成できますが、（a）IABとIESGの合意を取得した後にのみ公開および運用するものとします。提案された変更を実装する能力。
The processes and organizational models for publication of RFCs have changed significantly over the years. Most recently, in 2009, [RFC5620] defined the RFC Editor Model (Version 1), and in 2012, [RFC6635] defined the RFC Editor Model (Version 2), which was then modified slightly in 2020 by [RFC8728].
RFCの公開のためのプロセスと組織モデルは、長年にわたって大幅に変化しています。最近では、2009年に[RFC5620]はRFCエディターモデル（バージョン1）を定義し、2012年に[RFC6635]はRFCエディターモデル（バージョン2）を定義し、2020年に[RFC8728]によってわずかに変更されました。
However, the community experienced several problems with versions 1 and 2, including a lack of transparency, a lack of avenues for community input into policy definition, and unclear lines of authority and responsibility.
ただし、コミュニティは、透明性の欠如、政策定義へのコミュニティ入力の手段の欠如、権威と責任の明確なラインなど、バージョン1と2にいくつかの問題を経験しました。
To address these problems, in 2020, the IAB formed the RFC Editor Future Development Program to conduct a community discussion and consensus process for the further evolution of the RFC Editor Model. Under the auspices of this Program, the community considered changes that would increase transparency and community input regarding the definition of policies for the RFC Series as a whole, while at the same time ensuring the continuity of the RFC Series, maintaining the quality and timely publication of RFCs, ensuring document accessibility, and clarifying lines of authority and responsibility.
これらの問題に対処するために、2020年にIABはRFCエディターの将来の開発プログラムを形成し、RFCエディターモデルのさらなる進化のためのコミュニティディスカッションとコンセンサスプロセスを実施しました。このプログラムの後援の下で、コミュニティは、RFCシリーズ全体のポリシーの定義に関する透明性とコミュニティ入力を高める変化を検討し、同時にRFCシリーズの継続性を確保し、品質とタイムリーな出版を維持しますRFCS、ドキュメントのアクセシビリティを確保し、権限と責任の明確化を確保します。
This document is the result of discussion within the Program and describes version 3 of the RFC Editor Model while remaining consistent with [RFC8729].
このドキュメントは、プログラム内での議論の結果であり、[RFC8729]と一致しながら、RFCエディターモデルのバージョン3について説明します。
The following sections describe the changes from version 2 in more detail.
次のセクションでは、バージョン2の変更についてさらに詳しく説明します。
Several responsibilities previously assigned to the RFC Editor or,
more precisely, the RFC Editor function, are now performed by the
RSWG, RSAB, RPC, RSCE, and IETF LLC (alone or in combination). These
include various aspects of strategic leadership (Section 2.1.1 of
[RFC8728]), representation of the RFC Series (Section 2.1.2 of
[RFC8728]), development of RFC production and publication
(Section 2.1.3 of [RFC8728]), development of the RFC Series
(Section 2.1.4 of [RFC8728]), operational oversight (Section 3.3 of
[RFC8729]), policy oversight (Section 3.4 of [RFC8729]), the editing,
processing, and publication of documents (Section 4.2 of [RFC8729]),
and development and maintenance of guidelines and rules that apply to
the RFC Series (Section 4.4 of [RFC8729]). Among other things, this
changes the dependency on the RFC Series Editor (RSE) included in
Section 2.2 of [RFC8730] with regard to "coordinating work and
conforming to general RFC Series policies as specified by the IAB and
RSE." In addition, various details regarding these responsibilities
have been modified to accord with the framework defined in this
document.
Implied by the changes outlined in the previous section, the responsibilities of the RFC Series Editor (RSE) as a person or role (contrasted with the overall RFC Editor function) are now split or shared among the RSWG, RSAB, RSCE, RPC, and IETF LLC (alone or in combination). More specifically, the responsibilities of the RFC Series Consulting Editor (RSCE) under version 3 of the RFC Editor Model differ in many ways from the responsibilities of the RFC Series Editor under version 2 of the RFC Editor Model. In general, references in existing documents to the RSE can be taken as referring to the RFC Editor function as described herein but should not be taken as referring to the RSCE.
前のセクションで概説された変更に暗示されているため、RFCシリーズエディター（RSE）の個人または役割（RFCエディター関数全体とは対照的）としての責任が、RSWG、RSAB、RSCE、RPC、およびRPC、および共有されるようになりました。IETF LLC（単独または組み合わせ）。より具体的には、RFCエディターモデルのバージョン3に基づくRFCシリーズコンサルティングエディター（RSCE）の責任は、RFCエディターモデルのバージョン2に基づくRFCシリーズエディターの責任とさまざまな点で異なります。一般に、RSEへの既存のドキュメントの参照は、本明細書に記載されているRFCエディター関数を参照すると見なすことができますが、RSCEを参照するとは見なされません。
In practice, the RFC Production Center (RPC) and RFC Publisher roles have been performed by the same entity, and this practice is expected to continue; therefore, this document dispenses with the distinction between these roles and refers only to the RPC.
実際には、RFC生産センター（RPC）とRFCの出版社の役割は同じエンティティによって実行されており、この慣行は継続されると予想されています。したがって、このドキュメントはこれらの役割の区別を分配し、RPCのみを参照します。
Under earlier versions of the RFC Editor Model, the IAB was responsible for oversight of the RFC Series and acted as a body for final conflict resolution regarding the RFC Series. The IAB's authority in these matters is described in the IAB Charter ([RFC2850], as updated by [RFC9283]). Under version 2 of the RFC Editor Model, the IAB delegated some of its authority to the RFC Series Oversight Committee (see Section 9.5). Under version 3 of the RFC Editor Model, authority for policy definition resides with the RSWG as an independent venue for work by members of the community (with approval of policy proposals being the responsibility of the RSAB, which represents the streams and includes the RSCE), whereas authority for policy implementation resides with the IETF LLC.
RFCエディターモデルの以前のバージョンでは、IABはRFCシリーズの監視を担当し、RFCシリーズに関する最終的な紛争解決の団体として機能しました。これらの問題におけるIABの権限は、[RFC9283]によって更新されたIABチャーター（[RFC2850]）に記載されています。RFCエディターモデルのバージョン2では、IABはその権限の一部をRFCシリーズ監視委員会に委任しました（セクション9.5を参照）。RFCエディターモデルのバージョン3では、ポリシー定義の権限は、RSWGにコミュニティのメンバーによる独立した作業の場として存在します（ポリシー提案の承認は、RSABの責任であり、ストリームを表し、RSCEを含む）、一方、政策実施の権限はIETF LLCに存在します。
In practice, the relationships and lines of authority and responsibility between the IAB, RSOC, and RSE have proved unwieldy and somewhat opaque. To overcome some of these issues, this document dispenses with the RSOC. References to the RSOC in documents such as [RFC8730] are obsolete because this document disbands the RSOC.
実際には、IAB、RSOC、およびRSEの間の関係と権威、責任のラインは、扱いにくく、やや不透明であることが証明されています。これらの問題のいくつかを克服するために、このドキュメントはRSOCに分配されます。[RFC8730]などのドキュメントのRSOCへの参照は、このドキュメントがRSOCを解散するため、時代遅れです。
Version 1 of the RFC Editor Model [RFC5620] specified the existence of the RFC Series Advisory Group (RSAG), which was no longer specified in version 2 of the RFC Editor Model. For the avoidance of doubt, this document affirms that the RSAG has been disbanded. (The RSAG is not to be confused with the RFC Series Approval Board (RSAB), which this document establishes.)
RFCエディターモデル[RFC5620]のバージョン1は、RFCエディターモデルのバージョン2でははや指定されていないRFCシリーズアドバイザリーグループ（RSAG）の存在を指定しました。疑いを回避するために、この文書は、RSAGが解散したことを確認しています。（RSAGは、このドキュメントが確立しているRFCシリーズ承認ボード（RSAB）と混同しないでください。）
This document creates the Editorial Stream in addition to the streams already described in [RFC8729].
このドキュメントは、[RFC8729]ですでに説明されているストリームに加えて、編集ストリームを作成します。
The same security considerations as those in [RFC8729] apply. The processes for the publication of documents must prevent the introduction of unapproved changes. Because multiple entities described in this document (most especially the RPC) participate in maintenance of 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, originals that are not machine-readable) need to be secured against data storage failure.
[RFC8729]のセキュリティに関する考慮事項と同じセキュリティ上の考慮事項が適用されます。ドキュメントを公開するプロセスは、承認されていない変更の導入を防ぐ必要があります。このドキュメント（特にRPC）に記載されている複数のエンティティは、出版物のインデックスのメンテナンスに参加しているため、これらの公開されたドキュメントが外部関係者によって変更されるのを防ぐために十分なセキュリティを整える必要があります。RFCドキュメントのアーカイブ、RFCドキュメントを再作成するために必要なソースドキュメント、および関連する元のドキュメント（ERRATA、ツールのリスト、およびいくつかの初期項目の場合、機械可読ではないオリジナルなど）を保護する必要があります。データストレージの障害。
The IETF LLC (along with any other contracting or contracted entities) should take these security considerations into account during the implementation and enforcement of any relevant contracts.
IETF LLCは（他の契約または契約済みのエンティティとともに）、関連する契約の実施と執行中にこれらのセキュリティ上の考慮事項を考慮に入れる必要があります。
The RPC is responsible for coordinating with the IANA to ensure that RFCs accurately document registration processes and assigned values for IANA registries.
RPCは、IANAと調整して、RFCが登録プロセスを正確に文書化し、IANAレジストリに割り当てられた値を保証する責任があります。
The IETF LLC facilitates management of the relationship between the RPC and IANA.
IETF LLCは、RPCとIANAの関係の管理を促進します。
This document does not create a new registry nor does it register any values in existing registries, and no IANA action is required.
このドキュメントは、新しいレジストリを作成することはなく、既存のレジストリに値を登録することも、IANAアクションは必要ありません。
[BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[BCP9] Bradner、S。、「インターネット標準プロセス - 改訂3」、BCP 9、RFC 2026、1996年10月。
Dusseault, L. and R. Sparks, "Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard", BCP 9, RFC 5657, September 2009.
Dusseault、L。およびR. Sparks、「標準のドラフトへの進歩のための相互操作と実装レポートに関するガイダンス」、BCP 9、RFC 5657、2009年9月。
Housley, R., Crocker, D., and E. Burger, "Reducing the Standards Track to Two Maturity Levels", BCP 9, RFC 6410, October 2011.
Housley、R.、Crocker、D。、およびE. Burger、「標準の追跡を2つの成熟レベルに削減する」、BCP 9、RFC 6410、2011年10月。
Resnick, P., "Retirement of the "Internet Official Protocol Standards" Summary Document", BCP 9, RFC 7100, December 2013.
Resnick、P。、「「インターネット公式プロトコル標準の退職」要約文書」、BCP 9、RFC 7100、2013年12月。
Kolkman, O., Bradner, S., and S. Turner, "Characterization of Proposed Standards", BCP 9, RFC 7127, January 2014.
Kolkman、O.、Bradner、S。、およびS. Turner、「提案された基準の特性評価」、BCP 9、RFC 7127、2014年1月。
Dawkins, S., "Increasing the Number of Area Directors in an IETF Area", BCP 9, RFC 7475, March 2015.
Dawkins、S。、「IETFエリアのエリアディレクターの数の増加」、BCP 9、RFC 7475、2015年3月。
Halpern, J., Ed. and E. Rescorla, Ed., "IETF Stream Documents Require IETF Rough Consensus", BCP 9, RFC 8789, June 2020.
Halpern、J.、ed。and E. Rescorla、ed。、「IETFストリームドキュメントにはIETFラフコンセンサスが必要」、BCP 9、RFC 8789、2020年6月。
<https://www.rfc-editor.org/info/bcp9>
[BCP78] Bradner, S., Ed. and J. Contreras, Ed., "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, November 2008.
[BCP78] Bradner、S.、ed。and J. Contreras、ed。、「権利貢献者はIETF Trustに提供」、BCP 78、RFC 5378、2008年11月。
<https://www.rfc-editor.org/info/bcp78>
[BCP79] Bradner, S. and J. Contreras, "Intellectual Property Rights in IETF Technology", BCP 79, RFC 8179, May 2017.
[BCP79] Bradner、S。およびJ. Contreras、「IETFテクノロジーの知的財産権」、BCP 79、RFC 8179、2017年5月。
<https://www.rfc-editor.org/info/bcp79>
[RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, September 1998, <https://www.rfc-editor.org/info/rfc2418>.
[RFC2418] Bradner、S。、「IETFワーキンググループのガイドラインと手順」、BCP 25、RFC 2418、DOI 10.17487/RFC2418、1998年9月、<https://www.rfc-editor.org/info/rfc2418>
[RFC7154] Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54, RFC 7154, DOI 10.17487/RFC7154, March 2014, <https://www.rfc-editor.org/info/rfc7154>.
[RFC7154] Moonesamy、S.、ed。、「行動のためのIETFガイドライン」、BCP 54、RFC 7154、DOI 10.17487/RFC7154、2014年3月、<https://www.rfc-editor.org/info/rfc7154>
[RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, DOI 10.17487/RFC7322, September 2014, <https://www.rfc-editor.org/info/rfc7322>.
[RFC7322]フラナガン、H。およびS.ジノザ、「RFCスタイルガイド」、RFC 7322、DOI 10.17487/RFC7322、2014年9月、<https://www.rfc-editor.org/info/rfc7322>
[RFC7776] Resnick, P. and A. Farrel, "IETF Anti-Harassment Procedures", BCP 25, RFC 7776, DOI 10.17487/RFC7776, March 2016, <https://www.rfc-editor.org/info/rfc7776>.
[RFC7776] Resnick、P。and A. Farrel、「IETF Anti Harassment手順」、BCP 25、RFC 7776、DOI 10.17487/RFC7776、2016年3月、<https://www.rfc-edtor.org/info/rfc7776>。
[RFC7841] Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed., "RFC Streams, Headers, and Boilerplates", RFC 7841, DOI 10.17487/RFC7841, May 2016, <https://www.rfc-editor.org/info/rfc7841>.
[RFC7841] Halpern、J.、Ed。、Daigle、L.、Ed。、およびO. Kolkman、ed。、「RFCストリーム、ヘッダー、およびボイラープレート」、RFC 7841、DOI 10.17487/RFC7841、2016年5月、<HTTPSPSP：//www.rfc-editor.org/info/rfc7841>。
[RFC8716] Resnick, P. and A. Farrel, "Update to the IETF Anti-Harassment Procedures for the Replacement of the IETF Administrative Oversight Committee (IAOC) with the IETF Administration LLC", BCP 25, RFC 8716, DOI 10.17487/RFC8716, February 2020, <https://www.rfc-editor.org/info/rfc8716>.
[RFC8716] Resnick、P。and A. Farrel、「IETF管理監視委員会（IAOC）をIETF管理LLCに交換するためのIETFアンチハラスメント手順の更新」、BCP 25、RFC 8716、DOI 10.17487/RFC871666、2020年2月、<https://www.rfc-editor.org/info/rfc8716>。
[RFC8729] Housley, R., Ed. and L. Daigle, Ed., "The RFC Series and RFC Editor", RFC 8729, DOI 10.17487/RFC8729, February 2020, <https://www.rfc-editor.org/info/rfc8729>.
[RFC8729] Housley、R.、ed。およびL. Daigle編、「RFCシリーズとRFCエディター」、RFC 8729、DOI 10.17487/RFC8729、2020年2月、<https://www.rfc-editor.org/info/rfc8729>。
[RFC8730] Brownlee, N., Ed. and B. Hinden, Ed., "Independent Submission Editor Model", RFC 8730, DOI 10.17487/RFC8730, February 2020, <https://www.rfc-editor.org/info/rfc8730>.
[RFC8730] Brownlee、N.、ed。and B. Hinden、ed。、「Independent Submission Editor Model」、RFC 8730、DOI 10.17487/RFC8730、2020年2月、<https://www.rfc-editor.org/info/rfc8730>。
[RFC2850] Internet Architecture Board and B. Carpenter, Ed., "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000, <https://www.rfc-editor.org/info/rfc2850>.
[RFC2850]インターネットアーキテクチャボードとB.カーペンター編、「インターネットアーキテクチャボードのチャーター（IAB）」、BCP 39、RFC 2850、DOI 10.17487/RFC2850、2000年5月、<https：//www.rfc-editor.org/info/rfc2850>。
[RFC5620] Kolkman, O., Ed. and IAB, "RFC Editor Model (Version 1)", RFC 5620, DOI 10.17487/RFC5620, August 2009, <https://www.rfc-editor.org/info/rfc5620>.
[RFC5620] Kolkman、O.、ed。およびIAB、「RFCエディターモデル（バージョン1）」、RFC 5620、DOI 10.17487/RFC5620、2009年8月、<https://www.rfc-editor.org/info/rfc5620>。
[RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June 2012, <https://www.rfc-editor.org/info/rfc6635>.
[RFC6635] Kolkman、O.、Ed。、Halpern、J.、ed。、およびIAB、「RFCエディターモデル（バージョン2）」、RFC 6635、DOI 10.17487/RFC6635、2012年6月、<https：// www。rfc-editor.org/info/rfc6635>。
[RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, DOI 10.17487/RFC7991, December 2016, <https://www.rfc-editor.org/info/rfc7991>.
[RFC7991] Hoffman、P。、「XML2RFC」バージョン3 Vocabulary "、RFC 7991、DOI 10.17487/RFC7991、2016年12月、<https://www.rfc-editor.org/info/RFC791>。
[RFC8700] Flanagan, H., Ed., "Fifty Years of RFCs", RFC 8700, DOI 10.17487/RFC8700, December 2019, <https://www.rfc-editor.org/info/rfc8700>.
[RFC8700] Flanagan、H.、Ed。、「50年のRFCS」、RFC 8700、DOI 10.17487/RFC8700、2019年12月、<https://www.rfc-editor.org/info/rfc8700>。
[RFC8711] Haberman, B., Hall, J., and J. Livingood, "Structure of the IETF Administrative Support Activity, Version 2.0", BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020, <https://www.rfc-editor.org/info/rfc8711>.
[RFC8711] Haberman、B.、Hall、J。、およびJ. Livingood、「IETF管理サポートアクティビティの構造、バージョン2.0、BCP 101、RFC 8711、DOI 10.17487/RFC8711、2020年2月、<https：//www.rfc-editor.org/info/rfc8711>。
[RFC8728] Kolkman, O., Ed., Halpern, J., Ed., and R. Hinden, Ed., "RFC Editor Model (Version 2)", RFC 8728, DOI 10.17487/RFC8728, February 2020, <https://www.rfc-editor.org/info/rfc8728>.
[RFC8728] Kolkman、O.、Ed。、Halpern、J.、ed。、およびR. Hinden、ed。、 "RFC Editor Model（バージョン2）"、RFC 8728、DOI 10.17487/RFC8728、2020年2月、<https：//www.rfc-editor.org/info/rfc8728>。
[RFC8874] Thomson, M. and B. Stark, "Working Group GitHub Usage Guidance", RFC 8874, DOI 10.17487/RFC8874, August 2020, <https://www.rfc-editor.org/info/rfc8874>.
[RFC8874] Thomson、M。and B. Stark、「ワーキンググループGithub使用ガイダンス」、RFC 8874、DOI 10.17487/RFC8874、2020年8月、<https://www.rfc-editor.org/info/rfc8874>
[RFC9283] Carpenter, B., Ed., "IAB Charter Update for RFC Editor Model", BCP 39, RFC 9283, DOI 10.17487/RFC9283, June 2022, <https://www.rfc-editor.org/info/rfc9283>.
[RFC9283] Carpenter、B.、ed。、「RFCエディターモデルのIABチャーターアップデート」、BCP 39、RFC 9283、DOI 10.17487/RFC9283、2022年6月、<https://www.rfc-editor.org/info/RFC9283>。
[STYLEGUIDE] RFC Editor, "Style Guide", <https://www.rfc-editor.org/styleguide/>.
[StyleGuide] RFCエディター、「スタイルガイド」、<https://www.rfc-editor.org/styleguide/>。
IAB Members at the Time of Approval
承認時のIABメンバー
Internet Architecture Board members at the time this document was approved for publication were:
インターネットアーキテクチャ委員会メンバーこの文書が公開されたときに承認された時点は次のとおりです。
Jari Arkko Deborah Brungard Lars Eggert Wes Hardaker Cullen Jennings Mallory Knodel Mirja Kühlewind Zhenbin Li Tommy Pauly David Schinazi Russ White Qin Wu Jiankang Yao
Jari Arkko Deborah Brungard Lars Eggert Wes Hardaker Cullen Jennings Mallory Knodel MirjaKühlewindZhenbinLi Tommy Pauly David Schinazi Russ White Qin Wu Jiankang Yao
This document is the product of the IAB's RFC Editor Future Development Program. The RFC Editor Future Development Program allowed for open participation and used a rough consensus model for decision making.
このドキュメントは、IABのRFCエディターFuture Developmentプログラムの製品です。RFCエディターの将来の開発プログラムは、オープンな参加を可能にし、意思決定に大まかなコンセンサスモデルを使用しました。
Acknowledgments
謝辞
Portions of this document were borrowed from [RFC5620], [RFC6635], [RFC8728], [RFC8729], the Frequently Asked Questions of the IETF Trust, and earlier proposals submitted within the IAB's RFC Editor Future Development Program by Brian Carpenter, Michael StJohns, and Martin Thomson. Thanks to Eliot Lear and Brian Rosen in their role as chairs of the Program for their leadership and assistance. Thanks also for feedback and proposed text to Jari Arkko, Sarah Banks, Carsten Bormann, Scott Bradner, Nevil Brownlee, Ben Campbell, Jay Daley, Martin Dürst, Wesley Eddy, Lars Eggert, Adrian Farrel, Stephen Farrell, Sandy Ginoza, Bron Gondwana, Joel Halpern, Wes Hardaker, Bob Hinden, Russ Housley, Christian Huitema, Ole Jacobsen, Sheng Jiang, Benjamin Kaduk, John Klensin, Murray Kucherawy, Mirja Kühlewind, Ted Lemon, John Levine, Lucy Lynch, Jean Mahoney, Andrew Malis, Larry Masinter, S. Moonesamy, Russ Mundy, Mark Nottingham, Tommy Pauly, Colin Perkins, Julian Reschke, Eric Rescorla, Alvaro Retana, Adam Roach, Dan Romascanu, Doug Royer, Alice Russo, Rich Salz, John Scudder, Stig Venaas, Tim Wicinski, and Nico Williams.
このドキュメントの一部は、[RFC5620]、[RFC6635]、[RFC8728]、[RFC8729]、IETFトラストのよくある質問、およびブライアンカーペンター、マイケルStJohnsのIABのRFCエディター将来開発プログラム内で提出された以前の提案から借用されました。 、そしてマーティン・トムソン。リーダーシップと支援のためのプログラムの椅子としての彼らの役割において、エリオット・リアとブライアン・ローゼンに感謝します。フィードバックとJari Arkko、Sarah Banks、Carsten Bormann、Scott Bradner、Nevil Brownlee、Ben Campbell、Jay Daley、MartinDürst、Wesley Eddy、Lars Eggert、Adrian Farrel、Stephen Farrell、Sandy Ginozaジョエル・ハルパーン、ウェス・ハーダーカー、ボブ・ヒンデン、ラス・ハウズリー、クリスチャン・フイテマ、オレ・ヤコブセン、シェン・ジアン、ベンジャミン・カドゥク、ジョン・クレンシン、マレー・クレチン、ミルジャ・キュルウィンド、テッド・レモン、ジョン・レヴァイン、ルーシー・リンチ、ジャン・マホニー、ラリー・マス、ラリー・マス、ラリー・マス、S。ムーネミー、ラス・マンディ、マーク・ノッティンガム、トミー・ポーリー、コリン・パーキンス、ジュリアン・レシュケ、エリック・レスカルラ、アルバロ・レタナ、アダム・ローチ、ダン・ロマスカヌ、ダグ・ロイヤー、アリス・ルッソ、リッチ・ザズ、ジョン・スカッダー、スティグ・ベニース、ティム・ウィシンキ、ニコ・ウィリアムズ。
Author's Address
著者の住所
Peter Saint-Andre (editor) Email: stpeter@stpeter.im
Peter Saint-Andre（編集者）メール：stpeter@stpeter.im