[要約] RFC 5115は、Telephony Routing over IP（TRIP）リソース優先度のための属性に関するものであり、TRIPプロトコルで使用されるリソース優先度属性の定義と使用方法を提供しています。目的は、IPベースの通信ネットワークでのリソース優先度の管理と制御を向上させることです。
Network Working Group K. Carlberg
Request for Comments: 5115 G11
Category: Standards Track P. O'Hanlon
UCL
January 2008
Telephony Routing over IP (TRIP) Attribute for Resource Priority
リソースの優先度のためのIP（TRIP）属性を介したテレフォニールーティング
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document defines a new attribute for the Telephony Routing over IP (TRIP) protocol. The attribute associates protocols/services in the PSTN offering authorized prioritization during call setup that are reachable through a TRIP gateway. Current examples of preferential service in the Public Switched Telephone Network (PSTN) are Government Emergency Telecommunications Service (GETS) in the U.S. and Government Telephone Preference Scheme (GTPS) in the U.K. The proposed attribute for TRIP is based on the NameSpace.Value tuple defined for the SIP Resource-Priority field.
このドキュメントは、IP（TRIP）プロトコルを介したテレフォニールーティングの新しい属性を定義します。PSTNの属性アソシエイツプロトコル/サービスは、旅行ゲートウェイを通じて到達可能なコールセットアップ中に許可された優先順位付けを提供します。公共の切り替え電話網（PSTN）での優先サービスの現在の例は、米国の政府の緊急通信サービス（GET）です。英国の政府電話選好スキーム（GTPS）。SIPリソース優先フィールドの場合。
An IP telephony gateway allows nodes on an IP-based network to communicate with other entities on the circuit switched telephone network. The Telephony Routing over IP (TRIP) protocol [rfc3219] provides a way for nodes on the IP network to locate a suitable gateway through the use of Location Servers. TRIP is a policy-driven, inter-administrative domain protocol for advertising the reachability, negotiating the capabilities, and specifying the attributes of these gateways.
IPテレフォニーゲートウェイにより、IPベースのネットワーク上のノードが、回路スイッチ付き電話ネットワーク上の他のエンティティと通信できます。IP（TRIP）プロトコル[RFC3219]を介したテレフォニールーティングは、IPネットワーク上のノードがロケーションサーバーの使用を介して適切なゲートウェイを見つける方法を提供します。Tripは、到達可能性を宣伝し、機能を交渉し、これらのゲートウェイの属性を指定するためのポリシー主導型の管理間ドメインプロトコルです。
The TRIP protocol is modeled after BGP-4 [rfc4271] and uses path-vector advertisements distributed in a hop-by-hop manner (resembling a Bellman-Ford routing algorithm) via Location Servers. These Location Servers are grouped in administrative clusters known as Internet Telephony Administrative Domains (ITADs). A more extensive framework discussion on TRIP can be found in [rfc2871].
トリッププロトコルは、BGP-4 [RFC4271]の後にモデル化され、ロケーションサーバーを介してホップバイホップ方法（Bellman-Fordルーティングアルゴリズムに似た）で配布されるパスベクトル広告を使用します。これらのロケーションサーバーは、インターネットテレフォニー管理ドメイン（ITAD）として知られる管理クラスターにグループ化されています。旅行に関するより広範なフレームワークの議論は[RFC2871]にあります。
This document defines a new attribute that has been registered with IANA. The purpose of this new attribute, and the rationale behind its specification, is explained in the following sections.
このドキュメントは、IANAに登録された新しい属性を定義します。この新しい属性の目的、およびその仕様の背後にある理論的根拠は、次のセクションで説明されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [rfc2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
Emergency Telecommunications Service is a broad term that refers to the services provided by systems used to support emergency communications. One example of these systems is the U.S. Government Emergency Telecommunications Service (GETS). This system currently operates over the U.S. Public Switched Telephone Network (PSTN) as a pay-per-use system by authorized personnel. It uses the T1.631-1993 ANSI standard [ANSI] to signal the presence of the National Security / Emergency Preparedness (NS/EP) codepoint in an ISDN User Part (ISUP) Initial Address Message (IAM) for Signaling System No. 7 (SS7). A key aspect of GETS is that a signaling standard in the U.S. PSTN is used to convey the activation/request of the GETS service.
緊急通信サービスは、緊急通信をサポートするために使用されるシステムが提供するサービスを指す広範な用語です。これらのシステムの1つの例は、米国政府の緊急通信サービス（GETS）です。このシステムは現在、米国の公共交換電話網（PSTN）を介して、認定担当者によるペイパーユーザーシステムとして動作しています。T1.631-1993 ANSI標準[ANSI]を使用して、ISDNユーザーパーツ（NS / EP）の国家安全保障 /緊急時対応の存在（NS / EP）コードポイント（ISDNユーザーパーツ（ISUP）の初期住所メッセージ（IAM）のシグナリングシステム番号7（SS7）。GetSの重要な側面は、米国のPSTNのシグナル基準が、GetSサービスのアクティベーション/リクエストを伝えるために使用されることです。
From a protocol perspective, other examples of priority (and which can be argued as emergency/disaster related) standards are the H.460.4 ITU [itu460] standard on Call Priority designation for H.323 calls, and the I.255.3 [itu255] ITU standard on Multi-Level Precedence and Preemption Service. The latter has been integrated into private telephony systems like AUTOVON. In both cases, signaling codepoints exist to distinguish telephony calls by authenticated and prioritized end-user from the normal end-user. The form of this distinction varies and is outside the scope of this document. [rfc3689] and [rfc3690] provide additional information on ETS and its requirements.
プロトコルの観点から、優先度の他の例（および緊急/災害関連と議論することができる）の基準は、H.323コールのコール優先度指定に関するH.460.4 ITU [ITU460]標準、およびI.255.3 [ITU255]です。マルチレベルの優先順位と先制サービスに関するITU標準。後者は、Autovonのようなプライベートテレフォニーシステムに統合されています。どちらの場合も、信頼性の高いエンドユーザーから認証され、優先順位付けされたエンドユーザーによってテレフォニーコールを区別するためのシグナリングコードポイントが存在します。この区別の形式はさまざまであり、このドキュメントの範囲外です。[RFC3689]および[RFC3690]は、ETSとその要件に関する追加情報を提供します。
The initial discussions in the IEPREP working group list, along with the presentation at the Adelaide IETF [ADEL00], led to strawman requirements to augment SIP to have the ability to prioritize call signaling. This effort was then advanced formally in the SIPPING working group so that SIP would be able to prioritize access to circuit-switched networks, end systems, and proxy resources for emergency preparedness communication [rfc3487].
IEPREPワーキンググループリストでの最初の議論は、Adelaide IETF [Adel00]でのプレゼンテーションとともに、SIPを増やしてコールシグナリングを優先順位付けする能力を持つためにStrawmanの要件をもたらしました。その後、この取り組みは、SIPが緊急時対応コミュニケーションのためのサーキットスイッチネットワーク、エンドシステム、およびプロキシリソースへのアクセスを優先することができるように、すすり飲みワーキンググループで正式に進歩しました[RFC3487]。
The requirements in [rfc3487] produced the corresponding document [rfc4412] in the SIP working group, which defines a new header for SIP called Resource-Priority. This new header, which is optional, is divided into two parts: a NameSpace and a Value. The NameSpace part uniquely identifies a group of one or more priorities. The Value part identifies one of a set of priorities used for a SIP message.
[RFC3487]の要件は、SIPワーキンググループに対応するドキュメント[RFC4412]を作成しました。これは、リソース優先性と呼ばれるSIPの新しいヘッダーを定義します。オプションのこの新しいヘッダーは、名前空間と値の2つの部分に分割されます。名前空間部分は、1つ以上の優先順位のグループを一意に識別します。値部分は、SIPメッセージに使用される優先順位のセットの1つを識別します。
There are three basic benefits derived from the addition of the Resource Priority header in SIP. The first is an ability to signal the priority within a SIP message to other entities in an IP network. The caveat is that some entities may not recognize/support the priority or namespace, but at least the ability to signal the priority with respect to resources has been specified in the SIP protocol.
SIPにリソース優先ヘッダーの追加から導き出された3つの基本的な利点があります。1つ目は、IPネットワーク内の他のエンティティにSIPメッセージ内の優先度を合図する機能です。警告は、一部のエンティティが優先順位または名前空間を認識/サポートしない場合がありますが、少なくともリソースに関する優先度をシグナル化する能力がSIPプロトコルで指定されています。
The second benefit is that telephony-related protocol/codepoints from other standards can have a corresponding mapping to SIP NameSpace and Value tokens in the Resource-Priority header. Hence, the current NS/EP codepoint in ANSI standard T1.631-1993 could have a corresponding NameSpace.Value token set for the IETF standards body. And as a result, this mapping would facilitate the transparent bridging of signals (i.e., codepoints) between standards defined by various organizations -- be they private or public.
2番目の利点は、他の標準からのテレフォニー関連のプロトコル/コードポイントが、リソース優先ヘッダーのSIPネームスペースと値トークンに対応するマッピングを持つことができることです。したがって、ANSI標準のT1.631-1993の現在のNS/EPコードポイントには、IETF標準本体に対応する名前空間が設定されている可能性があります。その結果、このマッピングは、さまざまな組織によって定義された標準間の信号の透明な架橋（つまり、コードポイント）を促進します。
The third benefit of the Resource-Priority header, and its definition of alphanumeric tokens, is that it is highly versatile. The NameSpace allows for a wide set of priorities to be defined and updated, if the need arises, by simply defining a new NameSpace token. Hence, there is no reliance on a single set of priorities applied for all cases.
リソース優先ヘッダーの3番目の利点、および英数字トークンの定義は、非常に用途が広いことです。名前空間では、新しい名前空間トークンを定義するだけで、必要に応じて、幅広い優先順位を定義および更新できます。したがって、すべてのケースに適用される単一の優先順位セットに依存していません。
Having defined a means of signaling priority through gateways, the follow-on question arises of how does one determine which gateways support a given NameSpace. The dissemination of this type of information is within the scope of TRIP. However, the current specification of TRIP does not include a component that advertises associations of gateways with specific NameSpaces. To address this omission, the following section defines a new TRIP attribute that associates one or more NameSpaces with a gateway.
ゲートウェイを介して優先度を合図する手段を定義したため、どのゲートウェイが特定の名前空間をサポートするかをどのように決定するかについての次の疑問が生じます。このタイプの情報の普及は、旅行の範囲内です。ただし、トリップの現在の仕様には、ゲートウェイの関連付けを特定の名前空間と宣伝するコンポーネントは含まれていません。この省略に対処するために、次のセクションでは、1つ以上の名前空間をゲートウェイに関連付ける新しいトリップ属性を定義します。
This section provides details on the syntax and semantics of the ResourcePriority TRIP attribute. Its presentation reflects the form of existing attributes presented in Section 5 of [rfc3219].
このセクションでは、ResourcePriority Trip属性の構文とセマンティクスの詳細を説明します。そのプレゼンテーションは、[RFC3219]のセクション5に示されている既存の属性の形式を反映しています。
Attribute Flags are set to the following:
属性フラグは次のように設定されています。
Conditional Mandatory: False Required Flags: Not Well-Known, Independent Transitive Potential Flags: None TRIP Type Code: 12
条件付き必須：虚偽の必須フラグ：よく知られていない、独立した推移的潜在フラグ：なしトリップタイプコード：12
There are no dependencies on other attributes, thus Conditional Mandatory is set to "False".
他の属性に依存関係はありません。したがって、条件付き必須は「false」に設定されます。
Since the Resource-Priority field in SIP, with its corresponding NameSpace token, is optional, the ResourcePriority attribute in TRIP is also optional. Hence, it is set to "Not Well-Known".
SIPのリソース優先度フィールドは、対応する名前空間トークンを備えたものであるため、トリップのリソースプリアリティ属性もオプションです。したがって、「よく知られていない」ように設定されています。
The Independent Transitive condition indicates that the attribute is to be forwarded amongst all ITADs. The Location Server that does not recognize the attribute sets the Partial flag as well.
独立した推移的条件は、属性がすべてのITADの間で転送されることを示しています。属性を認識しないロケーションサーバーも部分フラグを設定します。
The ResourcePriority attribute contains one or more NameSpace token identifiers. An initial set of identifiers is defined in [rfc4412], with subsequent identifiers to be found in the IANA registry. The syntax of the ResourcePriority attribute is copied from the "namespace" token syntax from [rfc4412], which in turn imported "alphanum" from [rfc3261], and is an alphanumeric value as shown below:
ResourcePriority属性には、1つ以上の名前空間トークン識別子が含まれています。識別子の初期セットは[RFC4412]で定義されており、その後の識別子はIANAレジストリにあります。ResourcePriority属性の構文は、[RFC4412]の「名前空間」トークン構文からコピーされ、[RFC3261]から「アルファナム」をインポートし、以下に示すように英数字値です。
namespace = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+"
/ "`" / "'" / "~" )
Note that an augmented version of Backus-Naur Form is found in [rfc4234].
Backus-Naur形式の拡張バージョンは[RFC4234]に記載されていることに注意してください。
Since NameSpaces are arbitrary in length, each tuple consists of a Length value with a NameSpace value as shown in the figure below. There is no padding between tuples.
名前空間の長さは任意であるため、各タプルは、下の図に示すように、名前空間値の長さの値で構成されています。タプルの間にパディングはありません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| NameSpace Length | NameSpace Value (variable) |
+---------------+---------------+--------------+----------------+
It is important to note that the priority (i.e., "r-priority" token syntax) from [rfc4412] is NOT used in the ResourcePriority attribute. This is because the objective of the attribute is to advertise the NameSpace associated with a gateway and not the individual priorities within that NameSpace.
[RFC4412]の優先度（つまり、「R-Priority」トークン構文）は、ResourcePriolity属性では使用されていないことに注意することが重要です。これは、属性の目的は、その名前空間内の個々の優先順位ではなく、ゲートウェイに関連付けられた名前空間を宣伝することであるためです。
Section 5.12 of TRIP lists a number of considerations that should be addressed when defining new attributes. The first three considerations (use of the attribute, its flags, and syntax) have been discussed above in this section. The final three considerations are the following.
旅行のセクション5.12には、新しい属性を定義する際に対処すべき多くの考慮事項がリストされています。このセクションでは、最初の3つの考慮事項（属性、そのフラグ、および構文の使用）について上記で説明しています。最後の3つの考慮事項は次のとおりです。
The ResourcePriority attribute is not well-known. If a route has a ResourcePriority attribute associated with it, the Location Server (LS) MUST include that attribute in the advertisement it originates.
ResourcePriolity属性はよく知られていません。ルートにResourcePriority属性が関連付けられている場合、ロケーションサーバー（LS）には、その属性が発生する広告にその属性を含める必要があります。
Routes with differing ResourcePriority token values MUST NOT be aggregated. Routes with the same token values in the ResourcePriority attribute MAY be aggregated and the same ResourcePriority attribute attached to the aggregated object.
リソースプリアリティトークン値が異なるルートは、集約してはなりません。ResourcePriolity属性に同じトークン値を持つルートは、集約され、集約されたオブジェクトに接続された同じResourcePriolity属性を集計することができます。
An LS MUST include the ResourcePriority attribute when communicating with peer LSs within its own domain.
LSは、独自のドメイン内でピアLSSと通信する際に、ResourcePriolity属性を含める必要があります。
If received from a peer LS in another domain, an LS MUST propagate the ResourcePriority attribute to other LSs within its domain.
別のドメインのピアLSから受信した場合、LSはそのドメイン内の他のLSSにリソースプリアリティ属性を伝播する必要があります。
An LS MAY add the ResourcePriority attribute when propagating routing objects to an LS in another domain. The inclusion of the ResourcePriority attribute is a matter of local administrative policy.
LSは、ルーティングオブジェクトを別のドメイン内のLSに伝播するときに、ResourcePriority属性を追加する場合があります。ResourcePriolity属性を含めることは、現地の管理ポリシーの問題です。
The document defines a new attribute for the TRIP protocol and has no direct security considerations applied to it. However, the security considerations for TRIP and its messages remain the same and are articulated in Section 14 of [rfc3219].
このドキュメントは、旅行プロトコルの新しい属性を定義しており、それに適用される直接的なセキュリティ上の考慮事項はありません。ただし、旅行とそのメッセージに関するセキュリティ上の考慮事項は同じままであり、[RFC3219]のセクション14で明確にされています。
As described in Section 4 above, one new "TRIP attribute" has been defined. Its name and code value are the following:
上記のセクション4で説明したように、1つの新しい「トリップ属性」が定義されています。その名前とコード値は次のとおりです。
Code Attribute Name
---- ----------------
12 ResourcePriority
These assignments are recorded in the following registry: http://www.iana.org/assignments/trip-parameters
これらの割り当ては、次のレジストリに記録されています：http：//www.iana.org/assignments/trip-parameters
The authors appreciate review and subsequent comments from James Polk and Henning Schulzrinne.
著者は、ジェームズ・ポークとヘニング・シュルツリンからのレビューとその後のコメントに感謝しています。
[rfc3219] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing over IP (TRIP)", RFC 3219, January 2002.
[RFC3219] Rosenberg、J.、Salama、H。、およびM. Squire、「Thelephony Routing over IP（Trip）」、RFC 3219、2002年1月。
[rfc4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.
[RFC4412] Schulzrinne、H。およびJ. Polk、「セッション開始プロトコル（SIP）の通信リソースの優先順位」、RFC 4412、2006年2月。
[ADEL00] IETF Proceedings (47th), SIP Working Group, Adelaide, Australia, June 2000.
[ADEL00] IETF Proceedings（47th）、SIPワーキンググループ、アデレード、オーストラリア、2000年6月。
[ANSI] ANSI, "Signaling System No. 7 (SS7): High Probability of Completion (HPC) Network Capability", ANSI T1.631, 1993.
[ANSI] ANSI、「シグナリングシステムNo. 7（SS7）：完了の高い確率（HPC）ネットワーク機能」、ANSI T1.631、1993。
[itu460] ITU, "Call Priority Designation for H.323 Calls", ITU Recommendation H.460.4, November 2002.
[ITU460] ITU、「H.323コールのコール優先度指定」、ITU推奨H.460.4、2002年11月。
[itu255] ITU, "Multi-Level Precedence and Preemption Service", ITU Recommendation I.255.3, July 1990.
[ITU255] ITU、「マルチレベルの優先順位と先制サービス」、ITU推奨I.255.3、1990年7月。
[rfc2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[rfc2871] Rosenberg, J. and H. Schulzrinne, "A Framework for Telephony Routing over IP", RFC 2871, June 2000.
[RFC2871] Rosenberg、J。およびH. Schulzrinne、「IP上のテレフォニールーティングのフレームワーク」、RFC 2871、2000年6月。
[rfc3261] 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.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[rfc3487] Schulzrinne, H., "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487, February 2003.
[RFC3487] Schulzrinne、H。、「セッション開始プロトコル（SIP）のリソース優先メカニズムの要件」、RFC 3487、2003年2月。
[rfc3689] Carlberg, K. and R. Atkinson, "General Requirements for Emergency Telecommunication Service (ETS)", RFC 3689, February 2004.
[RFC3689] Carlberg、K。およびR. Atkinson、「緊急通信サービス（ETS）の一般的な要件」、RFC 3689、2004年2月。
[rfc3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements for Emergency Telecommunications Service (ETS)", RFC 3690, February 2004.
[RFC3690] Carlberg、K。およびR. Atkinson、「緊急通信サービス（ETS）のIPテレフォニー要件」、RFC 3690、2004年2月。
[rfc4234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[rfc4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
Authors' Addresses
著者のアドレス
Ken Carlberg G11 123a Versailles Circle Baltimore, MD USA
Ken Carlberg G11 123a Versailles Circle Baltimore、MD USA
EMail: carlberg@g11.org.uk
Piers O'Hanlon University College London Gower Street London UK
Piers O'Hanlon University College London Gower Street London UK
EMail: p.ohanlon@cs.ucl.ac.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
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への情報をお問い合わせください。