Network Working Group G. Dommety
Request for Comments: 3115 K. Leung
Obsoletes: 3025 cisco Systems
Category: Standards Track April 2001
Mobile IP Vendor/Organization-Specific Extensions
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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
RFC Editor Note:
RFCエディタ注：
This memo corrects discrepancies between the values assigned for CVSE-TYPE-NUMBER and NVSE-TYPE-NUMBER in RFC 3025 and in the Internet Assigned Numbers Authority's (IANA) repository. The difference in the assigned values are as follows:
このメモはRFC 3025で、インターネット割り当て番号機関の（IANA）リポジトリ内のCVSE-TYPE-NUMBERとNVSE-TYPE-NUMBERのために割り当てられた値の間の不一致を修正します。次のように割り当てられた値の差は、次のとおりです。
CVSE-TYPE-NUMBER = 37 in RFC 3025 CVSE-TYPE-NUMBER = 38 in IANA (Under Mobile IP numbers)
CVSE-TYPE-NUMBER = 37 RFC 3025にCVSE-TYPE-NUMBER = IANA 38（モバイルIP番号の下）
NVSE-TYPE-NUMBER = 133 in RFC 3025 NVSE-TYPE-NUMBER = 134 in IANA (Under Mobile IP numbers)
IANAにNVSE-TYPE-NUMBER = RFCで133 3025 NVSE-TYPE-NUMBER = 134（モバイルIP番号の下）
This memo obsoletes RFC 3025, since the current implementations follow the IANA assignments.
現在の実装では、IANAの割り当てに従うので、このメモは、RFC 3025を廃止します。
Abstract
抽象
This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes.
この文書では、モバイルIPには、2つの新しい拡張機能を定義します。これらの拡張機能は、彼らが研究や導入の目的のために合うようにこれらの拡張機能の特定の使用を作るために機器ベンダーや組織を促進します。
Current specification of Mobile IP [1] does not allow for organizations and vendors to include organization/vendor-specific information in the Mobile IP messages. With the imminent wide scale deployment of Mobile IP it is useful to have vendor or organization-Specific Extensions to support this capability. This document defines two extensions that can be used for making organization specific extensions by vendors/organizations for their own specific purposes.
組織やベンダーがモバイルIPメッセージで組織/ベンダー固有の情報を含めるようにするために、モバイルIPの現在の仕様では、[1]はできません。モバイルIPの差し迫った広い規模な展開で、この機能をサポートするために、ベンダーや組織固有の拡張機能があると便利です。この文書は、独自の特定の目的のためにベンダー/組織による組織固有の拡張機能を作成するために使用することができる2つの拡張を定義します。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED" は、 "NOT SHALL" "ものと" この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "OPTIONAL" はにありますRFC 2119に記載されるように解釈される[3]。
In addition, the following words are used to signify the requirements of the specification.
また、以下の単語は、仕様の要件を意味するために使用されています。
silently discard The implementation discards the datagram without further processing, and without indicating an error to the sender. The implementation SHOULD provide the capability of logging the error, including the contents of the discarded datagram, and SHOULD record the event in a statistics counter.
サイレント実装は、さらなる処理なしにデータグラムを破棄し、送信者にエラーを示すことなく廃棄します。実装は、廃棄されたデータグラムの内容を含め、エラーをログに記録する機能を提供すべきである、と統計カウンターにイベントを記録する必要があります。
Two Vendor/Organization Specific Extensions are described, Critical (CVSE) and Normal (NVSE) Vendor/Organization Specific Extensions. The basic differences between the Critical and Normal Extensions are that when the Critical extension is encountered but not recognized, the message containing the extension MUST be silently discarded, whereas when a Normal Vendor/Organization Specific Extension is encountered but not recognized, the extension SHOULD be ignored, but the rest of the Extensions and message data MUST still be processed. Another difference between the two is that Critical Vendor/Organization Extension has a length field of two octets and the NVSE has a length field of only one octet.
二つのベンダー/組織固有の拡張機能が説明され、クリティカル（CVSE）とノーマル（NVSE）ベンダー/組織固有の拡張機能。クリティカルと正規拡大の基本的な違いは、重要な拡張が遭遇したが認識されない場合、通常ベンダー/組織固有の拡張に遭遇したが認識されない場合、拡張子があるべきであるのに対し、拡張子を含むメッセージは黙って、捨てなければなりませんということです無視されますが、拡張機能やメッセージデータの残りの部分は、まだ処理しなければなりません。両者のもう1つの違いは重大ベンダ/組織の拡張は、2つのオクテットの長さフィールドを有することであるとNVSEは、1オクテットの長さフィールドを有しています。
The format of this extension is as shown below.
この拡張のフォーマットは以下のように示されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor/Org-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-CVSE-Type | Vendor-CVSE-Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Critical Vendor/Organization Specific Extension
図1：クリティカルベンダ/組織的な特定の拡張
Type CVSE-TYPE-NUMBER 38
タイプCVSE-TYPE-NUMBER 38
Reserved Reserved for future use. MUST be set to 0 on sending, MUST be ignored on reception.
予約済み将来の使用のために予約されています。送信時に0に設定しなければならなくて、レセプションで無視しなければなりません。
Length Length in bytes of this extension, not including the Type and Length bytes.
タイプと長さバイトを含まないこの拡張のバイト単位の長さの長さ、。
Vendor/Org-ID The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order, as defined in the Assigned Numbers RFC [2].
ベンダー/ ORG-ID上位オクテットは0で、割り当て番号のRFCで定義されている下位3オクテットは、ネットワークバイトオーダーでのベンダーのSMIネットワーク管理プライベートエンタープライズコードされている[2]。
Vendor-CVSE-Type Indicates the particular type of Vendor-CVSE-Extension. The administration of the Vendor-CVSE-Types is done by the Vendor.
ベンダーCVSE-タイプは、ベンダーCVSE-拡張の特定のタイプを示します。ベンダーCVSE-種類の投与はベンダーによって行われます。
Vendor-CVSE-Value Vendor/organization specific data of this Vendor-CVSE-Extension. These data fields may be published in future RFCs. The Vendor-CVSE-Value is zero or more octets. The length of this field can be computed from the Length Field Value.
このベンダーCVSE-拡張のベンダーCVSE-バリューベンダー/組織特有のデータ。これらのデータフィールドは、将来のRFCで公開することができます。ベンダーCVSE-値は、ゼロ以上のオクテットです。このフィールドの長さは長さフィールドの値から計算することができます。
If an implementation does not recognize the CVSE, according to RFC 2002 [1], the entire packet is to be silently dropped.
実装はCVSEを認識しない場合は、RFC 2002 [1]、パケット全体が静かにドロップします。
The format of this extension is as shown below.
この拡張のフォーマットは以下のように示されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor/Org-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-NVSE-Type | Vendor-NVSE-Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Normal Vendor/Organization Specific Extension
図2：通常ベンダー/組織固有の拡張
Type NVSE-TYPE-NUMBER 134
タイプNVSE-TYPE-NUMBER 134
Length Length in bytes of this extension, not including the Type and Length bytes.
タイプと長さバイトを含まないこの拡張のバイト単位の長さの長さ、。
Reserved Reserved for future use. To be set to 0.
予約済み将来の使用のために予約されています。 0に設定します。
Vendor/Org-ID The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order, as defined in the Assigned Numbers RFC [2].
ベンダー/ ORG-ID上位オクテットは0で、割り当て番号のRFCで定義されている下位3オクテットは、ネットワークバイトオーダーでのベンダーのSMIネットワーク管理プライベートエンタープライズコードされている[2]。
Vendor-NVSE-Type Indicates the particular type of Vendor-NVSE-Extension. The administration of the Vendor-NVSE-Types is done by the Vendor.
ベンダーNVSE-Typeがベンダー-NVSE-拡張の特定のタイプを示します。ベンダーNVSE-種類の投与はベンダーによって行われます。
Vendor-NVSE-Value Vendor/organization specific data of this Vendor-NVSE-Extension. These data fields may be published in future RFCs. The Vendor-NVSE-Value is zero or more octets. The length of this field can be computed from the Length Field Value.
このベンダー-NVSE-拡張のベンダーNVSE-バリューベンダー/組織特有のデータ。これらのデータフィールドは、将来のRFCで公開することができます。ベンダーNVSE-値は、ゼロ以上のオクテットです。このフィールドの長さは長さフィールドの値から計算することができます。
When a Mobile IP entity receives a registration request message (or any other request/update message) with an extension of type CVSE-TYPE-NUMBER and recognizes it, but the extension contains an unknown/unsupported vendor ID or Vendor-CVSE-Type, a registration reject (or the appropriate deny message) MUST be sent with the error code to indicate that the registration was rejected due to the presence of an unknown CVSE.
モバイルIPエンティティは、タイプCVSE-TYPE-NUMBERの拡張子で登録要求メッセージ（または他の任意の要求/更新メッセージ）を受信し、それを認識したが、拡張子が不明/サポートされていないベンダーID、またはベンダーCVSEタイプを含む場合登録拒否（または適切なメッセージを拒否）は登録が原因不明CVSEの存在のために拒絶されたことを示すためにエラーコードを送信しなければなりません。
When a Mobile IP entity receives a registration reply (or any other mobile IP reply/acknowledgement message) with an extension of type CVSE-TYPE-NUMBER and recognizes it, but the extensions contains an unknown/unsupported vendor ID or Vendor-CVSE-Type, the processing is performed as described below.
モバイルIPのエンティティタイプCVSE-TYPE-NUMBERの拡張子で登録応答（または任意の他のモバイルIP応答/確認応答メッセージ）を受信し、それを認識したが、拡張機能は不明/サポートされていないベンダーID、またはベンダーCVSEタイプを含む場合以下に説明するように、処理が行われます。
1. If the Mobile IP entity is a transit node for the reply (i.e., this entity processes and sends the registration reply to another entity) a registration reject (or the appropriate deny message) MUST be sent with the error code to indicate that the registration was rejected due to the presence of an unknown CVSE. For example, FA when it receives an unknown CVSE in a registration reply from the HA, should send a registration reject to the MN.
1.モバイルIPエンティティは、応答を中継ノードである（すなわち、このエンティティは、プロセスを、別のエンティティに登録応答を送信する）ことを示すためにエラーコードを送信しなければならない登録が拒否（または適切なメッセージを拒否する）場合登録は原因不明CVSEの存在のために拒否されました。それはHAからの登録応答で、未知のCVSEを受信したとき例えば、FAは、MNに拒否登録を送信する必要があります。
2. If the Mobile IP entity is not a transit node for the reply, the reply is treated as a reject (or the appropriate deny message) due to the presence of an unknown CVSE.
2.モバイルIPエンティティが応答するためのトランジットノードではない場合、応答が原因不明CVSEの存在のために拒否（または拒否メッセージを適切な）として扱われます。
While designing enhancements wherein a CVSE is included in a reply message, it should noted that the reply message could be discarded by the mobile IP entity processing this message. Enhancements that include a CVSE should take this into consideration during design.
CVSEは、応答メッセージに含まれることを特徴とする請求の拡張を設計するが、それは応答メッセージは、このメッセージを処理するモバイルIPエンティティによって廃棄されることに留意すべきです。 CVSEを含める機能強化は、設計時にこれを考慮する必要があります。
When a Mobile IP entity receives a mobile IP related message (registration request/reply, advertisement/solicitation, etc.) with an extension of type NVSE-TYPE-NUMBER and recognizes it, but the extension contains an unknown/unsupported vendor ID or Vendor-NVSE-Type, the entire extension is skipped.
モバイルIPのエンティティタイプNVSE-TYPE-NUMBERの拡張モバイルIPに関連するメッセージ（登録要求/応答、広告/勧誘など）を受信し、それを認識したが、拡張子が不明/サポートされていないベンダーID、またはベンダーが含まれている場合-NVSE-Typeは、全体の拡張はスキップされます。
NOTE that according to RFC 2002 [1], when an extension numbered within the range 0 through 127 is encountered in a registration message but not recognized, the message containing that extension MUST be silently discarded. This document is compliant with the above specification and specifies the action if the extension of type CVSE-TYPE-NUMBER is encountered and recognized, but does not support the vendor ID or the vendor type extension within.
RFC 2002によれば、[1]、127までの範囲内で0番の拡張を登録メッセージに遭遇するが、認識されない場合、その内線番号を含むメッセージを静かに捨てなければならないことに留意されたいです。この文書では、上記の仕様に準拠しており、型CVSE-TYPE-NUMBERの延長が発生したと認識された場合のアクションを指定しますが、ベンダーIDまたは内のベンダータイプの拡張機能をサポートしていません。
The following error codes are defined.
以下のエラーコードが定義されています。
Registration denied by the Foreign agent:
外国人のエージェントによって拒否された登録：
ERROR-FA-1 100: Unsupported Vendor-ID or
unable to interpret Vendor-CVSE-Type in the CVSE sent by the
Mobile Node to the Foreign Agent.
ERROR-FA-2 101: Unsupported Vendor-ID or unable to interpret Vendor-CVSE-Type in the CVSE sent by the Home Agent to the Foreign Agent.
ERROR-FA-2 101：サポートされていないベンダーIDまたは外部エージェントにホームエージェントによって送信されるCVSEにベンダーCVSE型を解釈することができませんでし。
Registration denied by the Home agent:
ホーム・エージェントによって拒否された登録：
ERROR-HA-1 140: Unsupported Vendor-ID or
unable to interpret Vendor-CVSE-Type in the CVSE sent by the
Mobile Node to the Home Agent.
ERROR-HA-2 141: Unsupported Vendor-ID or unable to interpret Vendor-CVSE-Type in the CVSE sent by the Foreign Agent to the Home Agent.
ERROR-HA-2 141：サポートされていないベンダーIDまたはホーム・エージェントへの外部エージェントによって送信されるCVSEにベンダーCVSE型を解釈することができませんでし。
Multiple TLV's with the types CVSE-TYPE-NUMBER and NVSE-TYPE-NUMBER can be included in a message. TLVs with types CVSE-TYPE-NUMBER and NVSE-TYPE-NUMBER can be placed anywhere after the fixed portion of the Mobile IP message. These TLVs are expected to be protected by the corresponding authenticator as necessary. Ordering of these TLV's should not be modified by intermediate nodes.
複数のTLVのタイプCVSE-TYPE-NUMBERとNVSE-TYPE-NUMBERとは、メッセージに含めることができます。タイプCVSE-TYPE-NUMBERとNVSE-TYPE-NUMBERとのTLVは、モバイルIPメッセージの固定部分の後にどこにでも配置することができます。これらのTLVは、必要に応じて、対応するオーセンティケータによって保護されることが期待されます。これらのTLV年代の注文は、中間ノードで変更すべきではありません。
The Critical Vendor/Organization Specific Extension (CVSE) as defined in Section 2.1 and Normal Vendor/Organization Specific Extension (NVSE) as defined in section 2.2 are proposed new extensions to the Mobile IP protocol, defined in RFC 2002 [1] and extended in RFC 2356 [5].
セクション2.2で定義されたような重要なベンダーセクション2.1および正常ベンダ/組織的な特定の拡張（NVSE）で定義されるように/組織的な特定の拡張（CVSE）は、RFC 2002で定義される[1]に延び、モバイルIPプロトコルに新しい拡張を提案していますRFC 2356 [5]。
IANA has assigned a Type value of CVSE-TYPE-NUMBER for the Critical Vendor/Organization Specific Extension (CVSE), and a Type value of NVSE-TYPE-NUMBER for the Normal Vendor/Organization Specific Extension (NVSE). The numbers CVSE-TYPE-NUMBER and NVSE-TYPE-NUMBER for the CVSE and the NVSE are taken from the numbering space defined for Mobile IP registration extensions [1].
IANAは、クリティカルベンダ/組織的な特定の拡張（CVSE）、および正常ベンダ/組織的な特定の拡張（NVSE）用NVSE-TYPE-NUMBERのタイプ値をCVSE-TYPE-NUMBERのタイプの値を割り当てました。 CVSEとNVSEの数値CVSE-TYPE-NUMBERとNVSE-TYPE-NUMBERは、モバイルIP登録拡張のために定義されたナンバリング空間から取られている[1]。
IANA has assigned new Foreign Agent Error Codes, ERROR-FA-1 and ERROR-FA-2 taken from the numbering space defined for Mobile IP Foreign Agent error codes [1]. IANA has also assigned new Home Agent Error Codes, ERROR-HA-1 and ERROR-HA-2 taken from the numbering space defined for Mobile IP Home Agent error codes [1].
IANAは、モバイルIPフォーリンエージェントのエラーコード[1]について定義されたナンバリング空間から取られ、新たな外部エージェントのエラーコード、ERROR-FA-1およびERROR-FA-2が割り当てられています。 IANAはまた、モバイルIPホームエージェントのエラーコード[1]について定義されたナンバリングスペースから取られた新しいホームエージェントのエラーコード、ERROR-HA-1およびERROR-HA-2が割り当てられています。
This document assumes that the Mobile IP messages are authenticated using a method defined by the Mobile IP protocol. This document does not impose any additional requirements on Mobile IP messages from a security point of view. So this is not expected to be a security issue.
この文書では、モバイルIPメッセージは、モバイルIPプロトコルによって定義された方法を使用して認証されることを想定しています。この文書では、セキュリティの観点から、モバイルIPメッセージ上の任意の追加要件を課していません。だから、これはセキュリティ上の問題であることが予想されていません。
The authors would like to thank TR45.4 WG, TR45.6 WG, Basavaraj Patil, Phil Roberts, Jouni Malinen, and Patrice Calhoun for their useful discussions.
著者は彼らの有益な議論のためにTR45.4 WG、TR45.6 WG、Basavarajパティル、フィル・ロバーツ、Jouni Malinen、とパトリス・カルフーンに感謝したいと思います。
[1] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[1]パーキンス、C.、 "IPモビリティサポート"、RFC 2002、1996年10月。
[2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[2]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、STD 2、RFC 1700、1994年10月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[4] Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 2344, May 1998.
[4]モンテネグロ、G.、 "モバイルIPのためのリバーストンネリング"、RFC 2344、1998年5月を。
[5] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998.
[5]モンテネグロ、G.およびV.グプタ、 "モバイルIPのための日のSKIPファイアウォール越え"、RFC 2356、1998年6月。
Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
ゴパルDommetyシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134
EMail: gdommety@cisco.com
メールアドレス：gdommety@cisco.com
Kent Leung Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
ケントレオンシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134
EMail: kleung@cisco.com
メールアドレス：kleung@cisco.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。