[要約] RFC 5742は、独立したおよびIRTFストリームの提出物の処理に関するIESG手順を定めています。このRFCの目的は、これらの提出物を効果的かつ公平に処理するための手順を提供することです。
Internet Engineering Task Force (IETF) H. Alvestrand
Request for Comments: 5742 Google
BCP: 92 R. Housley
Obsoletes: 3932 Vigil Security
Updates: 2026, 3710 December 2009
Category: Best Current Practice
ISSN: 2070-1721
IESG Procedures for Handling of Independent and IRTF Stream Submissions
独立およびIRTFストリームの提出物を処理するためのIESG手順
Abstract
概要
This document describes the procedures used by the IESG for handling documents submitted for RFC publication from the Independent Submission and IRTF streams.
このドキュメントでは、IESGがRFC出版物に送信したドキュメントを独立した提出およびIRTFストリームから処理するために使用する手順について説明します。
This document updates procedures described in RFC 2026 and RFC 3710.
このドキュメントは、RFC 2026およびRFC 3710で説明されている手順を更新します。
Status of This Memo
本文書の位置付け
This memo documents an Internet Best Current Practice.
このメモは、インターネットの最高の現在の練習を文書化しています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。BCPの詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5742.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5742で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、BSDライセンスに記載されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
RFC 4844 [N1] defines four RFC streams. When a document is submitted for publication, the review that it receives depends on the stream in which it will be published. The four streams defined in RFC 4844 are:
RFC 4844 [N1]は4つのRFCストリームを定義します。公開のためにドキュメントが提出されると、受信するというレビューは、公開されるストリームによって異なります。RFC 4844で定義されている4つのストリームは次のとおりです。
- The IETF stream - The IAB stream - The IRTF stream - The Independent Submission stream
- IETFストリーム-IABストリーム-IRTFストリーム - 独立した提出ストリーム
The IETF is responsible for maintaining the Internet Standards Process, which includes the requirements for developing, reviewing and approving Standards Track and BCP RFCs. These RFCs, and any other IETF-generated Informational or Experimental documents, are reviewed by appropriate IETF bodies [N2] and published as part of the IETF stream.
IETFは、インターネット標準プロセスを維持する責任があります。インターネット標準プロセスには、標準の追跡とBCP RFCの開発、レビュー、承認の要件が含まれます。これらのRFC、およびその他のIETF生成された情報文書または実験文書は、適切なIETFボディ[N2]によってレビューされ、IETFストリームの一部として公開されます。
Documents published in streams other than the IETF stream might not receive any review by the IETF for such things as security, congestion control, or inappropriate interaction with deployed protocols. Generally, there is no attempt for IETF consensus or IESG approval. Therefore, the IETF disclaims, for any of the non-IETF stream documents, any knowledge of the fitness of those RFCs for any purpose.
IETFストリーム以外のストリームで公開されているドキュメントは、セキュリティ、混雑制御、展開プロトコルとの不適切な相互作用など、IETFによるレビューを受け取っていない場合があります。一般に、IETFコンセンサスまたはIESGの承認の試みはありません。したがって、IETFは、いずれかの非IITFストリームドキュメントのいずれかについて、あらゆる目的のためにそれらのRFCのフィットネスに関する知識を否認します。
IESG processing described in this document is concerned only with the last two categories, which comprise the Independent Submission stream and the IRTF stream, respectively [N1].
このドキュメントで説明されているIESG処理は、それぞれ独立した提出ストリームとIRTFストリームを含む最後の2つのカテゴリにのみ関係しています[N1]。
Following the approval of RFC 2026 [N2] and prior to the publication of RFC 3932 [I1], the IESG reviewed all Independent Submission stream documents before publication. This review was often a full-scale review of technical content, with the Area Directors (ADs) attempting to clear points with the authors, stimulate revisions of the documents, encourage the authors to contact appropriate working groups (WGs), and so on. This was a considerable drain on the resources of the IESG, and because this was not the highest priority task of the IESG members, it often resulted in significant delays.
RFC 2026 [N2]の承認後、RFC 3932 [I1]の公開前に、IESGは公開前にすべての独立した提出ストリーム文書をレビューしました。このレビューは、多くの場合、技術コンテンツの本格的なレビューであり、エリアディレクター（AD）が著者とのポイントをクリアし、文書の改訂を刺激しようとし、著者が適切なワーキンググループ（WGS）に連絡するように促します。これはIESGのリソースのかなりの流出であり、これはIESGメンバーの最優先タスクではなかったため、多くの場合、大きな遅延をもたらしました。
In March 2004, the IESG decided to make a major change in this review model, with the IESG taking 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 AD chooses to review the technical content of the document and finds issues, that AD 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は、IETFの作業と提出されたドキュメントの間の競合をチェックすることのみを担当する責任を負いました。技術レビューの勧誘は、RFCエディターの責任であるとみなされます。個々の広告がドキュメントの技術コンテンツを確認し、問題を見つけることを選択した場合、その広告はこれらの問題をRFCエディターに伝え、他のソースからのドキュメントに関するコメントと同じように扱われます。
Prior to 2006, documents from the IRTF were treated as either IAB submissions or Independent Submissions via the RFC Editor. However, the Internet Research Steering Group (IRSG) has established a review process for the publication of RFCs from the IRTF stream [I2]. Once these procedures are fully adopted, the IESG will be responsible only for checking for conflicts between the work of the IETF and the documents submitted, but results of the check will be reported to the IRTF. These results may be copied to the RFC Editor as a courtesy.
2006年以前は、IRTFからの文書は、RFCエディターを介してIAB提出または独立した提出物として扱われていました。しかし、インターネットリサーチステアリンググループ（IRSG）は、IRTFストリーム[I2]からのRFCSの公開に関するレビュープロセスを確立しています。これらの手順が完全に採用されると、IESGはIETFの作業と提出されたドキュメントの間の競合のチェックのみを担当しますが、チェックの結果はIRTFに報告されます。これらの結果は、礼儀としてRFCエディターにコピーされる場合があります。
This document describes only the review process done by the IESG when the RFC Editor or the IRTF requests that review. The RFC Editor will request the review of Independent Submission stream documents, and the IRTF will request review of IRTF stream documents. 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 as part of the Independent Submission stream, or the IESG may suggest that a document submitted to the IETF is better suited for submission to the RFC Editor as part of Independent Submission stream, but these interactions are not described in this memo.
このドキュメントでは、RFCエディターまたはIRTFがそのレビューを要求したときにIESGによって行われたレビュープロセスのみを説明します。RFCエディターは、独立した提出ストリームドキュメントのレビューを要求し、IRTFはIRTFストリームドキュメントのレビューを要求します。ドキュメントエディターとIESGの間には他の多くの相互作用があります。たとえば、広告は、著者が独立した提出ストリームの一部としてRFCエディターではなく、IETF内の作業の入力としてドキュメントを提出することを示唆する場合があります。IETFに送信されたドキュメントは、独立した提出ストリームの一部としてRFCエディターへの提出に適していることを提案しますが、これらの相互作用はこのメモでは説明されていません。
For the convenience of the reader, this document includes description of some actions taken by the RFC Editor, the IAB, and the IRSG. The inclusion of these actions is not normative. Rather, these actions are included to describe the overall process surrounding the normative IESG procedures described in this document. No RFC Editor, IAB, or IRSG procedures are set by this document.
読者の便利さのために、このドキュメントには、RFCエディター、IAB、およびIRSGが取ったいくつかのアクションの説明が含まれています。これらのアクションを含めることは規範的ではありません。むしろ、これらのアクションは、このドキュメントで説明されている規範的なIESG手順を取り巻く全体的なプロセスを記述するために含まれています。このドキュメントにより、RFCエディター、IAB、またはIRSG手順は設定されていません。
RFC 3932 provided procedures for the review of Independent Submission stream submissions. With the definition of procedures by the IRSG for the IRTF stream, it has become clear that similar procedures apply to the review by the IESG of IRTF stream documents.
RFC 3932は、独立した提出ストリーム提出のレビューの手順を提供しました。IRTFストリームのIRSGによる手順の定義により、IESG of IRTFストリームドキュメントによるレビューに同様の手順が適用されることが明らかになりました。
The IAB and the RFC Editor have made updates to the formatting of the title page for all RFCs [N3]. With these changes, the upper left hand corner of the title page indicates the stream that produced the RFC. This label replaces some of the information that was previously provided in mandatory IESG notes on non-IETF-stream documents.
IABとRFCエディターは、すべてのRFC [N3]のタイトルページのフォーマットを更新しました。これらの変更により、タイトルページの左上隅は、RFCを生成したストリームを示します。このラベルは、以前に非IESGストリームドキュメントに関する必須のIESGノートで提供されていた情報の一部を置き換えます。
The IESG may request the inclusion of an IESG note in an Independent Submission or IRTF stream document to explain the specific relationship, if any, to IETF work. In case there is a dispute about the content of the IESG note, this document provides a dispute resolution process.
IESGは、IETF作業との特定の関係を説明するために、独立した提出またはIRTFストリームドキュメントにIESGノートを含めることを要求する場合があります。IESGノートの内容について紛争がある場合、このドキュメントは紛争解決プロセスを提供します。
The review of Independent Submissions by the IESG was prescribed by RFC 2026 [N2], Section 4.2.3. The procedure described in this document is compatible with that description.
IESGによる独立した提出のレビューは、RFC 2026 [N2]、セクション4.2.3によって規定されました。このドキュメントで説明されている手順は、その説明と互換性があります。
The procedures developed by the IRTF for documents created by the Research Groups also include review by the IESG [I2].
IRTFが研究グループによって作成された文書のために開発された手順には、IESG [I2]によるレビューも含まれます。
The IESG Charter (RFC 3710 [I5], Section 5.2.2) describes the review process that was employed in Spring 2003 (even though the RFC was not published until 2004); with the publication of RFC 3932 [I1], the procedure described in RFC 3710 was no longer relevant to documents submitted via the RFC Editor. The publication of this document further updates Section 5.2.2 of RFC 3710, now covering both the IRTF and the Independent Submission streams.
IESGチャーター（RFC 3710 [I5]、セクション5.2.2）は、2003年春に採用されたレビュープロセスについて説明しています（RFCは2004年まで公開されていませんでしたが）。RFC 3932 [I1]の公開により、RFC 3710で説明されている手順は、RFCエディターを介して提出されたドキュメントに関連しなくなりました。このドキュメントの公開は、RFC 3710のセクション5.2.2をさらに更新し、現在IRTFと独立した提出ストリームの両方をカバーしています。
The RFC Editor reviews Independent Submission stream submissions for suitability for publication as RFCs. As described in RFC 4846 [I3], 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エディターは、RFCSとしての公開の適合性について、独立した提出ストリーム提出をレビューします。RFC 4846 [i3]で説明されているように、RFCエディターはIESGに、IETFコミュニティで行われたIETF標準プロセスまたは作業との競合についてドキュメントを確認するように依頼します。
Similarly, documents intended for publication as part of the IRTF stream are sent to the IESG for review for conflicts with the IETF standards process or work done in the IETF community [I2].
同様に、IRTFストリームの一部として公開を目的とした文書は、IETF標準プロセスまたはIETFコミュニティで行われた作業との競合のレビューのためにIESGに送信されます[I2]。
The IESG review of these Independent Submission and IRTF stream documents results in one of the following five types of conclusion, any of which may be accompanied by a request to include an IESG note if the document is published.
これらの独立した提出およびIRTFストリームドキュメントのIESGレビューでは、次の5つのタイプの結論のいずれかがあります。そのいずれにも、ドキュメントが公開されている場合はIESGノートを含めるという要求が伴う場合があります。
1. The IESG has concluded that there is no conflict between this document and IETF work.
1. IESGは、このドキュメントとIETFの作業の間に矛盾はないと結論付けました。
2. The IESG has concluded that this work is related to IETF work done in WG <X>, but this relationship does not prevent publishing.
2. IESGは、この作業はWG <x>で行われたIETF作業に関連していると結論付けていますが、この関係は公開を妨げません。
3. The IESG has concluded that publication could potentially disrupt the IETF work done in WG <X> and recommends not publishing the document at this time.
3. IESGは、出版物がWG <x>で行われたIETF作業を潜在的に混乱させる可能性があると結論付けており、現時点ではドキュメントを公開しないことを推奨しています。
4. The IESG has concluded that this document violates IETF procedures for <Y> and should therefore not be published without IETF review and IESG approval.
4. IESGは、このドキュメントが<y>のIETF手順に違反しているため、IETFレビューとIESGの承認なしに公開されるべきではないと結論付けました。
5. The IESG has concluded 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 RFC headers and boilerplate [N3] is intended to describe the relationship of the document to the IETF standards process. In exceptional cases, when the relationship of the document to the IETF standards process might be unclear, the IESG may request the inclusion of an IESG note to clarify the relationship of the document to the IETF standards process. Such a note is likely to include pointers to related IETF RFCs. The dispute resolution process in Section 4 is provided to handle situations in which the IRSG or RFC Editor is concerned with the content of the requested IESG note.
RFCヘッダーとボイラープレート[N3]は、ドキュメントのIETF標準プロセスとの関係を説明することを目的としています。例外的な場合、ドキュメントとIETF標準プロセスとの関係が不明な場合、IESGはIESGノートを含めることを要求して、ドキュメントのIETF標準プロセスとの関係を明確にすることができます。このようなメモには、関連するIETF RFCへのポインターが含まれる可能性があります。セクション4の紛争解決プロセスは、IRSGまたはRFCエディターが要求された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 Review, Standards Action, or IESG Approval (as these terms are defined in RFC 5226 [I6]), and for the case where there is a proposed change or extension to an IETF protocol that was not anticipated by the original authors and that may be detrimental 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スキームの登録など）を実行しようとする場合、それぞれ最後の2つの回答が含まれています（これらの用語はRFC 5226 [I6]で定義されているため、IESGの承認が必要です。）、そして、元の著者によって予想されていない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 IETF 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または拒否への割り当ての可能性を含む完全なIETFレビューの対象となる広告支援の個々のドキュメントとして公開を求める機会を提供します。完全なIESGレビューパスへのリダイレクトは、IESGが作業項目を受け入れること、またはIESGが特定の優先順位を与えることを保証するものではありません。IESGがドキュメントを検討することは保証です。
The IESG will normally complete review within four weeks of notification by the RFC Editor or IRTF. 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 that WG and, in the case of a possible conflict with an IANA registration procedure, the IANA expert for that registry.
IESGは通常、RFCエディターまたはIRTFによる通知から4週間以内にレビューを完了します。紛争の可能性がある場合、IESGは、文書を公開することがそのWGの作業に有害であるかどうか、およびIANA登録手続きとの競合の可能性がある場合、WGまたはWG椅子に連絡することができます。そのレジストリのIANAの専門家。
If the IESG does not find any conflict between an Independent Submission and IETF work, then the RFC Editor is responsible for judging the technical merits for that submission, including considerations of possible harm to the Internet. If the IESG does not find any conflict between an IRTF submission and IETF work, then the IRSG is responsible for judging the technical merits for that submission, including considerations of possible harm to the Internet.
IESGが独立した提出とIETFの作業との間に矛盾を見つけられない場合、RFCエディターは、インターネットへの害の可能性のある考慮事項を含む、その提出の技術的メリットを判断する責任があります。IESGがIRTFの提出とIETFの作業との間に競合を見つけられない場合、IRSGは、インターネットへの害の可能性のある考慮事項を含む、その提出の技術的メリットを判断する責任があります。
The RFC Editor, in agreement with the IAB, shall manage mechanisms for appropriate technical review of Independent Submissions. Likewise, the IRSG, in agreement with the IAB, shall manage mechanisms for appropriate technical review of IRTF submissions.
RFCエディターは、IABと一致して、独立した提出物の適切な技術レビューのためにメカニズムを管理するものとします。同様に、IRSGは、IABと一致して、IRTF提出の適切な技術レビューのためにメカニズムを管理するものとします。
Experience has shown that the IESG and the RFC Editor have worked well together regarding publication recommendations and IESG notes. Where questions have arisen, they have been quickly resolved when all parties become aware of the concerns. However, should a dispute ever arise, a third party can assist with resolution. Therefore, this dispute procedure has an informal dialogue phase followed by an arbitration phase if the matter remains unresolved.
経験によると、IESGとRFCエディターは、出版物の推奨事項とIESGノートに関してうまく機能していることが示されています。疑問が生じた場合、すべての当事者が懸念を認識したとき、彼らはすぐに解決されました。ただし、紛争が発生した場合、第三者は解決を支援できます。したがって、この紛争手続きには、問題が未解決のままである場合、非公式の対話段階に続いて仲裁段階が続きます。
If the IESG requests the inclusion of an IESG note and the IRSG or the RFC Editor intends to publish the document without the requested IESG note, then they must provide a clear and concise description of the concerns to the IESG before proceeding. A proposal for alternate IESG note text from the IRSG or the RFC Editor is highly encouraged.
IESGがIESGノートの包含を要求し、IRSGまたはRFCエディターが要求されたIESGノートなしでドキュメントを公開する予定の場合、進行する前にIESGに懸念事項の明確かつ簡潔な説明を提供する必要があります。IRSGまたはRFCエディターからの代替IESGノートテキストの提案を強くお勧めします。
If the IESG does not want the document to be published without the requested IESG note, then the IESG must initiate an informal dialogue. The dialogue should not take more than six weeks. This period of time allows the IESG to conduct an IETF Last Call concerning the content of the requested IESG note (and not on the document as a whole) to determine community consensus if desired. At the end of the dialogue, the IESG can reaffirm the original IESG note, provide an alternate IESG note, or withdraw the note altogether. If an IESG note is requested, the IRSG or the RFC Editor must state whether they intend to include it.
IESGが要求されたIESGノートなしでドキュメントを公開したくない場合、IESGは非公式の対話を開始する必要があります。対話には6週間以上かかるべきではありません。この期間により、IESGは、要求されたIESGノートのコンテンツ（ドキュメント全体ではなく）のコンテンツに関するIETFの最後の呼び出しを実施して、必要に応じてコミュニティのコンセンサスを決定できます。ダイアログの最後に、IESGは元のIESGノートを再確認したり、代替IESGノートを提供したり、メモを完全に撤回したりできます。IESGノートが要求された場合、IRSGまたはRFCエディターは、ISGを含めるつもりかどうかを述べる必要があります。
If dialogue fails to resolve IRSG or RFC Editor concerns with the content of a requested IESG note and they intend to publish the document as an RFC without the requested IESG note, then the IESG can formally ask the IAB to provide arbitration. The IAB is not obligated to perform arbitration and may decline the request. If the IAB declines, the RFC Editor decides whether the IESG note is included. If the IAB accepts, the IAB review will occur according to procedures of the IAB's own choosing. The IAB can direct the inclusion of the IESG note, direct the withdrawal of the IESG note, or leave the final decision to the RFC Editor. Unlike the IAB reviews specified in RFC 4846 [I3], if the IAB directs the inclusion or withdrawal the IESG note, the IAB decision is binding, not advisory.
DialogueがIRSGまたはRFCエディターの懸念を要求されたIESGノートの内容に関する懸念を解決できず、要求されたIESGノートなしでドキュメントをRFCとして公開する予定の場合、IESGは正式にIABに仲裁を提供するように依頼できます。IABは仲裁を実行する義務はなく、要求を拒否する可能性があります。IABが辞退した場合、RFCエディターはIESGノートが含まれているかどうかを決定します。IABが受け入れると、IABの選択肢の手順に従ってIABレビューが発生します。IABは、IESGノートの包含を指示したり、IESGノートの撤回を指示したり、RFCエディターに最終決定を任せることができます。RFC 4846 [I3]で指定されたIABレビューとは異なり、IABがIESGノートを包含または撤回する場合、IABの決定はアドバイザリーではなく拘束力があります。
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:
拒否された代替バイパス：
As a WG is working on a solution to a problem, a participant decides to ask for Independent Submission stream publication of a solution that the WG has rejected. Publication of the document will give the publishing party an RFC number 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）。
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 adopted by the WG.
注：一般的に、IESGは、コミュニティが利用できるようになった拒否された代替案に問題はありません。このような出版物は、技術文献への貴重な貢献となる可能性があります。ただし、WGが採用した代替案との混乱を避ける必要があります。
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エディターは推奨事項を受け入れました。
The RFC series is one of many available publication channels; this document takes no position on the question of which documents are appropriate for publication in the RFC Series. That is a matter for discussion in the Internet community.
RFCシリーズは、利用可能な多くの出版チャネルの1つです。このドキュメントは、どのドキュメントがRFCシリーズに公開するのに適しているかという問題についての立場を取得しません。それはインターネットコミュニティでの議論の問題です。
In its capacity as the body that approves the general policy followed by the RFC Editor (see RFC 2850 [I4]), the IAB has reviewed this proposal and supports it as an operational change that is in line with the respective roles of the IESG, IRTF, and RFC Editor. The IAB continues to monitor discussions within the IETF about potential adjustments to the IETF document publication processes and recognizes that the process described in this document, as well as other general IETF publication processes, may need to be adjusted to align with any changes that result from such discussions.
一般的なポリシーに続くRFCエディターが承認する身体としての能力において（RFC 2850 [i4]を参照）、IABはこの提案をレビューし、IESGのそれぞれの役割に沿った運用変更としてサポートしています。IRTF、およびRFCエディター。IABは、IETFのIETFドキュメントの公開プロセスに対する潜在的な調整に関するIETF内での議論を引き続き監視し、このドキュメントで説明したプロセス、および他の一般的なIETF公開プロセスであることを認識しています。そのような議論。
The process change described in this memo has no direct bearing on the security of the Internet.
このメモで説明されているプロセスの変更は、インターネットのセキュリティに直接関係していません。
RFC 3932 was a product of the IESG in October 2004, and it was reviewed in the IETF, by the RFC Editor, and by the IAB. Special thanks for the development of RFC 3932 go to (in alphabetical order) Scott Bradner, Brian Carpenter, Paul Hoffman, John Klensin, Eliot Lear, Keith Moore, Pete Resnick, Kurt Zeilenga, and all other IETF community participants who provided valuable feedback.
RFC 3932は2004年10月にIESGの製品であり、IETFでRFCエディター、およびIABによってレビューされました。RFC 3932の開発に感謝します（アルファベット順）スコットブラッドナー、ブライアンカーペンター、ポールホフマン、ジョンクレンシン、エリオットリア、キースムーア、ピートレストニック、カートゼイレンガ、および貴重なフィードバックを提供した他のすべてのIETFコミュニティ参加者。
This update to RFC 3932 was the product of the IESG in July and August of 2008, and it was reviewed in the IETF, by the RFC Editor, by the IRSG, and by the IAB. Special thanks for the development of this update go to (in alphabetical order) Jari Arkko, Ran Atkinson, Leslie Daigle, Lars Eggert, Aaron Falk, Sam Hartman, John Klensin, Olaf Kolkman, and Andy Malis.
RFC 3932のこの更新は、2008年7月と8月のIESGの製品であり、IETF、RFCエディター、IRSG、およびIABによってレビューされました。このアップデートの開発に感謝します（アルファベット順に）Jari Arkko、Ran Atkinson、Leslie Daigle、Lars Eggert、Aaron Falk、Sam Hartman、John Klensin、Olaf Kolkman、Andy Malisに送られます。
[N1] Daigle, L., Ed., and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007.
[N1] Daigle、L.、ed。、およびInternet Architecture Board、「The RFC Series and RFC Editor」、RFC 4844、2007年7月。
[N2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[N2] Bradner、S。、「インターネット標準プロセス - 改訂3」、BCP 9、RFC 2026、1996年10月。
[N3] Daigle, L., Ed., and O. Kolkman, Ed., "RFC Streams, Headers, and Boilerplates", RFC 5741, December 2009.
[N3] Daigle、L.、ed。、およびO. Kolkman、ed。、「RFCストリーム、ヘッダー、およびボイラープレート」、RFC 5741、2009年12月。
[I1] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004.
[i1] Alvestrand、H。、「IESGおよびRFCエディタードキュメント：手順」、BCP 92、RFC 3932、2004年10月。
[I2] Falk, A., "Definition of an Internet Research Task Force (IRTF) Document Stream", RFC 5743, December 2009.
[i2] Falk、A。、「インターネット研究タスクフォース（IRTF）ドキュメントストリームの定義」、RFC 5743、2009年12月。
[I3] Klensin, J., Ed., and D. Thaler, Ed., "Independent Submissions to the RFC Editor", RFC 4846, July 2007.
[i3] Klensin、J.、ed。、およびD. Thaler、ed。、「RFCエディターへの独立した提出」、RFC 4846、2007年7月。
[I4] Internet Architecture Board and B. Carpenter, Ed., "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000.
[i4] Internet Architecture Board and B. Carpenter、ed。、「Internet Architecture Board（IAB）のチャーター」、BCP 39、RFC 2850、2000年5月。
[I5] Alvestrand, H., "An IESG charter", RFC 3710, February 2004.
[i5] Alvestrand、H。、「IESGチャーター」、RFC 3710、2004年2月。
[I6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[i6] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
Authors' Address
著者の住所
Harald Alvestrand EMail: harald@alvestrand.no
Harald Alvestrandメール：harald@alvestrand.no
Russell Housley EMail: housley@vigilsec.com
Russell Housleyメール：housley@vigilsec.com