Network Working Group J. Rosenberg
Request for Comments: 4453 Cisco Systems
Category: Informational G. Camarillo, Ed.
Ericsson
D. Willis
Cisco Systems
April 2006
Requirements for Consent-Based Communications
in the Session Initiation Protocol (SIP)
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 Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
The Session Initiation Protocol (SIP) supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including spam and denial-of-service attacks. This document identifies a set of requirements for extensions to SIP that add consent-based communications.
セッション開始プロトコル（SIP）は、リアルタイムのオーディオ、ビデオ、テキスト、インスタントメッセージング、プレゼンスなど、多くのメディアタイプ、間の通信をサポートしています。現在の形では、セッション招待、インスタントメッセージ、および受信者の明示的な同意を必要とせずに別の関係者から配信される他の要求を可能にします。 SIPは、スパムやDoS攻撃などの悪質な目的に使用されるために、このような同意がなければ、それが可能です。この文書では、同意ベースのコミュニケーションを追加するSIPへの拡張のための要件のセットを識別します。
Table of Contents
目次
1. Introduction ....................................................2
2. Problem Statement ...............................................2
3. Requirements ....................................................4
4. Security Considerations .........................................5
5. References ......................................................6
5.1. Normative References .......................................6
5.2. Informational References ...................................6
The Session Initiation Protocol (SIP) [1] supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. This communication is established by the transmission of various SIP requests (such as INVITE and MESSAGE [3]) from an initiator to the recipient, with whom communication is desired. Although a recipient of such a SIP request can reject the request, and therefore decline the session, a SIP network will deliver a SIP request to the recipient without their explicit consent.
セッション開始プロトコル（SIP）[1]は、リアルタイムのオーディオ、ビデオ、テキスト、インスタントメッセージング、プレゼンスなど、多くのメディアタイプ、間の通信をサポートしています。この通信は、通信が望まれると、受信者にイニシエータから（例えばINVITEとMESSAGE [3]のような）様々なSIPリクエストを送信することによって確立されます。そのようなSIPリクエストの受信者が要求を拒否し、そのためのセッションを辞退することができますが、SIPネットワークは、彼らの明示的な同意なしに受信者にSIPリクエストをお届けします。
Receipt of these requests without explicit consent can cause a number of problems in SIP networks. These include amplification attacks. These problems have plagued email. At the time of this writing, most SIP services are not interconnected, so the incidence of amplification attacks directed at SIP services is low compared to the same attacks on email services. The SIPPING working group believes it is necessary to address these attacks proactively so the attacks do not become as burdensome as attacks on email have become.
明示的な同意なしにこれらの要求の領収書は、SIPネットワークにおける多くの問題を引き起こす可能性があります。これらは、増幅攻撃が含まれます。これらの問題は、電子メールを悩ませてきました。この記事の執筆時点では、ほとんどのSIPサービスが相互接続されていないので、SIPサービスに向けた増幅攻撃の発生率は、電子メールサービスで同じ攻撃に比べて低いです。 SIPPINGワーキンググループは、攻撃が電子メールでの攻撃がなっているほど負担になりませんので、積極的にこれらの攻撃に対処するために必要であると考えています。
This document elaborates on the problems posed by the current open model in which SIP was designed, and then goes on to define a set of requirements for adding a consent framework to SIP.
この文書では、SIPが設計した後、SIPに同意フレームワークを追加するための要件のセットを定義するために行くされた現在のオープンモデルによって生じる問題について詳しく説明します。
In SIP networks designed according to the principles of RFC 3261 [1] and RFC 3263 [2], anyone on the Internet can create and send a SIP request to any other SIP user, by identifying that user with a SIP Uniform Resource Identifier (URI). The SIP network will usually deliver this request to the user identified by that URI. It is possible, of course, for network services, such as call screening, to block such messaging from occurring, but this is not widespread and certainly not a systematic solution to the problem under consideration here.
SIPネットワークでRFC 3261の原理に従って設計された[1]および[2]、インターネット上の誰でも作成することができ、SIPユニフォームリソース識別子とそのユーザを識別することによって、他のSIPユーザに対してSIPリクエストを送信RFC 3263（URI ）。 SIPネットワークは、通常、そのURIで識別されるユーザーには、このリクエストをお届けします。これは、発生からそのようなメッセージをブロックするために、もちろん、そのようなコールスクリーニングなどのネットワークサービスのために、可能であるが、これは、ここで検討中の問題への体系的な解決策普及していないですし、確かではありません。
Once the SIP request is received by the recipient, the user agent typically takes some kind of automated action to alert the user about receipt of the message. For INVITE requests, this usually involves delivering an audible alert (e.g., "ringing the phone"), or a visual alert (e.g., creating a screen pop-up window). These indicators frequently convey the subject of the call and the identity of the caller. Due to the real-time nature of the session, these alerts are typically disruptive in nature, so as to get the attention of the user.
SIPリクエストが受信者によって受信されると、ユーザエージェントは、通常、メッセージの受信についてユーザーに警告するために自動化されたアクションのいくつかの種類になります。 INVITE要求のために、これは通常（例えば、「電話を鳴らす」）可聴警報を提供する、または視覚警報（例えば、画面のポップアップウィンドウを作成する）が含まれます。これらの指標は、頻繁に呼び出しの対象と呼び出し側のアイデンティティを伝えます。ユーザーの注意を引くように起因するセッションのリアルタイム性に、これらのアラートは、自然の中で一般的に破壊されています。
For MESSAGE requests, the content of the message is usually rendered to the user.
MESSAGE要求の場合、メッセージの内容は、通常、ユーザーにレンダリングされます。
SUBSCRIBE [4] requests do not normally get delivered to the user agents residing on a user's devices. Rather, they are normally processed by network-based state agents. The watcher information event package allows a user to find out that such requests were generated for them, affording the user the opportunity to approve or deny the request. As a result, SUBSCRIBE processing, and most notably presence, already has a consent-based operation. Nevertheless, this already-existing consent mechanism for SIP subscriptions does not protect network agents against denial-of-service (DoS) attacks.
SUBSCRIBE [4]の要求は、通常、ユーザーのデバイスに常駐しているユーザエージェントに配信されません。むしろ、それらは通常、ネットワークベースの状態のエージェントによって処理されています。ウォッチャー情報イベントパッケージは、ユーザーがそのような要求は、ユーザーが要求を承認または拒否する機会を与える、彼らのために生成されたことを知ることができます。その結果、処理をSUBSCRIBE、そして最も注目すべき存在は、すでに同意ベースの操作があります。それにも関わらず、SIPサブスクリプションのこの既存の同意メカニズムは、サービス拒否（DoS）攻撃からネットワークエージェントを保護しません。
A problem that arises when requests can be delivered to user agents directly, without their consent, is amplification attacks. SIP proxies provide a convenient relay point for targeting a message to a particular user or IP address and, in particular, forwarding to a recipient that is often not directly reachable without usage of the proxy. Some SIP proxy servers forward a single request to several instances or contacts for the same user or resource. This process is called "forking". Another type of SIP server provides the SIP URI-list service [5], which sends a new copy of the same request to each recipient in the URI-list. Examples of URI-list services are subscriptions to resource lists [6], dial-out conference servers [8], and MESSAGE URI-list services [7]. A SIP URI-list service could be used as an amplifier, allowing a single SIP request to flood a single target host or network. For example, a user can create a resource list with 100 entries, each of which is a URI of the form "sip:identifier@target-IP", where target-IP is the IP address to which the attack is to be directed. Sending a single SIP SUBSCRIBE request to such a list will cause the resource list server to generate 100 SUBSCRIBE requests, each to the IP address of the target, which does not even need to be a SIP node.
リクエストが直接ユーザエージェントに配信することができたときに生じる問題は、本人の同意なしに、増幅攻撃です。 SIPプロキシは、特定のユーザまたはIPアドレスにメッセージを標的とし、具体的には、プロキシの使用なしにしばしば直接到達可能ではない受信者に転送するための便利な中継点を提供します。いくつかのSIPプロキシサーバは、いくつかのインスタンス、または同じユーザまたはリソースの連絡先への単一の要求を転送します。このプロセスは、「フォーク」と呼ばれています。 SIPサーバの別のタイプは、SIP URIリストサービスを提供する[5]、URIリスト内の各受信者に同じ要求の新しいコピーを送信します。 URIリストサービスの例としては、リストのリソースへのサブスクリプションしている[6]、ダイヤルアウト会議サーバ[8]、およびMESSAGE URI - リストサービス[7]。 SIP URIリストサービスは、単一のターゲットホストまたはネットワークをフラッディングする単一のSIP要求を許可、増幅器として使用することができます。ターゲットIPが攻撃を指向するのIPアドレスである「識別子@ターゲットIP SIP」、例えば、ユーザがフォームのURIであり、各々が100個のエントリを有するリソースのリストを作成することができます。単一SIPは、そのようなリストにSUBSCRIBEリクエストを送信すると、リソースリストサーバ100を生成するようになります各でもSIPノードである必要はありません、ターゲットのIPアドレスに、SUBSCRIBE要求。
Note that the target-IP does not need to be the same in all the URIs in order to attack a single machine. For example, the target-IP addresses may all belong to the same subnetwork, in which case the target of the attack would be the access router of the subnetwork.
ターゲット-IPは、単一のマシンを攻撃するために、すべてのURIで同じである必要はないことに注意してください。例えば、ターゲットIPアドレスは、すべての攻撃のターゲットはサブネットワークのアクセスルータになり、その場合には、同じサブネットワークに属していてもよいです。
In addition to launching DoS attacks, attackers could also use SIP URI-list servers as amplifiers to deliver spam. For INVITE requests, this takes the form of typical "telemarketer" calls. A user might receive a stream of never-ending requests for communications, each of them disrupting the user and demanding their attention. For MESSAGE requests, the problem is even more severe. The user might receive a never-ending stream of visual alerts (e.g., screen pop-up windows) that deliver unwanted, malicious, or otherwise undesired content.
DoS攻撃を開始することに加えて、攻撃者はまた、スパムを配信するために増幅器としてSIP URIリストサーバを使用することができます。 INVITE要求のために、これは典型的な「テレマーケティング」のコールの形をとります。利用者は、通信のための要求を終わることのないそれらのそれぞれは、ユーザを破壊し、彼らの注意を要求するストリームを受け取ることがあります。 MESSAGE要求の場合、問題はさらに深刻です。ユーザーは、不要な悪意のある、またはその他の望ましくないコンテンツを配信し、視覚的警告（例えば、画面のポップアップウィンドウ）の終わることのないストリームを受け取ることがあります。
Both amplification attacks related to spam and DoS can be alleviated by adding a consent-based communications framework to SIP. Such a framework keeps servers from relaying messages to users without their consent.
スパムやDoS攻撃に関連する両方の増幅攻撃は、SIPに同意ベースの通信フレームワークを追加することによって軽減することができます。このような枠組みは、本人の同意なしにユーザーにメッセージを中継するからサーバーを保持します。
The framework for SIP URI-list services [5] identifies amplification attacks as a problem in the context of URI-list services. That framework mandates the use of opt-in lists, which are a form of consent-based communications. The reader can find an analysis on how a consent-based framework helps alleviate spam-related problems in [9].
SIP URIリストサービスのためのフレームワークは、[5] URIリストサービスの文脈における問題として増幅攻撃を識別する。そのフレームワークは同意ベースのコミュニケーションの形をしているオプトインリストの使用を義務付け。読者は同意ベースのフレームワークは、[9]でスパム関連の問題を軽減することができますどのように分析を見つけることができます。
The following identify requirements for a solution that provides consent-based communications in SIP. A relay is defined as any SIP server, be it a proxy, Back-to-Back User Agent (B2BUA), or some hybrid, that receives a request and translates the request URI into one or more next-hop URIs to which it then delivers a request.
以下は、SIPに同意ベースの通信を提供するソリューションのための要件を特定します。リレーは、それが要求を受信し、それへの1つまたは複数の次ホップのURIに要求URIを変換プロキシ、バックツーバックユーザエージェント（B2BUA）、またはいくつかのハイブリッドであっても、任意のSIPサーバのように定義されます要求を提供します。
REQ 1: The solution must keep relays from delivering a SIP request to a recipient unless the recipient has explicitly granted permission to the relay using appropriately authenticated messages.
REQ 1：ソリューションは、受信者が明示的に適切に認証されたメッセージを使用してリレーに許可を与えていない限り、受信者にSIPリクエストを提供するからリレーを維持する必要があります。
REQ 2: The solution shall prevent relays from generating more than one outbound request in response to an inbound request, unless permission to do so has been granted by the resource to whom the outbound request was to be targeted. This requirement avoids the consent mechanism itself becoming the focus of DoS attacks.
REQ 2：そうするための許可がOutbound要求が対象とされることになった人へのリソースによって付与されていない限り、解決策は、インバウンド要求に応じて、複数のOutbound要求を生成するからリレーを防止しなければなりません。この要件は、DoS攻撃の焦点になってきて同意メカニズム自体を回避することができます。
REQ 3: The permissions shall be capable of specifying that messages from a specific user, identified by a SIP URI that is an Address-of-Record (AOR), are permitted.
REQ 3：許可がアドレス・オブ・レコード（AOR）であるSIP URIによって識別される特定のユーザからのメッセージが、許可されていることを特定できなければなりません。
REQ 4: Each recipient AOR must be able to specify permissions separately for each SIP service that forwards messages to the recipient. For example, Alice may authorize forwarding to her from domain A, but not from domain B.
REQ 4：各受信者のAORは、受信者にメッセージを転送する各SIPサービスに対して個別に権限を指定することができなければなりません。例えば、アリスはなく、ドメインBから、ドメインAから彼女への転送を許可することができます
REQ 5: It shall be possible for a user to revoke permissions at any time.
REQ 5：ユーザーが任意の時点で許可を取り消すことができなければなりません。
REQ 6: It shall not be required for a user or user agent to store information in order to be able to revoke permissions that were previously granted for a relay resource.
REQ 6：これは、以前に中継リソースのために付与された権限を取り消すことができるようにするために情報を格納するユーザやユーザエージェントのために必要とされるものではありません。
REQ 7: The solution shall work in an inter-domain context, without requiring preestablished relationships between domains.
REQ 7：溶液は、ドメイン間の予め設定された関係を必要とせず、ドメイン間のコンテキストで動作しなければなりません。
REQ 8: The solution shall work for all current and future SIP methods.
REQ 8：ソリューションは、現在および将来のすべてのSIPメソッドのために働くものとします。
REQ 9: The solution shall be applicable to forking proxies.
REQ 9：ソリューションは、プロキシをフォークに適用しなければなりません。
REQ 10: The solution shall be applicable to URI-list services, such as resource list servers [5], MESSAGE URI-list services [7], and conference servers performing dial-out functions [8].
REQ 10：ソリューションは、リソースリストサーバなどのURIリストサービス、[5]、MESSAGE URI - リストサービスに適用されるもの[7]、およびダイヤルアウト機能を実行する会議サーバ[8]。
REQ 11: In SIP, URI-lists can be stored on the URI-list server or provided in a SIP request. The consent framework must work in both cases.
REQ 11：SIPでは、URI-リストは、URIリストサーバ上に格納することができるか、またはSIPリクエストにおいて提供します。同意フレームワークは、両方のケースで働かなければなりません。
REQ 12: The solution shall allow anonymous communications, as long as the recipient is willing to accept anonymous communications.
REQ 12：受信者が匿名通信を受け入れることを望んでいるように、溶液がいる限り、匿名の通信を許可するものとします。
REQ 13: If the recipient of a request wishes to be anonymous with respect to the original sender, it must be possible for the recipient to grant permission for the sender without the original sender learning the recipient's identity.
REQ 13：要求の受信者が元の送信者に関して匿名を希望する場合は、受信者が受信者の身元を学習せずに元の送信者、送信者の権限を付与するために、それが可能でなければなりません。
REQ 14: The solution shall prevent attacks that seek to undermine the underlying goal of consent. That is, it should not be possible to "fool" the system into delivering a request for which permission was not, in fact, granted.
REQ 14：ソリューションは同意の根本的な目標を弱体化しようと攻撃を防止しなければなりません。それは実際には、許可されなかった許可の要求を提供するにシステムを「だます」することはできないはずです。
REQ 15: The solution shall not require the recipient of the communications to be connected to the network at the time communications are attempted.
REQ 15：ソリューションは、通信を行おうとしている時にネットワークに接続するための通信の受信者を必要としないものとします。
REQ 16: The solution shall not require the sender of a SIP request to be connected at the time that a recipient provides permission.
REQ 16：ソリューションは、受信者が権限を提供して一度に接続するSIPリクエストの送信者を必要としないものとします。
REQ 17: The solution should scale to Internet-wide deployment.
REQ 17：ソリューションは、インターネット全体の展開に拡張する必要があります。
Security has been discussed throughout this document.
セキュリティは、この文書全体で議論されています。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[2]ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）：SIPサーバの検索"、RFC 3263、2002年6月。
[3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[3]キャンベル、B.、ローゼンバーグ、J.、Schulzrinneと、H.、のHuitema、C.、およびD. Gurle、 "インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張子"、RFC 3428、2002年12月。
[4] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[4]ローチ、A.B.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[5] Camarillo, G. and A.B. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services", Work in Progress, January 2006.
[5]キャマリロ、G.およびA.B. 、進捗状況、2006年1月に仕事ローチ、「セッション開始プロトコル（SIP）URI（Uniform Resource Identifier）で - リストサービスのためのフレームワークおよびセキュリティに関する注意事項」。
[6] Roach, A.B., Rosenberg, J., and B. Campbell, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", Work in Progress, January 2005.
[6]ローチ、A.B.、ローゼンバーグ、J.、およびB.キャンベル、 "リソースリストのAのセッション開始プロトコル（SIP）イベント通知拡張"、進歩、2005年1月に働いています。
[7] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)", Work in Progress, February 2006.
[7]ガルシア・マーチン、M.およびG.カマリロは、進歩、2006年2月にワーク「複数受信者MESSAGEは、セッション開始プロトコル（SIP）に要求します」。
[8] Camarillo, G. and A. Johnston, "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", Work in Progress, February 2006.
[8]カマリロ、G.とA.ジョンストン、「会議の設立をセッション開始プロトコル（SIP）に要求-含まれるリストの使用」、進歩、2006年2月に作業。
[9] Rosenberg, J., "The Session Initiation Protocol (SIP) and Spam", Work in Progress, July 2005.
進歩、2005年7月[10]ローゼンバーグ、J.、「セッション開始プロトコル（SIP）およびスパム」、ワーク。
Authors' Addresses
著者のアドレス
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサン・ローゼンバーグシスコシステムズ600 Lanidexプラザパーシッパニー、NJ 07054米国
Phone: +1 973 952-5000 EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
電話：+1 973 952-5000 Eメール：jdrosen@cisco.com URI：http://www.jdrosen.net
Gonzalo Camarillo (Editor) Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロ（編集）エリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Dean Willis Cisco Systems 2200 E. Pres. George Bush Turnpike Richardson, TX 75082 USA
ディーンウィリスシスコシステムズ2200のE.プレ。ジョージ・ブッシュターンパイクリチャードソン、TX 75082 USA
EMail: dean.willis@softarmor.com
メールアドレス：dean.willis@softarmor.com
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）によって提供されます。