Network Working Group J. Klensin, Ed.
Request for Comments: 4846 D. Thaler, Ed.
Category: Informational July 2007
Independent Submissions to the RFC Editor
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
There is a long-standing tradition in the Internet community, predating the Internet Engineering Task Force (IETF) by many years, of use of the RFC Series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms. These documents, known as "Independent Submissions", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants. This document discusses the Independent Submission model and some reasons why it is important. It then describes editorial and processing norms that can be used for Independent Submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher.
IETF標準化プロセスとそのレビューと承認のメカニズムに根ざしていない資料を公開するRFCシリーズの使用の多くの年で、インターネット技術タスクフォース（IETF）をより以前のインターネットコミュニティでの長年の伝統が、あります。 「独立の提出」として知られているこれらのドキュメントは、両方の内側とアクティブIETF参加者のコミュニティの外に、インターネットコミュニティのための重要な機能の数を提供しています。この文書では、独立したサブミッションモデルと、それが重要ないくつかの理由を説明します。その後、コミュニティはIETFコミュニティとその主要な技術的な出版社との新しい関係に進むよう、独立の提出のために使用することができる編集と処理の規範を説明しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology Note . . . . . . . . . . . . . . . . . . . . . 3
1.2. Context and Philosophical Assumptions . . . . . . . . . . 4
2. The Role of Independent Submissions . . . . . . . . . . . . . 4
3. Document Submission . . . . . . . . . . . . . . . . . . . . . 5
4. The Review Process . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Posting of Draft . . . . . . . . . . . . . . . . . . . . . 6
4.2. Request for Publication . . . . . . . . . . . . . . . . . 6
4.3. Initial RFC Editor Review . . . . . . . . . . . . . . . . 6
4.4. Review and Evaluation . . . . . . . . . . . . . . . . . . 7
4.5. Additional Reviews . . . . . . . . . . . . . . . . . . . . 7
4.6. Document Rejection . . . . . . . . . . . . . . . . . . . . 7
4.7. Final Decision and Notification . . . . . . . . . . . . . 8
4.8. Final Editing and Publication . . . . . . . . . . . . . . 8
5. Formal IESG Review . . . . . . . . . . . . . . . . . . . . . . 8
6. The Editorial Review Board . . . . . . . . . . . . . . . . . . 9
7. Status and Availability of Reviews . . . . . . . . . . . . . . 10
7.1. Posted Reviews . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Rejected Documents . . . . . . . . . . . . . . . . . . . . 11
7.3. Documents Approved for Publication . . . . . . . . . . . . 11
8. Intellectual Property Rights . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. IAB Members at the Time of Approval . . . . . . . . . 15
There is a long-standing tradition in the Internet community, predating the IETF by many years, of use of the RFC Series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms. These documents, known as "Independent Submissions", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants. This document discusses the Independent Submission model and some reasons why it is important. It then describes editorial and processing norms that can be used for Independent Submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher.
IETF標準化プロセスとそのレビューと承認のメカニズムに根ざしていない資料を公開するRFCシリーズの使用の多くの年でIETFより以前のインターネットコミュニティでの長年の伝統が、あります。 「独立の提出」として知られているこれらのドキュメントは、両方の内側とアクティブIETF参加者のコミュニティの外に、インターネットコミュニティのための重要な機能の数を提供しています。この文書では、独立したサブミッションモデルと、それが重要ないくつかの理由を説明します。その後、コミュニティはIETFコミュニティとその主要な技術的な出版社との新しい関係に進むよう、独立の提出のために使用することができる編集と処理の規範を説明しています。
To understand the perspective of this document, it is important to remember that the RFC Editor function predates the creation of the IETF. As of the time of this writing, the RFC Series goes back 38 years [RFC2555], while the IETF is celebrating its 21st anniversary. All of the documents that were published before the IETF was created, and for some years thereafter, would be considered Independent Submissions today. As the IETF evolved, the Internet Architecture Board (IAB) and then the IETF itself chose to publish IETF documents as RFCs while fully understanding that the RFC Editor function was an independent publication mechanism. Other decisions were possible: e.g., the IETF could have decided to create its own publication series. It was felt that there was considerable value in continuing to publish the IETF work in the same series as the one used to publish the basic protocols for the Internet.
このドキュメントの視点を理解するには、RFC Editorの機能はIETFの作成に先行していることを覚えておくことが重要です。 IETFは、その21周年を祝っている間にこれを書いている時点では、RFCシリーズは、38年[RFC2555]は、戻ります。 IETFが作成される前に公開された文書のすべて、その後何年かのために、今日独立提出と考えられます。 IETFが進化するにつれて、インターネットアーキテクチャ委員会（IAB）、その後、IETF自身がRFCエディタの機能が独立した出版メカニズムであったことを完全に理解しながら、RFCとしてIETFの文書を公開することにしました。他の決定が可能であった：例えば、IETFは、独自の出版シリーズを作成することを決めた可能性があります。これは、1つは、インターネットのための基本的なプロトコルを公開するために使用したのと同じ直列にIETFの作業を公開し続けることにはかなりの価値があったことを感じました。
This document describes what have historically been referred to as "Independent Submissions". That term is distinguished from those IETF and IAB community documents that originate from formal groups -- the IAB, IRTF, and IETF Working Groups -- and from submissions submitted to the Internet Engineering Steering Group (IESG) for Standards-Track, Informational, or Experimental processing. Documents produced by individuals, rather than IETF WGs or others IETF-affiliated groups, but submitted for publication via the IESG under Area Director sponsorship, are known as "individual submissions".
この文書では、歴史的に「独立の提出」と呼ばれているものを説明します。 IAB、IRTF、およびIETFワーキンググループ - - と標準トラック、情報、またはのためのインターネットEngineering Steering Group（IESG）に提出された応募作品から、その用語は、正式なグループから発信それらのIETFとIABコミュニティの文書と区別され実験的処理。個人によって作成されたドキュメントではなく、IETFのWG等IETF-傘下のグループが、地域ディレクターの後援の下でIESGを通じて出版のために提出は、「個々の提出」として知られています。
For convenience and obvious historical reasons, the editor and publisher of documents that are not processed through the IETF is known below as the "RFC Editor". The RFC Editor will typically be an organization of one or more senior people and associated editorial staff, and the term is used collectively below. That term is not intended to predict the future, either in terms of who does the job or what they, or the document series, are called.
利便性と明白な歴史的な理由のために、IETFによって処理されていない文書の編集者や出版社は、「RFC編集者」として以下に知られています。 RFC Editorは通常、1つ以上の高齢者と関連する編集スタッフの組織となり、用語は以下にまとめて使用されています。その用語は、いずれかのジョブまたは何彼ら、またはドキュメントシリーズは、と呼ばれているがない方の面で、未来を予測するものではありません。
This document complements the discussion and guidelines in [RFC4714], which focuses on Standards-Track documents. It takes a somewhat stronger view than the discussions that led to that document, starting from the belief that Independent Submissions are most valuable if they are, in fact, independent of the IETF process. From the perspective of the IETF, Independent Submissions are especially important as checks on the IETF processes even though such checks are not the only, or even a common, reason for them. That role is compromised if IETF-related entities are able to block or deprecate such documents to a degree beyond that needed to avoid difficulties with the standards process.
この文書では、標準化過程文書に焦点を当てた、[RFC4714]で議論し、ガイドラインを補完します。それは彼らがしている場合は、独立の提出は、実際には、IETFプロセスの独立した最も価値があるという信念から始めて、その文書につながった議論よりもやや強い見解をとります。 IETFの観点から、独立の提出は、このようなチェックのみ、またはそれらのためにも共通する、理由はないにもかかわらず、IETFプロセス上のチェックなど、特に重要です。 IETF関連のエンティティは標準化プロセスの困難を避けるために必要とされる以上の程度まで、このような文書をブロックまたは廃止することができれば、その役割が損なわれています。
When the RFC Series was fairly new, RFCs were used to publish general papers on networking as well as the types of documents we would describe as standards today. Those roles also developed as part of the early design and development of the ARPANET, long before anyone dreamt of the IETF and when the distinction between, e.g., Standards and Informational documents was less precisely drawn. In more recent years, Independent Submissions have become important for multiple reasons, some of them relatively new. They include:
RFCシリーズはかなり新しいだったときに、RFCは、ネットワーキング全般に関する論文だけでなく、我々が今日の標準として記述します文書の種類を公開するために使用されました。これらの役割はまた、誰もがIETFを夢見て、長い前に、ARPANETの初期の設計と開発の一環として開発され、例えば、標準化と情報の文書間の区別はあまり正確に描かれたとき。より最近では、独立の提出は、そのうちのいくつかの比較的新しい、複数の理由のために重要になってきました。彼らは、次のとおりです。
o Discussion of Internet-related technologies that are not part of the IETF agenda.
O IETF議題の一部ではない、インターネット関連技術の議論。
o Introduction of important new ideas as a bridge publication venue between academia and IETF engineering.
O学界とIETFエンジニアリングの間のブリッジ公開会場などの重要な新しいアイデアのご紹介。
o Informational discussions of technologies, options, or experience with protocols.
O情報技術の議論、オプション、またはプロトコルの経験。
o Informational publication of vendor-specific protocols.
ベンダー固有のプロトコルのO情報出版。
o Critiques and discussions of alternatives to IETF Standards-Track protocols. The potential for such critiques provides an important check on the IETF's standards processes and should be seen in that light.
O批評とIETF標準トラックプロトコルの選択肢の議論。そのような批判の可能性はIETFの標準化プロセスに重要なチェックを提供し、その光の中で理解すべきです。
o Documents considered by IETF Working Groups but not standardized. While many documents of this type are still published in the IETF document stream (see [RFC4844], Section 5.1.1) as Informational or
OドキュメントはIETFのワーキンググループで検討が、標準化されていません。このタイプの多くの文書はまだIETFドキュメントストリームで公開されていますが（[RFC4844]、セクション5.1.1を参照）の情報として、あるいは
Experimental RFCs, the Independent Submission path has traditionally been open to them as well. However, because of their intimate connection to the IETF Standards Process and WG activities and the consequent sensitivity to exact statements of relationships and to timing, there is reason to believe that such documents should normally be published via the IETF document stream. In any event, these documents are published for the historical record.
実験的RFCは、独立提出パスは、伝統的にだけでなく、それらに開放されています。しかし、彼らの親密なIETF標準化プロセスへの接続およびWGの活動と関係の正確な文にし、タイミングの結果として起こる感度の、そのような文書は、通常、IETFドキュメントストリームを経由して公表すべきであると信じる理由があります。いずれにせよ、これらの文書は歴史的な記録のために公開されています。
o Satirical materials.
O風刺材料。
o Meeting notes and reports (RFC 21 [RFC0021] is the earliest; RFC 1109 [RFC1109] is probably the most important).
O会議のメモやレポート（RFC 21 [RFC0021]は早いです。RFC 1109 [RFC1109]は、おそらく最も重要です）。
o Editorials (the best example is IEN 137 [IEN137], not an RFC).
社説O（最良の例では、IEN 137 [IEN137]ないRFCです）。
o Eulogies (RFC 2441 [RFC2441]).
O Eulogies（RFC 2441 [RFC2441]）。
o Technical contributions (e.g., RFC 1810 [RFC1810]).
O技術の貢献（例えば、RFC 1810 [RFC1810]）。
o Historically, RFC Editor and, at least prior to the handoff between the Informational Sciences Institute (ISI) and the Internet Corporation for Assigned Names and Numbers (ICANN) and the June 2000 MOU [RFC2860], Internet Assigned Numbers Authority (IANA) Policy Statements (e.g., RFC 2223 [RFC2223] and RFC 1591 [RFC1591]).
O歴史的に、RFCエディタと、少なくとも前の情報科学研究所（ISI）と割り当てられた名前と番号のためのインターネットコーポレーション（ICANN）と2000年6月MOU [RFC2860]の間のハンドオフに、IANA（Internet Assigned Numbers Authority）の方針文（例えば、RFC 2223 [RFC2223]及びRFC 1591 [RFC1591]）。
It should be clear from the list above that, to be effective, the review and approval process for Independent Submissions should be largely independent of the IETF. As an important principle that has been applied historically, the RFC Editor seeks advice from the IESG about possible relationships and conflicts with IETF work. Any submission that constitutes an alternative to, or is in conflict with, an IETF Standard or proposal for Standards-Track adoption must clearly indicate that relationship. The IESG may identify such conflicts as part of its review.
それは有効であるために、独立した提出物のレビューおよび承認プロセスがIETFの大部分が独立していなければならない、その上記のリストから明らかです。歴史的に適用されている重要な原則として、RFC EditorはIETFの仕事と考えられる関係や紛争についてIESGからのアドバイスを求めています。代替を構成する、またはと競合している任意の提出、IETF標準または標準化過程の採用のための提案は明らかにその関係を示す必要があります。 IESGは、その見直しの一環として、このような競合を識別することができます。
The specific procedures to be followed in review are described in Section 4 and Section 5.
レビューに従うべき特定の手順は、第4及び第5節に記載されています。
Independent Submissions are submitted directly to the RFC Editor. They must first be posted as Internet-Drafts (I-Ds), so the submission is typically simply a note requesting that the RFC Editor consider a particular Internet-Draft for publication. The process is described in [RFC2223]. Further information can be found in the working draft of an update of that document [RFC2223BIS].
独立提出はRFCエディタに直接提出されます。提出は、単に一般的にRFC Editorは出版のための特定のインターネットドラフトを検討することを要求するノートですので、彼らはまず、インターネットドラフト（I-DS）として計上しなければなりません。プロセスは、[RFC2223]に記載されています。さらなる情報は、[RFC2223BIS】その文書の更新の作業草案に見出すことができます。
Any document that meets the requirements of this specification, of [RFC2223] and its successors, and of any intellectual property or other conditions that may be established from time to time, may be submitted to the RFC Editor for consideration as an Independent Submission. However, the RFC Editor prefers that documents created through IETF processes (e.g., working group output) be considered by the IESG and submitted using this path only if a working group or the IESG declines to publish it. In the latter cases, the review process will be more efficient if the authors provide a history of consideration and reviews of the document at the time of submission.
[RFC2223]及びその後継の、任意の知的財産又は随時確立することができる他の状態のこの仕様の要件を満たす任意の文書は、独立服従として検討のためRFCエディタに提出することができます。しかし、RFC EditorはIETFのプロセス（例えば、ワーキンググループ出力）を介して作成された文書は、IESGによって考慮し、ワーキンググループまたはIESGはそれを公開するために拒否した場合にのみ、このパスを使用して提出することを好みます。著者は、提出の際に考慮し、文書のレビューの歴史を提供する場合、後者のケースでは、レビュープロセスをより効率的になります。
In general, the steps in the review process are identified in the subsections below. Any of them may be iterated and, at the discretion of the RFC Editor, steps after the first may be taken out of order. In addition, the IESG review, as discussed in Section 5, must take place before a final decision is made on whether to publish the document.
一般的には、レビュープロセスのステップは以下のサブセクションで識別されています。それらのいずれかが最初は順不同で行うことができるステップの後に、RFC編集者の裁量で、繰り返してもよいです。最終的な決定は、文書を公開するかどうかについて説明する前に、また、IESGレビューでは、第5章で説明したように、場所を取る必要があります。
The author(s) or editor(s) of a document post it as an Internet-Draft.
文書の作成者（複数可）またはエディタ（複数可）インターネットドラフトとしてそれを投稿してください。
After the normal opportunity for community review and feedback provided by the submission of the I-D and the I-D repository announcement thereof, the author or editor sends a request for consideration for publication to the RFC Editor at rfc-editor@rfc-editor.org. That request should note any community discussion or reviews of the document that have occurred before submission, as well as the desired document category (Informational or Experimental, as discussed in RFC 2026 [RFC2026], Section 4.2).
I-DおよびI-Dリポジトリ発表その、著者や編集者の提出が提供するコミュニティのレビューとフィードバックのための通常の機会の後rfc-editor@rfc-editor.orgでRFC編集者への公開のための検討を要請します。その要求は、提出前に発生した文書だけでなく、所望の文書カテゴリ（RFC 2026で説明したように情報や実験、[RFC2026]、セクション4.2）のいずれかのコミュニティの議論やレビューを注意してください。
If the document requires any IANA allocations, authors should take care to check the assignment policy for the relevant namespace, since some assignment policies (e.g., "IETF Consensus") cannot be used by Independent Submissions. See RFC 2434 [RFC2434] for more information.
文書は、どんなIANAの割り当てを必要とする場合、著者は、関連する名前空間の割り当てポリシーを確認するために注意する必要があり、いくつかの割り当てポリシーいるので（例えば、「IETFコンセンサス」）は、独立の提出で使用することはできません。詳細については、RFC 2434 [RFC2434]を参照してください。
RFC Editor staff performs an initial check on the document to determine whether there are obvious issues or problems and to decide on the sequencing of other steps.
RFC Editorのスタッフは明らかな問題や問題があるかどうかを判断するために他のステップの順序を決定するために、文書の初期チェックを実行します。
At any time during the process, the RFC Editor may make general and/or specific suggestions to the author on how to improve the editorial quality of the document and note any specific violations of the rules. The author will be expected to make the suggested updates, submit a new version, and inform the RFC Editor. This may be repeated as often as necessary to obtain an acceptable editorial quality.
プロセス中はいつでも、RFC Editorは、文書の編集の質を改善する方法について著者に一般的および/または特定の提案を行い、ルールのいずれかの特定の違反を注意することがあります。著者は、提案の更新を行い、新しいバージョンを提出し、RFCエディタに通知することが期待されます。これは許容社説品質を得るために必要な頻度で繰り返されてもよいです。
The RFC Editor arranges for one or more reviews of the document. This may include Editorial Board (see Section 6) reviews or reviews by others. Unsolicited reviews from parties independent of the author are welcome at any time.
RFC Editorは、文書の一つ以上のレビューのためにアレンジ。これは、他の人が編集委員会（第6節参照）レビューやレビューを含むことができます。著者の独立した関係者からの迷惑レビューはいつでも歓迎します。
At minimum, the author of every document shall receive a written summary of the review(s). Reviewer anonymity is discussed in Section 7. The RFC Editor may also share reviews with the Editorial Board.
最低でも、すべての文書の作成者は、レビュー（複数可）の書かれた概要を受けなければなりません。レビュアー匿名性はまた、編集委員会でレビューを共有することができ、セクション7 RFCエディタで議論されています。
An author rebuttal to some aspect of a review, followed by a healthy technical dialog among the author and the reviewer(s), is fully appropriate. Consensus followed by document revision is the desired outcome.
著者と校閲（複数可）の間で健康的な技術的なダイアログが続いレビューのいくつかの側面に、著者の反論は、完全に適切です。文書の改訂が続くコンセンサスが所望の結果です。
The RFC Editor is expected to consider all competent reviews carefully, and in the absence of some unusual circumstance, a preponderance of favorable reviews should lead to publication.
RFC Editorは慎重にすべての有能なレビューを考慮することが期待されている、といくつかの異常な状況が存在しない場合には、好評の優位は、出版につながるはず。
If the author is dissatisfied with one or more review(s), the author may request that the RFC Editor solicit additional reviews. In exceptional circumstances, the author may request that the IAB review the document. Such requests to the IAB, and any reviews the IAB chooses to perform, will occur according to procedures of the IAB's choosing. The IAB is not required to initiate a review or comply with a request for one: a request to the IAB for a review is not an appeal process.
著者は、1つまたは複数のレビュー（複数可）に不服がある場合、著者はRFC Editorは追加レビューを勧誘することを要求することができます。例外的な状況では、著者は、IABがドキュメントを確認することを要求することができます。このようなIABへの要求、およびIABは、実行するために選択した任意のレビューは、IABの選んだの手順に従って行われます。レビューのためのIABへのリクエストが控訴プロセスではありません：IABは、レビューを開始または1つの要求を遵守する必要はありません。
If any stage of the review process just described leads to the conclusion that the document is not publishable, the RFC Editor may reject the document. Such rejection would normally be based on the conclusion that the submission does not meet the technical or editorial standards of the RFC Series or is not relevant to the areas that the series covers.
レビュー・プロセスのどの段階だけで文書が公開可能ではないという結論にリードを説明した場合は、RFC Editorは、文書を拒否することができます。このような拒絶は、通常、提出がRFCシリーズの技術的または編集上の基準を満たしていないか、シリーズがカバーするエリアに関連しないん結論に基づいてされるだろう。
If a document is rejected by the RFC Editor, the author may request an additional review from the IAB, as described below, but the IAB is not obligated to perform that review, nor is the RFC Editor obligated to publish it, even with a favorable IAB review.
文書がRFCエディタによって拒否された場合は、以下に説明するように、著者は、IABから追加の見直しを要求することができるが、それでも有利で、IABはその見直しを行う義務はない、またRFC Editorは、それを公開する義務がありますIABレビュー。
In all cases, the ultimate decision to publish or not publish, and with what text, rests with the RFC Editor.
すべての場合において、最終的な決定は公開公開したりしないように、そしてどのようなテキストで、RFCエディタにかかっています。
The RFC Editor will communicate the final decision to the author and the Editorial Board. For a rejection, there will be a summary of the reason(s) for the action.
RFC Editorは、著者と編集委員会への最終的な決定を伝えます。拒否の場合は、アクションの理由（複数可）の概要があるでしょう。
Information about any IESG-requested publication delay or request to not publish a document will be posted to the RFC Editor Web site to supplement document status information.
どんなIESGが要求した出版物の遅延またはドキュメントを公開しないように要求に関する情報は、文書のステータス情報を補完するRFC EditorのWebサイトに掲載されます。
Once a document is approved for publication, it is handled in a fashion similar to other RFCs, with principles about priorities worked out with the IAB as appropriate.
文書が公表のために承認されると優先順位についての原則を適宜IABで働いて、それは、他のRFCと同様の方法で処理されます。
At an appropriate time in the review process, normally after the RFC Editor has made a tentative decision to publish, the document is forwarded to the IESG for evaluation with a relatively short timeout. If the nature of the document persuades the RFC Editor or the IESG that the interests of the community or efficiency in the publication process would be better served by a different schedule, then that schedule should be followed. For example, if it appears to the RFC Editor that it is likely that the IESG will wish to take the document over and assign it to a working group, it may be better to ask for the IESG review prior to incurring the delays associated with other reviews or significant editorial work.
レビュー・プロセスの適切な時点で、通常はRFC Editorが発行する仮決定を行った後、文書は比較的短いタイムアウトと評価のためにIESGに転送されます。文書の性質がRFCエディタまたは公開プロセスにおけるコミュニティや効率の利益が良く異なるスケジュールによって提供されることをIESG説得した場合、そのスケジュールは従うべきです。 IESGが終わった文書を取りたいとワーキンググループに割り当てれる可能性があることをRFCエディタに表示された場合、前に他に関連した遅延を発生するIESGのレビューを依頼する方が良いかもしれレビューまたは重大な編集作業。
The IESG evaluation is not a technical one. Instead, it covers the issues listed in RFC 3932 [RFC3932] or its successors, presumably from the perspective outlined above in Section 1.2. That is, the evaluation should focus exclusively on conflicts or confusion with IETF process and attempts to subvert ("end run") working group activities.
IESG評価は、技術的なものではありません。その代わりに、それは、おそらく1.2節において上記に概説観点から、[RFC3932]、またはその後継RFC 3932に記載されている問題を覆います。つまり、評価はグループ活動を取り組んで紛争や混乱IETFプロセスとし、（「エンド・ラン」）を覆すための試みだけに焦点を当てるべきです。
At the time the document is forwarded to the IESG, the RFC Editor posts an indication on its Web site that the document is under IESG review and that comments on conflicts can be sent to the IESG with copies to the RFC Editor. Additional mechanisms may be developed from time to time to inform a community that a document is entering formal prepublication review. Comments not directly related to IETF procedures or conflicts may be sent directly to the author(s) and RFC Editor.
当時ドキュメントがIESGに転送され、RFC EditorのポストドキュメントはIESGの検討および競合上のコメントはRFCエディタにコピーしてIESGに送信することができるということである同社のウェブサイト上で表示。追加のメカニズムは、文書が正式な出版前の見直しに入っているコミュニティを知らせるために随時開発することができます。 IETFプロシージャまたは競合に直接関係しないコメントは、著者（S）とRFCエディタに直接送信してもよいです。
In addition to the IESG review for conflict with IETF work, individuals in the IESG or in the broader IETF community are free to review a draft and, if they have comments of any kind --including the extreme case of believing that the proposal is damaging to the Internet as a whole-- these comments should be directed to the author(s) and the RFC Editor.
彼らは提案が損傷していることを信じるの極端なケースを--includingあらゆる種類のコメントがあればIETF仕事との競合のためにIESGのレビューに加えて、IESGや広いIETFコミュニティの人々は、草案を検討して自由であり、 whole--としてインターネットにこれらのコメントは、著者（複数可）およびRFCエディタに向けられるべきです。
If the IESG, after completing its review, identifies issues, it may recommend explanatory or qualifying text for the RFC Editor to include in the document if it is published.
IESGは、その審査を完了した後、問題を識別した場合、それが公開されている場合、文書に含めるRFC Editorの説明や予選テキストを勧告することができます。
If the IESG concludes that publication of the document should be delayed for a reasonable period of time because its untimely publication could cause confusion or other harm with proposals under consideration for standardization, the RFC Editor will grant that request. The current agreement between the RFC Editor and the IESG on requested delays is expected to continue. That agreement permits the IESG to ask for a delay of up to six months and, if necessary, to renew that request twice, for a total possible delay of 18 months.
IESGは、その早すぎる出版物は、混乱や標準化のための検討中の提案と他の害を引き起こす可能性があるため、文書の公開は、合理的な期間のために延期されるべきであると判断した場合、RFC Editorはその要求を許可します。要求された遅延のRFC編集者とIESGの間の電流の契約は継続すると予想されます。その契約が必要な場合は18ヶ月の合計の可能な遅延のために、その倍の要求を更新するために、最大6ヶ月の遅延を求めるとするIESGが可能になります。
If the IESG concludes that the document should not be published as an RFC, it will request that the RFC Editor not publish and provide appropriate justification for that request. The RFC Editor will consider the request to not publish the document.
IESGは、文書がRFCとして公開されるべきではないと判断した場合、それはRFC Editorはその要求に対して適切な正当性を公開し、提供しないことを要求します。 RFC Editorはドキュメントを公開しないように要請を検討します。
The RFC Editor or the author may request that the IAB review the IESG's request to delay or not publish the document and request that the IAB provide an additional opinion. Such a request will be made public via the RFC Editor Web site. As with the IESG review itself, the IAB's opinion, if any, will be advisory. And, as with author requests for an IAB technical review (see Section 4.5), the IAB is not obligated to perform this type of review and may decline the request.
RFC編集者や著者は、IABが遅延したり、文書を公開し、IABは、追加の意見を提供することを要求しないためにIESGの要求を確認することを要求することができます。このような要求は、RFC EditorのWebサイトで公開されます。 IESGレビュー自体と同じように、IABの意見があれば、顧問となります。そして、IABの技術的な見直し（4.5節を参照）のための著者の要求と同様に、IABは、レビューのこのタイプを実行する義務を負いませんし、要求を断ることがあります。
The RFC Editor appoints and maintains the Editorial Review Board, which, much like the editorial boards of professional journals and publishers, provides the RFC Editor with both advice and reviews of particular proposed publications and general and strategic policy advice. The membership list of the Editorial Review Board is public and can be found at http://www.rfc-editor.org/edboard.html.
RFC Editorは任命と、多くの専門誌や出版社の編集委員と同様に、アドバイスや特定の提案の出版物及び一般戦略的な政策助言のレビューの両方でRFCエディタを提供して編集委員会を、維持します。編集委員会のメンバーシップ・リストが公開されているとhttp://www.rfc-editor.org/edboard.htmlで見つけることができます。
Editorial Board members serve at the pleasure of the RFC Editor. From time to time, the RFC Editor will solicit suggestions for new appointees from the IAB and other sources and will seek IAB comments on those to be appointed. The RFC Editor will also solicit IAB comments on the effectiveness of the review process and the quality of documents being published and criteria applied. However, to ensure the independence of the Independent Submission process, the final decision to appoint (or not appoint) Editorial Board members rests with the RFC Editor.
編集委員会のメンバーは、RFCエディタの喜びに役立ちます。随時、RFC EditorはIABおよび他のソースからの新しい任命者のための提案を募集し、任命されるために、それらのIABのコメントを図ってまいります。 RFC Editorはまた、レビュープロセスの有効性と適用され、公開された文書や基準の品質にIABのコメントを募集します。しかし、独立した提出プロセスの独立性を確保するために、編集委員会のメンバーを任命（または任命せず）に最終決定は、RFCエディタにかかっています。
The RFC Editor will conduct the reviews discussed above with the intent of balancing fairness to authors, transparency of the review process to the general community, protection of reviewers from possible retaliation or undue pressure, and the interest of the community in having any significant dissents from published documents available to the community with the same degree of scrutiny that the original documents received. To this end, reviews and information about reviewers will be made public under the following circumstances. In special cases in which other considerations apply, the RFC Editor may adopt special provisions after reviewing the circumstances and proposed action with the IAB.
RFC Editorは、一般的なコミュニティ、可能な報復や不当な圧力のレビュアーからの保護、およびからの重大なdissentsを持つコミュニティの関心にレビュープロセスの透明性を作者に公平性をバランスさを意図して、上述のレビューを行います原稿は受信精査の同程度とコミュニティに利用できる出版された文書。このため、査読についての口コミ情報は以下の状況で公表されます。他の考慮事項が適用される特別なケースでは、RFC EditorはIABと状況および提案されたアクションを確認した後、特別な規定を採用することができます。
Any reviewer participating in the process outlined in this document does so on the condition of giving consent to handling of the reviews as outlined in this section. In special cases, individual arrangements may be worked out in advance with the RFC Editor.
このドキュメントで概説プロセスに参加する任意のレビュアーは、このセクションで概説されているようレビューの取り扱いに同意を与えることを条件にそのようにします。特殊なケースでは、個々の構成は、RFCエディタで事前に働いていてもよいです。
As described in Section 4.4, all reviews will be shared with the document authors (with possible editing to remove any extreme language). The names of the reviewers will normally accompany these reviews, but reviewers will be granted anonymity upon request to the RFC Editor. The RFC Editor will in any case forward any author rebuttal messages to the reviewer.
4.4節で述べたように、全てのレビューは、（極端な言語を削除することが可能に編集して）文書の作成者と共有されます。査読の名前は、通常、これらのレビューを同行しますが、レビューアがRFCエディタへの要求に応じて匿名性を付与されます。 RFC Editorはどのような場合には審査にどの著者の反論メッセージを転送します。
Nothing in this section or the subsections below precludes private communications between reviewers, the Editorial Board, and the RFC Editor; such communications will remain confidential.
このセクションの以下のサブセクションでは何も査読、編集委員会、およびRFC編集者間のプライベートな通信を排除しません。このような通信は、機密ままになります。
Once a final accept or reject decision has been made on a document, the RFC Editor may choose to post the full set of reviews (and author rebuttals, if any) associated with a document, if doing so would be in the best interest of the community. The author may request earlier posting of reviews and rebuttals, to inspire additional unsolicited reviews, for example. The names of the reviewers will accompany their reviews, except for a reviewer who requested anonymity.
最終受け入れるか拒否決定が文書上で行われていたら、そうすることの最善の利益になる場合は、文書に関連付けられた、RFC Editorは（もしあれば、著者の反論）レビューのフルセットを投稿することもできますコミュニティ。著者は、たとえば、追加の迷惑レビューを鼓舞するために、レビューや反論の以前の投稿を要求することができます。査読の名前が匿名を要求したレビューアを除き、そのレビューを同行します。
The author will be notified in advance of the intent to post the final reviews. The author may then request that the document be withdrawn and the reviews kept private. However, such an author request must be timely, generally within 14 days of the notification of intent to post.
著者は、最終的なレビューを投稿する意図を事前に通知されます。著者は、その文書が取り下げとレビューは非公開にすることを要求することができます。しかし、そのような著者の要求は、一般的にポストする意図の通知から14日以内に、タイムリーでなければなりません。
If the RFC Editor rejects a document, the author has the following options for recourse.
RFC Editorは、文書を拒否した場合、著者は償還請求するために、次のオプションがあります。
o Request one or more additional reviews (Section 4.5) followed by a reconsideration.
Oリクエスト1つ以上の追加のレビュー（4.5節）は再考が続きます。
o Request an IAB review (Section 4.5, Section 4.6) followed by a reconsideration.
O再考続いIABレビュー（4.5節、4.6節）を要求します。
o Request that the reviews be published on the RFC Editor Web site.
レビューは、RFC EditorのWebサイトで公開されていることO要求。
In considering whether to make review materials public for documents
accepted for publication, the RFC Editor is expected to note that the
best way to comment on or dissent from an RFC is generally another
RFC; that reviews critical of a document are not themselves reviewed;
that the review and refutation process is necessarily fragmentary;
and that a reviewer who feels strongly about a subject about which a
review has already been written often would not need to do
significant additional work to produce an RFC-format document from
that review.
The following material was extracted from the relevant sections of BCP 78 [RFC3978] [RFC4748] in order to get all Independent Submission information for technical publications produced under the auspices of the IETF, the IETF Administrative Support Activity (IASA) or the IETF Trust, or the Internet Society (ISOC) into a single place and to initialize the process of separating discussions of Independent Submissions from those about Standards-Track or other IETF documents. Note that the text that follows uses the term "RFC Editor Contribution" to describe the same type of document referred to as an "Independent Submission" elsewhere in this document. The RFC Editor may change these provisions from time to time after obtaining the advice and consent of the IETF Trust in the RFC Editor's capacity as the formal publisher of RFCs.
以下の材料はIETFの後援の下で生産技術の刊行物のためのすべての独立した申込情報を取得するために、BCP 78 [RFC3978]、[RFC4748]の関連セクションから抽出された、IETF管理サポート活動（IASA）またはIETFトラストまたはインターネット協会（ISOC）の単一の場所にし、標準化過程または他のIETF文書に関するものとは独立した提出の議論を分離するプロセスを初期化します。次のテキストは別の場所で、この文書の「独立提出」と呼ばれる文書の同じタイプを記述するために用語「RFCエディタの貢献」を使用することに注意してください。 RFC EditorはRFCの正式な出版社としてRFC編集者の能力にIETFトラストの助言と同意を得た後、随時これらの規定を変更することがあります。
By submission of an RFC Editor Contribution, each person actually submitting the RFC Editor Contribution, and each named co-Contributor, is deemed to agree to the following terms and conditions, and to grant the following rights, on his or her own behalf and on behalf of the organization the Contributor represents or is sponsored by (if any) when submitting the RFC Editor Contribution.
RFCエディタ貢献を提出することにより、それぞれの人は実際にはRFCエディタの貢献を提出し、共同寄稿命名それぞれが、自分に代わってと上、以下の条件に同意し、かつ、以下の権利を付与するものとみなされますコントリビュータが表すか、RFCエディタの貢献を提出する際に（もしあれば）が主催している組織を代表。
a. For Internet-Drafts that are expected to be submitted as RFC Editor Contributions: To the extent that an RFC Editor Contribution or any portion thereof is protected by copyright and other rights of authorship, the Contributor, and each named co-Contributor, and the organization he or she represents or is sponsored by (if any) grant an irrevocable, non-exclusive, royalty-free, world-wide right and license to the IETF Trust and the IETF under all intellectual property rights in the RFC Editor Contribution for at least the life of the Internet-Draft, to copy, publish, display, and distribute the RFC Editor Contribution as an Internet-Draft.
A。限りRFCエディタ貢献またはその任意の部分コントリビュータは、著作権および著作者その他の権利により保護されており、各共同寄稿命名されていること、および組織：RFCエディタ貢献として提出されることが期待されるインターネットドラフトのために彼または彼女を表すか、（もしあれば）が主催しているが、少なくともためにRFCエディタの貢献にすべての知的財産権の下にIETF信託とIETFに取消不能、非独占的、ロイヤリティフリー、世界的な権利およびライセンスを付与しますインターネットドラフトの人生は、コピーし、ディスプレイを公開し、インターネットドラフトとしてRFC Editorの貢献を配布します。
b. For an RFC Editor Contribution submitted for publication as an RFC, and to the extent described above, the Contributor, each named co-Contributor, and the organizations represented above grant the same license to those organizations and to the community as a whole to copy, publish, display, and distribute the RFC Editor Contribution irrevocably and in perpetuity and, also irrevocably and in perpetuity, grant the rights listed below to those organizations and entities and to the community:
B。 、および上記の範囲にRFCとして公表のために提出され、RFCエディタの貢献のために、貢献者、各名前の共同寄稿者、および上記の代表組織がコピーするために、全体として、これらの組織にし、コミュニティに同じライセンスを付与し、これらの組織や事業体にし、コミュニティに以下に挙げる権利を付与、取消不能かつ永久にも、ディスプレイを公開し、RFCエディタの貢献を配布する取消不能かつ永久にと：
A. to prepare or allow the preparation of translations of the
RFC into languages other than English,
B. unless explicitly disallowed in the notices contained in an RFC Editor Contribution, to prepare derivative works (other than translations) that are based on or incorporate all or part of the RFC Editor Contribution, or comment upon it. The license to such derivative works shall not grant the IETF Trust, the IETF, or other party preparing a derivative work any more rights than the license to the original RFC Editor Contribution, and
B.がない限り、明示的に基づいて、またはRFCエディタ貢献の全てまたは一部を組み込む、またはそれにコメントされている（翻訳以外の）派生物を調製するために、RFCエディタ貢献に含まれる通知に禁止します。そのような派生作品のライセンスは、IETFトラスト、IETF、または他の当事者が派生物を準備し、元のRFCエディタ貢献へのライセンスよりも、それ以上の権限を付与してはならない、と
C. to reproduce any trademarks, service marks, or trade names that are included in the RFC Editor Contribution solely in connection with the reproduction, distribution, or publication of the RFC Editor Contribution and derivative works thereof as permitted by this paragraph. Any entity reproducing RFC Editor Contributions will, as a condition of permission of such reproduction, preserve trademark and service mark identifiers used by the Contributor of the RFC Editor Contribution, including (TM) and (R) where appropriate.
C.は、もっぱらRFCエディタの貢献と、この段落で許可され、その派生物の複製、配布、またはパブリケーションに関連するRFCエディタ貢献に含まれているすべての商標、サービスマーク、または商号を再現します。 RFCエディタの寄与を再生する任意のエンティティは、そのような再生の許可の条件として、適切な場合を含むRFCエディタ貢献のコントリビュータ（TM）及び（R）で使用される商標、サービスマーク識別子を保存します。
D. The Contributor grants the IETF Trust and the IETF, permission to reference the name(s) and address(es) of the Contributor(s) and of the organization(s) s/he represents or is sponsored by (if any).
D.ザ・コントリビューターsが/彼が表すか（もしあれば）が主催している組織（複数可）のIETF信託とIETF、名前（複数可）および寄稿（S）のアドレスを参照する権限を付与し、 。
This document specifies an RFC Editor (and, indirectly, IETF) administrative and publication procedure. It has no specific security implications.
この文書は、RFCエディタ（と、間接的に、IETF）行政や出版の手順を指定します。それには、特定のセキュリティの意味を持っていません。
Special thanks are due to Bob Hinden and Craig Partridge, who made several suggestions for improved text in earlier versions of this document, and to Stewart Bryant, Scott Bradner, Brian Carpenter, Vint Cerf, Leslie Daigle, and Olaf Kolkman, who made a number of useful suggestions about the organization and content of subsequent versions. We also express our appreciation to the IETF and Scott Bradner, Editor, for the material extracted from BCP 78 [RFC3978] and used in Section 8.
特別な感謝はこのドキュメントの以前のバージョンで改善されたテキストのためのいくつかの提案をしたボブHindenとクレイグ・パートリッジ、によるものであり、その数を作ったスチュワートブライアント、スコット・ブラッドナー、ブライアン・カーペンター、ヴィントン・サーフ、レスリーDaigle氏、およびオラフKolkmanへ組織とそれ以降のバージョンの内容についての有益な示唆。我々はまた、BCP 78 [RFC3978]から抽出し、第8章で使用される材料のために、IETFおよびスコットブラドナー、エディタに感謝の意を表します。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC2223]ポステル、J.、およびJ.レイノルズ、RFC 2223、1997年10月 "RFC作者への指示"。
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004.
[RFC3932] Alvestrand、H.、 "IESGとRFC Editorのドキュメント：プロシージャ"、BCP 92、RFC 3932、2004年10月。
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
[RFC3978]ブラドナーの、S.、 "質問の投稿IETF権"、BCP 78、RFC 3978、2005年3月。
[RFC4748] Bradner, S., "RFC 3978 Update to Recognize the IETF Trust", BCP 78, RFC 4748, October 2006.
[RFC4748]ブラドナーの、S.、BCP 78、RFC 4748、2006年10月の "RFC 3978の更新は、IETFの信頼を認識するために"。
[IEN137] Cohen, D., "On Holy Wars and a Plea for Peace", IEN 137, April 1980, <ftp://ftp.rfc-editor.org/in-notes/ien/ien137.txt>.
、IEN 137、1980年4月、<ftp://ftp.rfc-editor.org/in-notes/ien/ien137.txt> "聖なる戦争と平和のための嘆願について" [IEN137]コーエン、D.、。
[RFC0021] Cerf, V., "Network meeting", RFC 21, October 1969.
[RFC0021]サーフ、V.、 "ネットワーク会議"、RFC 21、1969年10月。
[RFC1109] Cerf, V., "Report of the second Ad Hoc Network Management Review Group", RFC 1109, August 1989.
[RFC1109]サーフ、V.、「第2臨時のネットワークマネージメントレビューグループの報告書」、RFC 1109、1989年8月。
[RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.
[RFC1591]ポステル、J.、 "ドメインネームシステムの構造と委任"、RFC 1591、1994年3月。
[RFC1810] Touch, J., "Report on MD5 Performance", RFC 1810, June 1995.
[RFC1810]タッチ、J.、 "MD5のパフォーマンスに関する報告書"、RFC 1810、1995年6月。
[RFC2223BIS] Reynolds, J., Ed. and R. Braden, Ed., "Instructions to Request for Comments (RFC) Authors", Work in Progress, August 2004.
【RFC2223BIS]レイノルズ、J.、エド。そして、R.ブレーデン、エド。、「コメント（RFC）作者の要求への指示」、進歩、2004年8月での作業。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC2441] Cohen, D., "Working with Jon Tribute delivered at UCLA, October 30, 1998", RFC 2441, November 1998.
[RFC2441]コーエン、D.、RFC 2441、1998年11月 "ジョン・トリビュートでの作業は、UCLA、1998年10月30日に配信します"。
[RFC2555] Braden, R., Reynolds, J., Crocker, S., Cerf, V., Feinler, J., and C. Anderson, "30 Years of RFCs", RFC 2555, April 1999.
[RFC2555]ブレーデン、R.、レイノルズ、J.、クロッカー、S.、サーフ、V.、Feinler、J.、およびC.アンダーソン、 "RFCの30年"、RFC 2555、1999年4月。
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000.
[RFC2860]大工、B.、ベイカー、F.、およびM.ロバーツ、RFC 2860、2000年6月「インターネット割り当て番号機関の技術的な仕事に関する覚書」。
[RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF Technical Publication Service", RFC 4714, October 2006.
[RFC4714]マンキン、A.とS.ヘイズ、RFC 4714、2006年10月 "IETFの技術公開サービスの要件"。
[RFC4844] Daigle, L., Ed. and IAB, "The RFC Series and RFC Editor", RFC 4844, July 2007.
[RFC4844] Daigle氏、L.、エド。そして、IAB、 "RFCシリーズとRFCエディタ"、RFC 4844、2007年7月。
Appendix A. IAB Members at the Time of Approval
承認時の付録A. IABメンバー
Bernard Aboba Loa Andersson Brian Carpenter Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman Kurtis Lindqvist David Meyer David Oran Eric Rescorla Dave Thaler Lixia Zhang
バーナードAbobaロア・アンダーソン、ブライアン・カーペンターレスリーDaigle氏エルウィン・デイビスケビン秋オラフKolkmanカーティスLindqvistデビッド・マイヤーデヴィッドオランエリックレスコラデーブターラーLixiaチャン
Authors' Addresses
著者のアドレス
John C Klensin (editor) 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
ジョン・C Klensin（編集者）1770年マサチューセッツアベニュー、＃322ケンブリッジ、MA 02140 USA
Phone: +1 617 491 5735 EMail: john-ietf@jck.com
電話：+1 617 491 5735 Eメール：john-ietf@jck.com
Dave Thaler (editor) One Microsoft Way Redmond, WA 98052 USA
デーブターラー（エディタ）1マイクロソフト道、レッドモンド、ワシントン98052 USA
Phone: +1 425 703 8835 EMail: dthaler@microsoft.com
電話：+1 425 703 8835 Eメール：dthaler@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
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, THE IETF TRUST 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が表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、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機能のための基金は現在、インターネット協会によって提供されます。