Network Working Group H. Alvestrand
Request for Comments: 4693 Google
Category: Experimental October 2006
IETF Operational Notes
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document describes a new document series intended for use as a repository for IETF operations documents, which should be more ephemeral than RFCs, but more referenceable than Internet-Drafts, and with more clear handling procedures than a random Web page.
この文書は、RFCにより短命が、インターネットドラフトよりも参照可能、かつランダムなWebページより明確な取り扱い手順であるべきIETF業務文書のリポジトリとして使用することを意図し、新しい文書シリーズについて説明します。
It proposes to establish this series as an RFC 3933 process experiment.
これは、RFC 3933のプロセス実験としてこのシリーズを確立することを提案しています。
Table of Contents
目次
1. Introduction ....................................................2
2. A Description of the ION Mechanism ..............................2
2.1. Properties of an ION .......................................2
2.2. ION Approval ...............................................3
2.3. Draft IONs .................................................3
2.4. The ION Store ..............................................4
3. Proposed Initial IONs ...........................................4
4. Success Criteria and Sunset Period ..............................5
5. Background and Motivation .......................................6
6. IANA Considerations .............................................7
7. Security Considerations .........................................8
8. Acknowledgements ................................................8
9. References ......................................................8
9.1. Normative References .......................................8
9.2. Informative References .....................................8
This document describes a new document series, called the IETF Operational Notes, or IONs.
この文書は、IETF操作上の注意事項、またはイオンと呼ばれる新しいドキュメントシリーズを、説明しています。
This document series is intended to capture the set of procedures that the IETF follows, but for which the RFC process is an inappropriate documentation vehicle.
この文書シリーズは、IETFは、以下の手順のセットを捕捉することを意図するものではなく、そのためRFCプロセスが不適切マニュアル車です。
The document series defined here does not modify the IETF process rules that are defined in currently valid BCP documents.
ここで定義されたドキュメントシリーズは、現在有効なBCP文書で定義されているIETFプロセスルールを変更しません。
The document series is a process experiment according to RFC 3933 [RFC3933].
ドキュメントシリーズは、RFC 3933 [RFC3933]に従う方法の実験です。
An ION is a document with a certain set of attributes ("front page matter"). This specification does not place any limits on what else an ION can contain.
IONは、属性の特定のセット（「フロントページ事項」）との文書です。この仕様は、IONに含めることができる他に何上の任意の制限を課しません。
An ION has the following attributes:
IONは、次の属性があります。
o A name, which is usable as the filename of the document
文書のファイル名として使用可能である名前、O
o A title
お あ ちｔぇ
o A date of approval
承認日O
o An identification of the body that approved this version
Oこのバージョンを承認した体の識別
The format of the document is not restricted by this document. It's suggested that there be an ION that describes expectations for ION formats.
文書の形式は、本文書に限定されるものではありません。 IONフォーマットへの期待を説明しIONがあることを示唆しています。
An ION is a versioned document. When a new ION is issued with the same name, it obsoletes the previous version. When one desires to retire an ION, one issues an ION saying "This document name is now obsolete".
IONは、バージョニングされたドキュメントです。新しいIONは、同じ名前で発行されると、それは以前のバージョンを廃止します。 1はIONを引退することを望むとき、人は「この文書名は廃止されました」と言っIONを発行します。
The ION name + the approval date forms a stable identifier for one particular version of an ION; once it is published, it shall never be changed, although it may be withdrawn (see below).
ION名+承認日は、IONの一つの特定のバージョンのための安定した識別子を形成し;それが公開されたら、それは撤回することができるが、それは（下記参照）、変更することはないものとします。
The properties list does not include a "category"; while the set of documents that might be IONs is extremely wide, we do not know yet which categories could make sense. The question of categories might get revisited at the end of the experiment period.
プロパティリストには、「カテゴリ」が含まれていません。イオンがあるかもしれない文書のセットは非常に広いですが、私たちは知らないまだどのカテゴリには意味をなさないことができます。カテゴリーの質問は、実験期間の終了時に再訪てしまうかもしれません。
Procedurally, an ION has the formal authority of a statement from its approving body. This means that an ION cannot change those procedures of the IETF that are documented via the BCP series, since the BCP series represents a determination of IETF consensus.
手続き上、IONは、その承認体から声明の正式な権限を有しています。これは、BCPシリーズはIETFコンセンサスの決定を表すのでIONは、BCPシリーズを介して文書化されているIETFのこれらの手順を変更できないことを意味します。
An ION is always approved by some body. The IESG is granted authority by this document over the practical management of the series and the definition of detailed processes and rules associated with it.
IONは、常にいくつかの機関によって承認されています。 IESGは、一連の実用的な管理とそれに関連する詳細なプロセスやルールの定義より、この文書により権限を付与されます。
The IESG, the IAB, and IAOC are given the right to approve IONs by this document. The IESG, IAB, or IAOC may decide that other groups or roles should be given the right to approve IONs.
IESG、IAB、およびIAOCは、この文書でイオンを承認する権利を与えられています。 IESG、IAB、またはIAOCは、他のグループや役割は、イオンを承認する権利を与えられるべきであると判断してもよいです。
The ION-approving groups are expected to issue IONs related to their own areas of responsibility, and to use common sense when IONs are needed where it isn't obvious who's responsible for them.
ION-承認グループは、責任の自分の分野に関連したイオンを発行し、彼らのために責任が誰明らかでない場合、イオンが必要な時に常識を使用することが期待されています。
An updated ION will normally be approved by the same body that approved the previous version, or by another body with the approval of the previously-approving body. In case of conflict, or when the previous body no longer exists, the IESG will decide who gets to approve an updated ION.
更新IONは、通常、以前のバージョン、または別体で、以前に承認体の承認を得て承認を同じ身体によって承認されます。前の体がもう存在しない時に矛盾がある場合に、または、IESGが更新IONを承認するために誰が決めるんだろう。
A decision by any other body than the IESG to approve an ION can be appealed to the IESG, in which case the IESG can nullify the approval. A decision of the IESG can be appealed using the common IETF appeals procedure, except that an IESG decision to nullify an IAB decision to approve an ION cannot be appealed to the IAB.
IONを承認するIESG以外の機関による決定は、IESGが承認を無効にすることができ、その場合には、IESGに控訴することができます。 IESGの決定はIONを承認するIABの決定を無効にするIESGの決定は、IABにアピールすることができないことを除いて、一般的なIETF控訴手続きを使用して上訴することができます。
In the case that the IESG ceases to exist, its successors or assignees will take over the tasks given to the IESG in this document.
IESGが存在しなくなった場合には、その後継者または譲受人は、本文書にIESGに与えられたタスクを引き継ぎます。
There is no requirement that an ION will be published as a draft before publication. This will, however, be desirable in many cases, and thus, this document describes the properties and procedures for handling draft IONs.
IONは、出版前にドラフトとして公開される必要はありません。これは、しかし、多くの場合に望ましいであろうし、したがって、この文書はドラフトイオンを処理するためのプロパティと手順を説明します。
Draft IONs shall have, instead of an approval date and an identification of the body that approved it, information about:
ドラフトイオンは、代わりに承認日と、それを承認した体の同定、についての情報を持っていなければなりません。
o The word "DRAFT", prominently displayed
単語「DRAFT」、目立つように表示O
o The publication date and time
O発行日時
o The approval date of the document it is intended to update (if any)
（もしあれば）を更新することを意図している文書の承認日O
o The body that is intended to approve this version
このバージョンを承認することを意図しているボディO
o The appropriate forum for discussion of this draft (if any)
この草案の議論のための適切なフォーラム（もしあれば）O
All approved IONs are archived, in all their versions, and made publicly available from resources operated by the IETF secretariat. The store should be reachable by common methods like HTTP and FTP, and should offer both easy access to the "current" version of all IONs and bulk download of all IONs, all versions.
すべて承認されたイオンはすべてのバージョンでは、アーカイブ、およびIETF事務局が運営するリソースから公開されています。ストアは、HTTPやFTPなどの一般的な方法によって到達可能である必要があり、全てのイオンの「現在」のバージョンとすべてのイオン、すべてのバージョンの一括ダウンロードへの容易なアクセスの両方を提供する必要があります。
This document does not constrain the form of the ION Store, but mandates that there be a public one.
この文書では、IONストアの形式を制約するが、公共の1が存在することが義務付けられていません。
Public draft IONs are published separately from the approved IONs. Old versions may be published in the draft store and must be kept in a version management system for the duration of the experiment. Experience will show what the best policy for draft retention is if the series is made permanent.
公開草案イオンが承認されたイオンとは別に公開されています。古いバージョンでは、ドラフトストアに公開することができると実験期間中、バージョン管理システムに保管されなければなりません。経験はシリーズは永久的なものにされている場合、ドラフト保持のための最善の政策が何であるかが表示されます。
The following IONs should be created as soon as possible after this document is published, to give the details of the maintenance of the ION series, in order to bootstrap the process:
以下のイオンは、プロセスを起動するためには、イオン系列のメンテナンスの詳細を与えるために、できるだけ早くこの文書が公開された後に作成する必要があります。
o The ION Format Guide
IONフォーマットガイドO
o The ION Store Description
IONストアの説明O
The following list of documents, some of which currently exist, provides examples of documents that could be converted to IONs. This is not a binding recommendation, but gives examples of what IONs can be good for.
現在存在し、その一部の文書の以下のリストは、イオンに変換することができる書類の例を提供します。これは、結合の推薦ではなく、イオンはのために良いことができるかの例を示します。
o The I-D publishing procedure o The checklist for I-D submission to the IESG (formerly known as id-nits)
（旧ID-ニットとしても知られる）IESGにI-Dの提出のためのチェックリストO I-D公開手順O
o Procedures for spam control on IETF mailing lists
IETFメーリングリスト上のスパム制御のためのO手続き
o Procedures for requesting a WG meeting slot
WG会議スロットを要求するためのO手続き
o Procedures for IETF minutes
IETF分間O手続き
o Procedures for IESG meeting minutes
IESG会議議事録のためのO手続き
Once the ION series is permanent, the existence of the ION series may cause the following documents to be split into a "policy and principles" BCP and a "procedures and boilerplate" document published as ION:
IONシリーズは永久になると、IONシリーズの存在は、以下の文書は、「ポリシーと原則」BCPおよびIONとして公開「手順や決まり文句」文書に分割される可能性があり：
o IETF Rights in Documents (currently BCP 78) RFC 3978 [RFC3978]
IETF権利O資料中の（現在BCP 78）RFC 3978 [RFC3978]
o IETF Rights in Technology (currently BCP 79) RFC 3979 [RFC3979]
OテクノロジーにおけるIETF権（現在はBCP 79）RFC 3979 [RFC3979]
o IETF mailing list management (currently RFC 3005 [RFC3005], BCP 45, RFC 3683 [RFC3683], BCP 83, and RFC 3934 [RFC3934], BCP 94)
O IETFメーリング・リスト管理（現在はRFC 3005 [RFC3005]、BCP 45、RFC 3683 [RFC3683]、BCP 83、及びRFC 3934 [RFC3934]、BCP 94）
If someone wishes to do such a split while the experiment is running, the BCPs cannot refer to the "procedures" documents as IONs, since the concept of an ION may go away. In that case, any procedures removed from a BCP must either be reinstated or otherwise stored as a permanently available reference.
実験の実行中に、誰かがこのような分割を行うことを希望する場合はIONの概念が離れて行くかもしれないので、のBCPは、イオンとして「手続き」の文書を参照することはできません。その場合には、BCPから取り外した手順のいずれか回復しなければならないか、そうでなければ恒久的に利用可能な基準として記憶されます。
This experiment is expected to run for a period of 12 months, starting from the date of the first ION published using this mechanism. At the end of the period, the IESG should issue a call for comments from the community, asking for people to state their agreement to one of the following statements (or a suitable reformulation thereof):
この実験は、IONは、このメカニズムを使用して公開最初の日から、12ヶ月の期間で実行することが期待されます。期間の終了時に、IESGは、次のステートメントの1つ（またはその適切な改質）への同意を述べるために人々のために求め、コミュニティからのコメントのための呼び出しを発行する必要があります。
1. This document series has proved useful, and should be made permanent
1.このドキュメントシリーズが有用であることが判明した、と永久なされるべきです
2. This document series is less useful than the equivalent information in RFCs and informal Web pages, and should be abandoned
2.このドキュメントシリーズは、RFCと非公式のWebページで同等の情報よりも少ない有用であり、放棄されるべき
The author believes that establishing objective metrics for the success or failure of this experiment is not a worthwhile exercise; the success or failure will be readily apparent in the community's attitudes towards the series.
著者は、この実験の成功または失敗のための客観的指標を確立することは価値が行使ではないと考えています。成功または失敗を直列に向けた地域社会の態度には容易に明らかであろう。
If the feedback reveals a community consensus for keeping the series, the IESG may choose to create a new BCP RFC containing the information herein, suitably modified by experience.
フィードバックは、シリーズを維持するためのコミュニティのコンセンサスがあることが判明した場合、IESGは適切な経験によって変更され、本明細書の情報を含む新しいBCPのRFCを作成することもできます。
If the IESG decides that the feedback warrants terminating the series, the repository will be closed for new documents, and the existing ION documents will be returned to having the same status as any other Web page or file on the IETF servers -- this situation will closely resemble the situation before the experiment started.
IESGは、フィードバックワラントは、シリーズを終了することを決定した場合、リポジトリは、新しいドキュメントのため閉鎖され、既存のION文書はIETFのサーバ上の他のWebページやファイルと同じ地位を有することに返送されます - このような状況は、意志実験開始前に密接な状況に似ています。
The IETF is an open organization, which means (among other things) that there are always newcomers coming in to learn how to perform work; this places a requirement on the organization to document its processes and procedures in an accessible manner.
IETFは、作業を実行する方法を学ぶために入ってくる新規参入が常に存在していること（とりわけ）を意味オープン団体、です。これは、アクセス可能な方法でそのプロセスおよび手順を文書化するために、組織上の要件を課します。
The IETF is also a large organization, which means that when procedures change, there are a number of people who will like to know of the change, to figure out what has changed, and possibly to protest or appeal the change if they disagree with it.
IETFは、手順が変更されたとき、彼らはそれに同意しない場合は変更されているかを把握するために、変更を知りたいでしょうし、おそらく変更に抗議あるいは上訴する人の数があることを意味し、また、大規模な組織であります。
At the present time (spring 2006), there are three kinds of documents used for IETF documentation of its operations and procedures:
現時点（2006年春）には、その操作や手順のIETF文書化のために使用されたドキュメントの3種類があります。
o BCP and Informational RFCs, which require an IETF consensus call for BCP, approval by the IESG, and usually a great deal of debate and effort to change, and which bind up editing resources in the final edit stage, as well as being limited (in practice) to ASCII. The BCP number forms a means of having a stable reference for new versions of a document, but an updated Info RFC has a completely different identifier from the RFC that it updates; "updates/ obsoletes" links can give some of the same information, but can also be quite confusing to follow.
O BCPと情報のRFC、変更するにはBCPのためのIETFコンセンサスコール、IESGの承認、および議論と努力の通常多くを必要とし、最終編集段階で編集リソースを結合するだけでなく、限定されるものでは（ ）実際にはASCIIへ。 BCP番号は、文書の新しいバージョンの安定した基準を有する手段を形成するが、更新された情報RFCは、それが更新RFC全く異なる識別子を有します。リンクは、同じ情報のいくつかを与えることができ、また従うことが非常に混乱することができ、「アップデート/廃止」。
o Web pages, which can be changed without notice, provide very little ability to track changes, and have no formal standing -- confusion is often seen about who has the right to update them, what the process for updating them is, and so on. It is hard when looking at a Web page to see whether this is a current procedure, a procedure introduced and abandoned, or a draft of a future procedure. For certain procedures, their informal documentation in the "IESG Guide" wiki has partially clarified this situation but has no official status.
予告なしに変更することができるWebページ、O、変更を追跡するために非常に少ない能力を提供し、正式な地位を持っていない - 混乱がしばしばようにそれらを更新するためのプロセスが何であるか、それらを更新する権利を持っている人については見ており、 。これは現在のプロシージャ、導入および放棄された手順、または将来の手続きの草案であるかどうかを確認するために、Webページを見ているとき、それは難しいです。特定の手順については、「IESGガイド」のwikiでの非公式ドキュメントは、部分的にこのような状況を明らかにしたが公式のステータスを持っていませんでした。
o "floating" Internet-Drafts, which are frequently updated, in a trackable manner, but have no approval mechanism, are limited (in practice) to ASCII format, and whose use as semi-permanent documents clutters up their use as 6-month temporary working documents.
頻繁に追跡可能な方法で、更新されますが、何の承認メカニズムを持っていない、ASCII形式に（実際に）制限されており、その使用は半永久的文書のクラッタとして最大6ヶ月としての使用されているO「浮動」インターネットドラフト、一時的な作業文書。
This note introduces a new series that seems to fulfil the requirements for "something in between":
このノートは、「間に何か」のための要件を満たしているようだ新シリーズが導入されています。
o Unlike RFCs, they can be produced without a post-editing stage, they can be in any format the controllers of the series choose (allowing web pages with hyperlinks, which is an advantage for newcomers).
RFCとは異なり、彼らはポスト編集段階せずに製造することができるO、彼らはシリーズのコントローラは（新規参入のための利点である、ハイパーリンク付きのWebページを可能）選択した任意の形式にすることができます。
o Also unlike RFCs, they can be produced by any body that the IESG gives the right to use the mechanism; this allows certain procedures to be updated without having to wait for the IESG approval cycle.
OまたのRFCとは異なり、彼らはIESGメカニズムを使用する権利を与える任意の体内で生成することができます。これは、特定の手順は、IESGの承認サイクルを待たずに更新することができます。
o Unlike Internet-Drafts, they have an explicit approval step -- this allows a reader to easily see the difference between an idea and an operational procedure.
Oインターネットドラフトとは異なり、彼らは明示的な承認ステップを持っている - これは、読者が簡単にアイデアや操作手順の違いを見ることができます。
o Unlike Web pages, there is an explicit mechanism for finding "all current versions", and a mechanism for tracking the history of a document.
O Webページとは異なり、「現在のすべてのバージョン」、および文書の歴史を追跡するためのメカニズムを発見するための明示的なメカニズムがあります。
The "author" attribute has quite deliberately been omitted from the required property list. While there may be many cases where identifying an author is a Good Thing, the responsibility for an approved ION rests with the approving body.
「著者」属性は、かなり意図的に必要なプロパティリストから省略されました。作者を特定することは良いことです多くの例があるかもしれませんが、承認されたIONの責任は承認体にかかっています。
Note: This proposal is NOT intended to affect the standards track in any way -- a side effect may be to reduce the number of "process BCPs" emitted, but this has no direct bearing on the IETF's technical specifications. It is therefore not within the scope of the NEWTRK working group.
注意：この提案は、規格がどのような方法で追跡に影響することを目的とされていない - 副作用が放出され、「プロセスのBCP」の数を減らすことかもしれないが、これはIETFの技術仕様には直接関係がありません。それはNEWTRKワーキンググループの範囲内でそのためではありません。
IONs will not include protocol specifications, so IONs will make no requests for IANA actions. IANA will not need to review all IONs.
イオンはIANAのアクションのための要求を行いませんので、イオンは、プロトコル仕様が含まれていません。 IANAは、全てのイオンを検討する必要はありません。
This document makes no requests of IANA either.
この文書では、どちらかのIANAの何の要求も行いません。
IONs will not include protocol specifications, so shouldn't have much need to talk about security the way RFCs do.
イオンは、プロトコルの仕様が含まれないので、セキュリティについてのRFCのやり方を話す多くの必要性を持つべきではありません。
Many people have contributed over the years to the ideas that I have tried to express here.
多くの人々は、私がここに表現しようとしたアイデアに長年にわたって貢献してきました。
I'm in particular indebted to John Klensin for his work on trying to find a balance between formalism and flexibility in the IETF process, and for his earlier attempts at creating such a document series as an adjunct to the "ISD" effort, and for his many valuable comments on this document.
私は、IETFプロセスに形式化と柔軟性のバランスを見つけようとの彼の仕事のためにジョン・クレンシンにお世話特にだし、「ISD」努力の補助として、このようなドキュメントシリーズを作成するに彼の以前の試みのために、とのためにこのドキュメントの彼の多くの貴重なコメント。
In addition, Dave Crocker, Spencer Dawkins, Jeff Hutzelman, Sam Hartman, and David Black (gen-ART reviewer) provided valuable comments at Last Call time.
また、デイブ・クロッカー、スペンサードーキンスジェフHutzelman、サム・ハートマン、そしてデヴィッド・ブラック（GEN-ART投稿者）ラストコール時の貴重なコメントを提供しました。
[RFC3933] Klensin, J. and S. Dawkins, "A Model for IETF Process Experiments", BCP 93, RFC 3933, November 2004.
[RFC3933] Klensin、J.及びS.ドーキンス、 "IETFプロセスの実験のためのモデル"、BCP 93、RFC 3933、2004年11月。
[RFC3005] Harris, S., "IETF Discussion List Charter", BCP 45, RFC 3005, November 2000.
[RFC3005]ハリス、S.、 "IETFディスカッションリスト憲章"、BCP 45、RFC 3005、2000年11月。
[RFC3683] Rose, M., "A Practice for Revoking Posting Rights to IETF mailing lists", BCP 83, RFC 3683, February 2004.
[RFC3683]ローズ、M.、 "IETFメーリングリストへの投稿の権利を取り消すための実践"、BCP 83、RFC 3683、2004年2月。
[RFC3934] Wasserman, M., "Updates to RFC 2418 Regarding the Management of IETF Mailing Lists", BCP 94, RFC 3934, October 2004.
"IETFメーリングリストの管理に関するRFC 2418への更新" [RFC3934]ワッサーマン、M.、BCP 94、RFC 3934、2004年10月。
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
[RFC3978]ブラドナーの、S.、 "質問の投稿IETF権"、BCP 78、RFC 3978、2005年3月。
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
[RFC3979]ブラドナーの、S.、 "IETF技術の知的財産権"、BCP 79、RFC 3979、2005年3月。
Author's Address
著者のアドレス
Harald Tveit Alvestrand Google Beddingen 10 N-7014 Trondheim Norway
ハラルド・トバイット・アルベストランドグーグルBeddingen 10 N-7014トロンハイムノルウェー
EMail: harald@alvestrand.no
メールアドレス：harald@alvestrand.no
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。