[要約] RFC 4531は、LDAPのターン操作に関する仕様を定義しており、LDAPセッションの継続性を提供するためのプロトコルを提供します。目的は、LDAPクライアントとサーバー間のセッションの状態を維持し、セッションの切り替えや再接続を可能にすることです。
Network Working Group K. Zeilenga
Request for Comments: 4531 OpenLDAP Foundation
Category: Experimental June 2006
Lightweight Directory Access Protocol (LDAP) Turn Operation
LightWeight Directory Access Protocol（LDAP）ターン操作
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to reverse (or "turn") the roles of client and server for subsequent protocol exchanges in the session, or to enable each peer to act as both client and server with respect to the other.
この仕様では、セッションでの後続のプロトコル交換のクライアントとサーバーの役割を逆転（または「ターン」）するために、軽量ディレクトリアクセスプロトコル（LDAP）拡張操作を説明します。もう一方。
Table of Contents
目次
1. Background and Intent of Use ....................................2
1.1. Terminology ................................................2
2. Turn Operation ..................................................2
2.1. Turn Request ...............................................3
2.2. Turn Response ..............................................3
3. Authentication ..................................................3
3.1. Use with TLS and Simple Authentication .....................4
3.2. Use with TLS and SASL EXTERNAL .............................4
3.3. Use of Mutual Authentication and SASL EXTERNAL .............4
4. TLS and SASL Security Layers ....................................5
5. Security Considerations .........................................6
6. IANA Considerations .............................................6
6.1. Object Identifier ..........................................6
6.2. LDAP Protocol Mechanism ....................................7
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................8
The Lightweight Directory Access Protocol (LDAP) [RFC4510][RFC4511] is a client-server protocol that typically operates over reliable octet-stream transports, such as the Transport Control Protocol (TCP). Generally, the client initiates the stream by connecting to the server's listener at some well-known address.
Lightweight Directory Access Protocol（LDAP）[RFC4510] [RFC4511]は、通常、輸送制御プロトコル（TCP）などの信頼できるオクテットストリームトランスポートを介して動作するクライアントサーバープロトコルです。一般に、クライアントは、いくつかのよく知られたアドレスでサーバーのリスナーに接続することにより、ストリームを開始します。
There are cases where it is desirable for the server to initiate the stream. Although it certainly is possible to write a technical specification detailing how to implement server-initiated LDAP sessions, this would require the design of new authentication and other security mechanisms to support server-initiated LDAP sessions.
サーバーがストリームを開始することが望ましい場合があります。サーバーが開始したLDAPセッションを実装する方法を詳述する技術仕様を作成することは確かに可能ですが、これには、サーバーが開始するLDAPセッションをサポートするために、新しい認証およびその他のセキュリティメカニズムの設計が必要になります。
Instead, this document introduces an operation, the Turn operation, which may be used to reverse the client-server roles of the protocol peers. This allows the initiating protocol peer to become the server (after the reversal).
代わりに、このドキュメントでは、プロトコルピアのクライアントサーバーの役割を逆転させるために使用できる操作であるターン操作を導入します。これにより、開始プロトコルピアが（反転後）サーバーになることができます。
As an additional feature, the Turn operation may be used to allow both peers to act in both roles. This is useful where both peers are directory servers that desire to request, as LDAP clients, that operations be performed by the other. This may be useful in replicated and/or distributed environments.
追加の機能として、ターン操作を使用して、両方のピアが両方の役割で行動できるようにすることができます。これは、両方のピアが、LDAPクライアントとして、その操作を他の操作を要求したいディレクトリサーバーである場合に役立ちます。これは、複製された環境および/または分散環境に役立つ場合があります。
This operation is intended to be used between protocol peers that have established a mutual agreement, by means outside of the protocol, that requires reversal of client-server roles, or allows both peers to act both as client and server.
この操作は、プロトコルの外側にある相互契約を確立したプロトコルピア間で使用することを目的としています。これは、クライアントサーバーの役割の逆転を必要とするか、両方のピアがクライアントとサーバーとして行動できるようにします。
Protocol elements are described using ASN.1 [X.680] with implicit tags. The term "BER-encoded" means the element is to be encoded using the Basic Encoding Rules [X.690] under the restrictions detailed in Section 5.1 of [RFC4511].
プロトコル要素は、暗黙のタグを使用してASN.1 [X.680]を使用して記述されています。「BERENCODED」という用語は、[RFC4511]のセクション5.1で詳述されている制限の下で、基本エンコードルール[x.690]を使用して要素をエンコードすることを意味します。
The Turn operation is defined as an LDAP-Extended Operation [Protocol, Section 4.12] identified by the 1.3.6.1.1.19 OID. The function of the Turn Operation is to request that the client-server roles be reversed, or, optionally, to request that both protocol peers be able to act both as client and server in respect to the other.
ターン操作は、1.3.6.1.1.19 OIDによって識別されるLDAP拡張操作[プロトコル、セクション4.12]として定義されます。ターン操作の機能は、クライアントサーバーの役割を逆転させること、またはオプションで、両方のプロトコルピアが他のプロトコルとサーバーの両方として行動できるように要求することです。
The Turn request is an ExtendedRequest where the requestName field contains the 1.3.6.1.1.19 OID and the requestValue field is a BER-encoded turnValue:
ターンリクエストは、requestNameフィールドに1.3.6.1.1.19が含まれ、requestValueフィールドがベルエンコードされたターンバリューです。
turnValue ::= SEQUENCE {
mutual BOOLEAN DEFAULT FALSE,
identifier LDAPString
}
A TRUE mutual field value indicates a request to allow both peers to act both as client and server. A FALSE mutual field value indicates a request to reserve the client and server roles.
真の相互フィールド値は、両方のピアがクライアントとサーバーの両方として行動できるようにするための要求を示しています。誤った相互のフィールド値は、クライアントとサーバーの役割を予約するリクエストを示します。
The value of the identifier field is a locally defined policy identifier (typically associated with a mutual agreement for which this turn is be executed as part of).
識別子フィールドの値は、ローカルで定義されたポリシー識別子です（通常、このターンがその一部として実行される相互の合意に関連付けられています）。
A Turn response is an ExtendedResponse where the responseName and responseValue fields are absent. A resultCode of success is returned if and only if the responder is willing and able to turn the session as requested. Otherwise, a different resultCode is returned.
ターン応答とは、responsedaname and ResponseValueフィールドが存在しない拡張リスペンスです。Responderが要求に応じてセッションを回転させることができ、順番にできる場合にのみ、成功の結果が返されます。それ以外の場合、別の結果コードが返されます。
This extension's authentication model assumes separate authentication of the peers in each of their roles. A separate Bind exchange is expected between the peers in their new roles to establish identities in these roles.
この拡張機能の認証モデルは、各役割のピアの個別の認証を想定しています。これらの役割でアイデンティティを確立するために、新しい役割のピア間で別のバインド交換が予想されます。
Upon completion of the Turn, the responding peer in its new client role has an anonymous association at the initiating peer in its new server role. If the turn was mutual, the authentication association of the initiating peer in its pre-existing client role is left intact at the responding peer in its pre-existing server role. If the turn was not mutual, this association is void.
ターンが完了すると、新しいクライアントの役割における応答ピアは、新しいサーバーの役割で開始ピアに匿名の関連付けを行います。ターンが相互の場合、既存のクライアントの役割における開始ピアの認証協会は、既存のサーバーの役割で応答するピアでそのまま残されます。ターンが相互になければ、この関連性は無効です。
The responding peer may establish its identity in its client role by requesting and successfully completing a Bind operation.
応答するピアは、バインド操作を要求して正常に完了することにより、クライアントの役割においてそのアイデンティティを確立する場合があります。
The remainder of this section discusses some authentication scenarios. In the protocol exchange illustrations, A refers to the initiating peer (the original client) and B refers to the responding peer (the original server).
このセクションの残りの部分では、いくつかの認証シナリオについて説明します。プロトコル交換の図では、Aは開始ピア（元のクライアント）を指し、Bは応答するピア（元のサーバー）を指します。
A->B: StartTLS Request
B->A: StartTLS(success) Response
A->B: Bind(Simple(cn=B,dc=example,dc=net,B's secret)) Request
B->A: Bind(success) Response
A->B: Turn(TRUE,"XXYYZ") Request
B->A: Turn(success) Response
B->A: Bind(Simple(cn=A,dc=example,dc=net,A's secret)) Request
A->B: Bind(success) Response
In this scenario, TLS (Transport Layer Security) [RFC4346] is started and the initiating peer (the original client) establishes its identity with the responding peer prior to the Turn using the DN/password mechanism of the Simple method of the Bind operation. After the turn, the responding peer, in its new client role, establishes its identity with the initiating peer in its new server role.
このシナリオでは、TLS（輸送層のセキュリティ）[RFC4346]が開始され、開始ピア（元のクライアント）は、バインド操作の単純な方法のDN/パスワードメカニズムを使用して、ターン前に応答ピアとのアイデンティティを確立します。ターン後、応答するピアは、新しいクライアントの役割で、新しいサーバーの役割で開始ピアとのアイデンティティを確立します。
A->B: StartTLS Request
B->A: StartTLS(success) Response
A->B: Bind(SASL(EXTERNAL)) Request
B->A: Bind(success) Response
A->B: Turn(TRUE,"XXYYZ") Request
B->A: Turn(success) Response
B->A: Bind(SASL(EXTERNAL)) Request
A->B: Bind(success) Response
In this scenario, TLS is started (with each peer providing a valid certificate), and the initiating peer (the original client) establishes its identity through the use of the EXTERNAL mechanism of the SASL (Simple Authentication and Security Layer) [RFC4422] method of the Bind operation prior to the Turn. After the turn, the responding peer, in its new client role, establishes its identity with the initiating peer in its new server role.
このシナリオでは、TLSが開始され（各ピアが有効な証明書を提供します）、開始ピア（元のクライアント）は、SASLの外部メカニズム（単純認証とセキュリティ層）[RFC4422]メソッドを使用してそのアイデンティティを確立します。ターン前のバインド操作の。ターン後、応答するピアは、新しいクライアントの役割で、新しいサーバーの役割で開始ピアとのアイデンティティを確立します。
A number of SASL mechanisms, such as GSSAPI [SASL-K5], support mutual authentication. The initiating peer, in its new server role, may use the identity of the responding peer, established by a prior authentication exchange, as its source for "external" identity in subsequent EXTERNAL exchange.
GSSAPI [SASL-K5]などの多くのSASLメカニズムが相互認証をサポートしています。開始ピアは、新しいサーバーの役割で、以前の認証交換によって確立された応答ピアのIDを使用する場合があります。
A->B: Bind(SASL(GSSAPI)) Request
<intermediate messages>
B->A: Bind(success) Response
A->B: Turn(TRUE,"XXYYZ") Request
B->A: Turn(success) Response
B->A: Bind(SASL(EXTERNAL)) Request
A->B: Bind(success) Response
In this scenario, a GSSAPI mutual-authentication exchange is completed between the initiating peer (the original client) and the responding server (the original server) prior to the turn. After the turn, the responding peer, in its new client role, requests that the initiating peer utilize an "external" identity to establish its LDAP authorization identity.
このシナリオでは、ターン前に開始ピア（元のクライアント）と応答サーバー（元のサーバー）の間にGSSAPI相互認証交換が完了します。ターン後、応答するピアは、その新しいクライアントの役割で、開始ピアが「外部」のアイデンティティを利用してLDAP認証IDを確立することを要求します。
As described in [RFC4511], LDAP supports both Transport Layer Security (TLS) [RFC4346] and Simple Authentication and Security Layer (SASL) [RFC4422] security frameworks. The following table illustrates the relationship between the LDAP message layer, SASL layer, TLS layer, and transport connection within an LDAP session.
[RFC4511]で説明されているように、LDAPはトランスポートレイヤーセキュリティ（TLS）[RFC4346]と簡単な認証およびセキュリティ層（SASL）[RFC4422]セキュリティフレームワークの両方をサポートしています。次の表は、LDAPセッション内のLDAPメッセージレイヤー、SASLレイヤー、TLSレイヤー、および輸送接続の関係を示しています。
+----------------------+
| LDAP message layer |
+----------------------+ > LDAP PDUs
+----------------------+ < data
| SASL layer |
+----------------------+ > SASL-protected data
+----------------------+ < data
| TLS layer |
Application +----------------------+ > TLS-protected data
------------+----------------------+ < data
Transport | transport connection |
+----------------------+
This extension does not alter this relationship, nor does it remove the general restriction against multiple TLS layers, nor does it remove the general restriction against multiple SASL layers.
この拡張はこの関係を変更せず、複数のTLS層に対する一般的な制限を除去したり、複数のSASL層に対する一般的な制限を除去したりしません。
As specified in [RFC4511], the StartTLS operation is used to initiate negotiation of a TLS layer. If a TLS is already installed, the StartTLS operation must fail. Upon establishment of the TLS layer, regardless of which peer issued the request to start TLS, the peer that initiated the LDAP session (the original client) performs the "server identity check", as described in Section 3.1.5 of [RFC4513], treating itself as the "client" and its peer as the "server".
[RFC4511]で指定されているように、StartTLS操作は、TLS層の交渉を開始するために使用されます。TLSが既にインストールされている場合、startTLS操作が失敗する必要があります。TLSレイヤーを確立すると、どのピアがTLSを開始するリクエストを発行したかに関係なく、[RFC4513]のセクション3.1.5で説明されているように、LDAPセッション（元のクライアント）を開始したピアは「サーバーIDチェック」を実行します。自分自身を「クライアント」として、そのピアは「サーバー」として扱います。
As specified in [RFC4422], a newly negotiated SASL security layer replaces the installed SASL security layer. Though the client/server roles in LDAP, and hence SASL, may be reversed in subsequent exchanges, only one SASL security layer may be installed at any instance.
[RFC4422]で指定されているように、新しく交渉されたSASLセキュリティ層は、インストールされているSASLセキュリティ層を置き換えます。LDAPのクライアント/サーバーの役割、したがってSASLはその後の交換で逆転する可能性がありますが、任意のインスタンスで1つのSASLセキュリティレイヤーのみをインストールできます。
Implementors should be aware that the reversing of client/server roles and/or allowing both peers to act as client and server likely introduces security considerations not foreseen by the authors of this document. In particular, the security implications of the design choices made in the authentication and data security models for this extension (discussed in Sections 3 and 4, respectively) are not fully studied. It is hoped that experimentation with this extension will lead to better understanding of the security implications of these models and other aspects of this extension, and that appropriate considerations will be documented in a future document. The following security considerations are apparent at this time.
実装者は、クライアント/サーバーの役割を逆転させること、および/または両方のピアがクライアントとサーバーとして行動できるようにすることで、このドキュメントの著者が予測しないセキュリティ上の考慮事項を導入する可能性が高いことに注意する必要があります。特に、この拡張機能の認証およびデータセキュリティモデルで行われた設計選択のセキュリティの意味（それぞれセクション3と4で説明）は完全には研究されていません。この拡張機能の実験が、これらのモデルのセキュリティへの影響やこの拡張機能の他の側面のより良い理解につながり、適切な考慮事項が将来の文書に記録されることが期待されています。現時点では、以下のセキュリティ上の考慮事項が明らかです。
Implementors should take special care to process LDAP, SASL, TLS, and other events in the appropriate roles for the peers. Note that while the Turn reverses the client/server roles with LDAP, and in SASL authentication exchanges, it does not reverse the roles within the TLS layer or the transport connection.
実装者は、ピアにとって適切な役割でLDAP、SASL、TLS、およびその他のイベントを処理するために特別な注意を払う必要があります。ターンはLDAPでクライアント/サーバーの役割を逆転させ、SASL認証交換では、TLSレイヤーまたはトランスポート接続内の役割を逆にしないことに注意してください。
The responding server (the original server) should restrict use of this operation to authorized clients. Client knowledge of a valid identifier should not be the sole factor in determining authorization to turn.
応答サーバー（元のサーバー）は、この操作の使用を認定クライアントに制限する必要があります。有効な識別子に関するクライアントの知識は、ターンする許可を決定する唯一の要因であってはなりません。
Where the peers except to establish TLS, TLS should be started prior to the Turn and any request to authenticate via the Bind operation.
TLSを確立する以外のピアがある場合、ターン前にTLSを開始し、バインド操作を介して認証するリクエストを開始する必要があります。
LDAP security considerations [RFC4511][RFC4513] generally apply to this extension.
LDAPセキュリティに関する考慮事項[RFC4511] [RFC4513]は、一般にこの拡張機能に適用されます。
The following values [RFC4520] have been registered by the IANA.
次の値[RFC4520]はIANAによって登録されています。
The IANA has assigned an LDAP Object Identifier to identify the LDAP Turn Operation, as defined in this document.
IANAは、このドキュメントで定義されているように、LDAPターン操作を識別するためにLDAPオブジェクト識別子を割り当てました。
Subject: Request for LDAP Object Identifier Registration Person & email address to contact for further information: Kurt Zeilenga <kurt@OpenLDAP.org> Specification: RFC 4531 Author/Change Controller: Author Comments: Identifies the LDAP Turn Operation
件名：詳細については、LDAPオブジェクト識別子識別子登録担当者と連絡先の要求担当者とメールアドレスをお問い合わせ：Kurt Zeilenga <kurt@openldap.org>仕様：RFC 4531著者/変更コントローラー：著者コメント：LDAPターン操作を識別します
The IANA has registered the LDAP Protocol Mechanism described in this document.
IANAは、このドキュメントで説明されているLDAPプロトコルメカニズムを登録しています。
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: 1.3.6.1.1.19
Description: LDAP Turn Operation
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Extended Operation
Specification: RFC 4531
Author/Change Controller: Author
Comments: none
[RFC4346] Dierks, T. and, E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346] Dierks、T。および、E。Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.1」、RFC 4346、2006年4月。
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422] Melnikov、A.、ed。K. Zeilenga編、「Simple Authentication and Security Layer（SASL）」、RFC 4422、2006年6月。
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510] Zeilenga、K。、ed。、「Lightweight Directory Access Protocol（LDAP）：技術仕様ロードマップ」、RFC 4510、2006年6月。
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J.、ed。、「Lightweight Directory Access Protocol（LDAP）：The Protocol」、RFC 4511、2006年6月。
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[RFC4513] Harrison、R.、ed。、「Lightweight Directory Access Protocol（LDAP）：認証方法とセキュリティメカニズム」、RFC 4513、2006年6月。
[X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
[X.680]国際電気通信連合 - 通信標準化セクター、「要約構文表記1（ASN.1） - 基本表記の仕様」、X.680（2002）（ISO/IEC 8824-1：2002）。
[X.690] International Telecommunication Union - Telecommunication Standardization Sector, "Specification of ASN.1 encoding rules: Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER)", X.690(2002) (also ISO/IEC 8825-1:2002).
[x.690]国際通信連合 - 通信標準化セクター、「ASN.1エンコーディングルールの仕様：基本エンコーディングルール（BER）、標準エンコードルール（CER）、および区別されたエンコードルール（der）」、X.690（2002）（ISO/IEC 8825-1：2002）。
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[RFC4520] Zeilenga、K。、「Internet Assigned Numbers Authority（IANA）Lightwight Directory Access Protocol（LDAP）の考慮事項」、BCP 64、RFC 4520、2006年6月。
[SASL-K5] Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") SASL Mechanism", Work in Progress, May 2006.
[SASL-K5] Melnikov、A.、ed。、「Kerberos V5（ "gssapi"）SASLメカニズム」、2006年5月の作業。
Author's Address
著者の連絡先
Kurt D. Zeilenga OpenLDAP Foundation
Kurt D. Zeilenga OpenLdap Foundation
EMail: Kurt@OpenLDAP.org
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）によって提供されます。