RFC 3703
Policy Core Lightweight Directory Access Protocol (LDAP) Schema
RFC 3703: Policy Core Lightweight Directory Access Protocol (LDAP) Schema ✨
Okay, title block first, because the details matter 🎀
- Network Working Group 🌸
- Request for Comments: 3703
- Authors: J. Strassner (Intelliden Corporation), B. Moore (IBM Corporation), R. Moats (Lemur Networks, Inc.), and E. Ellesson
- Category: Standards Track 💜
- Date: February 2004
- Obsoletes / Updates: this header doesn't list any RFCs it obsoletes or updates 🦋
Status of This Memo
Bestie, this one is an Internet standards track protocol document 🧚 It's meant for the whole Internet community, and it's asking for discussion and suggestions for improvements 💖 If you want the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). And distribution of this memo is unlimited, so share it with everyone 🌈
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. 💅
Abstract
Okay, so this document defines a mapping of the Policy Core Information Model into a form you can actually implement in a directory that uses Lightweight Directory Access Protocol (LDAP) as its access protocol 🫶 The model has two hierarchies of object classes. The first is the structural classes, which hold information for representing and controlling policy data as specified in RFC 3060. The second is the relationship classes, which show how instances of the structural classes are connected to each other 🔥
The schema also adds some classes to the LDAP schema to speed things up when a client is pulling large amounts of policy-related information from an LDAP server. These classes exist only to optimize LDAP retrievals, so there are no classes in the information model that correspond to them ✨
Table of Contents
1. Introduction ................................................. 2
2. The Policy Core Information Model ............................ 4
3. Inheritance Hierarchy for the PCLS ........................... 5
4. General Discussion of Mapping the Information Model to LDAP .. 6
4.1. Summary of Class and Association Mappings .............. 7
4.2. Usage of DIT Content and Structure Rules and Name Forms. 9
4.3. Naming Attributes in the PCLS .......................... 10
4.4. Rule-Specific and Reusable Conditions and Actions ...... 11
4.5. Location and Retrieval of Policy Objects in the
Directory .............................................. 16
4.5.1. Aliases and Other DIT-Optimization Techniques .. 19
5. Class Definitions ............................................ 19
5.1. The Abstract Class "pcimPolicy" ........................ 21
5.2. The Three Policy Group Classes ......................... 22
5.3. The Three Policy Rule Classes .......................... 23
5.4. The Class pcimRuleConditionAssociation ................. 30
5.5. The Class pcimRuleValidityAssociation .................. 32
5.6. The Class pcimRuleActionAssociation .................... 34
5.7. The Auxiliary Class pcimConditionAuxClass .............. 36
5.8. The Auxiliary Class pcimTPCAuxClass .................... 36
5.9. The Auxiliary Class pcimConditionVendorAuxClass ........ 40
5.10. The Auxiliary Class pcimActionAuxClass ................. 41
5.11. The Auxiliary Class pcimActionVendorAuxClass ........... 42
5.12. The Class pcimPolicyInstance ........................... 43
5.13. The Auxiliary Class pcimElementAuxClass ................ 44
5.14. The Three Policy Repository Classes .................... 45
5.15. The Auxiliary Class pcimSubtreesPtrAuxClass ............ 46
5.16. The Auxiliary Class pcimGroupContainmentAuxClass ....... 48
5.17. The Auxiliary Class pcimRuleContainmentAuxClass ........ 49
6. Extending the Classes Defined in This Document ............... 50
6.1. Subclassing pcimConditionAuxClass and pcimActionAuxClass 50
6.2. Using the Vendor Policy Attributes ..................... 50
6.3. Using Time Validity Periods ............................ 51
7. Security Considerations ...................................... 51
8. IANA Considerations .......................................... 53
8.1. Object Identifiers ..................................... 53
8.2. Object Identifier Descriptors .......................... 53
9. Acknowledgments .............................................. 56
10. Appendix: Constructing the Value of orderedCIMKeys .......... 57
11. References ................................................... 58
11.1. Normative References ................................... 58
11.2. Informative References ................................. 59
12. Authors' Addresses ........................................... 60
13. Full Copyright Statement ..................................... 611. Introduction 🎀
This document starts from the object-oriented information model for representing and controlling policy data, as specified in [1]. Hey, LDAP [2] implementers, listen up 👂 In this document, "policy" does not mean what X.501 [4] means by the word. Here's how this document uses "policy":
Policy is defined as a set of rules to administer, manage, and control access to network resources.
This work is being developed jointly in the IETF's Policy Framework working group and in the Policy working group of the Distributed Management Task Force (DMTF) 🌸 The model has two hierarchies of object classes. The structural classes represent policy information and how policies are controlled. The relationship classes show how instances of the structural classes are related. Generally, both of these class hierarchies will need to be mapped to a particular data store 💅
This document defines how those information model classes get mapped into a directory that uses LDAP as its access protocol. There are two types of mappings going on:
- For the structural classes in the information model, the mapping is basically one-for-one. Information model classes map to LDAP classes, and information model properties map to LDAP attributes.
- 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) 🧚
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. Basically, the information model in reference [1] is the starting point, which makes the inheritance and relationship class hierarchies extensible. That means other kinds of policy repositories, like relational databases, can use this information too 🦋
This document fits into the bigger framework for representing, deploying, and managing policies that the Policy Framework Working Group is building 🌈
The LDAP schema here uses the prefix "pcim" to name its classes and attributes. It has ten very general classes: pcimPolicy (an abstract class), three policy group classes (pcimGroup, pcimGroupAuxClass, and pcimGroupInstance), three policy rule classes (pcimRule, pcimRuleAuxClass, and pcimRuleInstance), and three special auxiliary classes (pcimConditionAuxClass, pcimTPCAuxClass, and pcimActionAuxClass). (Quick aside: the PolicyTimePeriodCondition auxiliary class defined in [1] would normally have been named pcimTimePeriodConditionAuxClass, but that name is too long for some directories. So they shortened it to 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 there's an abstract superclass that contains all required properties of each PCIM class. Then both an auxiliary class and a structural class are derived from that abstract superclass. That gives the developer maximum flexibility 👑
The schema also has two less general classes: pcimConditionVendorAuxClass and pcimActionVendorAuxClass. To map the information model's relationships, it also has two auxiliary classes: pcimGroupContainmentAuxClass and pcimRuleContainmentAuxClass. Capturing the difference between rule-specific and reusable policy conditions and policy actions brings in seven other classes: pcimRuleConditionAssociation, pcimRuleValidityAssociation, pcimRuleActionAssociation, pcimPolicyInstance, and three policy repository classes (pcimRepository, pcimRepositoryAuxClass, and pcimRepositoryInstance). Finally, two classes (pcimSubtreesPtrAuxClass and pcimElementAuxClass) are there for optimizing LDAP retrievals. All up, the schema has 23 classes 🔥
In this document, "PCLS" (Policy Core LDAP Schema) refers to the LDAP class definitions in this document. "PCIM" refers to the classes defined in [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] 💜
2. The Policy Core Information Model 🌸
This document has an LDAP schema that represents the classes defined in the companion document "Policy Core Information Model -- Version 1 Specification" [1]. Other documents may be made later, mapping this same PCIM to other storage technologies. The detailed semantics of the PCIM classes only show up in [1], so you need to read that document first to understand this one 📚
3. Inheritance Hierarchy for the PCLS 🦋
okay so this is the family tree for every LDAP class in this doc 🌳 it's giving org chart, and once you see how the branches connect the rest of the spec clicks ✨
top
|
+--dlm1ManagedElement (abstract)
| |
| +--pcimPolicy (abstract)
| | |
| | +--pcimGroup (abstract)
| | | |
| | | +--pcimGroupAuxClass (auxiliary)
| | | |
| | | +--pcimGroupInstance (structural)
| | |
| | +--pcimRule (abstract)
| | | |
| | | +--pcimRuleAuxClass (auxiliary)
| | | |
| | | +--pcimRuleInstance (structural)
| | |
| | +--pcimRuleConditionAssociation (structural)
| | |
| | +--pcimRuleValidityAssociation (structural)
| | |
| | +--pcimRuleActionAssociation (structural)
| | |
| | +--pcimPolicyInstance (structural)
| | |
| | +--pcimElementAuxClass (auxiliary)
| |
| +--dlm1ManagedSystemElement (abstract)
| |
| +--dlm1LogicalElement (abstract)
| |
| +--dlm1System (abstract)
| |
| +--dlm1AdminDomain (abstract)
| |
| +--pcimRepository (abstract)
| |
| +--pcimRepositoryAuxClass (auxiliary)
top
| |
| +--pcimRepositoryInstance
| (structural)
|
+--pcimConditionAuxClass (auxiliary)
| |
| +---pcimTPCAuxClass (auxiliary)
| |
| +---pcimConditionVendorAuxClass (auxiliary)
|
+--pcimActionAuxClass (auxiliary)
| |
| +---pcimActionVendorAuxClass (auxiliary)
|
+--pcimSubtreesPtrAuxClass (auxiliary)
|
+--pcimGroupContainmentAuxClass (auxiliary)
|
+--pcimRuleContainmentAuxClass (auxiliary)Figure 1. LDAP Class Inheritance Hierarchy for the PCLS
4. General Discussion of Mapping the Information Model to LDAP 💅
okay bestie, so the classes in Section 5 have some optimizations baked in for directories that use LDAP as their access protocol 🫶 one is using auxiliary classes to stand in for some of the associations from the information model. other data stores might handle those associations differently, just saying 🙈 the second is brand new classes made specifically so you can grab big piles of policy data out of a directory super fast 🚀 this section is the general tea on mapping the info model over to LDAP ☕
here's the roadmap for the rest of the section 🗺️ Section 4.1 covers the strategy for turning the classes and associations from [1] into something a directory using LDAP can actually hold. Section 4.2 is all about DIT content and structure rules plus name forms 📚. Section 4.3 explains how the naming attributes for the Section 5 schema were picked 🏷️. And Section 4.4 is the recommended way to find and fetch PCIM-derived objects in the directory 🔍
4.1. Summary of Class and Association Mappings 🎀
ngl this is where it gets fun 🤩 fifteen of the classes in the PCLS come straight from the nine matching classes in the information model. quick thing to know: info model class names start with an uppercase letter, but LDAP ones start lowercase. the reason is that LDAP doesn't care about case, but X.500 won't let class names start with an uppercase character 💀 (for CIM in particular, case doesn't matter in class and property names either). also, the prefix "pcim" is how you spot these LDAP classes 🌸
+---------------------------+-------------------------------+
| Information Model | LDAP Class(es) |
+---------------------------+-------------------------------+
+---------------------------+-------------------------------+
| Policy | pcimPolicy |
+---------------------------+-------------------------------+
| PolicyGroup | pcimGroup |
| | pcimGroupAuxClass |
| | pcimGroupInstance |
+---------------------------+-------------------------------+
| PolicyRule | pcimRule |
| | pcimRuleAuxClass |
| | pcimRuleInstance |
+---------------------------+-------------------------------+
| PolicyCondition | pcimConditionAuxClass |
+---------------------------+-------------------------------+
| PolicyAction | pcimActionAuxClass |
+---------------------------+-------------------------------+
| VendorPolicyCondition | pcimConditionVendorAuxClass |
+---------------------------+-------------------------------+
| VendorPolicyAction | pcimActionVendorAuxClass |
+---------------------------+-------------------------------+
| PolicyTimePeriodCondition | pcimTPCAuxClass |
+---------------------------+-------------------------------+
| PolicyRepository | pcimRepository |
| | pcimRepositoryAuxClass |
| | pcimRepositoryInstance |
+---------------------------+-------------------------------+Figure 2. Mapping of Information Model Classes to LDAP
okay so now the associations 💜 in the info model they turn into attributes that point at DNs (Distinguished Names), or into DIT containment (basically the superior-subordinate parent-child vibes in LDAP) 🌳. and two of those DN-pointing attributes live in auxiliary classes, which lets each one stand for several relationships from the info model. iconic multitasking 👑
+----------------------------------+----------------------------------+
| Information Model Association | LDAP Attribute / Class |
+-----------------------------------+---------------------------------+
+-----------------------------------+---------------------------------+
| PolicyGroupInPolicyGroup | pcimGroupsAuxContainedSet in |
| | pcimGroupContainmentAuxClass |
+-----------------------------------+---------------------------------+
| PolicyRuleInPolicyGroup | pcimRulesAuxContainedSet in |
| | pcimRuleContainmentAuxClass |
+-----------------------------------+---------------------------------+
| PolicyConditionInPolicyRule | DIT containment or |
| | pcimRuleConditionList in |
| | pcimRule or |
| | pcimConditionDN in |
| | pcimRuleConditionAssociation |
+-----------------------------------+---------------------------------+
| PolicyActionInPolicyRule | DIT containment or |
| | pcimRuleActionList in |
| | pcimRule or |
| | pcimActionDN in |
| | pcimRuleActionAssociation |
+-----------------------------------+---------------------------------+
| PolicyRuleValidityPeriod | pcimRuleValidityPeriodList |
| | in pcimRule or (if reusable) |
| | referenced through the |
| | pcimTimePeriodConditionDN in |
| | pcimRuleValidityAssociation |
+-----------------------------------+---------------------------------+
| PolicyConditionInPolicyRepository | DIT containment |
+-----------------------------------+---------------------------------+
| PolicyActionInPolicyRepository | DIT containment |
+-----------------------------------+---------------------------------+
| PolicyRepositoryInPolicyRepository| DIT containment |
+-----------------------------------+---------------------------------+Figure 3. Mapping of Information Model Associations to LDAP
last bit of the family drama 🎭 two of the leftover classes in the PCLS, pcimElementAuxClass and pcimSubtreesPtrAuxClass, are there to make moving around the DIT and grabbing entries from it more efficient 🏃♀️💨 that gets its own discussion in Section 4.5.
and the other four, pcimRuleConditionAssociation, pcimRuleValidityAssociation, pcimRuleActionAssociation, and pcimPolicyInstance, are all about representing policy conditions and policy actions in an LDAP directory 🧚 those are covered in Section 4.4 below. periodt 💖
4.2. Usage of DIT Content and Structure Rules and Name Forms ✨
okay so there are three powerful tools that can help define schemata 💅 The first one is DIT content rules. They basically decide what an entry for a structural object class is supposed to look like 🎀 A DIT content rule can specify:
- 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 🙈
Next up, a DIT structure rule. It works together with a name form to control the placement and naming of an entry within the scope of a subschema 🧚 Name forms define which attribute types are required and which are allowed to be used when forming the Relative Distinguished Names (RDNs) of entries. DIT structure rules specify which entries are allowed to be superior to other entries, so they control how RDNs get stacked together to make 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
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 💜
Unfortunately, current LDAP servers vary quite a lot in how well they support these features 😭 There are also three crucial implementation points that must be followed. First, X.500 use of structure rules requires that a structural object class with no superior structure rule be a subschema administrative point. This is exactly NOT what we want for policy information 🙅♀️ Second, when an auxiliary class is subclassed, if a content rule exists for the structural class that the auxiliary class refers to, then that content rule needs to be augmented. Finally, most LDAP servers unfortunately do not support inheritance of structure and content rules 💀
Given all these concerns, DIT structure and content rules have been removed from the PCLS. If they were included, they would be normative references and would require OIDs. But we don't want to lose the insight gained from building the structure and content rules of the previous version of the schema, so we describe where such rules could be used in this schema, what they would control, and what their effect would be 🌈
4.3. Naming Attributes in the PCLS
okay so instances in a directory are identified by distinguished names (DNs), which give you the same kind of hierarchical organization a file system gives you on a computer 📁 A distinguished name is a sequence of RDNs. An RDN gives an instance a unique identifier within the context of its immediate superior, the same way a filename gives a file a unique identifier within the folder it lives in 🎀
To give policy administrators maximum naming flexibility, three optional (i.e., "MAY") naming attributes have been defined. They are:
- 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 use these attributes to guarantee there will be no name collisions between instances of different classes, even if the same value is assigned to the instances' respective naming attributes ✨
- 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) 🧚
- 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 🦋
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 👑
Heads up, bestie 💅 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 🙈
4.4. Rule-Specific and Reusable Conditions and Actions ✨
okay so the PCIM [1] splits policy conditions and policy actions into two flavours: the ones attached to a single policy rule, and the reusable ones that can be linked to more than one rule. bestie, there's no inherent functional difference between a rule-specific condition or action and a reusable one 💅 but there is a difference in how you use them and how you implement them, and it's giving main character energy 👑
Defining something as reusable vs. rule-specific is a conscious choice the administrator makes about how it'll be used 🎀 There are also variations for how rule-specific and reusable conditions and actions get implemented, and how they're treated in a policy repository 🦋 The big implementation differences between a rule-specific and a reusable condition or action are:
- It's natural for a rule-specific condition or action to be removed from the policy repository at the same time the rule is. It's the opposite for reusable conditions and actions 🌸 That's because a rule-specific one is conceptually attached to the rule, whereas a reusable one is referenced (e.g., pointed at). The persistence of a
pcimRepositoryinstance is independent of the persistence of apcimRuleinstance. - Access permissions for a rule-specific condition or action are usually identical to those for the rule itself. Reusable conditions and actions, on the other hand, must have access permissions that can be expressed without reference to a policy rule 🔐
- Rule-specific conditions and actions require fewer accesses, because they're "attached" to the rule. Reusable conditions and actions require more accesses, since each reusable condition or action needs its own separate access 🧚
- Rule-specific conditions and actions are designed for use by a single rule. As the number of rules using the same rule-specific condition goes up, subtle problems pop up (the most obvious one being how to keep every copy updated to the same value) 😭 Reusable conditions and actions are made for use by multiple independent rules 💜
- Reusable conditions and actions give you an optimization when multiple rules use the same one. The reusable condition or action only needs to be updated once, and because of DN reference, the policy rules get updated automatically ✨
The paragraph above isn't an exhaustive list of how reusable and rule-specific conditions should be treated differently 🙈 Its whole purpose is to justify the semantic distinction between rule-specific and reusable, and then reflect that distinction in the policy repository itself.
When the policy repository lives in an LDAP-accessible directory, the rule-specific vs. reusable split gets realized through auxiliary classes and DIT containment 🌈 Figure 4 shows a policy rule Rule1 with one rule-specific condition CA and one rule-specific action AB:
+-----+
|Rule1|
| |
+-----|- -|-----+
| +-----+ |
| * * |
| * * |
| **** **** |
| * * |
v * * v
+--------+ +--------+
| CA+ca | | AB+ab |
+--------+ +--------+
+------------------------------+
|LEGEND: |
| ***** DIT containment |
| + auxiliary attachment |
| ----> DN reference |
+------------------------------+Figure 4 Rule-Specific Policy Conditions and Actions
Because the condition and action are specific to Rule1, the auxiliary classes ca and ab that represent them are attached to the structural classes CA and AB respectively 🍓 Those structural classes don't represent the condition ca or the action ab themselves. They represent the associations between Rule1 and ca, and between Rule1 and ab.
As Figure 4 shows, Rule1 contains DN references to the structural classes CA and AB, which sit below it in the DIT. At first glance you might think those DN references are unnecessary, since a subtree search below Rule1 would find every structural class representing the associations between Rule1 and its conditions and actions 🤔 But relying only on a subtree search runs the risk of missing conditions or actions that should have appeared in the subtree but for some reason didn't. It also runs the risk of finding conditions or actions that were placed in the subtree by mistake, or that should have been removed from it but for some reason weren't 😬 Implementation experience has suggested that many (but not all) of these risks go away.
However, it must be noted that this comes at a price 💀 The use of DN references, like in Figure 4 above, gets in the way of inheritance of access control information as well as existence dependency information. It's also subject to referential integrity considerations. So it's included as an option for the designer 🫶
Figure 5 shows a second way to represent rule-specific conditions and actions in an LDAP-accessible directory: attaching the auxiliary classes directly to the instance representing the policy rule 🦋 When all of the conditions and actions are attached to a policy rule this way, the rule is called a "simple" policy rule. When conditions and actions aren't attached directly to a policy rule, the rule is called a "complex" policy rule.
+-----------+
|Rule1+ca+ab|
| |
+-----------+
+------------------------------+
|LEGEND: |
| + auxiliary attachment |
+------------------------------+Figure 5. A Simple Policy Rule
The simple/complex distinction for a policy rule isn't all or nothing 🌷 A policy rule can have its conditions attached to itself while its actions are attached to other entries, or it can have its actions attached to itself while its conditions are 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. 🚫
The tradeoffs between simple and complex policy rules come down to the efficiency of simple rules vs. the flexibility and greater reuse potential of complex rules ⚖️ With a simple policy rule, your 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) expressions characteristic of policy conditions (please see [1] for definitions of these terms): 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.
- 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's a set of actions that must be ordered, then the only option is a complex policy rule 🧠
Finally, Figure 6 shows the same policy rule Rule1, but this time its condition and action are reusable 💖 The association classes CA and AB are still there, and they're still DIT contained under Rule1. But instead of having the auxiliary classes ca and ab attached directly to CA and AB, each one now contains DN references to other entries that those auxiliary classes are attached to. These other entries, CIA and AIB, are DIT contained under RepositoryX, which is an instance of the class pcimRepository. Because they're named under an instance of pcimRepository, ca and ab are clearly identified as reusable 🌈
+-----+ +-------------+
|Rule1| | RepositoryX |
+-|- -|--+ | |
| +-----+ | +-------------+
| * * | * *
| * * | * *
| *** **** | * *
| * * v * *
| * +---+ * *
| * |AB | +------+ *
v * | -|-------->|AIB+ab| *
+---+ +---+ +------+ *
|CA | +------+
| -|------------------------>|CIA+ca|
+---+ +------+
+------------------------------+
|LEGEND: |
| ***** DIT containment |
| + auxiliary attachment |
| ----> DN reference |
+------------------------------+Figure 6. Reusable Policy Conditions and Actions
The classes pcimConditionAuxClass and pcimActionAuxClass don't represent actual conditions and actions themselves 🙃 Those get introduced in their subclasses. What pcimConditionAuxClass and pcimActionAuxClass do introduce are the semantics of being a policy condition or a policy action. Every subclass of pcimConditionAuxClass and pcimActionAuxClass inherits those semantics, and among them are the semantics of representing either a rule-specific or a reusable policy condition or policy action 💜
To keep 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. 🎀✨
4.5. Location and Retrieval of Policy Objects in the Directory ✨
okay so bestie, picture a PDP (Policy Decision Point) going into an LDAP directory to grab the policy objects for the PEPs (Policy Enforcement Points) it looks after. 💅 It runs into two related problems:
- How does it find the directory entries that apply to its PEPs? 🔍 Those entries might be instances of the PCLS classes, instances of domain-specific subclasses of those classes, and instances of other classes that model things like user groups, interfaces, and address ranges.
- How does it grab those entries efficiently, so that pulling policy info out of the directory doesn't become a roadblock for scalability? 🚧 There are two parts to this efficiency: only fetching the entries that are actually relevant, and fetching them with as few LDAP calls as possible.
Here's the tea 🍵: where objects sit in the Directory Information Tree (DIT) is decided by way more than just how a PDP will retrieve policy objects. So the PCLS can only give the policy admin a "toolkit" of classes to help while they're designing and building the DIT. 🧰 A PDP SHOULD be able to take advantage of any tools the policy administrator manages to build into the DIT, but it MUST be able to fall back to a less efficient way of retrieving things if that's all it has. 🫶
The big idea behind the LDAP optimization classes is pretty simple 🦋: let a PDP retrieve all the policy-related objects it needs, and only those, using as few LDAP calls as possible. The key assumption here is that the policy administrator has enough control over the DIT structure to define subtrees for storing policy info. If they don't have that level of control, a PDP can still fetch the policy-related objects it needs one at a time. 😩 It'll just need more LDAP access operations to pull them all in that way. Figure 7 shows how LDAP optimization works:
+-----+
---------------->| A |
DN reference to | | DN references to subtrees +---+
starting object +-----+ +-------------------------->| C |
| o--+----+ +---+ +---+
| o--+------------->| B | / \
+-----+ +---+ / \
/ \ / \ / ... \
/ \ / \
/ \ / ... \
Figure 7. Using the pcimSubtreesPtrAuxClass to Locate PoliciesOkay, so the PDP starts out configured with a DN reference to some entry in the DIT. 🌸 The structural class of that entry doesn't matter at all. The PDP only cares about the pcimSubtreesPtrAuxClass attached to it. That auxiliary class holds a multi-valued attribute full of DN references to objects that anchor subtrees containing policy-related objects the PDP wants. And since pcimSubtreesPtrAuxClass is auxiliary, it can be stuck onto an entry the PDP would have to access anyway, like an entry with initial configuration settings for the PDP itself or for a PEP that uses the PDP. 🎀
Once it has those DN references, the PDP sends each of the objects they point to an LDAP request asking that every entry in its subtree gets checked against the selection criteria in the request. ✨ The LDAP-enabled directory then sends back every entry in that subtree that passes the criteria.
The selection criteria always say object class="pcimPolicy". 💜 Every class that represents policy rules, policy conditions, and policy actions, whether it's in the PCLS or in a domain-specific schema built from it, is a subclass of the abstract class policy. So this criterion comes out TRUE for all instances of those classes. 😭 Now, for the special cases where a PDP needs objects that aren't policy-related on their own (like an IP address range object pointed to by a subclass of pcimActionAuxClass that represents the DHCP action "assign from this address range"), the auxiliary class pcimElementAuxClass can "tag" an entry. That way the entry still gets found by the selection criterion object class="pcimPolicy". 🏷️
Heads up: the tagging trick I just described won't work with certain directory implementations, because those don't support matching auxiliary classes in the objectClass attribute. 🙈
For environments where those implementations are expected to show up, you can tag an entry as relevant to policy by putting the special value "POLICY" into the list of values in the pcimKeywords attribute (which comes from the pcimPolicy class). 🍓
If a PDP only needs a subset of the policy-related objects in the indicated subtrees, it can be configured with extra selection criteria based on the pcimKeywords attribute from the pcimPolicy class. 🔥 That attribute supports both standardized values and administrator-defined ones. For example, a PDP could be set up to only request policy-related objects containing the keywords "DHCP" and "Eastern US". 🇺🇸
Here's a cute optimization for the typical case 🧚: the client's first request includes not just the object its "seed" DN points to, but also the subtree under that object. The filter for searching that subtree is whatever the client will use later to search the other subtrees. That's object class="pcimPolicy", or the presence of the keyword "POLICY", and/or the presence of a more specific pcimKeywords value (for example, "QoS Edge Policy"). 💖
Now back to Figure 7 🦋. In the best case, a PDP can get all the policy-related objects it needs, and only those, with exactly three LDAP requests. First, one request to its starting object A to get the references to B and C, plus the policy-related objects it needs from the subtree under A. Then one request each to B and C to get all the policy-related objects that pass the selection criteria it was configured with. 👑 Once it has all of those objects, the PDP can follow their various DN references locally to figure out how they relate to each other semantically. 🧠 The PDP should also be ready to find a reference to another subtree attached to any object it retrieves, and to follow that subtree reference first, before it follows any of the semantically significant references it received. This recursion gives you a structured way to find related policies. In Figure 7, for example, if the subtree under B holds departmental policies and the subtree under C holds divisional policies, there might be a reference from the subtree under C to an object D that roots the subtree of corporate-level policies. 🏢
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 that needs to pull policy info out of the directory. So a Policy Management Tool that grabs policy entries from the directory to do validation and conflict detection SHOULD also understand and be capable of using the pcimSubtreesPtrAuxClass. 🛠️ All of these requirements are "SHOULD"s rather than "MUST"s, because an LDAP client that doesn't implement them can still access and retrieve the directory entries it needs. 💅 It'll just be less efficient than it would've been if the client had built in these optimizations. 🐢
When a Policy Management Tool is acting as a tool for creating policy entries in the directory, it SHOULD support creating pcimSubtreesPtrAuxClass entries and their references to object instances. 🎀
4.5.1. Aliases and Other DIT-Optimization Techniques
The policy admin gets even more flexibility in DIT structure through LDAP aliasing and other techniques. 🦋 Earlier versions of this document used aliases. 💀 But aliases are experimental, so they've been removed from this version. The reason is that the IETF hasn't yet produced a specification for how aliases are represented in the directory or how server implementations are supposed to process them. 🙃
5. Class Definitions ✨
okay so this part is where the actual schema lives, bestie 🎀 The policy information classes that map straight from the information model to LDAP are already fully explained in [1], so this section only covers how to do that mapping. The info model doesn't care what repository or access protocol you use, so this is the bridge that gets it into LDAP 🌉 Some brand-new LDAP-only classes had to be invented too (they weren't in [1]), and those are fully documented right here 💖
The formal language for the classes, attributes, and DIT structure and content rules is the one defined in reference [3] 📜 If your implementation doesn't support auxiliary class inheritance, you'll have to list auxiliary classes in content rules explicitly, or define them some other implementation-specific way 🫶
The following notes apply to this whole section, so read them all 👀
Note 1: in the definitions below, the class and attribute definitions follow RFC 2252 [3], but they're line-wrapped so they're easier for humans to read 📖
Note 2: where it applies, the ways to specify DIT structure and content rules are noted. BUT be careful with DIT structure rules 🚨 X.501 [4] says an entry can 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:
- indicates a name form for the structural object class of the subordinate entry, and
- either includes the entry's superior structure rule as a possible superior structure rule, or
- does not specify a superior structure rule.
If that last case (3) applies, the entry is defined to be a subschema administrative point, and that is NOT what we want 💀 So structure rules need real care, and in particular they must be locally augmented 🧩
Note 3: wherever possible, BOTH an equality and a substring matching rule get defined for a particular attribute (plus an ordering match rule so results can be sorted) 🍓 That gives developers two different choices for maximum flexibility ✨
Let's look at the pcimRoles attribute (section 5.3) as an example 👀 Say a PEP has reported that it's interested in pcimRules for three roles, R1, R2, and R3. If the goal is to minimize queries, the PDP can supply three substring filters, each containing one of the three role names 🔍
These queries will return all of the pcimRules that apply to the PEP, but they might also grab some that DON'T apply. For example, ones that contain one of the roles R1, R2, or R3 plus one or more other roles from a role-combination [1] 🙃
Another strategy is for the PDP to use only equality filters 💅 That kills the extra replies, but now the PDP has to build the desired role-combinations itself, and it needs extra queries too. This approach is only practical because the role names in a role combination are required to appear in alphabetical order 🔤
Note 4: in the definitions below, all LDAP matching rules are defined in [3] and [9]. The matching X.500 rules are defined in [8] 📚
Note 5: some attribute definitions below add extra constraints on data types. For example, this integer is only valid from 1..10 🔢 Text has been added to tell servers and applications what to do when a value outside that range shows up. In every case, if a constraint is violated, the policy rule SHOULD be treated as being disabled, meaning that execution of the policy rule SHOULD be stopped 🛑 (ngl this is the part where you DON'T want to skip ahead 😭)
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 how you identify policy-related instances in the Directory Information Tree 🌳 Any instance of any class can be "tagged" with this class value by attaching the auxiliary class pcimElementAuxClass to it 🏷️ Since pcimPolicy is derived from the class dlm1ManagedElement defined in reference [6], this spec has a normative dependency on that element of [6] 🫶
Here's the class definition:
( 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 pcimKeywords attribute is a multi-valued attribute holding a set of keywords that help directory clients find the policy objects tagged with them 🔍 It's defined like this:
( 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
)5.2. The Three Policy Group Classes
PCIM [1] defines the PolicyGroup class as a generalized aggregation mechanism, so PolicyRules and/or PolicyGroups can be bundled together 📦 PCLS maps this one class into three LDAP classes: pcimGroup, pcimGroupAuxClass, and pcimGroupInstance 💖 Splitting it up is done on purpose, to give the DIT designer maximum flexibility 🧚
The definitions for the three policy group classes are below. They do NOT include attributes for the PolicyRuleInPolicyGroup and PolicyGroupInPolicyGroup associations from the PCIM, because a pcimGroup object refers to instances of pcimGroup and pcimRule through, respectively, the attribute pcimGroupsAuxContainedSet in the pcimGroupContainmentAuxClass object class and the attribute pcimRulesAuxContainedSet in the pcimRuleContainmentAuxClass object class 🔗
To maximize flexibility, pcimGroup is defined as abstract 🦋 The subclass pcimGroupAuxClass gives you auxiliary attachment to another entry, while the structural subclass pcimGroupInstance lets you represent a policy group as a standalone entry 🌸 Here's the abstract pcimGroup first:
( 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 )
)pcimGroup's one attribute is pcimGroupName 🏷️ It holds a user-friendly name for the policy group, and it can be used as a naming attribute if you want 🫶 Here's how it's defined:
( 1.3.6.1.1.6.2.4 NAME 'pcimGroupName'
DESC 'The user-friendly name of this policy group.'
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)The two subclasses of pcimGroup are next 🎀 pcimGroupAuxClass is an auxiliary class you can use to collect a set of related pcimRule and/or pcimGroup classes:
( 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
)And pcimGroupInstance is a structural class, also for collecting a set of related pcimRule and/or pcimGroup classes 🧩
( 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 so an instance of pcimGroupInstance can 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 formalize the semantics of the PolicyGroup class [1]. Since those semantics don't include specifying any properties of PolicyGroup, the content rule wouldn't need to specify any attributes 🙈
Similarly, three separate DIT structure rules could be written, each referring to a specific name form that identifies one of the three possible naming attributes (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
The information model defines a PolicyRule class to represent the "If Condition then Action" semantics for processing policy information 🧠 For maximum flexibility, PCLS maps this class into three LDAP classes 🦋
Same energy as before: pcimRule is defined as abstract 💅 The subclass pcimRuleAuxClass gives you auxiliary attachment to another entry, while the structural subclass pcimRuleInstance lets you represent a policy rule as a standalone entry 🌸
The conditions and actions of a policy rule are modeled with auxiliary subclasses of the auxiliary classes pcimConditionAuxClass and pcimActionAuxClass 🎀 Each of those auxiliary subclasses gets attached to an instance of one of three structural classes. A subclass of pcimConditionAuxClass attaches to an instance of pcimRuleInstance, to an instance of pcimRuleConditionAssociation, or to an instance of pcimPolicyInstance. Similarly, a subclass of pcimActionAuxClass attaches 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 from the PCIM 🕰️ That association has no extra properties beyond the ones tying it to its associated objects, so it can be realized by simply using an attribute ✨ So pcimRuleValidityPeriodList is just a multi-valued attribute giving an unordered set of DN references to one or more instances of pcimTPCAuxClass, showing when the policy rule is scheduled to be active and when it's 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 PolicyActionInPolicyRule association defines an integer attribute to sequence the actions 🔢 The PolicyConditionInPolicyRule association has both an integer attribute to group the condition terms AND a Boolean property to specify whether a condition is to be negated 🙃
In the PCLS, these extra association attributes show up as attributes of two classes made just for modelling these associations, bestie 🎀. Those are the pcimRuleConditionAssociation class and the pcimRuleActionAssociation class, defined in Sections 5.4 and 5.5 respectively. So they never appear as attributes of pcimRule itself 🙈. Instead, the pcimRuleConditionList and pcimRuleActionList attributes point at these classes 🔗.
Okay, here are the class definitions for the three pcimRule classes ✨.
First up is the abstract class pcimRule 🧚. It's the base class for representing the "If Condition then Action" semantics tied to a policy rule, and it looks like this 💜:
( 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 )
)Here's the vibe check 💅. PCIM [1] defines seven properties for the PolicyRule class. The PCLS gives the pcimRule class (the LDAP version of PolicyRule) eleven attributes 🦋. Seven of those map straight across from PCIM's PolicyRule properties. The other four are a class-specific optional naming attribute plus three attributes that make the three associations pcimRule takes part in work 🫶.
The pcimRuleName attribute is the user-friendly name of the policy rule 🌸. It can also double as the class-specific optional naming attribute 👑:
( 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 enum saying whether a rule is administratively enabled (value=1), administratively disabled (value=2), or enabled for debug (value=3) 🔥:
( 1.3.6.1.1.6.2.6 NAME 'pcimRuleEnabled'
DESC 'An integer indicating whether a policy rule is
administratively enabled (value=1), disabled
(value=2), or enabled for debug (value=3).'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)Note: All other values for the pcimRuleEnabled attribute are considered errors, and the administrator SHOULD treat this rule as being disabled if an invalid value is found. 🚨
The pcimRuleConditionListType attribute says whether the rule's list of conditions is in disjunctive normal form (DNF, value=1) or conjunctive normal form (CNF, value=2) 🌈:
( 1.3.6.1.1.6.2.7 NAME 'pcimRuleConditionListType'
DESC 'A value of 1 means that this policy rule is in
disjunctive normal form; a value of 2 means that this
policy rule is in conjunctive normal form.'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)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 multi-valued and realizes the policyRuleInPolicyCondition association defined in [1] 🧠. It holds a set of DNs of pcimRuleConditionAssociation entries, which represent associations between this rule and its conditions. No order is implied 🍓:
( 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
)The pcimRuleActionList attribute is also multi-valued, and it realizes the policyRuleInPolicyAction association defined in [1] 💖. It holds a set of DNs of pcimRuleActionAssociation entries for the rule's actions. Again, no order is implied ✨:
( 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 multi-valued and realizes the pcimRuleValidityPeriod association defined in [1] 🗓️. It holds a set of DNs of pcimRuleValidityAssociation entries that decide when the pcimRule is scheduled to be active or inactive. No order is implied 🦋:
( 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 with guidelines on how the policy should be used 📝:
( 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
)The pcimRulePriority attribute is a non-negative integer used to rank this pcimRule against other pcimRules 👑. A larger value means higher priority 🚀:
( 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. 😬
The pcimRuleMandatory attribute is a Boolean. If it's TRUE, the rule's conditions must be evaluated and its actions must be executed (if the condition is satisfied) 🫡. If it's FALSE, that evaluation and execution is not required 🌸:
( 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 enum that says the ordering of actions set by the pcimActionOrder attribute is either mandatory(value=1), recommended(value=2), or dontCare(value=3) 🎀:
( 1.3.6.1.1.6.2.14 NAME 'pcimRuleSequencedActions'
DESC 'An integer enumeration indicating that the ordering of
actions defined by the pcimActionOrder attribute is
mandatory(1), recommended(2), or dontCare(3).'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)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 is a role-combination, which is a string of the form shown below, with the individual role names in alphabetical order according to the collating sequence for UCS-2 🔤:
<RoleName>[&&<RoleName>]*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
)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. 🥺
Next are the two subclasses of pcimRule 🧁. First, pcimRuleAuxClass is an auxiliary class for representing the "If Condition then Action" semantics tied to a policy rule 💫:
( 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
)Then there's pcimRuleInstance, a structural class for representing those same semantics 🦄:
( 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.'
SUP pcimRule
STRUCTURAL
)A DIT content rule could be written so that an instance of pcimRuleInstance can 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 formalize the semantics of the PolicyRule class [1]. Since those semantics don't include specifying any properties of the PolicyRule class, the content rule wouldn't need to specify any attributes 🌈.
Similarly, three separate DIT structure rules could be written, each referring to a specific name form that identifies one of the three possible naming attributes (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 ✨
Okay so this class is where we keep the details of PCIM's PolicyConditionInPolicyRule association 💅 Every instance gets DIT-contained under a pcimRule instance, which is very neat 🎀 The actual policy conditions are auxiliary subclasses of pcimConditionAuxClass. For rule-specific conditions, those aux classes get attached straight onto pcimRuleConditionAssociation instances 🦋 For a reusable condition, it's a bit different: the policyCondition aux subclass lives on a pcimPolicyInstance (which is presumably tied to a pcimRepository through DIT containment), and the policyConditionDN attribute in this class points at that reusable instance. Iconic reference energy 🔥
The class definition goes like this:
( 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 )
)Here's the rundown on each attribute 🌸
The pcimConditionGroupNumber attribute is a non-negative integer, and it tells you which group a referenced condition belongs to. It's literally how the DNF or CNF expression for a policy rule gets built 🧚 Defined like so:
( 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
)Note that this number has to be non-negative 🙈 A negative value is invalid, and any policy rule that refers to an invalid entry SHOULD be treated as being disabled. Big yikes energy, so don't do it 💀
The pcimConditionNegated attribute is a Boolean that says whether the policy condition gets negated or not. If it's TRUE (FALSE), the condition IS (IS NOT) negated in the DNF or CNF expression for the rule 💜 Here it is:
( 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
)The pcimConditionName is a user-friendly name for spotting a policy condition, and you can use it as a naming attribute if you want to 🎀
( 1.3.6.1.1.6.2.18
NAME 'pcimConditionName'
DESC 'A user-friendly name for a policy condition.'
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)The pcimConditionDN attribute is a DN that points at an instance of a reusable policy condition 🦋
( 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
)Now for the DIT stuff, which is giving architect 👑 A DIT content rule could be written so an instance of pcimRuleConditionAssociation can have an instance of the auxiliary class pcimConditionAuxClass (or one of its subclasses) attached to it. That's how you formalize the semantics of the PolicyConditionInPolicyRule association, and specifically how you represent a rule-specific policy condition [1]. Then you'd write three separate DIT structure rules, and each one would point at a name form with two key jobs. First, each name form picks out one of the three possible naming attributes for the pcimRuleConditionAssociation object class: pcimConditionName, cn, or orderedCIMKeys. Second, each name form requires that the pcimRuleConditionAssociation instance has a pcimRule instance as its superior. Also, this structure rule SHOULD include a superiorStructureRule (see Note 2 at the beginning of section 5) 🫶
5.5. The Class pcimRuleValidityAssociation 🌈
Here the policyRuleValidityPeriod aggregation gets mapped to the PCLS pcimRuleValidityAssociation class. This class is the scheduled activation and deactivation of a policy rule, because it binds the definition of when the policy is active to the rule itself ⏰ The "scheduled" times come either from an attached auxiliary class pcimTPCAuxClass, or from whatever pcimTimePeriodConditionDN attribute references.
The class is defined like this:
( 1.3.6.1.1.6.1.9 NAME 'pcimRuleValidityAssociation'
DESC 'This defines the scheduled activation or deactivation
of a policy rule.'
SUP pcimPolicy
STRUCTURAL
MAY ( pcimValidityConditionName $ pcimTimePeriodConditionDN )
)The attributes are defined as follows 🍓
The pcimValidityConditionName attribute gives a user-friendly name for this condition, and you may use it as a naming attribute if you like ✨
( 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
)The pcimTimePeriodConditionDN attribute is a DN that references a reusable time period condition 💜
( 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
)A DIT content rule could be written so an instance of pcimRuleValidityAssociation gets an instance of the auxiliary class pcimTPCAuxClass (or one of its subclasses) attached to it. That's how you formalize the semantics of the PolicyRuleValidityPeriod aggregation [1] 🦋
Same deal as before: three separate DIT structure rules could be written, each one pointing at a name form with two important semantics. First, each name form identifies one of the three possible naming attributes for the pcimRuleValidityAssociation object class: pcimValidityConditionName, cn, or orderedCIMKeys. Second, each name form requires that the pcimRuleValidityAssociation instance has a pcimRule instance as its superior. And yep, this structure rule SHOULD also include a superiorStructureRule (see Note 2 at the beginning of section 5) 💅
5.6. The Class pcimRuleActionAssociation ✨
okay so this class holds the one property of the PCIM PolicyActionInPolicyRule association, and that property is ActionOrder 🎀. ActionOrder is what decides the order the actions linked to a policy rule get executed in 💅. Every instance of this class is related to an instance of pcimRule through DIT containment 🌸. The actions themselves are represented by auxiliary subclasses of the auxiliary class pcimActionAuxClass 🦋.
here's the split 👑. For rule-specific policy actions, the auxiliary classes get attached directly to instances of pcimRuleActionAssociation 💖. For a reusable policy action, the pcimAction auxiliary subclass gets attached to an instance of the class pcimPolicyInstance (which is presumably associated with a pcimRepository by DIT containment 🧚). Then the pcimActionDN attribute (of this class) is used to reference the reusable pcimCondition instance 🙈.
The class definition is as follows:
( 1.3.6.1.1.6.1.10 NAME 'pcimRuleActionAssociation'
DESC 'This class contains attributes characterizing the
relationship between a policy rule and one of its
policy actions.'
SUP pcimPolicy
MUST ( pcimActionOrder )
MAY ( pcimActionName $ pcimActionDN )
)the pcimActionName attribute is a user-friendly name for the action 🥰. It can be used as a naming attribute too, if you want 🍓. Here's how it's defined:
( 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
)the pcimActionOrder attribute is an unsigned integer that tells you where an action sits in a sequence of actions for a given policy rule 📋. When the number is positive, it's a spot in the sequence, and smaller numbers go earlier ⭐. If the value is zero, the order doesn't matter at all 🌈. Also, if two or more actions have the same non-zero value, they can run in any order, as long as each one still lands in the right spot in the overall sequence 🫶. Here's the definition:
( 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
)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. 🚨
the pcimActionDN attribute is a DN that points at a reusable policy action 🔗. It's defined like this:
( 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
)a DIT content rule could be written so that an instance of pcimRuleActionAssociation gets an instance of the auxiliary class pcimActionAuxClass (or one of its subclasses) attached to it 🧩. That's how you'd formalize the semantics of the PolicyActionInPolicyRule association. Specifically, it's what you'd use to represent a rule-specific policy action [1] 💅.
and then there are three separate DIT structure rules that could be written 🦋. Each one would refer to a specific name form with two important semantics ✨. First, each name form identifies one of the three possible naming attributes (i.e., pcimActionName, cn, and orderedCIMKeys) for the pcimRuleActionAssociation object class 🎀. Second, each name form requires that an instance of the pcimRuleActionAssociation class have an instance of the pcimRule class as its superior 👑. This structure rule should also include a superiorStructureRule (see Note 2 at the beginning of section 5) 🌸.
5.7. The Auxiliary Class pcimConditionAuxClass 🌷
okay so the whole point of a policy condition is to decide whether the set of actions (contained in the pcimRule the condition applies to) should get executed or not 🤔. This class sets up 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 is attached to an instance of pcimRuleConditionAssociation, or to an instance of pcimRule, it's a rule-specific policy condition 🎯. When a subclass is attached to an instance of pcimPolicyInstance, it's a reusable policy condition ♻️.
Here's the tea 🫖. Every class these subclasses can attach to is derived from the pcimPolicy class, so the attributes of pcimPolicy are already defined for the entries they attach to 🧁. That's why this class is derived directly from "top" 🙌.
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
)5.8. The Auxiliary Class pcimTPCAuxClass ⏰
Okay bestie, so the PCIM has this time period class called PolicyTimePeriodCondition 🕰️, which is basically how you say "these are the exact times this rule is live." 💅 It also has an aggregation called PolicyRuleValidityPeriod 🔗 that hooks those time periods up to a PolicyRule. The LDAP mapping gives us two classes too: one for the time condition itself and one for the aggregation ✨.
Now the name drama: in the PCIM it's PolicyTimePeriodCondition, but the auxiliary class name in this mapping (pcimTimePeriodConditionAuxClass) is too long for some directories to store 😭. So it got shortened to pcimTPCAuxClass 🫶.
The class definition is as follows:
( 1.3.6.1.1.6.1.12 NAME 'pcimTPCAuxClass'
DESC 'This provides the capability of enabling or disabling
a policy rule according to a predetermined schedule.'
SUP pcimConditionAuxClass
AUXILIARY
MAY ( pcimTPCTime $ pcimTPCMonthOfYearMask $
pcimTPCDayOfMonthMask $ pcimTPCDayOfWeekMask $
pcimTPCTimeOfDayMask $ pcimTPCLocalOrUtcTime )
)Here's the cast of attributes for pcimTPCAuxClass, one by one 🎀.
The pcimTPCTime attribute is the start and end of the window a policy rule is enabled for 🌸. In [1] it's a string with a special format: a starting date and an ending date separated by a forward slash ("/"), like this:
yyyymmddThhmmss/yyyymmddThhmmssHere's the fun bit 🙈: the first date and time can be swapped out for the string "THISANDPRIOR", or the second date and time can be swapped out for the string "THISANDFUTURE". The attribute is defined as follows:
( 1.3.6.1.1.6.2.25
NAME 'pcimTPCTime'
DESC 'The start and end times on which a policy rule is
valid.'
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
SINGLE-VALUE
)The value of this attribute SHOULD be checked against its defined format ("yyyymmddThhmmss/yyyymmddThhmmss", where the first and second date strings can be replaced with "THISANDPRIOR" and "THISANDFUTURE"). If the value doesn't match this syntax, then this SHOULD be considered an error and the policy rule SHOULD be treated as being disabled 💀.
The next four attributes (pcimTPCMonthOfYearMask, pcimTPCDayOfMonthMask, pcimTPCDayOfWeekMask, and pcimTPCTimeOfDayMask) are all defined as octet strings in [1]. But their meanings live in bit strings of fixed lengths 🧩, so the PCLS uses a syntax of Bit String for each one. Here's how they're defined.
The pcimTPCMonthOfYearMask attribute is a 12-bit mask for the months of the year when a policy rule is valid 🗓️. The format is a bit string of length 12, covering January through December. The definition is as follows:
( 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
)The value of this attribute SHOULD be checked against its defined format. If the value doesn't match this syntax, then this SHOULD be considered an error and the policy rule SHOULD be treated as being disabled.
The pcimTPCMonthOfDayMask attribute (yes, that's how the text spells it 👀) defines a mask for the days of the month when a policy rule is valid 📅. The format is a bit string of length 62. The first 31 positions are the days of the month in ascending order, from day 1 to day 31. The next 31 positions are the days of the month in descending order, starting from the last day and counting back to the day 31 days from the end. The definition is as follows:
( 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
)The value of this attribute SHOULD be checked against its defined format. If the value doesn't match this syntax, then this SHOULD be considered an error and the policy rule SHOULD be treated as being disabled.
The pcimTPCDayOfWeekMask attribute is a mask for the days of the week when a policy rule is valid 📆. The format is a bit string of length 7, covering Sunday through Saturday. The definition is as follows:
( 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
)The value of this attribute SHOULD be checked against its defined format. If the value doesn't match this syntax, then this SHOULD be considered an error and the policy rule SHOULD be treated as being disabled.
The pcimTPCTimeOfDayMask attribute defines the range of times of day when a policy rule is valid ⏱️. If the second time is earlier than the first, then the interval spans midnight 🌙, which is giving overnight shift energy. The format of the string is Thhmmss/Thhmmss. The definition is as follows:
( 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
)The value of this attribute SHOULD be checked against its defined format. If the value doesn't match this syntax, then this SHOULD be considered an error and the policy rule SHOULD be treated as being disabled.
Last but not least, the pcimTPCLocalOrUtcTime attribute picks between local time and UTC time 🌍. It's mapped as a simple integer syntax: the value 1 means local time, and the value 2 means UTC time. The definition is as follows:
( 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
)Note: if the value of pcimTPCLocalOrUtcTime isn't 1 or 2, then this SHOULD be considered an error and the policy rule SHOULD be disabled. If the attribute isn't present at all, then all times are read as if it were there with the value 2, which means UTC time ⏰✨.
5.9. The Auxiliary Class pcimConditionVendorAuxClass 🧃
This class is a general extension mechanism for policy conditions that haven't been modeled with specific properties 🔧. Instead of dedicated attributes, its two properties define the content and format of the condition, as explained below. It's meant for vendor-specific extensions that don't fit pcimCondition, so standardized extensions SHOULD NOT use this class 🙅♀️.
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 )
)The pcimVendorConstraintData attribute is multi-valued 🫧. It's the catch-all for representing policy conditions that haven't been modeled as specific attributes. The information is encoded in a set of octet strings, and the format of those octet strings is identified by the OID stored in the pcimVendorConstraintEncoding attribute. The attribute is defined as follows:
( 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
)The pcimVendorConstraintEncoding attribute tells you the format and semantics for the pcimVendorConstraintData 🔍. It's defined as follows:
( 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
)5.10. The Auxiliary Class pcimActionAuxClass 🎬
The whole point of a policy action is to run one or more operations that affect network traffic and/or systems, devices, and so on 🚀, all so the network reaches a desired policy state. This class represents an action to be performed as a result of a policy rule whose condition clause was satisfied 💖.
Subclasses of this auxiliary class can be attached to instances of three other classes in the PCLS 🧩. When a subclass is attached to an instance of pcimRuleActionAssociation, or to an instance of pcimRule, it represents a rule-specific policy action 🎯. When a subclass is attached to an instance of pcimPolicyInstance, it represents a reusable policy action ♻️.
Every class these subclasses can attach to is derived from the pcimPolicy class, so the attributes of pcimPolicy are already defined for the entries they attach to 🙌. That means this class can derive directly from "top" ✨.
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
)5.11. The Auxiliary Class pcimActionVendorAuxClass
okay this class is the ultimate "make it your own" 🎀 its whole job is to be a general extension mechanism for policy actions that haven't been modeled with specific properties yet. instead of a bunch of named properties, it uses its two properties to define the content and format of the action, and we'll get into how that works in a sec ✨
heads up though, this one is for vendor-specific stuff that doesn't fit the standard pcimAction class 💅 standardized extensions SHOULD NOT use it, so don't be that person 🙅♀️
here's the class definition:
( 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 )
)the pcimVendorActionData attribute is multi-valued 🫶 it's the catch-all for representing policy actions that haven't been turned into specific attributes. the info gets encoded as a set of octet strings, and the format of those octet strings is identified by the OID stored in pcimVendorActionEncoding. here's how it's defined:
( 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
)and then pcimVendorActionEncoding is the one that tells you the format and semantics for pcimVendorActionData 🔥 it's defined like this:
( 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
)5.12. The Class pcimPolicyInstance
this class isn't defined in the PCIM, so it's kind of its own little thing 🌸 its role is to be a structural class that auxiliary classes holding reusable policy information get attached to. for conditions and actions there are alternative structural classes you can use instead. if you want the full tea on reusable conditions and actions, and how this class fits in, check out Section 4.4 🧚
here's the class definition:
( 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 )
)the pcimPolicyInstanceName attribute is a user-friendly name for this class, and it may be used as a naming attribute if you want 🍓 it's defined as:
( 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
)a DIT content rule could be written so that a pcimPolicyInstance entry can have attached to it instances of one or more of the auxiliary object classes pcimConditionAuxClass and pcimActionAuxClass 💖 since these semantics don't include specifying any properties, the content rule wouldn't need to specify any attributes. and other content rules could be defined to let other policy-related auxiliary classes attach to pcimPolicyInstance too.
then there's the DIT structure rules, and there are three separate ones that could be written 🦋 each one refers to a specific name form, and those name forms do two big things. first, each one picks one of the three possible naming attributes for this class (pcimPolicyInstanceName, cn, and orderedCIMKeys). second, each one requires that an instance of pcimPolicyInstance has an instance of the pcimRepository class as its superior. this structure rule SHOULD also include a superiorStructureRule (see Note 2 at the beginning of section 5) ✨
5.13. The Auxiliary Class pcimElementAuxClass
this class adds no extra attributes beyond what it inherits from the class pcimPolicy 💜 its whole vibe is "tagging." it lets you take an instance of a class that lives outside the PCIM policy world and say "hey, you're still relevant to a policy spec" 👑 this tagging can happen at two levels:
- every instance with pcimElementAuxClass attached becomes an instance of the class pcimPolicy, since pcimElementAuxClass is a subclass of pcimPolicy. searching for
object class="pcimPolicy"will return it. (as noted earlier, this approach does NOT work for some directory implementations. to accommodate those, policy-related entries SHOULD be tagged with the pcimKeyword"POLICY"🙈) - with the
pcimKeywordsattribute it inherits from pcimPolicy, an instance can be tagged as relevant to a particular type or category of policy information. you can use standard keywords, administrator-defined keywords, or both 🌈
here's the class definition:
( 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.'
SUP pcimPolicy
AUXILIARY
)5.14. The Three Policy Repository Classes
okay these classes are basically a container for reusable policy info, like reusable conditions and/or actions 📦 this document only cares about mapping the properties that show up in these classes. think of it as a special spot in the DIT where policy stuff can hang out 🧸
pcimRepository is derived from the class dlm1AdminDomain defined in reference [6], which means this spec has a normative dependency on that bit of reference [6] (plus its whole derivation hierarchy, which also lives in reference [6]) 🔗 to keep things flexible, pcimRepository is defined as abstract. then you get two subclasses to play with: pcimRepositoryAuxClass, which attaches to another entry as an auxiliary class, and pcimRepositoryInstance, a structural class that lets a policy repository stand on its own as a standalone entry 🌸
the definition for pcimRepository is:
( 1.3.6.1.1.6.1.18 NAME 'pcimRepository'
DESC 'A container for reusable policy information.'
SUP dlm1AdminDomain
ABSTRACT
MAY ( pcimRepositoryName )
)the pcimRepositoryName attribute is a user-friendly name for this class, and it may be used as a naming attribute if you want 🍓 it's defined as:
( 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
)the two subclasses of pcimRepository are defined as follows. first up, pcimRepositoryAuxClass is an auxiliary class that can be used to aggregate reusable policy information 🎀
( 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
)and when you need a structural class instead of an auxiliary one, pcimRepositoryInstance steps in 💅 it's defined as:
( 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
)three separate DIT structure rules could be written for this class 🧚 each one refers to a specific name form that lets an instance of pcimRepository be named under any superior, using one of the three possible naming attributes (pcimRepositoryName, cn, and orderedCIMKeys). this structure rule SHOULD also include a superiorStructureRule (see Note 2 at the beginning of section 5) 🫶
5.15. The Auxiliary Class pcimSubtreesPtrAuxClass 🧚
okay so this auxiliary class gives you a single multi-valued attribute that points at a bunch of objects sitting at the roots of DIT subtrees full of policy info 📂 when you stick this attribute on different kinds of entries, the policy admin gets a flexible front door into the directory, so a client can find and grab the policy stuff that's relevant to it ✨
the vibe is that these entries get placed in the DIT so that well-known DNs can point at a well-known structural entry with pcimSubtreesPtrAuxClass attached. basically that makes a set of entry points 🚪 each entry point can hold and/or reference all the related policy entries for any well-known policy domains. pcimSubtreesPtrAuxClass works like a tag that marks which parts of the DIT actually contain policy info 🏷️
this object doesn't create the semantic links between individual policy objects, like the ones between a policy group and the rules that belong to it. its only job is to make bulk retrieval of policy objects efficient, as described in Section 4.5 🏎️
once the objects are retrieved, a directory client can work out the semantic links by following references in multi-valued attributes, like pcimRulesAuxContainedSet 🔗
here's the tea: policy-related objects often end up in the DIT subtree under whatever object this auxiliary class is attached to. so a client SHOULD request the policy-related objects from that subtree at the same time it requests the references themselves 🫶
since clients are expected to act that way, the policy administrator SHOULD make sure the subtree doesn't have so many non-policy objects that an initial search like this turns into a performance problem 😬 pcimSubtreesPtrAuxClass SHOULD NOT be attached to the partition root of a large directory partition that has relatively few policy-related objects sitting alongside a huge pile of unrelated ones 🙅♀️ (quick reminder that "policy" here means the PCIM definition, not the X.501 one 🤓) a better move is to add a container object right below the partition root, attach pcimSubtreesPtrAuxClass to that container, and then put all the policy-related objects inside that subtree 📦✨
the class definition goes like this:
( 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 )
)the attribute pcimSubtreesAuxContainedSet is an unordered set of DN references to one or more objects under which policy-related info lives 🗂️ those referenced objects may or may not contain policy info themselves, so no pressure 😌 the attribute definition is:
( 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
)heads up: the cn attribute does NOT need to be defined for this class 🙌 that's because an auxiliary class is just a way to collect common attributes and treat them as properties of an object. the analogy they use is a #include file, except an auxiliary class is still a class, so you get all the class perks (like inheritance) on it too 💅
5.16. The Auxiliary Class pcimGroupContainmentAuxClass 🌸
this auxiliary class gives you one multi-valued attribute that references a set of pcimGroups 🎀 stick it on different kinds of entries and the policy admin has a flexible entry point into the directory, so a client can locate and fetch the pcimGroups that matter to it 🔍
same energy as pcimRules: a policy admin might have a bunch of different references to one pcimGroup scattered around the overall directory structure. pcimGroupContainmentAuxClass is the mechanism that lets the admin define all of those different references 🧩
the class definition:
( 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 )
)the attribute pcimGroupsAuxContainedSet is an unordered set of references to one or more pcimGroup instances associated with the instance of a structural class this attribute has been appended to 🫧 the attribute definition:
( 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
)and yep, the cn attribute does NOT have to be defined for this class either, for the same reasons given for pcimSubtreesPtrAuxClass in section 5.15 🔁
5.17. The Auxiliary Class pcimRuleContainmentAuxClass 🦋
this auxiliary class gives you one multi-valued attribute that references a set of pcimRules 💜 attach it to instances of other classes and the policy admin gets a flexible entry point, so a client can locate and retrieve the pcimRules relevant to it 🎯
a policy admin might have lots of different references to one pcimRule in the overall directory. for example, there could be references to all the pcimRules for traffic coming from a particular subnet, sitting on the directory entry that represents that subnet 🌐 and there could also be references to all the pcimRules related to one particular DiffServ setting, hanging off a pcimGroup that's explicitly set up as a container for DiffServ-related pcimRules 📮 pcimRuleContainmentAuxClass is the mechanism that lets the admin define all these separate references, no cap 🫶
the class definition:
( 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 )
)the attribute pcimRulesAuxContainedSet is an unordered set of references to one or more pcimRule instances associated with the instance of a structural class this attribute has been appended to 📋 the attribute definition:
( 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
)and once again, the cn attribute does NOT have to be defined for this class, for the same reasons as those given for pcimSubtreesPtrAuxClass in section 5.15 🙈
6. Extending the Classes Defined in This Document 🌈
okay bestie, this part is all about the guidance for making a domain-specific schema based on this document ✨ it also covers how the vendor classes in the PCLS should be used, and how policyTimePeriodConditions connect to the other policy conditions 🧠
6.1. Subclassing pcimConditionAuxClass and pcimActionAuxClass 🧁
back in Section 4.4 we talked about how representing policy conditions and policy actions as auxiliary classes in a schema keeps the flexibility to instantiate a condition or action as either rule-specific or reusable 🔄 that flexibility goes out the window if a condition or action class gets defined as structural instead of auxiliary 💀 for standardized schemata, this document says domain-specific info MUST be expressed in auxiliary subclasses of pcimConditionAuxClass and pcimActionAuxClass 📜 non-standardized schemata are RECOMMENDED to follow this practice too 💖
6.2. Using the Vendor Policy Attributes 🛠️
as discussed in Section 5.9, the attributes pcimVendorConstraintData and pcimVendorConstraintEncoding are included in the pcimConditionVendorAuxClass 📦 they give you a way to represent vendor-specific policy conditions that can't really be represented with the pcimCondition class (or its subclasses) 🙃 the attributes pcimVendorActionData and pcimVendorActionEncoding in the pcimActionVendorAuxClass class play the same role for actions 🎬 this is what lets different vendors interoperate when they otherwise couldn't 🤝
picture this: a network made of access devices from vendor A, edge and core devices from vendor B, and a policy server from vendor C 🖥️ it's really desirable for that policy server to be able to configure and manage all the devices from vendors A and B 🥹 the problem is these devices usually have almost nothing in common (different mechanisms, different ways of controlling those mechanisms, different operating systems, different commands, and so forth) 😩 the extension conditions give vendor-specific commands a way to get encoded as octet strings, so one policy server can manage devices from different vendors without a meltdown 🧚✨
6.3. Using Time Validity Periods ⏰
time validity periods are defined as an auxiliary subclass of pcimConditionAuxClass, called pcimTPCAuxClass 🕰️ that's so they can be included in the AND/OR condition definitions for a pcimRule 🔀 care should be taken not to subclass pcimTPCAuxClass to add domain-specific condition properties 🚫
for example, it would be incorrect to add IPsec- or QoS-specific condition properties to pcimTPCAuxClass, just because IPsec or QoS includes time in its condition definition 🙅♀️ the correct move is to create IPsec- or QoS-specific subclasses of pcimConditionAuxClass, and then combine instances of those domain-specific condition classes with the appropriate validity period criteria 🫶 that gets done with the AND/OR association capabilities for policy conditions in pcimRules 💜
7. Security Considerations 🔐✨
okay bestie, this is the serious part 😭 but it's still giving main character energy. PCLS is the mapping of the object-oriented policy model (PCIM) into a data model that's the basic framework for describing policy data, specifically when the policy repository is an LDAP-accessible directory 💖
PCLS isn't meant to be any particular system design or implementation 🙅♀️. It's also not directly useable in a real-world system on its own. It needs the discipline-specific mappings that the Policy Framework Working Group of the IETF is still cooking 🍳.
Those other derivative documents, which build on PCIM and its discipline-specific extensions, will need to spell out more specific security considerations. (Go check RFC 3060 for more info 📚.)
PCLS doesn't represent a real-world system because its object classes were designed to be independent of any specific discipline or policy domain 🌸. DiffServ and IPsec are two totally different policy domains, for example. Each document that extends PCIM into one of these domains derives subclasses from the classes and relationships defined in PCIM, so a generic model can cover specific technical areas.
PCIM-derived documents will subclass the PCIM classes into classes specific to each technical policy domain (QoS, IPsec, etc.) 🎀. Those classes will then get mapped to directory-specific schemata that match the PCLS documented here.
Even though discipline-specific security requirements don't belong in PCLS, specific security requirements MUST be defined for each operational real-world application of PCIM 🚨. Just like there's a huge range of real-world systems using PCIM, there's a huge range of security requirements for them too. Some deployed systems using PCLS might have extensive security requirements that touch nearly every object class they use, while others might barely be affected at all 🦋.
The derivative documents mentioned above will set up the context for applying operational, real-world, system-level security requirements to the various models that come from PCIM, while staying consistent with PCLS ✨.
In some real-world scenarios, the values tied to certain properties inside certain instantiated object classes can represent information about scarce and/or costly (so valuable) resources 💎. Those values might need to be kept away from unauthorized parties, both for reading and for changing 😤.
Since this document is the basis for representing a policy data model in a specific format (an LDAP-accessible directory), it makes sense to point at the data model-specific tools and mechanisms available for the authentication and authorization that's implied by any requirement restricting read and/or read-write access to those stored values 🔑.
General LDAP security considerations apply, as documented in RFC 3377 [2]. The LDAP-specific authentication and authorization tools and mechanisms live in the following standards track documents, which are a good fit for managing security on policy data models stored in an LDAP-accessible directory 🫶:
- RFC 2829 (Authentication Methods for LDAP)
- RFC 2830 (Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security)
Any identified security requirements that aren't handled in the appropriate discipline-specific information model documents, or in this document, MUST be dealt with in the derivative data model documents that are specific to each discipline 💅.
8. IANA Considerations 🧚
Refer to RFC 3383, "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)" [16] 📖.
8.1. Object Identifiers 🆔
IANA has registered an LDAP Object Identifier for this technical specification, using the following template:
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.IANA assigned the OID 1.3.6.1.1.6 with the name pcimSchema to this registration, recorded in the following registry: http://www.iana.org/assignments/smi-numbers 🌈.
8.2. Object Identifier Descriptors 🍓
IANA has registered the LDAP Descriptors used in this technical specification, using the following template:
Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comment
Object Identifier: see comment
Person & email address to contact for further information:
Bob Moore (remoore@us.ibm.com)
Usage: see comment
Specification: RFC 3703
Author/Change Controller: IESG
Comments:The following descriptors have been added 👑:
NAME Type OID
-------------- ---- ------------
pcimPolicy O 1.3.6.1.1.6.1.1
pcimGroup O 1.3.6.1.1.6.1.2
pcimGroupAuxClass O 1.3.6.1.1.6.1.3
pcimGroupInstance O 1.3.6.1.1.6.1.4
pcimRule O 1.3.6.1.1.6.1.5
pcimRuleAuxClass O 1.3.6.1.1.6.1.6
pcimRuleInstance O 1.3.6.1.1.6.1.7
pcimRuleConditionAssociation O 1.3.6.1.1.6.1.8
pcimRuleValidityAssociation O 1.3.6.1.1.6.1.9
pcimRuleActionAssociation O 1.3.6.1.1.6.1.10
pcimConditionAuxClass O 1.3.6.1.1.6.1.11
pcimTPCAuxClass O 1.3.6.1.1.6.1.12
pcimConditionVendorAuxClass O 1.3.6.1.1.6.1.13
pcimActionAuxClass O 1.3.6.1.1.6.1.14
pcimActionVendorAuxClass O 1.3.6.1.1.6.1.15
pcimPolicyInstance O 1.3.6.1.1.6.1.16
pcimElementAuxClass O 1.3.6.1.1.6.1.17
pcimRepository O 1.3.6.1.1.6.1.18
pcimRepositoryAuxClass O 1.3.6.1.1.6.1.19
pcimRepositoryInstance O 1.3.6.1.1.6.1.20
pcimSubtreesPtrAuxClass O 1.3.6.1.1.6.1.21
pcimGroupContainmentAuxClass O 1.3.6.1.1.6.1.22
pcimRuleContainmentAuxClass O 1.3.6.1.1.6.1.23
pcimKeywords A 1.3.6.1.1.6.2.3
pcimGroupName A 1.3.6.1.1.6.2.4
pcimRuleName A 1.3.6.1.1.6.2.5
pcimRuleEnabled A 1.3.6.1.1.6.2.6
pcimRuleConditionListType A 1.3.6.1.1.6.2.7
pcimRuleConditionList A 1.3.6.1.1.6.2.8
pcimRuleActionList A 1.3.6.1.1.6.2.9
pcimRuleValidityPeriodList A 1.3.6.1.1.6.2.10
pcimRuleUsage A 1.3.6.1.1.6.2.11
pcimRulePriority A 1.3.6.1.1.6.2.12
pcimRuleMandatory A 1.3.6.1.1.6.2.13
pcimRuleSequencedActions A 1.3.6.1.1.6.2.14
pcimRoles A 1.3.6.1.1.6.2.15
pcimConditionGroupNumber A 1.3.6.1.1.6.2.16
NAME Type OID
-------------- ---- ------------
pcimConditionNegated A 1.3.6.1.1.6.2.17
pcimConditionName A 1.3.6.1.1.6.2.18
pcimConditionDN A 1.3.6.1.1.6.2.19
pcimValidityConditionName A 1.3.6.1.1.6.2.20
pcimTimePeriodConditionDN A 1.3.6.1.1.6.2.21
pcimActionName A 1.3.6.1.1.6.2.22
pcimActionOrder A 1.3.6.1.1.6.2.23
pcimActionDN A 1.3.6.1.1.6.2.24
pcimTPCTime A 1.3.6.1.1.6.2.25
pcimTPCMonthOfYearMask A 1.3.6.1.1.6.2.26
pcimTPCDayOfMonthMask A 1.3.6.1.1.6.2.27
pcimTPCDayOfWeekMask A 1.3.6.1.1.6.2.28
pcimTPCTimeOfDayMask A 1.3.6.1.1.6.2.29
pcimTPCLocalOrUtcTime A 1.3.6.1.1.6.2.30
pcimVendorConstraintData A 1.3.6.1.1.6.2.31
pcimVendorConstraintEncoding A 1.3.6.1.1.6.2.32
pcimVendorActionData A 1.3.6.1.1.6.2.33
pcimVendorActionEncoding A 1.3.6.1.1.6.2.34
pcimPolicyInstanceName A 1.3.6.1.1.6.2.35
pcimRepositoryName A 1.3.6.1.1.6.2.36
pcimSubtreesAuxContainedSet A 1.3.6.1.1.6.2.37
pcimGroupsAuxContainedSet A 1.3.6.1.1.6.2.38
pcimRulesAuxContainedSet A 1.3.6.1.1.6.2.39where Type A is Attribute, Type O is ObjectClass 🧾
These assignments are recorded in the following registry: http://www.iana.org/assignments/ldap-parameters 📝.
9. Acknowledgments 💜
We would like to thank Kurt Zeilenga, Roland Hedburg, and Steven Legg for reviewing this document and giving many helpful suggestions and corrections 🙌.
Several of the policy classes in this model first showed up in early IETF drafts on IPsec policy and QoS policy. The authors of those 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 🌟.
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 🥹✨.
10. Appendix: Constructing the Value of orderedCIMKeys ✨
Okay bestie, this appendix is non-normative 🫶, which just means it's a helpful guide for implementers who wanna swap info between CIM schemata and LDAP schemata. It's a tip sheet, not a rulebook 💅.
Okay so, inside a CIM name space the naming is basically flat 🌸. Every instance is identified by the values of its key properties, and every combo of key values has to be unique. BUT there's a lil bit of hierarchy through weak associations ✨. A weak association propagates key properties and their values from the superior object to the subordinate one, so the subordinate object is kinda named "under" the superior one 🧚. Once they've been propagated, though, those propagated keys work exactly the same way native keys do in identifying a CIM instance 👑.
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 you need to map between an LDAP-accessible directory and a CIM repository. For an LDAP environment, there are other LDAP naming attributes (cn and a class-specific naming attribute) that SHOULD be used instead 💖.
The job of orderedCIMKeys is to carry the info needed to match up 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 the LDAP directory, its value is one of two things:
- If the DIT hierarchy does not mirror the "weakness hierarchy" of the CIM name space,
orderedCIMKeysrepresents 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,
orderedCIMKeysmay represent either all the keys of the instance, or only the native keys.
No matter which route you take, the syntax of orderedCIMKeys is the same 🎀. It's a DirectoryString of this form:
<className>.<key>=<value>[,<key>=<value>]*The <key>=<value> elements are ordered by the names of the key properties, using the collating sequence for US ASCII. The only spaces allowed in the DirectoryString are the ones that fall inside a <value> element. Same vibe as alphabetizing the key properties: suppressing the spaces keeps string operations predictable 🌈.
The values of the <value> elements are derived from the various CIM syntaxes, following a grammar specified in [5] 🔥.
11. References
11.1. Normative References
- [1] Moore, B., Ellesson,E., Strassner, J. and A. Westerinen "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001.
- [2] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
- [3] Wahl, M., Coulbeck, A., Howes,T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
- [4] The Directory: Models. ITU-T Recommendation 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 - [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 - [7] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997.
- [8] The Directory: Selected Attribute Types. ITU-T Recommendation X.520, 2001.
- [9] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Additional Matching Rules", RFC 3698, February 2004.
- [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
- [11] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.
- [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. - [13] Yavatkar, R., Guerin, R. and D. Pendarakis, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
- [14] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000
- [15] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000.
- [16] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
12. Authors' Addresses 💌
John Strassner
Intelliden Corporation
90 South Cascade Avenue
Colorado Springs, CO 80903
Phone: +1.719.785.0648
Fax: +1.719.785.0644
EMail: john.strassner@intelliden.com
Bob Moore
IBM Corporation
P. O. Box 12195, BRQA/B501/G206
3039 Cornwallis Rd.
Research Triangle Park, NC 27709-2195
Phone: +1 919-254-4436
Fax: +1 919-254-6243
EMail: remoore@us.ibm.com
Ryan Moats
Lemur Networks, Inc.
15621 Drexel Circle
Omaha, NE 68135
Phone: +1-402-894-9456
EMail: rmoats@lemurnetworks.net
Ed Ellesson
3026 Carriage Trail
Hillsborough, NC 27278
Phone: +1 919-644-3977
EMail: ellesson@mindspring.com13. Full Copyright Statement 🌸
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.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
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.
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society. 💖
📦 where this page comes from
- ietf: rfc3703 2004-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms