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
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提供中のサービスがTRIPゲートウェイ経由で到達可能でコールセットアップ中に優先順位付けを許可関連付けます。公共での優遇サービスの現在の例は、電話網（PSTN）はTRIPのための提案属性が定義されてNameSpace.Valueタプルに基づいており、英国では米国の政府の緊急通信サービス（GETS）と政府電話優先スキーム（GTPS）されているスイッチSIPリソース-Priorityフィールドのため。
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].
TRIPプロトコルは、BGP-4 [RFC4271]をモデルとロケーションサーバを介して（ベルマン・フォード・ルーティング・アルゴリズムに似ている）ホップバイホップに分布パスベクトル広告を使用しています。これらのロケーションサーバは、インターネットテレフォニー管理ドメイン（ITADs）として知られている行政のクラスタにグループ化されています。 TRIP上のより広範な枠組みの議論は[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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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.
緊急通信サービスは、緊急時の通信をサポートするために使用されるシステムが提供するサービスを指し、広義の用語です。これらのシステムの一例は、米国政府の緊急通信サービス（GETS）です。このシステムは、現在、米国公開が許可された担当者が従量課金システムとして交換電話網（PSTN）で動作します。これは、信号システム第7号のためのISDNユーザ部（ISUP）初期アドレスメッセージ（IAM）に国家安全保障/災害対策（NS / EP）コードポイントの存在を知らせるためにT1.631-1993 ANSI標準[ANSI]を使用しています（SS7）。 GETSの重要な側面は、米国PSTNにおけるシグナリング標準取得サービスのアクティベーション/要求を伝えるために使用されることです。
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.
プロトコルの観点から、優先度の他の例（及びその関連の緊急事態/災害のように主張することができる）規格は、[itu255] H.323のコールのコール優先度指定にH.460.4 ITU [itu460]標準、およびI.255.3ありますマルチレベル優先順位および優先処理サービス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ワーキンググループリストの最初の議論は、アデレードIETF [ADEL00]でプレゼンテーションとともに、コールシグナリングの優先順位を決定する能力を有することSIPを強化するためにstrawman要件につながりました。 SIPは、防災通信[rfc3487]用の回路交換ネットワーク、エンドシステム、およびプロキシリソースへのアクセスの優先順位を設定することが可能であろうように、この取り組みは、その後SIPPINGワーキンググループで正式に進めました。
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のために新しいヘッダを定義SIPワーキンググループ、に対応する文書[rfc4412]を生成しました。名前空間と値：オプションであるこの新しいヘッダは、2つの部分に分割されます。ネームスペースの一部を一意に一つまたはそれ以上の優先順位のグループを識別する。値部分は、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におけるリソースプライオリティヘッダーの追加由来三つの基本的な利点があります。最初は、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標準化団体のための対応NameSpace.Valueトークンセットを持つことができます。結果として、このマッピングは、さまざまな組織によって定義された標準との間の信号のトランスペアレントブリッジング（すなわち、コードポイント）を促進するであろう - 彼らはプライベートまたはパブリックにします。
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.
第三の資源優先度ヘッダの利点、および英数字トークンのその定義は、それが非常に汎用性であることです。必要が生じた場合は名前空間には、単に新しい名前空間のトークンを定義することによって、定義され、更新される優先順位の広いセットすることができます。したがって、すべての場合に適用される優先順位の単一のセットには信頼がありません。
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つが与えられた名前空間をサポートするゲートウェイを決定どのようで生じます。このタイプの情報の普及は、TRIPの範囲内です。しかし、TRIPの現在の仕様では、特定の名前空間とゲートウェイの関連付けをアドバタイズ成分を含みません。この漏れに対処するには、次のセクションでは、ゲートウェイを有する1つまたは複数の名前空間を関連付ける新しいTRIP属性を定義します。
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
条件付き必須：偽必要なフラグ：よく知られていない、独立した推移潜在的なフラグ：なしTRIPタイプコード：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におけるResourcePriorityフィールドので、その対応する名前空間のトークンと、任意であり、TRIPにResourcePriority属性も任意です。したがって、「よく分からない」に設定されています。
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.
独立した推移条件は、属性がすべてITADsの間で転送されることを示しています。属性を認識しないロケーションサーバは、同様に部分的なフラグを設定します。
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属性は、一つ以上のネームスペーストークン識別子が含まれています。識別子の最初のセットは、IANAレジストリに発見される後続の識別子と、[rfc4412]で定義されています。 ResourcePriority属性の構文は[RFC3261]から「alphanum」順番にインポート[rfc4412]から「名前空間」トークン構文、からコピーされ、そして以下に示すように英数字の値です。
namespace = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" )
= 1 *名前空間（alphanum / " - " / / "％" / "*" / "_" / "+" / "`"/ "'"/ "〜" "！"）
Note that an augmented version of Backus-Naur Form is found in [rfc4234].
バッカスナウア記法の拡張バージョンは、[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-優先」トークン構文が）ResourcePriority属性で使用されていないことに注意することが重要です。属性の目的は、その名前空間内のゲートウェイではなく、個々の優先順位に関連付けられた名前空間を宣伝することだからです。
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.
TRIPの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.
ResourcePriority属性は、よく知られていません。ルートは、それに関連付けられた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.
ResourcePriorityトークン値が異なるルートは集約されてはなりません。 ResourcePriority属性に同じトークン値を持つルートが集約されてもよく、同じResourcePriority属性が集約オブジェクトに取り付けられました。
An LS MUST include the ResourcePriority attribute when communicating with peer LSs within its own domain.
独自のドメイン内のピアのLSとの通信時LSはResourcePriority属性を含まなければなりません。
If received from a peer LS in another domain, an LS MUST propagate the ResourcePriority attribute to other LSs within its domain.
別のドメイン内のピアLSから受信した場合、LSは、そのドメイン内の他のLSにResourcePriority属性を伝播する必要があります。
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属性を追加するかもしれません。 ResourcePriority属性を含めることは、ローカル管理ポリシーの問題です。
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].
文書には、TRIPプロトコルのための新しい属性を定義し、それに適用されるには直接のセキュリティ上の考慮事項を持っていません。しかし、TRIPとそのメッセージのセキュリティの考慮事項は同じままで、[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新しい「TRIP属性が」定義されています。その名前とコードの値は次のとおりです。
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.
著者は、レビューとジェームズ・ポークとヘニングSchulzrinneとから、その後のコメントを感謝しています。
[rfc3219] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing over IP (TRIP)", RFC 3219, January 2002.
"オーバーIPテレフォニールーティング（TRIP）" [rfc3219]ローゼンバーグ、J.、サラマ、H.、およびM.スクワイア、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.ポーク、 "セッション開始プロトコル（SIP）のための通信リソースプライオリティ"、RFC 4412、2006年2月。
[ADEL00] IETF Proceedings (47th), SIP Working Group, Adelaide, Australia, June 2000.
[ADEL00] IETF議事録（第47回）、SIPワーキンググループ、アデレード、オーストラリア、2000年6月。
[ANSI] ANSI, "Signaling System No. 7 (SS7): High Probability of Completion (HPC) Network Capability", ANSI T1.631, 1993.
[ANSI] ANSI、 "信号システム第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は、ITU勧告H.460.4、2002年11月、 "H.323のための呼優先度指定がコール"。
[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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[rfc2871] Rosenberg, J. and H. Schulzrinne, "A Framework for Telephony Routing over IP", RFC 2871, June 2000.
[rfc2871]ローゼンバーグ、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、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.、RFC 3487 "セッション開始プロトコル（SIP）のためのリソースプライオリティメカニズムのための要件"、2003年2月。
[rfc3689] Carlberg, K. and R. Atkinson, "General Requirements for Emergency Telecommunication Service (ETS)", RFC 3689, February 2004.
[rfc3689]カールバーグ氏、K.とR.アトキンソン、 "緊急通信サービスの一般的な要件（ETS）"、RFC 3689、2004年2月。
[rfc3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements for Emergency Telecommunications Service (ETS)", RFC 3690, February 2004.
[rfc3690]カールバーグ氏、K.とR.アトキンソン、 "緊急通信サービス（ETS）のためのIPテレフォニーの要件"、RFC 3690、2004年2月。
[rfc4234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
"構文仕様のための増大しているBNF：ABNF" [RFC4234]クロッカー、D.、エド、およびP. Overell、。、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.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
Authors' Addresses
著者のアドレス
Ken Carlberg G11 123a Versailles Circle Baltimore, MD USA
ケン・カールバーグG11 123Aベルサイユサークルボルチモア、MD USA
EMail: carlberg@g11.org.uk
メールアドレス：carlberg@g11.org.uk
Piers O'Hanlon University College London Gower Street London UK
埠頭オハンロンロンドン大学ガウアーストリートロンドン、英国
EMail: p.ohanlon@cs.ucl.ac.uk
メールアドレス：p.ohanlon@cs.ucl.ac.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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に情報を記述してください。