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
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）インターネット協会（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.
この文書では、そのアクセスプロトコルとしてLDAP（Lightweight Directory Access Protocol）を使用するディレクトリで実行することができる形に方針コア情報モデルのマッピングを定義します。 RFC 3060で指定されたポリシーデータを表現し、制御するための情報を表す構造クラス、および構造クラスのインスタンスが互いにどのように関連しているかを示す関係クラス：このモデルは、2つのオブジェクトクラスの階層を定義します。クラスは、クライアントがポリシー関連情報を大量に取得しているときに、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]で指定されるようにポリシーデータを表現し、制御するための情報を表現するためのオブジェクト指向の情報モデルをとります。 LDAP（Lightweight Directory Access Protocol）は、[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を使用するディレクトリにこれらの情報モデルクラスのマッピングを定義します。マッピングの二つのタイプが関与しています：
- 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).
- 情報モデルのリレーションシップクラスの場合、異なるマッピングが可能です。この文書では、方針コア情報モデル'S（PCIM年代）リレーションシップクラスとそのプロパティは、以下の3つの方法でマッピングされている：LDAP補助クラスに、識別名を表す属性（DN）参照にし、ディレクトリ情報ツリーに優れ、部下の関係に（ 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」を使用しています。それは10の非常に一般的なクラスから構成されていますpcimPolicy（抽象クラス）、3つのポリシーグループクラス（pcimGroup、pcimGroupAuxClass、およびpcimGroupInstance）、3つのポリシールールクラス（pcimRule、pcimRuleAuxClass、およびpcimRuleInstance）、および3つの特別補助クラス（pcimConditionAuxClass、pcimTPCAuxClass 、およびpcimActionAuxClass）。 （そのため、私たちはpcimTPCAuxClassになるこの名前を省略している。PolicyTimePeriodCondition補助クラスが[1]正常に命名されていたであろうpcimTimePeriodConditionAuxClassで定義されていることに注意しますが、この名前は、いくつかのディレクトリのために長すぎます）。
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クラスのために定義されています。まず、抽象スーパークラスは、各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つの以下の一般的なクラスが含まれています。 pcimGroupContainmentAuxClassとpcimRuleContainmentAuxClass：情報モデルの関係のマッピングを実現するために、スキーマは、2つの補助クラスが含まれています。 pcimRuleConditionAssociation、pcimRuleValidityAssociation、pcimRuleActionAssociation、pcimPolicyInstance、三のポリシーリポジトリクラス（pcimRepository、pcimRepositoryAuxClass、及びpcimRepositoryInstance）：ルール固有および再利用可能なポリシー条件とポリシー・アクションとの間の区別を捕捉する他の七つのクラスを導入します。最後に、スキーマは、LDAP回収のを最適化するための2つのクラス（pcimSubtreesPtrAuxClassとpcimElementAuxClass）を含みます。すべてでは、スキーマは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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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つの仕」このドキュメントは、仲間の文書で定義されたクラスを表すLDAPスキーマが含まれている[1]。他の文書は、その後、他のストレージ技術へのこの同じ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
PCLS図1. 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を使用するディレクトリのための特定の最適化が含まれています。この一例は、情報モデルで定義された関連付けの一部を表す補助クラスを使用することです。他のデータストアは異なり、これらの関連付けを実装する必要があります。第二の例は、具体的には、ディレクトリからポリシー関連の大量のデータの検索を最適化するように設計されたクラスの導入です。このセクションでは、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は、そのアクセスプロトコルとしてLDAPを使用するディレクトリで表現できる形式に[1]で定義されたクラスと関連をマッピングに使用される戦略について説明します。 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のクラスのフィフティーンは、情報モデルの9つの対応するクラスから直接来ます。しかし、LDAPでの小文字で、クラスの名前は、情報モデルの大文字（特にCIMのために、ケースは、クラスとプロパティ名に重要ではありませんが）で始まることに注意してください。 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
LDAPの情報モデルクラスの図2.マッピング
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でのDN（識別名）またはディレクトリ情報ツリー（DIT）封じ込め（すなわち、優れた-従属関係）に参照属性に情報モデルマップで団体。 DNを参照する属性の二つは、それらのそれぞれは、情報モデルからいくつかの関係を表すためにできるように補助クラス、で表示されます。
+----------------------------------+----------------------------------+
| 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
LDAPの情報モデルアソシエーションの図3のマッピング
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、pcimRuleConditionAssociation、pcimRuleValidityAssociation、pcimRuleActionAssociation、およびpcimPolicyInstanceの残りの4つのクラスは、すべてのポリシーの条件と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の使用はない優れた構造の規則構造化オブジェクトクラスがサブスキーマ管理ポイントであることを必要とします。これは、私たちがポリシー情報のために欲しいものを正確ではありません。補助クラスはサブクラス化されたときに、コンテンツルールは、補助クラスを指す構造クラスのために存在する場合には、第2、、、そのコンテンツルールは、拡張される必要があります。最後に、ほとんどの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.
ディレクトリ内のインスタンスは、ファイルシステムは、コンピュータ・システムに提供階層的な組織の同じ種類を提供識別名（DN）によって識別されます。識別名は、相対識別名のシーケンスです。 RDNは、ファイル名はそれが存在するフォルダのコンテキスト内のファイルの一意の識別子を提供するのと同じ方法で、そのすぐ優れのコンテキスト内でインスタンスの一意の識別子を提供します。
To preserve maximum naming flexibility for policy administrators, three optional (i.e., "MAY") naming attributes have been defined. They are:
ポリシー管理者のための最大の命名の柔軟性を維持するために、3つのオプション（すなわち、「MAY」）の命名属性が定義されています。彼らです：
- 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.
- このスキーマで定義された構造の各クラスは、独自のユニークな（「MAY」）の命名属性を持っています。命名属性が異なるため、ポリシー管理者は、これらの属性を使用することで、同じ値がインスタンスのそれぞれの命名属性に割り当てられている場合でも、異なるクラスのインスタンス間では、名前の衝突がないことを保証することができます。
- 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).
- 抽象クラスpcimPolicyで、したがって、そのサブクラスのすべてで継承によってMAY属性としてLDAP属性のcn（X.500のcommonNameのに相当）が含まれています。 X.500では、commonNameのは、一般的に多くのクラス（例えば、X.500の人クラス）のインスタンスに名前を付けるために、RDN属性として機能します。
- 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.
これらの属性の2つ以上がマルチパートのRDNのサポートは既存のディレクトリの実装の間で制限されるため、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つのポリシー条件の種類とポリシー・アクションとを区別する。ルール特定の条件またはアクションと、再利用可能な1の間には、固有の機能的な違いはないが、使用、並びに、それらの間の実装差の両方があります。
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.再利用可能な条件とアクションは、複数のルールが同じ条件またはアクションを使用している最適化を提供します。再利用可能な条件またはアクションを一度だけ更新される必要があり、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と一つのルール固有のアクション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.
条件とアクションは、ルール1に固有であるため、それらを表す補助クラスのCAとABは構造クラスのCAとABにそれぞれ取り付けられています。これらの構造クラスがない状態CAとアクションAB自身が、ルール1とCAとの間にかなりの関連を表し、ルール1と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に示すように、ルール1は、DITにその下に表示される構造クラスCAとABにDN参照を含みます。一見ルール1以下のサブツリー検索は、ルール1とその条件とアクションの間の関係を表す構造クラスのすべてを見つけるだろうので、これらのDN参照が不要であることを表示される場合があります。サブツリー検索のみに依存、しかし、サブツリーに登場しているはずな条件やアクションが欠落しているのリスクを実行しますが、何らかの理由ではない、または不注意サブツリーに置かれた条件やアクションを見つけることのなかった、またはそれを持っている必要がありますサブツリーから削除されますが、何らかの理由ではありませんでしたされて。実装経験は、これらのリスクの多く（すべてではないが）解消されることを示唆しています。
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. A単純なポリシールール
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.
政策ルールのためのシンプルな/複雑な区別はオール・オア・ナッシングではありません。ポリシー・ルールは、条件がそれ自体に付着し、そのアクションは、他のエントリに取り付けられていてもよい、又はそれは、そのアクションがそれ自体に付着し、その条件は、他のエントリに取り付けられていてもよいです。しかし、それは一つの例外を除いて、その条件や自分自身にして他のエントリの両方に取り付けたそのアクションのいずれかを持っていないもの：政策ルールはpcimRuleValidityPeriodList属性とその有効期間を参照するが、それ自体に取り付けたそのほかの条件を有することができます。
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.
- すべての条件が一緒にAND演算されています。この組み合わせは、ポリシー条件の特性式は、（これらの用語の定義については、[1]参照）選言標準形（DNF）/連言標準形（CNF）内の2つの方法で表すことができる：単一およびグループとDNF式として、または複数の単一条件OR基を有するCNF式として。これらの最初は、任意の単純なポリシールールで論理積条件の表現として選択されます。
- 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を示すが、今回は、その条件とアクションが再利用可能です。関連クラスCAとABはまだ存在している、と彼らはまだルール1の下に含まれているDITあります。むしろ関連クラスCAとABに直接結合補助クラスCA及びABを有するよりも、それぞれは、これらの補助クラスが結合している他のエントリへのDN参照を含みます。これらの他のエントリ、CIAとAIBは、DITは、クラス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）は、ポリシー実行ポイント（PEPは）それはそれは関連する2つの問題に直面している、機能に関連するポリシーオブジェクトのインスタンスを取得するために、LDAPディレクトリに移行した場合：
- 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の最適化クラスの背後にある基本的な考え方は単純なものである：それは可能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参照を持つ複数値の属性が含まれています。おそらく、PDPの初期設定値を含むエントリ、またはPDPを使用するためのPEP - pcimSubtreesPtrAuxClass補助クラスであるので、PDPはとにかくアクセスする必要があるエントリに取り付けることができます。
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".
選択基準は、常に、そのオブジェクトのクラス=「pcimPolicy」を指定します。 PCLSで、そこから派生した任意のドメイン固有のスキーマの両方のポリシールール、ポリシー条件、およびポリシーアクションを、表現するすべてのクラスので、抽象クラスポリシーのサブクラスである、この基準は、これらのクラスのすべてのインスタンスについてTRUEと評価されます。 PDPは、本質的にポリシー関連（例えば、DHCP動作を表すpcimActionAuxClassのサブクラスによって参照されるIPアドレス範囲のオブジェクトは「このアドレス範囲から割り当てる」）、補助クラスpcimElementAuxClassないオブジェクトを取得する必要がある特殊なケースに対応するためそれは選択基準によって発見されるように、「オブジェクト・クラス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属性に補助クラスのマッチングをサポートしていないので、前の段落で説明したアプローチは、特定のディレクトリの実装のために動作しません。これらの実装が存在することが予想される環境では、ポリシーに関連するようなエントリの「タグ付け」（pcimPolicyクラスによって提供される）pcimKeywords属性に含まれる値のリストに特別な値「ポリシー」を挿入することによって達成することができます。
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属性に基づいて、追加の選択基準を使用して構成することができます。この属性は、標準化と管理者 - 定義された値の両方をサポートしています。例えば、PDPは、キーワード「DHCP」と「米国東部」を含むのみポリシー関連のオブジェクトを要求するように構成することができます。
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のエッジポリシー"）。
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は、ちょうど3つのLDAP要求で、すべてのことが必要ポリシー関連オブジェクト、およびオブジェクトのみを得ることができることを参照してください。1その開始オブジェクトAへの参照を取得するにはBおよびC、ならびにそれがAの下のサブツリーから必要なポリシー関連オブジェクト、及びB及びCへ、次に一つずつに、設定されたときの選択基準に合格すべてのポリシー関連のオブジェクトを取得します。それは、これらのオブジェクトのすべてを取得した後、PDPは、それらの間の意味関係を理解するために、ローカルに彼らの様々なDN参照をたどることができます。 PDPはまた、取得したオブジェクトのいずれかに取り付けられた別のサブツリーへの参照を見つけるために準備する必要があり、そしてそれが受信した意味的に有意な参照のいずれかを次の前に、最初にこの基準に従うこと。この再帰は、関連するポリシーを識別する体系的なアプローチが可能になります。 Bの下にあるサブツリーは、部門別の方針を含み、Cの下に一つの分割ポリシーが含まれている場合、図7においては、例えば、その根、企業レベルポリシーのサブツリーオブジェクトDに対するCの下にあるサブツリーからの参照があるかもしれません。
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クライアントはまだそれが必要とするディレクトリエントリにアクセスして取得することができますので、むしろ「MUST」s以下S「すべきである」です。そうすることのプロセスは、ちょうど、クライアントがこれらの最適化を実現していた場合、それはあったであろうよりも効率的になります。
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を使用してアクセスすることができる形式に（リポジトリタイプとアクセス・プロトコルとは無関係である）情報モデルからマッピングを行う方法の仕様です。 （[1]の一部ではなかった）を作成するために必要ないくつかの新しいクラスがLDAPマッピングを実装することを忘れないでください。これらの新しい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
注2：該当する場合、DIT構造およびコンテンツルールを指定する可能性が指摘されています。ただし、注意がDIT構造規則を指定する際に注意する必要があります。 X.501 [4]が述べているからです
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:
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に適用さpcimRulesのすべてを返しますが、彼らはまた、適用されません。その一部（例えば、ロールR1、R2、またはR3のいずれかが含まれたものと役割に存在する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].
抽象クラスpcimPolicyは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 )
)
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
)
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及び/又はPolicyGroupsを可能にする、一般的な凝集機構として機能するのPolicyGroupクラスを定義します。 PCLSは3つのLDAPクラスと呼ばれるpcimGroup、pcimGroupAuxClass、およびpcimGroupInstanceにこのクラスをマッピングします。これは、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関連付けを実現するための属性が含まれていません。 pcimGroupオブジェクトは、それぞれを介しpcimGroupとpcimRuleのインスタンスにpcimGroupContainmentAuxClassオブジェクトクラスの属性pcimGroupsAuxContainedSetとpcimRuleContainmentAuxClassオブジェクトクラスの属性pcimRulesAuxContainedSetを意味するからです。
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クラスは抽象として定義されています。構造サブクラスpcimGroupInstanceスタンドアロンエントリとしてポリシーグループを表すために使用可能である間サブクラスpcimGroupAuxClassは、別のエントリへの補助アタッチメントを提供します。
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 )
)
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の一つの属性は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
)
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
)
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
)
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コンテンツルールは、（pcimRuleContainmentAuxClassを使用して）1つまたは複数のポリシールールにいずれか（pcimGroupContainmentAuxClassを使用して）1つまたは複数のポリシー・グループへの参照または参照に取り付けられていることpcimGroupInstanceのインスタンスを可能にするために書くことができます。これは、[1]のPolicyGroupクラスのセマンティクスを形式化するために使用されます。これらのセマンティクスはのPolicyGroupクラスの任意のプロパティを指定含まれていないので、コンテンツルールは、任意の属性を指定する必要はありません。
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）のいずれかの識別された特定の名前形態を参照してしまうそれぞれが。この構造規則はsuperiorStructureRule（セクション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.
情報モデルは、処理ポリシー情報に関連付けられた「If条件[アクション」の意味を表すために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クラスは抽象として定義されています。構造サブクラスpcimRuleInstanceスタンドアロンエントリとしてポリシールールを表現するために使用可能である間サブクラスpcimRuleAuxClassは、別のエントリへの補助アタッチメントを提供します。
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の補助サブクラスと、それぞれモデル化されます。これらの補助サブクラスの各々は、三つの構造クラスの一つのインスタンスに取り付けられています。 pcimConditionAuxClassのサブクラスはpcimRuleConditionAssociationのインスタンスへの、またはpcimPolicyInstanceのインスタンスに、pcimRuleInstanceのインスタンスに取り付けられています。同様に、pcimActionAuxClassのサブクラスはpcimRuleActionAssociationのインスタンスへの、またはpcimPolicyInstanceのインスタンスに、pcimRuleInstanceのインスタンスに取り付けられています。
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.
（以下に定義）pcimRuleValidityPeriodList属性はPCIMで定義さPolicyRuleValidityPeriodの関連付けを実現します。この関連付けは、その関連するオブジェクトへの関連付けを結ぶものに加えて追加の特性を有していないので、この関連付けは、単に属性を使用して実現することができます。したがって、pcimRuleValidityPeriodList属性は、単にそれが不活性であることが予定されている場合、ポリシールールがアクティブになるようにスケジュールされたときを示す、pcimTPCAuxClassの1つまたは複数のインスタンスへのDN参照の順不同のセットを提供する多値属性です。ポリシールールは、それがこの属性によって参照pcimTPCAuxClassインスタンスの少なくとも一方に応じてアクティブになっている場合にアクティブであることを予定しています。
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とPolicyActionInPolicyRule団体は、しかし、追加の属性を持っています。関連PolicyActionInPolicyRuleアクションを配列決定する整数の属性を定義し、関連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クラスとpcimRuleActionAssociationクラスです。このように、彼らはクラス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条件[アクション」の意味を表現するための基底クラスです。これは次のように定義されます。
( 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 NAME 'pcimRule' DESC 'を表すための基底クラス "If条件[アクション" 政策ルールに関連した意味論' SUP pcimPolicy ABSTRACT MAY（pcimRuleName $ pcimRuleEnabled $ pcimRuleConditionListType $ pcimRuleConditionList $ pcimRuleActionList $ pcimRuleValidityPeriodList $ 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はPolicyRuleのクラスのLDAPと同等であるpcimRuleクラスのための11の属性を定義します。これらの11個の属性のうち、7はPCIMのPolicyRuleのクラスのプロパティを対応から直接マッピングされます。残りの4つの属性は、クラス固有のオプションの命名属性であり、3つの属性はpcimRuleクラスが参加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
)
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:
pcimRuleEnabled属性ポリシールールが管理を有効にするかどうかを示す整数列挙である（値= 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
)
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.
注：pcimRuleEnabled属性の他のすべての値はエラーとみなされ、管理者は、無効な値が検出された場合は無効にされているものとして、このルールを扱うべきです。
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属性はポリシー条件のリストは、このポリシールールに関連付けられているかどうかを示すために使用されるか、連言標準形（CNF、値= 2）選言標準形（DNF値= 1）です。これは次のように定義されます。
( 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.6.2.7 NAME「pcimRuleConditionListType」DESC「1の値は、このポリシー・ルールは、選言標準形であることを意味し、2の値は、このポリシールールは連言標準形であることを意味する」平等integerMatchはintegerOrderingMatch SYNTAXオーダー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]で定義さpolicyRuleInPolicyConditionの関連付けを実現するために使用される多値属性です。これは、このポリシールールとその条件との関連を表すpcimRuleConditionAssociationエントリのDNのセットが含まれています。いかなる順序が暗示されていません。これは次のように定義されます。
( 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 NAME「pcimRuleConditionList」DESC「は、このポリシー・ルールとその条件との間の関連を表すpcimRuleConditionAssociationエントリのDNの順不同組」平等distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12）
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の関連付けを実現するために使用される多値属性です。これは、このポリシールールとその行動との関連性を表すpcimRuleActionAssociationエントリのDNのセットが含まれています。いかなる順序が暗示されていません。これは次のように定義されます。
( 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 NAME「pcimRuleActionList」DESC「このポリシールール及びその作用との間の関連を表すpcimRuleActionAssociationエントリのDNの順不同組」平等distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12）
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:
pcimRuleValidityPeriodList属性は、[1]で定義されpcimRuleValidityPeriodの関連付けを実現するために使用される多値属性です。それはpcimRuleがアクティブまたは非アクティブに予定されている場合を決定pcimRuleValidityAssociationエントリのDNのセットが含まれています。いかなる順序が暗示されていません。これは次のように定義されます。
( 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 NAME「pcimRuleValidityPeriodList」DESC「pcimRuleをアクティブまたは非アクティブであることが予定されているときを決定pcimRuleValidityAssociationエントリのDNの順不同組」平等distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12）
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.6.2.11 NAME「pcimRuleUsage」DESC「この属性は、このポリシーを使用する方法に関するガイドラインを提供する自由形式刺さです。」caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1オーダー平等caseIgnoreMatch。 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属性は、他のpcimRulesに対してこの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 NAME「pcimRulePriority」DESC「他のpcimRulesこのpcimRuleの相対優先順位を付けるための非負整数。大きな値は、より高い優先度を示す。」平等integerMatch integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115オーダー。 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属性がTRUEの場合、（条件が満たされた場合）は、この政策ルールのため、その条件とそのアクションの実行の評価が必要であることを示し、ブール属性です。それがFALSEである場合は、その条件とそのアクションの実行（条件が成立した場合）の評価が必要とされていません。次のようにこの属性が定義されています。
( 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 NAME「pcimRuleMandatory」DESC「TRUEの場合は、条件が満たされた場合、このポリシールールのため、その条件と、そのアクションの実行の評価（）が必要であることを示している。」平等booleanMatch SYNTAX 1.3。 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:
pcimRuleSequencedActions属性pcimActionOrder属性によって定義されたアクションの順序があることを示すために使用される整数の列挙のいずれか必須（値= 1）、推奨（値= 2）、またはDONTCARE（値= 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
（1.3.6.1.1.6.2.14 NAME 'pcimRuleSequencedActions' DESC平等integerMatch順序付けintegerOrderingMatch 'pcimActionOrder属性で定義されたアクションの順序は、（1）、（3）必須（2）推奨、またはDONTCAREされる。示す整数列挙'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE）
Note: if the value of pcimRulesSequencedActions field is not one of these three values, then Administrators SHOULD treat this rule as being disabled.
注意：pcimRulesSequencedActionsフィールドの値がこれらの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プロパティを表します。 <ロール名> [&& <ロール名>] *個々のロール名は、UCS-2の照合順序に従ってアルファベット順に表示されます。この属性の各値は、次の形式の文字列である役割の組み合わせを表します。次のようにこの属性が定義されています。
( 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 NAME 'pcimRoles' DESC 'この属性の各値は、役割の組み合わせを表す。' 平等caseIgnoreMatchがcaseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15オーダー）
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の値はフォーマットに準拠していない属性場合は「<ロール名> [&& <ロール名>] *」この属性が不正な形式であり、そのポリシールールがあるべき、（[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条件[アクション」の意味を表すための補助クラスです。次のようにそのクラス定義は次のとおりです。
( 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.1.6 NAME「pcimRuleAuxClass」DESC「ポリシールールに関連付けられている 『条件であれば、その後のアクション』の意味を表すための補助クラスを」SUP pcimRule補助）
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条件[アクション」の意味を表現するための構造的なクラスです。次のようにそのクラス定義は次のとおりです。
( 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 NAME「pcimRuleInstance」DESC「ポリシールールに関連付けられている 『条件であれば、その後のアクション』の意味を表すための構造クラス」。
SUP pcimRule STRUCTURAL )
SUP pcimRule STRUCTURAL）
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コンテンツルールは、（pcimActionAuxClassを使用して）1つまたは複数のポリシー・アクションに1つまたは複数のポリシー条件（pcimConditionAuxClassを用いて）または参照にいずれかの参考文献に取り付けられていることpcimRuleInstanceのインスタンスを可能にするために書くことができます。これは、[1] PolicyRuleのクラスのセマンティクスを形式化するために使用されます。これらのセマンティクスは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構造規則を書くことができ、その三つの可能なネーミング属性（すなわち、pcimRuleName、CN、及びorderedCIMKeys）のいずれかの識別された特定の名前形態を参照してしまうそれぞれが。この構造規則はsuperiorStructureRule（セクション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協会の性質を表す属性が含まれています。このクラスのインスタンスは、DITの封じ込めを経由してpcimRuleのインスタンスに関連しています。ポリシー条件自体は補助クラスのpcimConditionAuxClassの補助サブクラスで表現されています。これらの補助クラスは、ルール固有のポリシー条件のためpcimRuleConditionAssociationのインスタンスに直接結合しています。再利用可能なポリシー条件のため、policyCondition補助サブクラスは（おそらくDIT封じ込めによってpcimRepositoryに関連付けられている）クラスpcimPolicyInstanceのインスタンスに取り付けられ、そして（このクラスの）policyConditionDN属性は、再利用可能なpolicyConditionインスタンスを参照するために使用されます。
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 NAME 'pcimRuleConditionAssociation' DESC 'このクラスは、ポリシールールとそのポリシー条件の一つとの間の関係を特徴付ける属性が含まれています。' SUPのpcimPolicy必要があります（pcimConditionGroupNumber $ pcimConditionNegated）MAY（pcimConditionName $ pcimConditionDN））
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 NAME「pcimConditionGroupNumber」DESC「ポリシー条件が属するグループの数。これは、ポリシールールに関連付けられたDNF又はCNF表現を形成するために使用される。」平等integerMatchがintegerOrderingMatch SYNTAX 1.3オーダー。 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）TRUEの場合は、ポリシー条件がポリシールールに関連付けられたDNFかCNF式の否定（NOT）であることを示しています。次のようにこの属性が定義されています。
( 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.6.2.17 NAME「pcimConditionNegated」DESC「TRUE（FALSE）場合は、ポリシー条件であることを示している（されない）ポリシールールに関連付けられたDNF又はCNF式で否定。」平等booleanMatch SYNTAX 1.3。 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
（1.3.6.1.1.6.2.18 NAME 'pcimConditionName' DESC 'ポリシー条件のわかりやすい名前。' caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatchオーダー平等caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE）
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.6.2.19 NAME「pcimConditionDN」DESC「の再利用可能なポリシー条件のインスタンスを参照するDN。」平等distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12単一値）
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コンテンツルールは、それに補助クラスpcimConditionAuxClass、またはそのサブクラスの1つのインスタンスを取り付けているとpcimRuleConditionAssociationのインスタンスを可能にするために書くことができます。これはPolicyConditionInPolicyRule協会のセマンティクスを形式化するために使用されます。具体的には、このルール固有のポリシー条件を表すために使用される[1]。同様に、3つの別々のDIT構造規則を書くことができます。これらのDIT構造規則のそれぞれは、2つの重要な意味を定義し、特定の名前のフォームを参照することになります。まず、それぞれの名前フォームはpcimRuleConditionAssociationオブジェクト・クラスのための3つの可能なネーミング属性（すなわち、pcimConditionName、CN、及びorderedCIMKeys）のいずれかを識別する。第二に、それぞれの名前の形式はpcimRuleConditionAssociationクラスのインスタンスは、その優れたとしてpcimRuleクラスのインスタンスを持っていることが必要となります。この構造ルールは、（第5章の冒頭に注2を参照）superiorStructureRuleを含むべきです。
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のpcimRuleValidityAssociationクラスにマッピングされています。このクラスは、ポリシーがポリシールール自体にアクティブである時間の定義を結合することによってポリシールールのスケジュールされたアクティブ化および非アクティブ化を表します。 「スケジュール設定」の時間はいずれかの添付補助クラスの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 NAME「pcimRuleValidityAssociation」DESC「これは、ポリシールールのスケジュールされた活性化または非活性化を定義しています。」
SUP pcimPolicy STRUCTURAL MAY ( pcimValidityConditionName $ pcimTimePeriodConditionDN ) )
SUP pcimPolicy 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:
pcimValidityConditionName属性は、この状態のユーザーフレンドリーな名前を定義するために使用され、必要に応じてネーミング属性として使用することができます。次のようにこの属性が定義されています。
( 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 'pcimValidityConditionName' DESC 'pcimRuleValidityAssociationエントリのインスタンスを識別するためのユーザフレンドリーな名前。' 平等caseIgnoreMatchオーダcaseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ）
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.2.21 NAME「pcimTimePeriodConditionDN」DESC「の再利用可能なポリシーの時間条件を参照する。」平等distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12単一値）
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コンテンツルールは、それに補助クラスpcimTPCAuxClass、またはそのサブクラスの1つのインスタンスを取り付けているとpcimRuleValidityAssociationのインスタンスを可能にするために書くことができます。これは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つの重要な意味を定義し、特定の名前のフォームを参照することになります。まず、それぞれの名前フォームはpcimRuleValidityAssociationオブジェクト・クラスのための3つの可能なネーミング属性（すなわち、pcimValidityConditionName、CN、及びorderedCIMKeys）のいずれかを識別する。第二に、それぞれの名前の形式はpcimRuleValidityAssociationクラスのインスタンスは、その優れたとしてpcimRuleクラスのインスタンスを持っていることが必要となります。この構造ルールは、（第5章の冒頭に注2を参照）superiorStructureRuleを含むべきです。
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協会、ActionOrderの一つの特性を表すための属性が含まれています。このプロパティは、ポリシールールに関連付けられたアクションを実行する順序を指定するために使用されます。このクラスのインスタンスは、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.
これらの補助クラスは、ルール固有のポリシーアクションのためのpcimRuleActionAssociationのインスタンスに直接取り付けられています。再利用可能なポリシーアクションのために、pcimAction補助サブクラスは（おそらくDIT封じ込めによってpcimRepositoryに関連付けられている）クラスpcimPolicyInstanceのインスタンスに取り付けられ、そして（このクラスの）pcimActionDN属性は、再利用可能なpcimConditionインスタンスを参照するために使用されます。
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.1.10 NAME「pcimRuleActionAssociation」DESCは「このクラスは、ポリシールールとその政策行動の一つとの間の関係を特徴付ける属性が含まれています。」SUPのpcimPolicy必要があります（pcimActionOrder）MAY（pcimActionName $ pcimActionDN））
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.2.22 NAME 'pcimActionName' DESC平等caseIgnoreMatchがcaseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUEオーダー '政策行動のためのユーザーフレンドリー名'）
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:
pcimActionOrder属性は、指定されたポリシールールに関連付けられているアクションのシーケンスにおける作用の相対的位置を示すために使用される符号なし整数です。この数値が正の場合には、シーケンス内の以前の位置を示す小さな値で、実行されるべきアクションのシーケンスで行わを示します。値がゼロである場合、これは順序は無関係であることを示しています。二つ以上のアクションが同一の非ゼロ値を有する場合、それらは限り、それらは各アクションの全体的な順序で正しい場所で実行されるように、任意の順序で実行されてもよいことに留意されたいです。次のようにこの属性が定義されています。
( 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 NAME「pcimActionOrder」DESC「ポリシールールの文脈における作用の相対的な順序を示す整数。」平等integerMatchがintegerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27シングルオーダーVALUE）
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.24 NAME「pcimActionDN」DESC「の再利用可能なポリシーアクションを参照するDN。」平等distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12単一値）
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コンテンツルールは、それに補助クラスpcimActionAuxClass、またはそのサブクラスの1つのインスタンスを取り付けているとpcimRuleActionAssociationのインスタンスを可能にするために書くことができます。これはPolicyActionInPolicyRule協会のセマンティクスを形式化するために使用されます。具体的には、このルール固有のポリシー・アクションを表すために使用される[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つの重要な意味を定義し、特定の名前のフォームを参照することになります。まず、それぞれの名前フォームはpcimRuleActionAssociationオブジェクト・クラスのための3つの可能なネーミング属性（すなわち、pcimActionName、CN、及びorderedCIMKeys）のいずれかを識別する。第二に、それぞれの名前の形式はpcimRuleActionAssociationクラスのインスタンスは、その優れたとしてpcimRuleクラスのインスタンスを持っていることが必要となります。この構造ルールは、（第5章の冒頭に注2を参照）superiorStructureRuleを含むべきです。
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三の他のクラスのインスタンスに取り付けることができます。このクラスのサブクラスはpcimRuleConditionAssociationのインスタンスへの、または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 NAME「pcimConditionAuxClass」DESC「ポリシールールに関連して評価される条件を表すクラス」SUPトップ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という名前です。しかし、このマッピング（pcimTimePeriodConditionAuxClass）における補助クラスの結果として得られる名前は、いくつかのディレクトリに格納することができる名前の長さを超えます。そのため、名前は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.6.1.12 NAME 'pcimTPCAuxClass' DESC 'これは、所定のスケジュールに従ってポリシールールを有効または無効にする能力を提供する。' SUP pcimConditionAuxClass AUXILIARY MAY（pcimTPCTime $ pcimTPCMonthOfYearMask $ pcimTPCDayOfMonthMask $ pcimTPCDayOfWeekMask $ pcimTPCTimeOfDayMask $ 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 / YYYYMMDDTHHMMSS
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」又は第二の日時に置き換えることができる場合、文字列「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
)
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.
この属性の値は、（第1及び第2の日付列は、文字列「THISANDPRIOR」および「THISANDFUTURE」と置き換えてもよい「YYYYMMDDTHHMMSS / YYYYMMDDTHHMMSS」）は、その定義されたフォーマットに照らしてチェックされるべきです。この属性の値は、この構文に準拠していない場合、これはエラーとみなされるべきであり、ポリシールールは無効にされているものとして扱われるべきです。
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.6.2.26 NAME「pcimTPCMonthOfYearMask」DESC「これは1月から12月の年の月を表して12ビットの文字列を使用して、ポリシールールの年の有効ヶ月を示しています。」平等bitStringMatch SYNTAX 1.3。 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属性は、ポリシールールが有効である月の日数を特定するマスクを定義します。フォーマットは、次の31点の位置は、最後の日からまで、降順に月の日数を表す1日目から31日目に、最初の31点の位置が昇順に月の日数を表す長さ62のビット列であります一日終わりから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.27 NAME「pcimTPCDayOfMonthMask」DESC「これは、最初の31点の位置が昇順に月の日数を表す62ビットのビット列を使用してポリシールールの月の有効日を特定し、次31の位置を降順に月の日数を表す。」平等bitStringMatch SYNTAX 1.3.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 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.6.2.28 NAME「pcimTPCDayOfWeekMask」DESC「これは、7ビットの文字列を使用して、ポリシールールの週の有効日数を指定します。これは、日曜日から土曜日までの週の日数を表します。」平等bitStringMatch SYNTAX 1.3 .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属性は、ポリシールールが有効であるで時間の範囲を定義します。二回目は、最初よりも前である場合には、間隔が深夜に及びます。文字列の形式はThhmmss / Thhmmssです。次のようにこの属性の定義は次のとおりです。
( 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.2.29 NAME「pcimTPCTimeOfDayMask」DESC「これは形式Thhmmss / Thhmmssを使用してポリシーの倍の有効範囲を特定する。」平等caseIgnoreMatchがcaseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44オーダーSINGLE-VALUE）
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時刻表現の間で選択するために使用されます。これは、ローカル時刻とUTC時刻を表す2の値を表す1の値と、単純な整数構文としてマッピングされます。次のようにこの属性の定義は次のとおりです。
( 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 NAME「pcimTPCLocalOrUtcTime」DESC「これは、この例では時間が2）倍=ローカル（値= 1）倍またはUTC（値を表しているかどうかを定義する。」平等integerMatchがintegerOrderingMatch構文1.3.6.1.4.1オーダー.1466.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 NAME 'pcimConditionVendorAuxClass' DESC 'ポリシー条件を記述するために登録する手段を定義するクラス。' SUP pcimConditionAuxClass補助MAY（pcimVendorConstraintData $ pcimVendorConstraintEncoding））
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:
pcimVendorConstraintData属性は複数値の属性です。これは、特定の属性としてモデル化されていないポリシーの条件を表現するための一般的なメカニズムを提供します。この情報は、オクテット文字列のセットでエンコードされています。オクテット文字列の形式はpcimVendorConstraintEncoding属性に保存されている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 NAME「pcimVendorConstraintData」DESC「特定の属性としてモデル化されていない制約を表現するための仕組み。彼らのフォーマットが属性pcimVendorConstraintEncodingに保存されているOIDで識別されます。」平等octetStringMatch注文octetStringOrderingMatch構文1.3.6.1。 4.1.1466.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:
pcimVendorConstraintEncoding属性は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 NAME「pcimVendorConstraintEncoding」DESC]このインスタンスのpcimVendorConstraintDataのフォーマット及びセマンティクスを識別するOID。「平等objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38単一値）
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三の他のクラスのインスタンスに取り付けることができます。このクラスのサブクラスはpcimRuleActionAssociationのインスタンスへの、または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.1.14 NAME「pcimActionAuxClass」DESC「ポリシールールの結果として実行されるアクションを表すクラス」SUPトップAUXILIARY）
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 NAME 'pcimActionVendorAuxClass' DESC 'ポリシーアクションを記述するために登録する手段を定義するクラス。' SUP pcimActionAuxClass補助MAY（pcimVendorActionData $ pcimVendorActionEncoding））
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属性は複数値の属性です。これは、特定の属性としてモデル化されていないポリシーアクションを表現するための一般的なメカニズムを提供します。この情報は、オクテット文字列のセットでエンコードされています。オクテット文字列の形式は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 NAME「pcimVendorActionData」DESC「特定の属性としてモデル化されていないポリシーアクションを表現するための仕組み。彼らのフォーマットが属性pcimVendorActionEncodingに保存されているOIDで識別されます。」平等octetStringMatchがoctetStringOrderingMatch SYNTAX 1.3.6.1オーダー.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 NAME「pcimVendorActionEncoding」DESC「はこのインスタンスのpcimVendorActionData属性のフォーマット及びセマンティクスを識別するOID。」平等objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38単一値）
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 NAME「pcimPolicyInstance」DESC「再利用可能なポリシー情報を含む補助クラスを結合させることができるため、構造クラス」SUP pcimPolicy MAY（pcimPolicyInstanceName））
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 NAME 'pcimPolicyInstanceName' DESC 'このポリシーインスタンスの使いやすい名前。' caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15単一値オーダー平等caseIgnoreMatch）
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コンテンツルールは、それに補助オブジェクトクラスpcimConditionAuxClassとpcimActionAuxClassの一つ以上のいずれかのインスタンスを取り付けているとpcimPolicyInstanceのインスタンスを可能にするために書くことができます。これらのセマンティクスは、任意のプロパティを指定して含まれていないので、コンテンツルールは、任意の属性を指定する必要はありません。他のコンテンツルールが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を参照）superiorStructureRuleを含むべきです。
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によって表されるようなポリシー情報の領域外に定義されたクラスのインスタンスです。このタグ付けは、潜在的に二つのレベルで行うことができます。
- 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なります。オブジェクトのクラス=「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 NAME「pcimElementAuxClass」DESC「特定のポリシー仕様などの関連政策の領域外に定義されたクラスのインスタンスをタグ付けするために使用される補助クラス」。
SUP pcimPolicy AUXILIARY )
SUP pcimPolicy補助）
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クラスは抽象として定義されています。構造サブクラスpcimRepositoryInstanceスタンドアロンエントリとしてポリシーリポジトリを表すために使用可能である間サブクラスpcimRepositoryAuxClassは、別のエントリへの補助アタッチメントを提供します。
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 '再利用可能なポリシー情報のコンテナ。' SUP dlm1AdminDomain ABSTRACT MAY（pcimRepositoryName））
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 NAME 'pcimRepositoryName' DESC 'このポリシーリポジトリのわかりやすい名前。' caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUEオーダー平等caseIgnoreMatch）
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 NAME「pcimRepositoryAuxClass」DESC「再利用可能なポリシー情報を集約するために使用することができる補助クラス」SUP pcimRepository AUXILIARY）
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:
構造クラスはなく、補助クラスで必要とされる場合には、pcimRepositoryInstanceクラスは、再利用可能なポリシー情報を集約するために使用することができ、構造のクラスです。これは次のように定義されます。
( 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 NAME「pcimRepositoryInstance」DESC「再利用可能なポリシー情報を集約するために使用することができる構造クラス」SUP pcimRepository STRUCTURAL）
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構造規則の各々は、三つの可能なネーミング属性（すなわち、pcimRepositoryName、CN、及びorderedCIMKeys）のいずれかを使用して、任意の優れ下で命名するpcimRepositoryクラスのインスタンスを有効に特定の名前フォームを指すであろう。この構造ルールは、（第5章の冒頭に注2を参照）superiorStructureRuleを含むべきです。
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.
これらのエントリは、よく知られているDNSがそれに結合pcimSubtreesPtrAuxClassを有する周知構造のエントリを参照するのに使用することができるように、DIT内に配置されることが意図されます。実際には、これはエントリポイントのセットを定義します。これらのエントリポイントの各々は、任意のよく知られているポリシー・ドメインのすべての関連ポリシーエントリを含むおよび/または参照することができます。ポリシー情報を含むDITの部分を識別するためのタグとしてpcimSubtreesPtrAuxClass機能します。
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.
オブジェクトを取得したら、ディレクトリクライアントは、pcimRulesAuxContainedSetなど複数値属性に含まれる参照に従うことによってセマンティック結合を決定することができます。
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は、ここでのポリシーとは無関係な多数のオブジェクト（再び、「ポリシー」と共にポリシー関連オブジェクトの比較的少ない数を含む大きなディレクトリパーティションのパーティションルートに結合すべきではないPCIMはなく、Xを指し0.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 NAME「pcimSubtreesPtrAuxClass」DESC「ポリシー関連オブジェクトを含むDITサブツリーのルートへのDN参照を提供する補助クラス」SUP上部補助MAY（pcimSubtreesAuxContainedSet））
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:
属性pcimSubtreesAuxContainedSetポリシー関連情報が存在する下で、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 NAME「pcimSubtreesAuxContainedSet」DESC「ポリシー関連オブジェクトを含むDITのサブツリーのルートとして機能するオブジェクトの識別名。」平等distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12）
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.
この補助クラスでは、pcimGroupsのセットを参照単一、複数の値を持つ属性を提供します。様々な他のクラスのインスタンスに、この属性を付加することにより、ポリシー管理者は、クライアントが見つけ、それに関連するpcimGroupsを取得することを可能にするディレクトリへのエントリポイントを提供する柔軟な方法があります。
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 NAME「pcimGroupContainmentAuxClass」DESC「適切なコンテナオブジェクトにpcimGroupsを結合するために使用される補助クラス」SUP上補助MAY（pcimGroupsAuxContainedSet））
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.
属性pcimGroupsAuxContainedSetは、この属性が付加されていた構造的クラスのインスタンスに関連する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 NAME「pcimGroupsAuxContainedSet」DESC]この属性が付加されたインスタンスに何らかの方法で関連pcimGroupsの識別名。「平等distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12）
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.
cn属性は、セクション5.15でpcimSubtreesPtrAuxClassのために与えられたものと同様の理由により、このクラスに定義されている必要はありません。
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には、いくつかの異なる参照を持っているかもしれません。例えば、そのサブネットを表し、ディレクトリエントリから特定のサブネットに発信されるトラフィックのためのすべてのpcimRulesへの参照があるかもしれません。同時に、明示的DiffServの関連pcimRules用容器として導入pcimGroupのインスタンスから特定のDiffServ設定に関連するすべてのpcimRulesへの参照があるかもしれません。 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 NAME「pcimRuleContainmentAuxClass」DESC「適切なコンテナオブジェクトにpcimRulesを結合するために使用される補助クラス」SUP上補助MAY（pcimRulesAuxContainedSet））
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:
属性pcimRulesAuxContainedSetは、この属性が付加されていた構造的クラスのインスタンスに関連付けられたpcimRulesの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 NAME「pcimRulesAuxContainedSet」DESC]この属性が付加されたインスタンスに何らかの方法で関連pcimRulesの識別名。「平等distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12）
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.
以下のサブセクションでは、この文書から派生ドメイン固有のスキーマを作成PCLS内のベンダクラスは使用すべきか議論し、policyTimePeriodConditionsは、他のポリシーの条件に関連している方法を説明する方法についての一般的なガイダンスを提供します。
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はpcimConditionクラス（またはそのサブクラス）で表現されることに適していないベンダー固有のポリシー条件を表すための機構を提供することpcimConditionVendorAuxClassに含まれています。 pcimActionVendorAuxClassクラスの属性pcimVendorActionDataとpcimVendorActionEncodingは、アクションに対して同じ役割を果たしています。これは、そうでない場合は相互運用できなかった異なるベンダー間の相互運用性を可能にします。
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.
このポリシーサーバは、ベンダーからのすべてのデバイスを構成および管理できるようにするために、例えば、ベンダーCからベンダー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ためのAND / OR条件の定義に包含できるようにすることです。ケアは、ドメイン固有の条件のプロパティを追加する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がその条件定義で時間が含まという理由だけで、pcimTPCAuxClassクラスにのIPSecまたはQoS固有の条件プロパティを追加するには正しくないだろう。正しいサブクラスはpcimConditionAuxClassのIPsecのまたはQoS固有のサブクラスを作成し、適切な有効期間を基準にこれらのドメイン固有の条件クラスのインスタンスを組み合わせることであろう。これはpcimRulesのポリシー条件をAND / ORの関連機能を使用して達成されます。
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.)
ベースとしてPCIMとその専門分野固有の拡張機能を使用してこれらの他の派生文書は、より具体的なセキュリティの考慮事項を伝える必要があります（詳細については、RFC 3060を参照してください。）
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.
PCLSが、ここで定義されているように、任意の実世界のシステムの代表ではないという理由は、そのオブジェクトのクラスは、特定の専門分野、またはポリシードメインに依存しないように設計されたということです。例えば、DiffServのとIPsecは、二つの異なるポリシー・ドメインを表しています。これらのドメインのいずれかに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由来の文書は、このように、ここで説明PCLSと一致ディレクトリ固有のスキーマに、順番に、マッピングされる各技術のポリシー・ドメイン（QOS、IPsecの、など）、固有のクラスにPCIMのクラスをサブクラス化します。
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:
一般的なLDAPセキュリティの考慮事項は、RFC 3377に記載されているように、適用されます[2]。 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（ライトウェイトディレクトリアクセスプロトコル（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を参照してください、 "LDAP（Lightweight Directory Access Protocol）のためのIANA（Internet Assigned Numbers Authority）の考慮事項" [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登録人とEメールアドレスの要求：ボブ・ムーア（remoore@us.ibm.com）仕様：RFC 3703著者/変更コントローラ：IESGはコメント：割り当てられた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
ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／あっしｇんめんｔｓ／ｓみーぬｍべｒｓ
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
件名：LDAP記述子の登録を更新記述子（短い名前）のための要求：コメントのオブジェクト識別子を参照してくださいコメントを見ます
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:
ボブ・ムーア（remoore@us.ibm.com）使用法：：人とEメールアドレスは、詳細のために連絡するコメント仕様を参照してください。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
ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／あっしｇんめんｔｓ／ｌだｐーぱらめてｒｓ
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、ローランドHedburg、およびスティーブンレッグに感謝したいと思います。
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ドラフトで登場しました。これらのドラフトの著者はParthaバッタチャリヤ、ロブ・アダムス、ウィリアムディクソン、ロイ・ペレイラ、ラジュ・ラジャン、ジャン=クリストフ・マーティン、サンジャイKamat、マイケルを参照してください、ラジブChaudhury、ディネッシュバーマ、ジョージ・パワーズ、およびラジYavatkarました。
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）のポリシーとグループの作業ネットワークで行われている作業と整列しています。我々は、特に彼らの有益なコメントのためにリーRafalow、グレン・ウォーターズ、デヴィッド・ブラック、マイケル・リチャードソン、マーク・スティーブンス、デビッド・ジョーンズ、ヒュー・マオン、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] LDAPクラスdlm1ManagedElementにCIM_ManagedElementクラスからマップを助けるために特別な属性、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の役割は、CIM名前空間のインスタンスとLDAPアクセス可能なディレクトリ内のエントリを関連付けるために必要な情報を表現することです。 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の名前空間の「弱階層を」ミラーリングした場合、orderedCIMKeysは、すべてのインスタンスのキー、または唯一のネイティブのキーのいずれかを表すことができます。
Regardless of which of these alternatives is taken, the syntax of orderedCIMKeys is the same - a DirectoryString of the form
かかわらず取られるこれらの選択肢のうち、orderedCIMKeysの構文は同じです - フォームのDirectoryString
<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.
ここで、<キー> = <値>要素は、米国ASCIIのための照合順序に従って、キープロパティの名前によって順序付けされています。 DirectoryStringで許可される唯一のスペースは、<値>要素内に収まるものです。キーのプロパティをアルファベット順に並べと同じように、スペースを抑制することの目的は、文字列操作の結果が予測可能にするために、再びです。
The values of the <value> elements are derived from the various CIM syntaxes according to a grammar specified in [5].
<値>の値は、要素が[5]で指定された文法に従った様々なCIMの構文に由来します。
[1] Moore, B., Ellesson,E., Strassner, J. and A. Westerinen "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001.
[1]ムーア、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]ホッジス、J.とR.モルガン、 "ライトウェイトディレクトリアクセスプロトコル（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]ワール、M.、Coulbeck、A.、ハウズ、T。およびS. Kille、 "軽量のディレクトリアクセスプロトコル（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
http://www.dmtf.org/：[5]分散管理タスクフォース株式会社、「共通情報モデル（CIM）仕様」、バージョン2.2、6月14日、1999年には、このドキュメントでは、次のDMTFのWebページで提供されています標準/文書/ 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]「CIM v2.5のコア情報モデルのためのDMTF LDAPスキーマ」分散管理タスクフォース社、4月15日、2002年には、このドキュメントでは、次のDMTFのWebページで提供されています：http：//www.dmtf。 ORG /標準/文書/ DEN / DSP0123.pdf
[7] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997.
[7]ワール、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.、エド、 "ライトウェイトディレクトリアクセスプロトコル（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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.ブラドナー、BCP 11、RFC 2028、1996年10月 "IETF標準化プロセスに関与する組織"。
[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会議、シカゴ、イリノイ州10月本BOFの1998分は、次の場所で利用可能である：http://www.ietf.org/proceedings/98aug/index .htmlを。
[13] Yavatkar, R., Guerin, R. and D. Pendarakis, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[13] Yavatkar、R.、ゲラン、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]ワール、M.、Alvestrand、H.、ホッジス、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]ホッジス、J.、モルガン、R.とM.ワール、 "ライトウェイトディレクトリアクセスプロトコル（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.、 "IANA（Internet Assigned Numbers Authority）のライトウェイトディレクトリアクセスプロトコル（LDAP）に関する考慮事項"、BCP 64、RFC 3383、2002年9月。
John Strassner Intelliden Corporation 90 South Cascade Avenue Colorado Springs, CO 80903
ジョンStrassner Intelliden株式会社90南カスケード・アベニューコロラドスプリングス、CO 80903
Phone: +1.719.785.0648 Fax: +1.719.785.0644 EMail: john.strassner@intelliden.com
電話：+1.719.785.0648ファックス：+1.719.785.0644電子メール：john.strassner@intelliden.com
Bob Moore IBM Corporation P. O. Box 12195, BRQA/B501/G206 3039 Cornwallis Rd. Research Triangle Park, NC 27709-2195
ボブ・ムーアIBM社P. O.ボックス12195、BRQA / B501 / G206 3039コーンウォリスRdを。リサーチトライアングルパーク、NC 27709-2195
Phone: +1 919-254-4436 Fax: +1 919-254-6243 EMail: remoore@us.ibm.com
電話：+1 919-254-4436ファックス：+1 919-254-6243電子メール：remoore@us.ibm.com
Ryan Moats Lemur Networks, Inc. 15621 Drexel Circle Omaha, NE 68135
ライアン・モーツキツネザルネットワークス株式会社15621ドレクセルサークルオマハ、ネブラスカ68135
Phone: +1-402-894-9456 EMail: rmoats@lemurnetworks.net
電話：+ 1-402-894-9456 Eメール：rmoats@lemurnetworks.net
Ed Ellesson 3026 Carriage Trail Hillsborough, NC 27278
エドEllesson 3026馬車道ヒルズボロ、NC 27278
Phone: +1 919-644-3977 EMail: ellesson@mindspring.com
電話：+1 919-644-3977電子メール：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）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。