Network Working Group H. Alvestrand
Request for Comments: 3932 October 2004
BCP: 92
Updates: 3710, 2026
Category: Best Current Practice
The IESG and RFC Editor Documents: Procedures
Status of this Memo
このメモの位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document describes the IESG's procedures for handling documents submitted for RFC publication via the RFC Editor, subsequent to the changes proposed by the IESG at the Seoul IETF, March 2004.
この文書は、ソウルIETF、2004年3月にIESGによって提案された変更の後にRFC EditorでRFCの出版のために提出された書類を処理するためのIESGの手順について説明します。
This document updates procedures described in RFC 2026 and RFC 3710.
このドキュメントの更新手順は、RFC 2026およびRFC 3710で説明します。
There are a number of different methods by which an RFC is published, some of which include review in the Internet Engineering Task Force (IETF), and some of which include approval by the Internet Engineering Steering Group (IESG):
そこIETF（Internet Engineering Task Force）で検討を含め、いくつかのそれらのRFCが公開されたことにより、多くの異なる方法は、であり、そのうちのいくつかは、インターネットエンジニアリング運営グループ（IESG）による承認を含めます：
o IETF Working Group (WG) to Standards Track: Includes WG consensus, review in the IETF, IETF Last Call, and IESG approval
標準化過程へのO IETFワーキンググループ（WG）：、IETF、IETFラストコール、およびIESGの承認でレビューをWGコンセンサスが含まれています
o IETF WG to Experimental/Informational: Includes WG consensus, review in the IETF, and IESG approval
実験/情報へのIETF WG O：WGコンセンサス、IETFでのレビュー、およびIESGの承認が含まれています
o Area Director (AD) sponsored to Standards Track: Includes review in the IETF, IETF Last Call, and IESG approval
Oエリアディレクター（AD）標準化過程への後援は：IETF、IETFラストコール、およびIESGの承認でのレビューが含まれています
o AD Sponsored Individual to Experimental/Informational: Includes some form of review in the IETF and IESG approval
O実験/情報へのADスポンサー個人は：IETFとIESG承認でのレビューのいくつかのフォームが含まれています
o Documents for which special rules exist o RFC Editor documents to Experimental/Informational
特別なルールが実験/情報にRFC Editorの文書oを存在しているOドキュメント
This memo is only concerned with the IESG processing of the last category.
このメモは最後のカテゴリーのIESG処理のみに関心があります。
Special rules apply to some documents, including documents from the Internet Architecture Board (IAB), April 1st RFCs, and republication of documents from other standards development organizations. The IESG and the RFC Editor keep a running dialogue, in consultation with the IAB, on these other documents and their classification, but they are outside the scope of this memo.
特別な規則は、インターネットアーキテクチャ委員会（IAB）、4月1日ののRFCからの文書、および他の規格開発機関からの書類の再発行を含め、いくつかの文書に適用されます。 IESGとRFC Editorは、これらの他の文書とその分類に、IABと協議して、実行中の対話を続けるが、彼らはこのメモの範囲外です。
For the last few years, the IESG has reviewed all RFC Editor documents (documents submitted by individuals to the RFC Editor for RFC publication) before publication. In 2003, this review was often a full-scale review of technical content, with the ADs attempting to clear points with the authors, stimulate revisions of the documents, encourage the authors to contact appropriate working groups and so on. This was a considerable drain on the resources of the IESG, and since this is not the highest priority task of the IESG members, it often resulted in significant delays.
過去数年間、IESGは、出版前にすべてのRFC Editorの文書（RFC公表のためにRFC編集者に個人が提出された書類を）検討しています。 2003年には、このレビューは、著者でポイントをクリアした文書の改訂を刺激し、その上で適切なワーキンググループとを連絡する著者を奨励しようとする広告と技術的な内容の本格的な見直しは、しばしばでした。これはIESGのリソースにかなりのドレインで、これはIESGメンバーの最も優先度の高いタスクではないので、それは多くの場合、大幅な遅延が生じました。
In March 2004, the IESG decided to make a major change in this review model. The new review model will have the IESG take responsibility ONLY for checking for conflicts between the work of the IETF and the documents submitted; soliciting technical review is deemed to be the responsibility of the RFC Editor. If an individual IESG member chooses to review the technical content of the document and finds issues, that member will communicate these issues to the RFC Editor, and they will be treated the same way as comments on the documents from other sources.
2004年3月に、IESGが、この口コミモデルに大きな変更を加えることにしました。新しいレビューモデルは、IESGがONLY IETFの作業と提出書類間の競合をチェックするための責任を取る必要があります。勧誘技術審査は、RFCエディタの責任であると思われます。個々のIESGメンバーは、ドキュメントの技術的な内容を検討することを選択したとの問題を見つけた場合、そのメンバーは、RFC編集者にこれらの問題を伝えるだろう、と彼らは他のソースからの文書に対するコメントと同じように扱われます。
Note: This document describes only the review process done by the IESG when the RFC Editor requests that review. There are many other interactions between document editors and the IESG for instance, an AD may suggest that an author submit a document as input for work within the IETF rather than to the RFC Editor, or the IESG may suggest that a document submitted to the IETF is better suited for submission to the RFC Editor but these interactions are not described in this memo.
注：この文書は、審査IESG時にRFC Editorの要求によって行わのみレビュープロセスを説明します。例えば、文書の編集者とIESGの間に他の多くの相互作用がありますが、ADは、著者はIETF内ではなく、RFC編集者への作業のための入力として書類を提出することを示唆したり、IESGは、文書がIETFに提出することを提案してもよいですRFCエディターへの提出に適していますが、これらの相互作用は、このメモに記載されていません。
The review of independent submissions by the IESG was prescribed by RFC 2026 [1] section 4.2.3. The procedure described in this document is compatible with that description.
IESGによって独立した提出物のレビューはRFC 2026 [1]セクション4.2.3で規定されました。この文書に記載された手順は、その説明と互換性があります。
RFC 3710 [4] section 5.2.2 describes the spring 2003 review process (even though the RFC was published in 2004); with the publication of this document, the procedure described in RFC 3710 is no longer relevant to documents submitted via the RFC Editor.
RFC 3710 [4]セクション5.2.2（RFCが2004年に発表されたにも関わらず）2003年春レビュープロセスを記述し、本書の出版物で、RFC 3710で説明する手順は、もはやRFCエディタを経由して提出された書類に関連していません。
The RFC Editor reviews submissions for suitability for publications as RFC. Once the RFC Editor thinks a document may be suited for RFC publication, the RFC Editor asks the IESG to review the documents for conflicts with the IETF standards process or work done in the IETF community.
RFC EditorはRFCとして出版物の適合のために提出を検討します。 RFC Editorは、文書がRFC公表に適しすることができると思ったら、RFC EditorはIETFコミュニティで行わIETF標準化プロセスや仕事との競合のためのドキュメントを確認するためにIESGを要求します。
The review is initiated by a note from the RFC Editor specifying the document name, the RFC Editor's belief about the document's present suitability for publication, and (if possible) the list of people who have reviewed the document for the RFC Editor.
レビューは、ドキュメント名、出版のための文書の現在の適合性についてRFC編集者の信念、そして（可能であれば）RFCエディターのための文書をレビューしている人のリストを指定するRFC編集者からの注記によって開始されます。
The IESG may return five different responses, any of which may be accompanied by an IESG note to be put on the document if the RFC Editor wishes to publish.
IESGは、RFC Editorは公開したい場合は、文書に貼り付けるIESGノートを伴うことがありいずれも5つの異なる応答を返すことがあります。
1. The IESG has not found any conflict between this document and IETF work.
1. IESGは、この文書とIETF仕事との矛盾を見つけていません。
2. The IESG thinks that this work is related to IETF work done in WG <X>, but this does not prevent publishing.
2. IESGは、この作業はWG <X>で行わIETF仕事に関連していると思うが、これは公開を防ぐことはできません。
3. The IESG thinks that publication is harmful to the IETF work done in WG <X> and recommends not publishing the document at this time.
3. IESGは、パブリケーションが<X> WGで行わIETF仕事に有害であり、この時点で文書を公開しないことをお勧めしますと思います。
4. The IESG thinks that this document violates IETF procedures for <X> and should therefore not be published without IETF review and IESG approval.
4. IESGは、この文書は<X>、したがって、IETFレビューとIESGの承認を得ずに公開してはならないためのIETF手順に違反していると考えています。
5. The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval.
5. IESGは、この文書はIETFレビューを必要とするため、IETFレビューとIESGの承認を得ずに公表すべきではない方法で、IETFプロトコルを拡張することを考えています。
The last two responses are included respectively, for the case where a document attempts to take actions (such as registering a new URI scheme) that require IETF consensus or IESG approval (as these terms are defined in RFC 2434 [2]), and for the case where an IETF protocol is proposed to be changed or extended in an unanticipated way that may be harmful to the normal usage of the protocol, but where the protocol documents do not explicitly say that this type of extension requires IETF review.
最後の2つの応答は、文書がIETFコンセンサスまたはIESGの承認を必要とする（例えば、新たなURIスキームを登録するような）行動を取るしようとする場合（これらの用語は、RFC 2434で定義された通りである[2]）のために、そしてために、それぞれ含まれていますプロトコルドキュメントは、明示的に延長のこのタイプは、IETF見直しが必要であることを言っていないところIETFプロトコルが提案されている場合は、変更またはプロトコルの通常の使用に有害かもしれない予期せぬ方法で拡張が、します。
If a document requires IETF review, the IESG will offer the author the opportunity to ask for publication as an AD-sponsored individual document, which is subject to full IESG review, including possible assignment to a WG or rejection. Redirection to the full IESG review path is not a guarantee that the IESG will accept the work item, or even that the IESG will give it any particular priority; it is a guarantee that the IESG will consider the document.
文書はIETFレビューを必要とする場合は、IESGは、著者にWGまたは却下する可能性の割り当てを含む、完全なIESGレビューの対象となるAD主催の個々の文書として公表を求めるための機会を提供します。フルIESGレビューパスへのリダイレクトは、IESGがIESGはそれを任意の特定の優先度を与えることも、作業項目を受け入れるか、という保証はありません。 IESGがドキュメントを検討することを保証するものです。
The IESG will normally have review done within 4 weeks from the RFC Editor's notification. In the case of a possible conflict, the IESG may contact a WG or a WG chair for an outside opinion of whether publishing the document is harmful to the work of the WG and, in the case of a possible conflict with an IANA registration procedure, the IANA expert for that registry.
IESGは通常、審査はRFC編集者の通知から4週間以内に行っています。可能矛盾する場合には、IESGは、IANA登録手順で可能抵触の場合には、文書を公開するWGの作業に有害であるかどうかの外部意見をWG又はWGの椅子に連絡してもよく、そのレジストリのためのIANAの専門家。
Note that if the IESG has not found any conflict between a submission and IETF work, then judging its technical merits, including considerations of possible harm to the Internet, will become the responsibility of the RFC Editor. The IESG assumes that the RFC Editor, in agreement with the IAB, will manage mechanisms for additional technical review.
IESGが提出し、IETFの作業の間に矛盾、そしてインターネットに害を及ぼす可能性の配慮を含め、その技術的なメリットを判断を見つけていない場合は、RFCエディタの責任となりますのでご注意ください。 IESGは、RFC Editorは、IABと一致して、追加の技術レビューのためのメカニズムを管理することを前提としています。
One of the following IESG notes will be sent to the RFC Editor for all documents, with a request for placement either in or immediately following the "Status of this Memo" section of the finished RFC, unless the IESG decides otherwise:
IESGは、そうでないことを決定しない限り、以下のIESGノートの一つは、完成したRFCの「ステータスこのメモの」セクション次の配置や、すぐにどちらかの要求で、すべての文書については、RFC編集者に送信されます。
1. For documents that specify a protocol or other technology, and that have been considered in the IETF at one time:
プロトコルやその他の技術を指定し、それは一度にIETFで検討されている文書の場合1：
The content of this RFC was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work. This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this RFC should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCの内容は、IETFによって考慮一度だったので、それが進行または公開されたIETF仕事で現在IETFの作業に似ていてもよいです。このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のためにと、公開する決定が展開されたプロトコルとセキュリティ、輻輳制御、または不適切な相互作用のようなもののためにIETFレビューに基づいていない特定のノートに、このRFCのフィットネスの知識を負いません。 RFC Editorはその裁量でこの文書を公開することを選択しました。このRFCの読者は実現と展開のためにその値を評価する際に警戒する必要があります。詳細については、RFC 3932を参照してください。
2. For documents that specify a protocol or similar technology and are independent of the IETF process:
プロトコルまたは同様の技術を指定してIETFプロセスとは独立している文書2.：
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のためにと、公開する決定が展開されたプロトコルとセキュリティ、輻輳制御、または不適切な相互作用のようなもののためにIETFレビューに基づいていない特定のノートに、このRFCのフィットネスの知識を負いません。 RFC Editorはその裁量でこの文書を公開することを選択しました。このドキュメントの読者は実現と展開のためにその値を評価する際に警戒する必要があります。詳細については、RFC 3932を参照してください。
3. For documents that do not specify a protocol or similar technology:
プロトコルまたは同様の技術を指定していない文書3.：
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from IESG review for conflict with IETF work. The RFC Editor has chosen to publish this document at its discretion. See RFC 3932 for more information.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のために、このRFCのフィットネスの知識を否認し、公開する決定がIETF仕事との競合のためのIESGレビューとは別にIETFレビューに基づいていないことを指摘しています。 RFC Editorはその裁量でこの文書を公開することを選択しました。詳細については、RFC 3932を参照してください。
This section gives a couple of examples where delaying or preventing publication of a document might be appropriate due to conflict with IETF work. It forms part of the background material, not a part of the procedure.
このセクションでは、ドキュメントの遅延または防止の出版物が原因IETF仕事との競合に適切であるかもしれない例をいくつか示します。これは、バックグラウンドの材料ではなく、手順の一部の一部を構成しています。
Rejected Alternative Bypass: A WG is working on a solution to a problem, and a participant decides to ask for publication of a solution that the WG has rejected. Publication of the document will give the publishing party an RFC number to refer to before the WG is finished. It seems better to have the WG product published first, and have the non-adopted document published later, with a clear disclaimer note saying that "the IETF technology for this function is X".
代替バイパス拒否：WGは、問題の解決に取り組んでいる、と参加者は、WGが拒否したソリューションの公表を求めることにしました。文書の公表は、WGが終了する前に参照するために発行するパーティにRFC番号を与えます。明確な免責事項ノート「は、この機能のためのIETF技術がXである」と言って後に出版された文書最初に公開WGの製品を持っている方が良いようだ、と非採用しています。
Example: Photuris (RFC 2522), which was published after IKE (RFC 2409).
例：IKE（RFC 2409）の後に発表されたPhoturis（RFC 2522）、。
Inappropriate Reuse of "free" Bits: In 2003, a proposal for an experimental RFC was published that wanted to reuse the high bits of the "fragment offset" part of the IP header for another purpose. No IANA consideration says how these bits can be repurposed, but the standard defines a specific meaning for them. The IESG concluded that implementations of this experiment risked causing hard-to-debug interoperability problems and recommended not publishing the document in the RFC series. The RFC Editor accepted the recommendation.
「自由な」ビットの不適切な再利用は：2003年、実験RFCの提案は、他の目的のためにIPヘッダの「フラグメントオフセット」部分の上位ビットを再利用したいと発表されました。いいえIANAの考慮事項は、これらのビットは再利用することができますどのように述べていないが、標準的には、彼らのために特定の意味を定義します。 IESGは、この実験の実装が困難なデバッグ相互運用性の問題を引き起こし危険にさらしたとRFCシリーズの文書を公開しませ推奨と結論付けました。 RFC Editorは勧告を受け入れました。
Note: in general, the IESG has no problem with rejected alternatives being made available to the community; such publications can be a valuable contribution to the technical literature. However, it is necessary to avoid confusion with the alternatives the working group did adopt.
注意：一般的に、IESGは拒否の選択肢をコミュニティに利用可能になるとの問題がありません。そのような出版物は、技術文献に価値ある貢献することができます。しかし、ワーキンググループが採用した代替案との混同を避ける必要があります。
The RFC series is one of many available publication channels; this document takes no position on the question of which documents the RFC series is appropriate for. That is a matter for discussion in the IETF community.
RFCシリーズは、多くの利用可能な出版チャネルの一つです。この文書は、RFCシリーズが適している文書その質問に何のポジションを取りません。それは、IETFコミュニティでの議論の問題です。
In its capacity as the body that approves the general policy followed by the RFC Editor (see RFC 2850 [3]), the IAB has reviewed this proposal and supports it as an operational change that is in line with the respective roles of the IESG and RFC Editor. The IAB continues to monitor the range of organized discussions within the IETF about potential adjustments to the IETF document publication processes (e.g., NEWTRK working group) and recognizes that the process described in this document, as well as other general IETF publication processes, may need to be adjusted in the light of the outcome of those discussions.
RFCエディタ（[3] RFC 2850を参照）、続いて一般的なポリシーを承認体としてのその能力において、IABはこの提案を検討しており、IESGのそれぞれの役割と一致している動作の変化としてそれをサポートしてRFCエディタ。 IABは、IETF文書公開プロセスへの潜在的な調整（例えば、NEWTRKワーキンググループ）約IETF内の組織の議論の範囲を監視し続けると、この文書に記載された方法、ならびにその他の一般的なIETFリケーションプロセスは、必要があるかもしれないことを認識しそれらの議論の結果を踏まえて調整することができます。
The process change described in this memo has no direct bearing on the security of the Internet.
このメモに記載されているプロセスの変更は、インターネットのセキュリティには直接関係がありません。
This document is a product of the IESG, and all its members deserve thanks for their contributions.
この文書は、IESGの製品であり、そのすべてのメンバーは、彼らの貢献に感謝に値します。
This document has been reviewed in the IETF and by the RFC Editor and the IAB; the IAB produced the text of section 6. Special thanks go to John Klensin, Keith Moore, Pete Resnick, Scott Bradner, Kurt Zeilenga, Eliot Lear, Paul Hoffman, Brian Carpenter, and all other IETF community members who provided valuable feedback on the document.
この文書は、IETFでRFCと編集者とIABによって検討されています。 IABは6.特別な感謝はジョン・クレンシン、キースムーア、ピート・レズニック、スコット・ブラッドナー、クルトZeilenga、エリオット・リア、ポール・ホフマン、ブライアン・カーペンター、およびドキュメントの貴重なフィードバックを提供し、他のすべてのIETFのコミュニティメンバーに進んセクションのテキストを作成しました。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[2] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[3] Internet Architecture Board and B. Carpenter, Ed., "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000.
[3]インターネットアーキテクチャ委員会とB.カーペンター、エド。、BCP 39、RFC 2850、2000年5月 "インターネットアーキテクチャ委員会（IAB）の憲章"。
[4] Alvestrand, H., "An IESG charter", RFC 3710, February 2004.
[4] Alvestrand、H.、 "IESG憲章"、RFC 3710、2004年2月。
Author's Address
著者のアドレス
Harald Alvestrand
ハラルドAlvestrand
EMail: harald@alvestrand.no
メールアドレス：harald@alvestrand.no
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。