[要約] RFC 2820は、LDAPのアクセス制御要件に関する規格であり、LDAPサーバーへのアクセス制御のためのガイドラインを提供します。このRFCの目的は、セキュリティを強化し、LDAPディレクトリサービスへの不正なアクセスを防止することです。
Network Working Group E. Stokes
Request for Comments: 2820 D. Byrne
Category: Informational IBM
B. Blakley
Dascom
P. Behera
Netscape
May 2000
Access Control Requirements for LDAP
LDAPのアクセス制御要件
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This document describes the fundamental requirements of an access control list (ACL) model for the Lightweight Directory Application Protocol (LDAP) directory service. It is intended to be a gathering place for access control requirements needed to provide authorized access to and interoperability between directories.
このドキュメントでは、LightWeight Directory Application Protocol（LDAP）ディレクトリサービスのアクセス制御リスト（ACL）モデルの基本要件について説明します。これは、ディレクトリ間で許可されたアクセスと相互運用性を提供するために必要なアクセス制御要件のための集まりの場所になることを目的としています。
The keywords "MUST", "SHOULD", and "MAY" used in this document are to be interpreted as described in [bradner97].
このドキュメントで使用されるキーワードは「必須」、「必要」、「可能性があります」は、[bradner97]で説明されているように解釈されます。
The ability to securely access (replicate and distribute) directory information throughout the network is necessary for successful deployment. LDAP's acceptance as an access protocol for directory information is driving the need to provide an access control model definition for LDAP directory content among servers within an enterprise and the Internet. Currently LDAP does not define an access control model, but is needed to ensure consistent secure access across heterogeneous LDAP implementations. The requirements for access control are critical to the successful deployment and acceptance of LDAP in the market place.
展開を成功させるには、ネットワーク全体にディレクトリ情報を安全にアクセス（複製および配布）する機能が必要です。ディレクトリ情報のアクセスプロトコルとしてのLDAPの受け入れは、エンタープライズおよびインターネット内のサーバー間のLDAPディレクトリコンテンツのアクセス制御モデル定義を提供する必要性を推進しています。現在、LDAPはアクセス制御モデルを定義していませんが、不均一なLDAP実装全体で一貫した安全なアクセスを確保するために必要です。アクセス制御の要件は、市場でのLDAPの展開と受け入れの成功にとって重要です。
The RFC 2119 terminology is used in this document.
このドキュメントでは、RFC 2119用語が使用されています。
The major objective is to provide a simple, but secure, highly efficient access control model for LDAP while also providing the appropriate flexibility to meet the needs of both the Internet and enterprise environments and policies.
主な目的は、LDAPのシンプルであるが安全で効率的なアクセス制御モデルを提供しながら、インターネット環境とエンタープライズ環境とポリシーの両方のニーズを満たすための適切な柔軟性を提供することです。
This generally leads to several general requirements that are discussed below.
これは通常、以下で説明するいくつかの一般的な要件につながります。
This section is divided into several areas of requirements: general, semantics/policy, usability, and nested groups (an unresolved issue). The requirements are not in any priority order. Examples and explanatory text is provided where deemed necessary. Usability is perhaps the one set of requirements that is generally overlooked, but must be addressed to provide a secure system. Usability is a security issue, not just a nice design goal and requirement. If it is impossible to set and manage a policy for a secure situation that a human can understand, then what was set up will probably be non-secure. We all need to think of usability as a functional security requirement.
このセクションは、一般、セマンティクス/ポリシー、ユーザビリティ、ネストされたグループ（未解決の問題）のいくつかの要件に分かれています。要件は優先順位ではありません。必要と思われる場合は、例と説明テキストが提供されます。ユーザビリティは、おそらく一般的に見落とされている一連の要件ですが、安全なシステムを提供するために対処する必要があります。ユーザビリティはセキュリティの問題であり、優れたデザインの目標と要件ではありません。人間が理解できる安全な状況のためにポリシーを設定および管理することが不可能な場合、設定されたものはおそらく安全ではありません。私たちは皆、ユーザビリティを機能的なセキュリティ要件と考える必要があります。
G1. Model SHOULD be general enough to support extensibility to add desirable features in the future.
G1。モデルは、将来的に望ましい機能を追加するための拡張性をサポートするのに十分な一般的である必要があります。
G2. When in doubt, safer is better, especially when establishing defaults.
G2。疑わしい場合は、特にデフォルトを確立するときは、より安全な方が優れています。
G3. ACL administration SHOULD be part of the LDAP protocol. Access control information MUST be an LDAP attribute.
G3。ACL管理はLDAPプロトコルの一部である必要があります。アクセス制御情報は、LDAP属性である必要があります。
G4. Object reuse protection SHOULD be provided and MUST NOT inhibit implementation of object reuse. The directory SHOULD support policy controlling the re-creation of deleted DNs, particularly in cases where they are re-created for the purpose of assigning them to a subject other than the owner of the deleted DN.
G4。オブジェクトの再利用保護を提供する必要があり、オブジェクトの再利用の実装を阻害してはなりません。ディレクトリは、特に削除されたDNの所有者以外の被験者に割り当てる目的で再作成される場合に、削除されたDNの再作成を制御するポリシーをサポートする必要があります。
S1. Omitted as redundant; see U8.
S1。冗長として省略。U8を参照してください。
S2. More specific policies must override less specific ones (e.g. individual user entry in ACL SHOULD take precedence over group entry) for the evaluation of an ACL.
S2。ACLの評価のために、より具体的なポリシーは、より少ない具体的なポリシーをオーバーライドする必要があります（たとえば、ACLの個々のユーザーエントリはグループエントリよりも優先されるはずです）。
S3. Multiple policies of equal specificity SHOULD be combined in some easily-understood way (e.g. union or intersection). This is best understood by example. Suppose user A belongs to 3 groups and those 3 groups are listed on the ACL. Also suppose that the permissions for each of those groups are not identical. Each group is of equal specificity (e.g. each group is listed on the ACL) and the policy for granting user A access (given the example) SHOULD be combined in some easily understood way, such as by intersection or union. For example, an intersection policy here may yield a more limited access for user A than a union policy.
S3。等しい特異性の複数のポリシーを、簡単に理解できる方法（たとえば、組合や交差点）で組み合わせる必要があります。これは、例で最もよく理解されています。ユーザーAが3つのグループに属し、これらの3つのグループがACLにリストされているとします。また、これらのグループの各グループの権限が同一ではないと仮定します。各グループは同等の特異性（たとえば、各グループがACLにリストされています）であり、ユーザーにアクセスを付与するためのポリシー（例を与えられます）は、交差点や組合など、簡単に理解できる方法で組み合わせる必要があります。たとえば、ここでの交差点ポリシーは、ユニオンポリシーよりもユーザーAのアクセスが制限されている場合があります。
S4. Newly created directory entries SHOULD be subject to a secure default policy.
S4。新しく作成されたディレクトリエントリには、安全なデフォルトポリシーの対象となる必要があります。
S5. Access policy SHOULD NOT be expressed in terms of attributes which the directory administrator or his organization cannot administer (e.g. groups whose membership is administered by another organization).
S5。アクセスポリシーは、ディレクトリ管理者または彼の組織が管理できない属性（たとえば、メンバーシップが別の組織によって管理されているグループ）の観点から表現すべきではありません。
S6. Access policy SHOULD NOT be expressed in terms of attributes which are easily forged (e.g. IP addresses). There may be valid reasons for enabling access based on attributes that are easily forged and the behavior/implications of doing that should be documented.
S6。アクセスポリシーは、簡単に偽造される属性（IPアドレスなど）の観点から表現すべきではありません。簡単に偽造される属性に基づいてアクセスを有効にする正当な理由があり、それを文書化すべき行為の行動/意味があります。
S7. Humans (including administrators) SHOULD NOT be required to manage access policy on the basis of attributes which are not "human-readable" (e.g. IP addresses).
S7。人間（管理者を含む）は、「人間の読み取り可能」ではない属性（IPアドレスなど）に基づいてアクセスポリシーを管理する必要はありません。
S8. It MUST be possible to deny a subject the right to invoke a directory operation. The system SHOULD NOT require a specific implementation of denial (e.g. explicit denial, implicit denial).
S8。被験者にディレクトリ操作を呼び出す権利を拒否することが可能でなければなりません。システムは、特定の拒否の実装を必要としないはずです（例：明示的な否定、暗黙の拒否）。
S9. The system MUST be able (semantically) to support either default-grant or default-deny semantics (not simultaneously).
S9。システムは、デフォルトグラントまたはデフォルトのデニーセマンティクス（同時に）のいずれかをサポートできるように（意味的に）可能である必要があります。
S10. The system MUST be able to support either union semantics or intersection semantics for aggregate subjects (not simultaneously).
S10。システムは、集合人の被験者の組合セマンティクスまたは交差セマンティクスのいずれかをサポートできる必要があります（同時に）。
S11. Absence of policy SHOULD be interpretable as grant or deny. Deny takes precedence over grant among entries of equal specificity.
S11。ポリシーの欠如は、助成金または拒否として解釈可能でなければなりません。DENYは、平等な特異性のエントリ間の助成金よりも優先されます。
S12. ACL policy resolution MUST NOT depend on the order of entries in the ACL.
S12。ACLポリシーの解決は、ACLのエントリの順序に依存してはなりません。
S13. Rights management MUST have no side effects. Granting a subject one right to an object MUST NOT implicitly grant the same or any other subject a different right to the same object. Granting a privilege attribute to one subject MUST NOT implicitly grant the same privilege attribute to any other subject. Granting a privilege attribute to one subject MUST NOT implicitly grant a different privilege attribute to the same or any other subject. Definition: An ACL's "scope" is defined as the set of directory objects governed by the policy it defines; this set of objects is a sub-tree of the directory. Changing the policy asserted by an ACL (by changing one or more of its entries) MUST NOT implicitly change the policy governed by an ACL in a different scope.
S13。権利管理には副作用がない必要があります。対象にオブジェクトに1つの権利を付与すると、同じオブジェクトに対して異なる権利を同じまたは他の主題に暗黙的に付与してはなりません。1つの主題に特権属性を付与することは、他の主題に同じ特権属性を暗黙的に付与してはなりません。1つの主題に特権属性を付与することは、同じまたは他の主題に異なる特権属性を暗黙的に付与してはなりません。定義：ACLの「スコープ」は、定義するポリシーによって支配されるディレクトリオブジェクトのセットとして定義されます。このオブジェクトのセットは、ディレクトリのサブツリーです。ACLによって主張されたポリシーの変更（1つ以上のエントリを変更することにより）は、ACLによって支配されたポリシーを異なる範囲で暗黙的に変更してはなりません。
S14. It SHOULD be possible to apply a single policy to multiple directory entries, even if those entries are in different subtrees. Applying a single policy to multiple directory entries SHOULD NOT require creation and storage of multiple copies of the policy data. The system SHOULD NOT require a specific implementation (e.g. nested groups, named ACLs) of support for policy sharing.
S14。これらのエントリが異なるサブツリーにある場合でも、単一のポリシーを複数のディレクトリエントリに適用することが可能です。複数のディレクトリエントリに単一のポリシーを適用すると、ポリシーデータの複数のコピーの作成とストレージを必要としないでください。システムは、ポリシー共有のサポートの特定の実装（ネストされたグループ、ACLSという名前のネストされたグループなど）を必要としないでください。
U1. When in doubt, simpler is better, both at the interface and in the implementation.
U1。疑わしい場合は、インターフェイスと実装の両方で、よりシンプルに優れています。
U2. Subjects MUST be drawn from the "natural" LDAP namespace; they should be DNs.
U2。被験者は、「自然な」LDAPネームスペースから描画する必要があります。それらはDNSでなければなりません。
U3. It SHOULD NOT be possible via ACL administration to lock all users, including all administrators, out of the directory.
U3。ACL管理を介して、すべての管理者を含むすべてのユーザーをディレクトリからロックすることはできません。
U4. Administrators SHOULD NOT be required to evaluate arbitrary Boolean predicates in order to create or understand policy.
U4。管理者は、ポリシーを作成または理解するために、任意のブールの述語を評価する必要はありません。
U5. Administrators SHOULD be able to administer access to directories and their attributes based on their sensitivity, without having to understand the semantics of individual schema elements and their attributes (see U9).
U5。管理者は、個々のスキーマ要素とその属性のセマンティクスを理解することなく、感度に基づいてディレクトリとその属性へのアクセスを管理できる必要があります（U9を参照）。
U6. Management of access to resources in an entire subtree SHOULD require only one ACL (at the subtree root). Note that this makes access control based explicitly on attribute types very hard, unless you constrain the types of entries in subtrees. For example, another attribute is added to an entry. That attribute may fall outside the grouping covered by the ACL and hence require additional administration where the desired affect is indeed a different ACL. Access control information specified in one administrative area MUST NOT have jurisdiction in another area. You SHOULD NOT be able to control access to the aliased entry in the alias. You SHOULD be able to control access to the alias name.
U6。サブツリー全体のリソースへのアクセスの管理は、1つのACL（サブツリールートで）のみを必要とする必要があります。これにより、サブツリーのエントリのタイプを制約しない限り、アクセス制御が属性タイプに明示的にベースになっていることに注意してください。たとえば、別の属性がエントリに追加されます。その属性は、ACLの対象となるグループの外側に収まる可能性があるため、望ましい影響が実際に別のACLである追加の投与が必要です。ある管理エリアで指定されたアクセス制御情報は、別の領域に管轄権を持たないようにしてください。エイリアスのエイリアスエントリへのアクセスを制御できないはずです。エイリアス名へのアクセスを制御できるはずです。
U7. Override of subtree policy MUST be supported on a per-directory-entry basis.
U7。サブツリーポリシーのオーバーライドは、ディレクトリエントリごとにサポートする必要があります。
U8. Control of access to individual directory entry attributes (not just the whole directory entry) MUST be supported.
U8。個々のディレクトリエントリ属性へのアクセスの制御（ディレクトリエントリ全体だけでなく）をサポートする必要があります。
U9. Administrator MUST be able to coarsen access policy granularity by grouping attributes with similar access sensitivities.
U9。管理者は、同様のアクセス感度を持つ属性をグループ化することにより、アクセスポリシーの粒度をcorarenすることができなければなりません。
U10. Control of access on a per-user granularity MUST be supported.
U10。ユーザーごとの粒度に対するアクセスの制御をサポートする必要があります。
U11. Administrator MUST be able to aggregate users (for example, by assigning them to groups or roles) to simplify administration.
U11。管理者は、管理を簡素化するために（たとえば、グループまたは役割にユーザーを割り当てることにより）集約できる必要があります。
U12. It MUST be possible to review "effective access" of any user, group, or role to any entry's attributes. This aids the administrator in setting the correct policy.
U12。エントリの属性に対して、ユーザー、グループ、または役割の「効果的なアクセス」を確認できる必要があります。これにより、管理者が正しいポリシーを設定するのに役立ちます。
U13. A single administrator SHOULD be able to define policy for the entire directory tree. An administrator MUST be able to delegate policy administration for specific subtrees to other users. This allows for the partitioning of the entire directory tree for policy administration, but still allows a single policy to be defined for the entire tree independent of partitioning. (Partition in this context means scope of administration). An administrator MUST be able to create new partitions at any point in the directory tree, and MUST be able to merge a superior and subordinate partition. An administrator MUST be able to configure whether delegated access control information from superior partitions is to be accepted or not.
U13。単一の管理者は、ディレクトリツリー全体のポリシーを定義できる必要があります。管理者は、特定のサブツリーのポリシー管理を他のユーザーに委任できる必要があります。これにより、政策管理のためにディレクトリツリー全体をパーティション化できますが、分割とは無関係にツリー全体に対して単一のポリシーを定義することができます。（この文脈でのパーティションは、管理の範囲を意味します）。管理者は、ディレクトリツリーの任意の時点で新しいパーティションを作成できる必要があり、上位および下位のパーティションをマージできる必要があります。管理者は、優れたパーティションからの委任されたアクセス制御情報が受け入れられるかどうかを構成できる必要があります。
U14. It MUST be possible to authorize users to traverse directory structure even if they are not authorized to examine or modify some traversed entries; it MUST also be possible to prohibit this. The tree structure MUST be able to be protected from view if so desired by the administrator.
U14。いくつかのトラバースエントリを調べたり変更したりすることを許可されていない場合でも、ユーザーがディレクトリ構造をトラバースすることを許可することは可能でなければなりません。これを禁止することも可能でなければなりません。管理者が望む場合、ツリー構造は視界から保護できる必要があります。
U15. It MUST be possible to create publicly readable entries, which may be read even by unauthenticated clients.
U15。公開されていないエントリを作成することは可能である必要があります。これは、認定されていないクライアントによっても読まれる場合があります。
U16. The model for combining multiple access control list entries referring to a single individual MUST be easy to understand.
U16。単一の個人を参照する複数のアクセス制御リストエントリを組み合わせるためのモデルは、理解しやすい必要があります。
U17. Administrator MUST be able to determine where inherited policy information comes from, that is, where ACLs are located and which ACLs were applied. Where inheritance of ACLs is applied, it must be able to be shown how/where that new ACL is derived from.
U17。管理者は、継承されたポリシー情報がどこから来たのか、つまりACLがどこにあるのか、どのACLが適用されたかを判断できる必要があります。ACLの継承が適用される場合、その新しいACLがどのように/どこから導出されるかを示すことができなければなりません。
U18. It SHOULD be possible for the administrator to configure the access control system to permit users to grant additional access control rights for entries which they create.
U18。管理者がアクセス制御システムを構成して、ユーザーが作成したエントリの追加アクセス制御権を付与できるようにすることが可能です。
Access control is a security consideration. This documents addresses the requirements.
アクセス制御はセキュリティの考慮事項です。このドキュメントは要件に対応しています。
This glossary is intended to aid the novice not versed in depth about access control. It contains a list of terms and their definitions that are commonly used in discussing access control [emca].
この用語集は、アクセス制御に深く精通していない初心者を支援することを目的としています。これには、アクセス制御[EMCA]の議論で一般的に使用される用語のリストとその定義が含まれています。
Access control - The prevention of use of a resource by unidentified and/or unauthorized entities in any other that an authorized manner.
アクセス制御 - 正確なおよび/または許可されていないエンティティによるリソースの使用の防止その他の承認された方法。
Access control list - A set of control attributes. It is a list, associated with a security object or a group of security objects. The list contains the names of security subjects and the type of access that may be granted.
アクセス制御リスト - コントロール属性のセット。これは、セキュリティオブジェクトまたはセキュリティオブジェクトのグループに関連付けられたリストです。リストには、セキュリティ対象の名前と付与される可能性のあるアクセスの種類が含まれています。
Access control policy - A set of rules, part of a security policy, by which human users, or their representatives, are authenticated and by which access by these users to applications and other services and security objects is granted or denied.
アクセス制御ポリシー - 人間のユーザーまたはその代表者が認証され、これらのユーザーがアプリケーションやその他のサービスおよびセキュリティオブジェクトへのアクセスが認証または拒否される一連のルール、セキュリティポリシーの一部。
Access context - The context, in terms of such variables as location, time of day, level of security of the underlying associations, etc., in which an access to a security object is made.
アクセスコンテキスト - コンテキストは、場所、時刻の時刻、基礎となる関連性のセキュリティレベルなど、セキュリティオブジェクトへのアクセスが作成されるなどの変数の観点からです。
Authorization - The granting of access to a security object.
承認 - セキュリティオブジェクトへのアクセスの付与。
Authorization policy - A set of rules, part of an access control policy, by which access by security subjects to security objects is granted or denied. An authorization policy may be defined in terms of access control lists, capabilities, or attributes assigned to security subjects, security objects, or both.
承認ポリシー - セキュリティ対象者によるセキュリティオブジェクトへのアクセスが許可または拒否される、アクセス制御ポリシーの一部である一連のルール。許可ポリシーは、セキュリティ対象、セキュリティオブジェクト、またはその両方に割り当てられたアクセス制御リスト、機能、または属性に関して定義される場合があります。
Control attributes - Attributes, associated with a security object that, when matched against the privilege attributes of a security subject, are used to grant or deny access to the security object. An access control list or list of rights or time of day range are examples of control attributes.
制御属性 - セキュリティ対象の特権属性と一致する場合、セキュリティオブジェクトへのアクセスを許可または拒否するために使用されるセキュリティオブジェクトに関連付けられた属性。アクセス制御リストまたは権利または時間範囲のリストは、制御属性の例です。
Credentials - Data that serve to establish the claimed identity of a security subject relative to a given security domain.
資格情報 - 特定のセキュリティドメインに対するセキュリティ主題の請求されたアイデンティティを確立するのに役立つデータ。
Privilege attributes - Attributes, associated with a security subject that, when matched against control attributes of a security object, are used to grant or deny access to that subject. Group and role memberships are examples of privilege attributes.
特権属性 - セキュリティオブジェクトの制御属性と一致する場合、その主題へのアクセスを許可または拒否するために使用されるセキュリティ主題に関連付けられた属性。グループおよびロールメンバーシップは、特権属性の例です。
Security attributes - A general term covering both privilege attributes and control attributes. The use of security attributes is defined by a security policy.
セキュリティ属性 - 特権属性と制御属性の両方をカバーする一般的な用語。セキュリティ属性の使用は、セキュリティポリシーによって定義されます。
Security object - An entity in a passive role to which a security policy applies.
セキュリティオブジェクト - セキュリティポリシーが適用される受動的役割のエンティティ。
Security policy - A general term covering both access control policies and authorization policies.
セキュリティポリシー - アクセス制御ポリシーと承認ポリシーの両方をカバーする一般用語。
Security subject - An entity in an active role to which a security policy applies.
セキュリティ科目 - セキュリティポリシーが適用される積極的な役割のエンティティ。
[ldap] Kille, S., Howes, T. and M. Wahl, "Lightweight Directory Access Protocol (v3)", RFC 2251, August 1997.
[LDAP] Kille、S.、Howes、T。およびM. Wahl、「Lightweight Directory Access Protocol（V3）」、RFC 2251、1997年8月。
[ecma] ECMA, "Security in Open Systems: A Security Framework" ECMA TR/46, July 1988.
[ECMA] ECMA、「オープンシステムのセキュリティ：セキュリティフレームワーク」ECMA TR/46、1988年7月。
[bradner97] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bradner97] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
Bob Blakley Dascom 5515 Balcones Drive Austin, TX 78731 USA
ボブ・ブラクリー・ダスコム5515バルコンドライブオースティン、テキサス78731 USA
Phone: +1 512 458 4037 ext 5012
Fax: +1 512 458 2377
EMail: blakley@dascom.com
Ellen Stokes IBM 11400 Burnet Rd Austin, TX 78758 USA
エレンストークスIBM 11400バーネットRDオースティン、テキサス78758 USA
Phone: +1 512 838 3725
Fax: +1 512 838 0156
EMail: stokes@austin.ibm.com
Debbie Byrne IBM 11400 Burnet Rd Austin, TX 78758 USA
Debbie Byrne IBM 11400 Burnet Rd Austin、TX 78758 USA
Phone: +1 512 838 1930
Fax: +1 512 838 8597
EMail: djbyrne@us.ibm.com
Prasanta Behera Netscape 501 Ellis Street Mountain View, CA 94043 USA
Prasanta Behera Netscape 501 Ellis Street Mountain View、CA 94043 USA
Phone: +1 650 937 4948
Fax: +1 650 528-4164
EMail: prasanta@netscape.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。