[要約] RFC 3703は、ポリシーコア軽量ディレクトリアクセスプロトコル（LDAP）スキーマに関する規格であり、ポリシー情報を効率的に管理するための標準化を目的としています。
Network Working Group J. Strassner
Request for Comments: 3703 Intelliden Corporation
Category: Standards Track B. Moore
IBM Corporation
R. Moats
Lemur Networks, Inc.
E. Ellesson
February 2004
Policy Core Lightweight Directory Access Protocol (LDAP) Schema
ポリシーコアライトウェイトディレクトリアクセスプロトコル（LDAP）スキーマ
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 Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
Abstract
概要
This document defines a mapping of the Policy Core Information Model to a form that can be implemented in a directory that uses Lightweight Directory Access Protocol (LDAP) as its access protocol. This model defines two hierarchies of object classes: structural classes representing information for representing and controlling policy data as specified in RFC 3060, and relationship classes that indicate how instances of the structural classes are related to each other. Classes are also added to the LDAP schema to improve the performance of a client's interactions with an LDAP server when the client is retrieving large amounts of policy-related information. These classes exist only to optimize LDAP retrievals: there are no classes in the information model that correspond to them.
このドキュメントでは、ポリシーコア情報モデルのマッピングを、LightWeight Directory Access Protocol（LDAP）をアクセスプロトコルとして使用するディレクトリに実装できるフォームに定義します。このモデルは、オブジェクトクラスの2つの階層を定義します。RFC3060で指定されているポリシーデータを表現および制御するための情報を表す構造クラスと、構造クラスのインスタンスが互いにどのように関連しているかを示す関係クラスです。クライアントが大量のポリシー関連情報を取得しているときに、クライアントとLDAPサーバーとの相互作用のパフォーマンスを改善するために、クラスもLDAPスキーマに追加されます。これらのクラスは、LDAP検索を最適化するためにのみ存在します。情報モデルには、それらに対応するクラスはありません。
Table of Contents
目次
1. Introduction ................................................. 2
2. The Policy Core Information Model ............................ 4
3. Inheritance Hierarchy for the PCLS ........................... 5
4. General Discussion of Mapping the Information Model to LDAP .. 6
4.1. Summary of Class and Association Mappings .............. 7
4.2. Usage of DIT Content and Structure Rules and Name Forms. 9
4.3. Naming Attributes in the PCLS .......................... 10
4.4. Rule-Specific and Reusable Conditions and Actions ...... 11
4.5. Location and Retrieval of Policy Objects in the
Directory .............................................. 16
4.5.1. Aliases and Other DIT-Optimization Techniques .. 19
5. Class Definitions ............................................ 19
5.1. The Abstract Class "pcimPolicy" ........................ 21
5.2. The Three Policy Group Classes ......................... 22
5.3. The Three Policy Rule Classes .......................... 23
5.4. The Class pcimRuleConditionAssociation ................. 30
5.5. The Class pcimRuleValidityAssociation .................. 32
5.6. The Class pcimRuleActionAssociation .................... 34
5.7. The Auxiliary Class pcimConditionAuxClass .............. 36
5.8. The Auxiliary Class pcimTPCAuxClass .................... 36
5.9. The Auxiliary Class pcimConditionVendorAuxClass ........ 40
5.10. The Auxiliary Class pcimActionAuxClass ................. 41
5.11. The Auxiliary Class pcimActionVendorAuxClass ........... 42
5.12. The Class pcimPolicyInstance ........................... 43
5.13. The Auxiliary Class pcimElementAuxClass ................ 44
5.14. The Three Policy Repository Classes .................... 45
5.15. The Auxiliary Class pcimSubtreesPtrAuxClass ............ 46
5.16. The Auxiliary Class pcimGroupContainmentAuxClass ....... 48
5.17. The Auxiliary Class pcimRuleContainmentAuxClass ........ 49
6. Extending the Classes Defined in This Document ............... 50
6.1. Subclassing pcimConditionAuxClass and pcimActionAuxClass 50
6.2. Using the Vendor Policy Attributes ..................... 50
6.3. Using Time Validity Periods ............................ 51
7. Security Considerations ...................................... 51
8. IANA Considerations .......................................... 53
8.1. Object Identifiers ..................................... 53
8.2. Object Identifier Descriptors .......................... 53
9. Acknowledgments .............................................. 56
10. Appendix: Constructing the Value of orderedCIMKeys .......... 57
11. References ................................................... 58
11.1. Normative References ................................... 58
11.2. Informative References ................................. 59
12. Authors' Addresses ........................................... 60
13. Full Copyright Statement ..................................... 61
This document takes as its starting point the object-oriented information model for representing information for representing and controlling policy data as specified in [1]. Lightweight Directory Access Protocol (LDAP) [2] implementers, please note that the use of the term "policy" in this document does not refer to the use of the term "policy" as defined in X.501 [4]. Rather, the use of the term "policy" throughout this document is defined as follows:
このドキュメントは、[1]で指定されているように、ポリシーデータを表現および制御するための情報を表すためのオブジェクト指向の情報モデルを出発点として取得します。Lightweight Directory Access Protocol（LDAP）[2]実装者は、このドキュメントの「ポリシー」という用語の使用は、X.501 [4]で定義されている「ポリシー」という用語の使用を指すものではないことに注意してください。むしろ、このドキュメント全体の「ポリシー」という用語の使用は、次のように定義されています。
Policy is defined as a set of rules to administer, manage, and control access to network resources.
ポリシーは、ネットワークリソースへのアクセスを管理、管理、および制御するための一連のルールとして定義されます。
This work is currently under joint development in the IETF's Policy Framework working group and in the Policy working group of the Distributed Management Task Force (DMTF). This model defines two hierarchies of object classes: structural classes representing policy information and control of policies, and relationship classes that indicate how instances of the structural classes are related to each other. In general, both of these class hierarchies will need to be mapped to a particular data store.
この作業は現在、IETFのポリシーフレームワークワーキンググループおよび分散管理タスクフォース（DMTF）のポリシーワーキンググループで共同開発中です。このモデルは、オブジェクトクラスの2つの階層を定義します。ポリシー情報とポリシーの制御を表す構造クラスと、構造クラスのインスタンスが互いにどのように関連しているかを示す関係クラスです。一般に、これらのクラス階層は両方とも特定のデータストアにマッピングする必要があります。
This document defines the mapping of these information model classes to a directory that uses LDAP as its access protocol. Two types of mappings are involved:
このドキュメントでは、これらの情報モデルクラスのLDAPをアクセスプロトコルとして使用するディレクトリへのマッピングを定義します。2種類のマッピングが関係しています。
- For the structural classes in the information model, the mapping is basically one-for-one: information model classes map to LDAP classes, information model properties map to LDAP attributes.
- 情報モデルの構造クラスの場合、マッピングは基本的に1対1です。情報モデルクラスはLDAPクラスにマッピングされ、情報モデルプロパティはLDAP属性にマッピングされます。
- For the relationship classes in the information model, different mappings are possible. In this document, the Policy Core Information Model's (PCIM's) relationship classes and their properties are mapped in three ways: to LDAP auxiliary classes, to attributes representing distinguished name (DN) references, and to superior-subordinate relationships in the Directory Information Tree (DIT).
- 情報モデルの関係クラスでは、さまざまなマッピングが可能です。このドキュメントでは、ポリシーコア情報モデル（PCIM）関係クラスとそのプロパティは、次の3つの方法でマッピングされます。dit）。
Implementations that use an LDAP directory as their policy repository and want to implement policy information according to RFC 3060 [1] SHALL use the LDAP schema defined in this document, or a schema that subclasses from the schema defined in this document. The use of the information model defined in reference [1] as the starting point enables the inheritance and the relationship class hierarchies to be extensible, such that other types of policy repositories, such as relational databases, can also use this information.
LDAPディレクトリをポリシーリポジトリとして使用し、RFC 3060 [1]に従ってポリシー情報を実装する実装は、このドキュメントで定義されているLDAPスキーマ、またはこのドキュメントで定義されたスキーマからサブクラス化するスキーマを使用するものとします。参照[1]で定義された情報モデルの使用は、出発点として定義されているため、継承と関係クラスの階層を拡張可能にすることができ、リレーショナルデータベースなどの他のタイプのポリシーリポジトリもこの情報を使用できます。
This document fits into the overall framework for representing, deploying, and managing policies being developed by the Policy Framework Working Group.
このドキュメントは、ポリシーフレームワークワーキンググループによって開発されているポリシーを表現、展開、および管理するための全体的なフレームワークに適合します。
The LDAP schema described in this document uses the prefix "pcim" to identify its classes and attributes. It consists of ten very general classes: pcimPolicy (an abstract class), three policy group classes (pcimGroup, pcimGroupAuxClass, and pcimGroupInstance), three policy rule classes (pcimRule, pcimRuleAuxClass, and pcimRuleInstance), and three special auxiliary classes (pcimConditionAuxClass, pcimTPCAuxClass, and pcimActionAuxClass). (Note that the PolicyTimePeriodCondition auxiliary class defined in [1] would normally have been named pcimTimePeriodConditionAuxClass, but this name is too long for some directories. Therefore, we have abbreviated this name to be pcimTPCAuxClass).
このドキュメントで説明されているLDAPスキーマは、プレフィックス「PCIM」を使用してクラスと属性を識別します。、およびpcimactionauxclass）。（[1]で定義されているPolicyTimeperiodConditionの補助クラスは通常、pcimtimeperiodConditionauxclassと呼ばれていますが、この名前は一部のディレクトリには長すぎます。したがって、この名前をpcimtpcauxclassと略しています）。
The mapping for the PCIM classes pcimGroup and pcimRule is designed to be as flexible as possible. Three classes are defined for these two PCIM classes. First, an abstract superclass is defined that contains all required properties of each PCIM class. Then, both an auxiliary class as well as a structural class are derived from the abstract superclass. This provides maximum flexibility for the developer.
PCIMクラスPCIMGROUPとPCIMRULEのマッピングは、可能な限り柔軟になるように設計されています。これら2つのPCIMクラスで3つのクラスが定義されています。まず、各PCIMクラスのすべての必要なプロパティを含む抽象的なスーパークラスが定義されています。次に、補助クラスと構造クラスの両方が、抽象的なスーパークラスから派生します。これにより、開発者に最大限の柔軟性が得られます。
The schema also contains two less general classes: pcimConditionVendorAuxClass and pcimActionVendorAuxClass. To achieve the mapping of the information model's relationships, the schema also contains two auxiliary classes: pcimGroupContainmentAuxClass and pcimRuleContainmentAuxClass. Capturing the distinction between rule-specific and reusable policy conditions and policy actions introduces seven other classes: pcimRuleConditionAssociation, pcimRuleValidityAssociation, pcimRuleActionAssociation, pcimPolicyInstance, and three policy repository classes (pcimRepository, pcimRepositoryAuxClass, and pcimRepositoryInstance). Finally, the schema includes two classes (pcimSubtreesPtrAuxClass and pcimElementAuxClass) for optimizing LDAP retrievals. In all, the schema contains 23 classes.
スキーマには、PCIMConditionVendorauxClassとPCIMACTIONVENDORAUXCLASSの2つの一般的なクラスも含まれています。情報モデルの関係のマッピングを実現するために、スキーマには2つの補助クラスも含まれています：pcimgroupContainmentauxclassとpcimrulecontainmentclass。ルール固有のポリシー条件と再利用可能なポリシー条件とポリシーアクションの区別をキャプチャすると、PCIMRULECONDITIONASSOCIATION、PCIMRULEVALIATIONASSOCIATION、PCIMRULEACTIONACTIONASOCIATION、PCIMREPOLITITIORY、およびPCIMREPOSITORY CLASSE（PCIMREPOSITORYOXCLASS、およびPCIMREPOSIOTIORITIORINTANCE）の7つのクラスが導入されます。最後に、スキーマには、LDAP検索を最適化するための2つのクラス（PCIMSUBTREESPTRAUXCLASSとPCIMELEMENEMENTAUXCLASS）が含まれています。全体として、スキーマには23のクラスが含まれています。
Within the context of this document, the term "PCLS" (Policy Core LDAP Schema) is used to refer to the LDAP class definitions that this document contains. The term "PCIM" refers to classes defined in [1].
このドキュメントのコンテキスト内で、「PCLS」という用語（ポリシーコアLDAPスキーマ）を使用して、このドキュメントに含まれるLDAPクラスの定義を参照します。「PCIM」という用語は、[1]で定義されているクラスを指します。
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 [10].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [10]に記載されているように解釈される。
This document contains an LDAP schema representing the classes defined in the companion document "Policy Core Information Model -- Version 1 Specification" [1]. Other documents may subsequently be produced, with mappings of this same PCIM to other storage technologies. Since the detailed semantics of the PCIM classes appear only in [1], that document is a prerequisite for reading and understanding this document.
このドキュメントには、コンパニオンドキュメント「ポリシーコア情報モデル - バージョン1仕様」[1]で定義されているクラスを表すLDAPスキーマが含まれています。その後、他のドキュメントが作成される場合があり、この同じPCIMのマッピングが他のストレージテクノロジーにマッピングされます。PCIMクラスの詳細なセマンティクスは[1]にのみ表示されるため、そのドキュメントはこのドキュメントを読んで理解するための前提条件です。
The following diagram illustrates the class hierarchy for the LDAP Classes defined in this document:
次の図は、このドキュメントで定義されているLDAPクラスのクラス階層を示しています。
top
|
+--dlm1ManagedElement (abstract)
| |
| +--pcimPolicy (abstract)
| | |
| | +--pcimGroup (abstract)
| | | |
| | | +--pcimGroupAuxClass (auxiliary)
| | | |
| | | +--pcimGroupInstance (structural)
| | |
| | +--pcimRule (abstract)
| | | |
| | | +--pcimRuleAuxClass (auxiliary)
| | | |
| | | +--pcimRuleInstance (structural)
| | |
| | +--pcimRuleConditionAssociation (structural)
| | |
| | +--pcimRuleValidityAssociation (structural)
| | |
| | +--pcimRuleActionAssociation (structural)
| | |
| | +--pcimPolicyInstance (structural)
| | |
| | +--pcimElementAuxClass (auxiliary)
| |
| +--dlm1ManagedSystemElement (abstract)
| |
| +--dlm1LogicalElement (abstract)
| |
| +--dlm1System (abstract)
| |
| +--dlm1AdminDomain (abstract)
| |
| +--pcimRepository (abstract)
| |
| +--pcimRepositoryAuxClass (auxiliary)
top
| |
| +--pcimRepositoryInstance
| (structural)
|
+--pcimConditionAuxClass (auxiliary)
| |
| +---pcimTPCAuxClass (auxiliary)
| |
| +---pcimConditionVendorAuxClass (auxiliary)
|
+--pcimActionAuxClass (auxiliary)
| |
| +---pcimActionVendorAuxClass (auxiliary)
|
+--pcimSubtreesPtrAuxClass (auxiliary)
|
+--pcimGroupContainmentAuxClass (auxiliary)
|
+--pcimRuleContainmentAuxClass (auxiliary)
Figure 1. LDAP Class Inheritance Hierarchy for the PCLS
図1. PCLSのLDAPクラス継承階層
The classes described in Section 5 below contain certain optimizations for a directory that uses LDAP as its access protocol. One example of this is the use of auxiliary classes to represent some of the associations defined in the information model. Other data stores might need to implement these associations differently. A second example is the introduction of classes specifically designed to optimize retrieval of large amounts of policy-related data from a directory. This section discusses some general topics related to the mapping from the information model to LDAP.
以下のセクション5で説明するクラスには、LDAPをアクセスプロトコルとして使用するディレクトリの特定の最適化が含まれています。この一例は、情報モデルで定義されている関連付けの一部を表すために補助クラスを使用することです。他のデータストアは、これらの関連付けを異なる方法で実装する必要がある場合があります。2番目の例は、ディレクトリから大量のポリシー関連データの検索を最適化するために特別に設計されたクラスの導入です。このセクションでは、情報モデルからLDAPへのマッピングに関連するいくつかの一般的なトピックについて説明します。
The remainder of this section will discuss the following topics. Section 4.1 will discuss the strategy used in mapping the classes and associations defined in [1] to a form that can be represented in a directory that uses LDAP as its access protocol. Section 4.2 discusses DIT content and structure rules, as well as name forms. Section 4.3 describes the strategy used in defining naming attributes for the schema described in Section 5 of this document. Section 4.4 defines the strategy recommended for locating and retrieving PCIM-derived objects in the directory.
このセクションの残りの部分では、次のトピックについて説明します。セクション4.1では、[1]で定義されているクラスとアソシエーションのマッピングで使用される戦略について、LDAPをアクセスプロトコルとして使用するディレクトリに表すことができるフォームに説明します。セクション4.2では、DITコンテンツと構造のルール、および名前フォームについて説明します。セクション4.3では、このドキュメントのセクション5で説明したスキーマの命名属性の定義に使用される戦略について説明します。セクション4.4は、ディレクトリ内のPCIM由来のオブジェクトを見つけて取得するために推奨される戦略を定義します。
Fifteen of the classes in the PCLS come directly from the nine corresponding classes in the information model. Note that names of classes begin with an upper case character in the information model (although for CIM in particular, case is not significant in class and property names), but with a lower case character in LDAP. This is because although LDAP doesn't care, X.500 doesn't allow class names to begin with an uppercase character. Note also that the prefix "pcim" is used to identify these LDAP classes.
PCLSのクラスの15は、情報モデルの9つの対応するクラスから直接届きます。クラスの名前は、情報モデルの大文字の文字から始まることに注意してください（特にCIMの場合、クラスおよびプロパティ名ではケースは重要ではありません）が、LDAPの小文字のキャラクターであることに注意してください。これは、LDAPは気にしないが、X.500でクラス名が大文字で始まることを許可していないためです。また、プレフィックス「PCIM」を使用して、これらのLDAPクラスを識別することに注意してください。
+---------------------------+-------------------------------+
| Information Model | LDAP Class(es) |
+---------------------------+-------------------------------+
+---------------------------+-------------------------------+
| Policy | pcimPolicy |
+---------------------------+-------------------------------+
| PolicyGroup | pcimGroup |
| | pcimGroupAuxClass |
| | pcimGroupInstance |
+---------------------------+-------------------------------+
| PolicyRule | pcimRule |
| | pcimRuleAuxClass |
| | pcimRuleInstance |
+---------------------------+-------------------------------+
| PolicyCondition | pcimConditionAuxClass |
+---------------------------+-------------------------------+
| PolicyAction | pcimActionAuxClass |
+---------------------------+-------------------------------+
| VendorPolicyCondition | pcimConditionVendorAuxClass |
+---------------------------+-------------------------------+
| VendorPolicyAction | pcimActionVendorAuxClass |
+---------------------------+-------------------------------+
| PolicyTimePeriodCondition | pcimTPCAuxClass |
+---------------------------+-------------------------------+
| PolicyRepository | pcimRepository |
| | pcimRepositoryAuxClass |
| | pcimRepositoryInstance |
+---------------------------+-------------------------------+
Figure 2. Mapping of Information Model Classes to LDAP
図2. LDAPへの情報モデルクラスのマッピング
The associations in the information model map to attributes that reference DNs (Distinguished Names) or to Directory Information Tree (DIT) containment (i.e., superior-subordinate relationships) in LDAP. Two of the attributes that reference DNs appear in auxiliary classes, which allow each of them to represent several relationships from the information model.
情報モデルの関連付けは、LDAPのDNS（著名な名前）またはディレクトリ情報ツリー（DIT）封じ込め（つまり、上位の関係）を参照する属性にマップします。DNSを参照する2つの属性が補助クラスに表示され、それぞれが情報モデルからいくつかの関係を表すことができます。
+----------------------------------+----------------------------------+
| Information Model Association | LDAP Attribute / Class |
+-----------------------------------+---------------------------------+
+-----------------------------------+---------------------------------+
| PolicyGroupInPolicyGroup | pcimGroupsAuxContainedSet in |
| | pcimGroupContainmentAuxClass |
+-----------------------------------+---------------------------------+
| PolicyRuleInPolicyGroup | pcimRulesAuxContainedSet in |
| | pcimRuleContainmentAuxClass |
+-----------------------------------+---------------------------------+
| PolicyConditionInPolicyRule | DIT containment or |
| | pcimRuleConditionList in |
| | pcimRule or |
| | pcimConditionDN in |
| | pcimRuleConditionAssociation |
+-----------------------------------+---------------------------------+
| PolicyActionInPolicyRule | DIT containment or |
| | pcimRuleActionList in |
| | pcimRule or |
| | pcimActionDN in |
| | pcimRuleActionAssociation |
+-----------------------------------+---------------------------------+
| PolicyRuleValidityPeriod | pcimRuleValidityPeriodList |
| | in pcimRule or (if reusable) |
| | referenced through the |
| | pcimTimePeriodConditionDN in |
| | pcimRuleValidityAssociation |
+-----------------------------------+---------------------------------+
| PolicyConditionInPolicyRepository | DIT containment |
+-----------------------------------+---------------------------------+
| PolicyActionInPolicyRepository | DIT containment |
+-----------------------------------+---------------------------------+
| PolicyRepositoryInPolicyRepository| DIT containment |
+-----------------------------------+---------------------------------+
Figure 3. Mapping of Information Model Associations to LDAP
図3. LDAPへの情報モデル関連のマッピング
Of the remaining classes in the PCLS, two (pcimElementAuxClass and pcimSubtreesPtrAuxClass) are included to make navigation through the DIT and retrieval of the entries found there more efficient. This topic is discussed below in Section 4.5.
PCLSの残りのクラスのうち、2つ（pcimelementauxclassとpcimsubtreesptrauxclass）が含まれており、より効率的であると見つかったエントリのDITと検索をナビゲーションにします。このトピックについては、セクション4.5で説明します。
The remaining four classes in the PCLS, pcimRuleConditionAssociation, pcimRuleValidityAssociation, pcimRuleActionAssociation, and pcimPolicyInstance, are all involved with the representation of policy conditions and policy actions in an LDAP directory. This topic is discussed below in Section 4.4.
PCLSの残りの4つのクラス、PCIMRULECONDITIONASSOCIATION、PCIMRULEVALISITION ASSOCIATION、PCIMRULEACTIONATIONASOCIATION、およびPCIMPOLICOLYINSTANCEはすべて、LDAPディレクトリのポリシー条件とポリシーアクションの表現に関与しています。このトピックについては、以下でセクション4.4で説明します。
There are three powerful tools that can be used to help define schemata. The first, DIT content rules, is a way of defining the content of an entry for a structural object class. It can be used to specify the following characteristics of the entry:
スキーマの定義を支援するために使用できる3つの強力なツールがあります。最初のDITコンテンツルールは、構造オブジェクトクラスのエントリのコンテンツを定義する方法です。エントリの次の特性を指定するために使用できます。
- additional mandatory attributes that the entries are required to contain - additional optional attributes the entries are allowed to contain - the set of additional auxiliary object classes that these entries are allowed to be members of - any optional attributes from the structural and auxiliary object class definitions that the entries are required to preclude
- エントリに含める必要がある追加の必須属性 - 追加のオプション属性が含まれている追加のオプション属性 - これらのエントリが許可されている追加の補助オブジェクトクラスのセット - 構造および補助オブジェクトクラス定義のオプションの属性は、エントリは排除するために必要です
DIT content rules are NOT mandatory for any structural object class.
DITコンテンツルールは、構造オブジェクトクラスでは必須ではありません。
A DIT structure rule, together with a name form, controls the placement and naming of an entry within the scope of a subschema. Name forms define which attribute type(s) are required and are allowed to be used in forming the Relative Distinguished Names (RDNs) of entries. DIT structure rules specify which entries are allowed to be superior to other entries, and hence control the way that RDNs are added together to make DNs.
DIT構造ルールは、名前フォームとともに、補助の範囲内でのエントリの配置と命名を制御します。名前フォームは、どの属性タイプが必要かを定義し、エントリの相対的な識別名（RDN）を形成する際に使用することができます。DIT構造ルールは、どのエントリが他のエントリよりも優れているかを指定するため、RDNが一緒に追加されてDNSを作成する方法を制御します。
A name form specifies the following:
名前のフォームは、次を指定します。
- the structural object class of the entries named by this name form - attributes that are required to be used in forming the RDNs of these entries - attributes that are allowed to be used in forming the RDNs of these entries - an object identifier to uniquely identify this name form
- この名前フォームで指定されたエントリの構造オブジェクトクラス - これらのエントリのRDNを形成する際に使用する必要がある属性 - これらのエントリのRDNを形成する際に使用できる属性 - これを一意に識別するオブジェクト識別子名前フォーム
Note that name forms can only be specified for structural object classes. However, every entry in the DIT must have a name form controlling it.
名前フォームは、構造オブジェクトクラスにのみ指定できることに注意してください。ただし、DITのすべてのエントリには、それを制御する名前の形式が必要です。
Unfortunately, current LDAP servers vary quite a lot in their support of these features. There are also three crucial implementation points that must be followed. First, X.500 use of structure rules requires that a structural object class with no superior structure rule be a subschema administrative point. This is exactly NOT what we want for policy information. Second, when an auxiliary class is subclassed, if a content rule exists for the structural class that the auxiliary class refers to, then that content rule needs to be augmented. Finally, most LDAP servers unfortunately do not support inheritance of structure and content rules.
残念ながら、現在のLDAPサーバーは、これらの機能をサポートすることで非常に大きく異なります。また、3つの重要な実装ポイントを守る必要があります。まず、x.500構造ルールの使用には、優れた構造ルールのない構造オブジェクトクラスがサブセマの管理ポイントであることが必要です。これは、ポリシー情報に必要なものではありません。第二に、補助クラスがサブクラス化されている場合、補助クラスが言及する構造クラスに対してコンテンツルールが存在する場合、そのコンテンツルールを拡張する必要があります。最後に、ほとんどのLDAPサーバーは、残念ながら、構造とコンテンツルールの継承をサポートしていません。
Given these concerns, DIT structure and content rules have been removed from the PCLS. This is because, if included, they would be normative references and would require OIDs. However, we don't want to lose the insight gained in building the structure and content rules of the previous version of the schema. Therefore, we describe where such rules could be used in this schema, what they would control, and what their effect would be.
これらの懸念を考慮して、DIT構造とコンテンツルールはPCLSから削除されました。これは、含まれている場合、それらは規範的な参照であり、OIDを必要とするためです。ただし、スキーマの以前のバージョンの構造ルールとコンテンツルールを構築する際に得られた洞察を失いたくありません。したがって、このようなルールがこのスキーマのどこで使用できるか、それらが何を制御するか、そしてそれらの効果が何であるかを説明します。
Instances in a directory are identified by distinguished names (DNs), which provide the same type of hierarchical organization that a file system provides in a computer system. A distinguished name is a sequence of RDNs. An RDN provides a unique identifier for an instance within the context of its immediate superior, in the same way that a filename provides a unique identifier for a file within the context of the folder in which it resides.
ディレクトリ内のインスタンスは、ファイルシステムがコンピューターシステムで提供するのと同じタイプの階層組織を提供するDistinguished Names（DNS）によって識別されます。著名な名前は、RDNのシーケンスです。RDNは、ファイル名が存在するフォルダーのコンテキスト内のファイルに一意の識別子を提供するのと同じように、即時の上司のコンテキスト内でインスタンスに一意の識別子を提供します。
To preserve maximum naming flexibility for policy administrators, three optional (i.e., "MAY") naming attributes have been defined. They are:
ポリシー管理者の最大の命名柔軟性を維持するために、3つのオプション（つまり、「5月」）の命名属性が定義されています。彼らです：
- Each of the structural classes defined in this schema has its own unique ("MAY") naming attribute. Since the naming attributes are different, a policy administrator can, by using these attributes, guarantee that there will be no name collisions between instances of different classes, even if the same value is assigned to the instances' respective naming attributes.
- このスキーマで定義されている各構造クラスには、独自のユニークな（「5月」）ネーミング属性があります。命名属性は異なるため、ポリシー管理者は、これらの属性を使用することにより、同じ値がインスタンスのそれぞれの命名属性に割り当てられていても、異なるクラスのインスタンス間に名前の衝突がないことを保証できます。
- The LDAP attribute cn (corresponding to X.500's commonName) is included as a MAY attribute in the abstract class pcimPolicy, and thus by inheritance in all of its subclasses. In X.500, commonName typically functions as an RDN attribute, for naming instances of many classes (e.g., X.500's person class).
- LDAP属性CN（X.500のCommonNameに対応）は、抽象クラスPCIMPOLICYの5月属性として含まれ、したがってそのすべてのサブクラスの継承によって含まれています。X.500では、一般的に多くのクラスのインスタンスを命名するために、一般的にNameはRDN属性として機能します（例：X.500の人クラス）。
- A special attribute is provided for implementations that expect to map between native CIM and LDAP representations of policy information. This attribute, called orderedCimKeys, is defined in the class dlm1ManagedElement [6]. The value of this attribute is derived algorithmically from values that are already present in a CIM policy instance. The normative reference for this algorithm is contained in [6]. See the appendix of this document for a description of the algorithm.
- ポリシー情報のネイティブCIM表現とLDAP表現の間でマッピングすることを期待する実装に特別な属性が提供されます。OrderedCimkeysと呼ばれるこの属性は、クラスDLM1ManagedElement [6]で定義されています。この属性の値は、CIMポリシーインスタンスにすでに存在する値からアルゴリズム的に導出されます。このアルゴリズムの規範的参照は[6]に含まれています。アルゴリズムの説明については、このドキュメントの付録を参照してください。
Since any of these naming attributes MAY be used for naming an instance of a PCLS class, implementations MUST be able to accommodate instances named in any of these ways.
これらの命名属性のいずれかは、PCLSクラスのインスタンスを命名するために使用される可能性があるため、実装はこれらの方法で名前が付けられたインスタンスに対応できる必要があります。
Note that it is recommended that two or more of these attributes SHOULD NOT be used together to form a multi-part RDN, since support for multi-part RDNs is limited among existing directory implementations.
マルチパートRDNのサポートは既存のディレクトリ実装の中で制限されるため、これらの属性の2つ以上をマルチパートRDNを形成するために一緒に使用しないことをお勧めします。
The PCIM [1] distinguishes between two types of policy conditions and policy actions: those associated with a single policy rule, and those that are reusable, in the sense that they may be associated with more than one policy rule. While there is no inherent functional difference between a rule-specific condition or action and a reusable one, there is both a usage, as well as, an implementation difference between them.
PCIM [1]は、2つのタイプのポリシー条件とポリシーアクションを区別します。単一のポリシールールに関連するものと、複数のポリシールールに関連付けられる可能性があるという意味で、再利用可能なものです。ルール固有の条件やアクションと再利用可能な条件の間には固有の機能の違いはありませんが、それらの間には使用法と実装の違いの両方があります。
Defining a condition or action as reusable vs. rule-specific reflects a conscious decision on the part of the administrator in defining how they are used. In addition, there are variations that reflect implementing rule-specific vs. reusable policy conditions and actions and how they are treated in a policy repository. The major implementation differences between a rule-specific and a reusable condition or action are delineated below:
条件またはアクションを再利用可能なものとして定義することとルール固有のものは、使用方法を定義する際に、管理者側の意識的な決定を反映しています。さらに、ルール固有と再利用可能なポリシー条件と行動の実装を反映したバリエーションがあり、それらがポリシーリポジトリでどのように扱われるかを反映しています。ルール固有の条件または再利用可能な条件またはアクションの主要な実装の違いを以下に示します。
1. It is natural for a rule-specific condition or action to be removed from the policy repository at the same time the rule is. It is just the opposite for reusable conditions and actions. This is because the condition or action is conceptually attached to the rule in the rule-specific case, whereas it is referenced (e.g., pointed at) in the reusable case. The persistence of a pcimRepository instance is independent of the persistence of a pcimRule instance. 2. Access permissions for a rule-specific condition or action are usually identical to those for the rule itself. On the other hand, access permissions of reusable conditions and actions must be expressible without reference to a policy rule. 3. Rule-specific conditions and actions require fewer accesses, because the conditions and actions are "attached" to the rule. In contrast, reusable conditions and actions require more accesses, because each condition or action that is reusable requires a separate access. 4. Rule-specific conditions and actions are designed for use by a single rule. As the number of rules that use the same rule-specific condition increase, subtle problems are created (the most obvious being how to keep the rule-specific conditions and actions updated to reflect the same value). Reusable conditions and actions lend themselves for use by multiple independent rules. 5. Reusable conditions and actions offer an optimization when multiple rules are using the same condition or action. This is because the reusable condition or action only needs be updated once, and by virtue of DN reference, the policy rules will be automatically updated.
1. ルール固有の条件またはアクションが、ルールと同時にポリシーリポジトリから削除されることは自然です。再利用可能な条件と行動の正反対です。これは、条件またはアクションがルール固有のケースのルールに概念的に添付されているのに対し、再利用可能な場合に参照される（例えば、指摘された）ためです。PCIMREPOSITORYインスタンスの持続性は、PCIMRULEインスタンスの持続性とは無関係です。2.ルール固有の条件またはアクションのアクセス権限は、通常、ルール自体のアクセスと同じです。一方、再利用可能な条件とアクションのアクセス許可は、ポリシールールを参照せずに表現する必要があります。3.ルール固有の条件とアクションは、条件とアクションがルールに「添付」されるため、より少ないアクセスが必要です。対照的に、再利用可能な条件とアクションには、再利用可能な各条件またはアクションには個別のアクセスが必要であるため、より多くのアクセスが必要です。4.ルール固有の条件とアクションは、単一のルールによって使用するために設計されています。同じルール固有の条件を使用するルールの数が増加すると、微妙な問題が作成されます（最も明白なのは、同じ値を反映するように更新されるルール固有の条件とアクションを維持する方法です）。再利用可能な条件と行動は、複数の独立したルールによって使用されるようになります。5.複数のルールが同じ条件またはアクションを使用している場合、再利用可能な条件とアクションは最適化を提供します。これは、再利用可能な条件またはアクションを1回だけ更新する必要があり、DNリファレンスにより、ポリシールールが自動的に更新されるためです。
The preceding paragraph does not contain an exhaustive list of the ways in which reusable and rule-specific conditions should be treated differently. Its purpose is merely to justify making a semantic distinction between rule-specific and reusable, and then reflecting this distinction in the policy repository itself.
前の段落には、再利用可能なルール固有の条件を異なる方法で扱うべき方法の徹底的なリストは含まれていません。その目的は、ルール固有と再利用可能なものを意味的に区別することを正当化し、ポリシーリポジトリ自体にこの区別を反映することを正当化することです。
When the policy repository is realized in an LDAP-accessible directory, the distinction between rule-specific and reusable conditions and actions is realized via placement of auxiliary classes and via DIT containment. Figure 4 illustrates a policy rule Rule1 with one rule-specific condition CA and one rule-specific action AB.
ポリシーリポジトリがLDAPアクセス可能なディレクトリで実現されると、ルール固有の条件と再利用可能な条件とアクションの区別が、補助クラスの配置とDIT封じ込めによって実現されます。図4は、1つのルール固有の条件CAと1つのルール固有のアクションABを持つポリシールールルール1を示しています。
+-----+
|Rule1|
| |
+-----|- -|-----+
| +-----+ |
| * * |
| * * |
| **** **** |
| * * |
v * * v
+--------+ +--------+
| CA+ca | | AB+ab |
+--------+ +--------+
+------------------------------+
|LEGEND: |
| ***** DIT containment |
| + auxiliary attachment |
| ----> DN reference |
+------------------------------+
Figure 4 Rule-Specific Policy Conditions and Actions
図4ルール固有のポリシー条件とアクション
Because the condition and action are specific to Rule1, the auxiliary classes ca and ab that represent them are attached, respectively, to the structural classes CA and AB. These structural classes represent not the condition ca and action ab themselves, but rather the associations between Rule1 and ca, and between Rule1 and ab.
条件とアクションはRule1に固有であるため、それらを表す補助クラスCAおよびABは、それぞれ構造クラスCAおよびABに添付されています。これらの構造クラスは、条件CAおよびアクションAB自体ではなく、Rule1とCaの間、およびRule1とABの間の関連性を表します。
As Figure 4 illustrates, Rule1 contains DN references to the structural classes CA and AB that appear below it in the DIT. At first glance it might appear that these DN references are unnecessary, since a subtree search below Rule1 would find all of the structural classes representing the associations between Rule1 and its conditions and actions. Relying only on a subtree search, though, runs the risk of missing conditions or actions that should have appeared in the subtree, but for some reason did not, or of finding conditions or actions that were inadvertently placed in the subtree, or that should have been removed from the subtree, but for some reason were not. Implementation experience has suggested that many (but not all) of these risks are eliminated.
図4に示すように、Rule1には、DITの下に表示される構造クラスCAおよびABへのDN参照が含まれています。一見すると、これらのDN参照は不要であるように見えるかもしれません。なぜなら、Rule1以下のサブツリー検索では、Rule1とその条件とアクションの間の関連性を表すすべての構造クラスが見つかるからです。ただし、サブツリー検索のみに依存すると、サブツリーに表示されるはずの条件やアクションが欠落しているリスクがありますが、何らかの理由で、サブツリーに不注意に配置された条件やアクションを見つける、またはサブツリーから削除されましたが、何らかの理由でそうではありませんでした。実装の経験は、これらのリスクの多く（すべてではない）が排除されることを示唆しています。
However, it must be noted that this comes at a price. The use of DN references, as shown in Figure 4 above, thwarts inheritance of access control information as well as existence dependency information. It also is subject to referential integrity considerations. Therefore, it is being included as an option for the designer.
ただし、これには価格があることに注意する必要があります。上記の図4に示すように、DN参照の使用は、アクセス制御情報の継承と存在の依存情報を阻止します。また、参照整合性の考慮事項の対象となります。したがって、それはデザイナーのオプションとして含まれています。
Figure 5 illustrates a second way of representing rule-specific conditions and actions in an LDAP-accessible directory: attachment of the auxiliary classes directly to the instance representing the policy rule. When all of the conditions and actions are attached to a policy rule in this way, the rule is termed a "simple" policy rule. When conditions and actions are not attached directly to a policy rule, the rule is termed a "complex" policy rule.
図5は、LDAPアクセス可能なディレクトリでのルール固有の条件とアクションを表す2番目の方法を示しています。これは、ポリシールールを表すインスタンスに直接補助クラスを添付します。この方法ですべての条件とアクションがポリシールールに添付されている場合、ルールは「単純な」ポリシールールと呼ばれます。条件とアクションがポリシールールに直接添付されていない場合、ルールは「複雑な」ポリシールールと呼ばれます。
+-----------+
|Rule1+ca+ab|
| |
+-----------+
+------------------------------+
|LEGEND: |
| + auxiliary attachment |
+------------------------------+
Figure 5. A Simple Policy Rule
図5.単純なポリシールール
The simple/complex distinction for a policy rule is not all or nothing. A policy rule may have its conditions attached to itself and its actions attached to other entries, or it may have its actions attached to itself and its conditions attached to other entries. However, it SHALL NOT have either its conditions or its actions attached both to itself and to other entries, with one exception: a policy rule may reference its validity periods with the pcimRuleValidityPeriodList attribute, but have its other conditions attached to itself.
ポリシールールの単純/複雑な区別は、すべてまたは何もないわけではありません。ポリシールールには、その条件がそれ自体に付随し、他のエントリに添付されている条件がある場合があります。そうしないと、それ自体に添付されているアクションと他のエントリに添付されている場合があります。ただし、1つの例外を除いて、その条件またはそのアクションの両方に添付されているものと他のエントリの両方に添付されてはなりません。ポリシールールは、PCIMRULEVALISITYPERISTERIODLIST属性でその有効期間を参照する場合がありますが、それ自体に他の条件が付属しています。
The tradeoffs between simple and complex policy rules are between the efficiency of simple rules and the flexibility and greater potential for reuse of complex rules. With a simple policy rule, the semantic options are limited:
単純なポリシールールと複雑なポリシールールの間のトレードオフは、単純なルールの効率性と柔軟性と複雑なルールの再利用の可能性の強化の間にあります。単純なポリシールールでは、セマンティックオプションは制限されています。
- All conditions are ANDed together. This combination can be represented in two ways in the Disjunctive Normal Form (DNF)/ Conjunctive Normal Form (CNF) (please see [1] for definitions of these terms) expressions characteristic of policy conditions: as a DNF expression with a single AND group, or as a CNF expression with multiple single-condition OR groups. The first of these is arbitrarily chosen as the representation for the ANDed conditions in a simple policy rule.
- すべての条件は一緒にandedです。この組み合わせは、分野の正常形式（DNF）/接続詞正常形式（CNF）で2つの方法で表現できます（これらの用語の定義については[1]を参照）ポリシー条件に特徴的な式：単一およびグループのDNF式として、または複数の単一条件またはグループを使用したCNF式として。これらの最初のものは、単純な政策規則におけるANDED条件の表現としてarbitrarily意的に選択されます。
- If multiple actions are included, no order can be specified for them.
- 複数のアクションが含まれている場合、それらには注文を指定できません。
If a policy administrator needs to combine conditions in some other way, or if there is a set of actions that must be ordered, then the only option is to use a complex policy rule.
ポリシー管理者が他の方法で条件を組み合わせる必要がある場合、または注文する必要がある一連のアクションがある場合、唯一のオプションは複雑なポリシールールを使用することです。
Finally, Figure 6 illustrates the same policy rule Rule1, but this time its condition and action are reusable. The association classes CA and AB are still present, and they are still DIT contained under Rule1. But rather than having the auxiliary classes ca and ab attached directly to the association classes CA and AB, each now contains DN references to other entries to which these auxiliary classes are attached. These other entries, CIA and AIB, are DIT contained under RepositoryX, which is an instance of the class pcimRepository. Because they are named under an instance of pcimRepository, ca and ab are clearly identified as reusable.
最後に、図6は同じポリシールール規則1を示していますが、今回はその条件とアクションが再利用可能です。Association Classe CAとABはまだ存在していますが、それらはまだ規則1に含まれています。しかし、AssociationクラスCAおよびABに直接接続されている補助クラスCAとABを使用するのではなく、それぞれにこれらの補助クラスが添付されている他のエントリへのDN参照が含まれています。これらの他のエントリであるCIAとAIBは、クラスPCIMREPositoryのインスタンスであるRepositoryxの下に含まれています。それらはPCIMREPositoryのインスタンスで命名されているため、CAおよびABは再利用可能であると明確に識別されます。
+-----+ +-------------+
|Rule1| | RepositoryX |
+-|- -|--+ | |
| +-----+ | +-------------+
| * * | * *
| * * | * *
| *** **** | * *
| * * v * *
| * +---+ * *
| * |AB | +------+ *
v * | -|-------->|AIB+ab| *
+---+ +---+ +------+ *
|CA | +------+
| -|------------------------>|CIA+ca|
+---+ +------+
+------------------------------+
|LEGEND: |
| ***** DIT containment |
| + auxiliary attachment |
| ----> DN reference |
+------------------------------+
Figure 6. Reusable Policy Conditions and Actions
図6.再利用可能な政策条件と行動
The classes pcimConditionAuxClass and pcimActionAuxClass do not themselves represent actual conditions and actions: these are introduced in their subclasses. What pcimConditionAuxClass and pcimActionAuxClass do introduce are the semantics of being a policy condition or a policy action. These are the semantics that all the subclasses of pcimConditionAuxClass and pcimActionAuxClass inherit. Among these semantics are those of representing either a rule-specific or a reusable policy condition or policy action.
PCIMCONDITIONAUXCLASSとPCIMACTIONAUXCLASSクラス自体は、実際の条件とアクションを表しているわけではありません。これらはサブクラスに導入されています。Pcimconditionauxclassとpcimactionauxclassが導入するのは、ポリシー条件またはポリシーアクションであるというセマンティクスです。これらは、pcimconditionauxclassとpcimactionauxclassのすべてのサブクラスが継承するというセマンティクスです。これらのセマンティクスの中には、ルール固有または再利用可能なポリシー条件またはポリシーアクションを表すものがあります。
In order to preserve the ability to represent a rule-specific or a reusable condition or action, as well as a simple policy rule, all the subclasses of pcimConditionAuxClass and pcimActionAuxClass MUST also be auxiliary classes.
ルール固有または再利用可能な条件またはアクションを表す能力、および単純なポリシールールを維持するには、PCIMConditionAuxClassとPCIMACTIONAUXCLASSのすべてのサブクラスも補助クラスでなければなりません。
When a Policy Decision Point (PDP) goes to an LDAP directory to retrieve the policy object instances relevant to the Policy Enforcement Points (PEPs) it serves, it is faced with two related problems:
ポリシー決定ポイント（PDP）がLDAPディレクトリに移動して、ポリシー執行ポイント（PEP）に関連するポリシーオブジェクトインスタンスを取得すると、2つの関連する問題があります。
- How does it locate and retrieve the directory entries that apply to its PEPs? These entries may include instances of the PCLS classes, instances of domain-specific subclasses of these classes, and instances of other classes modeling such resources as user groups, interfaces, and address ranges.
- PEPに適用されるディレクトリエントリをどのように見つけて取得しますか？これらのエントリには、PCLSクラスのインスタンス、これらのクラスのドメイン固有のサブクラスのインスタンス、およびユーザーグループ、インターフェイス、アドレス範囲などのリソースをモデル化する他のクラスのインスタンスが含まれます。
- How does it retrieve the directory entries it needs in an efficient manner, so that retrieval of policy information from the directory does not become a roadblock to scalability? There are two facets to this efficiency: retrieving only the relevant directory entries, and retrieving these entries using as few LDAP calls as possible.
- ディレクトリエントリが効率的に必要な方法でどのように取得し、ディレクトリからポリシー情報の取得がスケーラビリティへの障害にならないようにしますか？この効率には2つのファセットがあります。関連するディレクトリエントリのみを取得し、できるだけ少ないLDAP呼び出しを使用してこれらのエントリを取得することです。
The placement of objects in the Directory Information Tree (DIT) involves considerations other than how the policy-related objects will be retrieved by a PDP. Consequently, all that the PCLS can do is to provide a "toolkit" of classes to assist the policy administrator as the DIT is being designed and built. A PDP SHOULD be able to take advantage of any tools that the policy administrator is able to build into the DIT, but it MUST be able to use a less efficient means of retrieval if that is all it has available to it.
ディレクトリ情報ツリー（DIT）へのオブジェクトの配置には、ポリシー関連のオブジェクトがPDPによって取得される方法以外の考慮事項が含まれます。その結果、PCLSができることは、DITが設計および構築されているときにポリシー管理者を支援するためにクラスの「ツールキット」を提供することです。PDPは、ポリシー管理者がDITに組み込むことができるツールを利用できるはずですが、それが利用可能である場合、より効率的でない検索手段を使用できる必要があります。
The basic idea behind the LDAP optimization classes is a simple one: make it possible for a PDP to retrieve all the policy-related objects it needs, and only those objects, using as few LDAP calls as possible. An important assumption underlying this approach is that the policy administrator has sufficient control over the underlying DIT structure to define subtrees for storing policy information. If the policy administrator does not have this level of control over DIT structure, a PDP can still retrieve the policy-related objects it needs individually. But it will require more LDAP access operations to do the retrieval in this way. Figure 7 illustrates how LDAP optimization is accomplished.
LDAP Optimizationクラスの背後にある基本的なアイデアは、簡単なものです。PDPが必要なすべてのポリシー関連オブジェクトを取得できるようにし、できるだけ少ないLDAP呼び出しを使用して、それらのオブジェクトのみを取得できます。このアプローチの根底にある重要な仮定は、ポリシー管理者が、ポリシー情報を保存するためのサブツリーを定義するために、基礎となるDIT構造を十分に制御していることです。ポリシー管理者がDIT構造に対するこのレベルの制御を持っていない場合、PDPは個別に必要なポリシー関連のオブジェクトを取得できます。ただし、この方法で検索を行うには、より多くのLDAPアクセス操作が必要になります。図7は、LDAPの最適化がどのように達成されるかを示しています。
+-----+
---------------->| A |
DN reference to | | DN references to subtrees +---+
starting object +-----+ +-------------------------->| C |
| o--+----+ +---+ +---+
| o--+------------->| B | / \
+-----+ +---+ / \
/ \ / \ / ... \
/ \ / \
/ \ / ... \
Figure 7. Using the pcimSubtreesPtrAuxClass to Locate Policies
図7. PCIMSUBTREESPTRAUXCLASSを使用してポリシーを見つけます
The PDP is configured initially with a DN reference to some entry in the DIT. The structural class of this entry is not important; the PDP is interested only in the pcimSubtreesPtrAuxClass attached to it. This auxiliary class contains a multi-valued attribute with DN references to objects that anchor subtrees containing policy-related objects of interest to the PDP. Since pcimSubtreesPtrAuxClass is an auxiliary class, it can be attached to an entry that the PDP would need to access anyway - perhaps an entry containing initial configuration settings for the PDP, or for a PEP that uses the PDP.
PDPは、DITのいくつかのエントリへのDN参照で最初に構成されます。このエントリの構造クラスは重要ではありません。PDPは、接続されているPCIMSubTreesPtrauxclassにのみ興味があります。この補助クラスには、PDPに関心のあるポリシー関連のオブジェクトを含むサブツリーをアンカーするオブジェクトへのDN参照を含む多値の属性が含まれています。pcimsubtreesptrauxclassは補助クラスであるため、とにかくPDPがアクセスする必要があるというエントリに添付できます - おそらくPDPの初期構成設定を含むエントリ、またはPDPを使用するPEP。
Once it has retrieved the DN references, the PDP will direct to each of the objects identified by them an LDAP request that all entries in its subtree be evaluated against the selection criteria specified in the request. The LDAP-enabled directory then returns all entries in that subtree that satisfy the specified criteria.
DN参照を取得すると、PDPは、リクエストで指定された選択基準に対してサブツリー内のすべてのエントリを評価するというLDAPリクエストを識別した各オブジェクトに向けます。LDAP対応ディレクトリは、指定された基準を満たすサブツリーのすべてのエントリを返します。
The selection criteria always specify that object class="pcimPolicy". Since all classes representing policy rules, policy conditions, and policy actions, both in the PCLS and in any domain-specific schema derived from it, are subclasses of the abstract class policy, this criterion evaluates to TRUE for all instances of these classes. To accommodate special cases where a PDP needs to retrieve objects that are not inherently policy-related (for example, an IP address range object referenced by a subclass of pcimActionAuxClass representing the DHCP action "assign from this address range"), the auxiliary class pcimElementAuxClass can be used to "tag" an entry, so that it will be found by the selection criterion "object class=pcimPolicy".
選択基準は、常にObject class = "pcimpolicy"を指定します。PCLSおよびそれから派生したドメイン固有のスキーマの両方で、ポリシールール、ポリシー条件、およびポリシーアクションを表すすべてのクラスは、抽象クラスポリシーのサブクラスであるため、この基準はこれらのクラスのすべてのインスタンスに対して真実を評価します。PDPが本質的にポリシーに関連していないオブジェクトを取得する必要がある特別なケースに対応するために（たとえば、「このアドレス範囲から割り当てられている」DHCPアクションを表すPCIMACTIONAUXCLASSのサブクラスによって参照されるIPアドレス範囲オブジェクト）、補助クラスpcimelementauxclassエントリを「タグ」するために使用できます。これにより、選択基準「Object class = pcimpolicy」によって見つかります。
The approach described in the preceding paragraph will not work for certain directory implementations, because these implementations do not support matching of auxiliary classes in the objectClass attribute. For environments where these implementations are expected to be present, the "tagging" of entries as relevant to policy can be accomplished by inserting the special value "POLICY" into the list of values contained in the pcimKeywords attribute (provided by the pcimPolicy class).
前の段落で説明されているアプローチは、特定のディレクトリの実装では機能しません。これらの実装は、ObjectClass属性の補助クラスのマッチングをサポートしていないためです。これらの実装が存在すると予想される環境の場合、ポリシーに関連するエントリの「タグ付け」は、PCIMKEYWORDS属性（PCIMPOLICYクラスが提供する）に含まれる値のリストに「ポリシー」を挿入することで実現できます。
If a PDP needs only a subset of the policy-related objects in the indicated subtrees, then it can be configured with additional selection criteria based on the pcimKeywords attribute defined in the pcimPolicy class. This attribute supports both standardized and administrator- defined values. For example, a PDP could be configured to request only those policy-related objects containing the keywords "DHCP" and "Eastern US".
PDPが示されたサブツリーのポリシー関連オブジェクトのサブセットのみを必要とする場合、PCIMPOLICYクラスで定義されたPCIMKEYWORDS属性に基づいて追加の選択基準で構成できます。この属性は、標準化された値と管理者定義値の両方をサポートします。たとえば、キーワード「DHCP」と「東部米国」を含むポリシー関連のオブジェクトのみを要求するようにPDPを構成できます。
To optimize what is expected to be a typical case, the initial request from the client includes not only the object to which its "seed" DN references, but also the subtree contained under this object. The filter for searching this subtree is whatever the client is going to use later to search the other subtrees: object class="pcimPolicy" or the presence of the keyword "POLICY", and/or presence of a more specific value of pcimKeywords (e.g., "QoS Edge Policy").
典型的なケースになると予想されるものを最適化するために、クライアントからの最初の要求には、「シード」DN参照が含まれるオブジェクトだけでなく、このオブジェクトの下に含まれるサブツリーも含まれます。このサブツリーを検索するためのフィルターは、クライアントが他のサブツリーを検索するために後で使用するものは何でもあります：オブジェクトクラス= "pcimpolicy"またはキーワードの存在「ポリシー」、および/またはpcimkeywordsのより具体的な値の存在（例：、「QoS Edgeポリシー」）。
Returning to the example in Figure 7, we see that in the best case, a PDP can get all the policy-related objects it needs, and only those objects, with exactly three LDAP requests: one to its starting object A to get the references to B and C, as well as the policy-related objects it needs from the subtree under A, and then one each to B and C to get all the policy-related objects that pass the selection criteria with which it was configured. Once it has retrieved all of these objects, the PDP can then traverse their various DN references locally to understand the semantic relationships among them. The PDP should also be prepared to find a reference to another subtree attached to any of the objects it retrieves, and to follow this reference first, before it follows any of the semantically significant references it has received. This recursion permits a structured approach to identifying related policies. In Figure 7, for example, if the subtree under B includes departmental policies and the one under C includes divisional policies, then there might be a reference from the subtree under C to an object D that roots the subtree of corporate-level policies.
図7の例に戻ると、最良の場合には、PDPが必要なすべてのポリシー関連オブジェクトを取得できることがわかります。BとC、およびAの下のサブツリーから必要なポリシー関連のオブジェクト、およびそれぞれがBとCに必要なオブジェクトが、構成された選択基準を渡すすべてのポリシー関連オブジェクトを取得します。これらすべてのオブジェクトを取得すると、PDPはさまざまなDN参照をローカルに通過して、それらの間のセマンティック関係を理解できます。また、PDPは、取得するオブジェクトのいずれかに接続されている別のサブツリーへの参照を見つける準備をし、最初にこの参照に従って、それが受け取った意味的に重要な参照のいずれかに従う前に、この参照に従う必要があります。この再帰により、関連するポリシーを特定するための構造化されたアプローチが可能になります。たとえば、図7では、Bの下のサブツリーに部門のポリシーが含まれており、Cの下のサブツリーが部門ポリシーを含む場合、Cの下のサブツリーから企業レベルのポリシーのサブツリーをルートするオブジェクトDへの参照がある場合があります。
A PDP SHOULD understand the pcimSubtreesPtrAuxClass class, SHOULD be capable of retrieving and processing the entries in the subtrees it references, and SHOULD be capable of doing all of this recursively. The same requirements apply to any other entity needing to retrieve policy information from the directory. Thus, a Policy Management Tool that retrieves policy entries from the directory in order to perform validation and conflict detection SHOULD also understand and be capable of using the pcimSubtreesPtrAuxClass. All of these requirements are "SHOULD"s rather than "MUST"s because an LDAP client that doesn't implement them can still access and retrieve the directory entries it needs. The process of doing so will just be less efficient than it would have been if the client had implemented these optimizations.
PDPは、PCIMSubTreesPtrauxClassクラスを理解し、参照するサブツリーのエントリを取得および処理できる必要があり、これをすべて再帰的に行うことができる必要があります。同じ要件は、ディレクトリからポリシー情報を取得する必要がある他のエンティティに適用されます。したがって、検証と競合の検出を実行するためにディレクトリからポリシーエントリを取得するポリシー管理ツールは、PCIMSubTreesPtrauxclassを理解し、使用できる必要があります。これらの要件はすべて、「必須」ではなく「正しい」です。なぜなら、それらを実装しないLDAPクライアントは、必要なディレクトリエントリにアクセスして取得できるからです。そうするプロセスは、クライアントがこれらの最適化を実装した場合よりも効率が低くなります。
When it is serving as a tool for creating policy entries in the directory, a Policy Management Tool SHOULD support creation of pcimSubtreesPtrAuxClass entries and their references to object instances.
ディレクトリにポリシーエントリを作成するためのツールとして機能する場合、ポリシー管理ツールは、PCIMSUBTREESPTRAUXCLASSエントリの作成とオブジェクトインスタンスへの参照をサポートする必要があります。
Additional flexibility in DIT structure is available to the policy administrator via LDAP aliasing and other techniques. Previous versions of this document have used aliases. However, because aliases are experimental, the use of aliases has been removed from this version of this document. This is because the IETF has yet to produce a specification on how aliases are represented in the directory or how server implementations are to process aliases.
DIT構造の追加の柔軟性は、LDAPエイリアシングおよびその他の手法を介して、ポリシー管理者が利用できます。このドキュメントの以前のバージョンでは、エイリアスを使用しています。ただし、エイリアスは実験的であるため、このドキュメントのこのバージョンからエイリアスの使用が削除されました。これは、IETFがディレクトリ内でエイリアスの表現方法やサーバーの実装がエイリアスを処理する方法に関する仕様をまだ作成していないためです。
The semantics for the policy information classes that are to be mapped directly from the information model to an LDAP representation are detailed in [1]. Consequently, all that this document presents for these classes is the specification for how to do the mapping from the information model (which is independent of repository type and access protocol) to a form that can be accessed using LDAP. Remember that some new classes needed to be created (that were not part of [1]) to implement the LDAP mapping. These new LDAP-only classes are fully documented in this document.
情報モデルからLDAP表現に直接マッピングするポリシー情報クラスのセマンティクスについては、[1]に詳しく説明しています。したがって、これらのクラスにこのドキュメントが提示するのは、情報モデル（リポジトリタイプとアクセスプロトコルとは無関係）からLDAPを使用してアクセスできるフォームにマッピングを行う方法の仕様です。LDAPマッピングを実装するには、いくつかの新しいクラスを作成する必要がある（[1]の一部ではなかった）ことを忘れないでください。これらの新しいLDAPのみのクラスは、このドキュメントに完全に文書化されています。
The formal language for specifying the classes, attributes, and DIT structure and content rules is that defined in reference [3]. If your implementation does not support auxiliary class inheritance, you will have to list auxiliary classes in content rules explicitly or define them in another (implementation-specific) way.
クラス、属性、およびDIT構造およびコンテンツルールを指定するための正式な言語は、参照で定義されているものです[3]。実装が補助クラスの継承をサポートしていない場合、コンテンツルールの補助クラスを明示的にリストするか、別の（実装固有の）方法で定義する必要があります。
The following notes apply to this section in its entirety.
次のメモは、このセクション全体に適用されます。
Note 1: in the following definitions, the class and attribute definitions follow RFC 2252 [3] but they are line-wrapped to enhance human readability.
注1：次の定義では、クラスと属性の定義はRFC 2252 [3]に従いますが、それらは人間の読みやすさを高めるためにラインで包まれています。
Note 2: where applicable, the possibilities for specifying DIT structure and content rules are noted. However, care must be taken in specifying DIT structure rules. This is because X.501 [4] states that an entry may only exist in the DIT as a subordinate to another superior entry (the superior) if a DIT structure rule exists in the governing subschema which:
注2：該当する場合、DIT構造とコンテンツルールを指定する可能性が記載されています。ただし、DIT構造ルールを指定する際には注意が必要です。これは、X.501 [4]が、DIT構造ルールが支配的な補助法に存在する場合、エントリは別の優れたエントリ（上位）の下位としてのみDITに存在する可能性があると述べているためです。
1) indicates a name form for the structural object class of the subordinate entry, and 2) either includes the entry's superior structure rule as a possible superior structure rule, or 3) does not specify a superior structure rule.
1) 下位エントリの構造オブジェクトクラスの名前形式を示し、2）エントリの優れた構造ルールを可能な優れた構造ルールとして含めるか、3）は優れた構造ルールを指定しません。
If this last case (3) applies, then the entry is defined to be a subschema administrative point. This is not what is desired. Therefore, care must be taken in defining structure rules, and in particular, they must be locally augmented.
この最後のケース（3）が適用される場合、エントリは補助的な管理ポイントであると定義されます。これは望ましいものではありません。したがって、構造規則を定義する際には注意が必要です。特に、それらは局所的に増強されなければなりません。
Note 3: Wherever possible, both an equality and a substring matching rule are defined for a particular attribute (as well as an ordering match rule to enable sorting of matching results). This provides two different choices for the developer for maximum flexibility.
注3：可能な限り、特定の属性（およびマッチング結果の並べ替えを可能にする順序付けマッチルール）に対して、平等とサブストリングマッチングルールの両方が定義されます。これにより、最大限の柔軟性を得るために、開発者に2つの異なる選択肢が提供されます。
For example, consider the pcimRoles attribute (section 5.3). Suppose that a PEP has reported that it is interested in pcimRules for three roles R1, R2, and R3. If the goal is to minimize queries, then the PDP can supply three substring filters containing the three role names.
たとえば、pcimroles属性（セクション5.3）を考慮してください。PEPが3つの役割R1、R2、およびR3のPCimrulesに関心があると報告していると仮定します。目標がクエリを最小限に抑えることである場合、PDPは3つのロール名を含む3つのサブストリングフィルターを提供できます。
These queries will return all of the pcimRules that apply to the PEP, but they may also get some that do not apply (e.g., ones that contain one of the roles R1, R2, or R3 and one or more other roles present in a role-combination [1]).
これらのクエリは、PEPに適用されるすべてのPCIMRULEを返しますが、適用されないもの（例えば、R1、R2、またはR3の1つを含むもの、および役割に存在する1つ以上の他の役割が含まれます。-combination [1]）。
Another strategy would be for the PDP to use only equality filters. This approach eliminates the extraneous replies, but it requires the PDP to explicitly build the desired role-combinations itself. It also requires extra queries. Note that this approach is practical only because the role names in a role combination are required to appear in alphabetical order.
別の戦略は、PDPが等式フィルターのみを使用することです。このアプローチは外部応答を排除しますが、PDPが目的のロールコンビネーション自体を明示的に構築する必要があります。また、追加のクエリが必要です。このアプローチは、役割の組み合わせにおける役割名がアルファベット順に表示されるために必要であるために実用的であることに注意してください。
Note 4: in the following definitions, note that all LDAP matching rules are defined in [3] and in [9]. The corresponding X.500 matching rules are defined in [8].
注4：次の定義では、すべてのLDAPマッチングルールは[3]および[9]で定義されていることに注意してください。対応するX.500マッチングルールは[8]で定義されています。
Note 5: some of the following attribute definitions specify additional constraints on various data types (e.g., this integer has values that are valid from 1..10). Text has been added to instruct servers and applications what to do if a value outside of this range is encountered. In all cases, if a constraint is violated, then the policy rule SHOULD be treated as being disabled, meaning that execution of the policy rule SHOULD be stopped.
注5：次の属性定義の一部は、さまざまなデータ型に追加の制約を指定しています（たとえば、この整数には1..10から有効な値があります）。この範囲の外側の値が発生した場合に何をすべきかをサーバーとアプリケーションに指示するためにテキストが追加されました。すべての場合において、制約が違反されている場合、ポリシールールは無効になっていると扱われるべきです。つまり、ポリシールールの実行を停止する必要があります。
The abstract class pcimPolicy is a direct mapping of the abstract class Policy from the PCIM. The class value "pcimPolicy" is also used as the mechanism for identifying policy-related instances in the Directory Information Tree. An instance of any class may be "tagged" with this class value by attaching to it the auxiliary class pcimElementAuxClass. Since pcimPolicy is derived from the class dlm1ManagedElement defined in reference [6], this specification has a normative dependency on that element of reference [6].
抽象クラスPCIMPOLICYYは、PCIMからの抽象クラスポリシーの直接マッピングです。クラス値「pcimpolicy」は、ディレクトリ情報ツリー内のポリシー関連のインスタンスを識別するメカニズムとしても使用されます。任意のクラスのインスタンスは、補助クラスのPCIMELEMENTAUXCLASSに接続することにより、このクラス値で「タグ付け」される場合があります。Pcimpolicyは参照[6]で定義されているクラスDLM1ManagedElementから派生しているため、この仕様は参照要素[6]に規範的依存性があります。
The class definition is as follows:
クラスの定義は次のとおりです。
( 1.3.6.1.1.6.1.1 NAME 'pcimPolicy' DESC 'An abstract class that is the base class for all classes that describe policy-related instances.' SUP dlm1ManagedElement ABSTRACT MAY ( cn $ dlmCaption $ dlmDescription $ orderedCimKeys $ pcimKeywords ) )
（1.3.6.1.1.6.1.1.1名「Pcimpolicy 'desc」は、ポリシー関連のインスタンスを説明するすべてのクラスの基本クラスである抽象クラスです。
The attribute cn is defined in RFC 2256 [7]. The dlmCaption, dlmDescription, and orderedCimKeys attributes are defined in [6].
属性CNはRFC 2256 [7]で定義されています。dlmcaption、dlmdescription、およびorderedcimkeys属性は[6]で定義されています。
The pcimKeywords attribute is a multi-valued attribute that contains a set of keywords to assist directory clients in locating the policy objects identified by these keywords. It is defined as follows:
PCIMKEYWORDS属性は、これらのキーワードで識別されたポリシーオブジェクトをディレクトリクライアントを見つけるのを支援するためのキーワードのセットを含む多値の属性です。次のように定義されています。
( 1.3.6.1.1.6.2.3 NAME 'pcimKeywords' DESC 'A set of keywords to assist directory clients in locating the policy objects applicable to them.' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
（1.3.6.1.1.6.2.3名「pcimkeywords 'desc」'キーワードのセット。ディレクトリクライアントがそれらに適用されるポリシーオブジェクトを見つけるのを支援する。））
PCIM [1] defines the PolicyGroup class to serve as a generalized aggregation mechanism, enabling PolicyRules and/or PolicyGroups to be aggregated together. PCLS maps this class into three LDAP classes, called pcimGroup, pcimGroupAuxClass, and pcimGroupInstance. This is done in order to provide maximum flexibility for the DIT designer.
PCIM [1]は、ポリシーグループのクラスを一般化された集合メカニズムとして定義し、Policyrulesおよび/またはPolicyGroupを一緒に集約できるようにします。PCLSは、このクラスをPCIMGROUP、PCIMGROUPAUXCLASS、およびPCIMGROPINSTANCEと呼ばれる3つのLDAPクラスにマッピングします。これは、DITデザイナーに最大限の柔軟性を提供するために行われます。
The class definitions for the three policy group classes are listed below. These class definitions do not include attributes to realize the PolicyRuleInPolicyGroup and PolicyGroupInPolicyGroup associations from the PCIM. This is because a pcimGroup object refers to instances of pcimGroup and pcimRule via, respectively, the attribute pcimGroupsAuxContainedSet in the pcimGroupContainmentAuxClass object class and the attribute pcimRulesAuxContainedSet in the pcimRuleContainmentAuxClass object class.
3つのポリシーグループクラスのクラス定義を以下に示します。これらのクラスの定義には、PCIMからのPolicyRuleinPolicyGroupおよびPolicyGroupinPolicyGroup Associationを実現するための属性は含まれていません。これは、PCIMGROUPオブジェクトがPCIMGROUPとPCIMRULEのインスタンスを、PCIMGROUPCONTAINMENTMENTCLASSオブジェクトクラスの属性PCIMGROUPSAUXCONTENSESTとPCIMRULULULESAUXCONTENSESTの属性PCIMGROUPSAUXCONTENSESTをそれぞれ指すためです。
To maximize flexibility, the pcimGroup class is defined as abstract. The subclass pcimGroupAuxClass provides for auxiliary attachment to another entry, while the structural subclass pcimGroupInstance is available to represent a policy group as a standalone entry.
柔軟性を最大化するために、PCIMGROUPクラスは抽象として定義されます。サブクラスPCIMGROUPOUPAUXCLASSは、別のエントリへの補助的なアタッチメントを提供しますが、構造的なサブクラスPCIMGROUPINSTANCEは、ポリシーグループをスタンドアロンエントリとして表すために利用できます。
The class definitions are as follows. First, the definition of the abstract class pcimGroup:
クラスの定義は次のとおりです。まず、抽象クラスPCIMGROUPの定義：
( 1.3.6.1.1.6.1.2 NAME 'pcimGroup' DESC 'A container for a set of related pcimRules and/or a set of related pcimGroups.' SUP pcimPolicy ABSTRACT MAY ( pcimGroupName ) )
（1.3.6.1.1.6.1.2名「pcimgroup」desc '関連するPCimrulesおよび/または関連するPCimgroupsのセットのコンテナ。
The one attribute of pcimGroup is pcimGroupName. This attribute is used to define a user-friendly name of this policy group, and may be used as a naming attribute if desired. It is defined as follows:
PCIMGROUPの属性の1つはPCIMGROUPNAMEです。この属性は、このポリシーグループのユーザーフレンドリーな名前を定義するために使用され、必要に応じて命名属性として使用できます。次のように定義されています。
( 1.3.6.1.1.6.2.4 NAME 'pcimGroupName' DESC 'The user-friendly name of this policy group.' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
（1.3.6.1.1.6.2.4 name 'pcimgroupname' desc 'このポリシーグループのユーザーフレンドリーな名前。
The two subclasses of pcimGroup are defined as follows. The class pcimGroupAuxClass is an auxiliary class that can be used to collect a set of related pcimRule and/or pcimGroup classes. It is defined as follows:
PCIMGROUPの2つのサブクラスは、次のように定義されています。クラスPCIMGROUPAUXCLASSは、関連するPCIMRULEおよび/またはPCIMGROUPクラスのセットを収集するために使用できる補助クラスです。次のように定義されています。
( 1.3.6.1.1.6.1.3 NAME 'pcimGroupAuxClass' DESC 'An auxiliary class that collects a set of related pcimRule and/or pcimGroup entries.' SUP pcimGroup AUXILIARY )
（1.3.6.1.1.6.1.3名「PCIMGROUPAUXCLASS」DESC '関連するPCIMRULEおよび/またはPCIMGROUPエントリのセットを収集する補助クラス。
The class pcimGroupInstance is a structural class that can be used to collect a set of related pcimRule and/or pcimGroup classes. It is defined as follows:
クラスPCIMGROUPINSTANCEは、関連するPCIMRULEおよび/またはPCIMGROUPクラスのセットを収集するために使用できる構造クラスです。次のように定義されています。
( 1.3.6.1.1.6.1.4 NAME 'pcimGroupInstance' DESC 'A structural class that collects a set of related pcimRule and/or pcimGroup entries.' SUP pcimGroup STRUCTURAL )
（1.3.6.1.1.6.1.4 name 'pcimgroupinstance' desc '関連するPCimruleおよび/またはpcimgroupエントリのセットを収集する構造クラス。
A DIT content rule could be written to enable an instance of pcimGroupInstance to have attached to it either references to one or more policy groups (using pcimGroupContainmentAuxClass) or references to one or more policy rules (using pcimRuleContainmentAuxClass). This would be used to formalize the semantics of the PolicyGroup class [1]. Since these semantics do not include specifying any properties of the PolicyGroup class, the content rule would not need to specify any attributes.
DITコンテンツルールは、PCIMGroupInstanceのインスタンスが1つまたは複数のポリシーグループ（PCIMGROUPCONTAINMENTMENTAUXCLASSを使用）への参照または1つまたは複数のポリシールール（PCIMRULECONTANMENTMENTAUXCLASSを使用）への参照のいずれかを添付できるようにするために作成できます。これは、ポリシーグループクラス[1]のセマンティクスを正式化するために使用されます。これらのセマンティクスには、ポリシーグループクラスのプロパティの指定は含まれていないため、コンテンツルールは属性を指定する必要はありません。
Similarly, three separate DIT structure rules could be written, each of which would refer to a specific name form that identified one of the three possible naming attributes (i.e., pcimGroupName, cn, and orderedCIMKeys) for the pcimGroup object class. This structure rule SHOULD include a superiorStructureRule (see Note 2 at the beginning of section 5). The three name forms referenced by the three structure rules would each define one of the three naming attributes.
同様に、3つの個別のDIT構造ルールを記述できます。それぞれは、PCIMGROUPオブジェクトクラスの3つの可能な命名属性（つまり、PCIMGROUPNAME、CN、およびOrderedCimkeys）のいずれかを識別する特定の名前フォームを参照します。この構造規則には、上層構造を含める必要があります（セクション5の開始の注2を参照）。3つの構造ルールで参照される3つの名前フォームは、それぞれ3つの命名属性のいずれかを定義します。
The information model defines a PolicyRule class to represent the "If Condition then Action" semantics associated with processing policy information. For maximum flexibility, the PCLS maps this class into three LDAP classes.
情報モデルは、ポリシー情報の処理に関連付けられた「条件thenアクション」セマンティクスを表すために、policyruleクラスを定義します。柔軟性を最大限に活用するために、PCLSはこのクラスを3つのLDAPクラスにマッピングします。
To maximize flexibility, the pcimRule class is defined as abstract. The subclass pcimRuleAuxClass provides for auxiliary attachment to another entry, while the structural subclass pcimRuleInstance is available to represent a policy rule as a standalone entry.
柔軟性を最大化するために、PCimruleクラスは抽象として定義されます。サブクラスのpcimruleauxclassは、別のエントリへの補助的な添付ファイルを提供しますが、構造的なサブクラスpcimruleinstanceは、ポリシールールをスタンドアロンエントリとして表すために利用できます。
The conditions and actions associated with a policy rule are modeled, respectively, with auxiliary subclasses of the auxiliary classes pcimConditionAuxClass and pcimActionAuxClass. Each of these auxiliary subclasses is attached to an instance of one of three structural classes. A subclass of pcimConditionAuxClass is attached to an instance of pcimRuleInstance, to an instance of pcimRuleConditionAssociation, or to an instance of pcimPolicyInstance. Similarly, a subclass of pcimActionAuxClass is attached to an instance of pcimRuleInstance, to an instance of pcimRuleActionAssociation, or to an instance of pcimPolicyInstance.
ポリシールールに関連する条件とアクションは、それぞれ補助クラスpcimconditionauxclassおよびpcimactionauxclassの補助サブクラスを使用してモデル化されています。これらの補助サブクラスはそれぞれ、3つの構造クラスのいずれかの1つに添付されています。pcimconditionauxclassのサブクラスは、pcimruleinstanceのインスタンス、pcimruleconditionasociationのインスタンス、またはpcimpolicyinstanceのインスタンスに接続されています。同様に、PCIMACTIONAUXCLASSのサブクラスは、PCIMRULEINSTANCEのインスタンス、PCIMRULEACTIONACTIONASOCIATIONのインスタンス、またはPCIMPOLICYINSTANCEのインスタンスに接続されています。
The pcimRuleValidityPeriodList attribute (defined below) realizes the PolicyRuleValidityPeriod association defined in the PCIM. Since this association has no additional properties besides those that tie the association to its associated objects, this association can be realized by simply using an attribute. Thus, the pcimRuleValidityPeriodList attribute is simply a multi-valued attribute that provides an unordered set of DN references to one or more instances of the pcimTPCAuxClass, indicating when the policy rule is scheduled to be active and when it is scheduled to be inactive. A policy rule is scheduled to be active if it is active according to AT LEAST ONE of the pcimTPCAuxClass instances referenced by this attribute.
PCIMRULEVALIDITIONPERIODLIST属性（以下に定義）は、PCIMで定義されているPolicyrulevalidityPeridioD Associationを実現します。この関連付けには、関連するオブジェクトに関連するプロパティ以外に追加のプロパティがないため、この関連付けは属性を使用するだけで実現できます。したがって、PCIMRULEVALIDITYPERIODLIST属性は、PCIMTPCAUXCLASSの1つまたは複数のインスタンスにDN参照の順序付けられていないセットを提供する単なる多値属性であり、ポリシールールがアクティブにスケジュールされ、いつ非アクティブになるかを示します。この属性が参照されているPCIMTPCAUXCLASSインスタンスの少なくとも1つに従ってアクティブである場合、ポリシールールがアクティブになるようにスケジュールされます。
The PolicyConditionInPolicyRule and PolicyActionInPolicyRule associations, however, do have additional attributes. The association PolicyActionInPolicyRule defines an integer attribute to sequence the actions, and the association PolicyConditionInPolicyRule has both an integer attribute to group the condition terms as well as a Boolean property to specify whether a condition is to be negated.
ただし、PolicyConditionInpolicyruleおよびPolication Inpolicyruleの関連付けには、追加の属性があります。Association Polication Inpolicyruleは、整数属性を定義してアクションをシーケンスし、Association PolicyConditionInpolicyruleの両方が条件用語をグループ化するための整数属性と、条件を否定するかどうかを指定するブールプロパティの両方を持っています。
In the PCLS, these additional association attributes are represented as attributes of two classes introduced specifically to model these associations. These classes are the pcimRuleConditionAssociation class and the pcimRuleActionAssociation class, which are defined in Sections 5.4 and 5.5, respectively. Thus, they do not appear as attributes of the class pcimRule. Instead, the pcimRuleConditionList and pcimRuleActionList attributes can be used to reference these classes.
PCLSでは、これらの追加の関連付け属性は、これらの関連付けをモデル化するために特別に導入された2つのクラスの属性として表されます。これらのクラスは、それぞれセクション5.4および5.5で定義されているPCIMRULECONDITIONASSOCIATIONクラスとPCIMRULEACTIONACTIONACOSOCIATIONクラスです。したがって、それらはクラスpcimruleの属性としては表示されません。代わりに、PCIMRULECONDITIONLISTおよびPCIMRULEACTIONLIST属性を使用して、これらのクラスを参照できます。
The class definitions for the three pcimRule classes are as follows.
3つのPCimruleクラスのクラス定義は次のとおりです。
The abstract class pcimRule is a base class for representing the "If Condition then Action" semantics associated with a policy rule. It is defined as follows:
抽象クラスPCIMRULEは、ポリシールールに関連付けられた「IF条件Thenアクション」セマンティクスを表すための基本クラスです。次のように定義されています。
( 1.3.6.1.1.6.1.5 NAME 'pcimRule' DESC 'The base class for representing the "If Condition then Action" semantics associated with a policy rule.' SUP pcimPolicy ABSTRACT MAY ( pcimRuleName $ pcimRuleEnabled $ pcimRuleConditionListType $ pcimRuleConditionList $ pcimRuleActionList $ pcimRuleValidityPeriodList $ pcimRuleUsage $ pcimRulePriority $ pcimRuleMandatory $ pcimRuleSequencedActions $ pcimRoles ) )
（1.3.6.1.1.6.1.5名「pcimrule」desc 'ポリシールールに関連する「If条件」セマンティクスを表すための基本クラス。$ pcimruleusage $ pcimrulepriority $ pcimrulemandatory $ pcimruleSequencedactions $ pcimroles））
The PCIM [1] defines seven properties for the PolicyRule class. The PCLS defines eleven attributes for the pcimRule class, which is the LDAP equivalent of the PolicyRule class. Of these eleven attributes, seven are mapped directly from corresponding properties in PCIM's PolicyRule class. The remaining four attributes are a class-specific optional naming attribute, and three attributes used to realize the three associations that the pcimRule class participates in.
PCIM [1]は、PolicyRuleクラスの7つのプロパティを定義します。PCLSは、PCimruleクラスの11の属性を定義します。これは、Policyruleクラスに相当するLDAPです。これらの11の属性のうち、7つはPCIMのPolicyruleクラスの対応するプロパティから直接マッピングされます。残りの4つの属性は、クラス固有のオプションの命名属性であり、PCIMRULEクラスが参加する3つの関連付けを実現するために使用される3つの属性です。
The pcimRuleName attribute is used as a user-friendly name of this policy rule, and can also serve as the class-specific optional naming attribute. It is defined as follows:
PCIMRULENAME属性は、このポリシールールのユーザーフレンドリーな名前として使用され、クラス固有のオプションのネーミング属性としても機能します。次のように定義されています。
( 1.3.6.1.1.6.2.5 NAME 'pcimRuleName' DESC 'The user-friendly name of this policy rule.' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
（1.3.6.1.1.6.2.5名「pcimrulename」desc 'このポリシールールのユーザーフレンドリーな名前。
The pcimRuleEnabled attribute is an integer enumeration indicating whether a policy rule is administratively enabled (value=1), administratively disabled (value=2), or enabled for debug (value=3). It is defined as follows:
PCimRureEnabled属性は、ポリシールールが管理上有効化（値= 1）、管理上無効化（値= 2）、またはデバッグ（値= 3）の有効であるかどうかを示す整数列挙です。次のように定義されています。
( 1.3.6.1.1.6.2.6 NAME 'pcimRuleEnabled' DESC 'An integer indicating whether a policy rule is administratively enabled (value=1), disabled (value=2), or enabled for debug (value=3).' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
（1.3.6.1.1.6.2.6 name 'pcimrureenabled' desc 'ポリシールールが管理的に有効になっているか（値= 1）、無効（値= 2）、またはデバッグの有効化（値= 3）かを示す整数。integerorderingmatch構文の注文1.3.6.1.4.1.1466.115.121.1.27単一価値）
Note: All other values for the pcimRuleEnabled attribute are considered errors, and the administrator SHOULD treat this rule as being disabled if an invalid value is found.
注：PCIMRUREENABLED属性の他のすべての値はエラーと見なされ、管理者は無効な値が見つかった場合、このルールを無効にしていると扱う必要があります。
The pcimRuleConditionListType attribute is used to indicate whether the list of policy conditions associated with this policy rule is in disjunctive normal form (DNF, value=1) or conjunctive normal form (CNF, value=2). It is defined as follows:
PCIMRULECONDITIONLISTTYPE属性は、このポリシールールに関連するポリシー条件のリストが、分離法の正常形態（DNF、値= 1）または接続的な正常形式（CNF、値= 2）であるかどうかを示すために使用されます。次のように定義されています。
( 1.3.6.1.1.6.2.7 NAME 'pcimRuleConditionListType' DESC 'A value of 1 means that this policy rule is in disjunctive normal form; a value of 2 means that this policy rule is in conjunctive normal form.' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
（1.3.6.1.1.1.6.2.7 name 'pcimruleconditionlisttype' desc '1の値は、このポリシールールが分離的な正常な形式であることを意味します。1.3.6.1.4.1.1466.115.121.1.27単一価値）
Note: any value other than 1 or 2 for the pcimRuleConditionListType attribute is considered an error. Administrators SHOULD treat this rule as being disabled if an invalid value is found, since it is unclear how to structure the condition list.
注：PCIMRULECONDITIONLISTTYPE属性の1または2以外の値は、エラーと見なされます。管理者は、条件リストを構成する方法が不明であるため、無効な値が見つかった場合、このルールを無効にしていると扱う必要があります。
The pcimRuleConditionList attribute is a multi-valued attribute that is used to realize the policyRuleInPolicyCondition association defined in [1]. It contains a set of DNs of pcimRuleConditionAssociation entries representing associations between this policy rule and its conditions. No order is implied. It is defined as follows:
PCIMRULECONDITIONLIST属性は、[1]で定義されているPolicyRuleinPolicyconcition Associationを実現するために使用される多検証属性です。これには、このポリシールールとその条件との関連性を表すPCIMRuleConditionAssociationエントリのDNSのセットが含まれています。注文は暗示されていません。次のように定義されています。
( 1.3.6.1.1.6.2.8 NAME 'pcimRuleConditionList' DESC 'Unordered set of DNs of pcimRuleConditionAssociation entries representing associations between this policy rule and its conditions.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
（1.3.6.1.1.6.2.8名 'PcimruleConditionList' DESC 'この政策規則とその条件との関連性を表すPCIMRULECONDITIONASSOCIATIONエントリのDNSのDNSの非注文セット。
The pcimRuleActionList attribute is a multi-valued attribute that is used to realize the policyRuleInPolicyAction association defined in [1]. It contains a set of DNs of pcimRuleActionAssociation entries representing associations between this policy rule and its actions. No order is implied. It is defined as follows:
PCIMRULEACTIONLIST属性は、[1]で定義されているPolicyRuleinPolicyAction Associationを実現するために使用される多値属性です。これには、このポリシールールとそのアクションとの関連性を表すPCIMRULEACTIONACTIONASOCIATIONエントリのDNSのセットが含まれています。注文は暗示されていません。次のように定義されています。
( 1.3.6.1.1.6.2.9 NAME 'pcimRuleActionList' DESC 'Unordered set of DNs of pcimRuleActionAssociation entries representing associations between this policy rule and its actions.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
（1.3.6.1.1.6.2.9名「PCIMRULEACTIONLIST」DESC 'この政策規則とその行動との関連性を表すPCIMRULEACTIONACTIONASOCIATIONエントリのDNSのDNSの順序付けられていないセット。
The pcimRuleValidityPeriodList attribute is a multi-valued attribute that is used to realize the pcimRuleValidityPeriod association that is defined in [1]. It contains a set of DNs of pcimRuleValidityAssociation entries that determine when the pcimRule is scheduled to be active or inactive. No order is implied. It is defined as follows:
PCIMRULEVALIDITITYPERIODLIST属性は、[1]で定義されているPCIMRULEVALITITIONPERISTIODPERIOD ASIONSを実現するために使用される多検証属性です。PCimruleがアクティブまたは非アクティブにスケジュールされている時期を決定するPCimrulevalidityAssociationエントリのDNSのセットが含まれています。注文は暗示されていません。次のように定義されています。
( 1.3.6.1.1.6.2.10 NAME 'pcimRuleValidityPeriodList' DESC 'Unordered set of DNs of pcimRuleValidityAssociation entries that determine when the pcimRule is scheduled to be active or inactive.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
（1.3.6.1.1.6.2.10名「PCIMRULEVALIDITYPERIDITYPERIODLIST」DSC 'PCIMRULEVALISITION ASSOCIATIONエントリのDNSのDNSの非注文セット。
The pcimRuleUsage attribute is a free-form string providing guidelines on how this policy should be used. It is defined as follows:
PCIMRULEUSAGE属性は、このポリシーの使用方法に関するガイドラインを提供するフリーフォーム文字列です。次のように定義されています。
( 1.3.6.1.1.6.2.11 NAME 'pcimRuleUsage' DESC 'This attribute is a free-form sting providing guidelines on how this policy should be used.' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
（1.3.6.1.1.1.6.2.11 name 'pcimruleusage' desc 'この属性は、このポリシーの使用方法に関するガイドラインを提供するフリーフォームスティングです。15単一価値）
The pcimRulePriority attribute is a non-negative integer that is used to prioritize this pcimRule relative to other pcimRules. A larger value indicates a higher priority. It is defined as follows:
PCIMRULEPRIORITY属性は、他のPCimruleと比較してこのPCimruleを優先するために使用される非陰性整数です。値が大きいほど優先度が高いことを示します。次のように定義されています。
( 1.3.6.1.1.6.2.12 NAME 'pcimRulePriority' DESC 'A non-negative integer for prioritizing this pcimRule relative to other pcimRules. A larger value indicates a higher priority.' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
（1.3.6.1.1.6.2.12名「pcimrulepriority 'desc」は、他のpcimrulesと比較してこのpcimruleに優先順位を付けるための非陰性整数です。より大きな値はより高い優先度を示します。121.1.27単一価値）
Note: if the value of the pcimRulePriority field is 0, then it SHOULD be treated as "don't care". On the other hand, if the value is negative, then it SHOULD be treated as an error and Administrators SHOULD treat this rule as being disabled.
注：PCIMRULEPRIORITYフィールドの値が0の場合、「気にしないでください」として扱う必要があります。一方、値が負の場合、エラーとして扱われ、管理者はこのルールを無効にしていると扱う必要があります。
The pcimRuleMandatory attribute is a Boolean attribute that, if TRUE, indicates that for this policy rule, the evaluation of its conditions and execution of its actions (if the condition is satisfied) is required. If it is FALSE, then the evaluation of its conditions and execution of its actions (if the condition is satisfied) is not required. This attribute is defined as follows:
PCIMRulemandatory属性は、真実の場合、このポリシールールでは、その条件の評価とそのアクションの実行（条件が満たされた場合）が必要であることを示すブール属性です。それが間違っている場合、その条件の評価とその行動の実行（条件が満たされている場合）は必要ありません。この属性は次のように定義されます。
( 1.3.6.1.1.6.2.13 NAME 'pcimRuleMandatory' DESC 'If TRUE, indicates that for this policy rule, the evaluation of its conditions and execution of its actions (if the condition is satisfied) is required.' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
（1.3.6.1.1.6.2.13名「pcimrulemandatory 'desc' 'trueの場合、このポリシールールでは、その条件の評価とそのアクションの実行（条件が満たされた場合）が必要であることを示します。6.1.4.1.1466.115.121.1.7単一価値）
The pcimRuleSequencedActions attribute is an integer enumeration that is used to indicate that the ordering of actions defined by the pcimActionOrder attribute is either mandatory(value=1), recommended(value=2), or dontCare(value=3). It is defined as follows:
PCIMRULESEQUENCENSEDACTIONS属性は、PCIMACTIONORDORDER属性によって定義されたアクションの順序付けが必須（値= 1）、推奨（値= 2）、またはDONTCARE（Value = 3）であることを示すために使用される整数列挙です。次のように定義されています。
( 1.3.6.1.1.6.2.14 NAME 'pcimRuleSequencedActions' DESC 'An integer enumeration indicating that the ordering of actions defined by the pcimActionOrder attribute is mandatory(1), recommended(2), or dontCare(3).' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
（1.3.6.1.1.6.2.14名「pcimrulesequencedions 'desc' 'pcimactionordory属性によって定義されたアクションの順序付けが必須（1）、推奨（2）、またはdontcare（3）が必須であることを示す整数列挙。構文1.3.6.1.4.1.1466.115.121.1.27単一価値）
Note: if the value of pcimRulesSequencedActions field is not one of these three values, then Administrators SHOULD treat this rule as being disabled.
注：PCIMRULESSEQUENCENGIONSフィールドの値がこれら3つの値のいずれかでない場合、管理者はこのルールを無効にしていると扱う必要があります。
The pcimRoles attribute represents the policyRoles property of [1]. Each value of this attribute represents a role-combination, which is a string of the form: <RoleName>[&&<RoleName>]* where the individual role names appear in alphabetical order according to the collating sequence for UCS-2. This attribute is defined as follows:
pcimroles属性は、[1]のPolicyroles特性を表します。この属性の各値は、フォームの文字列であるロールコンビネーションを表します。この属性は次のように定義されます。
( 1.3.6.1.1.6.2.15 NAME 'pcimRoles' DESC 'Each value of this attribute represents a role-combination.' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
（1.3.6.1.1.6.2.15名「pcimroles 'desc'この属性の各値はロールコンビネーションを表します。
Note: if the value of the pcimRoles attribute does not conform to the format "<RoleName>[&&<RoleName>]*" (see Section 6.3.7 of [1]), then this attribute is malformed and its policy rule SHOULD be treated as being disabled.
注：pcimroles属性の値がフォーマット "<rolename> [&& <rolename>]*"に準拠していない場合（[1]のセクション6.3.7を参照）、この属性は奇形であり、そのポリシールールは障害者として扱われます。
The two subclasses of the pcimRule class are defined as follows. First, the pcimRuleAuxClass is an auxiliary class for representing the "If Condition then Action" semantics associated with a policy rule. Its class definition is as follows:
PCimruleクラスの2つのサブクラスは、次のように定義されています。まず、PCIMRULEAUXCLASSは、ポリシールールに関連付けられた「IF条件Thenアクション」セマンティクスを表すための補助クラスです。そのクラスの定義は次のとおりです。
( 1.3.6.1.1.6.1.6 NAME 'pcimRuleAuxClass' DESC 'An auxiliary class for representing the "If Condition then Action" semantics associated with a policy rule.' SUP pcimRule AUXILIARY )
（1.3.6.1.1.6.6.1.6名「pcimruleauxclass 'desc'ポリシールールに関連付けられた「条件thenアクション」セマンティクスを表すための補助クラス。
The pcimRuleInstance is a structural class for representing the "If Condition then Action" semantics associated with a policy rule. Its class definition is as follows:
PCImruleInstanceは、ポリシールールに関連付けられた「IF条件Then Action」セマンティクスを表すための構造クラスです。そのクラスの定義は次のとおりです。
( 1.3.6.1.1.6.1.7 NAME 'pcimRuleInstance' DESC 'A structural class for representing the "If Condition then Action" semantics associated with a policy rule.'
（1.3.6.1.1.6.1.7名「pcimruleinstance」desc 'ポリシールールに関連付けられた「条件thenアクション」セマンティクスを表すための構造クラス。
SUP pcimRule STRUCTURAL )
sup pcimrule構造）
A DIT content rule could be written to enable an instance of pcimRuleInstance to have attached to it either references to one or more policy conditions (using pcimConditionAuxClass) or references to one or more policy actions (using pcimActionAuxClass). This would be used to formalize the semantics of the PolicyRule class [1]. Since these semantics do not include specifying any properties of the PolicyRule class, the content rule would not need to specify any attributes.
DITコンテンツルールは、PCImruleInstanceのインスタンスが1つまたは複数のポリシー条件（PCImConditionAuxClassを使用）への参照または1つ以上のポリシーアクション（PCIMACTIONAUXCLASSを使用）への参照のいずれかを添付できるようにするために書き込まれます。これは、Policyruleクラス[1]のセマンティクスを形式化するために使用されます。これらのセマンティクスには、PolicyRuleクラスのプロパティの指定は含まれていないため、コンテンツルールは属性を指定する必要はありません。
Similarly, three separate DIT structure rules could be written, each of which would refer to a specific name form that identified one of its three possible naming attributes (i.e., pcimRuleName, cn, and orderedCIMKeys). This structure rule SHOULD include a superiorStructureRule (see Note 2 at the beginning of section 5). The three name forms referenced by the three structure rules would each define one of the three naming attributes.
同様に、3つの個別のDIT構造ルールを記述できます。それぞれが、3つの可能な命名属性（つまり、PCIMRULENAME、CN、およびOrderedCimkeys）のいずれかを識別する特定の名前フォームを参照します。この構造規則には、上層構造を含める必要があります（セクション5の開始の注2を参照）。3つの構造ルールで参照される3つの名前フォームは、それぞれ3つの命名属性のいずれかを定義します。
This class contains attributes to represent the properties of the PCIM's PolicyConditionInPolicyRule association. Instances of this class are related to an instance of pcimRule via DIT containment. The policy conditions themselves are represented by auxiliary subclasses of the auxiliary class pcimConditionAuxClass. These auxiliary classes are attached directly to instances of pcimRuleConditionAssociation for rule-specific policy conditions. For a reusable policy condition, the policyCondition auxiliary subclass is attached to an instance of the class pcimPolicyInstance (which is presumably associated with a pcimRepository by DIT containment), and the policyConditionDN attribute (of this class) is used to reference the reusable policyCondition instance.
このクラスには、PCIMのPolicyConditionInpolicyrule Associationのプロパティを表すための属性が含まれています。このクラスのインスタンスは、DIT封じ込めによるPCimruleのインスタンスに関連しています。ポリシー条件自体は、補助クラスpcimconditionauxclassの補助サブクラスによって表されます。これらの補助クラスは、ルール固有のポリシー条件のためにPCIMRULECONDITIONASOCIATIONのインスタンスに直接添付されます。再利用可能なポリシー条件の場合、Policycondition Auxiliary Subclassは、クラスPcimpolicyInstance（おそらくDIT封じ込めによるPCimrepositoryに関連付けられている）のインスタンスに接続され、PolicyConditionDN属性（このクラス）が再利用可能なPolicyCondition Instanceを参照するために使用されます。
The class definition is as follows:
クラスの定義は次のとおりです。
( 1.3.6.1.1.6.1.8 NAME 'pcimRuleConditionAssociation' DESC 'This class contains attributes characterizing the relationship between a policy rule and one of its policy conditions.' SUP pcimPolicy MUST ( pcimConditionGroupNumber $ pcimConditionNegated ) MAY ( pcimConditionName $ pcimConditionDN ) )
（1.3.6.1.1.6.1.8名「PCIMRULECONDITIONASSOCIATION 'DESC」このクラスには、ポリシールールとそのポリシー条件の1つの関係を特徴付ける属性が含まれています。「PCIMCONDITIONGROILNUMBER $ PCIMCONDITIONNEGATED）
The attributes of this class are defined as follows.
このクラスの属性は、次のように定義されています。
The pcimConditionGroupNumber attribute is a non-negative integer. It is used to identify the group to which the condition referenced by this association is assigned. This attribute is defined as follows:
PCIMConditionGroupNumber属性は、非陰性整数です。これは、この関連付けによって参照される条件が割り当てられるグループを識別するために使用されます。この属性は次のように定義されます。
( 1.3.6.1.1.6.2.16 NAME 'pcimConditionGroupNumber' DESC 'The number of the group to which a policy condition belongs. This is used to form the DNF or CNF expression associated with a policy rule.' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
（1.3.6.1.1.6.2.16名「pcimconditiongroupNumber 'desc'ポリシー条件が属するグループの数。これは、ポリシールールに関連するDNFまたはCNF式を形成するために使用されます。6.1.4.1.1466.115.121.1.27単一価値）
Note that this number is non-negative. A negative value for this attribute is invalid, and any policy rule that refers to an invalid entry SHOULD be treated as being disabled.
この数は非陰性であることに注意してください。この属性の負の値は無効であり、無効なエントリを指すポリシールールは、無効になっていると扱う必要があります。
The pcimConditionNegated attribute is a Boolean attribute that indicates whether this policy condition is to be negated or not. If it is TRUE (FALSE), it indicates that a policy condition IS (IS NOT) negated in the DNF or CNF expression associated with a policy rule. This attribute is defined as follows:
PCImConditionNegated属性は、このポリシー条件が否定されるかどうかを示すブール属性です。それが真（false）の場合、ポリシールールに関連するDNFまたはCNF式では、ポリシー条件が否定されていることを示します。この属性は次のように定義されます。
( 1.3.6.1.1.6.2.17 NAME 'pcimConditionNegated' DESC 'If TRUE (FALSE), it indicates that a policy condition IS (IS NOT) negated in the DNF or CNF expression associated with a policy rule.' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
（1.3.6.1.1.1.6.2.17名「pcimcondition negated 'desc' 'true（false）、ポリシー条件がポリシールールに関連するDNFまたはCNF式では否定されていることを示します。6.1.4.1.1466.115.121.1.7単一価値）
The pcimConditionName is a user-friendly name for identifying this policy condition, and may be used as a naming attribute if desired. This attribute is defined as follows:
PCIMConditionNameは、このポリシー条件を識別するためのユーザーフレンドリーな名前であり、必要に応じて命名属性として使用できます。この属性は次のように定義されます。
( 1.3.6.1.1.6.2.18 NAME 'pcimConditionName' DESC 'A user-friendly name for a policy condition.' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
（1.3.6.1.1.1.6.2.18名 'pcimconditionname' desc 'ポリシー条件のユーザーフレンドリーな名前。
The pcimConditionDN attribute is a DN that references an instance of a reusable policy condition. This attribute is defined as follows:
PCIMConditionDN属性は、再利用可能なポリシー条件のインスタンスを参照するDNです。この属性は次のように定義されます。
( 1.3.6.1.1.6.2.19 NAME 'pcimConditionDN' DESC 'A DN that references an instance of a reusable policy condition.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
（1.3.6.1.1.1.6.2.19名 'pcimconditiondn' desc '再利用可能な政策条件のインスタンスを参照するDN。
A DIT content rule could be written to enable an instance of pcimRuleConditionAssociation to have attached to it an instance of the auxiliary class pcimConditionAuxClass, or one of its subclasses. This would be used to formalize the semantics of the PolicyConditionInPolicyRule association. Specifically, this would be used to represent a rule-specific policy condition [1]. Similarly, three separate DIT structure rules could be written. Each of these DIT structure rules would refer to a specific name form that defined two important semantics. First, each name form would identify one of the three possible naming attributes (i.e., pcimConditionName, cn, and orderedCIMKeys) for the pcimRuleConditionAssociation object class. Second, each name form would require that an instance of the pcimRuleConditionAssociation class have as its superior an instance of the pcimRule class. This structure rule SHOULD also include a superiorStructureRule (see Note 2 at the beginning of section 5).
DITコンテンツルールは、pcimruleconditionAssociationのインスタンスが補助クラスのpcimconditionauxclassのインスタンス、またはそのサブクラスの1つを有効にするために作成できます。これは、PolicyConditionInpolicyrule Associationのセマンティクスを正式化するために使用されます。具体的には、これはルール固有のポリシー条件を表すために使用されます[1]。同様に、3つの個別のDIT構造ルールを書くことができました。これらのDIT構造ルールのそれぞれは、2つの重要なセマンティクスを定義した特定の名前フォームを指します。まず、各名前形式は、PCIMRULECONDITIONASSOCIATIONオブジェクトクラスの3つの可能な命名属性（つまり、PCIMConditionName、CN、およびOrderedCimkeys）のいずれかを識別します。第二に、各名前の形式では、PCIMRULECONDITIONASSOCIATIONクラスのインスタンスがPCIMRULEクラスの優れたインスタンスを持つことを要求します。この構造規則には、上記の構造も含める必要があります（セクション5の開始の注2を参照）。
The policyRuleValidityPeriod aggregation is mapped to the PCLS pcimRuleValidityAssociation class. This class represents the scheduled activation and deactivation of a policy rule by binding the definition of times that the policy is active to the policy rule itself. The "scheduled" times are either identified through an attached auxiliary class pcimTPCAuxClass, or are referenced through its pcimTimePeriodConditionDN attribute.
Policyrulevalidityperiodの集約は、PCLS PCIMRULEVALISITION ASSOCIATIONクラスにマッピングされます。このクラスは、ポリシーがポリシールール自体に対してアクティブである時間の定義を拘束することにより、ポリシールールのスケジュールされたアクティベーションと非アクティブ化を表します。「スケジュールされた」時間は、添付された補助クラスPCIMTPCAUXCLASSを介して識別されるか、PCIMTIMEPERIODCONDITIONDN属性を介して参照されます。
This class is defined as follows:
このクラスは次のように定義されています。
( 1.3.6.1.1.6.1.9 NAME 'pcimRuleValidityAssociation' DESC 'This defines the scheduled activation or deactivation of a policy rule.'
（1.3.6.1.1.6.1.9名「PCIMRULEVALISITION ASSOCIATION 'DESC'これは、ポリシールールのスケジュールされたアクティブ化または非アクティブ化を定義します。
SUP pcimPolicy STRUCTURAL MAY ( pcimValidityConditionName $ pcimTimePeriodConditionDN ) )
suppcimpolicy structural may（pcimvalidityconditionname $ pcimtimeperiodconditiondn）））
The attributes of this class are defined as follows:
このクラスの属性は、次のように定義されています。
The pcimValidityConditionName attribute is used to define a user-friendly name of this condition, and may be used as a naming attribute if desired. This attribute is defined as follows:
PCIMALITITYCONDITIONNAME属性は、この条件のユーザーフレンドリーな名前を定義するために使用され、必要に応じて命名属性として使用できます。この属性は次のように定義されます。
( 1.3.6.1.1.6.2.20 NAME 'pcimValidityConditionName' DESC 'A user-friendly name for identifying an instance of a pcimRuleValidityAssociation entry.' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
（1.3.6.1.1.6.2.20 name name 'pcimalicidityconditionname' desc 'pcimrulevalidity Associationエントリのインスタンスを識別するためのユーザーフレンドリーな名前。））
The pcimTimePeriodConditionDN attribute is a DN that references a reusable time period condition. It is defined as follows:
PCIMTIMEPERIODCONDITIONDN属性は、再利用可能な期間条件を参照するDNです。次のように定義されています。
( 1.3.6.1.1.6.2.21 NAME 'pcimTimePeriodConditionDN' DESC 'A reference to a reusable policy time period condition.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
（1.3.6.1.1.6.6.2.21名 'pcimtimeperiodconditiondn' desc '再利用可能なポリシー期間条件への参照。
A DIT content rule could be written to enable an instance of pcimRuleValidityAssociation to have attached to it an instance of the auxiliary class pcimTPCAuxClass, or one of its subclasses. This would be used to formalize the semantics of the PolicyRuleValidityPeriod aggregation [1].
ditコンテンツルールは、pcimrulevalidityAssociationのインスタンスが補助クラスpcimtpcauxclassのインスタンス、またはそのサブクラスの1つを有効にするために作成できます。これは、Policyrulevalidityperiodの凝集のセマンティクスを形式化するために使用されます[1]。
Similarly, three separate DIT structure rules could be written. Each of these DIT structure rules would refer to a specific name form that defined two important semantics. First, each name form would identify one of the three possible naming attributes (i.e., pcimValidityConditionName, cn, and orderedCIMKeys) for the pcimRuleValidityAssociation object class. Second, each name form would require that an instance of the pcimRuleValidityAssociation class have as its superior an instance of the pcimRule class. This structure rule SHOULD also include a superiorStructureRule (see Note 2 at the beginning of section 5).
同様に、3つの個別のDIT構造ルールを書くことができました。これらのDIT構造ルールのそれぞれは、2つの重要なセマンティクスを定義した特定の名前フォームを指します。まず、各名前のフォームは、PCIMRULEVALISITION ASSOCIATIONオブジェクトクラスの3つの可能な命名属性のいずれか（つまり、PCIMValidityConditionName、CN、およびOrderedCimkeys）のいずれかを識別します。第二に、各名前の形式では、PCIMRULEVALISITION ASSOCIATIONクラスのインスタンスがPCIMRULEクラスの優れたインスタンスを持つことを要求します。この構造規則には、上記の構造も含める必要があります（セクション5の開始の注2を参照）。
This class contains an attribute to represent the one property of the PCIM PolicyActionInPolicyRule association, ActionOrder. This property is used to specify an order for executing the actions associated with a policy rule. Instances of this class are related to an instance of pcimRule via DIT containment. The actions themselves are represented by auxiliary subclasses of the auxiliary class pcimActionAuxClass.
このクラスには、PCIM PolicyActionInPolicyrule AssociationのActionOrderの1つのプロパティを表す属性が含まれています。このプロパティは、ポリシールールに関連付けられたアクションを実行するための注文を指定するために使用されます。このクラスのインスタンスは、DIT封じ込めによるPCimruleのインスタンスに関連しています。アクション自体は、補助クラスPCIMACTIONAUXCLASSの補助サブクラスによって表されます。
These auxiliary classes are attached directly to instances of pcimRuleActionAssociation for rule-specific policy actions. For a reusable policy action, the pcimAction auxiliary subclass is attached to an instance of the class pcimPolicyInstance (which is presumably associated with a pcimRepository by DIT containment), and the pcimActionDN attribute (of this class) is used to reference the reusable pcimCondition instance.
これらの補助クラスは、ルール固有のポリシーアクションのためにPCIMRULEACTIONACTIONACOITIONのインスタンスに直接添付されます。再利用可能なポリシーアクションのために、PCIMACTION AUXILARY SUBCLASSは、クラスPCIMPOLICYINSTANCEのインスタンス（おそらくDIT封じ込めによるPCIMREPOSITORYに関連付けられている）に添付され、PCIMACTIONDN属性（このクラスの）が再利用可能なPCImcondition Instanceを参照するために使用されます。
The class definition is as follows:
クラスの定義は次のとおりです。
( 1.3.6.1.1.6.1.10 NAME 'pcimRuleActionAssociation' DESC 'This class contains attributes characterizing the relationship between a policy rule and one of its policy actions.' SUP pcimPolicy MUST ( pcimActionOrder ) MAY ( pcimActionName $ pcimActionDN ) )
（1.3.6.1.1.6.6.1.10名「PCIMRULEACTIONACTIONCIATION 'DESC'このクラスには、ポリシールールとそのポリシーアクションの1つの関係を特徴付ける属性が含まれています。
The pcimActionName attribute is used to define a user-friendly name of this action, and may be used as a naming attribute if desired. This attribute is defined as follows:
PCIMACTIONNAME属性は、このアクションのユーザーフレンドリーな名前を定義するために使用され、必要に応じて命名属性として使用できます。この属性は次のように定義されます。
( 1.3.6.1.1.6.2.22 NAME 'pcimActionName' DESC 'A user-friendly name for a policy action.' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
（1.3.6.1.1.6.6.2.22名「PCIMACTIONNAME」desc 'ポリシーアクションのユーザーフレンドリーな名前。
The pcimActionOrder attribute is an unsigned integer that is used to indicate the relative position of an action in a sequence of actions that are associated with a given policy rule. When this number is positive, it indicates a place in the sequence of actions to be performed, with smaller values indicating earlier positions in the sequence. If the value is zero, then this indicates that the order is irrelevant. Note that if two or more actions have the same non-zero value, they may be performed in any order as long as they are each performed in the correct place in the overall sequence of actions. This attribute is defined as follows:
PCIMACTIONDORDER属性は、特定のポリシールールに関連付けられている一連のアクションでアクションの相対的な位置を示すために使用される署名されていない整数です。この数値が正である場合、それは実行される一連のアクションのシーケンス内の場所を示します。値がゼロの場合、これは順序が無関係であることを示します。2つ以上のアクションが同じ非ゼロ値を持っている場合、それぞれが一連のアクション全体の正しい場所で実行される限り、それらは任意の順序で実行される可能性があることに注意してください。この属性は次のように定義されます。
( 1.3.6.1.1.6.2.23 NAME 'pcimActionOrder' DESC 'An integer indicating the relative order of an action in the context of a policy rule.' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
（1.3.6.1.1.6.2.23名「PCIMACTIONORDER」DESC 'ポリシールールのコンテキストでのアクションの相対順序を示す整数。価値 ）
Note: if the value of the pcimActionOrder field is negative, then it SHOULD be treated as an error and any policy rule that refers to such an entry SHOULD be treated as being disabled.
注：PCIMACTIONORDERフィールドの値が負の場合、エラーとして扱われる必要があり、そのようなエントリを参照するポリシールールは無効であると扱う必要があります。
The pcimActionDN attribute is a DN that references a reusable policy action. It is defined as follows:
PCIMACTIONDN属性は、再利用可能なポリシーアクションを参照するDNです。次のように定義されています。
( 1.3.6.1.1.6.2.24 NAME 'pcimActionDN' DESC 'A DN that references a reusable policy action.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
（1.3.6.1.1.6.2.2.24名「pcimactiondn 'desc'再利用可能なポリシーアクションを参照するDN」。
A DIT content rule could be written to enable an instance of pcimRuleActionAssociation to have attached to it an instance of the auxiliary class pcimActionAuxClass, or one of its subclasses. This would be used to formalize the semantics of the PolicyActionInPolicyRule association. Specifically, this would be used to represent a rule-specific policy action [1].
DITコンテンツルールは、PCIMRULEACTIONASTASOCIATIONのインスタンスが補助クラスのPCIMACTIONAUXCLASSのインスタンス、またはそのサブクラスの1つを有効にするために記述できます。これは、PolicationInpolicyrule Associationのセマンティクスを正式化するために使用されます。具体的には、これはルール固有のポリシーアクション[1]を表すために使用されます。
Similarly, three separate DIT structure rules could be written. Each of these DIT structure rules would refer to a specific name form that defined two important semantics. First, each name form would identify one of the three possible naming attributes (i.e., pcimActionName, cn, and orderedCIMKeys) for the pcimRuleActionAssociation object class. Second, each name form would require that an instance of the pcimRuleActionAssociation class have as its superior an instance of the pcimRule class. This structure rule should also include a superiorStructureRule (see Note 2 at the beginning of section 5).
同様に、3つの個別のDIT構造ルールを書くことができました。これらのDIT構造ルールのそれぞれは、2つの重要なセマンティクスを定義した特定の名前フォームを指します。まず、各名前形式は、PCIMRULEACTIONACTIONASOCIATIONオブジェクトクラスの3つの可能な命名属性（つまり、PCIMACTIONNAME、CN、およびORDEREDCIMKEYS）のいずれかを識別します。第二に、各名前の形式では、PCIMRULEACTIONACTIONASOCIATIONクラスのインスタンスがPCIMRULEクラスの優れたインスタンスを持つことを要求します。この構造規則には、上記の構造も含める必要があります（セクション5の開始の注2を参照）。
The purpose of a policy condition is to determine whether or not the set of actions (contained in the pcimRule that the condition applies to) should be executed or not. This class defines the basic organizational semantics of a policy condition, as specified in [1]. Subclasses of this auxiliary class can be attached to instances of three other classes in the PCLS. When a subclass of this class is attached to an instance of pcimRuleConditionAssociation, or to an instance of pcimRule, it represents a rule-specific policy condition. When a subclass of this class is attached to an instance of pcimPolicyInstance, it represents a reusable policy condition.
ポリシー条件の目的は、一連のアクション（条件が適用されるPCimruleに含まれる）を実行するかどうかを判断することです。このクラスは、[1]で指定されているように、政策条件の基本的な組織的セマンティクスを定義します。この補助クラスのサブクラスは、PCLSの他の3つのクラスのインスタンスに添付できます。このクラスのサブクラスがpcimruleconditionasociationのインスタンス、またはpcimruleのインスタンスに添付される場合、ルール固有のポリシー条件を表します。このクラスのサブクラスがpcimpolicyInstanceのインスタンスに添付されると、再利用可能なポリシー条件を表します。
Since all of the classes to which subclasses of this auxiliary class may be attached are derived from the pcimPolicy class, the attributes of pcimPolicy will already be defined for the entries to which these subclasses attach. Thus, this class is derived directly from "top".
この補助クラスのサブクラスが添付される可能性のあるすべてのクラスはPCIMPOLICYクラスから派生しているため、Pcimpolicyの属性は、これらのサブクラスが付着するエントリに対して既に定義されています。したがって、このクラスは「トップ」から直接導出されます。
The class definition is as follows:
クラスの定義は次のとおりです。
( 1.3.6.1.1.6.1.11 NAME 'pcimConditionAuxClass' DESC 'A class representing a condition to be evaluated in conjunction with a policy rule.' SUP top AUXILIARY )
（1.3.6.1.1.6.1.11 'pcimconditionauxclass' desc 'ポリシールールと併せて評価される条件を表すクラス。' Sup Top Auxiliary）
The PCIM defines a time period class, PolicyTimePeriodCondition, to provide a means of representing the time periods during which a policy rule is valid, i.e., active. It also defines an aggregation, PolicyRuleValidityPeriod, so that time periods can be associated with a PolicyRule. The LDAP mapping also provides two classes, one for the time condition itself, and one for the aggregation.
PCIMは、ポリシールールが有効な期間、つまりアクティブな期間を表す手段を提供するために、期間クラスのPolicyTimeperiodConditionを定義します。また、期間をPolicyruleに関連付けることができるように、集計であるPolicyrulevalidityperiodを定義します。LDAPマッピングには、2つのクラスがあります。1つは時間条件自体、もう1つは集約用です。
In the PCIM, the time period class is named PolicyTimePeriodCondition. However, the resulting name of the auxiliary class in this mapping (pcimTimePeriodConditionAuxClass) exceeds the length of a name that some directories can store. Therefore, the name has been shortened to pcimTPCAuxClass.
PCIMでは、期間クラスはPolicyTimeperiodConditionと名付けられています。ただし、このマッピングの補助クラスの名前は、一部のディレクトリが保存できる名前の長さを超えています。したがって、名前はpcimtpcauxclassに短縮されました。
The class definition is as follows:
クラスの定義は次のとおりです。
( 1.3.6.1.1.6.1.12 NAME 'pcimTPCAuxClass' DESC 'This provides the capability of enabling or disabling a policy rule according to a predetermined schedule.' SUP pcimConditionAuxClass AUXILIARY MAY ( pcimTPCTime $ pcimTPCMonthOfYearMask $ pcimTPCDayOfMonthMask $ pcimTPCDayOfWeekMask $ pcimTPCTimeOfDayMask $ pcimTPCLocalOrUtcTime ) )
（1.3.6.1.1.1.6.1.12 name 'pcimtpcauxclass' desc 'これは、所定のスケジュールに従ってポリシールールを有効または無効にする能力を提供します。 ofdaymask $ pcimtpclocalorutctime））
The attributes of the pcimTPCAuxClass are defined as follows.
PCIMTPCAUXCLASSの属性は次のように定義されています。
The pcimTPCTime attribute represents the time period that a policy rule is enabled for. This attribute is defined as a string in [1] with a special format which defines a time period with a starting date and an ending date separated by a forward slash ("/"), as follows:
PCIMTPCTIME属性は、ポリシールールが有効になっている期間を表します。この属性は、[1]の文字列として定義されます。これは、以下のように、前方スラッシュ（ "/"）で区切られた開始日と終了日を定義する特別な形式を備えています。
yyyymmddThhmmss/yyyymmddThhmmss
yyyymmddthhmmss/yyyymmddthhmss
where the first date and time may be replaced with the string "THISANDPRIOR" or the second date and time may be replaced with the string "THISANDFUTURE". This attribute is defined as follows:
最初の日付と時間が文字列「thisandprior」に置き換えるか、2番目の日付と時間を文字列「thisandfuture」に置き換えることができます。この属性は次のように定義されます。
( 1.3.6.1.1.6.2.25 NAME 'pcimTPCTime' DESC 'The start and end times on which a policy rule is valid.' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 SINGLE-VALUE )
（1.3.6.1.1.1.6.2.25名「PCIMTPCTIME」DESC 'ポリシールールが有効な開始時と終了時間。
The value of this attribute SHOULD be checked against its defined format ("yyyymmddThhmmss/yyyymmddThhmmss", where the first and second date strings may be replaced with the strings "THISANDPRIOR" and "THISANDFUTURE"). If the value of this attribute does not conform to this syntax, then this SHOULD be considered an error and the policy rule SHOULD be treated as being disabled.
この属性の値は、定義された形式（「yyyymmddthhmmss/yyyymmddthhmmss」に対してチェックする必要があります。ここで、1番目と2番目の文字列は文字列「thisandprior」および「thisandfuture」に置き換えられます。この属性の値がこの構文に準拠していない場合、これはエラーと見なされ、ポリシールールは無効であると扱われるべきです。
The next four attributes (pcimTPCMonthOfYearMask, pcimTPCDayOfMonthMask, pcimTPCDayOfWeekMask, and pcimTPCTimeOfDayMask) are all defined as octet strings in [1]. However, the semantics of each of these attributes are contained in bit strings of various fixed lengths. Therefore, the PCLS uses a syntax of Bit String to represent each of them. The definition of these four attributes are as follows.
次の4つの属性（PCIMTPCMONTHOFYEARMASK、PCIMTPCDAYOFMONTHMASK、PCIMTPCDAYOFWEEKMASK、およびPCIMTPCTIMEOFDAYMASK）はすべて[1]のオクテット文字列として定義されています。ただし、これらの各属性のセマンティクスは、さまざまな固定長のビット文字列に含まれています。したがって、PCLSはビット文字列の構文を使用してそれぞれを表します。これらの4つの属性の定義は次のとおりです。
The pcimTPCMonthOfYearMask attribute defines a 12-bit mask identifying the months of the year in which a policy rule is valid. The format is a bit string of length 12, representing the months of the year from January through December. The definition of this attribute is as follows:
PCIMTPCMONTHOFYEARMASK属性は、ポリシールールが有効な年を識別する12ビットマスクを定義します。この形式は、1月から12月までの年の月を表す長さ12の少し文字列です。この属性の定義は次のとおりです。
( 1.3.6.1.1.6.2.26 NAME 'pcimTPCMonthOfYearMask' DESC 'This identifies the valid months of the year for a policy rule using a 12-bit string that represents the months of the year from January through December.' EQUALITY bitStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 SINGLE-VALUE )
（1.3.6.1.1.1.6.2.26名 'pcimtpcmonthofyearmask' desc 'これは、1月から12月までの年の月を表す12ビット文字列を使用したポリシールールの有効な月を識別します。6.1.4.1.1466.115.121.1.6単一価値）
The value of this attribute SHOULD be checked against its defined format. If the value of this attribute does not conform to this syntax, then this SHOULD be considered an error and the policy rule SHOULD be treated as being disabled.
この属性の値は、定義された形式に対してチェックする必要があります。この属性の値がこの構文に準拠していない場合、これはエラーと見なされ、ポリシールールは無効であると扱われるべきです。
The pcimTPCMonthOfDayMask attribute defines a mask identifying the days of the month on which a policy rule is valid. The format is a bit string of length 62. The first 31 positions represent the days of the month in ascending order, from day 1 to day 31. The next 31 positions represent the days of the month in descending order, from the last day to the day 31 days from the end. The definition of this attribute is as follows:
PCIMTPCMONTHOFDAYMASK属性は、ポリシールールが有効な月の日を識別するマスクを定義します。形式は長さ62の少し文字列です。最初の31ポジションは、1日目から31日目までの月の日を昇順で表しています。最後から31日目。この属性の定義は次のとおりです。
( 1.3.6.1.1.6.2.27 NAME 'pcimTPCDayOfMonthMask' DESC 'This identifies the valid days of the month for a policy rule using a 62-bit string. The first 31 positions represent the days of the month in ascending order, and the next 31 positions represent the days of the month in descending order.' EQUALITY bitStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 SINGLE-VALUE )
（1.3.6.1.1.6.2.2.27名 'pcimtpcdayofmonthmask' desc 'これは、62ビット文字列を使用したポリシールールの月の有効な日を識別します。最初の31ポジションは、昇順で月の日を表します。31ポジションは、月の日を降順で表しています。 'equality bitstringmatch構文1.3.6.1.4.1.146.115.121.1.6単一値）
The value of this attribute SHOULD be checked against its defined format. If the value of this attribute does not conform to this syntax, then this SHOULD be considered an error and the policy rule SHOULD be treated as being disabled.
この属性の値は、定義された形式に対してチェックする必要があります。この属性の値がこの構文に準拠していない場合、これはエラーと見なされ、ポリシールールは無効であると扱われるべきです。
The pcimTPCDayOfWeekMask attribute defines a mask identifying the days of the week on which a policy rule is valid. The format is a bit string of length 7, representing the days of the week from Sunday through Saturday. The definition of this attribute is as follows:
PCIMTPCDAYOFWEEKMASK属性は、ポリシールールが有効な週の日を識別するマスクを定義します。この形式は、日曜日から土曜日までの曜日を表す長さ7の少しの文字列です。この属性の定義は次のとおりです。
( 1.3.6.1.1.6.2.28 NAME 'pcimTPCDayOfWeekMask' DESC 'This identifies the valid days of the week for a policy rule using a 7-bit string. This represents the days of the week from Sunday through Saturday.' EQUALITY bitStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 SINGLE-VALUE )
（1.3.6.1.1.1.6.2.28名 'pcimtpcdayofweekmask' desc 'これは、7ビット文字列を使用したポリシールールの曜日の有効な日を識別します。これは日曜日から土曜日までの曜日を表します。.6.1.4.1.1466.115.121.1.6単一価値）
The value of this attribute SHOULD be checked against its defined format. If the value of this attribute does not conform to this syntax, then this SHOULD be considered an error and the policy rule SHOULD be treated as being disabled.
この属性の値は、定義された形式に対してチェックする必要があります。この属性の値がこの構文に準拠していない場合、これはエラーと見なされ、ポリシールールは無効であると扱われるべきです。
The pcimTPCTimeOfDayMask attribute defines the range of times at which a policy rule is valid. If the second time is earlier than the first, then the interval spans midnight. The format of the string is Thhmmss/Thhmmss. The definition of this attribute is as follows:
PCIMTPCTIMEOFDAYMASK属性は、ポリシールールが有効な時間の範囲を定義します。2回目が最初のものよりも早い場合、間隔は真夜中に及びます。文字列の形式はthhmmss/thhmmsです。この属性の定義は次のとおりです。
( 1.3.6.1.1.6.2.29 NAME 'pcimTPCTimeOfDayMask' DESC 'This identifies the valid range of times for a policy using the format Thhmmss/Thhmmss.' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 SINGLE-VALUE )
（1.3.6.1.1.6.6.2.29名 'pcimtpctimeofdaymask' desc 'これは、形式のthhmms/thhmmssを使用したポリシーの有効な時間を識別します。単一価値）
The value of this attribute SHOULD be checked against its defined format. If the value of this attribute does not conform to this syntax, then this SHOULD be considered an error and the policy rule SHOULD be treated as being disabled.
この属性の値は、定義された形式に対してチェックする必要があります。この属性の値がこの構文に準拠していない場合、これはエラーと見なされ、ポリシールールは無効であると扱われるべきです。
Finally, the pcimTPCLocalOrUtcTime attribute is used to choose between local or UTC time representation. This is mapped as a simple integer syntax, with the value of 1 representing local time and the value of 2 representing UTC time. The definition of this attribute is as follows:
最後に、PCIMTPCLOCALORUTCTIME属性を使用して、ローカルまたはUTCの時間表現を選択します。これは、単純な整数構文としてマッピングされ、1の値は現地時間を表し、2の値はUTC時間を表します。この属性の定義は次のとおりです。
( 1.3.6.1.1.6.2.30 NAME 'pcimTPCLocalOrUtcTime' DESC 'This defines whether the times in this instance represent local (value=1) times or UTC (value=2) times.' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
（1.3.6.1.1.6.2.30名「pcimtpclocalorutctime 'desc'これは、このインスタンスの時代がローカル（値= 1）回を表すか、UTC（値= 2）回を表すかどうかを定義します。.146.115.121.1.27単一価値）
Note: if the value of the pcimTPCLocalOrUtcTime is not 1 or 2, then this SHOULD be considered an error and the policy rule SHOULD be disabled. If the attribute is not present at all, then all times are interpreted as if it were present with the value 2, that is, UTC time.
注：PCIMTPCLOCALORUTCTIMEの値が1または2でない場合、これはエラーと見なされ、ポリシールールを無効にする必要があります。属性がまったく存在しない場合、値2、つまりUTC時間が存在するかのように常に解釈されます。
This class provides a general extension mechanism for representing policy conditions that have not been modeled with specific properties. Instead, its two properties are used to define the content and format of the condition, as explained below. This class is intended for vendor-specific extensions that are not amenable to using pcimCondition; standardized extensions SHOULD NOT use this class.
このクラスは、特定の特性でモデル化されていないポリシー条件を表すための一般的な拡張メカニズムを提供します。代わりに、その2つのプロパティを使用して、以下で説明するように、条件のコンテンツと形式を定義します。このクラスは、PCImConditionの使用が適切ではないベンダー固有の拡張機能を対象としています。標準化された拡張機能は、このクラスを使用しないでください。
The class definition is as follows:
クラスの定義は次のとおりです。
( 1.3.6.1.1.6.1.13 NAME 'pcimConditionVendorAuxClass' DESC 'A class that defines a registered means to describe a policy condition.' SUP pcimConditionAuxClass AUXILIARY MAY ( pcimVendorConstraintData $ pcimVendorConstraintEncoding ) )
（1.3.6.1.1.6.1.13名「pcimconditionvendorauxclass」desc 'ポリシー条件を説明するための登録手段を定義するクラス。
The pcimVendorConstraintData attribute is a multi-valued attribute. It provides a general mechanism for representing policy conditions that have not been modeled as specific attributes. This information is encoded in a set of octet strings. The format of the octet strings is identified by the OID stored in the pcimVendorConstraintEncoding attribute. This attribute is defined as follows:
PCIMVENDORCONSTRANTDATA属性は、多値属性です。特定の属性としてモデル化されていないポリシー条件を表すための一般的なメカニズムを提供します。この情報は、オクテット文字列のセットにエンコードされています。Octet文字列の形式は、PCIMVENDORCONSTRAINGENCODING属性に保存されているOIDによって識別されます。この属性は次のように定義されます。
( 1.3.6.1.1.6.2.31 NAME 'pcimVendorConstraintData' DESC 'Mechanism for representing constraints that have not been modeled as specific attributes. Their format is identified by the OID stored in the attribute pcimVendorConstraintEncoding.' EQUALITY octetStringMatch ORDERING octetStringOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
（1.3.6.1.1.6.2.31名「PCIMVENDORCONSTRAINDDATA」という名前の名前 'DESC'特定の属性としてモデル化されていない制約を表すためのメカニズム。それらの形式は、属性PCIMVENDORCONSTRINGENCODINGに保存されているOIDによって識別されます。4.1.146.115.121.1.40）
The pcimVendorConstraintEncoding attribute is used to identify the format and semantics for the pcimVendorConstraintData attribute. This attribute is defined as follows:
PCIMVENDORCONSTRINCENCODING属性は、PCIMVENDORCONSTRAINTDATA属性の形式とセマンティクスを識別するために使用されます。この属性は次のように定義されます。
( 1.3.6.1.1.6.2.32 NAME 'pcimVendorConstraintEncoding' DESC 'An OID identifying the format and semantics for the pcimVendorConstraintData for this instance.' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SINGLE-VALUE )
（1.3.6.1.1.6.2.32名「PCIMVENDORCONSTRAINCODENCODING 'DESC' 'このインスタンスのPCIMVENDORCONSTRAINTDATAの形式とセマンティクスを識別するOID。
The purpose of a policy action is to execute one or more operations that will affect network traffic and/or systems, devices, etc. in order to achieve a desired policy state. This class is used to represent an action to be performed as a result of a policy rule whose condition clause was satisfied.
ポリシーアクションの目的は、望ましいポリシー状態を達成するために、ネットワークトラフィックおよび/またはシステム、デバイスなどに影響を与える1つ以上の操作を実行することです。このクラスは、条件条項が満たされたポリシールールの結果として実行されるアクションを表すために使用されます。
Subclasses of this auxiliary class can be attached to instances of three other classes in the PCLS. When a subclass of this class is attached to an instance of pcimRuleActionAssociation, or to an instance of pcimRule, it represents a rule-specific policy action. When a subclass of this class is attached to an instance of pcimPolicyInstance, it represents a reusable policy action.
この補助クラスのサブクラスは、PCLSの他の3つのクラスのインスタンスに添付できます。このクラスのサブクラスがPCIMRULEACTIONACTIONASOCIATIONのインスタンス、またはPCIMRULEのインスタンスに添付される場合、ルール固有のポリシーアクションを表します。このクラスのサブクラスがpcimpolicyInstanceのインスタンスに添付されると、再利用可能なポリシーアクションを表します。
Since all of the classes to which subclasses of this auxiliary class may be attached are derived from the pcimPolicy class, the attributes of the pcimPolicy class will already be defined for the entries to which these subclasses attach. Thus, this class is derived directly from "top".
この補助クラスのサブクラスが添付される可能性のあるすべてのクラスはPCIMPOLICYクラスから派生しているため、Pcimpolicyクラスの属性は、これらのサブクラスが付着するエントリに対して既に定義されます。したがって、このクラスは「トップ」から直接導出されます。
The class definition is as follows:
クラスの定義は次のとおりです。
( 1.3.6.1.1.6.1.14 NAME 'pcimActionAuxClass' DESC 'A class representing an action to be performed as a result of a policy rule.' SUP top AUXILIARY )
（1.3.6.1.1.6.6.1.14名「PCIMACTIONAUXCLASS」DESC 'ポリシールールの結果として実行されるアクションを表すクラス。
The purpose of this class is to provide a general extension mechanism for representing policy actions that have not been modeled with specific properties. Instead, its two properties are used to define the content and format of the action, as explained below.
このクラスの目的は、特定のプロパティでモデル化されていないポリシーアクションを表すための一般的な拡張メカニズムを提供することです。代わりに、その2つのプロパティを使用して、以下で説明するように、アクションのコンテンツと形式を定義します。
As its name suggests, this class is intended for vendor-specific extensions that are not amenable to using the standard pcimAction class. Standardized extensions SHOULD NOT use this class.
その名前が示すように、このクラスは、標準のPCimactionクラスを使用することができないベンダー固有の拡張機能を対象としています。標準化された拡張機能は、このクラスを使用しないでください。
The class definition is as follows:
クラスの定義は次のとおりです。
( 1.3.6.1.1.6.1.15 NAME 'pcimActionVendorAuxClass' DESC 'A class that defines a registered means to describe a policy action.' SUP pcimActionAuxClass AUXILIARY MAY ( pcimVendorActionData $ pcimVendorActionEncoding ) )
（1.3.6.1.1.6.1.15名 'pcimactionvendorauxclass' desc 'ポリシーアクションを説明する登録手段を定義するクラス。
The pcimVendorActionData attribute is a multi-valued attribute. It provides a general mechanism for representing policy actions that have not been modeled as specific attributes. This information is encoded in a set of octet strings. The format of the octet strings is identified by the OID stored in the pcimVendorActionEncoding attribute. This attribute is defined as follows:
PCIMVENDORACTIONDATA属性は、多値属性です。特定の属性としてモデル化されていないポリシーアクションを表すための一般的なメカニズムを提供します。この情報は、オクテット文字列のセットにエンコードされています。Octet文字列の形式は、PCIMVENDORACTIONENCODING属性に保存されているOIDによって識別されます。この属性は次のように定義されます。
( 1.3.6.1.1.6.2.33 NAME 'pcimVendorActionData' DESC ' Mechanism for representing policy actions that have not been modeled as specific attributes. Their format is identified by the OID stored in the attribute pcimVendorActionEncoding.' EQUALITY octetStringMatch ORDERING octetStringOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
（1.3.6.1.1.6.2.33名「PCIMVENDORACTIONDATA 'DESC'特定の属性としてモデル化されていないポリシーアクションを表すためのメカニズム。その形式は、属性PCIMVENDORACTIONENCODINGに保存されているOIDによって識別されます。.4.1.1466.115.121.1.40）
The pcimVendorActionEncoding attribute is used to identify the format and semantics for the pcimVendorActionData attribute. This attribute is defined as follows:
PCIMVENDORACTIONENCODING属性は、PCIMVENDORACTIONDATA属性の形式とセマンティクスを識別するために使用されます。この属性は次のように定義されます。
( 1.3.6.1.1.6.2.34 NAME 'pcimVendorActionEncoding' DESC 'An OID identifying the format and semantics for the pcimVendorActionData attribute of this instance.' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SINGLE-VALUE )
（1.3.6.1.1.6.2.34名「PCIMVENDORACTIONENCODING 'DESC」an OIDこのインスタンスのPCIMVENDORACTIONDATA属性の形式とセマンティクスを識別します。
This class is not defined in the PCIM. Its role is to serve as a structural class to which auxiliary classes representing policy information are attached when the information is reusable. For auxiliary classes representing policy conditions and policy actions, there are alternative structural classes that may be used. See Section 4.4 for a complete discussion of reusable policy conditions and actions, and of the role that this class plays in how they are represented.
このクラスはPCIMで定義されていません。その役割は、情報が再利用可能なときにポリシー情報を表す補助クラスが添付される構造クラスとして機能することです。ポリシー条件と政策措置を表す補助クラスには、使用できる代替構造クラスがあります。再利用可能な政策条件と行動の完全な議論、およびこのクラスがそれらの表現方法において果たす役割については、セクション4.4を参照してください。
The class definition is as follows:
クラスの定義は次のとおりです。
( 1.3.6.1.1.6.1.16 NAME 'pcimPolicyInstance' DESC 'A structural class to which aux classes containing reusable policy information can be attached.' SUP pcimPolicy MAY ( pcimPolicyInstanceName ) )
（1.3.6.1.1.6.1.16名「PcimpolicyInstance」DESC '再利用可能なポリシー情報を含むAUXクラスを添付できる構造クラス。
The pcimPolicyInstanceName attribute is used to define a user-friendly name of this class, and may be used as a naming attribute if desired. It is defined as follows:
pcimpolicyinstancename属性は、このクラスのユーザーフレンドリーな名前を定義するために使用され、必要に応じて命名属性として使用できます。次のように定義されています。
( 1.3.6.1.1.6.2.35 NAME 'pcimPolicyInstanceName' DESC 'The user-friendly name of this policy instance.' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
（1.3.6.1.1.6.2.35名「pcimpolicyinstancename 'desc」このポリシーインスタンスのユーザーフレンドリーな名前。
A DIT content rule could be written to enable an instance of pcimPolicyInstance to have attached to it either instances of one or more of the auxiliary object classes pcimConditionAuxClass and pcimActionAuxClass. Since these semantics do not include specifying any properties, the content rule would not need to specify any attributes. Note that other content rules could be defined to enable other policy-related auxiliary classes to be attached to pcimPolicyInstance.
DITコンテンツルールは、PcimpolicyInstanceのインスタンスが1つまたは複数の補助オブジェクトクラスpcimconditionauxclassとpcimactionauxclassのいずれかのインスタンスのいずれかのインスタンスに接続できるようにするために作成できます。これらのセマンティクスにはプロパティの指定は含まれていないため、コンテンツルールは属性を指定する必要はありません。他のコンテンツルールを定義して、他のポリシー関連の補助クラスをpcimpolicyInstanceに添付できるようにすることに注意してください。
Similarly, three separate DIT structure rules could be written. Each of these DIT structure rules would refer to a specific name form that defined two important semantics. First, each name form would identify one of the three possible naming attributes (i.e., pcimPolicyInstanceName, cn, and orderedCIMKeys) for this object class. Second, each name form would require that an instance of the pcimPolicyInstance class have as its superior an instance of the pcimRepository class. This structure rule SHOULD also include a superiorStructureRule (see Note 2 at the beginning of section 5).
同様に、3つの個別のDIT構造ルールを書くことができました。これらのDIT構造ルールのそれぞれは、2つの重要なセマンティクスを定義した特定の名前フォームを指します。まず、各名前の形式は、このオブジェクトクラスの3つの可能な命名属性のいずれか（つまり、PcimpolicyInstancename、CN、およびOrderedCimkeys）を識別します。第二に、各名前の形式では、pcimpolicyInstanceクラスのインスタンスがPCIMREPositoryクラスの優れたインスタンスを持つことを要求します。この構造規則には、上記の構造も含める必要があります（セクション5の開始の注2を参照）。
This class introduces no additional attributes, beyond those defined in the class pcimPolicy from which it is derived. Its role is to "tag" an instance of a class defined outside the realm of policy information as represented by PCIM as being nevertheless relevant to a policy specification. This tagging can potentially take place at two levels:
このクラスでは、クラスのpcimpolicyで定義されているものを超えて、導き出された属性を導入しません。その役割は、PCIMが代表するポリシー情報の領域外に定義されているクラスのインスタンスを「タグ」し、それでもポリシー仕様に関連するものとして「タグ」します。このタグ付けは、潜在的に2つのレベルで行われる可能性があります。
- Every instance to which pcimElementAuxClass is attached becomes an instance of the class pcimPolicy, since pcimElementAuxClass is a subclass of pcimPolicy. Searching for object class="pcimPolicy" will return the instance. (As noted earlier, this approach does NOT work for some directory implementations. To accommodate these implementations, policy-related entries SHOULD be tagged with the pcimKeyword "POLICY".)
- pcimelementauxclassはpcimpolicyのサブクラスであるため、pcimelementauxclassが添付されているすべてのインスタンスはクラスのpcimpolicyのインスタンスになります。Object class = "pcimpolicy"を検索すると、インスタンスが返されます。（前述のように、このアプローチは一部のディレクトリの実装では機能しません。これらの実装に対応するには、ポリシー関連のエントリにPCIMKEYWORDの「ポリシー」にタグを付ける必要があります。）
- With the pcimKeywords attribute that it inherits from pcimPolicy, an instance to which pcimElementAuxClass is attached can be tagged as being relevant to a particular type or category of policy information, using standard keywords, administrator-defined keywords, or both.
- PcimkeyWordsの属性をPcimpolicyから継承すると、標準のキーワード、管理者定義のキーワード、またはその両方を使用して、Pcimelementauxclassが添付されるインスタンスには、特定のタイプまたはポリシー情報のカテゴリに関連するものとしてタグ付けできます。
The class definition is as follows:
クラスの定義は次のとおりです。
( 1.3.6.1.1.6.1.17 NAME 'pcimElementAuxClass' DESC 'An auxiliary class used to tag instances of classes defined outside the realm of policy as relevant to a particular policy specification.'
（1.3.6.1.1.6.1.17名「Pcimelementauxclass 'desc' '特定のポリシー仕様に関連するものとして、ポリシーの領域外に定義されたクラスのインスタンスをタグ付けするために使用される補助クラス。
SUP pcimPolicy AUXILIARY )
suppcimpolicy Auxiliary）
These classes provide a container for reusable policy information, such as reusable policy conditions and/or reusable policy actions. This document is concerned with mapping just the properties that appear in these classes. Conceptually, this may be thought of as a special location in the DIT where policy information may reside. Since pcimRepository is derived from the class dlm1AdminDomain defined in reference [6], this specification has a normative dependency on that element of reference [6] (as well as on its entire derivation hierarchy, which also appears in reference [6]). To maximize flexibility, the pcimRepository class is defined as abstract. A subclass pcimRepositoryAuxClass provides for auxiliary attachment to another entry, while a structural subclass pcimRepositoryInstance is available to represent a policy repository as a standalone entry.
これらのクラスは、再利用可能なポリシー条件や再利用可能なポリシーアクションなど、再利用可能なポリシー情報のコンテナを提供します。このドキュメントは、これらのクラスに表示されるプロパティのみをマッピングすることに関係しています。概念的には、これはポリシー情報が存在する可能性のあるDITの特別な場所と考えられるかもしれません。PCIMREPositoryは参照[6]で定義されたクラスDLM1ADMINDOMAINから派生しているため、この仕様は参照[6]（および参照[6]にも表示される派生階層全体）に規範的依存性があります。柔軟性を最大化するために、PCIMREPositoryクラスは抽象として定義されます。サブクラスのPCIMREPOSITORYAUXCLASSは、別のエントリへの補助的な添付ファイルを提供しますが、構造的なサブクラスPCIMREPOSITORYINTANCEは、スタンドアロンエントリとしてポリシーリポジトリを表すために利用できます。
The definition for the pcimRepository class is as follows:
PCIMREPositoryクラスの定義は次のとおりです。
( 1.3.6.1.1.6.1.18 NAME 'pcimRepository' DESC 'A container for reusable policy information.' SUP dlm1AdminDomain ABSTRACT MAY ( pcimRepositoryName ) )
（1.3.6.1.1.6.1.18 name 'pcimrepository' desc '再利用可能なポリシー情報のコンテナ。
The pcimRepositoryName attribute is used to define a user-friendly name of this class, and may be used as a naming attribute if desired. It is defined as follows:
PCIMREPOSITORYNAME属性は、このクラスのユーザーフレンドリーな名前を定義するために使用され、必要に応じて命名属性として使用できます。次のように定義されています。
( 1.3.6.1.1.6.2.36 NAME 'pcimRepositoryName' DESC 'The user-friendly name of this policy repository.' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
（1.3.6.1.1.6.2.36名「PcimrepositoryName 'desc」このポリシーリポジトリのユーザーフレンドリーな名前。
The two subclasses of pcimRepository are defined as follows. First, the pcimRepositoryAuxClass is an auxiliary class that can be used to aggregate reusable policy information. It is defined as follows:
PCIMREPositoryの2つのサブクラスは、次のように定義されています。まず、PCIMREPOSITORYAUXCLASSは、再利用可能なポリシー情報を集約するために使用できる補助クラスです。次のように定義されています。
( 1.3.6.1.1.6.1.19 NAME 'pcimRepositoryAuxClass' DESC 'An auxiliary class that can be used to aggregate reusable policy information.' SUP pcimRepository AUXILIARY )
（1.3.6.1.1.6.1.19名「Pcimrepositoryauxclass」desc '再利用可能なポリシー情報を集約するために使用できる補助クラス。
In cases where structural classes are needed instead of an auxiliary class, the pcimRepositoryInstance class is a structural class that can be used to aggregate reusable policy information. It is defined as follows:
補助クラスの代わりに構造クラスが必要な場合、PCIMREPOSITORYINTANCEクラスは、再利用可能なポリシー情報を集約するために使用できる構造クラスです。次のように定義されています。
( 1.3.6.1.1.6.1.20 NAME 'pcimRepositoryInstance' DESC 'A structural class that can be used to aggregate reusable policy information.' SUP pcimRepository STRUCTURAL )
（1.3.6.1.1.6.1.20名「pcimrepositoryInstance」desc '再利用可能なポリシー情報を集約するために使用できる構造クラス。
Three separate DIT structure rules could be written for this class. Each of these DIT structure rules would refer to a specific name form that enabled an instance of the pcimRepository class to be named under any superior using one of the three possible naming attributes (i.e., pcimRepositoryName, cn, and orderedCIMKeys). This structure rule SHOULD also include a superiorStructureRule (see Note 2 at the beginning of section 5).
このクラスについては、3つの個別のDIT構造ルールを書くことができます。これらのDIT構造ルールのそれぞれは、PCIMREPositoryクラスのインスタンスを、3つの可能な命名属性（つまり、PCIMREPOSITORYNAME、CN、およびOrderedCimkeys）のいずれかを使用して上司の下で名前を付けることを可能にする特定の名前フォームを指します。この構造規則には、上記の構造も含める必要があります（セクション5の開始の注2を参照）。
This auxiliary class provides a single, multi-valued attribute that references a set of objects that are at the root of DIT subtrees containing policy-related information. By attaching this attribute to instances of various other classes, a policy administrator has a flexible way of providing an entry point into the directory that allows a client to locate and retrieve the policy information relevant to it.
この補助クラスは、ポリシー関連の情報を含むDITサブツリーのルートにある一連のオブジェクトを参照する単一のマルチ値属性を提供します。この属性を他のさまざまなクラスのインスタンスに添付することにより、ポリシー管理者は、クライアントがそれに関連するポリシー情報を見つけて取得できるようにするディレクトリにエントリポイントを提供する柔軟な方法を持っています。
It is intended that these entries are placed in the DIT such that well-known DNs can be used to reference a well-known structural entry that has the pcimSubtreesPtrAuxClass attached to it. In effect, this defines a set of entry points. Each of these entry points can contain and/or reference all related policy entries for any well-known policy domains. The pcimSubtreesPtrAuxClass functions as a tag to identify portions of the DIT that contain policy information.
これらのエントリはDITに配置され、よく知られているDNSを使用して、PCIMSubTreesPtrauxClassが付属している有名な構造エントリを参照できるようにします。実際には、これは一連のエントリポイントを定義します。これらの各エントリポイントは、よく知られているポリシードメインのすべての関連ポリシーエントリを含めることができます。pcimsubtreesptrauxclassは、ポリシー情報を含むDITの部分を識別するためのタグとして機能します。
This object does not provide the semantic linkages between individual policy objects, such as those between a policy group and the policy rules that belong to it. Its only role is to enable efficient bulk retrieval of policy-related objects, as described in Section 4.5.
このオブジェクトは、ポリシーグループとそれに属するポリシールールの間の個々のポリシーオブジェクト間のセマンティックリンケージを提供しません。その唯一の役割は、セクション4.5で説明されているように、ポリシー関連のオブジェクトの効率的なバルク検索を可能にすることです。
Once the objects have been retrieved, a directory client can determine the semantic linkages by following references contained in multi-valued attributes, such as pcimRulesAuxContainedSet.
オブジェクトが取得されると、ディレクトリクライアントは、PCIMRULESAUXCONTENSESTなどの多検証属性に含まれる参照に従って、セマンティックリンケージを決定できます。
Since policy-related objects will often be included in the DIT subtree beneath an object to which this auxiliary class is attached, a client SHOULD request the policy-related objects from the subtree under the object with these references at the same time that it requests the references themselves.
ポリシー関連のオブジェクトは、この補助クラスが添付されているオブジェクトの下のDITサブツリーに含まれることが多いため、クライアントは、これらの参照と同時に、オブジェクトの下にあるサブツリーからポリシー関連のオブジェクトを要求する必要があります。参照自体。
Since clients are expected to behave in this way, the policy administrator SHOULD make sure that this subtree does not contain so many objects unrelated to policy that an initial search done in this way results in a performance problem. The pcimSubtreesPtrAuxClass SHOULD NOT be attached to the partition root for a large directory partition containing a relatively few number of policy-related objects along with a large number of objects unrelated to policy (again, "policy" here refers to the PCIM, not the X.501, definition and use of "policy"). A better approach would be to introduce a container object immediately below the partition root, attach pcimSubtreesPtrAuxClass to this container object, and then place all of the policy-related objects in that subtree.
クライアントはこのように振る舞うと予想されるため、ポリシー管理者は、このサブツリーにポリシーとは関係のない多くのオブジェクトが含まれていないことを確認する必要があります。pcimsubtreesptrauxclassは、比較的少数のポリシー関連オブジェクトを含む大規模なディレクトリパーティションのパーティションルートに接続しないでください。.501、「ポリシー」の定義と使用）。より良いアプローチは、パーティションルートのすぐ下にコンテナオブジェクトを導入し、このコンテナオブジェクトにPCIMSUBTREESPTRAUXCLASSを取り付けてから、そのサブツリーにすべてのポリシー関連オブジェクトを配置することです。
The class definition is as follows:
クラスの定義は次のとおりです。
( 1.3.6.1.1.6.1.21 NAME 'pcimSubtreesPtrAuxClass' DESC 'An auxiliary class providing DN references to roots of DIT subtrees containing policy-related objects.' SUP top AUXILIARY MAY ( pcimSubtreesAuxContainedSet ) )
（1.3.6.1.1.6.1.21名「pcimsubtreesptrauxclass」desc 'ポリシー関連オブジェクトを含むDITサブツリーのルーツへの参照を提供する補助クラス。
The attribute pcimSubtreesAuxContainedSet provides an unordered set of DN references to instances of one or more objects under which policy-related information is present. The objects referenced may or may not themselves contain policy-related information. The attribute definition is as follows:
属性pcimsubtreesauxContededsetは、ポリシー関連の情報が存在する1つ以上のオブジェクトのインスタンスへの順序付けられていないDN参照を提供します。参照されるオブジェクト自体には、ポリシー関連の情報が含まれている場合とそうでない場合があります。属性定義は次のとおりです。
( 1.3.6.1.1.6.2.37 NAME 'pcimSubtreesAuxContainedSet' DESC 'DNs of objects that serve as roots for DIT subtrees containing policy-related objects.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
（1.3.6.1.1.6.2.37名「PCIMSUBTREESAUXCONTENSEST 'DESC」DNSは、ポリシー関連オブジェクトを含むDITサブツリーのルーツとして機能するオブジェクトのDNS。
Note that the cn attribute does NOT need to be defined for this class. This is because an auxiliary class is used as a means to collect common attributes and treat them as properties of an object. A good analogy is a #include file, except that since an auxiliary class is a class, all the benefits of a class (e.g., inheritance) can be applied to an auxiliary class.
このクラスでは、CN属性を定義する必要はないことに注意してください。これは、補助クラスが一般的な属性を収集し、それらをオブジェクトの特性として扱う手段として使用されるためです。良い類推は#includeファイルですが、補助クラスはクラスであるため、クラスのすべての利点（継承など）を補助クラスに適用できることを除きます。
This auxiliary class provides a single, multi-valued attribute that references a set of pcimGroups. By attaching this attribute to instances of various other classes, a policy administrator has a flexible way of providing an entry point into the directory that allows a client to locate and retrieve the pcimGroups relevant to it.
この補助クラスは、PCIMGROUPのセットを参照する単一のマルチ値の属性を提供します。この属性を他のさまざまなクラスのインスタンスに添付することにより、ポリシー管理者は、クライアントがそれに関連するPCImgroupを見つけて検索できるようにするディレクトリにエントリポイントを提供する柔軟な方法を持っています。
As is the case with pcimRules, a policy administrator might have several different references to a pcimGroup in the overall directory structure. The pcimGroupContainmentAuxClass is the mechanism that makes it possible for the policy administrator to define all these different references.
PCIMRULESの場合と同様に、ポリシー管理者は、ディレクトリ構造全体のPCIMGROUPにいくつかの異なる参照を持っている可能性があります。PCIMGROUPCONTAINMENTAUXCLASSは、ポリシー管理者がこれらすべての異なる参照を定義できるメカニズムです。
The class definition is as follows:
クラスの定義は次のとおりです。
( 1.3.6.1.1.6.1.22 NAME 'pcimGroupContainmentAuxClass' DESC 'An auxiliary class used to bind pcimGroups to an appropriate container object.' SUP top AUXILIARY MAY ( pcimGroupsAuxContainedSet ) )
（1.3.6.1.1.6.1.22名「pcimgroupContainmentAuxclass」desc '' PCIMGROUPSを適切なコンテナオブジェクトに結合するために使用される補助クラス。
The attribute pcimGroupsAuxContainedSet provides an unordered set of references to instances of one or more pcimGroups associated with the instance of a structural class to which this attribute has been appended.
属性pcimgroupsauxContededsetは、この属性が追加された構造クラスのインスタンスに関連付けられた1つ以上のPCIMGROUPSのインスタンスの順序付けられていない一連の参照セットを提供します。
The attribute definition is as follows:
属性定義は次のとおりです。
( 1.3.6.1.1.6.2.38 NAME 'pcimGroupsAuxContainedSet' DESC 'DNs of pcimGroups associated in some way with the instance to which this attribute has been appended.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
（1.3.6.1.1.6.2.38名「PCIMGROUPSAUXCONTENSEST 'DESC」DNSは、この属性が追加されたインスタンスに何らかの方法で関連付けられています。
Note that the cn attribute does NOT have to be defined for this class for the same reasons as those given for the pcimSubtreesPtrAuxClass in section 5.15.
セクション5.15のPCIMSUBTREESPTRAUXCLASSに与えられた理由と同じ理由で、CN属性をこのクラスで定義する必要はないことに注意してください。
This auxiliary class provides a single, multi-valued attribute that references a set of pcimRules. By attaching this attribute to instances of various other classes, a policy administrator has a flexible way of providing an entry point into the directory that allows a client to locate and retrieve the pcimRules relevant to it.
この補助クラスは、PCimrulesのセットを参照する単一の多値の属性を提供します。この属性を他のさまざまなクラスのインスタンスに添付することにより、ポリシー管理者は、クライアントが関連するPCimrulesを見つけて検索できるようにするディレクトリにエントリポイントを提供する柔軟な方法を持っています。
A policy administrator might have several different references to a pcimRule in the overall directory structure. For example, there might be references to all pcimRules for traffic originating in a particular subnet from a directory entry that represents that subnet. At the same time, there might be references to all pcimRules related to a particular DiffServ setting from an instance of a pcimGroup explicitly introduced as a container for DiffServ-related pcimRules. The pcimRuleContainmentAuxClass is the mechanism that makes it possible for the policy administrator to define all these separate references.
ポリシー管理者は、ディレクトリ構造全体にPCimruleにいくつかの異なる参照を持っている可能性があります。たとえば、そのサブネットを表すディレクトリエントリから特定のサブネットに由来するトラフィックについては、すべてのPCIMRULEへの参照がある場合があります。同時に、Diffserv関連PCimrulesのコンテナとして明示的に導入されたPCIMGROUPのインスタンスのインスタンスから、特定のDiffServ設定に関連するすべてのPCIMRULEへの参照があるかもしれません。pcimrulecontainmentauxclassは、ポリシー管理者がこれらすべての個別の参照を定義することを可能にするメカニズムです。
The class definition is as follows:
クラスの定義は次のとおりです。
( 1.3.6.1.1.6.1.23 NAME 'pcimRuleContainmentAuxClass' DESC 'An auxiliary class used to bind pcimRules to an appropriate container object.' SUP top AUXILIARY MAY ( pcimRulesAuxContainedSet ) )
（1.3.6.1.1.6.1.23名「pcimrulecontainmentauxclass 'desc' 'pcimrulesを適切なコンテナオブジェクトに結合するために使用される補助クラス。
The attribute pcimRulesAuxContainedSet provides an unordered set of references to one or more instances of pcimRules associated with the instance of a structural class to which this attribute has been appended. The attribute definition is as follows:
属性PCIMRULESAUXCONTEDENSESTは、この属性が追加された構造クラスのインスタンスに関連付けられたPCIMRULEの1つまたは複数のインスタンスへの順序付けられていない一連の参照セットを提供します。属性定義は次のとおりです。
( 1.3.6.1.1.6.2.39 NAME 'pcimRulesAuxContainedSet' DESC 'DNs of pcimRules associated in some way with the instance to which this attribute has been appended.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
（1.3.6.1.1.6.2.39名「PCIMRULESAUXCONTENSEST 'DESC' DNS」DNSは、この属性が追加されたインスタンスに何らかの方法で関連付けられています。
The cn attribute does NOT have to be defined for this class for the same reasons as those given for the pcimSubtreesPtrAuxClass in section 5.15.
CN属性は、セクション5.15のPCIMSubTreesPtrauxclassに与えられた理由と同じ理由で、このクラスで定義する必要はありません。
The following subsections provide general guidance on how to create a domain-specific schema derived from this document, discuss how the vendor classes in the PCLS should be used, and explain how policyTimePeriodConditions are related to other policy conditions.
次のサブセクションは、このドキュメントから派生したドメイン固有のスキーマを作成する方法に関する一般的なガイダンスを提供し、PCLのベンダークラスを使用する方法を議論し、PolicyTimeperiodConditionが他のポリシー条件にどのように関連しているかを説明します。
In Section 4.4, there is a discussion of how, by representing policy conditions and policy actions as auxiliary classes in a schema, the flexibility is retained to instantiate a particular condition or action as either rule-specific or reusable. This flexibility is lost if a condition or action class is defined as structural rather than auxiliary. For standardized schemata, this document specifies that domain-specific information MUST be expressed in auxiliary subclasses of pcimConditionAuxClass and pcimActionAuxClass. It is RECOMMENDED that non-standardized schemata follow this practice as well.
セクション4.4では、スキーマ内の補助クラスとしてポリシー条件とポリシーアクションを表現することにより、特定の条件またはアクションをルール固有または再利用可能なものとしてインスタンス化するために柔軟性が保持される方法について説明しています。この柔軟性は、条件またはアクションクラスが補助ではなく構造的なものとして定義されている場合に失われます。標準化されたスキーマの場合、このドキュメントは、ドメイン固有の情報をPCImConditionAuxClassおよびPCIMACTIONAUXCLASSの補助サブクラスで表現する必要があることを指定しています。標準化されていないスキーマもこの慣行に従うことをお勧めします。
As discussed Section 5.9, the attributes pcimVendorConstraintData and pcimVendorConstraintEncoding are included in the pcimConditionVendorAuxClass to provide a mechanism for representing vendor-specific policy conditions that are not amenable to being represented with the pcimCondition class (or its subclasses). The attributes pcimVendorActionData and pcimVendorActionEncoding in the pcimActionVendorAuxClass class play the same role with respect to actions. This enables interoperability between different vendors who could not otherwise interoperate.
セクション5.9で説明したように、属性はpcimvendorconstraintdataとpcimvendorconstraintencodingをpcimconditionvendorauxclassに含まれており、Pcimconditionクラス（またはそのサブクラス化）に表現できないベンダー固有のポリシー条件を表すメカニズムを提供します。PCIMVENDORACTIONDATAおよびPCIMVENDORACTIONENCODING PCIMACTIONVENDORAUXCLASSクラスの属性は、アクションに関して同じ役割を果たします。これにより、そうでなければ相互運用できないさまざまなベンダー間の相互運用性が可能になります。
For example, imagine a network composed of access devices from vendor A, edge and core devices from vendor B, and a policy server from vendor C. It is desirable for this policy server to be able to configure and manage all of the devices from vendors A and B. Unfortunately, these devices will in general have little in common (e.g., different mechanisms, different ways for controlling those mechanisms, different operating systems, different commands, and so forth). The extension conditions provide a way for vendor-specific commands to be encoded as octet strings, so that a single policy server can commonly manage devices from different vendors.
たとえば、ベンダーA、エッジ、コアデバイスからのアクセスデバイス、ベンダーBからのポリシーサーバーで構成されるネットワークを想像してください。このポリシーサーバーがベンダーからすべてのデバイスを構成および管理できることが望ましいAおよびB.残念ながら、これらのデバイスは一般にほとんど共通していません（例えば、さまざまなメカニズム、それらのメカニズムを制御するためのさまざまな方法、異なるオペレーティングシステム、異なるコマンドなど）。拡張条件は、ベンダー固有のコマンドをオクテット文字列としてエンコードする方法を提供し、単一のポリシーサーバーが一般に異なるベンダーのデバイスを管理できるようにします。
Time validity periods are defined as an auxiliary subclass of pcimConditionAuxClass, called pcimTPCAuxClass. This is to allow their inclusion in the AND/OR condition definitions for a pcimRule. Care should be taken not to subclass pcimTPCAuxClass to add domain-specific condition properties.
時間の妥当性期間は、pcimtpcauxclassと呼ばれるpcimconditionauxclassの補助サブクラスとして定義されます。これは、PCimruleのおよび/または状態定義にそれらを含めることを可能にするためです。ドメイン固有の条件特性を追加するために、PCIMTPCAUXCLASSをサブクラス化しないように注意する必要があります。
For example, it would be incorrect to add IPsec- or QoS-specific condition properties to the pcimTPCAuxClass class, just because IPsec or QoS includes time in its condition definition. The correct subclassing would be to create IPsec or QoS-specific subclasses of pcimConditionAuxClass and then combine instances of these domain-specific condition classes with the appropriate validity period criteria. This is accomplished using the AND/OR association capabilities for policy conditions in pcimRules.
たとえば、IPSECまたはQOSが条件定義に時間が含まれているという理由だけで、IPSECまたはQOS固有の条件特性をPCIMTPCAUXCLASSクラスに追加することは間違っています。正しいサブクラス化は、PCIMConditionAuxClassのIPSECまたはQOS固有のサブクラスを作成し、これらのドメイン固有の条件クラスのインスタンスを適切な妥当性期間基準と組み合わせることです。これは、PCIMRULEのポリシー条件のためのおよび/または協会の機能を使用して達成されます。
The PCLS, presented in this document, provides a mapping of the object-oriented model for describing policy information (PCIM) into a data model that forms the basic framework for describing the structure of policy data, in the case where the policy repository takes the form of an LDAP-accessible directory.
このドキュメントで提示されているPCLSは、ポリシーリポジトリが撮影する場合のポリシーデータの構造を説明するための基本的なフレームワークを形成するデータモデル（PCIM）を説明するためのオブジェクト指向モデルのマッピングを提供します。LDAPアクセス可能なディレクトリの形式。
PCLS is not intended to represent any particular system design or implementation. PCLS is not directly useable in a real world system, without the discipline-specific mappings that are works in progress in the Policy Framework Working Group of the IETF.
PCLSは、特定のシステム設計または実装を表すことを意図したものではありません。PCLSは、IETFのポリシーフレームワークワーキンググループで進行中の規律固有のマッピングなしでは、実際のシステムでは直接使用できません。
These other derivative documents, which use PCIM and its discipline-specific extensions as a base, will need to convey more specific security considerations (refer to RFC 3060 for more information.) The reason that PCLS, as defined here, is not representative of any real-world system, is that its object classes were designed to be independent of any specific discipline, or policy domain. For example, DiffServ and IPsec represent two different policy domains. Each document that extends PCIM to one of these domains will derive subclasses from the classes and relationships defined in PCIM, in order to represent extensions of a generic model to cover specific technical domains.
PCIMとその規律固有の拡張機能をベースとして使用するこれらの他のデリバティブドキュメントは、より具体的なセキュリティに関する考慮事項を伝える必要があります（詳細については、RFC 3060を参照してください。）ここで定義されているPCLSは、現実世界のシステムは、そのオブジェクトクラスは、特定の規律またはポリシードメインとは独立しているように設計されていることです。たとえば、diffservとipsecは2つの異なるポリシードメインを表します。PCIMをこれらのドメインのいずれかに拡張する各ドキュメントは、特定の技術ドメインをカバーする一般的なモデルの拡張を表すために、PCIMで定義されたクラスと関係からサブクラスを導き出します。
PCIM-derived documents will thus subclass the PCIM classes into classes specific to each technical policy domain (QOS, IPsec, etc.), which will, in turn, be mapped, to directory-specific schemata consistent with the PCLS documented here.
したがって、PCIM由来のドキュメントは、PCIMクラスを各技術ポリシードメイン（QOS、IPSECなど）に固有のクラスにサブクラス化し、ここで文書化されたPCLSと一致するディレクトリ固有のスキーマにマッピングされます。
Even though discipline-specific security requirements are not appropriate for PCLS, specific security requirements MUST be defined for each operational real-world application of PCIM. Just as there will be a wide range of operational, real-world systems using PCIM, there will also be a wide range of security requirements for these systems. Some operational, real-world systems that are deployed using PCLS may have extensive security requirements that impact nearly all object classes utilized by such a system, while other systems' security requirements might have very little impact.
PCLSには規律固有のセキュリティ要件が適切ではありませんが、PCIMの運用上の現実世界アプリケーションごとに特定のセキュリティ要件を定義する必要があります。PCIMを使用して幅広い運用上の実世界のシステムがあるように、これらのシステムには幅広いセキュリティ要件もあります。PCLSを使用して展開されている運用上の現実世界の一部のシステムには、そのようなシステムが利用するほぼすべてのオブジェクトクラスに影響を与える広範なセキュリティ要件がありますが、他のシステムのセキュリティ要件はほとんど影響を与えない可能性があります。
The derivative documents, discussed above, will create the context for applying operational, real-world, system-level security requirements against the various models that derive from PCIM, consistent with PCLS.
上記のデリバティブ文書は、PCLSと一致するPCIMに由来するさまざまなモデルに対して、運用上の実際のシステムレベルのセキュリティ要件を適用するためのコンテキストを作成します。
In some real-world scenarios, the values associated with certain properties, within certain instantiated object classes, may represent information associated with scarce, and/or costly (and therefore valuable) resources. It may be the case that these values must not be disclosed to, or manipulated by, unauthorized parties.
いくつかの実際のシナリオでは、特定のインスタンス化されたオブジェクトクラス内の特定のプロパティに関連する値は、希少性に関連する情報、および/または費用のかかる（したがって価値のある）リソースを表す場合があります。これらの値を不正な当事者に開示したり、操作したりしてはならない場合があります。
Since this document forms the basis for the representation of a policy data model in a specific format (an LDAP-accessible directory), it is herein appropriate to reference the data model-specific tools and mechanisms that are available for achieving the authentication and authorization implicit in a requirement that restricts read and/or read- write access to these values stored in a directory.
このドキュメントは、特定の形式（LDAPアクセス可能なディレクトリ）でポリシーデータモデルの表現の基礎を形成するため、ここでは、認証と承認を達成するために利用可能なデータモデル固有のツールとメカニズムを参照することが適切です。ディレクトリに保存されているこれらの値への読み取りおよび/または読み取りアクセスを制限する要件で。
General LDAP security considerations apply, as documented in RFC 3377 [2]. LDAP-specific authentication and authorization tools and mechanisms are found in the following standards track documents, which are appropriate for application to the management of security applied to policy data models stored in an LDAP-accessible directory:
RFC 3377 [2]に記載されているように、一般的なLDAPセキュリティに関する考慮事項が適用されます。LDAP固有の認証と承認ツールとメカニズムは、LDAPアクセス可能なディレクトリに保存されているポリシーデータモデルに適用されるセキュリティの管理への適用に適した次の標準トラックドキュメントにあります。
- RFC 2829 (Authentication Methods for LDAP) - RFC 2830 (Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security)
- RFC 2829（LDAPの認証方法）-RFC 2830（LightWeight Directory Access Protocol（V3）：輸送層のセキュリティの拡張）
Any identified security requirements that are not dealt with in the appropriate discipline-specific information model documents, or in this document, MUST be dealt with in the derivative data model documents which are specific to each discipline.
適切な規律固有の情報モデルドキュメントで、またはこのドキュメントでは、特定されたセキュリティ要件は、各分野に固有の派生データモデルドキュメントで対処する必要があります。
Refer to RFC 3383, "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)" [16].
RFC 3383を参照してください。「Internet Assigned Numbers Authority（IANA）の考慮事項に関するLightweight Directory Access Protocol（LDAP）」[16]。
The IANA has registered an LDAP Object Identifier for use in this technical specification according to the following template:
IANAは、次のテンプレートに従って、この技術仕様で使用するためのLDAPオブジェクト識別子を登録しています。
Subject: Request for LDAP OID Registration Person & email address to contact for further information: Bob Moore (remoore@us.ibm.com) Specification: RFC 3703 Author/Change Controller: IESG Comments: The assigned OID will be used as a base for identifying a number of schema elements defined in this document.
件名：LDAP OID登録担当者のリクエスト担当者とメールアドレスを連絡先に連絡先このドキュメントで定義されている多くのスキーマ要素を識別します。
IANA has assigned an OID of 1.3.6.1.1.6 with the name of pcimSchema to this registration as recorded in the following registry:
IANAは、次のレジストリに記録されているように、この登録にPCIMSchemaの名前を持つ1.3.6.1.1.6のOIDを割り当てました。
http://www.iana.org/assignments/smi-numbers
http://www.iana.org/assignments/smi-numbers
The IANA has registered the LDAP Descriptors used in this technical specification as detailed in the following template:
IANAは、次のテンプレートで詳述されているように、この技術仕様で使用されるLDAP記述子を登録しています。
Subject: Request for LDAP Descriptor Registration Update Descriptor (short name): see comment Object Identifier: see comment Person & email address to contact for further information: Bob Moore (remoore@us.ibm.com) Usage: see comment Specification: RFC 3703 Author/Change Controller: IESG Comments:
件名：LDAP記述子登録更新記述子（ショート名）のリクエスト：コメントオブジェクト識別子を参照：詳細については、連絡先のコメント担当者とメールアドレスを参照：Bob Moore（remaore@us.ibm.com）使用法：コメント仕様：RFC 3703著者/変更コントローラー：IESGコメント：
The following descriptors have been added:
次の記述子が追加されました：
NAME Type OID
-------------- ---- ------------
pcimPolicy O 1.3.6.1.1.6.1.1
pcimGroup O 1.3.6.1.1.6.1.2
pcimGroupAuxClass O 1.3.6.1.1.6.1.3
pcimGroupInstance O 1.3.6.1.1.6.1.4
pcimRule O 1.3.6.1.1.6.1.5
pcimRuleAuxClass O 1.3.6.1.1.6.1.6
pcimRuleInstance O 1.3.6.1.1.6.1.7
pcimRuleConditionAssociation O 1.3.6.1.1.6.1.8
pcimRuleValidityAssociation O 1.3.6.1.1.6.1.9
pcimRuleActionAssociation O 1.3.6.1.1.6.1.10
pcimConditionAuxClass O 1.3.6.1.1.6.1.11
pcimTPCAuxClass O 1.3.6.1.1.6.1.12
pcimConditionVendorAuxClass O 1.3.6.1.1.6.1.13
pcimActionAuxClass O 1.3.6.1.1.6.1.14
pcimActionVendorAuxClass O 1.3.6.1.1.6.1.15
pcimPolicyInstance O 1.3.6.1.1.6.1.16
pcimElementAuxClass O 1.3.6.1.1.6.1.17
pcimRepository O 1.3.6.1.1.6.1.18
pcimRepositoryAuxClass O 1.3.6.1.1.6.1.19
pcimRepositoryInstance O 1.3.6.1.1.6.1.20
pcimSubtreesPtrAuxClass O 1.3.6.1.1.6.1.21
pcimGroupContainmentAuxClass O 1.3.6.1.1.6.1.22
pcimRuleContainmentAuxClass O 1.3.6.1.1.6.1.23
pcimKeywords A 1.3.6.1.1.6.2.3
pcimGroupName A 1.3.6.1.1.6.2.4
pcimRuleName A 1.3.6.1.1.6.2.5
pcimRuleEnabled A 1.3.6.1.1.6.2.6
pcimRuleConditionListType A 1.3.6.1.1.6.2.7
pcimRuleConditionList A 1.3.6.1.1.6.2.8
pcimRuleActionList A 1.3.6.1.1.6.2.9
pcimRuleValidityPeriodList A 1.3.6.1.1.6.2.10
pcimRuleUsage A 1.3.6.1.1.6.2.11
pcimRulePriority A 1.3.6.1.1.6.2.12
pcimRuleMandatory A 1.3.6.1.1.6.2.13
pcimRuleSequencedActions A 1.3.6.1.1.6.2.14
pcimRoles A 1.3.6.1.1.6.2.15
pcimConditionGroupNumber A 1.3.6.1.1.6.2.16
NAME Type OID
-------------- ---- ------------
pcimConditionNegated A 1.3.6.1.1.6.2.17
pcimConditionName A 1.3.6.1.1.6.2.18
pcimConditionDN A 1.3.6.1.1.6.2.19
pcimValidityConditionName A 1.3.6.1.1.6.2.20
pcimTimePeriodConditionDN A 1.3.6.1.1.6.2.21
pcimActionName A 1.3.6.1.1.6.2.22
pcimActionOrder A 1.3.6.1.1.6.2.23
pcimActionDN A 1.3.6.1.1.6.2.24
pcimTPCTime A 1.3.6.1.1.6.2.25
pcimTPCMonthOfYearMask A 1.3.6.1.1.6.2.26
pcimTPCDayOfMonthMask A 1.3.6.1.1.6.2.27
pcimTPCDayOfWeekMask A 1.3.6.1.1.6.2.28
pcimTPCTimeOfDayMask A 1.3.6.1.1.6.2.29
pcimTPCLocalOrUtcTime A 1.3.6.1.1.6.2.30
pcimVendorConstraintData A 1.3.6.1.1.6.2.31
pcimVendorConstraintEncoding A 1.3.6.1.1.6.2.32
pcimVendorActionData A 1.3.6.1.1.6.2.33
pcimVendorActionEncoding A 1.3.6.1.1.6.2.34
pcimPolicyInstanceName A 1.3.6.1.1.6.2.35
pcimRepositoryName A 1.3.6.1.1.6.2.36
pcimSubtreesAuxContainedSet A 1.3.6.1.1.6.2.37
pcimGroupsAuxContainedSet A 1.3.6.1.1.6.2.38
pcimRulesAuxContainedSet A 1.3.6.1.1.6.2.39
where Type A is Attribute, Type O is ObjectClass
タイプAが属性である場合、タイプOはオブジェクトクラスです
These assignments are recorded in the following registry:
これらの割り当ては、次のレジストリに記録されます。
http://www.iana.org/assignments/ldap-parameters
http://www.iana.org/assignments/ldap-parameters
We would like to thank Kurt Zeilenga, Roland Hedburg, and Steven Legg for doing a review of this document and making many helpful suggestions and corrections.
この文書のレビューを行い、多くの有益な提案と修正を行ってくれたKurt Zeilenga、Roland Hedburg、Steven Leggに感謝します。
Several of the policy classes in this model first appeared in early IETF drafts on IPsec policy and QoS policy. The authors of these drafts were Partha Bhattacharya, Rob Adams, William Dixon, Roy Pereira, Raju Rajan, Jean-Christophe Martin, Sanjay Kamat, Michael See, Rajiv Chaudhury, Dinesh Verma, George Powers, and Raj Yavatkar.
このモデルのポリシークラスのいくつかは、IPSECポリシーとQoSポリシーに関する初期のIETFドラフトに最初に登場しました。これらのドラフトの著者は、パルタ・バタチャリヤ、ロブ・アダムス、ウィリアム・ディクソン、ロイ・ペレイラ、ラジュ・ラジャン、ジャン・キリストフ・マーティン、サンジェイ・カマット、マイケル・シー、ラジフ・チョードゥリー、ダージフ・ヴェルマ、ジョージ・パワーズ、ラジ・ヤバトカルでした。
This document is closely aligned with the work being done in the Distributed Management Task Force (DMTF) Policy and Networks working groups. We would especially like to thank Lee Rafalow, Glenn Waters, David Black, Michael Richardson, Mark Stevens, David Jones, Hugh Mahon, Yoram Snir, and Yoram Ramberg for their helpful comments.
このドキュメントは、分散管理タスクフォース（DMTF）ポリシーおよびネットワークのワーキンググループで行われている作業と密接に整合しています。Lee Rafalow、Glenn Waters、David Black、Michael Richardson、Mark Stevens、David Jones、Hugh Mahon、Yoram Snir、Yoram Rambergの有益なコメントに感謝します。
This appendix is non-normative, and is included in this document as a guide to implementers that wish to exchange information between CIM schemata and LDAP schemata.
この付録は非規範的であり、CIMスキーマとLDAPスキーマの間で情報を交換したい実装者へのガイドとしてこのドキュメントに含まれています。
Within a CIM name space, the naming is basically flat; all instances are identified by the values of their key properties, and each combination of key values must be unique. A limited form of hierarchical naming is available in CIM, however, by using weak associations: since a weak association involves propagation of key properties and their values from the superior object to the subordinate one, the subordinate object can be thought of as being named "under" the superior object. Once they have been propagated, however, propagated key properties and their values function in exactly the same way that native key properties and their values do in identifying a CIM instance.
CIM名空間内では、命名は基本的にフラットです。すべてのインスタンスは、キープロパティの値によって識別され、キー値の各組み合わせは一意でなければなりません。ただし、弱い関連性を使用することにより、CIMでは限られた形式の階層的命名が利用可能です。弱い関連には、優れたオブジェクトから下位オブジェクトへの主要な特性とその値の伝播が含まれるため、下位オブジェクトは名前が付けられていると考えることができます。「優れたオブジェクトの下。ただし、それらが伝播されると、キープロパティとその値は、ネイティブのキープロパティとその値がCIMインスタンスを識別するのとまったく同じ方法で機能します。
The CIM mapping document [6] introduces a special attribute, orderedCIMKeys, to help map from the CIM_ManagedElement class to the LDAP class dlm1ManagedElement. This attribute SHOULD only be used in an environment where it is necessary to map between an LDAP-accessible directory and a CIM repository. For an LDAP environment, other LDAP naming attributes are defined (i.e., cn and a class-specific naming attribute) that SHOULD be used instead.
CIMマッピングドキュメント[6]は、CIM_MANAGEDELEMENTクラスからLDAPクラスDLM1ManagedElementにマップするのに役立つ特別な属性（OrderedCimkeys）を導入します。この属性は、LDAPアクセス可能なディレクトリとCIMリポジトリの間でマッピングする必要がある環境でのみ使用する必要があります。LDAP環境の場合、代わりに使用する必要がある他のLDAP命名属性（つまり、CNおよびクラス固有のネーミング属性）が定義されます。
The role of orderedCIMKeys is to represent the information necessary to correlate an entry in an LDAP-accessible directory with an instance in a CIM name space. Depending on how naming of CIM-related entries is handled in an LDAP directory, the value of orderedCIMKeys represents one of two things:
OrderedCimkeysの役割は、LDAPアクセス可能なディレクトリのエントリをCIM名空間のインスタンスと相関させるために必要な情報を表すことです。CIM関連のエントリの命名がLDAPディレクトリでどのように処理されるかに応じて、OrderedCimkeysの値は2つのことのいずれかを表します。
- If the DIT hierarchy does not mirror the "weakness hierarchy" of the CIM name space, then orderedCIMKeys represents all the keys of the CIM instance, both native and propagated. - If the DIT hierarchy does mirror the "weakness hierarchy" of the CIM name space, then orderedCIMKeys may represent either all the keys of the instance, or only the native keys.
- DIT階層がCIM名空間の「弱い階層」を反映していない場合、OrderedCimkeysは、ネイティブと伝播の両方のCIMインスタンスのすべてのキーを表します。-DIT階層がCIM名空間の「弱い階層」を反映している場合、注文されたCimkeysは、インスタンスのすべてのキーを表すか、ネイティブキーのみを表すことができます。
Regardless of which of these alternatives is taken, the syntax of orderedCIMKeys is the same - a DirectoryString of the form
これらの選択肢のどれに関係なく、OrderedCimkeysの構文は同じです - フォームのディレクトリストリング
<className>.<key>=<value>[,<key>=<value>]*
where the <key>=<value> elements are ordered by the names of the key properties, according to the collating sequence for US ASCII. The only spaces allowed in the DirectoryString are those that fall within a <value> element. As with alphabetizing the key properties, the goal of suppressing the spaces is once again to make the results of string operations predictable.
ここで、US ASCIIの照合シーケンスに従って、<key> = <value>要素はキープロパティの名前によって順序付けられます。DirectoryStringで許可されている唯一のスペースは、<value>要素内に該当するスペースです。主要な特性のアルファベット順と同様に、スペースを抑制するという目標は、文字列操作の結果を予測可能にすることです。
The values of the <value> elements are derived from the various CIM syntaxes according to a grammar specified in [5].
<value>要素の値は、[5]で指定された文法に従って、さまざまなCIM構文から導出されます。
[1] Moore, B., Ellesson,E., Strassner, J. and A. Westerinen "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001.
[1] Moore、B.、Ellesson、e。、Strassner、J。およびA. Westerinen「ポリシーコア情報モデル - バージョン1仕様」、RFC 3060、2001年2月。
[2] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[2] Hodges、J。およびR. Morgan、「Lightweight Directory Access Protocol（V3）：技術仕様」、RFC 3377、2002年9月。
[3] Wahl, M., Coulbeck, A., Howes,T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[3] Wahl、M.、Coulbeck、A.、Howes、T。およびS. Kille、「Lightweight Directory Access Protocol（V3）：属性構文定義」、RFC 2252、1997年12月。
[4] The Directory: Models. ITU-T Recommendation X.501, 2001.
[4] ディレクトリ：モデル。ITU-T推奨X.501、2001。
[5] Distributed Management Task Force, Inc., "Common Information Model (CIM) Specification", Version 2.2, June 14, 1999. This document is available on the following DMTF web page: http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf
[5] 分散管理タスクフォース、Inc。、「Common Information Model（CIM）仕様」、バージョン2.2、1999年6月14日。このドキュメントは、次のDMTF Webページで入手できます：http：//www.dmtf.org/standards/documents/cim/dsp0004.pdf
[6] Distributed Management Task Force, Inc., "DMTF LDAP Schema for the CIM v2.5 Core Information Model", April 15, 2002. This document is available on the following DMTF web page: http://www.dmtf.org/standards/documents/DEN/DSP0123.pdf
[6] 2002年4月15日、「CIM V2.5コア情報モデル用のDMTF LDAPスキーマ」、分配管理タスクフォース、Inc。。このドキュメントは、次のDMTF Webページで入手できます。/documents/den/dsp0123.pdf
[7] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997.
[7] Wahl、M。、「LDAPV3で使用するX.500（96）ユーザースキーマの要約」、RFC 2256、1997年12月。
[8] The Directory: Selected Attribute Types. ITU-T Recommendation X.520, 2001.
[8] ディレクトリ：選択された属性タイプ。ITU-T推奨X.520、2001。
[9] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Additional Matching Rules", RFC 3698, February 2004.
[9] Zeilenga、K.、ed。、「Lightweight Directory Access Protocol（LDAP）：追加マッチングルール」、RFC 3698、2004年2月。
[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[10] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[11] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.
[11] Hovey、R。およびS. Bradner、「IETF標準プロセスに関与する組織」、BCP 11、RFC 2028、1996年10月。
[12] Strassner, J., policy architecture BOF presentation, 42nd IETF Meeting, Chicago, Illinois, October 1998. Minutes of this BOF are available at the following location: http://www.ietf.org/proceedings/98aug/index.html.
[12] Strassner、J.、ポリシーアーキテクチャBOFプレゼンテーション、イリノイ州シカゴの第42 IETFミーティング、1998年10月。
[13] Yavatkar, R., Guerin, R. and D. Pendarakis, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[13] Yavatkar、R.、Guerin、R。、およびD. Pendarakis、「政策ベースの入場管理の枠組み」、RFC 2753、2000年1月。
[14] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000
[14] Wahl、M.、Alvestrand、H.、Hodges、J。およびR. Morgan、「LDAPの認証方法」、RFC 2829、2000年5月
[15] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000.
[15] Hodges、J.、Morgan、R。、およびM. Wahl、「Lightweight Directory Access Protocol（V3）：輸送層のセキュリティの拡張」、RFC 2830、2000年5月。
[16] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
[16] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）のインターネット割り当てされた数字権（IANA）の考慮事項」、BCP 64、RFC 3383、2002年9月。
John Strassner Intelliden Corporation 90 South Cascade Avenue Colorado Springs, CO 80903
John Strassner Intelliden Corporation 90サウスカスケードアベニューコロラドスプリングス、CO 80903
Phone: +1.719.785.0648
Fax: +1.719.785.0644
EMail: john.strassner@intelliden.com
Bob Moore IBM Corporation P. O. Box 12195, BRQA/B501/G206 3039 Cornwallis Rd. Research Triangle Park, NC 27709-2195
Bob Moore IBM Corporation P. O. Box 12195、BRQA/B501/G206 3039 Cornwallis Rd。研究トライアングルパーク、NC 27709-2195
Phone: +1 919-254-4436
Fax: +1 919-254-6243
EMail: remoore@us.ibm.com
Ryan Moats Lemur Networks, Inc. 15621 Drexel Circle Omaha, NE 68135
Ryan Moats Lemur Networks、Inc。15621 Drexel Circle Omaha、NE 68135
Phone: +1-402-894-9456
EMail: rmoats@lemurnetworks.net
Ed Ellesson 3026 Carriage Trail Hillsborough, NC 27278
エドエルソン3026キャリッジトレイルヒルズボロ、ノースカロライナ州27278
Phone: +1 919-644-3977
EMail: ellesson@mindspring.com
Copyright (C) The Internet Society (2004). 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.
著作権（c）The Internet Society（2004）。この文書は、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 currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。