[要約] RFC 5178は、GSS-APIの国際化とドメインベースのサービス名と名前タイプに関する標準仕様です。このRFCの目的は、GSS-APIの国際化とドメインベースのサービス名のサポートを提供することです。
Network Working Group N. Williams
Request for Comments: 5178 Sun
Category: Standards Track A. Melnikov
Isode Ltd.
May 2008
Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type
ジェネリックセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）国際化とドメインベースのサービス名と名前タイプ
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
概要
This document describes domain-name-based service principal names and the corresponding name type for the Generic Security Service Application Programming Interface (GSS-API). Internationalization of the GSS-API is also covered.
このドキュメントでは、ドメイン名ベースのサービスプリンシパル名と、一般的なセキュリティサービスアプリケーションプログラミングインターフェイス（GSS-API）の対応する名前タイプについて説明します。GSS-APIの国際化もカバーされています。
Domain-based service names are similar to host-based service names, but using a domain name (not necessarily an Internet domain name) in addition to a hostname. The primary purpose of domain-based names is to provide a measure of protection to applications that utilize insecure service discovery protocols. This is achieved by providing a way to name clustered services after the "domain" which they service, thereby allowing their clients to authorize the service's servers based on authentication of their service names.
ドメインベースのサービス名は、ホストベースのサービス名に似ていますが、ホスト名に加えてドメイン名（必ずしもインターネットドメイン名ではない）を使用します。ドメインベースの名前の主な目的は、安全でないサービス発見プロトコルを利用するアプリケーションに保護の尺度を提供することです。これは、サービスサービスの「ドメイン」にちなんでクラスター化されたサービスに名前を付ける方法を提供することで達成され、それにより、サービス名の認証に基づいてクライアントがサービスのサーバーを承認できるようにします。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Name Type OID . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Name Type OID and Symbolic Name . . . . . . . . . . . . . . 4
4. Query and Display Syntaxes . . . . . . . . . . . . . . . . . . 4
4.1. Examples of Domain-Based Names . . . . . . . . . . . . . . 5
5. Internationalization (I18N) Considerations . . . . . . . . . . 5
5.1. Importing Internationalized Names . . . . . . . . . . . . . 5
5.2. Displaying Internationalized Names . . . . . . . . . . . . 5
6. Application Protocol Examples . . . . . . . . . . . . . . . . . 6
6.1. NFSv4 Domain-Wide Namespace Root Server Discovery . . . . . 6
6.2. LDAP Server Discovery . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Some applications need to discover the names of servers for a specific resource. Some common methods for server discovery are insecure, e.g., queries for DNS [RFC1035] SRV resource records [RFC2782] without using DNSSEC [RFC4033], and are subject to attacks whereby a client can be re-directed to incorrect and possibly malicious servers. A client may even be re-directed to a server that has credentials for itself and thus may authenticate itself to the client, and yet it could be incorrect or malicious (because it has been compromised, say).
一部のアプリケーションは、特定のリソースのサーバーの名前を発見する必要があります。サーバーの発見の一般的な方法のいくつかは、DNSSEC [RFC4033]を使用せずにDNS [RFC1035] SRVリソースレコード[RFC2782]のクエリなど、不安定なものであり、クライアントが不正確で悪意のあるサーバーに再審理される攻撃の対象となります。クライアントは、それ自体の資格情報を持っているため、クライアントに自らを認証するかもしれないサーバーに再監督されるかもしれませんが、それは間違っているか悪意があるかもしれません（それは妥協したためです、例えば）。
Domain-based names allow for GSS-API [RFC2743] initiator applications (clients) to authorize acceptor principals (servers) to serve the resource for which the client used insecure server discovery without either securing the server discovery method or requiring an additional protocol for server authorization. That is, either a discovered server has credentials for authenticating the domain-based service names that it is intended to respond to, or it does not. Availability of valid credentials for authenticating domain-based names embodies the authorization of a given server to a domain-wide service.
ドメインベースの名前では、GSS-API [RFC2743]イニシエーターアプリケーション（クライアント）がアクセプタープリンシパル（サーバー）を許可することを許可し、クライアントがサーバー発見メソッドを保護するか、サーバーの追加プロトコルを必要とすることなく、クライアントが安全でないサーバー発見を使用したリソースを提供します。許可。つまり、発見されたサーバーには、応答することを目的としたドメインベースのサービス名を認証するための資格情報があるか、そうではありません。ドメインベースの名前を認証するための有効な資格情報の可用性は、特定のサーバーの承認をドメイン全体のサービスに具体化します。
A domain-based name consists of three required elements:
ドメインベースの名前は、必要な3つの要素で構成されています。
o a service name
o サービス名
o a domain name
o ドメイン名
o a hostname
o ホスト名
The domain name and the hostname should be Domain Name System (DNS) names, though domain-based names could be used in non-DNS environments. Because of the use of DNS names we must also provide for internationalization of the GSS-API.
ドメイン名とホスト名はドメイン名システム（DNS）名である必要がありますが、ドメインベースの名前は非DNS環境で使用できます。DNS名が使用されているため、GSS-APIの国際化にも提供する必要があります。
Note that domain-based naming isn't new. According to a report to the KITTEN WG mailing list, there exists at least one implementation of LDAP which uses domain-based service naming, and the DIGEST-MD5 HTTP / Simple Authentication and Security Layer (SASL) mechanism [RFC2831] describes a similar notion. (See section 2.1.2 of [RFC2831] for a description of the "serv-name" field of the digest-response.)
ドメインベースの命名は新しいものではないことに注意してください。子猫のWGメーリングリストへのレポートによると、ドメインベースのサービス命名を使用するLDAPの少なくとも1つの実装が存在し、Digest-MD5 HTTP / Simple認証およびセキュリティ層（SASL）メカニズム[RFC2831]が同様の概念を説明しています。。（[RFC2831]のセクション2.1.2を参照して、消化反応の「サーブ名」フィールドの説明を参照してください。）
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 [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
The IANA has recorded the following new name-type OID in IANA's "SMI Security for Name System Designators Codes (nametypes)" registry:
IANAは、IANAの「Name System Designators Codes（nameTypes）のSMIセキュリティ（nameTypes）」に次の新しい名前型OIDを記録しました。
5 gss-domain-based-services [RFC5178]
5 GSS-Domainベースのサービス[RFC5178]
This document creates a new GSS-API name-type, with a symbolic name of "GSS_C_NT_DOMAINBASED_SERVICE" and this OID:
このドキュメントでは、「GSS_C_NT_DOMAINBASED_SERVICE」とThis Oid：の象徴的な名前を持つ新しいGSS-API Name-Typeを作成します。
{iso(1) org(3) dod(6) internet(1) security(5) nametypes(6) gss-
domain-based(5)}
There is a single name syntax for domain-based names. It is expressed using the ABNF [RFC5234].
ドメインベースの名前には単一の名前構文があります。ABNF [RFC5234]を使用して表現されます。
The syntax is:
構文は次のとおりです。
domain-based-name = service "@" domain "@" hostname
hostname = domain
domain = sub-domain 1*("." sub-domain)
domain = sub-domain 1*（ "。" sub-domain）
sub-domain = Let-dig [Ldh-str]
sub-domain = let-dig [ldh-str]
Let-dig = ALPHA / DIGIT
Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
Where <service> is defined in Section 4.1 of [RFC2743]. Other rules not defined above are defined in Appendix B.1 of [RFC5234].
ここで、<Service>は[RFC2743]のセクション4.1で定義されています。上記で定義されていない他のルールは、[RFC5234]の付録B.1に定義されています。
These examples are not normative:
これらの例は規範的ではありません。
o ldap@somecompany.example@ds1.somecompany.example
o ldap@somecompany.example@ds1.somecompany.example
o nfs@somecompany.example@nfsroot1.somecompany.example
o nfs@somecompany.example@nfsroot1.somecompany.example
The .example top-level domain is used here in accordance with [RFC2606].
.exampleのトップレベルドメインは、[RFC2606]に従ってここで使用されます。
We introduce new versions of GSS_Import_name() and GSS_Display_name() to better support Unicode. Additionally, we provide for the use of ASCII Compatible Encoding (ACE)-encoded DNS in the non-internationalized interfaces [RFC3490].
gss_import_name（）およびgss_display_name（）の新しいバージョンを紹介して、Unicodeをよりよくサポートします。さらに、非国内インターフェイス[RFC3490]でASCII互換エンコード（ACE）エンコードDNSの使用を提供します。
When the input_name_type parameter is the GSS_C_NT_DOMAINBASED_SERVICE OID, then GSS_Import_name() implementations and GSS-API mechanisms MUST accept ACE-encoded internationalized domain names in the hostname and domain name slots of the given domain-based name string.
input_name_typeパラメーターがgss_c_nt_domainbased_service oidである場合、GSS_IMPORT_NAME（）実装とGSS-APIメカニズムは、与えられたドーマインベースの名前の弦のホスト名とドメイン名スロットのACEエンコードされた国際化ドメイン名を受け入れる必要があります。
Support for non-ASCII internationalized domain names SHOULD also be provided through a new function, GSS_Import_name_utf8(), that operates exactly like GSS_Import_name() (with the same input and output parameters and behavior), except that it MUST accept internationalized domain names both as UTF-8 strings and as ACE-encoded strings via its input_name_string argument.
非ASCII国際化ドメイン名のサポートは、gss_import_name_utf8（）を介して新しい関数gss_import_name（）とまったく同じように動作します（同じ入力パラメーターと出力パラメーターと動作を使用）。UTF-8文字列およびそのinput_name_string引数を介してエースエンコードされた文字列として。
Implementations of GSS_Display_name() MUST only output US-ASCII or ACE-encoded internationalized domain names in the hostname and domain name slots of domain-based names (or mechanism names (MN) that conform to the mechanism's form for domain-based names).
GSS_DISPLAY_NAME（）の実装は、ドメインベースの名前（またはメカニズム名（MN）のホスト名とドメイン名スロットに、ドメインベースの名前のメカニズム形式に準拠したドメインベースの名前（またはメカニズム名（MN））にUS-ASCIIまたはACE-Encodedの国際化ドメイン名のみを出力する必要があります。
Support for non-ASCII internationalized domain names SHOULD also be provided through a new function, GSS_Display_name_utf8(), that operates exactly like GSS_Display_name() (with the same input and output parameters and behavior), except that it outputs UTF-8 strings via its name_string output argument. GSS_Display_name_utf8() MUST NOT output ACE-encoded internationalized domain names.
非ASCII国際化されたドメイン名のサポートは、GSS_DISPLAY_UTF8（）を介して新しい機能を介して提供する必要があります。これは、GSS_DISPLAY_NAME（）（同じ入力パラメーターと出力パラメーターと動作を使用）とまったく同じように動作します。ただし、UTF-8ストリングを介してUTF-8ストリングを出力します。name_string出力引数。GSS_DISPLAY_NAME_UTF8（）は、ACEエンコードの国際化ドメイン名を出力してはなりません。
The following examples are not normative. They describe how the authors envision two applications' use of domain-based names.
次の例は規範的ではありません。彼らは、著者がドメインベースの2つのアプリケーションの使用をどのように想定しているかを説明しています。
Work is ongoing to provide a method for constructing domain-wide NFSv4 [RFC3530] filesystem namespaces where there is a single "root" with one or more servers (replicas) and multiple filesystems glued into the namespace through use of "referrals". Clients could then construct a "global" namespace through use of the DNS domain hierarchy.
「紹介」を使用して名前空間に接着された1つ以上のサーバー（レプリカ）と複数のファイルシステムが接着された単一の「ルート」がある単一の「ルート」がある場合、ドメイン全体のNFSV4 [RFC3530]ファイルシステム名空間を構築する方法を提供する作業が進行中です。クライアントは、DNSドメイン階層を使用して「グローバルな」名前空間を構築できます。
Here, clients would always know, from context, when they need to find the root servers for a given DNS domain. Root server discovery would be performed using DNS SRV RR lookups, without using DNSSEC where DNSSEC has not been deployed.
ここで、クライアントは、特定のDNSドメインのルートサーバーを見つける必要があるときに、コンテキストから常に知っています。ルートサーバーの発見は、DNSSECが展開されていないDNSSECを使用せずに、DNS SRV RRルックアップを使用して実行されます。
When using RPCSEC_GSS [RFC2203] for security, NFSv4 clients would use domain-based names to ensure that the servers named in the SRV RRs are in fact authorized to be the NFSv4 root servers for the target domain.
セキュリティにRPCSEC_GSS [RFC2203]を使用する場合、NFSV4クライアントはドメインベースの名前を使用して、SRV RRに指定されたサーバーが実際にターゲットドメインのNFSV4ルートサーバーであることが許可されていることを確認します。
LDAP clients using the GSS-API through SASL would also benefit from use of domain-based names to protect server discovery through insecure DNS SRV RR lookups, much as described above.
SASLを介してGSS-APIを使用しているLDAPクライアントは、上記のように、安全でないDNS SRV RRルックアップを介してサーバーの発見を保護するためにドメインベースの名前を使用することからも恩恵を受けます。
Unlike NFSv4 clients, not all LDAP clients always know from context when they should use domain-based names. That's because existing clients may use host-based naming to authenticate servers discovered through SRV RR lookups. Changing such clients to use domain-based naming when domain-based acceptor credentials have not been deployed to LDAP servers, or when LDAP servers have not been modified to allow use of domain-based naming, would break interoperability. That is, there is a legacy server interoperability issue here. Therefore, LDAP clients may require additional configuration at deployment time to enable (or disable) use of domain-based naming.
NFSV4のクライアントとは異なり、すべてのLDAPクライアントがドメインベースの名前を使用する必要があるときに常にコンテキストから知っているわけではありません。これは、既存のクライアントがホストベースのネーミングを使用して、SRV RRルックアップを通じて発見されたサーバーを認証できるためです。ドメインベースのアクセプター資格情報がLDAPサーバーに展開されていない場合、またはLDAPサーバーが変更されていない場合、ドメインベースのネーミングの使用を許可していない場合、そのようなクライアントをドメインベースのネーミングを使用すると、相互運用性が壊れます。つまり、ここにはレガシーサーバーの相互運用性の問題があります。したがって、LDAPクライアントは、ドメインベースの命名を有効に（または無効にする）ために、展開時間に追加の構成が必要になる場合があります。
Note: whether SASL [RFC4422] or its GSS-API bridges [RFC4752] [GS2] require updates in order allow use of domain-based names is not relevant to the theory of how domain-based naming would protect LDAP clients' server discovery.
注：SASL [RFC4422]またはそのGSS-APIブリッジ[RFC4752] [GS2]は、ドメインベースの名前の使用を許可する順序で更新を必要とするかどうかは、ドメインベースのネーミングがLDAPクライアントのサーバー発見をどのように保護するかの理論とは関係ありません。
Use of GSS-API domain-based names may not be negotiable by some GSS-API mechanisms, and some acceptors may not support GSS-API domain-based names. In such cases, the initiators are left to fall back on the use of host-based names, so the initiators MUST also verify that the acceptor's host-based name is authorized to provide the given service for the domain that the initiator had wanted.
The above security consideration also applies to all GSS-API initiators who lack support for domain-based service names.
上記のセキュリティ対価は、ドメインベースのサービス名のサポートがないすべてのGSS-APIイニシエーターにも適用されます。
Note that, as with all service names, the mere existence of a domain-based service name conveys meaningful information that may be used by initiators for making authorization decisions; therefore, administrators of distributed authentication services should be aware of the significance of the service names for which they create acceptor credentials.
すべてのサービス名と同様に、ドメインベースのサービス名の単なる存在は、承認の決定を行うためにイニシエーターが使用できる意味のある情報を伝えていることに注意してください。したがって、分散認証サービスの管理者は、アクセプター資格情報を作成するサービス名の重要性を認識する必要があります。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[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月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743] Linn、J。、「Generic Security Service Application Program Interfaceバージョン2、Update 1」、RFC 2743、2000年1月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[RFC2831] Leach、P。およびC. Newman、「SASLメカニズムとして消化認証を使用」、RFC 2831、2000年5月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[GS2] Josefsson, S., "Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family", Work in Progress, October 2007.
[GS2] Josefsson、S。、「SASLにおけるGSS-APIメカニズムの使用：GS2メカニズムファミリー」、2007年10月、進行中の作業。
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997.
[RFC2203] Eisler、M.、Chiu、A。、およびL. Ling、「RPCSEC_GSSプロトコル仕様」、RFC 2203、1997年9月。
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606] Eastlake、D。およびA. Panitz、「予約されたトップレベルDNS名」、BCP 32、RFC 2606、1999年6月。
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC3530] Shepler、S.、Callaghan、B.、Robinson、D.、Thurlow、R.、Beame、C.、Eisler、M。、およびD. Noveck、「ネットワークファイルシステム（NFS）バージョン4プロトコル」、RFC 3530、2003年4月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの紹介と要件」、RFC 4033、2005年3月。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422] Melnikov、A。およびK. Zeilenga、「Simple Authentication and Security Layer（SASL）」、RFC 4422、2006年6月。
[RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism", RFC 4752, November 2006.
[RFC4752] Melnikov、A。、「Kerberos V5（ "GSSAPI"）単純な認証とセキュリティ層（SASL）メカニズム "、RFC 4752、2006年11月。
Authors' Addresses
著者のアドレス
Nicolas Williams Sun Microsystems 5300 Riata Trace Ct. Austin, TX 78727 US
ニコラス・ウィリアムズサンマイクロシステムズ5300リアタトレースCT。テキサス州オースティン78727 US
EMail: Nicolas.Williams@sun.com
Alexey Melnikov Isode Ltd. 5 Castle Business Village, 36 Station Road Hampton, Middlesex TW12 2BX United Kingdom
Alexey Melnikov Isode Ltd. 5 Castle Business Village、36 Station Road Hampton、ミドルセックスTW12 2BXイギリス
EMail: Alexey.Melnikov@isode.com
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への情報をお問い合わせください。