Network Working Group L. Martini
Request for Comments: 4446 Cisco Systems Inc.
BCP: 116 April 2006
Category: Best Current Practice
IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)
Status of This Memo
このメモのステータス
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document allocates the fixed pseudowire identifier and other fixed protocol values for protocols that have been defined in the Pseudo Wire Edge to Edge (PWE3) working group. Detailed IANA allocation instructions are also included in this document.
この文書は、固定された疑似回線識別子及びEdgeに疑似ワイヤエッジで定義されているプロトコルの他の固定プロトコル値（PWE3）ワーキンググループを割り当てます。詳細IANA割り当て命令も、この文書に含まれています。
Table of Contents
目次
1. Introduction ....................................................2
2. Specification of Requirements ...................................2
3. IANA Considerations .............................................2
3.1. Expert Review Directives ...................................2
3.2. MPLS Pseudowire Type .......................................3
3.3. Interface Parameters Sub-TLV Type ..........................4
3.4. Attachment Identifiers .....................................5
3.4.1. Attachment Individual Identifier Type ...............5
3.4.2. Attachment Group Identifier (AGI) Type ..............5
3.5. Pseudowire Status ..........................................6
3.6. PW Associated Channel Type .................................6
4. Security Considerations .........................................7
5. References ......................................................7
5.1. Normative References .......................................7
5.2. Informative References .....................................7
Most of the new IANA registries and respective IANA-allocation processes for protocols defined in the PWE3 IETF working group can be found in this document. The IANA registries defined here are in general subdivided into three main ranges: a range to be allocated by IETF consensus according to [RFC2434], a range to be allocated by the expert review process according to [RFC2434], and a range to be allocated on a first come, first served basis that is reserved for vendor proprietary allocations. Note that vendor proprietary types MUST NOT be registered for IETF standards or extensions thereof, whether they are still in development or already completed.
PWE3 IETFワーキンググループで定義されたプロトコルのための新しいIANAレジストリとそれぞれのIANA割り当て方法のほとんどは、この文書に記載されています。 [RFC2434]、[RFC2434]に記載のエキスパートレビュープロセスによって割り当てられる範囲、および割り当てられる範囲に従ってIETFコンセンサスによって割り当てられる範囲：ここで定義されたIANAレジストリは、一般的には三つの主要な範囲に分割されます来る第一に、最初のベンダー独自の配分のために予約されている基礎を務めました。ベンダー独自仕様のタイプは、彼らはまだ開発中であるか、すでに完了したかどうか、そのIETF標準または拡張のために登録されてはならないことに注意してください。
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]に記載されているように解釈されます。
IANA has created several registries as described in the following paragraphs. Each of these registries contains numeric values used to identify data types. In each of these registries, the value of 0 is reserved and MUST not be used.
次の段落で説明するようにIANAには、いくつかのレジストリを作成しました。これらのレジストリのそれぞれには、データ型を識別するために使用される数値が含まれています。これらのレジストリのそれぞれにおいて、0の値は予約されており、使用してはなりません。
Throughout this document, allocation procedures for several registries call for an expert review process according to [RFC2434]. The expert should consider the following points:
このドキュメントでは、いくつかのレジストリの割り当て手順は[RFC2434]によると、専門家レビュー・プロセスのために呼び出します。専門家は、次の点を考慮する必要があります。
* Duplication of code point allocations should be avoided.
*コードポイントの割り当ての重複は避けるべきです。
* A brief, clear description of the code point allocation requested should be provided.
*要求されたコードポイントの割り当てを簡単に、明確な説明が提供されるべきです。
* The type allocation requested should be appropriate for the particular requested value range in the registry.
*要求されたタイプの割り当ては、レジストリ内の特定の要求された値の範囲に対して適切であるべきです。
The expert reviewing the request MUST approve or disapprove the request within 10 business days from when he or she received the expert review request.
リクエストを見直し、専門家は、彼または彼女は専門家の審査リクエストを受けてから10営業日以内にリクエストを承認または却下しなければなりません。
IANA has set up the registry of "MPLS Pseudowire Type". This type has 15-bit values. PW Type values 1 through 30 are specified in this document, and PW Type values 31 through 1024 are to be assigned by IANA, using the "Expert Review" policy defined in [RFC2434]. PW Type values 1025 through 4096 and 32767 are to be allocated using the IETF consensus policy defined in [RFC2434]. PW Type values 4097 through 32766 are reserved for vendor-proprietary extensions and are to be assigned by IANA, using the "First Come First Served" policy defined in [RFC2434]. A Pseudowire Type description is required for any assignment from this registry. Additionally, for the vendor-proprietary extensions range, a citation of a person or company name is also required. A document reference should also be provided.
IANAは、「MPLS擬似回線タイプ」のレジストリを設定しています。このタイプは、15ビット値を有しています。 PWタイプ30を介して1は、この文書で指定された値、およびPWタイプ1024を介して、31 [RFC2434]で定義された「エキスパートレビュー」ポリシーを使用して、IANAによって割り当てられる値。 PWタイプ値4096と32767 1025は[RFC2434]で定義されたIETFコンセンサスポリシーを使用して割り当てられなければなりません。 PWタイプ32766スルー4097は、ベンダ独自の拡張のために予約されており、[RFC2434]で定義されたポリシー「まず最初に配信是非」を用い、IANAによって割り当てられる値。疑似回線タイプの説明は、このレジストリから任意の割り当てのために必要とされます。また、ベンダー独自の拡張機能の範囲のために、個人または会社名の引用も必要です。ドキュメントの参照も提供されるべきです。
Initial Pseudowire Type value allocations are specified below:
初期の疑似回線タイプ値の割り当ては、以下に指定されています。
PW type Description Reference
===================================================================
0x0001 Frame Relay DLCI ( Martini Mode ) [FRAME]
0x0002 ATM AAL5 SDU VCC transport [ATM]
0x0003 ATM transparent cell transport [ATM]
0x0004 Ethernet Tagged Mode [ETH]
0x0005 Ethernet [ETH]
0x0006 HDLC [PPPHDLC]
0x0007 PPP [PPPHDLC]
0x0008 SONET/SDH Circuit Emulation Service Over MPLS [CEP]
0x0009 ATM n-to-one VCC cell transport [ATM]
0x000A ATM n-to-one VPC cell transport [ATM]
0x000B IP Layer2 Transport [RFC3032]
0x000C ATM one-to-one VCC Cell Mode [ATM]
0x000D ATM one-to-one VPC Cell Mode [ATM]
0x000E ATM AAL5 PDU VCC transport [ATM]
0x000F Frame-Relay Port mode [FRAME]
0x0010 SONET/SDH Circuit Emulation over Packet [CEP]
0x0011 Structure-agnostic E1 over Packet [SAToP]
0x0012 Structure-agnostic T1 (DS1) over Packet [SAToP]
0x0013 Structure-agnostic E3 over Packet [SAToP]
0x0014 Structure-agnostic T3 (DS3) over Packet [SAToP]
0x0015 CESoPSN basic mode [CESoPSN]
0x0016 TDMoIP AAL1 Mode [TDMoIP]
0x0017 CESoPSN TDM with CAS [CESoPSN]
0x0018 TDMoIP AAL2 Mode [TDMoIP]
0x0019 Frame Relay DLCI [FRAME]
IANA has to set up the registry of "Pseudowire Interface Parameter Sub-TLV types". This type has 8-bit values. Sub-TLV types 1 through 12 are specified in this document. Sub-TLV types 13 through 64 are to be assigned by IANA, using the "Expert Review" policy defined in [RFC2434]. Sub-TLV types 65 through 127 and 255 are to be allocated using the IETF consensus policy defined in [RFC2434]. Sub-TLV types values 128 through 254 are reserved for vendor-proprietary extensions and are to be assigned by IANA, using the "First Come First Served" policy defined in [RFC2434].
IANAは、「擬似回線インタフェースパラメータサブTLVタイプ」のレジストリを設定する必要があります。このタイプは、8ビット値を有しています。サブTLVのタイプ12を介して図1に示すように、この文書で指定されています。サブTLVのタイプ13〜64は、[RFC2434]で定義された「エキスパートレビュー」ポリシーを使用して、IANAによって割り当てられます。サブTLVのタイプ127および255を介して、65 [RFC2434]で定義されたIETFコンセンサスポリシーを使用して割り当てられなければなりません。サブTLVのタイプは、254を介して、128はベンダー独自の拡張のために予約されており、[RFC2434]で定義された「まず最初に配信是非」ポリシーを使用して、IANAによって割り当てられる値。
Any assignments requested from this registry require a description of up to 54 characters.
このレジストリから要求された任意の割り当ては最大54文字の説明を必要としています。
For each allocation, a length field MUST also be specified in one of the following formats:
各割り当てのために、長さフィールドは、以下のいずれかの形式で指定する必要があります。
- Text as follows:"up to X", where X is a decimal integer. - Up to 3 different decimal integers.
- テキストは次のとおりです。Xは10進整数である、「Xまで」。 - 3種類の進整数まで。
The text "up to X" means up to and including X.
「Xまでの」テキストがX.までを含む意味します
Additionally, for the vendor-proprietary extensions range, a citation of a person or company name is also required. A document reference should also be provided.
また、ベンダー独自の拡張機能の範囲のために、個人または会社名の引用も必要です。ドキュメントの参照も提供されるべきです。
Initial Pseudowire Interface Parameter Sub-TLV type allocations are specified below:
初期擬似回線インタフェースパラメータサブTLVのタイプの割り当ては以下に指定されています。
Parameter Length Description Reference
ID
========================================================================
0x01 4 Interface MTU in octets [CRTL]
0x02 4 Maximum Number of concatenated ATM cells [ATM]
0x03 up to 82 Optional Interface Description string [CRTL][RFC2277]
0x04 4 CEP/TDM Payload Bytes [CEP][TDMoIP]
0x05 4 CEP options [CEP]
0x06 4 Requested VLAN ID [ETH]
0x07 6 CEP/TDM bit-rate [CEP][TDMoIP]
0x08 4 Frame-Relay DLCI Length [FRAME]
0x09 4 Fragmentation indicator [FRAG]
0x0A 4 FCS retention indicator [FCS]
0x0B 4/8/12 TDM options [TDMoIP]
0x0C 4 VCCV parameter [VCCV]
Note that the Length field is defined as the length of the Sub-TLV, including the Sub-TLV type and length field itself.
サブTLVのタイプと長さフィールド自体を含む、Lengthフィールドは、サブTLVの長さとして定義されることに留意されたいです。
IANA has to set up the registry of "Attachment Individual Identifier (AII) Type". This type has 8-bit values. AII Type value 1 is defined in this document. AII Type values 2 through 64 are to be assigned by IANA, using the "Expert Review" policy defined in [RFC2434]. AII Type values 65 through 127 and 255 are to be allocated using the IETF consensus policy defined in [RFC2434]. AII types values 128 through 254 are reserved for vendor-proprietary extensions and are to be assigned by IANA, using the "First Come First Served" policy defined in [RFC2434].
IANAは、「添付ファイルの個別識別子タイプ（AII）」のレジストリを設定する必要があります。このタイプは、8ビット値を有しています。 AIIタイプ値1は、このドキュメントで定義されています。 AIIタイプ値2〜64は、[RFC2434]で定義された「エキスパートレビュー」ポリシーを使用して、IANAによって割り当てられます。 AIIタイプ127および255を介して65値[RFC2434]で定義されたIETFコンセンサスポリシーを使用して割り当てられなければなりません。 AIIタイプ254を介して、128はベンダー独自の拡張のために予約されており、[RFC2434]で定義された「まず最初に配信是非」ポリシーを使用して、IANAによって割り当てられる値。
Any assignments requested from this registry require a description of up to 54 characters.
このレジストリから要求された任意の割り当ては最大54文字の説明を必要としています。
For each allocation, a length field MUST also be specified as a decimal integer.
各割り当てのために、長さフィールドは、また、10進整数として指定されなければなりません。
Additionally, for the vendor-proprietary extensions range, a citation of a person or company name is also required. A document reference should also be provided.
また、ベンダー独自の拡張機能の範囲のために、個人または会社名の引用も必要です。ドキュメントの参照も提供されるべきです。
Initial Attachment Individual Identifier (AII) Type allocations are specified below:
初期アタッチメント個体識別子（AII）割り当てを型が下に指定されています。
AII Type Length Description Reference
=====================================================================
0x01 4 A 32 bit unsigned number local [SIG]
identifier.
IANA has to set up the registry of "Attachment Group Identifier (AGI) Type". This type has 8-bit values. AGI Type value 1 is defined in this document. AGI Type values 2 through 64 are to be assigned by IANA, using the "Expert Review" policy defined in [RFC2434]. AGI Type values 65 through 127 and 255 are to be allocated using the IETF consensus policy defined in [RFC2434]. AGI type values 128 through 254 are reserved for vendor-proprietary extensions and are to be assigned by IANA, using the "First Come First Served" policy defined in [RFC2434].
IANAは、「添付ファイルのグループ識別子（AGI）タイプ」のレジストリを設定する必要があります。このタイプは、8ビット値を有しています。 AGI Type値1は、このドキュメントで定義されています。 AGIタイプ値2〜64は、[RFC2434]で定義された「エキスパートレビュー」ポリシーを使用して、IANAによって割り当てられます。 AGIタイプ127および255を介して、65 [RFC2434]で定義されたIETFコンセンサスポリシーを使用して割り当てられる値です。 AGI型254を通る128はベンダー独自の拡張のために予約されており、[RFC2434]で定義された「まず最初に配信是非」ポリシーを使用して、IANAによって割り当てられる値。
Any assignments requested from this registry require a description of up to 54 characters.
このレジストリから要求された任意の割り当ては最大54文字の説明を必要としています。
For each allocation, a length field MUST also be specified as a decimal integer.
各割り当てのために、長さフィールドは、また、10進整数として指定されなければなりません。
Additionally, for the vendor-proprietary extensions range, a citation of a person or company name is also required. A document reference should also be provided.
また、ベンダー独自の拡張機能の範囲のために、個人または会社名の引用も必要です。ドキュメントの参照も提供されるべきです。
Initial Attachment Group Identifier (AGI) Type allocations are specified below:
初期アタッチメントグループ識別子（AGI）は、割り当ては以下に指定されている入力します。
AGI Type Length Description Reference
===================================================================
0x01 8 AGI encoded as Route Distinguisher [SIG]
IANA has to set up the registry of "Pseudowire Status Codes". These are bit strings of length 32. Status bits 0 through 4 are defined in this document. Status bits 5 through 31 are to be assigned by IANA using the "Expert Review" policy defined in [RFC2434].
IANAは、「疑似回線ステータスコード」のレジストリを設定する必要があります。これらは、0〜4は、本文書で定義されている長さ32のステータスビットのビット列です。ステータスビット5から31は[RFC2434]で定義された「エキスパートレビュー」ポリシーを使用してIANAによって割り当てられるべきです。
Any requests for allocation from this registry require a description of up to 65 characters.
このレジストリから配分のための任意の要求は、最大65文字の説明を必要としています。
Initial Pseudowire Status Code value allocations are as follows:
次のように初期の擬似回線のステータスコード値の割り当ては、次のとおりです。
Bit Mask Description
====================================================================
0x00000000 - Pseudowire forwarding (clear all failures) [CRTL]
0x00000001 - Pseudowire Not Forwarding [CRTL]
0x00000002 - Local Attachment Circuit (ingress) Receive Fault [CRTL]
0x00000004 - Local Attachment Circuit (egress) Transmit Fault [CRTL]
0x00000008 - Local PSN-facing PW (ingress) Receive Fault [CRTL]
0x00000010 - Local PSN-facing PW (egress) Transmit Fault [CRTL]
For the definition of the "PW Associated Channel Type" please refer to [RFC4385].
「PW関連するチャネルタイプ」の定義については、[RFC4385]を参照してください。
For the definition of the "PW Associated Channel Type", please refer to [RFC4385].
「PW関連するチャネルタイプ」の定義については、[RFC4385]を参照してください。
This document specifies only fixed identifiers, and not the protocols used to carry the encapsulated packets across the network. Each such protocol may have its own set of security issues, but those issues are not affected by the identifiers specified herein.
この文書では、固定の識別子ではなく、ネットワークを介してカプセル化されたパケットを運ぶために使用されるプロトコルを指定します。各そのようなプロトコルは、セキュリティ上の問題の独自のセットを持っている可能性がありますが、これらの問題は、ここで指定された識別子によって影響を受けません。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、 "文字セットと言語のIETF方針"、BCP 18、RFC 2277、1998年1月。
[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月。
[CRTL] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
、RFC 4447 [CRTL]マルティーニ、L.、エド。、ローゼン、E.、エルAawar、N.、スミス、T.、およびG.サギ、 "ラベル配布プロトコル（LDP）を使用して疑似回線の設定とメンテナンス" 、2006年4月。
[VCCV] Nadeau, T. and R. Aggarwal, "Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)", Work in Progress, August 2005.
[VCCV]ナドー、T.、およびR.アガルワル、 "疑似ワイヤー仮想回線接続性検証（VCCV）"、進歩、2005年8月の作業。
[FRAG] Malis, A. and M. Townsley, "PWE3 Fragmentation and Reassembly", Work in Progress, September 2005.
[FRAG] Malis、A.とM. Townsley、 "PWE3フラグメンテーションおよび再構成"、進歩、2005年9月での作業。
[FCS] Malis, A., Allan, D., and N. Del Regno, "PWE3 Frame Check Sequence Retention", Work in Progress, September 2005.
[FCS] Malis、A.、アラン、D.、およびN.デル・レグノ、 "PWE3フレームチェックシーケンスの保持"、進歩、2005年9月での作業。
[CEP] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, "SONET/SDH Circuit Emulation Service Over Packet (CEP)", Work in Progress.
【CEP】Malis、A.、パテ、P.、コーエン、R.、編、及びD.カメレオンマン、 "SONET / SDH回線エミュレーションサービスを介してパケット（CEP）"、ProgressのWork。
[SAToP] Vainshtein, A. Ed. and Y. Stein, Ed. "Structure-Agnostic TDM over Packet (SAToP)", Work in Progress.
[のSAToP] Vainshtein、A.編。そして、Y.スタイン、エド。 「パケットオーバー構造 - 不可知論者TDM（のSAToPは）」、進行中の作業します。
[FRAME] Martini, L., Ed. and C. Kawa, "Encapsulation Methods for Transport of Frame Relay Over MPLS Networks", Work in Progress.
[FRAME]マティーニ、L.、エド。そして、C.カワ、「フレームリレーでのMPLSネットワークの輸送のためのカプセル化方法」、進行中の作業。
[ATM] Martini, L., Ed., El-Aawar, N., and M. Bocci, Ed., "Encapsulation Methods for Transport of ATM Over MPLS Networks", Work in Progress.
[ATM]マティーニ、L.、エド。、エル・Aawar、N.、およびM.ボッチ、エド。、 "ATMオーバーMPLSネットワークの輸送のためのカプセル化方法"、進行中の作業。
[PPPHDLC] Martini, L., Rosen, E., Heron, G. and A. Malis, "Encapsulation Methods for Transport of PPP/HDLC Frames Over MPLS Networks", Work in Progress.
[PPPHDLC]マティーニ、L.、ローゼン、E.、ヘロン、G.とA. Malis、 "PPP / HDLCフレームに渡ってMPLSネットワークの輸送のためのカプセル化方法"、進行中の作業。
[ETH] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet Frames Over MPLS Networks", RFC 4448, April 2006.
[ETH]マティーニ、L.、ローゼン、E.、エル・Aawar、N.、およびG.サギ、 "イーサネットのフレームにMPLSネットワークの輸送のためのカプセル化方法"、RFC 4448、2006年4月。
[CESoPSN] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and P. Pate, "Structure-aware TDM Circuit Emulation Service over Packet Switched Network (CESoPSN)", Work in Progress.
【のCESoPSN] Vainshtein、A.編、Sasson、I.、メス、E.、フロスト、T.、およびP.パテは、 "構造認識TDM回線エミュレーションサービスは、パケットを介してネットワーク（のCESoPSN）の交換"、において動作進捗。
[TDMoIP] Stein, Y., Shashoua, R., Insler, R., and M. Anavi, "TDM over IP", Work in Progress, February 2005.
[のTDMoIP]スタイン、Y.、Shashoua、R.、Insler、R.、およびM. Anavi、 "IPオーバーTDM"、進歩、2005年2月に作業。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、RFC 3032、2001年1月。
[SIG] Rosen, E., Luo, W., Davie, B., and V. Radoaca, "Provisioning, Autodiscovery, and Signaling in L2VPNs", Work in Progress, September 2005.
[SIG]ローゼン、E.、羅、W.、デイビー、B.、およびV. Radoaca、 "プロビジョニング、自動検出、およびのL2VPNにシグナリング"、進歩、2005年9月での作業。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385]ブライアント、S.、ツバメ、G.、マティーニ、L.、およびD.マクファーソン、 "MPLS PSNの上の使用のための擬似回線エミュレーションエッジツーエッジ（PWE3）制御ワード"、RFC 4385、2006年2月。
Author's Address
著者のアドレス
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112
ルカ・マティーニシスコシステムズ株式会社9155東ニコルズアベニュー、スイート400イングルウッド、CO、80112
EMail: lmartini@cisco.com
メールアドレス：lmartini@cisco.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）によって提供されます。