[要約] RFC 4846は、独立した提出者がRFCエディターに対して行う提案を規定しています。このRFCの目的は、独立した提案者がRFCプロセスに参加し、技術的なアイデアや標準化の提案を共有することを促進することです。
Network Working Group J. Klensin, Ed.
Request for Comments: 4846 D. Thaler, Ed.
Category: Informational July 2007
Independent Submissions to the RFC Editor
RFCエディターへの独立した提出
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）The IETF Trust（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）が長年にわたって使用されており、IETF標準プロセスとそのレビューおよび承認メカニズムに根ざしていない資料を公開するために、RFCシリーズを使用して長年の伝統があります。「独立した提出」として知られるこれらのドキュメントは、アクティブな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エディターの機能がIETFの作成よりも前のものであることを覚えておくことが重要です。この執筆時点で、RFCシリーズは38年前に遡り[RFC2555]、IETFは21周年を迎えています。IETFが作成される前に公開されたすべてのドキュメントは、その後数年間、今日独立した提出と見なされます。IETFが進化するにつれて、インターネットアーキテクチャボード（IAB）が進化し、IETF自体がIETFドキュメントをRFCとして公開することを選択し、RFCエディター機能が独立した出版メカニズムであることを完全に理解しました。その他の決定は可能でした。たとえば、IETFは独自の出版シリーズを作成することを決定した可能性があります。インターネット用の基本プロトコルを公開するために使用されたシリーズと同じシリーズで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ワーキンググループなどの正式なグループから発生するIETFおよびIABコミュニティの文書と、および標準トラック、情報、または情報のためにインターネットエンジニアリングステアリンググループ（IESG）に提出された提出から区別されます。実験処理。IETF WGSまたは他の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エディターは通常、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 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.
o IETFワーキンググループによって考慮されたドキュメントですが、標準化されていません。このタイプの多くのドキュメントは、IETFドキュメントストリーム（[RFC4844]、セクション5.1.1を参照）でまだ情報または実験的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）のポリシー声明（例えば、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エディターは、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エディターに直接送信されます。最初にインターネットドラフト（I-DS）として投稿する必要があるため、通常、RFCエディターが公開のために特定のインターネットドラフトを検討することを要求するメモです。このプロセスは[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エディターは、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エディターの裁量により、最初のエディタの後の措置が整理されない場合があります。さらに、セクション5で説明したIESGレビューは、ドキュメントを公開するかどうかについて最終決定が下される前に行われなければなりません。
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エディタースタッフは、ドキュメントの最初のチェックを実行して、明らかな問題や問題があるかどうかを判断し、他の手順のシーケンスを決定します。
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エディターは、ドキュメントの編集品質を改善し、規則の特定の違反を注意する方法について、著者に一般的および/または具体的な提案を行うことができます。著者は、提案された更新を行い、新しいバージョンを送信し、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エディターは、ドキュメントの1つ以上のレビューを手配します。これには、編集委員会（セクション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エディターは、すべての有能なレビューを慎重に検討することが期待されており、いくつかの異常な状況がない場合、有利なレビューの優勢は出版につながるはずです。
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エディターが追加のレビューを求めるように要求する場合があります。例外的な状況では、著者はIABがドキュメントをレビューするように要求する場合があります。IABへのこのような要求、およびIABが実行することを選択したレビューは、IABの選択の手順に従って発生します。IABは、レビューを開始したり、1つのリクエストを遵守する必要はありません。レビューのためのIABへのリクエストは控訴プロセスではありません。
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エディターはドキュメントを拒否する可能性があります。このような拒否は通常、提出が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エディターは有利であっても公開する義務がありません。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エディターは、最終決定を著者と編集委員会に伝えます。拒否のために、アクションの理由の要約があります。
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エディター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.
ドキュメントが公開されていることが承認されると、他のRFCと同様の方法で処理され、優先順位に関する原則が必要に応じてIABで解決されます。
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エディターが公開するという暫定的な決定を下した後、ドキュメントは比較的短いタイムアウトで評価のために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で上記の観点から、RFC 3932 [RFC3932]またはその後継者にリストされている問題をカバーします。つまり、この評価は、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エディターはそのWebサイトに、ドキュメントがIESGレビュー中であり、競合に関するコメントをRFCエディターにコピーでIESGに送信できることを示しています。追加のメカニズムは、文書が正式な前公開レビューを入力していることをコミュニティに通知するために、随時開発される場合があります。IETFの手順や競合に直接関係していないコメントは、著者および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.
IETF作業との競合に関するIESGレビューに加えて、IESGまたはより広いIETFコミュニティの個人は、ドラフトを自由にレビューできます。インターネット全体に - これらのコメントは、著者と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エディターが公開されている場合はドキュメントに含めるように説明または適格なテキストを推奨する場合があります。
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エディターはその要求を認めます。RFCエディターと要求された遅延に応じてIESGの間の現在の契約は継続すると予想されます。この契約により、IESGは最大6か月の遅延を要求し、必要に応じてその要求を2回更新することを許可します。
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エディターが公開せず、その要求に対して適切な正当化を提供することを要求します。RFCエディターは、ドキュメントを公開しないようにリクエストを検討します。
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がドキュメントを遅らせるかどうかのIESGの要求を確認し、IABが追加の意見を提供するように要求することを要求することができます。このようなリクエストは、RFCエディター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編集者は、専門誌や出版社の編集委員会と同様に、特定の提案された出版物と一般的および戦略的政策アドバイスのアドバイスとレビューの両方を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エディターは、IABやその他の情報源からの新しい任命者に対する提案を際立し、任命されるものに関するIABのコメントを求めます。また、RFCエディターは、レビュープロセスの有効性と公開されているドキュメントの品質と適用される基準に関する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エディターは、著者への公平性のバランスをとる目的、レビュープロセスの一般コミュニティへの透明性、報復の可能性や過度のプレッシャーからのレビュアーの保護、およびコミュニティの関心を持っていることを意図して、上記のレビューを実施します。元の文書が受け取ったのと同じ程度の精査で、コミュニティが利用できる公開された文書。この目的のために、レビュアーに関するレビューと情報は、次の状況下で公開されます。他の考慮事項が適用される特別な場合、RFCエディターは、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エディターは、いずれにせよ、著者の反論メッセージをレビュアーに転送します。
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エディターは、ドキュメントに関連するレビューの完全なセット（および著者の反論）を投稿することを選択できます。コミュニティ。著者は、たとえば、レビューと反論の以前の投稿と反論の投稿を要求して、たとえば追加の未承諾のレビューを刺激することができます。レビュアーの名前は、匿名を要求したレビュアーを除き、レビューに同行します。
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エディターがドキュメントを拒否した場合、著者には次のオプションがあります。
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.
o レビューをRFCエディターWebサイトで公開するようにリクエストします。
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.
RFCエディターは、RFCエディターが、RFCにコメントまたは反対する最良の方法は一般に別のRFCであることに注意することが期待されることが期待されています。文書に批判的なレビューはそれ自体がレビューされていません。レビューと反論のプロセスが必然的に断片的であること。そして、レビューがすでに書かれていることについての主題について強く感じているレビュアーは、そのレビューからRFC形式の文書を作成するために重要な追加作業を行う必要はありません。
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、IETF管理サポート活動（IASA）またはIETFトラストの支援の下で生成された技術出版物のすべての独立した提出情報を取得するために、BCP 78 [RFC3978] [RFC4748]の関連セクションから次の材料を抽出しました。または、インターネット協会（ISOC）は、独立した提出物の議論を標準トラックまたは他のIETFドキュメントに関するものと分離するプロセスを初期化します。次のテキストは、「RFCエディターの貢献」という用語を使用して、このドキュメントの他の場所で「独立した提出」と呼ばれる同じタイプのドキュメントを説明することに注意してください。RFCエディターは、RFCSの正式な出版社としての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エディターの貢献をインターネットドラフトとしてコピー、公開、表示、配布します。
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,
A.英語以外の言語にRFCの翻訳を準備または準備することを許可するには、
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エディターの貢献者が使用する商標およびサービスマーク識別子を保存します。
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.貢献者は、IETFトラストとIETFを付与し、貢献者とHEの名前と住所（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.
このドキュメントの以前のバージョンで改善されたテキストについていくつかの提案をしたボブ・ヒンデンとクレイグ・パートリッジ、そしてスチュワート・ブライアント、スコット・ブラッドナー、ブライアン・カーペンター、ヴィント・ケルフ、レスリー・デイグル、オラフ・コルクマンが数を出したことに感謝します。後続のバージョンの組織とコンテンツに関する有用な提案の。また、BCP 78 [RFC3978]から抽出され、セクション8で使用された資料について、編集者のIETFとScott Bradnerに感謝します。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC2223] Postel、J。およびJ. Reynolds、「RFC著者への指示」、RFC 2223、1997年10月。
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004.
[RFC3932] Alvestrand、H。、「IESGおよびRFCエディタードキュメント：手順」、BCP 92、RFC 3932、2004年10月。
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
[RFC3978] Bradner、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] Bradner、S。、「IETF Trustを認識するRFC 3978アップデート」、BCP 78、RFC 4748、2006年10月。
[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>.
[IEN137] Cohen、D。、「聖戦と平和の嘆願」、Ien 137、1980年4月、<ftp://ftp.rfc-editor.org/in-notes/ien/ien137.txt>。
[RFC0021] Cerf, V., "Network meeting", RFC 21, October 1969.
[RFC0021] Cerf、V。、「ネットワーク会議」、RFC 21、1969年10月。
[RFC1109] Cerf, V., "Report of the second Ad Hoc Network Management Review Group", RFC 1109, August 1989.
[RFC1109] Cerf、V。、「2番目のアドホックネットワーク管理レビューグループのレポート」、RFC 1109、1989年8月。
[RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.
[RFC1591] Postel、J。、「ドメイン名システム構造と委任」、RFC 1591、1994年3月。
[RFC1810] Touch, J., "Report on MD5 Performance", RFC 1810, June 1995.
[RFC1810] Touch、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。、編and R. Braden、ed。、「コメント要求の指示（RFC）著者」、2004年8月、Progress In Progress。
[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] Cohen、D。、「1998年10月30日、UCLAで配信されたJon Tributeとの協力」、RFC 2441、1998年11月。
[RFC2555] Braden, R., Reynolds, J., Crocker, S., Cerf, V., Feinler, J., and C. Anderson, "30 Years of RFCs", RFC 2555, April 1999.
[RFC2555] Braden、R.、Reynolds、J.、Crocker、S.、Cerf、V.、Feinler、J。、およびC. Anderson、「30年のRFC」、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] Carpenter、B.、Baker、F。、およびM. Roberts、「インターネットが割り当てられた数字の権限の技術的作業に関する覚書」、RFC 2860、2000年6月。
[RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF Technical Publication Service", RFC 4714, October 2006.
[RFC4714] Mankin、A。およびS. Hayes、「IETF技術出版サービスの要件」、RFC 4714、2006年10月。
[RFC4844] Daigle, L., Ed. and IAB, "The RFC Series and RFC Editor", RFC 4844, July 2007.
[RFC4844] Daigle、L.、ed。IAB、「RFCシリーズおよびRFCエディター」、RFC 4844、2007年7月。
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
バーナード・アボバ・ロア・アンダーソン・ブライアン・カーペンター・レスリー・デイグル・エルウィン・デイヴィス・ケビン・フォール・フォール・オラフ・コルクマン・カルティス・リンドクヴィスト
Authors' Addresses
著者のアドレス
John C Klensin (editor) 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
ジョンCクレンシン（編集者）1770マサチューセッツアベニュー、＃322ケンブリッジ、マサチューセッツ州02140 USA
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Dave Thaler (editor) One Microsoft Way Redmond, WA 98052 USA
Dave Thaler（編集者）One Microsoft Way Redmond、WA 98052 USA
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。