[要約] RFC 4693は、IETFの運用上の注意事項をまとめたものであり、ネットワーク運用者に対して実践的なガイダンスを提供することを目的としています。
Network Working Group H. Alvestrand
Request for Comments: 4693 Google
Category: Experimental October 2006
IETF Operational Notes
IETF運用ノート
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントでは、IETF操作ドキュメントのリポジトリとして使用することを目的とした新しいドキュメントシリーズについて説明します。これは、RFCよりもはるかには短いが、インターネットドラフトよりも参照可能であり、ランダムWebページよりも明確な取り扱い手順を備えています。
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.
イオンは、特定の属性セット（「フロントページの問題」）を備えたドキュメントです。この仕様では、イオンが他に含めることができるものに制限はありません。
An ION has the following attributes:
イオンには次の属性があります。
o A name, which is usable as the filename of the document
o ドキュメントのファイル名として使用可能な名前
o A title
o タイトル
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.
ドキュメントの形式は、このドキュメントによって制限されていません。イオン形式への期待を説明するイオンがあることが示唆されています。
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".
イオンはバージョンされたドキュメントです。新しいイオンが同じ名前で発行されると、以前のバージョンが廃止されます。イオンを引退したい場合、「このドキュメント名は廃止された」というイオンを発行します。
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).
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.
手続き的には、イオンには承認機関からの声明の正式な権限があります。これは、BCPシリーズがIETFコンセンサスの決定を表しているため、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.
イオンは常に何らかの身体によって承認されます。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.
イオン承認グループは、自分の責任領域に関連するイオンを発行し、イオンが必要な場合に誰が責任を負わない場合に常識を使用することが期待されています。
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.
更新されたイオンは通常、以前のバージョンを承認したのと同じ本体、または以前に承認した本体の承認を得て別のボディによって承認されます。紛争の場合、または前のボディが存在しなくなった場合、IESGは誰が更新されたイオンを承認できるかを決定します。
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.
IESG以外のボディによるイオンを承認するという決定は、IESGに訴えることができます。その場合、IESGは承認を無効にすることができます。IESGの決定は、IETFアピール手続きを使用して控訴することができますが、IESGがIABを承認するというIABの決定を無効にする決定は、IABに控訴できないことを除きます。
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.
公開前にイオンがドラフトとして公開されるという要件はありません。ただし、これは多くの場合に望ましいため、このドキュメントでは、ドラフトイオンを処理するための特性と手順について説明します。
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
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.
このドキュメントは、イオンストアの形式を制約しませんが、公開されているものがあることを義務付けています。
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
o
o The ION Store Description
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)
o IESGへのI-D提出のチェックリスト（以前はID-Nitsとして知られています）
o Procedures for spam control on IETF mailing lists
o IETFメーリングリストのスパム制御の手順
o Procedures for requesting a WG meeting slot
o WGミーティングスロットを要求する手順
o Procedures for IETF minutes
o
o Procedures for IESG meeting minutes
o IESG会議議事録の手順
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:
o IETF Rights in Documents (currently BCP 78) RFC 3978 [RFC3978]
o 文書のIETF権利（現在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.
実験中に誰かがそのような分割をしたい場合、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):
この実験は、このメカニズムを使用して公開された最初のイオンの日付から12か月間実行されると予想されます。期間の終わりに、IESGはコミュニティからのコメントの呼びかけを発行し、次の声明のいずれか（または適切な再定式化）に合意を述べるように人々に求める必要があります。
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. このドキュメントシリーズは、RFCSおよび非公式のWebページの同等の情報よりも有用ではなく、放棄する必要があります
3. We cannot decide yet; the experiment should continue 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.
3. まだ決めることはできません。この実験は、この実験の成功または失敗のための客観的な指標を確立することは価値のある運動ではないと著者を継続する必要があります。成功または失敗は、シリーズに対するコミュニティの態度で容易に明らかになります。
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がフィードバックがシリーズの終了を保証することを決定した場合、リポジトリは新しいドキュメントのために閉鎖され、既存のイオンドキュメントは、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および情報RFCSは、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.
o 予告なしに変更できるWebページは、変更を追跡する能力をほとんど提供し、正式な地位を持たないことができます。それらを更新する権利、それらを更新するプロセスなどについては、混乱がよく見られます。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.
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).
o RFCとは異なり、編集後の段階なしで生産できます。シリーズのコントローラーが選択した任意の形式（ハイパーリンク付きの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.
「著者」属性は、必要なプロパティリストから意図的に省略されています。著者を識別することが良いことである多くの場合があるかもしれませんが、承認されたイオンの責任は承認機関にかかっています。
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.
イオンにはプロトコル仕様が含まれていないため、RFCSのようにセキュリティについて話す必要はありません。
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.
さらに、Dave Crocker、Spencer Dawkins、Jeff Hutzelman、Sam Hartman、David Black（Gen-Art Reviewer）は、昨年のコールタイムで貴重なコメントを提供しました。
[RFC3933] Klensin, J. and S. Dawkins, "A Model for IETF Process Experiments", BCP 93, RFC 3933, November 2004.
[RFC3933]クレンシン、J。およびS.ドーキンス、「IETFプロセス実験のモデル」、BCP 93、RFC 3933、2004年11月。
[RFC3005] Harris, S., "IETF Discussion List Charter", BCP 45, RFC 3005, November 2000.
[RFC3005] Harris、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.
[RFC3934] Wasserman, M., "Updates to RFC 2418 Regarding the Management of IETF Mailing Lists", BCP 94, RFC 3934, October 2004.
[RFC3934] Wasserman、M。、「IETFメーリングリストの管理に関するRFC 2418の更新」、BCP 94、RFC 3934、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月。
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
Author's Address
著者の連絡先
Harald Tveit Alvestrand Google Beddingen 10 N-7014 Trondheim Norway
Harald Tveit Alvestrand Google Beddingen 10 N-7014 Trondheim Norway
EMail: harald@alvestrand.no
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。