Network Working Group D. Wysochanski
Request for Comments: 4850 Network Appliance, Inc.
Updates: 3720 April 2007
Category: Standards Track
Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture
インターネット小型コンピュータシステムインタフェース（iSCSIの）ノードアーキテクチャのための宣言型のパブリックExtensionキー
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 IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
The Internet Small Computer Systems Interface (iSCSI) protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys. This document describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. This document updates RFC 3720 to allow iSCSI extension items to be defined by standards track RFCs and experimental RFCs in addition to informational RFCs.
RFC 3720に記述インターネット小型コンピュータシステムインタフェース（iSCSIの）プロトコルは、プライベートまたはパブリック拡張キーの形でプロトコルの拡張項目が可能になります。この文書では、iSCSIのサポート性を向上させる目的のためのパブリックExtensionキーを説明しています。キーは、iSCSIノードがiSCSIログインシーケンス中アーキテクチャの詳細を通信することを可能にすることによってこの目的を達成します。受信ノードは、強化され、ロギングおよびサポートのために、この情報を使用することができます。このドキュメントの更新RFC 3720は、iSCSI拡張項目が標準で定義されることを可能にする情報のRFCに加えて、RFCと実験的RFCを追跡します。
This document describes a declarative Public Extension Key, as defined by Section 12.22 of RFC 3720 [2], that may be used to communicate additional iSCSI node information to the peer node in a session. The information carried in the described key has been found to be valuable in real iSCSI customer environments as initiator and target vendors collaborate to resolve technical issues and better understand the interaction of iSCSI implementations.
RFC 3720のセクション12.22によって定義されるように、この文書は、セッション内のピア・ノードへの追加iSCSIノード情報を通信するために使用され得ること、[2]、宣言パブリック拡張キーが記載されています。説明キーで運ばれた情報は、イニシエータとターゲットのベンダーは、技術的な問題を解決するために協力してより良いiSCSI実装の相互作用を理解し、実際のiSCSIの顧客環境に価値があることが判明しています。
The key has been modeled after the HTTP "Server" and "User-Agent" header fields as specified in Sections 14.38 and 14.43 of RFC 2616 [3], with the text-value(s) of the key roughly equivalent to Product Tokens in Section 3.8 of RFC 2616 [3]. Note, however, that the text-value(s) in the key's list-of-values MUST conform to the Text Format as specified in Section 5.1 of RFC 3720 [2].
キーは、商品にトークンとほぼ同じキーのテキスト値（S）と、HTTP「サーバ」と「ユーザエージェント」セクション14.38およびRFC 2616の14.43で指定されたヘッダフィールド[3]の後にモデル化されていますRFC 2616のセクション3.8 [3]。 RFC 3720のセクション5.1で指定されたキーのリストの値のテキスト値（s）はテキスト形式に従わなければならないこと、しかし、注意してください[2]。
The key is sent during operational parameter negotiation of an iSCSI session's login phase. The intended use of this key is to provide enhanced logging and support capabilities, and to enable collection of iSCSI implementation and usage information.
キーは、iSCSIセッションのログイン・フェーズの動作パラメータのネゴシエーション中に送信されます。このキーの使用目的は、強化されたログ機能とサポート機能を提供するために、およびiSCSIの実装と使用情報の収集を可能にするためです。
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 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。
The definition of the key is as follows, conforming to Sections 11 and 12 of RFC 3720 [2], with example list-of-values conforming to Section 5.1 of RFC 3720 [2].
次のようにキーの定義は、セクション11及びRFC 3720の12に準拠し、[2]、例のリストの値RFC 3720のセクション5.1に準拠した[2]。
The key is defined with a use of "LO", making it a Leading Only key, and does not modify Sections 11 or 12 of RFC 3720 [2]. Thus, the key MUST only be sent on the leading connection, MUST NOT be changed after the leading connection login, and MUST only be sent after the security negotiation login stage has completed (during operational negotiation login stage). The key may be sent during normal or discovery sessions.
キーはリーディングのみキー製造、「LO」を用いて定義され、セクション11またはRFC 3720の12を変更しない[2]。このように、キーが唯一の主要な接続で送らなければなりません、主要な接続ログイン後に変更してはならない、とセキュリティ交渉ログインステージが完了した後にのみ（運用交渉のログイン段階で）送らなければなりません。キーが正常または発見セッション中に送信することができます。
Use: LO, Declarative Senders: Initiator and Target Scope: SW
用途：LO、宣言送信者：イニシエータとターゲット範囲：SW
X#NodeArchitecture=<list-of-values>
X＃NodeArchitecture = <リスト-の値>
Examples:
例：
X#NodeArchitecture=ExampleOS/v1234,ExampleInc_SW_Initiator/1.05a X#NodeArchitecture=ExampleInc_HW_Initiator/4010,Firmware/2.0.0.5 X#NodeArchitecture=ExampleInc_SW_Initiator/2.1,CPU_Arch/i686
X＃NodeArchitecture = ExampleOS / v1234、ExampleInc_SW_Initiator / 1.05a X＃NodeArchitecture = ExampleInc_HW_Initiator / 4010、ファームウェア/ 2.0.0.5 X＃NodeArchitecture = ExampleInc_SW_Initiator / 2.1、CPU_ARCH / i686の
The initiator or target declares the details of its iSCSI node architecture to the remote endpoint. These details may include, but are not limited to, iSCSI vendor software, firmware, or hardware versions, the OS version, or hardware architecture.
イニシエータまたはターゲットは、リモートエンドポイントへのiSCSIノードアーキテクチャの詳細を宣言する。これらの詳細は含まれるが、iSCSIのベンダーのソフトウェア、ファームウェア、またはハードウェアのバージョン、OSのバージョン、またはハードウェア・アーキテクチャが、これらに限定されません。
The length of the key value (total length of the list-of-values) MUST NOT be greater than 255 bytes.
キー値の長さ（リストの値の合計の長さ）が255のバイトを超えてはなりません。
X#NodeArchitecture MUST NOT be redeclared.
X＃NodeArchitectureを再宣言してはなりません。
Functional behavior of the iSCSI node (this includes the iSCSI protocol logic -- the SCSI, iSCSI, and TCP/IP protocols) MUST NOT depend on the presence, absence, or content of the key. The key MUST NOT be used by iSCSI nodes for interoperability, or exclusion of other nodes. To ensure proper use, key values SHOULD be set by the node itself, and there SHOULD NOT be provisions for the key values to contain user-defined text.
iSCSIノードの機能動作は、（これは、iSCSIプロトコルロジック含まれています - SCSI、iSCSI、およびTCP / IPプロトコルを）キーの存在、不在、またはコンテンツに依存してはなりません。キーは、相互運用性、または他のノードの除外のためのiSCSIノードで使用してはいけません。適切な使用を確保するために、キーの値は、ノード自体によって設定する必要があり、キーの値は、ユーザー定義のテキストを格納するための規定があってはなりません。
Nodes implementing this key MUST choose one of the following implementation options:
このキーを実装するノードには、次の実装オプションのいずれかを選択する必要があります。
o only transmit the key, o only log the key values received from other nodes, or o both transmit and log the key values.
Oのみのみ、他のノードから受信したキー値をログO、または両方の送信O、キーを送信し、キー値を記録。
Each node choosing to implement transmission of the key values MUST be prepared to handle the response of RFC 3720 [2] compliant nodes that do not understand the key (RFC 3720 [2] states that compliant nodes MUST respond with X#NodeArchitecture=NotUnderstood).
キー値の伝送を実現するために選択する各ノードは、RFC 3720の応答を処理するために準備しなければなりません[2]キーを理解していない対応ノード（RFC 3720 [2]対応ノードがX＃NodeArchitecture = NotUnderstoodで応答しなければならないと述べています） 。
Nodes that implement transmission and/or logging of the key values may also implement administrative mechanisms that disable and/or change the logging and key transmission detail (see Security Considerations). Thus, a valid behavior for this key may be that a node is completely silent (the node does not transmit any key value, and simply discards any key values it receives without issuing a NotUnderstood response).
キー値の送信および/またはロギングを実装するノードはまた、（セキュリティ上の考慮事項を参照）を無効管理メカニズムを実装および/またはロギングと鍵送信細部を変更することがあります。したがって、このキーの有効な動作は、ノード（ノードは、任意のキー値を送信し、単にNotUnderstood応答を発行することなく、受信する任意のキー値を破棄しない）完全に沈黙していることであってもよいです。
This extension key transmits specific implementation details about the node that sends it; such details may be considered sensitive in some environments. For example, if a certain software or firmware version is known to contain security weaknesses, announcing the presence of that version via this key may not be desirable. The countermeasures for this security concern are:
この拡張キーは、それを送信したノードについての具体的な実装の詳細を送信し、このような詳細は、いくつかの環境に敏感であると考えてよいです。特定のソフトウェアやファームウェアのバージョンが、このキーを経由して、そのバージョンが存在することを発表し、セキュリティの弱点を含むことが知られている場合たとえば、望ましくないかもしれません。このセキュリティ上の懸念のための対策は以下のとおりです。
o sending less detailed information in the key values,
キー値に以下の詳細情報を送信し、O、
o not sending the extension key, or
O拡張キーを送信しない、または
o using IPsec to provide confidentiality for the iSCSI connection on which the key is sent (see RFC 3720 [2] and RFC 3723 [4]).
キーが送信されたiSCSI接続のための機密性を提供するためにIPsecを使用して、O（RFC 3720を参照し、[2]及びRFC 3723 [4]）。
To support the first and second countermeasures, all implementations of this extension key MUST provide an administrative mechanism to disable sending the key. In addition, all implementations SHOULD provide an administrative mechanism to configure a verbosity level of the key value, thereby controlling the amount of information sent. For example, a lower verbosity might enable transmission of node architecture component names only, but no version numbers.
第一及び第二の対策をサポートするために、この拡張キーのすべての実装は、キーの送信を無効にする管理メカニズムを提供しなければなりません。加えて、すべての実装は、それによって送信される情報の量を制御する、キー値の詳細レベルを設定するための管理機構を提供しなければなりません。例えば、より低い冗長のみノードアーキテクチャのコンポーネント名、ないバージョン番号の送信を可能かもしれません。
The choice of which countermeasure is most appropriate depends on the environment. However, sending less detailed information in the key values may be an acceptable countermeasure in many environments, since it provides a compromise between sending too much information and the other more complete countermeasures of not sending the key at all or using IPsec.
対策が最も適切であるの選択は、環境に依存します。それはあまりにも多くの情報およびすべてのキーを送信するか、IPsecを使用していない他のより完全な対策を送るとの間の妥協を提供するのでしかし、キーの値にあまり詳細な情報を送信することは、多くの環境では許容対策かもしれません。
In addition to security considerations involving transmission of the key contents, any logging method(s) used for the key values MUST keep the information secure from intruders. For all implementations, the requirements to address this security concern are:
コンテンツキーの送信を含むセキュリティ上の考慮事項に加えて、キーの値に使用される任意の伐採方法（複数可）侵入者から安全な情報を保持しなければなりません。すべての実装のために、このセキュリティ問題に対処するための要件は次のとおりです。
o Display of the log MUST only be possible with administrative rights to the node.
Oログの表示のみのノードに対する管理者権限で可能でなければなりません。
o Options to disable logging to disk and to keep logs for a fixed duration SHOULD be provided.
Oオプションは、ディスクへのロギングを無効にして提供されるべきである固定期間のログを維持します。
Finally, it is important to note that different nodes may have different levels of risk, and these differences may affect the implementation. The components of risk include assets, threats, and vulnerabilities. Consider the following example iSCSI nodes, which demonstrate differences in assets and vulnerabilities of the nodes, and as a result, differences in implementation:
最後に、異なるノードがリスクの異なるレベルを有することができ、そしてこれらの違いは、実装に影響を与える可能性があることに注意することが重要です。リスクのコンポーネントは、資産、脅威、脆弱性が含まれます。ノードの資産と脆弱性の違いを示し、次の例のiSCSIノードを、考えてみて、その結果、実装の違い：
o One iSCSI target based on a special-purpose operating system. Since the iSCSI target controls access to the data storage containing company assets, the asset level is seen as very high. Also, because of the special-purpose operating system, in which vulnerabilities are less well-known, the vulnerability level is viewed as low.
OつのiSCSIターゲットは、特別な目的のオペレーティングシステムに基づきます。 iSCSIターゲットのコントロールは、会社の資産を含むデータストレージにアクセスするので、資産レベルが非常に高いと見られています。また、ため脆弱性はあまりよく知られている専用のオペレーティングシステムの脆弱性レベルが低いとみなされます。
o Multiple iSCSI initiators in a blade farm, each running a general-purpose operating system. The asset level of each node is viewed as low, since blades are replaceable and low cost. However, the vulnerability level is viewed as high, since there are many well-known vulnerabilities to the general-purpose operating system.
ブレードファーム内のO複数のiSCSIイニシエータは、それぞれ、汎用オペレーティングシステムを実行しています。ブレードは交換可能で低コストであるため、各ノードの資産レベルは、低いとみなされます。汎用オペレーティングシステムに多くのよく知られている脆弱性が存在するので、脆弱性レベルが高いとみなされます。
For the above target, an appropriate implementation might be logging of received key values, but no transmission of the key. For the initiators, an appropriate implementation might be transmission of the key, but no logging of received key values.
上記目標のために、適切な実装は、受信したキー値のロギングが、キーのない伝送かもしれません。イニシエータのために、適切な実装は、鍵の伝送が、受信したキーの値のロギングなしであるかもしれません。
The standards action of this document updates RFC 3720 to allow any iSCSI extension item, specifically X# extension text keys, Y# digest algorithms, and Z# authentication methods, to be defined by a standards track, experimental, or informational RFC. This document is a standards track RFC that defines an X# extension text key.
標準化過程、実験、または情報RFCによって定義される任意のiSCSI拡張アイテム、具体的にX＃拡張テキストキー、Y＃ダイジェストアルゴリズム、およびZ位の認証方法を、可能にするために、この文書の更新RFC 3720の標準化作用。この文書では、X＃拡張テキストキーを定義する標準トラックRFCです。
IANA registered this key as follows:
次のようにIANAは、このキーを登録しました：
o Key Name: X#NodeArchitecture
Oキー名：X＃NodeArchitecture
o Description: Node architecture details
O説明：ノードアーキテクチャの詳細
o Reference: [RFC4850]
Oリファレンス：[RFC4850]
The update to RFC 3720 to allow additional types of RFCs for iSCSI Extension items has the same effect as if the following changes were made to the text of RFC 3720 (RFC text cannot be changed after publication):
RFC 3720への更新は、以下の変更がRFC 3720（RFCテキストが発行後に変更することができない）のテキストに行われたかのようにiSCSIの拡張アイテムのRFCの追加の種類が同じ効果を有することを可能にします。
1) In Section 11.1, the requirement that Z# Authentication methods "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC, or an informational RFC."
1）11.1において、Z＃認証方法が要求「情報RFCによって記述しなければなりません。」 「標準トラックRFC、実験的RFC、または情報のRFCで記述しなければならない。」に変更されます
2) In Section 12.1, the requirement that Y# Digest algorithms "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC, or an informational RFC."
2）セクション12.1において、Y＃ダイジェストアルゴリズムは、「情報RFCによって記述しなければなりません。」の要件「標準トラックRFC、実験的RFC、または情報のRFCで記述しなければならない。」に変更されます
3) In Section 12.22, the requirement that X# text keys "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC, or an informational RFC."
3）セクション12.22、X＃テキストキーが必要で、「情報RFCによって記述しなければなりません。」 「標準トラックRFC、実験的RFC、または情報のRFCで記述しなければならない。」に変更されます
4) In Section 13.3, the description of allowed RFC types for extension items is changed from "The RFC may be informational rather than Standards-Track," to "The RFC MUST be standards track, experimental, or informational,"
4）セクション13.3では、拡張項目の許容RFCタイプの記述は「RFCは標準化過程、実験、または情報でなければなりません」「RFCはむしろ標準トラック以外の情報であってもよい」から変更されます
5) In Section 13.5.2, the phrase "standards track" is changed to "standards track or experimental" in the last sentence of the first paragraph, so that the sentence reads: "If the specification is a standards track or experimental document, the usual IETF procedures for such documents are followed."
「仕様が標準化トラックや実験的な文書である場合は、：文を読むように5）13.5.2項において「基準が追跡」、最初の段落の最後の文で、「標準化トラックまたは実験」に変更されこのような文書のための通常のIETF手順が続いています。」
The registries for iSCSI extension items should be managed as if these changes had been made to the text of RFC 3720.
これらの変更は、RFC 3720のテキストに行われていたかのようにiSCSIの拡張項目のレジストリは管理されるべきです。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
[2] Satran、J.、メタ、K.、Sapuntzakis、C.、Chadalapaka、M.、およびE. Zeidner、 "インターネットの小さいコンピュータシステム（のiSCSI）"、RFC 3720、2004年4月。
[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[3]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[4] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[4] Aboba、B.、ツェン、J.、ウォーカー、J.、Rangan、V.、およびF. Travostino、 "IP上のセキュリティブロックストレージプロトコル"、RFC 3723、2004年4月。
Appendix A. Acknowledgments
付録A.謝辞
The IP Storage (ips) Working Group in the Transport Area of IETF has been responsible for defining the iSCSI protocol (apart from a host of other relevant IP Storage protocols). The author acknowledges the contributions of the entire working group.
IETFの交通地域におけるIPストレージ（IPS）ワーキンググループは、（他の関連するIPストレージプロトコルのホストから離れて）iSCSIプロトコルを定義を担当してきました。著者は全体のワーキンググループの貢献を認めています。
The following individuals directly contributed to identifying issues and/or suggesting resolutions to the issues found in this document: David Black, Mallikarjun Chadalapaka, Paul Koning, Julian Satran, John Hufferd, Claire Kraft, Ranga Sankar, Joseph Pittman, Greg Berg, John Forte, Jim Yuill, William Studenmund, and Ken Sandars. This document benefited from all these contributions.
デビッド・ブラック、Mallikarjun Chadalapaka、ポールKONING、ジュリアンSatran、ジョンHufferd、クレアクラフト、ランガSankarの、ジョセフ・ピットマン、グレッグ・バーグ、ジョン・フォルテ：以下の個人が直接問題を特定および/またはこのドキュメントで見つかった問題への解決策を示唆に貢献しました、ジム・Yuill、ウィリアムStudenmund、とケンSandars。この文書では、これらすべての貢献の恩恵を受けました。
Finally, the author recognizes Network Appliance, Inc. for sponsorship and support during the development of this work.
最後に、著者はこの作品の開発中にスポンサーと支援のためにネットワーク・アプライアンス社を認識しています。
Author's Address
著者のアドレス
Dave Wysochanski 8311 Brier Creek Parkway Suite 105-296 Raleigh, NC 27617 US
デイブWysochanski 8311ブライアークリークパークウェイスイート105から296ローリー、ノースカロライナ27617米国
Phone: +1 919 696 8130 EMail: wysochanski@pobox.com
電話：+1 919 696 8130 Eメール：wysochanski@pobox.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。