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
Abstract
抽象
This document describes the procedures used by the IESG for handling documents submitted for RFC publication from the Independent Submission and IRTF streams.
この文書では、独立した提出とIRTFストリームからRFCの出版のために提出された書類を処理するためにIESGが使用する手順を説明します。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション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は、非IETFストリーム文書のいずれかのために、任意の目的のために、これらの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処理は、[N1]は、それぞれ、独立提出ストリームとIRTFストリームを含む最後の2つのカテゴリにも関します。
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.
[N2]と前RFC 3932 [I1]の出版物へのRFC 2026の承認に続いて、IESGは、出版前に、すべての独立提出ストリーム文書をレビューしました。このレビューはように、著者でポイントをクリアした文書の改訂を刺激し、適切なワーキンググループ（作業部会）に連絡する作家を奨励し、しようとするエリアディレクター（ADS）と、多くの場合、技術的な内容の本格的な見直しました。これは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エディタの責任であると思われます。個々のADは、文書の技術的内容を検討することを選択したとの問題を見つけた場合、その広告は、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]からRFCの出版のための検討プロセスを確立しました。これらの手順が完全に採用されると、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 EditorやIRTFが、その見直しを要求したときIESGによって行わのみレビュープロセスを説明します。 RFC Editorは独立提出ストリーム文書の見直しを要求します、とIRTFはIRTFストリーム文書の見直しを要求します。文書の編集者とIESGの間に、他の多くの相互作用があり、例えば、ADは、著者が可能独立提出ストリームの一部としてIETF内ではなく、RFC編集者への仕事のための入力として文書を提出、またはIESGことを示唆していることがあり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によって手順の定義と、それは同様の手順は、IRTFストリームドキュメントのIESGによって審査に適用されることが明らかになりました。
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 Editorは、すべてのRFC [N3]のタイトルページのフォーマットへの更新を行っています。これらの変更により、タイトルページの左上隅には、RFCを生産したストリームを示します。このラベルは、以前に非IETFストリーム文書に必須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エディタを介して提出された書類に関連しませんでした。今IRTFと独立提出ストリームの両方をカバーするRFC 3710のこの文書はさらに更新5.2.2の出版、。
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 EditorはRFCとして公表のための適性のための独立した提出ストリームの提出を検討します。 RFC 4846 [I3]で説明したように、RFC EditorはIETFコミュニティで行わIETF標準化プロセスや仕事との競合のためのドキュメントを確認するためにIESGを要求します。
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コミュニティ[I2]で行わIETF標準化プロセスや仕事との競合のためのレビューのためにIESGに送信されます。
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.
ドキュメントが公開されている場合IESGノートを含むように要求を添付することができるそれらのいずれかの結論を以下の5種類、のいずれかで、これらの独立した提出とIRTFストリーム文書の結果の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は、出版物が潜在的に<X> WGで行わ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レビューとIESGの承認を得ずに公表すべきではない方法で、IETFプロトコルを拡張することを締結しています。
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は、IETF標準化プロセスへの文書との関係を明確にするためにIESGノートを含めることを要求することができます。このようなノートでは、関連する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.
最後の2つの応答は、それぞれ含まれている文書は、これらの用語は、RFC 5226 [I6]で定義されているようIETFレビュー、標準アクション、またはIESGの承認を（必要（新しいURIスキームを登録するなど）行動を取るしようとした場合のために）、およびそこに原作者が予想していなかった、それはプロトコルの通常の使用に有害であり得る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見直し、対象となるAD主催の個々の文書として公表を求めるための機会を提供します。フル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は、IANA登録手順で可能な衝突の場合には、文書を公開すると、そのWGの作業に有害であるかどうかの外部意見を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 Editorは、インターネットに害を及ぼす可能性の配慮を含め、その提出のための技術的なメリットを判断する責任があります。 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 Editorは、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 Editorは出版お薦めや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から代替IESGノートテキストまたはRFCエディターのための提案は非常に奨励されています。
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 Editorは、彼らはそれを含めるつもりかどうかを述べなければなりません。
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
対話が要求されたIESGノートの内容にIRSGまたはRFCエディタの問題を解決するために失敗し、彼らが要求されたIESGノートなしRFCとして文書を公開する場合は、その後、IESGは正式に仲裁を提供するために、IABを求めることができます。 IABは、調停を実行する義務を負いませんし、要求を断ることがあります。 IABが拒否した場合、RFC EditorはIESGノートが含まれているかどうかを決定します。 IABが受け入れる場合は、IABのレビューは、IABの自身の選択の手順に従って行われます。 IABは、IESGノートを含めることを指示IESGノートの撤退を指示、またはRFCエディタに最終決定を残すことができます。 RFC 4846 [I3]で指定されたIABレビューとは異なり、IABの包含を指示する場合
or withdrawal the IESG note, the IAB decision is binding, not advisory.
または撤回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番号を与えます。明確な免責事項ノート「は、この機能のためのIETF技術がXである」と言って後に出版された文書最初に公開WGの製品を持っている方が良いようだ、と非採用しています。
Example: Photuris (RFC 2522), which was published after IKE (RFC 2409).
例：IKE（RFC 2409）の後に発表されたPhoturis（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年に、実験的RFCの提案は、他の目的のためにIPヘッダの「フラグメントオフセット」部分の上位ビットを再利用したいと発表されました。いいえIANAの考慮事項は、これらのビットは再利用することができますどのように述べていないが、標準的には、彼らのために特定の意味を定義します。 IESGは、この実験の実装が困難なデバッグ相互運用性の問題を引き起こし危険にさらしたとRFCシリーズの文書を公開しませ推奨と結論付けました。 RFC Editorは勧告を受け入れました。
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シリーズは、多くの利用可能な出版チャネルの一つです。この文書では、文書が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内の議論を監視し続けるから生じるすべての変更に合わせて調整する必要があるかもしれませんそのような議論。
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の産物であり、それはRFCエディタによって、およびIABによって、IETFで検討しました。 RFC 3932の開発のための特別な感謝はスコット・ブラッドナー、ブライアン・カーペンター、ポール・ホフマン、ジョン・クレンシン、エリオット・リア、キースムーア、ピート・レズニック、クルトZeilenga、そして貴重なフィードバックを提供する他のすべての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により検討しました。このアップデートの開発のための特別な感謝はヤリArkko（アルファベット順）に行き、アトキンソン、レスリーDaigle氏、ラースEggertの、アーロンフォーク、サム・ハートマン、ジョン・クレンシン、オラフKolkman、そしてアンディMalisを実行しました。
[N1] Daigle, L., Ed., and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007.
[N1] Daigle氏、L.、エド。、およびインターネットアーキテクチャ委員会、 "RFCシリーズとRFCエディタ"、RFC 4844、2007年7月。
[N2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[N2]ブラドナーの、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.、エド。、およびO. Kolkman、エド。、 "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 Editorのドキュメント：プロシージャ"、BCP 92、RFC 3932、2004年10月。
[I2] Falk, A., "Definition of an Internet Research Task Force (IRTF) Document Stream", RFC 5743, December 2009.
[I2]、RFC 5743、2009年12月フォーク、A.、 "インターネットResearch Task Force（IRTF）文書ストリームの定義"。
[I3] Klensin, J., Ed., and D. Thaler, Ed., "Independent Submissions to the RFC Editor", RFC 4846, July 2007.
[I3] Klensin、J.、エド。、およびD.ターラー、エド。、 "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]インターネットアーキテクチャ委員会とB.カーペンター、エド。、 "インターネットアーキテクチャ委員会（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
ハラルドAlvestrandメール：harald@alvestrand.no
Russell Housley EMail: housley@vigilsec.com
ラッセルHousleyのEメール：housley@vigilsec.com