[要約] RFC 3293は、GSMPパケットのATM、Ethernet、TCPへのカプセル化に関する規格です。その目的は、異なるネットワーク技術間でのGSMPの使用を可能にすることです。
Network Working Group A. Doria
Request for Comments: 3293 Lulea University of Technology
Category: Standards Track J. Buerkle
Nortel Networks
T. Worster
June 2002
General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP)
一般的なスイッチ管理プロトコル（GSMP）非同期転送モード（ATM）、イーサネット、トランスミッションコントロールプロトコル（TCP）のパケットカプセル
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 (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This memo specifies the encapsulation of GSMP (General Switch Management Protocol) packets in ATM (Asynchronous Transfer Mode), Ethernet and TCP (Transmission Control Protocol).
このメモは、ATM（非同期転送モード）、イーサネット、TCP（伝送制御プロトコル）のGSMP（一般スイッチ管理プロトコル）パケットのカプセル化を指定します。
Specification of Requirements
要件の仕様
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 RFC 2119 [7].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [7]に記載されているように解釈される。
GSMP messages are defined in [1] and MAY be encapsulated in several different protocols for transport. This memo specifies their encapsulation in ATM AAL-5, in Ethernet or in TCP. Other encapsulations may be defined in future specifications.
GSMPメッセージは[1]で定義されており、輸送用のいくつかの異なるプロトコルにカプセル化される場合があります。このメモは、ATM AAL-5、イーサネット、またはTCPでのカプセル化を指定します。その他のカプセルは、将来の仕様で定義される場合があります。
GSMP packets are variable length and for an ATM data link layer they are encapsulated directly in an AAL-5 CPCS-PDU [3][4] with an LLC/SNAP header as illustrated:
GSMPパケットはさまざまな長さであり、ATMデータリンクレイヤーの場合、LLC/SNAPヘッダーを備えたAAL-5 CPCS-PDU [3] [4]に直接カプセル化されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLC (0xAA-AA-03) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| SNAP (0x00-00-00-88-0C) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pad (0 - 47 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ AAL-5 CPCS-PDU Trailer (8 bytes) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(The convention in the documentation of Internet Protocols [5] is to express numbers in decimal. Numbers in hexadecimal format are specified by prefacing them with the characters "0x". Numbers in binary format are specified by prefacing them with the characters "0b". Data is pictured in "big-endian" order. That is, fields are described left to right, with the most significant byte on the left and the least significant byte on the right. Whenever a diagram shows a group of bytes, the order of transmission of those bytes is the normal order in which they are read in English. Whenever a byte represents a numeric quantity the left most bit in the diagram is the high order or most significant bit. That is, the bit labelled 0 is the most significant bit. Similarly, whenever a multi-byte field represents a numeric quantity the left most bit of the whole field is the most significant bit. When a multi-byte quantity is transmitted, the most significant byte is transmitted first. This is the same coding convention as is used in the ATM layer [2] and AAL-5 [3][4].)
（インターネットプロトコルのドキュメント[5]の規則は、小数点以下で数字を表すことです。16進形式の数字は、文字「0x」を採点することで指定されます。。データは「ビッグエンディアン」の順序で描かれています。つまり、フィールドは左から右に記述され、左側に最も重要なバイトが、右側の最も重要なバイトが表示されます。図がバイトのグループを表示する場合はいつでも、順序これらのバイトの伝送は、英語で読み取られる通常の順序です。バイトが数値を表すときはいつでも、図の最も左が高次または最も重要なビットです。同様に、マルチバイトフィールドが数値を表す場合はいつでも、フィールド全体のほとんどのビットが最も重要なビットです。マルチバイト数量が送信されると、最も重要なバイトが最初に送信されます。これは同じです。ATM層[2]およびAAL-5 [3] [4]で使用されているコーディング慣習。
The LLC/SNAP header contains the bytes: 0xAA 0xAA 0x03 0x00 0x00 0x00 0x88 0x0C. (0x880C is the assigned Ethertype for GSMP.)
LLC/SNAPヘッダーには、バイトが含まれています：0xaa 0xaa 0x03 0x00 0x00 0x00 0x88 0x0c。（0x880cはGSMPに割り当てられたETHERTYPEです。）
The maximum transmission unit (MTU) of the GSMP Message field is 1492 bytes.
GSMPメッセージフィールドの最大透過ユニット（MTU）は1492バイトです。
The virtual channel over which a GSMP session is established between a controller and the switch it is controlling is called the GSMP control channel. The default VPI and VCI of the GSMP control channel for LLC/SNAP encapsulated GSMP messages on an ATM data link layer is:
コントローラーと制御されているスイッチの間にGSMPセッションが確立される仮想チャネルは、GSMPコントロールチャネルと呼ばれます。ATMデータリンクレイヤー上のLLC/SNAPカプセル化GSMPメッセージのGSMP制御チャネルのデフォルトVPIおよびVCIは次のとおりです。
VPI = 0 VCI = 15.
VPI = 0 VCI = 15。
The GSMP control channel MAY be changed using the GSMP MIB.
GSMP MIBを使用してGSMP制御チャネルを変更することができます。
GSMP packets MAY be encapsulated on an Ethernet data link as illustrated:
GSMPパケットは、図のようにイーサネットデータリンクにカプセル化される場合があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype (0x88-0C) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Check Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination Address For the SYN message of the adjacency protocol the Destination Address is the broadcast address 0xFFFFFFFFFFFF. (Alternatively, it is also valid to configure the node with the unicast 48-bit IEEE MAC address of the destination. In this case the configured unicast Destination Address is used in the SYN message.) For all other messages the Destination Address is the unicast 48-bit IEEE. MAC address of the destination. This address may be discovered from the Source Address field of messages received during synchronisation of the adjacency protocol.
隣接プロトコルのSynメッセージの宛先アドレス宛先アドレスは、放送アドレス0xffffffffffffffです。（または、宛先のユニキャスト48ビットIEEE MACアドレスでノードを構成することも有効です。この場合、構成されたユニキャスト宛先アドレスはSynメッセージで使用されます。）他のすべてのメッセージに対して宛先のアドレスはユニキャストです48ビットIEEE。宛先のMACアドレス。このアドレスは、隣接プロトコルの同期中に受信したメッセージのソースアドレスフィールドから発見できます。
Source Address For all messages, the Source Address is the 48-bit IEEE MAC address of the sender.
すべてのメッセージのソースアドレス、ソースアドレスは、送信者の48ビットIEEE Macアドレスです。
Ethertype The assigned Ethertype for GSMP is 0x880C.
ETHERTYPE GSMPに割り当てられたEtherTypeは0x880Cです。
GSMP Message The maximum transmission unit (MTU) of the GSMP Message field is 1492 bytes.
GSMPメッセージGSMPメッセージフィールドの最大透過ユニット（MTU）は1492バイトです。
Sender Instance The Sender Instance number for the link obtained from the adjacency protocol. This field is already present in the adjacency protocol message. It is appended to all non-adjacency GSMP messages in the Ethernet encapsulation to offer additional protection against the introduction of corrupt state.
送信者インスタンス隣接プロトコルから取得したリンクの送信者インスタンス番号。このフィールドは、隣接プロトコルメッセージにすでに存在しています。腐敗状態の導入に対する追加の保護を提供するために、イーサネットカプセル化のすべての非副次的なGSMPメッセージに追加されます。
Receiver Instance The Receiver Instance number is what the sender believes is the current instance number for the link, allocated by the entity at the far end of the link. This field is already present in the adjacency protocol message. It is appended to all non-adjacency GSMP messages in the Ethernet encapsulation to offer additional protection against the introduction of corrupt state.
受信者インスタンスレシーバーインスタンス番号は、リンクの遠端にあるエンティティによって割り当てられたリンクの現在のインスタンス番号であると送信者が信じているものです。このフィールドは、隣接プロトコルメッセージにすでに存在しています。腐敗状態の導入に対する追加の保護を提供するために、イーサネットカプセル化のすべての非副次的なGSMPメッセージに追加されます。
Pad After adjacency has been established the minimum length of the data field of an Ethernet packet is 46 bytes. If necessary, padding should be added such that it meets the minimum Ethernet frame size. This padding should be bytes of zero and is not to be considered part of the GSMP message.
隣接後にパッドが確立された後、イーサネットパケットのデータフィールドの最小長さは46バイトです。必要に応じて、最小イーサネットフレームサイズを満たすようにパディングを追加する必要があります。このパディングはゼロのバイトであるべきであり、GSMPメッセージの一部とは見なされません。
Frame Check Sequence The Frame Check Sequence (FCS) is defined in IEEE 802.3 [6] as follows:
フレームチェックシーケンスフレームチェックシーケンス（FCS）は、次のようにIEEE 802.3 [6]で定義されています。
Note: This section is included for informational and historical purposes only. The normative reference can be found in IEEE 802.3 Standard [6].
注：このセクションは、情報および歴史的な目的のみを目的としています。規範的な参照は、IEEE 802.3標準[6]にあります。
"A cyclic redundancy check (CRC) is used by the transmit and receive algorithms to generate a CRC value for the FCS field. The frame check sequence (FCS) field contains a 4-byte (32-bit) cyclic redundancy check (CRC) value. This value is computed as a function of the contents of the source address, destination address, length, LLC data and pad (that is, all fields except the preamble, SFD, FCS and extension). The encoding is defined by the following generating polynomial.
「環状冗長チェック（CRC）が送信および受信アルゴリズムで使用され、FCSフィールドのCRC値を生成します。フレームチェックシーケンス（FCS）フィールドには、4バイト（32ビット）周期冗長チェック（CRC）が含まれています。値。この値は、ソースアドレス、宛先アドレス、長さ、LLCデータ、およびパッドの内容の関数として計算されます（つまり、プリアンブル、SFD、FCS、拡張機能を除くすべてのフィールド）。エンコーディングは次のように定義されます。多項式の生成。
G(x)=x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^
7+x^5+x^4+x^2+x^1."
The procedure for the CRC calculation can be found in [6].
CRC計算の手順は[6]に記載されています。
After the adjacency protocol has achieved synchronisation, for every GSMP message received with an Ethernet encapsulation, the receiver must check the Source Address from the Ethernet MAC header, the Sender Instance, and the Receiver Instance. The incoming GSMP message must be discarded if the Sender Instance and the Source Address do not match the values of the Sender Instance and the Sender Name stored by the "Update Peer Verifier" operation of the GSMP adjacency protocol. The incoming GSMP message must also be discarded if it arrives over any port other than the port over which the adjacency protocol has achieved synchronisation. In addition, the incoming message must also be discarded if the Receiver Instance field does not match the current value for the Sender Instance of the GSMP adjacency protocol.
隣接プロトコルが同期を達成した後、イーサネットのカプセル化で受信したすべてのGSMPメッセージに対して、受信者はイーサネットMACヘッダー、送信者インスタンス、および受信機インスタンスからソースアドレスを確認する必要があります。送信者インスタンスとソースアドレスが送信者インスタンスの値とGSMP隣接隣接プロトコルの「更新ピアベリファイア」操作によって保存されている送信者名と一致しない場合、着信GSMPメッセージを破棄する必要があります。着信GSMPメッセージは、隣接プロトコルが同期を達成したポート以外のポートに到着する場合も破棄する必要があります。さらに、受信機インスタンスフィールドがGSMP隣接順位プロトコルの送信者インスタンスの現在の値と一致しない場合、着信メッセージも破棄する必要があります。
When GSMP messages are transported over an IP network, they MUST be transported using the TCP encapsulation. TCP provides reliable transport, network flow control, and end-system flow control suitable for networks that may have high loss and variable or unpredictable delay.
GSMPメッセージがIPネットワークを介して輸送される場合、TCPカプセル化を使用して輸送する必要があります。TCPは、信頼性の高い輸送、ネットワークフロー制御、および高い損失と可変または予測不可能な遅延を持つネットワークに適したエンドシステムフロー制御を提供します。
For TCP encapsulations of GSMP messages, the controller runs the client code and the switch runs the server code. Upon initialisation, the server is listening on GSMP's TCP port number: 6068. The controller establishes a TCP connection with each switch it manages. The switch under control MUST be a multi-connection server (PORT 6068) to allow creation of multiple control sessions from N GSMP controller instances. Adjacency protocol messages, which are used to synchronise the controller and switch and maintain handshakes, are sent by the controller to the switch after the TCP connection is established. GSMP messages other than adjacency protocol messages MUST NOT be sent until after the adjacency protocol has achieved synchronisation. The actual GSMP message flow will occur on other ports.
GSMPメッセージのTCPカプセルの場合、コントローラーはクライアントコードを実行し、スイッチはサーバーコードを実行します。初期化すると、サーバーはGSMPのTCPポート番号：6068でリスニングされています。コントローラーは、管理する各スイッチとのTCP接続を確立します。制御下のスイッチは、N GSMPコントローラーインスタンスから複数の制御セッションを作成できるようにするためのマルチ接続サーバー（ポート6068）でなければなりません。コントローラーの同期とスイッチとハンドシェイクの維持に使用される隣接プロトコルメッセージは、TCP接続が確立された後にコントローラーによってスイッチに送信されます。隣接プロトコル以外のGSMPメッセージは、隣接プロトコルが同期を達成するまで送信してはなりません。実際のGSMPメッセージフローは、他のポートで発生します。
GSMP messages are sent over a TCP connection. A GSMP message is processed only after it is entirely received. A four-byte TLV header field is prepended to the GSMP message to provide delineation of GSMP messages within the TCP stream.
GSMPメッセージはTCP接続を介して送信されます。GSMPメッセージは、完全に受信した後にのみ処理されます。4バイトのTLVヘッダーフィールドは、TCPストリーム内のGSMPメッセージの描写を提供するためにGSMPメッセージに加えられます。
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 (0x88-0C) | Length |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type This 2-byte field indicates the type code of the following message. The type code for GSMP messages is 0x88-0C (i.e., the same as GSMP's Ethertype).
タイプこの2バイトフィールドは、次のメッセージのタイプコードを示します。GSMPメッセージのタイプコードは0x88-0c（つまり、GSMPのEtherTypeと同じ）です。
Length This 2-byte unsigned integer indicates the total length of the GSMP message only. It does not include the 4-byte TLV header.
長さこの2バイトの符号なし整数は、GSMPメッセージの総長さのみを示します。4バイトのTLVヘッダーは含まれていません。
When GSMPv3 is implemented for use in IP networks, provisions for security between the controller and client MUST be available and MUST be provided by IP Security [IPSEC]. In this case, the IPSEC Encapsulation Security Payload (ESP) MUST be used to provide both integrity and confidentiality.
GSMPV3がIPネットワークで使用するために実装されている場合、コントローラーとクライアント間のセキュリティの規定が利用可能であり、IPセキュリティ[IPSEC]によって提供される必要があります。この場合、IPSECカプセル化セキュリティペイロード（ESP）を使用して、整合性と機密性の両方を提供する必要があります。
The security of GSMP's TCP/IP control channel has been addressed in Section 4.2. For all uses of GSMP over an IP network it is REQUIRED that GSMP be run over TCP/IP using the security considerations discussed in Section 4.2. Security using ATM and Ethernet encapsulations MAY be provided at the link layer. Discussion of these methods is beyond the scope of this specification. For secure operation over any media, the IP encapsulation with IPsec SHOULD be used.
GSMPのTCP/IPコントロールチャネルのセキュリティは、セクション4.2で対処されています。IPネットワーク上のGSMPのすべての使用については、セクション4.2で説明したセキュリティに関する考慮事項を使用して、GSMPをTCP/IPで実行する必要があります。ATMおよびイーサネットのカプセルを使用したセキュリティは、リンクレイヤーで提供される場合があります。これらの方法の議論は、この仕様の範囲を超えています。任意のメディアで安全な操作を行うには、IPSECを使用したIPカプセル化を使用する必要があります。
References
参考文献
[1] Doria, A., Sundell, K., Hellstrand, F. and T. Worster, "General Switch Management Protocol (GSMP) V3", RFC 3292, June 2002.
[1] Doria、A.、Sundell、K.、Hellstrand、F。、およびT. Worster、「General Switch Management Protocol（GSMP）V3」、RFC 3292、2002年6月。
[2] "B-ISDN ATM Layer Specification," International Telecommunication Union, ITU-T Recommendation I.361, Feb. 1999.
[2] 「B-ISDN ATM層仕様」、International Telecommunication Union、ITU-T推奨I.361、1999年2月。
[3] "B-ISDN ATM Adaptation Layer (AAL) Specification," International Telecommunication Union, ITU-T Recommendation I.363, Mar. 1993.
[3] 「B-ISDN ATM適応層（AAL）仕様」、International Telecommunication Union、ITU-T推奨I.363、1993年3月。
[4] "B-ISDN ATM Adaptation Layer specification: Type 5 AAL", International Telecommunication Union, ITU-T Recommendation I.363.5, Aug. 1996.
[4] 「B-ISDN ATM適応層の仕様：タイプ5 AAL」、International Telecommunication Union、ITU-T推奨I.363.5、1996年8月。
[5] Reynolds, J., Editor, "Assigned Numbers", RFC 3232, January 2002.
[5] Reynolds、J.、編集者、「割り当てられた番号」、RFC 3232、2002年1月。
[6] IEEE Std 802.3, 1998 Edition "Information technology-Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications"
[6] IEEE STD 802.3、1998エディション「情報技術の通信とシステム間の情報交換 - ローカルおよびメトロポリタンエリアネットワーク - 特定の要件 - パート3：衝突検出を伴う複数のアクセス（CSMA/CD）アクセス方法と物理層仕様」
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
Authors' Addresses
著者のアドレス
Tom Worster
トム・ワースター
Phone: +1 617 247 2624
EMail: fsb@thefsb.org
Avri Doria Div. of Computer Communications Lulea University of Technology S-971 87 Lulea Sweden
Avri Doria Div。コンピューター通信ルレア工科大学S-971 87ルレアスウェーデン
Phone: +1 401 663 5024
EMail: avri@acm.com
Joachim Buerkle Nortel Networks Germany GmbH & Co. KG Hahnstr. 37-39 60528 Frankfurt am Main Germany
Joachim Buerkle Nortel Networks Dermany Gmbh＆Co。Kg Hahnstr。37-39 60528フランクフルトAMメインドイツ
EMail: Joachim.Buerkle@nortelnetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。