RFC3703 日本語訳
3703 Policy Core Lightweight Directory Access Protocol (LDAP) Schema.J. Strassner, B. Moore, R. Moats, E. Ellesson. February 2004. (Format: TXT=142983 bytes) (Updated by RFC4104) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Strassnerがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 3703年のIntelliden社のカテゴリ: 規格はInc.E.Ellesson2004年2月にB.ムーアIBM社のR.堀のキツネザルネットワークを追跡します。
Policy Core Lightweight Directory Access Protocol (LDAP) Schema
方針コアライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)図式
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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)を使用するディレクトリで実装することができるフォームとPolicy Core情報Modelに関するマッピングを定義します。 このモデルはオブジェクトのクラスの2つの階層構造を定義します: 方針を表して、制御して、RFC3060、および関係で指定されるデータがそれを分類するので、情報を表す構造的なクラスが構造的なクラスのインスタンスがどう互いに関連するかを示します。 また、クラスは、クライアントが多量の方針関連の情報を検索しているとき、LDAPサーバとのクライアントの相互作用の性能を向上させるためにLDAP図式に追加されます。 これらのクラスは存在しますが、LDAP retrievalsを最適化します: 情報モデルのそれらに対応するクラスが全くありません。
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
1. 序論… 2 2. 方針コア情報モデル… 4 3. PCLSのための継承階層構造… 5 4. LDAPの情報モデルを写像する一般議論。 6 4.1. クラスと協会マッピングの概要… 7 4.2. デイット内容、構造規則、および名前の用法は4.3に. 9を形成します。 PCLSで属性を命名します… 10
Strassner, et al. Standards Track [Page 1] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[1ページ]。
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
4.4. 規則特有の、そして、再利用できる状態と動作… 11 4.5. ディレクトリにおける、政策目的の位置と検索… 16 4.5.1. 別名と他のデイット最適化手法。 19 5. クラス定義… 19 5.1. 抽象クラス"pcimPolicy"… 21 5.2. 3方針グループは属します… 22 5.3. 3政策ルールは属します… 23 5.4. クラスpcimRuleConditionAssociation… 30 5.5. クラスpcimRuleValidityAssociation… 32 5.6. クラスpcimRuleActionAssociation… 34 5.7. 補助のクラスpcimConditionAuxClass… 36 5.8. 補助のクラスpcimTPCAuxClass… 36 5.9. 補助のクラスpcimConditionVendorAuxClass… 40 5.10. 補助のクラスpcimActionAuxClass… 41 5.11. 補助のクラスpcimActionVendorAuxClass… 42 5.12. クラスpcimPolicyInstance… 43 5.13. 補助のクラスpcimElementAuxClass… 44 5.14. 3方針倉庫は属します… 45 5.15. 補助のクラスpcimSubtreesPtrAuxClass… 46 5.16. 補助のクラスpcimGroupContainmentAuxClass… 48 5.17. 補助のクラスpcimRuleContainmentAuxClass… 49 6. 本書では定義されたクラスを広げます… 50 6.1. Subclassing pcimConditionAuxClassとpcimActionAuxClass50 6.2。 ベンダー方針属性を使用します… 50 6.3. 時間有効期間を費やします… 51 7. セキュリティ問題… 51 8. IANA問題… 53 8.1. オブジェクト識別子… 53 8.2. オブジェクト識別子記述子… 53 9. 承認… 56 10. 付録: orderedCIMKeysの値を構成します… 57 11. 参照… 58 11.1. 標準の参照… 58 11.2. 有益な参照… 59 12. 作者のアドレス… 60 13. 完全な著作権宣言文… 61
1. Introduction
1. 序論
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]で指定されているとして方針データを表して、制御するための情報を表すのにオブジェクト指向情報モデルをみなします。 [2] ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)implementers、「方針」という用語の使用はX.501[4]で定義されるように本書では「方針」という用語の使用について言及しません。 むしろ、このドキュメント中の「方針」という用語の使用は以下の通り定義されます:
Strassner, et al. Standards Track [Page 2] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[2ページ]。
Policy is defined as a set of rules to administer, manage, and
control access to network resources.
方針は、ネットワーク資源へのアクセスを管理して、管理して、制御するために1セットの規則と定義されます。
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のPolicy FrameworkワーキンググループとDistributed Management Task Force(DMTF)のPolicyワーキンググループにはこの仕事は共同開発中であります。 このモデルはオブジェクトのクラスの2つの階層構造を定義します: 方針の方針情報とコントロールを表す構造的なクラス、および構造的なクラスのインスタンスがどう互いに関連するかを示す関係のクラス。 一般に、これらのクラス階層構造の両方が、特定のデータ・ストアに写像される必要があるでしょう。
This document defines the mapping of these information model classes to a directory that uses LDAP as its access protocol. Two types of mappings are involved:
このドキュメントはこれらの情報モデルのクラスに関するマッピングをアクセス・プロトコルとしてLDAPを使用するディレクトリと定義します。 2つのタイプに関するマッピングはかかわります:
- For the structural classes in the information model, the
mapping is basically one-for-one: information model classes map
to LDAP classes, information model properties map to LDAP
attributes.
- 情報モデルの構造的なクラスにおいて、マッピングは基本的に個人的には1です: 情報モデルのクラスはクラス、モデルの特性が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).
- 情報モデルの関係のクラスにおいて、異なったマッピングは可能です。 本書では、Policy Core情報Modelの(PCIM)の関係のクラスと彼らの特性は3つの方法で写像されます: LDAPに、補助物は分類名(DN)参照を表す属性と、そして、ディレクトリ情報Tree(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ディレクトリを使用して、RFC3060[1]SHALLによると、方針情報を実装したがっている実装が、本書では定義されたLDAP図式、または図式からのサブクラスが本書では定義した図式を使用します。 参照[1]で出発点と定義された情報モデルの使用は、継承と関係クラス階層構造が広げることができるのを可能にします、また、他のタイプの関係型データベースなどの方針倉庫がこの情報を使用できるように。
This document fits into the overall framework for representing, deploying, and managing policies being developed by the Policy Framework Working Group.
このドキュメントはPolicy Framework作業部会によって開発される方針を表して、配布して、管理するための総合的なフレームワークに収まります。
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,
本書では説明されたLDAP図式は、そのクラスと属性を特定するのに接頭語"pcim"を使用します。 それは10の非常に一般的なクラスから成ります: pcimPolicy(抽象クラス)、3つの方針グループのクラス(pcimGroup、pcimGroupAuxClass、およびpcimGroupInstance)、3政策ルールが(pcimRule、pcimRuleAuxClass、およびpcimRuleInstance)を分類して、3の特別な補助物が属する、(pcimConditionAuxClass
Strassner, et al. Standards Track [Page 3] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[3ページ]。
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).
pcimTPCAuxClass、およびpcimActionAuxClass、) ([1]で定義されたPolicyTimePeriodConditionの補助のクラスが通常pcimTimePeriodConditionAuxClassと命名されたでしょうが、いくつかのディレクトリには、この名前が長過ぎることに注意してください。 したがって、私たちがpcimTPCAuxClassになるようにこの名前を簡略化した、)
The mapping for the PCIM classes pcimGroup and pcimRule is designed to be as flexible as possible. Three classes are defined for these two PCIM classes. First, an abstract superclass is defined that contains all required properties of each PCIM class. Then, both an auxiliary class as well as a structural class are derived from the abstract superclass. This provides maximum flexibility for the developer.
PCIMのクラスのpcimGroupとpcimRuleのためのマッピングは、できるだけフレキシブルになるように設計されています。 3つのクラスがこれらの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.
また、図式は2つのそれほど一般的でないクラスを含みます: pcimConditionVendorAuxClassとpcimActionVendorAuxClass。 また、情報モデルの関係に関するマッピングを達成するために、図式は2つの補助のクラスを含みます: pcimGroupContainmentAuxClassとpcimRuleContainmentAuxClass。 規則特有の、そして、再利用できる保険約款と政策的措置の区別を得ると、他の7つのクラスが導入されます: pcimRuleConditionAssociation、pcimRuleValidityAssociation、pcimRuleActionAssociation、pcimPolicyInstance、および3つの方針倉庫のクラス(pcimRepository、pcimRepositoryAuxClass、およびpcimRepositoryInstance)。 最終的に、図式はLDAP retrievalsを最適化するための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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[10]で説明されるように本書では解釈されることであるべきですか?
2. The Policy Core Information Model
2. 方針コア情報モデル
This document contains an LDAP schema representing the classes defined in the companion document "Policy Core Information Model -- Version 1 Specification" [1]. Other documents may subsequently be produced, with mappings of this same PCIM to other storage technologies. Since the detailed semantics of the PCIM classes appear only in [1], that document is a prerequisite for reading and understanding this document.
このドキュメントは「方針コア情報はモデル化されます--バージョン1仕様」という仲間ドキュメントで定義されて、クラス[1]を表すLDAP図式を含んでいます。 他のドキュメントは次に、この同じPCIMに関するマッピングで他のストレージ技術に製作されるかもしれません。 クラスが[1]だけで見えるPCIMの詳細な意味論以来、そのドキュメントは、このドキュメントを読んで、理解するための前提条件です。
Strassner, et al. Standards Track [Page 4] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[4ページ]。
3. Inheritance Hierarchy for the PCLS
3. PCLSのための継承階層構造
The following diagram illustrates the class hierarchy for the LDAP Classes defined in this document:
以下のダイヤグラムは本書では定義されたLDAP Classesのためにクラス階層構造を例証します:
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)
トップ| +--dlm1ManagedElement(抽象的な)| | | +--pcimPolicy(抽象的な)| | | | | +--pcimGroup(抽象的な)| | | | | | | +--pcimGroupAuxClass(補助の)| | | | | | | +--pcimGroupInstance(構造的な)| | | | | +--pcimRule(抽象的な)| | | | | | | +--pcimRuleAuxClass(補助の)| | | | | | | +--pcimRuleInstance(構造的な)| | | | | +--pcimRuleConditionAssociation(構造的な)| | | | | +--pcimRuleValidityAssociation(構造的な)| | | | | +--pcimRuleActionAssociation(構造的な)| | | | | +--pcimPolicyInstance(構造的な)| | | | | +--pcimElementAuxClass(補助の)| | | +--dlm1ManagedSystemElement(抽象的な)| | | +--dlm1LogicalElement(抽象的な)| | | +--dlm1System(抽象的な)| | | +--dlm1AdminDomain(抽象的な)| | | +--pcimRepository(抽象的な)| | | +--pcimRepositoryAuxClass(補助)です。
Strassner, et al. Standards Track [Page 5] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[5ページ]。
top
| |
| +--pcimRepositoryInstance
| (structural)
|
+--pcimConditionAuxClass (auxiliary)
| |
| +---pcimTPCAuxClass (auxiliary)
| |
| +---pcimConditionVendorAuxClass (auxiliary)
|
+--pcimActionAuxClass (auxiliary)
| |
| +---pcimActionVendorAuxClass (auxiliary)
|
+--pcimSubtreesPtrAuxClass (auxiliary)
|
+--pcimGroupContainmentAuxClass (auxiliary)
|
+--pcimRuleContainmentAuxClass (auxiliary)
トップ| | | +--pcimRepositoryInstance| (構造的)です。 | +--pcimConditionAuxClass(補助の)| | | +---pcimTPCAuxClass(補助の)| | | +---pcimConditionVendorAuxClass(補助の)| +--pcimActionAuxClass(補助の)| | | +---pcimActionVendorAuxClass(補助の)| +--pcimSubtreesPtrAuxClass(補助の)| +--pcimGroupContainmentAuxClass(補助の)| +--pcimRuleContainmentAuxClass(補助)です。
Figure 1. LDAP Class Inheritance Hierarchy for the PCLS
図1。 PCLSのためのLDAPクラス継承階層構造
4. General Discussion of Mapping the Information Model to LDAP
4. 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を使用するディレクトリのためのある最適化を含みます。 この1つの例は情報モデルで定義された協会のいくつかを表す補助のクラスの使用です。 他のデータ・ストアは、これらの協会を異なって実装する必要があるかもしれません。 2番目の例はディレクトリからの多量の方針関連のデータの検索を最適化するように明確に設計されたクラスの導入です。 このセクションは情報モデルからLDAPまでマッピングに関連するいくつかの一般的な話題について論じます。
The remainder of this section will discuss the following topics. Section 4.1 will discuss the strategy used in mapping the classes and associations defined in [1] to a form that can be represented in a directory that uses LDAP as its access protocol. Section 4.2 discusses DIT content and structure rules, as well as name forms. Section 4.3 describes the strategy used in defining naming attributes for the schema described in Section 5 of this document. Section 4.4 defines the strategy recommended for locating and retrieving PCIM-derived objects in the directory.
このセクションの残りは以下の話題について議論するでしょう。 セクション4.1は[1]でアクセス・プロトコルとしてLDAPを使用するディレクトリに表すことができる書式と定義されたクラスと協会を写像する際に使用される戦略を論ずるでしょう。 セクション4.2はDIT内容と構造規則について論じます、名前フォームと同様に。セクション4.3はこのドキュメントのセクション5で説明された図式のために命名属性を定義する際に使用される戦略を説明します。 セクション4.4はディレクトリでPCIMによって誘導されたオブジェクトを場所を見つけて、検索するために推薦された戦略を定義します。
Strassner, et al. Standards Track [Page 6] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[6ページ]。
4.1. Summary of Class and Association Mappings
4.1. クラスと協会マッピングの概要
Fifteen of the classes in the PCLS come directly from the nine corresponding classes in the information model. Note that names of classes begin with an upper case character in the information model (although for CIM in particular, case is not significant in class and property names), but with a lower case character in LDAP. This is because although LDAP doesn't care, X.500 doesn't allow class names to begin with an uppercase character. Note also that the prefix "pcim" is used to identify these LDAP classes.
PCLSの15人のクラスが直接情報モデルの9つの対応するクラスから来ます。 クラスの名前が情報モデル(特にCIMには、ケースはクラスと特性の名では重要ではありませんが)という大文字キャラクタにもかかわらず、LDAPの小文字キャラクタと共に始まることに注意してください。 初めに、LDAPがそうしませんが、注意、X.500がクラス名を許容しないのが、これの理由です。大文字キャラクタ。 また、接頭語"pcim"がこれらのLDAPのクラスを特定するのに使用されることに注意してください。
+---------------------------+-------------------------------+
| Information Model | LDAP Class(es) |
+---------------------------+-------------------------------+
+---------------------------+-------------------------------+
| Policy | pcimPolicy |
+---------------------------+-------------------------------+
| PolicyGroup | pcimGroup |
| | pcimGroupAuxClass |
| | pcimGroupInstance |
+---------------------------+-------------------------------+
| PolicyRule | pcimRule |
| | pcimRuleAuxClass |
| | pcimRuleInstance |
+---------------------------+-------------------------------+
| PolicyCondition | pcimConditionAuxClass |
+---------------------------+-------------------------------+
| PolicyAction | pcimActionAuxClass |
+---------------------------+-------------------------------+
| VendorPolicyCondition | pcimConditionVendorAuxClass |
+---------------------------+-------------------------------+
| VendorPolicyAction | pcimActionVendorAuxClass |
+---------------------------+-------------------------------+
| PolicyTimePeriodCondition | pcimTPCAuxClass |
+---------------------------+-------------------------------+
| PolicyRepository | pcimRepository |
| | pcimRepositoryAuxClass |
| | pcimRepositoryInstance |
+---------------------------+-------------------------------+
+---------------------------+-------------------------------+ | 情報モデル| LDAPのクラス(es)| +---------------------------+-------------------------------+ +---------------------------+-------------------------------+ | 方針| pcimPolicy| +---------------------------+-------------------------------+ | PolicyGroup| pcimGroup| | | pcimGroupAuxClass| | | pcimGroupInstance| +---------------------------+-------------------------------+ | PolicyRule| pcimRule| | | pcimRuleAuxClass| | | pcimRuleInstance| +---------------------------+-------------------------------+ | PolicyCondition| pcimConditionAuxClass| +---------------------------+-------------------------------+ | PolicyAction| pcimActionAuxClass| +---------------------------+-------------------------------+ | VendorPolicyCondition| pcimConditionVendorAuxClass| +---------------------------+-------------------------------+ | VendorPolicyAction| pcimActionVendorAuxClass| +---------------------------+-------------------------------+ | PolicyTimePeriodCondition| pcimTPCAuxClass| +---------------------------+-------------------------------+ | PolicyRepository| pcimRepository| | | pcimRepositoryAuxClass| | | pcimRepositoryInstance| +---------------------------+-------------------------------+
Figure 2. Mapping of Information Model Classes to LDAP
図2。 LDAPへの情報モデルのクラスに関するマッピング
The associations in the information model map to attributes that reference DNs (Distinguished Names) or to Directory Information Tree (DIT) containment (i.e., superior-subordinate relationships) in LDAP. Two of the attributes that reference DNs appear in auxiliary classes, which allow each of them to represent several relationships from the information model.
情報モデルの協会はLDAPでDNs(Namesを区別する)かディレクトリ情報Tree(DIT)封じ込め(すなわち、優れた下位の関係)のその参照を属性に写像します。 参照DNsがそれぞれの彼らがいくつかの関係を表すことができる補助のクラスで見える2つの属性が情報からモデル化されます。
Strassner, et al. Standards Track [Page 7] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[7ページ]。
+----------------------------------+----------------------------------+ | 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 | +-----------------------------------+---------------------------------+
+----------------------------------+----------------------------------+ | 情報モデル協会| LDAPの属性/クラス| +-----------------------------------+---------------------------------+ +-----------------------------------+---------------------------------+ | PolicyGroupInPolicyGroup| 中のpcimGroupsAuxContainedSet| | | pcimGroupContainmentAuxClass| +-----------------------------------+---------------------------------+ | PolicyRuleInPolicyGroup| 中のpcimRulesAuxContainedSet| | | pcimRuleContainmentAuxClass| +-----------------------------------+---------------------------------+ | PolicyConditionInPolicyRule| またはDIT封じ込め。| | | 中のpcimRuleConditionList| | | またはpcimRule。| | | 中のpcimConditionDN| | | pcimRuleConditionAssociation| +-----------------------------------+---------------------------------+ | PolicyActionInPolicyRule| またはDIT封じ込め。| | | 中のpcimRuleActionList| | | またはpcimRule。| | | 中のpcimActionDN| | | pcimRuleActionAssociation| +-----------------------------------+---------------------------------+ | PolicyRuleValidityPeriod| pcimRuleValidityPeriodList| | | または、pcimRule、(再利用できる)| | | 参照をつけられます。| | | 中のpcimTimePeriodConditionDN| | | pcimRuleValidityAssociation| +-----------------------------------+---------------------------------+ | PolicyConditionInPolicyRepository| DIT封じ込め| +-----------------------------------+---------------------------------+ | PolicyActionInPolicyRepository| DIT封じ込め| +-----------------------------------+---------------------------------+ | PolicyRepositoryInPolicyRepository| DIT封じ込め| +-----------------------------------+---------------------------------+
Figure 3. Mapping of Information Model Associations to LDAP
図3。 LDAPへの情報モデル協会に関するマッピング
Of the remaining classes in the PCLS, two (pcimElementAuxClass and pcimSubtreesPtrAuxClass) are included to make navigation through the DIT and retrieval of the entries found there more efficient. This topic is discussed below in Section 4.5.
PCLSの残っているクラスでは、2(pcimElementAuxClassとpcimSubtreesPtrAuxClass)は、より効率的なそこでわかったエントリーのDITと検索でナビゲーションを作るために含まれています。 セクション4.5で以下でこの話題について議論します。
The remaining four classes in the PCLS, pcimRuleConditionAssociation, pcimRuleValidityAssociation, pcimRuleActionAssociation, and pcimPolicyInstance, are all involved with the representation of policy conditions and policy actions in an LDAP directory. This topic is discussed below in Section 4.4.
PCLSの残っている4つのクラス(pcimRuleConditionAssociation、pcimRuleValidityAssociation、pcimRuleActionAssociation、およびpcimPolicyInstance)が皆、LDAPディレクトリで保険約款と政策的措置の表現にかかわります。 セクション4.4で以下でこの話題について議論します。
Strassner, et al. Standards Track [Page 8] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[8ページ]。
4.2. Usage of DIT Content and Structure Rules and Name Forms
4.2. デイット内容、構造規則、および名前フォームの使用法
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個の強力な道具があります。 1(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構造規則は名前フォームと共にサブスキーマの範囲の中でエントリーのプレースメントと命名を制御します。 名前フォームは、どの属性タイプが必要であり、エントリーのRelative Distinguished Names(RDNs)を形成する際に使用できるかを定義します。 DIT構造規則は、どのエントリーを他のエントリー、およびしたがって、コントロールよりRDNsが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
- この名前フォームによって指定されたエントリーの構造的なオブジェクトのクラス--唯一この名前フォームを特定するためにこれらのエントリー--これらのエントリーのRDNsを形成する際に使用できる属性--オブジェクト識別子のRDNsを形成する際に使用されるのに必要である属性
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
残念ながら、現在のLDAPサーバは彼らのこれらの特徴のサポートでかなり多くを変えます。 また、従わなければならない重要な3実装ポイントがあります。 まず最初に、構造規則のX.500使用は、優れた構造規則のない構造的なオブジェクトのクラスがサブスキーマの管理ポイントであることを必要とします。 これはまさに私たちが方針情報のために欲しいものではありません。 補助のクラスが副分類されたら、満足している規則が構造的ために存在するなら、2番目に、それを分類してください。
Strassner, et al. Standards Track [Page 9] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[9ページ]。
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サーバは構造と満足している規則の継承をサポートしません。
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.
これらの関心を考えて、PCLSからDIT構造と満足している規則を取り外してあります。 含まれているなら、彼らは、引用規格であるだろう、OIDsを必要とするでしょう、したがって、これはそうです。 しかしながら、図式の旧バージョンの構造と満足している規則を建設する際に獲得された洞察を失いたいと思いません。 したがって、私たちはどこでこの図式にそのような規則を使用できたか、そして、何を制御するだろうか、そして、それらの効果が何であるかを説明します。
4.3. Naming Attributes in the PCLS
4.3. PCLSで属性を命名します。
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.
分類名(DNs)によってディレクトリのインスタンスは特定されます。(分類名はファイルシステムがコンピュータ・システムに供給する同じタイプの階層的な組織を提供します)。 分類名はRDNsの系列です。 RDNは即座の上司の文脈の中のインスタンスのためのユニークな識別子を提供します、ファイル名がそれが住んでいるフォルダーの文脈の中のファイルのためのユニークな識別子を提供するのと同じように。
To preserve maximum naming flexibility for policy administrators, three optional (i.e., "MAY") naming attributes have been defined. They are:
方針管理者のために最大の命名の自在性を保持するために、3つの任意(すなわち、「5月」)の命名属性が定義されました。 それらは以下の通りです。
- Each of the structural classes defined in this schema has its
own unique ("MAY") naming attribute. Since the naming
attributes are different, a policy administrator can, by using
these attributes, guarantee that there will be no name
collisions between instances of different classes, even if the
same value is assigned to the instances' respective naming
attributes.
- この図式で定義されたそれぞれの構造的なクラスはそれ自身のユニークな(「5月」)命名属性を持っています。 命名属性が異なっているので、これらの属性を使用することによって、方針管理者は、異なったクラスのインスタンスの間には、名前衝突が全くないのを保証できます、同じ値がインスタンスのそれぞれの命名属性に割り当てられても。
- The LDAP attribute cn (corresponding to X.500's commonName) is
included as a MAY attribute in the abstract class pcimPolicy,
and thus by inheritance in all of its subclasses. In X.500,
commonName typically functions as an RDN attribute, for naming
instances of many classes (e.g., X.500's person class).
- LDAP属性cn(X.500のcommonNameに対応する)は5月の属性として抽象クラスpcimPolicy、およびその結果、サブクラスのすべての継承によって含まれています。 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方針インスタンスで既に存在している値からこの属性の値をalgorithmicallyに得ます。 このアルゴリズムに関する引用規格は[6]に含まれています。 アルゴリズムの記述に関してこのドキュメントの付録を見てください。
Strassner, et al. Standards Track [Page 10] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[10ページ]。
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属性SHOULD NOTが複合RDNを形成するのに一緒に使用されるのが、お勧めであることに注意してください、複合RDNsのサポートが既存のディレクトリ実装の中で制限されるので。
4.4. Rule-Specific and Reusable Conditions and Actions
4.4. 規則特有の、そして、再利用できる状態と動作
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
1. 規則特有の状態か動作が規則がある同時代に方針倉庫から取り除かれるのは、当然です。 それはただ再利用できる状態と動作のための正反対です。 これは状態か動作が概念的に規則特有の場合における規則に添付されますが、それが再利用できる場合で参照をつけられるから(例えば、指し示されます)です。 pcimRepositoryインスタンスの固執はpcimRuleインスタンスの固執から独立しています。 2. 規則自体には、通常、規則特有の状態か動作のためのアクセス許容はそれらと同じです。 他方では、再利用できる状態と動作のアクセス許容は政策ルールの参照なしで表現できるに違いありません。 3. 状態と動作が規則に「付けられている」ので、規則特有の状態と動作は、より少ないアクセスを必要とします。 対照的に、再利用できる状態と動作は、より多くのアクセスを必要とします、それぞれの再利用できる状態か動作が別々のアクセサリーを必要とするので 4. 規則特有の状態と動作は使用のためにただ一つの規則で設計されています。 同じ規則特有の状態を使用する規則の数が増加するのに従って微妙な問題が生じる、(最も明白であるのは、どう規則特有の状態を保つかということです。
Strassner, et al. Standards Track [Page 11] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[11ページ]。
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.
同じ値を反映するためにアップデートされた動作) 再利用できる状態と動作は使用のために複数の独立している規則で自分たちを貸します。 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つが規則特有のRule1がカリフォルニアを条件とさせるという政策ルールと1つの規則特有の動作ABを例証します。
+-----+
|Rule1|
| |
+-----|- -|-----+
| +-----+ |
| * * |
| * * |
| **** **** |
| * * |
v * * v
+--------+ +--------+
| CA+ca | | AB+ab |
+--------+ +--------+
+-----+ |Rule1| | | +-----|- -|-----+ | +-----+ | | * * | | * * | | **** **** | | * * | +に対する**に対して--------+ +--------+ | カリフォルニア+ca| | AB+腹筋| +--------+ +--------+
+------------------------------+
|LEGEND: |
| ***** DIT containment |
| + auxiliary attachment |
| ----> DN reference |
+------------------------------+
+------------------------------+ |伝説: | | ***** DIT封じ込め| | + 補助の付属| | ---->DN参照| +------------------------------+
Figure 4 Rule-Specific Policy Conditions and Actions
図4規則特有の方針状態と動作
Strassner, et al. Standards Track [Page 12] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[12ページ]。
Because the condition and action are specific to Rule1, the auxiliary classes ca and ab that represent them are attached, respectively, to the structural classes CA and AB. These structural classes represent not the condition ca and action ab themselves, but rather the associations between Rule1 and ca, and between Rule1 and ab.
状態と動作がRule1に特定であるので、それらを表す補助のクラスcaと腹筋はそれぞれ構造的なクラスカリフォルニアとABに取り付けられます。 これらの構造的なクラスは、動作腹筋の状態ca、自分たち、むしろRule1の間の協会、およびcaだけの代理をしないで、Rule1と腹筋の間でそうします。
As Figure 4 illustrates, Rule1 contains DN references to the structural classes CA and AB that appear below it in the DIT. At first glance it might appear that these DN references are unnecessary, since a subtree search below Rule1 would find all of the structural classes representing the associations between Rule1 and its conditions and actions. Relying only on a subtree search, though, runs the risk of missing conditions or actions that should have appeared in the subtree, but for some reason did not, or of finding conditions or actions that were inadvertently placed in the subtree, or that should have been removed from the subtree, but for some reason were not. Implementation experience has suggested that many (but not all) of these risks are eliminated.
図4が例証するように、Rule1はDITにそれの下に現れる構造的なクラスカリフォルニアとABのDN参照を含んでいます。 これらのDN参照が不要であることを現れさせるかもしれません、Rule1の下の下位木検索はRule1と、状態と動作との協会を代表する構造的なクラスのすべてに当たるでしょう、したがって。 もっとも、下位木検索だけに依存すると、しかし何らかの理由がそうしなかったので下位木に現れるべきであったなくなった状態か動きか状態かうっかり下位木に置かれるべきであったか、下位木から取り除きましたが、または何らかの理由で取り除いたべきであった動作がそうでなかったのがわかる危険は冒されます。 実装経験は、これらの危険の多く(すべてでない)が排除されるのを示しました。
However, it must be noted that this comes at a price. The use of DN references, as shown in Figure 4 above, thwarts inheritance of access control information as well as existence dependency information. It also is subject to referential integrity considerations. Therefore, it is being included as an option for the designer.
しかしながら、これが犠牲をともなうことに注意しなければなりません。 DN参照の上の図4に示される使用は存在依存情報と同様にアクセス制御情報の継承を阻みます。 また、それも参考の保全問題を受けることがあります。 したがって、それはデザイナーのためのオプションとして含まれています。
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|
| |
+-----------+
+-----------+ |Rule1+ca+腹筋| | | +-----------+
+------------------------------+
|LEGEND: |
| + auxiliary attachment |
+------------------------------+
+------------------------------+ |伝説: | | + 補助の付属| +------------------------------+
Figure 5. A Simple Policy Rule
図5。 簡単な政策ルール
Strassner, et al. Standards Track [Page 13] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[13ページ]。
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.
政策ルールのための簡単であるか複雑な区別は、すべてでなくて、また無でもありません。 政策ルールでそれ自体に添付された状態とその動作を他のエントリーに付けるか、またはそれはそれ自体に付けられた動作とその状態を他のエントリーに添付するかもしれません。 しかしながら、それ、SHALL NOTはそれ自体と、そして、他のエントリーに状態かその動作のどちらかを添付させます、ただ1つを例外として: 政策ルールは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.
- すべての状態が一緒にANDedです。 保険約款のDisjunctive Normal Form(DNF)/接続語Normal Form(CNF)(これらの用語の定義のための[1]を見る)式の特性における2つの方法でこの組み合わせを表すことができます: ただ一つのANDグループがあるDNF式として、または、複数のただ一つの状態ORグループがあるCNF式として。 これらの1番目は簡単な政策ルールによるANDed状態の表現として任意に選ばれています。
- 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.
方針管理者が、ある他の方法で状態を結合する必要があるか、または注文しなければならない1セットの機能があれば、唯一のオプションは複雑な政策ルールを使用することです。
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は同じ政策ルールRule1を例証しますが、今回、その状態と動作は再利用できます。 協会のクラスカリフォルニアとABはまだ存在しています、そして、それらはそれでもRule1の下に含まれたDITです。 しかし、補助のクラスが協会のクラスカリフォルニアとABにcaと直接添付の腹筋を持っているよりむしろ、それぞれが現在、これらの補助のクラスが付けている他のエントリーのDN参照を含みます。 これらの他のエントリー(CIAとAIB)は、クラスpcimRepositoryのインスタンスであるRepositoryXの下に含まれたDITです。 それらがpcimRepositoryのインスタンスの下で命名されるので、caと腹筋は再利用できるとして明確に特定されます。
Strassner, et al. Standards Track [Page 14] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[14ページ]。
+-----+ +-------------+
|Rule1| | RepositoryX |
+-|- -|--+ | |
| +-----+ | +-------------+
| * * | * *
| * * | * *
| *** **** | * *
| * * v * *
| * +---+ * *
| * |AB | +------+ *
v * | -|-------->|AIB+ab| *
+---+ +---+ +------+ *
|CA | +------+
| -|------------------------>|CIA+ca|
+---+ +------+
+-----+ +-------------+ |Rule1| | RepositoryX| +-|- -|--+ | | | +-----+ | +-------------+ | * * | * * | * * | * * | *** **** | * * | * * **に対して| * +---+ * * | * |AB| +------+ *に対する*| -|、-、-、-、-、-、-、--、>|AIB+腹筋| * +---+ +---+ +------+ * |カリフォルニア| +------+ | -|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|CIA+ca| +---+ +------+
+------------------------------+
|LEGEND: |
| ***** DIT containment |
| + auxiliary attachment |
| ----> DN reference |
+------------------------------+
+------------------------------+ |伝説: | | ***** DIT封じ込め| | + 補助の付属| | ---->DN参照| +------------------------------+
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のすべてのサブクラスが補助のクラスでなければなりません。
Strassner, et al. Standards Track [Page 15] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[15ページ]。
4.5. Location and Retrieval of Policy Objects in the Directory
4.5. ディレクトリにおける、政策目的の位置と検索
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:
Policy Decision Point(PDP)がそれが役立つPolicy Enforcement Points(PEPs)に関連している政策目的インスタンスを検索しにLDAPディレクトリに行くとき、2つの関連する問題が直面されています:
- How does it locate and retrieve the directory entries that apply
to its PEPs? These entries may include instances of the PCLS
classes, instances of domain-specific subclasses of these
classes, and instances of other classes modeling such resources
as user groups, interfaces, and address ranges.
- それは、どのようにPEPsに適用されるディレクトリエントリーの、場所を見つけて、検索しますか? これらのエントリーは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.
ディレクトリ情報Tree(DIT)のオブジェクトのプレースメントは方針関連のオブジェクトがPDPによってどう検索されるかを除いた問題にかかわります。 PCLSができるすべてはDITが設計されていて、造られているとき方針管理者を補助するためにクラスの「ツールキット」を提供するその結果、ことです。 PDP SHOULD、方針管理者が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最適化がどう優れているかを例証します。
Strassner, et al. Standards Track [Page 16] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[16ページ]。
+-----+
---------------->| A |
DN reference to | | DN references to subtrees +---+
starting object +-----+ +-------------------------->| C |
| o--+----+ +---+ +---+
| o--+------------->| B | / \
+-----+ +---+ / \
/ \ / \ / ... \
/ \ / \
/ \ / ... \
+-----+ ---------------->| A| DN参照| | 下位木+のDN参照---+ 始めのオブジェクト+-----+ +-------------------------->| C| | o--+----+ +---+ +---+ | o--+------------->| B| / \ +-----+ +---+ / \ / \ / \ / ... \ / \ / \ / \ / ... \
Figure 7. Using the pcimSubtreesPtrAuxClass to Locate Policies
図7。 方針の場所を見つけるのにpcimSubtreesPtrAuxClassを使用します。
The PDP is configured initially with a DN reference to some entry in the DIT. The structural class of this entry is not important; the PDP is interested only in the pcimSubtreesPtrAuxClass attached to it. This auxiliary class contains a multi-valued attribute with DN references to objects that anchor subtrees containing policy-related objects of interest to the PDP. Since pcimSubtreesPtrAuxClass is an auxiliary class, it can be attached to an entry that the PDP would need to access anyway - perhaps an entry containing initial configuration settings for the PDP, or for a PEP that uses the PDP.
PDPは初めは、DITのいくらかのエントリーのDN参照によって構成されます。 このエントリーの構造的なクラスは重要ではありません。 PDPはそれに取り付けられたpcimSubtreesPtrAuxClassだけに興味を持っています。 この補助のクラスはPDPに興味がある方針関連のオブジェクトを含む下位木を据えつけるオブジェクトのDN参照があるマルチ評価された属性を含みます。 pcimSubtreesPtrAuxClassが補助のクラスであるので、PDPがとにかくアクセスする必要があるだろうエントリーにそれを付けることができます--恐らくPDP、またはPDPを使用するPEPのための初期の構成設定を含むエントリー。
Once it has retrieved the DN references, the PDP will direct to each of the objects identified by them an LDAP request that all entries in its subtree be evaluated against the selection criteria specified in the request. The LDAP-enabled directory then returns all entries in that subtree that satisfy the specified criteria.
いったんDN参照を検索すると、意志がそれぞれのオブジェクトに向けるPDPは下位木におけるすべてのエントリーが要求で指定された選択評価基準に対して評価されるというそれらによるLDAP要求を特定しました。 そして、LDAPによって可能にされたディレクトリはその下位木における指定された評価基準を満たすすべてのエントリーを返します。
The selection criteria always specify that object class="pcimPolicy". Since all classes representing policy rules, policy conditions, and policy actions, both in the PCLS and in any domain-specific schema derived from it, are subclasses of the abstract class policy, this criterion evaluates to TRUE for all instances of these classes. To accommodate special cases where a PDP needs to retrieve objects that are not inherently policy-related (for example, an IP address range object referenced by a subclass of pcimActionAuxClass representing the DHCP action "assign from this address range"), the auxiliary class pcimElementAuxClass can be used to "tag" an entry, so that it will be found by the selection criterion "object class=pcimPolicy".
選択評価基準はいつもそのオブジェクトのクラス="pcimPolicy"を指定します。 政策ルールを表すすべてのクラス(PCLSとそれから得られたどんなドメイン特有の図式でも保険約款、および政策的措置)が抽象クラス方針のサブクラスであるので、この評価基準はすべてのためにこれらのクラスのインスタンスをTRUEに評価します。 エントリーに「タグ付けをすること」に補助のクラスpcimElementAuxClassを使用できます、PDPが本来方針関連でないオブジェクト(例えば、動作が「このアドレスの範囲から割り当てる」DHCPを表すpcimActionAuxClassのサブクラスによって参照をつけられるIPアドレス範囲オブジェクト)を検索する必要がある特別なケースに対応するならそれが選択基準「オブジェクトのクラス=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
先行のパラグラフで説明されたアプローチはあるディレクトリ実装に効き目がないでしょう、これらの実装がobjectClass属性における、補助のクラスのマッチングをサポートしないので。 これらの実装が存在していると予想される環境のために、方針に関連するとしてのエントリーの「タグ付け」はそうであることができます。
Strassner, et al. Standards Track [Page 17] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[17ページ]。
accomplished by inserting the special value "POLICY" into the list of values contained in the pcimKeywords attribute (provided by the pcimPolicy class).
pcimKeywords属性(pcimPolicyのクラスによって提供される)に含まれた値のリストの中に特別な値の「方針」を挿入することによって、達成されます。
If a PDP needs only a subset of the policy-related objects in the indicated subtrees, then it can be configured with additional selection criteria based on the pcimKeywords attribute defined in the pcimPolicy class. This attribute supports both standardized and administrator- defined values. For example, a PDP could be configured to request only those policy-related objects containing the keywords "DHCP" and "Eastern US".
PDPが示された下位木で方針関連のオブジェクトの部分集合だけを必要とするなら、pcimPolicyのクラスで定義されたpcimKeywords属性に基づく追加選択評価基準でそれを構成できます。 サポートがともに標準化したこの属性と管理者は値を定義しました。 例えば、キーワード"DHCP"と「イースタン米国」を含むそれらの方針関連のオブジェクトだけを要求するためにPDPを構成できました。
To optimize what is expected to be a typical case, the initial request from the client includes not only the object to which its "seed" DN references, but also the subtree contained under this object. The filter for searching this subtree is whatever the client is going to use later to search the other subtrees: object class="pcimPolicy" or the presence of the keyword "POLICY", and/or presence of a more specific value of pcimKeywords (e.g., "QoS Edge Policy").
典型的なケースであると予想されることを最適化するために、クライアントからの初期の要求はどの「種子」DN参照、しかし、このオブジェクトの下に含まれた下位木にもオブジェクトだけを含んでいないか。 この下位木を捜すためのフィルタはクライアントが後で他の下位木を捜すのに使用するものなら何でもです: オブジェクトのクラスは「方針」というキーワードの"pcimPolicy"か存在、そして/または、pcimKeywords(例えば、「QoS縁の方針」)の、より特定の価値の存在と等しいです。
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要求で: BとCの参照を得るためにオブジェクトAを始動することへの1、方針関連のオブジェクトと同様に、それは次に、それぞれA、および1の下における下位木からBとCまでそれが構成された選択評価基準を通過するすべての方針関連のオブジェクトを手に入れる必要があります。 PDPは、一度、これらのオブジェクトのすべてを検索したことがあって、次に、それらの中で意味関係を理解するために局所的に彼らの様々なDN参照を横断できます。 また、PDPはそれが検索するオブジェクトのいずれにも付けられた別の下位木の参照を見つけて、最初にこの参照に続くように準備されるべきです、それが受け取った意味的に重要な参照のどれかに続く前に。 この再帰は関連する方針を特定することへの体系的なアプローチを可能にします。 図7には、例えば、Bの下の下位木が部門の方針を含んでいて、Cの下におけるものが部門方針を含んでいるなら、Cの下における下位木から法人のレベル方針の下位木を根づかせるオブジェクトDまでの参照があるかもしれません。
A PDP SHOULD understand the pcimSubtreesPtrAuxClass class, SHOULD be capable of retrieving and processing the entries in the subtrees it references, and SHOULD be capable of doing all of this recursively. The same requirements apply to any other entity needing to retrieve policy information from the directory. Thus, a Policy Management Tool that retrieves policy entries from the directory in order to perform validation and conflict detection SHOULD also understand and be capable of using the pcimSubtreesPtrAuxClass. All of these
A PDP SHOULDは、それが参照をつける下位木、およびSHOULDでエントリーを検索して、pcimSubtreesPtrAuxClassのクラス、SHOULDが処理できるのを理解しています。このすべてを再帰的にできてください。 同じ要件はディレクトリからの方針情報を検索する必要があるいかなる他の実体にも適用されます。 したがって、合法化を実行するためにディレクトリから方針エントリーを検索するPolicy Management Toolと闘争検出SHOULDも理解して、pcimSubtreesPtrAuxClassを使用できます。 これらのすべて
Strassner, et al. Standards Track [Page 18] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[18ページ]。
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.
彼らを実装しないLDAPクライアントがまだそれが必要とするディレクトリエントリーにアクセスして、検索できるので、要件は“MUST"sよりむしろ“SHOULD"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エントリーのPolicy Management Tool SHOULDサポート作成、および彼らの参照をオブジェクトインスタンスに作成するためのツールとして機能しているとき。
4.5.1. Aliases and Other DIT-Optimization Techniques
4.5.1. 別名と他のデイット最適化手法
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がまだ別名がディレクトリにどのように表されるか、そして、またはどのように別名を処理するかに関するサーバ実装がことである仕様を作り出していないからです。
5. Class Definitions
5. クラス定義
The semantics for the policy information classes that are to be mapped directly from the information model to an LDAP representation are detailed in [1]. Consequently, all that this document presents for these classes is the specification for how to do the mapping from the information model (which is independent of repository type and access protocol) to a form that can be accessed using LDAP. Remember that some new classes needed to be created (that were not part of [1]) to implement the LDAP mapping. These new LDAP-only classes are fully documented in this document.
直接情報モデルからLDAP表現まで写像されることになっているクラスが[1]で詳細であるという方針情報のための意味論。 その結果、このドキュメントがこれらのクラスのために提示するすべてが、情報モデル(倉庫タイプとアクセス・プロトコルから独立している)からLDAPを使用することでアクセスできる書式までどうマッピングをするかためには仕様です。 数人の新しいクラスが、作成される必要だったのを覚えていてください。(それはLDAPマッピングを実装する[1])の一部ではありません。 これらの新しいLDAPだけのクラスは本書では完全に記録されます。
The formal language for specifying the classes, attributes, and DIT structure and content rules is that defined in reference [3]. If your implementation does not support auxiliary class inheritance, you will have to list auxiliary classes in content rules explicitly or define them in another (implementation-specific) way.
クラス、属性、DIT構造、および満足している規則を指定するための形式言語は参照[3]でそんなに定義されています。 あなたの実装が補助のクラス継承をサポートしないと、あなたは、満足している規則で明らかに補助のクラスを記載しなければならないか、または別の(実装特有)の方法でそれらを定義しなければならないでしょう。
The following notes apply to this section in its entirety.
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.
Note 1: in the following definitions, the class and attribute definitions follow RFC 2252 [3] but they are line-wrapped to enhance human readability.
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
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
Strassner, et al. Standards Track [Page 19] RFC 3703 Policy Core LDAP Schema February 2004
Strassner, et al. Standards Track [Page 19] RFC 3703 Policy Core LDAP Schema February 2004
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:
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:
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) 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.
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.
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.
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.
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.
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.
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.
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]).
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]).
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.
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.
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].
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].
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
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
Strassner, et al. Standards Track [Page 20] RFC 3703 Policy Core LDAP Schema February 2004
Strassner, et al. Standards Track [Page 20] RFC 3703 Policy Core LDAP Schema February 2004
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.
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. The Abstract Class pcimPolicy
5.1. The Abstract Class pcimPolicy
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].
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].
The class definition is as follows:
The class definition is as follows:
( 1.3.6.1.1.6.1.1 NAME 'pcimPolicy'
DESC 'An abstract class that is the base class for all classes
that describe policy-related instances.'
SUP dlm1ManagedElement
ABSTRACT
MAY ( cn $ dlmCaption $ dlmDescription $ orderedCimKeys $
pcimKeywords )
)
( 1.3.6.1.1.6.1.1 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].
The attribute cn is defined in RFC 2256 [7]. The dlmCaption, dlmDescription, and orderedCimKeys attributes are defined in [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:
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:
( 1.3.6.1.1.6.2.3 NAME 'pcimKeywords'
DESC 'A set of keywords to assist directory clients in
locating the policy objects applicable to them.'
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
( 1.3.6.1.1.6.2.3 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 )
Strassner, et al. Standards Track [Page 21] RFC 3703 Policy Core LDAP Schema February 2004
Strassner, et al. Standards Track [Page 21] RFC 3703 Policy Core LDAP Schema February 2004
5.2. The Three Policy Group Classes
5.2. The Three Policy Group Classes
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] 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.
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.
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.
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.
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.
The class definitions are as follows. First, the definition of the abstract class pcimGroup:
The class definitions are as follows. First, the definition of the abstract class pcimGroup:
( 1.3.6.1.1.6.1.2 NAME 'pcimGroup'
DESC 'A container for a set of related pcimRules and/or
a set of related pcimGroups.'
SUP pcimPolicy
ABSTRACT
MAY ( pcimGroupName )
)
( 1.3.6.1.1.6.1.2 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:
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:
( 1.3.6.1.1.6.2.4 NAME 'pcimGroupName'
DESC 'The user-friendly name of this policy group.'
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
( 1.3.6.1.1.6.2.4 NAME 'pcimGroupName' DESC 'The 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 )
Strassner, et al. Standards Track [Page 22] RFC 3703 Policy Core LDAP Schema February 2004
Strassner, et al. Standards Track [Page 22] RFC 3703 Policy Core LDAP Schema February 2004
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:
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:
( 1.3.6.1.1.6.1.3 NAME 'pcimGroupAuxClass'
DESC 'An auxiliary class that collects a set of related
pcimRule and/or pcimGroup entries.'
SUP pcimGroup
AUXILIARY
)
( 1.3.6.1.1.6.1.3 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:
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:
( 1.3.6.1.1.6.1.4 NAME 'pcimGroupInstance'
DESC 'A structural class that collects a set of related
pcimRule and/or pcimGroup entries.'
SUP pcimGroup
STRUCTURAL
)
( 1.3.6.1.1.6.1.4 NAME 'pcimGroupInstance' DESC '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.
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.
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.
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.
5.3. The Three Policy Rule Classes
5.3. The Three Policy Rule Classes
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.
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.
Strassner, et al. Standards Track [Page 23] RFC 3703 Policy Core LDAP Schema February 2004
Strassner, et al. Standards Track [Page 23] RFC 3703 Policy Core LDAP Schema February 2004
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Strassner, et al. Standards Track [Page 24] RFC 3703 Policy Core LDAP Schema February 2004
Strassner, et al. Standards Track [Page 24] RFC 3703 Policy Core LDAP Schema February 2004
The class definitions for the three pcimRule classes are as follows.
The class definitions for the three pcimRule classes are as follows.
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:
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:
( 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 '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 ) )
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.
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.
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:
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:
( 1.3.6.1.1.6.2.5 NAME 'pcimRuleName'
DESC 'The user-friendly name of this policy rule.'
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
( 1.3.6.1.1.6.2.5 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:
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:
( 1.3.6.1.1.6.2.6 NAME 'pcimRuleEnabled'
DESC 'An integer indicating whether a policy rule is
administratively enabled (value=1), disabled
( 1.3.6.1.1.6.2.6 NAME 'pcimRuleEnabled' DESC 'An integer indicating whether a policy rule is administratively enabled (value=1), disabled
Strassner, et al. Standards Track [Page 25] RFC 3703 Policy Core LDAP Schema February 2004
Strassner, et al. Standards Track [Page 25] RFC 3703 Policy Core LDAP Schema February 2004
(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
)
(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.
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.
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:
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:
( 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 '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 )
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.
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.
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:
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:
( 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 '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 )
Strassner, et al. Standards Track [Page 26] RFC 3703 Policy Core LDAP Schema February 2004
Strassner, et al. Standards Track [Page 26] RFC 3703 Policy Core LDAP Schema February 2004
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:
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:
( 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 '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 )
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:
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:
( 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 '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 )
The pcimRuleUsage attribute is a free-form string providing guidelines on how this policy should be used. It is defined as follows:
The pcimRuleUsage attribute is a free-form string providing guidelines on how this policy should be used. It is defined as follows:
( 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 '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 )
Strassner, et al. Standards Track [Page 27] RFC 3703 Policy Core LDAP Schema February 2004
Strassner, et al. Standards Track [Page 27] RFC 3703 Policy Core LDAP Schema February 2004
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:
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:
( 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 '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 )
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.
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.
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:
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:
( 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 '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 )
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:
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:
( 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 '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
Strassner, et al. Standards Track [Page 28] RFC 3703 Policy Core LDAP Schema February 2004
Strassner, et al. Standards Track [Page 28] RFC 3703 Policy Core LDAP Schema February 2004
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.
Note: if the value of pcimRulesSequencedActions field is not one of these three values, then Administrators SHOULD treat this rule as being disabled.
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:
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:
( 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 '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 )
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.
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.
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:
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:
( 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 'An auxiliary class for representing the "If Condition then Action" semantics associated with a policy rule.' SUP pcimRule AUXILIARY )
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:
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:
( 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 'A structural class for representing the "If Condition then Action" semantics associated with a policy rule.'
Strassner, et al. Standards Track [Page 29] RFC 3703 Policy Core LDAP Schema February 2004
Strassner, et al. Standards Track [Page 29] RFC 3703 Policy Core LDAP Schema February 2004
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.
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.
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.
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.
5.4. The Class pcimRuleConditionAssociation
5.4. The Class pcimRuleConditionAssociation
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の補助のサブクラスはクラスpcimPolicyInstance(おそらく、DIT封じ込めでpcimRepositoryに関連している)のインスタンスに付けられています、そして、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、.8NAME'pcimRuleConditionAssociation'DESC'このクラスは政策ルールと保険約款の1つとの関係を特徴付ける属性を含んでいる'(pcimConditionGroupNumber$pcimConditionNegated). SUP pcimPolicyがそうしなければならない5月(pcimConditionName$pcimConditionDN)
Strassner, et al. Standards Track [Page 30] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[30ページ]。
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式が. 'EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX1.3.6を政策ルールに関連づけた、.1、.4、.1、.1466、.115、.121、.1、.27SINGLE-VALUE)
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.
この数が非負であることに注意してください。 この属性のための負の数は、病人と、無効にされるとして扱われた状態で無効のエントリーSHOULDについて言及するあらゆる政策ルールです。
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属性はこの方針状態が否定されるかどうかことであることを示すブール属性です。 TRUE(FALSE)であるなら、それは、方針状態が政策ルールに関連しているDNFかCNF式で否定されるのを(ありません)示します。 この属性は以下の通り定義されます:
( 1.3.6.1.1.6.2.17
NAME 'pcimConditionNegated'
DESC 'If TRUE (FALSE), it indicates that a policy condition
IS (IS NOT) negated in the DNF or CNF expression
associated with a policy rule.'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE
)
(1.3、.6、.1、.1、.6、.2.17NAME'pcimConditionNegated'DESC、'TRUE(FALSE)、方針状態がDNFで否定されるのを(ありません)示すか、またはCNF式が. 'EQUALITY booleanMatch SYNTAX1.3.6を政策ルールに関連づけた、.1、.4、.1、.1466、.115、.121、.1、.7SINGLE-VALUE)
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
(. 'a方針状態EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatchのための1.3.6.1.1.6.2.18NAME'pcimConditionName'DESC'Aユーザフレンドリーな名
Strassner, et al. Standards Track [Page 31] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[31ページ]。
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
構文1.3.6の.115の.121の.1の.15のただ一つの.1.4.1.1466価値)
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.19NAME'pcimConditionDN'DESC'A DNが. 'EQUALITY distinguishedNameMatch SYNTAX1.3.6を条件とさせる、.1、.4、.1、.1466、.115、.121、.1、.12SINGLE-VALUE)
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).
pcimRuleConditionAssociationのインスタンスが補助のクラスpcimConditionAuxClassのインスタンス、またはサブクラスの1つをそれに付けたのを可能にするためにDITの満足している規則を書くことができました。 これは、PolicyConditionInPolicyRule協会の意味論を正式にするのに使用されるでしょう。 明確に、これは、規則特有の方針状態[1]を表すのに使用されるでしょう。 同様に、3つの別々のDIT構造規則を書くことができました。 それぞれのこれらのDIT構造規則は2の重要な意味論を定義した種名書式を示すでしょう。 まず最初に、それぞれの名前フォームはpcimRuleConditionAssociationオブジェクトのクラスのために3つの可能な命名属性(すなわち、pcimConditionName、cn、およびorderedCIMKeys)の1つを特定するでしょう。 2番目に、それぞれの名前フォームは、pcimRuleConditionAssociationのクラスのインスタンスには上司としてpcimRuleのクラスのインスタンスがあるのを必要とするでしょう。 また、この構造規則SHOULDはsuperiorStructureRuleを含んでいます(セクション5の始めにNote2を見てください)。
5.5. The Class pcimRuleValidityAssociation
5.5. クラスpcimRuleValidityAssociation
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.9NAME'pcimRuleValidityAssociation'DESC、'これは政策ルールの予定されている起動か非活性化を定義します'。
Strassner, et al. Standards Track [Page 32] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[32ページ]。
SUP pcimPolicy
STRUCTURAL
MAY ( pcimValidityConditionName $ pcimTimePeriodConditionDN )
)
pcimPolicyの構造的な5月(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
)
(. 'EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX1.3にpcimRuleValidityAssociationエントリーのインスタンスを特定するための1.3.6.1.1.6.2.20NAME'pcimValidityConditionName'DESC'Aユーザフレンドリーな名、.6、.1、.4、.1、.1466、.115、.121、.1、.15SINGLE-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.21NAME'pcimTimePeriodConditionDN'DESC'Aが. 'EQUALITY distinguishedNameMatch SYNTAX1.3.6に再利用できる方針期間の状態に参照をつける、.1、.4、.1、.1466、.115、.121、.1、.12SINGLE-VALUE)
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].
pcimRuleValidityAssociationのインスタンスが補助のクラスpcimTPCAuxClassのインスタンス、またはサブクラスの1つをそれに付けたのを可能にするためにDITの満足している規則を書くことができました。 これは、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
同様に、3つの別々のDIT構造規則を書くことができました。 それぞれのこれらのDIT構造規則は2の重要な意味論を定義した種名書式を示すでしょう。 まず最初に、それぞれの名前フォームはpcimRuleValidityAssociationオブジェクトのクラスのために3つの可能な命名属性(すなわち、pcimValidityConditionName、cn、およびorderedCIMKeys)の1つを特定するでしょう。 2番目に、それぞれの名前フォームは、pcimRuleValidityAssociationのクラスのインスタンスには上司としてpcimRuleのクラスのインスタンスがあるのを必要とするでしょう。 これ
Strassner, et al. Standards Track [Page 33] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[33ページ]。
structure rule SHOULD also include a superiorStructureRule (see Note 2 at the beginning of section 5).
また、構造規則SHOULDはsuperiorStructureRuleを含んでいます(セクション5の始めにNote2を見てください)。
5.6. The Class pcimRuleActionAssociation
5.6. クラスpcimRuleActionAssociation
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協会の1つの特性、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の補助のサブクラスはクラスpcimPolicyInstance(おそらく、DIT封じ込めでpcimRepositoryに関連している)のインスタンスに付けられています、そして、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、.10NAME'pcimRuleActionAssociation'DESC'このクラスは政策ルールと政策的措置の1つとの関係を特徴付ける属性を含んでいる'(pcimActionOrder). SUP pcimPolicyがそうしなければならない5月(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
)
(. 'a政策的措置EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAXのための1.3.6.1.1.6.2.22NAME'pcimActionName'DESC'Aユーザフレンドリーな名、1.3、.6、.1、.4、.1、.1466、.115、.121、.1、.15SINGLE-VALUE)
Strassner, et al. Standards Track [Page 34] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[34ページ]。
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属性は次々にの与えられた政策ルールに関連している動作の動作の相対的な位置を示すのに使用される符号のない整数です。 この数が正であるときに、動作の系列の実行されるべき場所を示します、より小さい値が系列の以前の見解を示していて。 値がゼロであるなら、これは、オーダーが無関係であることを示します。 2つ以上の動作に同じ非ゼロ値があるなら、動作の総合的な系列の正しい場所でそれぞれ実行される限り、それらが順不同に実行されるかもしれないことに注意してください。 この属性は以下の通り定義されます:
( 1.3.6.1.1.6.2.23
NAME 'pcimActionOrder'
DESC 'An integer indicating the relative order of an action
in the context of a policy rule.'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)
(1.3、.6、.1、.1、.6、.2.23NAME'pcimActionOrder'DESC、'方針の文脈における動作の相対オーダを示す整数が. 'EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX1.3.6を統治する、.1、.4、.1、.1466、.115、.121、.1、.27SINGLE-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の値であるなら否定的であり、次に、それはSHOULDです。無効にされるとして扱われた状態でそのようなエントリーSHOULDについて言及する誤りとあらゆる政策ルールとして扱われてください。
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
)
(. 'EQUALITY distinguishedNameMatch SYNTAX1.3に再利用できる政策的措置に参照をつける1.3.6.1.1.6.2.24NAME'pcimActionDN'DESC'A DN、.6、.1、.4、.1、.1466、.115、.121、.1、.12SINGLE-VALUE)
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].
pcimRuleActionAssociationのインスタンスが補助のクラスpcimActionAuxClassのインスタンス、またはサブクラスの1つをそれに付けたのを可能にするためにDITの満足している規則を書くことができました。 これは、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
同様に、3つの別々のDIT構造規則を書くことができました。 それぞれのこれらのDIT構造規則は2の重要な意味論を定義した種名書式を示すでしょう。 まず最初に、それぞれの名前フォームは可能な命名が(すなわち、pcimActionName、cn、およびorderedCIMKeys)を結果と考える3つのものの1つを特定するでしょう。
Strassner, et al. Standards Track [Page 35] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[35ページ]。
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).
pcimRuleActionAssociationオブジェクトのクラス。 2番目に、それぞれの名前フォームは、pcimRuleActionAssociationのクラスのインスタンスには上司としてpcimRuleのクラスのインスタンスがあるのを必要とするでしょう。 また、この構造規則はsuperiorStructureRuleを含むべきです(セクション5の始めにNote2を見てください)。
5.7. The Auxiliary Class pcimConditionAuxClass
5.7. 補助のクラスpcimConditionAuxClass
The purpose of a policy condition is to determine whether or not the set of actions (contained in the pcimRule that the condition applies to) should be executed or not. This class defines the basic organizational semantics of a policy condition, as specified in [1]. Subclasses of this auxiliary class can be attached to instances of three other classes in the PCLS. When a subclass of this class is attached to an instance of pcimRuleConditionAssociation, or to an instance of pcimRule, it represents a rule-specific policy condition. When a subclass of this class is attached to an instance of pcimPolicyInstance, it represents a reusable policy condition.
方針状態の目的は動作(状態が申し込むpcimRuleでは、含まれている)のセットが実行されるべきであるかどうか決定することです。 このクラスは[1]で指定されるように方針状態の基本的な組織的な意味論を定義します。 PCLSの他の3つのクラスのインスタンスにこの補助のクラスのサブクラスを付けることができます。 このクラスのサブクラスが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.11NAME'pcimConditionAuxClass'DESC. '方針に関連して評価されるべき状態を表すクラスは統治する'SUP先端AUXILIARY)
5.8. The Auxiliary Class pcimTPCAuxClass
5.8. 補助のクラスpcimTPCAuxClass
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つを提供します。
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に短くされました。
Strassner, et al. Standards Track [Page 36] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[36ページ]。
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.12NAME'pcimTPCAuxClass'DESC. 'これは政策ルールを可能にするか、または予定されたスケジュール通りに無効にする能力を提供する'SUP pcimConditionAuxClass AUXILIARY5月(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"か第2日時に取り替えるかもしれないかストリング"THISANDFUTURE"に取り替えるかもしれません。 この属性は以下の通り定義されます:
( 1.3.6.1.1.6.2.25
NAME 'pcimTPCTime'
DESC 'The start and end times on which a policy rule is
valid.'
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
SINGLE-VALUE
)
(1.3、.6、.1、.1、.6、.2.25NAME'pcimTPCTime'DESC、'政策ルールが. 'EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX1.3に有効である始めと終わりの回、.6、.1、.4、.1、.1466、.115、.121、.1、.44SINGLE-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.
この値はSHOULDを結果と考えます。定義された形式(1番目と2番目の日付ストリングがストリング"THISANDPRIOR"と"THISANDFUTURE"に取り替えられるかもしれないところの「yyyymmddThhmmss/yyyymmddThhmmss」)に対してチェックされてください。 この属性の値がそうしないなら、次に、この構文、このSHOULDに従ってください。誤りと政策ルールSHOULDであると無効にされるとして扱われた状態で考えられてください。
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
次の4つの属性(pcimTPCMonthOfYearMask、pcimTPCDayOfMonthMask、pcimTPCDayOfWeekMask、およびpcimTPCTimeOfDayMask)が[1]で八重奏ストリングとすべて定義されます。 しかしながら、それぞれのこれらの属性の意味論は中に含まれています。
Strassner, et al. Standards Track [Page 37] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[37ページ]。
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.
様々な固定長のビット列。 したがって、PCLSは、それぞれの彼らを表すのにBit Stringの構文を使用します。 これらの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属性は政策ルールが有効である1年間の数カ月を特定する12ビットのマスクを定義します。 1月から12月まで1年の数カ月を表して、形式は長さ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.26NAME'pcimTPCMonthOfYearMask'DESC、'これがa政策ルール使用. 'EQUALITY bitStringMatch SYNTAX1.3に1月から12月まで1年の数カ月を表す12ビット列.6.1のために1年の有効な数カ月に.4を特定する、.1、.1466、.115、.121、.1、.6SINGLE-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.
この値はSHOULDを結果と考えます。定義された形式に対してチェックされます。 この属性の値がそうしないなら、次に、この構文、このSHOULDに従ってください。誤りと政策ルールSHOULDであると無効にされるとして扱われた状態で考えられてください。
The pcimTPCMonthOfDayMask attribute defines a mask identifying the days of the month on which a policy rule is valid. The format is a bit string of length 62. The first 31 positions represent the days of the month in ascending order, from day 1 to day 31. The next 31 positions represent the days of the month in descending order, from the last day to the day 31 days from the end. The definition of this attribute is as follows:
pcimTPCMonthOfDayMask属性は政策ルールが有効である月の数日を特定するマスクを定義します。 形式は長さ62のしばらくストリングです。 最初の31の位置が1日目から31日目まで昇順に月の数日を表します。 次期31の位置が終わりから1日も違わず正確に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、'これは政策ルールのために62ビット列を使用することで月の有効な日を特定します'。 '最初の31の位置が昇順、および次における31の位置が月の数日に. '降順にEQUALITY bitStringMatch SYNTAX1.3.6を表す月の数日に.1を表す、.4、.1、.1466、.115、.121、.1、.6SINGLE-VALUE)
Strassner, et al. Standards Track [Page 38] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[38ページ]。
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.
この値はSHOULDを結果と考えます。定義された形式に対してチェックされます。 この属性の値がそうしないなら、次に、この構文、このSHOULDに従ってください。誤りと政策ルールSHOULDであると無効にされるとして扱われた状態で考えられてください。
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属性は政策ルールが有効である1週間の数曜日を特定するマスクを定義します。 日曜日から土曜日の間、週の数曜日を表して、形式は長さ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ビット列を使用することで週の有効な曜日を特定します'。 . EQUALITY bitStringMatch SYNTAX1.3に'これは日曜日から土曜日の間、週の数曜日を表す'という.6、.1、.4、.1、.1466、.115、.121、.1、.6SINGLE-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.
この値はSHOULDを結果と考えます。定義された形式に対してチェックされます。 この属性の値がそうしないなら、次に、この構文、このSHOULDに従ってください。誤りと政策ルールSHOULDであると無効にされるとして扱われた状態で考えられてください。
The pcimTPCTimeOfDayMask attribute defines the range of times at which a policy rule is valid. If the second time is earlier than the first, then the interval spans midnight. The format of the string is Thhmmss/Thhmmss. The definition of this attribute is as follows:
pcimTPCTimeOfDayMask属性は政策ルールが有効である回の範囲を定義します。 2回目が1番目より初期であるなら、間隔は真夜中にかかっています。 ストリングの形式は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.29NAME'pcimTPCTimeOfDayMask'DESC、'これが方針のために. 'EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX1.3に形式Thhmmss/Thhmmssを使用することで回の有効枠を特定する、.6、.1、.4、.1、.1466、.115、.121、.1、.44SINGLE-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.
この値はSHOULDを結果と考えます。定義された形式に対してチェックされます。 この属性の値がそうしないなら、次に、この構文、このSHOULDに従ってください。誤りと政策ルールSHOULDであると無効にされるとして扱われた状態で考えられてください。
Strassner, et al. Standards Track [Page 39] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[39ページ]。
Finally, the pcimTPCLocalOrUtcTime attribute is used to choose between local or UTC time representation. This is mapped as a simple integer syntax, with the value of 1 representing local time and the value of 2 representing UTC time. The definition of this attribute is as follows:
最終的に、pcimTPCLocalOrUtcTime属性は、地方かUTC時間表現を選ぶのに使用されます。 これは簡単な整数構文として写像されます、1の表すことの現地時間の値と2の値がUTC時間を表していて。 この属性の定義は以下の通りです:
( 1.3.6.1.1.6.2.30
NAME 'pcimTPCLocalOrUtcTime'
DESC 'This defines whether the times in this instance
represent local (value=1) times or UTC (value=2)
times.'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)
(1.3.6.1.1.6.2.30NAME'pcimTPCLocalOrUtcTime'DESC. 'これは、回がこの場合地方(値の=1)の時勢かUTC(値の=2)時勢を表すかどうかを定義する'EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX1.3、.6、.1、.4、.1、.1466、.115、.121、.1、.27SINGLE-VALUE)
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、その時がこのSHOULDであるなら、考えられて、誤りと方針は、SHOULDが無効にされると裁決します。 属性が全く存在していないなら、まるでそれが値2について存在しているかのようにすべての回が解釈されます、すなわち、UTC時間。
5.9. The Auxiliary Class pcimConditionVendorAuxClass
5.9. 補助のクラスpcimConditionVendorAuxClass
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を使用するのに従順でないベンダー特有の拡大のために意図します。 標準化された拡大SHOULD NOTはこのクラスを使用します。
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.13NAME'pcimConditionVendorAuxClass'DESC. 'それが登録された手段を定義するクラスは方針状態について説明する'SUP pcimConditionAuxClass AUXILIARY5月(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
pcimVendorConstraintData属性はマルチ評価された属性です。 それは特定の属性としてモデル化されていない保険約款を表すのに一般的機構を提供します。 この情報は1セットの八重奏ストリングでコード化されます。 八重奏の形式
Strassner, et al. Standards Track [Page 40] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[40ページ]。
strings is identified by the OID stored in the pcimVendorConstraintEncoding attribute. This attribute is defined as follows:
ストリングは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'メカニズム'。 . EQUALITY octetStringMatch ORDERING octetStringOrderingMatch SYNTAX1.3に'それらの形式は属性pcimVendorConstraintEncodingに保存されたOIDによって特定される'という.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.32NAME'pcimVendorConstraintEncoding'DESC、'これのためのpcimVendorConstraintDataのための形式を特定するOIDと意味論が. 'EQUALITY objectIdentifierMatch SYNTAX1.3.6を例証する、.1、.4、.1、.1466、.115、.121、.1、.38SINGLE-VALUE)
5.10. The Auxiliary Class pcimActionAuxClass
5.10. 補助のクラスpcimActionAuxClass
The purpose of a policy action is to execute one or more operations that will affect network traffic and/or systems, devices, etc. in order to achieve a desired policy state. This class is used to represent an action to be performed as a result of a policy rule whose condition clause was satisfied.
政策的措置の目的は必要な政策ポジションを獲得するためにネットワークトラフィックに影響する1つ以上の操作、そして/または、システム、デバイスなどを実行することです。 このクラスは、基本定款が満たされた政策ルールの結果、実行されるために動作を表すのに使用されます。
Subclasses of this auxiliary class can be attached to instances of three other classes in the PCLS. When a subclass of this class is attached to an instance of pcimRuleActionAssociation, or to an instance of pcimRule, it represents a rule-specific policy action. When a subclass of this class is attached to an instance of pcimPolicyInstance, it represents a reusable policy action.
PCLSの他の3つのクラスのインスタンスにこの補助のクラスのサブクラスを付けることができます。 このクラスのサブクラスが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のクラスの属性は既にこれらのサブクラスが付くエントリーと定義されるでしょう。 したがって、このクラスは直接「先端」から引き出されます。
Strassner, et al. Standards Track [Page 41] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[41ページ]。
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.14NAME'pcimActionAuxClass'DESC. '方針の結果、実行されるために動作を表すクラスは統治する'SUP先端AUXILIARY)
5.11. The Auxiliary Class pcimActionVendorAuxClass
5.11. 補助のクラスpcimActionVendorAuxClass
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のクラスを使用するのに従順でないベンダー特有の拡大のために意図します。 標準化された拡大SHOULD NOTはこのクラスを使用します。
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 )
)
(. 'SUP pcimActionAuxClass AUXILIARYがそうする政策的措置(pcimVendorActionData$pcimVendorActionEncoding)について説明する登録された手段を定義する1.3.6.1.1.6.1.15NAME'pcimActionVendorAuxClass'DESC'Aのクラス)
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属性はマルチ評価された属性です。 それは特定の属性としてモデル化されていない政策的措置を表すのに一般的機構を提供します。 この情報は1セットの八重奏ストリングでコード化されます。 八重奏ストリングの形式は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'Mechanism'。 . EQUALITY octetStringMatch ORDERING octetStringOrderingMatch SYNTAX1.3に'それらの形式は属性pcimVendorActionEncodingに保存されたOIDによって特定される'という.6、.1、.4、.1、.1466、.115、.121、.1、.40)
Strassner, et al. Standards Track [Page 42] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[42ページ]。
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.34NAME'pcimVendorActionEncoding'DESC、'このpcimVendorActionData属性のための形式を特定するOIDと意味論が. 'EQUALITY objectIdentifierMatch SYNTAX1.3.6を例証する、.1、.4、.1、.1466、.115、.121、.1、.38SINGLE-VALUE)
5.12. The Class pcimPolicyInstance
5.12. クラスpcimPolicyInstance
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 )
)
'pcimPolicyInstanceの'DESC'A構造的なクラスをどの補助のクラス含有再利用できる方針情報に付けることができます'。(1.3、.6、.1、.1、.6、.1、.16NAME、SUP pcimPolicyはそうするかもしれません(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この方針の名前が. 'EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX1.3に例証するユーザフレンドリーの.35NAME'pcimPolicyInstanceName'DESC'.6、.1、.4、.1、.1466、.115、.121、.1、.15SINGLE-VALUE)
Strassner, et al. Standards Track [Page 43] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[43ページ]。
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.
pcimPolicyInstanceのインスタンスが一層の補助のオブジェクトのクラスのpcimConditionAuxClassと1のインスタンスかpcimActionAuxClassのどちらかをそれに取り付けたのを可能にするためにDITの満足している規則を書くことができました。 これらの意味論以来、どんな特性も指定するのを含まないでください、そして、満足している規則はどんな属性も指定する必要はないでしょう。 他の方針関連の補助のクラスが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)の1つを特定するでしょう。 2番目に、それぞれの名前フォームは、pcimPolicyInstanceのクラスのインスタンスには上司としてpcimRepositoryのクラスのインスタンスがあるのを必要とするでしょう。 また、この構造規則SHOULDはsuperiorStructureRuleを含んでいます(セクション5の始めにNote2を見てください)。
5.13. The Auxiliary Class pcimElementAuxClass
5.13. 補助のクラスpcimElementAuxClass
This class introduces no additional attributes, beyond those defined in the class pcimPolicy from which it is derived. Its role is to "tag" an instance of a class defined outside the realm of policy information as represented by PCIM as being nevertheless relevant to a policy specification. This tagging can potentially take place at two levels:
このクラスはそれが引き出されるクラスpcimPolicyで定義されたものを超えてどんな追加属性も導入しません。 「役割はそれにもかかわらず、方針仕様に関連しているとしてPCIMによって表されるように方針情報の分野の外で定義されたクラスのインスタンスにタグ付けをする」ことです。 このタグ付けは2つのレベルで潜在的に行われることができます:
- Every instance to which pcimElementAuxClass is attached becomes
an instance of the class pcimPolicy, since pcimElementAuxClass is
a subclass of pcimPolicy. Searching for object
class="pcimPolicy" will return the instance. (As noted earlier,
this approach does NOT work for some directory implementations.
To accommodate these implementations, policy-related entries
SHOULD be tagged with the pcimKeyword "POLICY".)
- pcimElementAuxClassが付けているあらゆるインスタンスがクラスpcimPolicyのインスタンスになります、pcimElementAuxClassがpcimPolicyのサブクラスであるので。 オブジェクトのクラス="pcimPolicy"を検索すると、インスタンスは返るでしょう。 (より早く注意されるように、このアプローチはいくつかのディレクトリ実装に効き目がありません。 これらの実装、方針関連のエントリーSHOULDを収容するには、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.
- それがpcimPolicyから引き継ぐpcimKeywords属性で、方針情報の特定のタイプかカテゴリに関連しているとして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.17NAME'pcimElementAuxClass'DESC、'補助のクラスは以前はよく方針の分野の外で特定の方針仕様に関連すると定義されたクラスのインスタンスにタグ付けをしていました'。
Strassner, et al. Standards Track [Page 44] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[44ページ]。
SUP pcimPolicy
AUXILIARY
)
一口pcimPolicy補助物)
5.14. The Three Policy Repository Classes
5.14. 3つの方針倉庫のクラス
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で考えられるかもしれません。 参照[6]で定義されたクラスdlm1AdminDomainからpcimRepositoryを得るので、この仕様は参照[6]のその要素の上に標準の依存を持っています。(全体の派生階層構造と同じくらいよく。(また、それは、参照[6])に現れます)。 柔軟性を最大にするために、pcimRepositoryのクラスは同じくらい抽象的に定義されます。 pcimRepositoryAuxClassが別のエントリーへの補助の付属に提供するサブクラス、構造的なサブクラスである間、pcimRepositoryInstanceは、スタンドアロンエントリーとして方針倉庫を表すために利用可能です。
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 )
)
('. SUP dlm1AdminDomainが5月(pcimRepositoryName)を抜き取るという再利用できる方針情報のための1.3.6.1.1.6.1.18NAME'pcimRepository'DESC'Aコンテナ)
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. 'この方針倉庫EQUALITY caseIgnoreMatch ORDERINGにおける名義のユーザフレンドリーの.36NAME'pcimRepositoryName'DESC'caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX1.3.6、.1、.4、.1、.1466、.115、.121、.1、.15SINGLE-VALUE)
Strassner, et al. Standards Track [Page 45] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[45ページ]。
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.19NAME'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
)
(. '再利用できる方針情報SUP pcimRepository STRUCTURALに集めるのに使用できる1.3.6.1.1.6.1.20NAME'pcimRepositoryInstance'DESC'A構造的なクラス)
Three separate DIT structure rules could be written for this class. Each of these DIT structure rules would refer to a specific name form that enabled an instance of the pcimRepository class to be named under any superior using one of the three possible naming attributes (i.e., pcimRepositoryName, cn, and orderedCIMKeys). This structure rule SHOULD also include a superiorStructureRule (see Note 2 at the beginning of section 5).
このクラスのために3つの別々のDIT構造規則を書くことができました。 それぞれのこれらのDIT構造規則はpcimRepositoryのクラスのインスタンスがどんな上司の下でも命名されるのを3つの可能な命名属性(すなわち、pcimRepositoryName、cn、およびorderedCIMKeys)の1つを使用することで可能にした種名書式を示すでしょう。 また、この構造規則SHOULDはsuperiorStructureRuleを含んでいます(セクション5の始めにNote2を見てください)。
5.15. The Auxiliary Class pcimSubtreesPtrAuxClass
5.15. 補助のクラスpcimSubtreesPtrAuxClass
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下位木の根本にある1セットのオブジェクトに参照をつけるマルチ評価された属性)を提供します。 他の様々なクラスのインスタンスにこの属性を付けることによって、方針管理者はクライアントが方針情報を場所を見つけて、検索するディレクトリにエントリー・ポイントを供給するフレキシブルな方法をそれに関連するようにします。
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
これらのエントリーによるよく知られるDNsを参照に使用できるようにDITに置かれて、pcimSubtreesPtrAuxClassを持っているよく知られる構造的なエントリーがそれに付いたということであることを意図します。 事実上、これは1セットのエントリー・ポイントを定義します。 それぞれのエントリー・ポイントが含むことができるこれら、そして/または、すべてが方針エントリーを関係づけた参照
Strassner, et al. Standards Track [Page 46] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[46ページ]。
any well-known policy domains. The pcimSubtreesPtrAuxClass functions as a tag to identify portions of the DIT that contain policy information.
どんなよく知られる方針ドメイン。 pcimSubtreesPtrAuxClassは、方針情報を含むDITの一部を特定するためにタグとして機能します。
This object does not provide the semantic linkages between individual policy objects, such as those between a policy group and the policy rules that belong to it. Its only role is to enable efficient bulk retrieval of policy-related objects, as described in Section 4.5.
このオブジェクトはそれに属す方針グループと政策ルールの間のそれらなどの個々の政策目的の間の意味リンケージを供給しません。 唯一の役割はセクション4.5で説明されるように方針関連のオブジェクトの効率的な大量の検索を可能にすることです。
Once the objects have been retrieved, a directory client can determine the semantic linkages by following references contained in multi-valued attributes, such as pcimRulesAuxContainedSet.
オブジェクトがいったん検索されると、ディレクトリクライアントはマルチ評価された属性に含まれた参照に続くことによって、意味リンケージを決定できます、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下位木にしばしば含まれて、クライアントSHOULD要求は参照自体を要求する同時間のこれらの参照があるオブジェクトの下の下位木からの方針関連のオブジェクトです。
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.
クライアントがこのように振る舞うと予想されて、方針管理者SHOULDは、この下位木が方針に関係ないとても多くのオブジェクトを含んでいないのでこのように行われた初期の検索が性能問題をもたらすのを確実にします。 pcimSubtreesPtrAuxClass SHOULD、方針に関係ない多くのオブジェクトに伴う比較的数数の方針関連のオブジェクトを含む大きいディレクトリパーティションのためにパーティション根に付けられないでください(一方、ここの「方針」は「方針」のX.501、定義、および使用ではなく、PCIMを示します)。 より良いアプローチは、コンテナオブジェクトをすぐパーティション根より下であるまで導入して、このコンテナオブジェクトに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 )
)
'DNを提供する補助のクラスは方針関連のオブジェクトを含む下位木にDITのルーツに参照をつけます'。(1.3.6.1.1.6.1.21NAME'pcimSubtreesPtrAuxClass'DESC、SUPはAUXILIARY MAY(pcimSubtreesAuxContainedSet)を上回っています)
Strassner, et al. Standards Track [Page 47] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[47ページ]。
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、それが. 'EQUALITY distinguishedNameMatch SYNTAX1.3に方針関連のオブジェクトを含むDIT下位木のためのルーツとして.6に役立つオブジェクトの.2.37NAME'pcimSubtreesAuxContainedSet'DESC'DNs、.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属性が定義される必要はないことに注意してください。 これは補助のクラスが一般的な属性を集めて、オブジェクトの特性としてそれらを扱う手段として使用されるからです。 良い類推は#インクルードファイルです、補助のクラスがクラスであるのでクラス(例えば、継承)のすべての利益を補助のクラスに適用できるのを除いて。
5.16. The Auxiliary Class pcimGroupContainmentAuxClass
5.16. 補助のクラスpcimGroupContainmentAuxClass
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.
この補助のクラスは1セットのその参照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.22NAME'pcimGroupContainmentAuxClass'DESC. '適切なコンテナにpcimGroupsを縛るのに使用される補助のクラスは反対する'SUP先端AUXILIARY MAY(pcimGroupsAuxContainedSet))
Strassner, et al. Standards Track [Page 48] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[48ページ]。
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はこの属性が追加された構造的なクラスのインスタンスに関連している1pcimGroupsのインスタンスの順不同の参照を提供します。
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、pcimGroupsの.2.38NAME'pcimGroupsAuxContainedSet'DESC'DNsが何らかの道のこの属性が. 'EQUALITY distinguishedNameMatch SYNTAX1.3に追加されたインスタンスで中のように関連づけた.6、.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.
セクション5.15のpcimSubtreesPtrAuxClassによってcn属性が与えられたものと同じ理由でこのクラスのために定義される必要はないことに注意してください。
5.17. The Auxiliary Class pcimRuleContainmentAuxClass
5.17. 補助のクラスpcimRuleContainmentAuxClass
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.
この補助のクラスは1セットのその参照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.23NAME'pcimRuleContainmentAuxClass'DESC. '適切なコンテナにpcimRulesを縛るのに使用される補助のクラスは反対する'SUP先端AUXILIARY MAY(pcimRulesAuxContainedSet))
Strassner, et al. Standards Track [Page 49] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[49ページ]。
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、pcimRulesの.2.39NAME'pcimRulesAuxContainedSet'DESC'DNsが何らかの道のこの属性が. 'EQUALITY distinguishedNameMatch SYNTAX1.3に追加されたインスタンスで中のように関連づけた.6、.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はpcimSubtreesPtrAuxClassのために与えられたものとしてセクション5.15で推論します。
6. Extending the Classes Defined in This Document
6. 本書では定義されたクラスを広げます。
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がどう他の保険約款に関連するかがわかります。
6.1. Subclassing pcimConditionAuxClass and pcimActionAuxClass
6.1. Subclassing pcimConditionAuxClassとpcimActionAuxClass
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の補助のサブクラスでドメイン特殊情報を言い表さなければならないと指定します。 非標準化された概要がまた、この習慣に続くのは、RECOMMENDEDです。
6.2. Using the Vendor Policy Attributes
6.2. ベンダー方針属性を使用します。
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は動作に関して同じ役割を果たします。 これは別の方法で共同利用できなかった異なったベンダーの間の相互運用性を可能にします。
Strassner, et al. Standards Track [Page 50] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[50ページ]。
For example, imagine a network composed of access devices from vendor A, edge and core devices from vendor B, and a policy server from vendor C. It is desirable for this policy server to be able to configure and manage all of the devices from vendors A and B. Unfortunately, these devices will in general have little in common (e.g., different mechanisms, different ways for controlling those mechanisms, different operating systems, different commands, and so forth). The extension conditions provide a way for vendor-specific commands to be encoded as octet strings, so that a single policy server can commonly manage devices from different vendors.
この方針サーバがベンダーAとB.Unfortunatelyからデバイスのすべてを構成して、対処できるのにおいてベンダーC.Itからの方針サーバが望ましい、例えば、ベンダーA、縁、およびコアデバイスからベンダーBからアクセスデバイスで構成されたネットワークを想像してください。そうすれば、一般に、これらのデバイスは少ししか(例えば、異なったメカニズム、それらのメカニズムを制御するための異なった方法、異なったオペレーティングシステム、異なったコマンドなど)が共通でないでしょう。 拡大状態は八重奏ストリングとしてコード化されるべきベンダー特有のコマンドのための方法を提供します、ただ一つの方針サーバが異なったベンダーからデバイスに一般的に対処できるように。
6.3. Using Time Validity Periods
6.3. 時間有効期間を費やします。
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.
例えば、pcimTPCAuxClassのクラスへのIPsecかQoS特有の状態性質を加えるのは不正確でしょう、ただIPsecかQoSが状態定義に時間を含んでいるので。 正しい副分類は、pcimConditionAuxClassのIPsecかQoS特有のサブクラスを作成して、次に、これらのドメイン特有の状態のクラスのインスタンスを適切な有効期間評価基準に結合するだろうことです。 これは保険約款にpcimRulesでAND/OR協会能力を使用するのに優れています。
7. Security Considerations
7. セキュリティ問題
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は実際の世界システムで直接useableではありません、IETFのPolicy Framework作業部会の執筆中の作品である規律特有のマッピングなしで。
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とその規律特有の拡張子を使用する)は、より特定のセキュリティ問題を伝える必要があるでしょう。(詳しい情報についてRFC3060を参照してください。)
Strassner, et al. Standards Track [Page 51] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[51ページ]。
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は2つの異なった方針ドメインを表します。 PCIMをこれらのドメインの1つまで広げる各ドキュメントがサブクラスに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.
上で議論した派生文献は操作上で適用するための文脈を作成するでしょう、本当の世界です、PCIMに由来している様々なモデルに対するシステムレベルセキュリティ要件、PCLSと一致しています。
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アクセス可能なディレクトリ)における、方針データモデルの表現の基礎を形成するので、それはここにデータのモデル特有のツールを参照に当てることであり、それが制限する要件の暗黙の認証と承認を達成するのが読む、そして/または、読んだので、利用可能なメカニズムはディレクトリに保存されたこれらの値へのアクセスを書きます。
Strassner, et al. Standards Track [Page 52] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[52ページ]。
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セキュリティ問題はRFC3377[2]に記録されるように適用されます。 LDAP特有の認証、承認ツール、およびメカニズムは以下の標準化過程ドキュメントで見つけられます:(アプリケーションに、ドキュメントはLDAPアクセス可能なディレクトリに保存された方針データモデルに適用されたセキュリティの管理に適切です)。
- RFC 2829 (Authentication Methods for LDAP)
- RFC 2830 (Lightweight Directory Access Protocol (v3): Extension
for Transport Layer Security)
- RFC2829(LDAPのための認証方法)--RFC2830(ライトウェイト・ディレクトリ・アクセス・プロトコル(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.
各規律に特定の派生しているデータモデルドキュメントで適切な規律特有の情報モデルドキュメント、または本書では対処されていないどんな特定されたセキュリティ要件にも対処しなければなりません。
8. IANA Considerations
8. IANA問題
Refer to RFC 3383, "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)" [16].
RFC3383、「ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)のためのインターネット規定番号権威(IANA)問題」[16]を参照してください。
8.1. Object Identifiers
8.1. オブジェクト識別子
The IANA has registered an LDAP Object Identifier for use in this technical specification according to the following template:
以下のテンプレートに従って、IANAはこの技術仕様書に基づく使用のためにLDAP Object Identifierを登録しました:
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.
Subject: 詳細のために連絡するLDAP OID Registration PersonとEメールアドレスのために以下を要求してください。 ボブ・ムーア( remoore@us.ibm.com )Specification: RFC3703作者/変化コントローラ: 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がOIDを割り当てた、1.3 .6 .1 .1 .6 以下の登録での記録されるとしてのこの登録へのpcimSchemaという名前で:
http://www.iana.org/assignments/smi-numbers
http://www.iana.org/assignments/smi-numbers
8.2. Object Identifier Descriptors
8.2. オブジェクト識別子記述子
The IANA has registered the LDAP Descriptors used in this technical specification as detailed in the following template:
IANAは以下のテンプレートで詳しく述べられるようにこの技術仕様書で使用されるLDAP Descriptorsを登録しました:
Subject: Request for LDAP Descriptor Registration Update Descriptor (short name): see comment Object Identifier: see comment
Subject: LDAP Descriptor Registration Update Descriptor(省略名)のために以下を要求してください。 コメントObject Identifierを見てください: コメントを見てください。
Strassner, et al. Standards Track [Page 53] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[53ページ]。
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:
詳細のために連絡する人とEメールアドレス: ボブ・ムーア( remoore@us.ibm.com )Usage: コメントSpecificationを見てください: RFC3703作者/変化コントローラ: 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
名前タイプOID-------------- ---- ------------ pcimPolicy O1.3.6.1.1.6.1.1pcimGroup O1.3.6.1.1.6.1.2pcimGroupAuxClass O1.3.6、.1、.1、.6、.1、.3pcimGroupInstance O1.3.6.1.1.6.1.4pcimRule O1.3.6.1.1.6.1.5pcimRuleAuxClass O1.3.6.1.1.6.1.6pcimRuleInstance O1.3.6.1.1.6.1.7pcimRuleConditionAssociation O1.3.6.1.1.6.1.8pcimRuleValidityAssociation O1.3.6.1.1.6.1.9pcimRuleActionAssociation O1.3.6.1.1.6.1.10pcimConditionAuxClass O1.3、.6 .1 .1 .6 .1 .11pcimTPCAuxClass O1.3.6.1.1.6.1.12pcimConditionVendorAuxClass O1.3.6.1.1.6.1.13pcimActionAuxClass O1.3; 6.1.1.6.1.14 pcimActionVendorAuxClass O1.3.6.1.1.6.1.15pcimPolicyInstance O1.3.6.1.1.6.1.16pcimElementAuxClass O1.3.6.1.1.6.1.17pcimRepository O1.3.6.1.1.6.1.18pcimRepositoryAuxClass O1.3.6.1.1.6.1.19pcimRepositoryInstance O1.3.6.1.1.6.1.20pcimSubtreesPtrAuxClass O1.3.6.1.1.6.1.21pcimGroupContainmentAuxClass O1.3.6.1.1.6.1.22pcimRuleContainmentAuxClass O1.3.6.1.1.6.1.23pcimKeywords、A1.3.6、.1、.1、.6、.2、.3、pcimGroupName A1.3.6.1.1.6.2.4pcimRuleName A、1.3.6.1.1.6.2.5pcimRuleEnabled A1.3.6、.1 .1。6.2.6 pcimRuleConditionListType A1.3.6.1.1.6.2.7pcimRuleConditionList A1.3.6.1.1.6.2.8pcimRuleActionList A1.3.6.1.1.6.2.9pcimRuleValidityPeriodList A1.3.6.1.1.6.2.10pcimRuleUsage A1.3.6.1.1.6.2.11pcimRulePriority A1.3.6.1.1.6.2.12pcimRuleMandatory A1.3.6.1.1.6.2.13pcimRuleSequencedActions A1.3.6.1.1.6.2.14pcimRoles A1.3.6.1.1.6.2.15pcimConditionGroupNumber A1.3.6、.1、.1、.6、.2、.16
Strassner, et al. Standards Track [Page 54] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[54ページ]。
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
名前タイプOID-------------- ---- ------------ pcimConditionNegated A1.3.6.1.1.6.2.17pcimConditionName A1.3.6.1.1.6.2.18pcimConditionDN A1.3.6.1.1.6.2.19pcimValidityConditionName A1.3.6.1.1.6.2.20pcimTimePeriodConditionDN A1.3.6.1.1.6.2.21pcimActionName A1.3.6.1.1.6.2.22pcimActionOrder A1.3.6.1.1.6.2.23pcimActionDN A1.3.6.1.1.6.2.24pcimTPCTime A1.3.6.1.1.6.2.25pcimTPCMonthOfYearMask A1.3.6.1.1.6.2.26pcimTPCDayOfMonthMask A1.3.6.1.1.6.2.27pcimTPCDayOfWeekMask A1.3.6、.1 .1 .6 .2; 28pcimTPCTimeOfDayMask A1.3.6.1.1.6.2.29pcimTPCLocalOrUtcTime A1.3.6.1.1.6.2.30pcimVendorConstraintData A1.3.6.1.1.6.2.31pcimVendorConstraintEncoding A1.3.6.1.1.6.2.32pcimVendorActionData A1.3.6.1.1.6.2.33pcimVendorActionEncoding A1.3.6.1.1.6.2.34pcimPolicyInstanceName A1.3.6.1.1.6.2.35pcimRepositoryName A1.3.6.1.1.6.2.36pcimSubtreesAuxContainedSet A1.3.6.1.1.6.2.37pcimGroupsAuxContainedSet A1.3.6.1.1.6.2.38pcimRulesAuxContainedSet A1.3.6、.1、.1、.6、.2、.39
where Type A is Attribute, Type O is ObjectClass
Type AがAttributeであるところでは、Type OはObjectClassです。
These assignments are recorded in the following registry:
これらの課題は以下の登録に記録されます:
http://www.iana.org/assignments/ldap-parameters
http://www.iana.org/assignments/ldap-parameters
Strassner, et al. Standards Track [Page 55] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[55ページ]。
9. Acknowledgments
9. 承認
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.
このドキュメントのレビューをして、多くの役立つ提案と修正をして頂いて、カートZeilenga、ローランドHedburg、およびスティーブンLeggに感謝申し上げます。
Several of the policy classes in this model first appeared in early IETF drafts on IPsec policy and QoS policy. The authors of these drafts were Partha Bhattacharya, Rob Adams, William Dixon, Roy Pereira, Raju Rajan, Jean-Christophe Martin, Sanjay Kamat, Michael See, Rajiv Chaudhury, Dinesh Verma, George Powers, and Raj Yavatkar.
このモデルのいくつかの方針のクラスが最初に、IPsec方針とQoS方針で早めのIETF草稿に現れました。 これらの草稿の作者は、Parthaバッタチャリヤと、ロブ・アダムスと、ウィリアム・ディクソンと、ロイ・ペレイラと、ラジュRajanと、Jean-Christopheマーチンと、Sanjay Kamatと、マイケルSeeと、ラジブChaudhuryと、Dinesh Vermaと、ジョージ・パワーズと、Raj 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.
このドキュメントは密接にDistributed Management Task Force(DMTF)方針とNetworksワーキンググループでする仕事に並べられます。 彼らの役に立つコメントについてリーRafalow、グレンWaters、デヴィッドBlack、マイケル・リチャードソン、マーク・スティーブンス、デーヴィッドジョーンズ百貨店、ヒューマホン、ヨラムSnir、およびヨラム・ランベルクに特に感謝申し上げます。
Strassner, et al. Standards Track [Page 56] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[56ページ]。
10. Appendix: Constructing the Value of orderedCIMKeys
10. 付録: orderedCIMKeysの値を構成します。
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概要の間で情報交換したがっているimplementersのガイドとして含まれています。
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で弱い協会を使用することによって、利用可能です: 以来、弱い協会は基本性質の伝播にかかわります、そして、それらの優れたオブジェクトから1、部下がいることができるのを反対させる部下までの値は“under"と命名されると優れたオブジェクトを考えました。 一度、それらは伝播されたことがあって、しかしながら、伝播された基本性質とそれらの値はまさに固有の基本性質とそれらの値が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.
ドキュメント[6]を写像するCIMは、CIM_ManagedElementのクラスからLDAPのクラスまでdlm1ManagedElementを写像するのを助けるために特別な属性、orderedCIMKeysを導入します。 これは中古のコネがそれがLDAPアクセス可能なディレクトリとCIM倉庫の間で写像するのに必要である環境であったならSHOULDだけを結果と考えます。 LDAP環境において、属性を命名する他のLDAPが定義されます。(すなわち、cnとクラス特有の命名している属性) SHOULDは代わりに使用されます。
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つのものの1つを表します:
- 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>]*
<className><主要な>=<値>[<の主要な>は<値の>と等しい]*
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
<の主要な>が<と等しいところでは、値の>要素は基本性質の名前によって注文されます、米国ASCIIのための照合順序によると。 DirectoryStringに許容された唯一の空間が<値の>要素の中で低下するものです。 基本性質をアルファベット順にするように
Strassner, et al. Standards Track [Page 57] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[57ページ]。
goal of suppressing the spaces is once again to make the results of string operations predictable.
空間を抑圧するという目標がストリング操作の結果を予測できるようにするのがもう一度あります。
The values of the <value> elements are derived from the various CIM syntaxes according to a grammar specified in [5].
[5]で指定された文法に応じて、様々なCIM構文から<値の>要素の値を得ます。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[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仕様」、RFC3060、2月2001。
[2] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377, September
2002.
[2] ホッジズ、J.、およびR.モーガン、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「技術的な仕様」、RFC3377、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)について議定書の中で述べます」。 「属性構文定義」、RFC2252、1997年12月。
[4] The Directory: Models. ITU-T Recommendation X.501, 2001.
[4] ディレクトリ: モデル。 ITU-T推薦X.501、2001。
[5] Distributed Management Task Force, Inc., "Common Information
Model (CIM) Specification", Version 2.2, June 14, 1999. This
document is available on the following DMTF web page:
http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf
[5]分散管理特別委員会Inc.、「一般的な情報モデル(CIM)仕様」、バージョン2.2、1999年6月14日。 このドキュメントは以下のDMTFウェブページで利用可能です: http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf
[6] Distributed Management Task Force, Inc., "DMTF LDAP Schema for
the CIM v2.5 Core Information Model", April 15, 2002. This
document is available on the following DMTF web page:
http://www.dmtf.org/standards/documents/DEN/DSP0123.pdf
[6] 分配されたManagement Task Force Inc.、「CIM v2.5 Core情報ModelのためのDMTF LDAP Schema」2002年4月15日。 このドキュメントは以下のDMTFウェブページで利用可能です: http://www.dmtf.org/standards/documents/DEN/DSP0123.pdf
[7] Wahl, M., "A Summary of the X.500(96) User Schema for use with
LDAPv3", RFC 2256, December 1997.
[7] ウォール、M.、「LDAPv3"、RFC2256、1997年12月との使用のためのX.500(96)ユーザSchemaのSummary。」
[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)について議定書の中で述べます」。 「追加合っている規則」、RFC3698、2004年2月。
[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[10] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Strassner, et al. Standards Track [Page 58] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[58ページ]。
11.2. Informative References
11.2. 有益な参照
[11] Hovey, R. and S. Bradner, "The Organizations Involved in the
IETF Standards Process", BCP 11, RFC 2028, October 1996.
[11] ハービとR.とS.ブラドナー、「IETF標準化過程にかかわる組織」、BCP11、RFC2028、1996年10月。
[12] Strassner, J., policy architecture BOF presentation, 42nd IETF
Meeting, Chicago, Illinois, October 1998. Minutes of this BOF
are available at the following location:
http://www.ietf.org/proceedings/98aug/index.html.
[12]Strassner、J.、方針アーキテクチャBOFプレゼンテーション、第42IETF Meeting、シカゴ(イリノイ)1998年10月。 このBOFの分は以下の位置で有効です: 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.、ゲラン、研究開発Pendarakis、「方針ベースの入場コントロールのためのフレームワーク」、RFC2753、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.モーガン、「LDAPのための認証方法」、RFC2829、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)について議定書の中で述べます」。 「トランスポート層セキュリティのための拡大」(RFC2830)は2000がそうするかもしれません。
[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.、「インターネットはライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)のために数の権威(IANA)に問題を割り当てました」、BCP64、RFC3383、2002年9月。
Strassner, et al. Standards Track [Page 59] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[59ページ]。
12. Authors' Addresses
12. 作者のアドレス
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.0648Fax: +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. Box12195、BRQA/B501/G206 3039コーンウォリス通り リサーチトライアングル公園、NC27709-2195
Phone: +1 919-254-4436 Fax: +1 919-254-6243 EMail: remoore@us.ibm.com
以下に電話をしてください。 +1 919-254-4436Fax: +1 919-254-6243 メールしてください: remoore@us.ibm.com
Ryan Moats Lemur Networks, Inc. 15621 Drexel Circle Omaha, NE 68135
ライアン・モウツLemurはInc.15621ドレクセル・円のオマハ、Ne68135をネットワークでつなぎます。
Phone: +1-402-894-9456 EMail: rmoats@lemurnetworks.net
以下に電話をしてください。 +1-402-894-9456 メールしてください: rmoats@lemurnetworks.net
Ed Ellesson 3026 Carriage Trail Hillsborough, NC 27278
Trailヒルズバラ、エドEllesson3026キャリッジNC 27278
Phone: +1 919-644-3977 EMail: ellesson@mindspring.com
以下に電話をしてください。 +1 919-644-3977 メールしてください: ellesson@mindspring.com
Strassner, et al. Standards Track [Page 60] RFC 3703 Policy Core LDAP Schema February 2004
Strassner、他 規格は方針コアLDAP図式2004年2月にRFC3703を追跡します[60ページ]。
13. Full Copyright Statement
13. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Strassner, et al. Standards Track [Page 61]
Strassner、他 標準化過程[61ページ]
一覧
スポンサーリンク
