[要約] RFC 4446は、PWE3（Pseudowire Edge to Edge Emulation）のためのIANAの割り当てに関する規定です。このRFCの目的は、PWE3に関連するプロトコルやパラメータの一貫性と一元管理を確保することです。
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)
Pseudowire EdgeからEdge Emulation（PWE3）へのIANAの割り当て
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントでは、擬似ワイヤエッジ（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配分プロセスのほとんどは、このドキュメントに記載されています。ここで定義されているIANAレジストリは、一般に3つの主要な範囲に分割されています。[RFC2434]に従ってIETFコンセンサスによって割り当てられる範囲、[RFC2434]に従って専門家のレビュープロセスによって割り当てられる範囲、および割り当てられる範囲が割り当てられる範囲です。最初の来ると、ベンダーの独自の割り当てのために予約されている最初のベース。ベンダー専有タイプは、まだ開発中であろうと既に完了しているかどうかにかかわらず、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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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 Pseudowire Type」のレジストリを設定しました。このタイプには15ビット値があります。このドキュメントでは、PWタイプの値1〜30が指定されており、PWタイプの値31〜1024は、[RFC2434]で定義された「エキスパートレビュー」ポリシーを使用して、IANAによって割り当てられます。PWタイプ値1025から4096および32767は、[RFC2434]で定義されたIETFコンセンサスポリシーを使用して割り当てられます。PWタイプの値4097から32766は、ベンダーと専門的な拡張用に予約されており、[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は、「Pseudowire InterfaceパラメーターサブTLV型」のレジストリを設定する必要があります。このタイプには8ビット値があります。このドキュメントでは、サブTLVタイプ1〜12が指定されています。[RFC2434]で定義されている「エキスパートレビュー」ポリシーを使用して、サブTLVタイプ13〜64はIANAによって割り当てられます。[RFC2434]で定義されているIETFコンセンサスポリシーを使用して、サブTLVタイプ65〜127および255は割り当てられます。サブTLVタイプの値128から254は、ベンダープロパリエタリエクステンション用に予約されており、[RFC2434]で定義された「First Come First Servent」ポリシーを使用して、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 to x」、xは小数整数です。 - 最大3つの異なる10進整数。
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タイプと長さのフィールド自体を含む、サブ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タイプの値65〜127および255は、[RFC2434]で定義されているIETFコンセンサスポリシーを使用して割り当てられます。AIIタイプ値128〜254は、ベンダープロパリエタリ拡張のために予約されており、[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.
各割り当てについて、長さフィールドも小数整数として指定する必要があります。
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タイプ値1は、このドキュメントで定義されています。AGIタイプの値2〜64は、[RFC2434]で定義された「エキスパートレビュー」ポリシーを使用して、IANAによって割り当てられます。AGIタイプの値65〜127および255は、[RFC2434]で定義されているIETFコンセンサスポリシーを使用して割り当てられます。AGIタイプの値128〜254は、ベンダープロパリエタリエクステンション用に予約されており、[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.
各割り当てについて、長さフィールドも小数整数として指定する必要があります。
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は、「Pseudowireステータスコード」のレジストリを設定する必要があります。これらは長さ32のビット文字列です。ステータスビット0〜4は、このドキュメントで定義されています。ステータスビット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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.
[CRTL] Martini、L.、Ed。、Rosen、E.、El-Aawar、N.、Smith、T.、およびG. Heron、「Pseudowire Setup and Maintenance futa Label Distribution Protocol（LDP）」、RFC 4447、2006年4月。
[VCCV] Nadeau, T. and R. Aggarwal, "Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)", Work in Progress, August 2005.
[VCCV] Nadeau、T。およびR. Aggarwal、「Pseudo Wire Virtual Circuit Connectivity Verification（VCCV）」、2005年8月の作業。
[FRAG] Malis, A. and M. Townsley, "PWE3 Fragmentation and Reassembly", Work in Progress, September 2005.
[frag] Malis、A。and 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.、Allan、D。、およびN. Del Regno、「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.、Pate、P.、Cohen、R.、ed。、およびD. Zelig、「Sonet/SDHサーキットエミュレーションサービスオーバーパケット（CEP）」、進行中の作業。
[SAToP] Vainshtein, A. Ed. and Y. Stein, Ed. "Structure-Agnostic TDM over Packet (SAToP)", Work in Progress.
[SATOP] Vainshtein、A。Ed。Y. Stein、ed。「構造に依存しないTDM Over Packet（SATOP）」、進行中の作業。
[FRAME] Martini, L., Ed. and C. Kawa, "Encapsulation Methods for Transport of Frame Relay Over MPLS Networks", Work in Progress.
[フレーム]マティーニ、L。、編C. kawa、「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] Martini、L.、ed。、El-Aawar、N。、およびM. Bocci、ed。、「MPLSネットワーク上のATMの輸送のためのカプセル化方法」、進行中の作業。
[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] Martini、L.、Rosen、E.、Heron、G。、およびA. Malis、「MPLSネットワーク上のPPP/HDLCフレームの輸送のためのカプセル化方法」、進行中の作業。
[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] Martini、L.、Rosen、E.、El-Aawar、N。、およびG. Heron、「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.、ed。、Sasson、I.、Metz、E.、Frost、T.、およびP. Pate、「構造認識TDM回路エミュレーションサービス上のパケットスイッチネットワーク（CESOPSN）」進捗。
[TDMoIP] Stein, Y., Shashoua, R., Insler, R., and M. Anavi, "TDM over IP", Work in Progress, February 2005.
[TDMOIP] Stein、Y.、Shashoua、R.、Insler、R。、およびM. Anavi、「TDM Over IP」、Progress、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] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack Encoding」、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] Rosen、E.、Luo、W.、Davie、B。、およびV. Radoaca、「プロビジョニング、自己発見、およびL2VPNSのシグナリング」、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] Bryant、S.、Swallow、G.、Martini、L。、およびD. McPherson、「Pseudowire Emulation Edge-to-Edge（PWE3）MPLS PSNを介して使用するコントロールワード」、RFC 4385、2006年2月。
Author's Address
著者の連絡先
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112
Luca Martini Cisco Systems、Inc。9155 East Nichols Avenue、Suite 400 Englewood、Co、80112
EMail: lmartini@cisco.com
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）によって提供されます。