[要約] RFC 3932は、IESGとRFC Editorの手続きに関するドキュメントであり、RFCの編集と承認のプロセスを定義しています。このRFCの目的は、RFCの作成と管理に関する明確な手順を提供することです。
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
IESGおよびRFCエディタードキュメント：手順
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（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.
このドキュメントでは、2004年3月、Seoul IETFで提案された変更に続いて、RFCエディターを介して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):
RFCが公開される多くの異なる方法があり、その一部にはインターネットエンジニアリングタスクフォース（IETF）のレビューが含まれ、その一部にはインターネットエンジニアリングステアリンググループ（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）から標準の追跡：WGコンセンサス、IETFでのレビュー、IETF最終呼び出し、およびIESG承認を含む
o IETF WG to Experimental/Informational: Includes WG consensus, review in the IETF, and IESG approval
o 実験/情報へのIETF WG：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 Last Call、および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
o 特別なルールが存在する文書o RFCエディタードキュメントは実験的/情報を提供します
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日のRFCS、他の標準開発組織からの文書の再公開など、特別な規則にはいくつかのドキュメントに適用されます。IESGとRFCエディターは、これらの他のドキュメントとその分類について、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エディタードキュメント（個人が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はこのレビューモデルに大きな変更を加えることを決定しました。新しいレビューモデルは、IETFの作業と提出されたドキュメントとの間の競合をチェックするためだけにIESGに責任を負わせます。技術レビューの勧誘は、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.
注：このドキュメントは、RFCエディターがそのレビューを要求したときにIESGによって行われたレビュープロセスのみを説明します。たとえば、ドキュメントエディターとIESGの間に他の多くのやり取りがあります。広告は、著者がRFCエディターではなく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は、2003年春のレビュープロセスについて説明しています（RFCが2004年に公開された場合でも）。このドキュメントの公開により、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エディターは、RFCとしての出版物への適合性についての提出をレビューします。RFCエディターがドキュメントがRFCの出版物に適していると考えると、RFCエディターはIESGにIETF標準プロセスまたはIETFコミュニティで行われた作業との競合についてドキュメントを確認するよう求めます。
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は5つの異なる回答を返す場合がありますが、RFCエディターが公開したい場合は、IESGノートを添付する場合があります。
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は、出版物はWG <x>で行われた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手順に違反しているため、IETFレビューとIESGの承認なしに公開されるべきではないと考えています。
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プロトコルを拡張しているため、IETFレビューとIESGの承認なしに公開されるべきではないと考えています。
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.
ドキュメントが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レビューの対象となる広告支援の個々のドキュメントとして公開を求める機会を提供します。完全な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は、文書を公開することがWGの作業に有害であるかどうか、およびIANA登録手順との競合の可能性がある場合、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エディターが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ノートのいずれかが、すべてのドキュメントのRFCエディターに送信され、IESGが別の方法で決定しない限り、完成したRFCの「このメモのステータス」セクションの前または直後に配置のリクエストが行われます。
1. For documents that specify a protocol or other technology, and that have been considered in the IETF at one time:
1. プロトコルまたはその他のテクノロジーを指定し、一度にIETFで検討されているドキュメントの場合：
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は、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄します。特に、公開する決定は、セキュリティ、混雑制御、または展開プロトコルとの不適切な相互作用のIETFレビューに基づいていないことに注意しています。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このRFCの読者は、実装と展開の価値を評価する際に注意する必要があります。詳細については、RFC 3932を参照してください。
2. For documents that specify a protocol or similar technology and are independent of the IETF process:
2. プロトコルまたは同様のテクノロジーを指定し、IETFプロセスとは無関係のドキュメントの場合：
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は、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄します。特に、公開する決定は、セキュリティ、混雑制御、または展開プロトコルとの不適切な相互作用のIETFレビューに基づいていないことに注意しています。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このドキュメントの読者は、実装と展開の価値を評価する際に注意する必要があります。詳細については、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は、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄し、公開する決定はIETFワークとの競合に関するIESGレビューとは別にIETFレビューに基づいていないことに注意してください。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。詳細については、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番号を出版パーティーに提供します。最初にWG製品を公開し、後で採用されていないドキュメントを公開する方が良いようです。「この関数のIETFテクノロジーはX」という明確な免責事項メモが記録されています。
Example: Photuris (RFC 2522), which was published after IKE (RFC 2409).
例：IKE（RFC 2409）の後に公開されたPhyuris（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年に、別の目的のためにIPヘッダーの「フラグメントオフセット」部分のハイビットを再利用したいという実験的RFCの提案が公開されました。IANAの考慮は、これらのビットをどのように再利用できるかを述べていませんが、標準はそれらの特定の意味を定義しています。IESGは、この実験の実装により、非難が困難な相互運用性の問題を引き起こし、RFCシリーズでドキュメントを公開しないことを推奨することが推奨されると結論付けました。RFCエディターは推奨事項を受け入れました。
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シリーズは、利用可能な多くの出版チャネルの1つです。このドキュメントは、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エディターが承認する機関としての能力において（RFC 2850 [3]を参照）、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のテキストを作成しました。ジョンクレンシン、キースムーア、ピートレストニック、スコットブラッドナー、カートゼイレンガ、エリオットリア、ポールホフマン、ブライアンカーペンター、および文書に関する貴重なフィードバックを提供してくれた他のすべてのIETFコミュニティメンバーに特別に感謝します。。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner、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] Internet Architecture Board and B. Carpenter、ed。、「Internet Architecture Board（IAB）のチャーター」、BCP 39、RFC 2850、2000年5月。
[4] Alvestrand, H., "An IESG charter", RFC 3710, February 2004.
[4] Alvestrand、H。、「IESGチャーター」、RFC 3710、2004年2月。
Author's Address
著者の連絡先
Harald Alvestrand
ハラルド・アルベスランド
EMail: harald@alvestrand.no
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。