[要約] RFC 5284は、RSVP（Resource Reservation Protocol）のためのユーザー定義エラーに関する規格であり、エラーコードの定義と使用方法を提供しています。その目的は、ネットワーク通信の際に発生するエラーをより詳細に識別し、適切な対応を行うことです。
Network Working Group G. Swallow
Request for Comments: 5284 Cisco Systems, Inc.
Category: Standards Track A. Farrel
Old Dog Consulting
August 2008
User-Defined Errors for RSVP
RSVPのユーザー定義エラー
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object for communicating errors. That object has a defined format that permits the definition of 256 error codes. As RSVP has been developed and extended, the convention has been to be conservative in defining new error codes. Further, no provision for user-defined errors exists in RSVP.
リソース予約プロトコル（RSVP）は、エラーを通信するためのERROR_SPECオブジェクトを定義します。そのオブジェクトには、256エラーコードの定義を許可する定義された形式があります。RSVPが開発され、拡張されたため、条約は新しいエラーコードの定義において保守的になることになっています。さらに、RSVPにはユーザー定義のエラーの規定は存在しません。
This document defines a USER_ERROR_SPEC to be used in addition to the ERROR_SPEC to carry additional user information related to errors.
このドキュメントでは、エラーに関連する追加のユーザー情報をCARLIDするために、ERROR_SPECに加えて使用されるuser_error_specを定義します。
The Resource ReserVation Protocol (RSVP) [RFC2205] defines an ERROR_SPEC object for communicating errors. That object has a defined format that permits the definition of 256 error codes. As RSVP has been developed and extended, the convention has been to be conservative in communicating errors. Further, no provision for user defined errors exists in RSVP.
リソース予約プロトコル（RSVP）[RFC2205]は、エラーを通信するためのERROR_SPECオブジェクトを定義します。そのオブジェクトには、256エラーコードの定義を許可する定義された形式があります。RSVPが開発され、拡張されたため、条約はエラーの通信において保守的であることになっています。さらに、RSVPにはユーザー定義エラーの規定は存在しません。
When developing extensions to RSVP, it is often useful for those implementing to define error messages to aid both in the initial debugging and in testing against older versions or other implementations.
RSVPへの拡張機能を開発する場合、エラーメッセージを定義する実装が、最初のデバッグと古いバージョンまたはその他の実装に対するテストの両方を支援するために、エラーメッセージを定義することができることがよくあります。
This document defines a new RSVP object to permit user-defined errors to be communicated. This will enable organizations to define errors that they can use for internal development. These error values could also be shared with the community at large to aid in promoting interoperability between diverse implementations.
このドキュメントでは、ユーザー定義のエラーが通信できるようにする新しいRSVPオブジェクトを定義します。これにより、組織は内部開発に使用できるエラーを定義できます。これらのエラー値は、多様な実装間の相互運用性を促進するために、コミュニティ全体と共有することもできます。
RSVP PathErr and ResvErr messages require the presence of an ERROR_SPEC object ([RFC2205]). [RFC3473] defines the Notify message that also requires the presence of an ERROR_SPEC object. In order to not change the mandatory contents of these messages, this document defines a new error code value that indicates that the new object is present and carries a user-defined error code.
RSVP PATHERRおよびRESVERRメッセージには、ERROR_SPECオブジェクト（[RFC2205]）の存在が必要です。[RFC3473]は、ERROR_SPECオブジェクトの存在も必要とする通知メッセージを定義します。これらのメッセージの必須コンテンツを変更しないために、このドキュメントは、新しいオブジェクトが存在し、ユーザー定義のエラーコードが搭載されていることを示す新しいエラーコード値を定義します。
Note that the ResvConf message defined in [RFC2205] also carries an ERROR_SPEC object. But this usage of the object does not carry meaningful Error Codes or Error Values and so the extensions defined in this document are not applicable to that message.
[RFC2205]で定義されているRESVCONFメッセージには、ERROR_SPECオブジェクトも搭載されていることに注意してください。ただし、このオブジェクトの使用は意味のあるエラーコードやエラー値を持たないため、このドキュメントで定義されている拡張機能はそのメッセージに適用できません。
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
A new Error Code is defined for use in an ERROR_SPEC object.
ERROR_SPECオブジェクトで使用するために、新しいエラーコードが定義されています。
Error Code = 33: User Error Spec
エラーコード= 33：ユーザーエラー仕様
This error code is used to signal the presence of a USER_ERROR_SPEC. One Error Value is defined as follows.
このエラーコードは、user_error_specの存在を信号するために使用されます。1つのエラー値は次のように定義されています。
Error Value 0 = Further details in User Error Spec
エラー値0 =ユーザーエラー仕様の詳細
Further error values may be defined in future specifications.
さらなるエラー値は、将来の仕様で定義される場合があります。
When sending this error code, a USER_ERROR_SPEC object MUST be included in the PathErr, ResvErr, or Notify message.
このエラーコードを送信する場合、user_error_specオブジェクトをpatherr、resverr、または通知メッセージに含める必要があります。
A new RSVP object class called USER_ERROR_SPEC is defined. To support backwards compatibility, its class number is in the range 192-247. As defined in [RFC2205], implementations that do not understand such an object will forward it unmodified.
user_error_specと呼ばれる新しいRSVPオブジェクトクラスが定義されています。後方互換性をサポートするために、そのクラス番号は192〜247の範囲にあります。[RFC2205]で定義されているように、そのようなオブジェクトを理解していない実装は、変更されていないことを転送します。
USER_ERROR_SPEC object: Class = 194, C-Type = 1
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
+---------------+---------------+---------------+---------------+
| Enterprise Number |
+---------------+---------------+---------------+---------------+
| Sub Org | Err Desc Len | User Error Value |
+---------------+---------------+---------------+---------------+
| |
~ Error Description ~
| |
+---------------+---------------+---------------+---------------+
| |
~ User-Defined Subobjects ~
| |
+---------------+---------------+---------------+---------------+
Enterprise Number
エンタープライズ番号
A unique identifier of an organization encoded as a 32-bit integer. Enterprise Numbers (sometimes known as Private Enterprise Numbers) are assigned by IANA and managed on a first come first served basis through the IANA registry named "Enterprise Numbers" [RFC2578].
32ビット整数としてエンコードされた組織の一意の識別子。エンタープライズ番号（プライベートエンタープライズ番号と呼ばれることもあります）は、IANAによって割り当てられ、「エンタープライズ番号」[RFC2578]という名前のIANAレジストリを介して先着順で管理されています。
Sub Org
サブオーグ
A unique identifier of an organization encoded as an 8-bit integer. An organization MAY use this field to create independent Error Value spaces. This is intended to facilitate teams that are doing parallel development. If independent spaces are not required, this field SHOULD be set to zero.
8ビット整数としてエンコードされた組織の一意の識別子。組織は、このフィールドを使用して、独立したエラー値スペースを作成する場合があります。これは、並行開発を行っているチームを促進することを目的としています。独立したスペースが不要な場合は、このフィールドをゼロに設定する必要があります。
Err Desc Len
err desc len
The length of the error description in the Error Description field in bytes excluding any padding. Zero is a valid length if no error description is supplied.
パディングを除くバイトのエラー説明フィールドのエラー説明の長さ。エラーの説明が提供されない場合、ゼロは有効な長さです。
User Error Value
ユーザーエラー値
A 16-bit integer. The meaning is specified by the (sub-)organization indicated by the Enterprise Number and Sub Org fields.
16ビット整数。この意味は、エンタープライズ番号とサブオーグフィールドで示される（サブ）組織によって指定されています。
Error Description
エラーの説明
A string of characters padded with nulls (0x00) to a multiple of 4 bytes. According to the guidance in [RFC2277], this string MUST use UTF-8/Net-Unicode encoding [RFC5198]. Furthermore, it is RECOMMENDED that implementations limit the strings that they generate to single-line printable US-ASCII [ASCII] whenever feasible to improve the likelihood of easy use by the recipient.
null（0x00）でパッド入りの文字列（0x00）が4バイトの複数のバイトにパッドされます。[RFC2277]のガイダンスによれば、この文字列はUTF-8/Net-Unicodeエンコード[RFC5198]を使用する必要があります。さらに、実装は、受信者による簡単な使用の可能性を改善するために実行可能な場合はいつでも、単一ラインの印刷可能なUS-ASCII [ASCII]に生成する文字列を制限することをお勧めします。
If the Err Desc Len is zero, then no bytes are supplied.
ERR DESC LENがゼロの場合、バイトは供給されません。
Note that the content of this field is implementation-specific. It is typically printable, but might not be shown to all users in all implementations (because of character set choice). Therefore, the content of the field SHOULD be limited to supplementary information and SHOULD NOT contain information critical to operating the network. Critical information is present in the User Error Value field.
このフィールドのコンテンツは実装固有であることに注意してください。通常、印刷可能ですが、すべての実装ですべてのユーザーには表示されない場合があります（文字セットの選択のため）。したがって、フィールドのコンテンツは補足情報に限定されるべきであり、ネットワークを操作するために重要な情報を含めるべきではありません。重要な情報は、ユーザーエラー値フィールドに存在します。
User-Defined Subobjects
ユーザー定義のサブオブジェクト
User-defined subobjects MAY be included. The generic format of subobjects is specified in Section 3.1. The semantics of a subobject is indicated by the Type field, but the semantics, format, and contents of the Value field are specified by the (sub-)organization indicated by the Enterprise Number and Sub Org fields of this object.
ユーザー定義のサブオブジェクトが含まれる場合があります。サブオブジェクトの汎用形式は、セクション3.1で指定されています。サブオブジェクトのセマンティクスはタイプフィールドで示されますが、値フィールドのセマンティクス、形式、および内容は、このオブジェクトのエンタープライズ番号とサブオーグフィールドで示される（サブ）組織によって指定されます。
Each subobject is encoded as a TLV in the following format:
各サブオブジェクトは、次の形式でTLVとしてエンコードされます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
| Type | Length | (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
Type
タイプ
An 8-bit number assigned by the (sub-)organization indicated by the Enterprise Number and Sub Org fields of the USER_ERROR_SPEC object.
user_error_specオブジェクトのエンタープライズ番号とサブオーグフィールドによって示される（サブ）組織によって割り当てられた8ビット番号。
Length
長さ
The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length MUST be at least 4, and MUST be a multiple of 4.
長さには、タイプと長さのフィールドを含む、バイト内のサブオブジェクトの全長が含まれます。長さは少なくとも4でなければならず、4の倍数でなければなりません。
A USER_ERROR_SPEC object MAY be included in any PathErr, ResvErr, or Notify message for any defined error code. The Enterprise Number MUST be a valid value assigned by IANA from the "Enterprise Numbers" registry.
user_error_specオブジェクトは、任意のpatherr、resverr、または定義されたエラーコードのメッセージを通知することができます。エンタープライズ番号は、「エンタープライズ番号」レジストリからIANAによって割り当てられた有効な値である必要があります。
As specified in [RFC2205] and [RFC3473], an ERROR_SPEC object with a valid error code MUST be included in all PathErr, ResvErr, and Notify messages. This rule is not changed by these procedures even when a USER_ERROR_SPEC object is included. If no other error code applies, the Error Code in the ERROR_SPEC object MUST be set to "User Error Spec" as defined in Section 2 of this document. When the Error Code in the ERROR_SPEC object is set to "User Error Spec", the Error Value sub-code SHOULD be set to "Further details in User Error Spec" as defined in Section 2, but further Error Value sub-codes may be defined in future specifications.
[RFC2205]および[RFC3473]で指定されているように、有効なエラーコードを備えたERROR_SPECオブジェクトは、すべてのPatherR、RESVERR、およびメッセージを通知する必要があります。このルールは、user_error_specオブジェクトが含まれている場合でも、これらの手順によって変更されません。他のエラーコードが適用されない場合、このドキュメントのセクション2で定義されているように、ERROR_SPECオブジェクトのエラーコードを「ユーザーエラー仕様」に設定する必要があります。ERROR_SPECオブジェクトのエラーコードが「ユーザーエラー仕様」に設定されている場合、セクション2で定義されているように、エラー値サブコードを「ユーザーエラー仕様の詳細」に設定する必要がありますが、エラー値サブコードはさらに将来の仕様で定義されています。
It is RECOMMENDED that implementations that receive a PathErr, ResvErr, or Notify message carrying a USER_ERROR_SPEC object log (at a minimum) the Enterprise Number, Sub-organization, User Error Value, and Error Description. Note that the character set used for the Error Description may mean that it might not be suitable for display of logging in all systems. Implementations capable of interpreting the contents of the USER_ERROR_SPEC object SHOULD take further action based on the reported error.
patherr、resverr、または通知メッセージを受信する実装は、ユーザー_ERROR_SPECオブジェクトログを（少なくとも）エンタープライズ番号、サブ組織、ユーザーエラー値、およびエラー説明を伝えることをお勧めします。エラーの説明に使用される文字セットは、すべてのシステムでのロギングの表示に適していない可能性があることを意味する場合があることに注意してください。user_error_specオブジェクトの内容を解釈できる実装は、報告されたエラーに基づいてさらにアクションを実行する必要があります。
Implementations that are not UTF-8 capable and that receive a USER_ERROR_SPEC object SHOULD handle the Error Description according to the procedures set out in [RFC5137].
UTF-8が有能ではなく、user_Error_Specオブジェクトを受信する実装は、[RFC5137]に記載されている手順に従ってエラー説明を処理する必要があります。
If a message is received containing an ERROR_SPEC object using the "User Error Spec" error code, but not containing a USER_ERROR_SPEC object, the message MUST be treated as malformed and handled according to [RFC2205].
「user_error_specオブジェクトを含む「ユーザーエラー仕様」エラーコードを使用してerror_specオブジェクトを含むメッセージが受信された場合、メッセージは[RFC2205]に従って奇形として扱われ、処理する必要があります。
Implementations SHOULD ignore repeated occurrences of USER_ERROR_SPEC objects, and SHOULD forward them unchanged on any messages that they forward. This provides for forward compatibility.
実装は、user_error_specオブジェクトの繰り返し発生を無視する必要があり、転送されるメッセージに変更されていないものを転送する必要があります。これにより、順方向の互換性が提供されます。
Implementations receiving a USER_ERROR_SPEC object on some message other than a PathErr, ResvErr, or Notify message MUST treat the error as a malformed message and process according to [RFC2205].
patherr、resverr、または通知メッセージ以外のメッセージにuser_error_specオブジェクトを受信する実装[RFC2205]に従って、エラーを奇形のメッセージとプロセスとして扱う必要があります。
This document makes the following assignments from the RSVP Error Codes and Globally-Defined Error Value Sub-Codes registry:
このドキュメントは、RSVPエラーコードとグローバルに定義されたエラー値サブコードレジストリから次の割り当てを作成します。
Error Code Meaning
エラーコードの意味
33 User Error Spec
33ユーザーエラー仕様
One Error Value sub-code is defined for use with this Error Code as follows:
次のように、このエラーコードで使用するために1つのエラー値サブコードが定義されます。
0 = Further details in User Error Spec
This document makes the following assignments from the RSVP Class Names, Class Numbers, and Class Types registry:
このドキュメントは、RSVPクラス名、クラス番号、およびクラスタイプのレジストリから次の割り当てを作成します。
Number Space Value Name
番号スペース値名
Class Numbers 194 USER_ERROR_SPEC
クラス番号194 user_error_spec
Class Type 1 User-Defined Error
クラスタイプ1ユーザー定義エラー
This document makes no changes to the basic message exchanges of [RFC2205] and [RFC3473]. It will result in a small increase in the number of error messages sent in cases where messages were previously silently dropped due to the lack of an appropriate error code.
このドキュメントは、[RFC2205]および[RFC3473]の基本的なメッセージ交換に変更を加えません。その結果、適切なエラーコードがないためにメッセージが静かに削除された場合に送信されるエラーメッセージの数がわずかに増加します。
The mechanisms defined in this document may be used by implementations to report additional error conditions and information arising from security issues and attacks on the RSVP network.
このドキュメントで定義されているメカニズムは、RSVPネットワークでのセキュリティの問題や攻撃から生じる追加のエラー条件と情報を報告するために実装によって使用できます。
Note that the use of a character string that will be displayed or logged opens the potential for certain security attacks through the use of overruns or embedded control characters. Implementations SHOULD take precautions against overruns, and (especially where the full character set of [RFC5198] is not supported, SHOULD use the procedures set out in [RFC5137] to handle unexpected or unknown control characters.
表示またはログに記録される文字列の使用は、オーバーランまたは埋め込まれたコントロール文字を使用して、特定のセキュリティ攻撃の可能性を開くことに注意してください。実装はオーバーランに対して予防策を講じる必要があり、（特に[RFC5198]の完全な文字セットがサポートされていない場合、[RFC5137]に記載されている手順を使用して、予期しないまたは不明な制御文字を処理する必要があります。
The authors would like to thank Elisheva Halevy for motivating this document. Thanks to Tom Nadeau, Magnus Westerlund, Hannes Tschofenig, Bruce Davie, Jukka Manner, Francois Le Faucheur, Lars Eggert, and Tom Petch for their review and comments.
著者は、この文書を動機付けてくれたElisheva Halevyに感謝したいと思います。Tom Nadeau、Magnus Westerlund、Hannes Tschofenig、Bruce Davie、Jukka Mather、Francois Le Faucheur、Lars Eggert、Tom Petchに感謝します。
[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月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、9月1997年。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC5137] Klensin, J., "ASCII Escaping of Unicode Characters", BCP 137, RFC 5137, February 2008.
[RFC5137]クレンシン、J。、「Unicode文字のASCII脱出」、BCP 137、RFC 5137、2008年2月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198] Klensin、J。およびM. Padlipsky、「ネットワークインターチェンジのユニコード形式」、RFC 5198、2008年3月。
[ASCII] American National Standards Institute, "USA Code for Information Interchange", ANSI X3.4, 1968.
[ASCII] American National Standards Institute、「USA Code for Information Interchange」、ANSI X3.4、1968。
[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月。
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、Perkins、D。、およびJ. Schoenwaelder、「管理情報の構造バージョン2（SMIV2）」、STD 58、RFC 2578、1999年4月。
Authors' Addresses
著者のアドレス
George Swallow Cisco Systems, Inc. EMail: swallow@cisco.com
George Swallow Cisco Systems、Inc。メール：swallow@cisco.com
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel Old Dog Consultingメール：adrian@olddog.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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への情報をお問い合わせください。