tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3703

 
 
 

Policy Core Lightweight Directory Access Protocol (LDAP) Schema

Part 2 of 3, p. 19 to 50
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 19 
5.  Class Definitions

   The semantics for the policy information classes that are to be
   mapped directly from the information model to an LDAP representation
   are detailed in [1].  Consequently, all that this document presents
   for these classes is the specification for how to do the mapping from
   the information model (which is independent of repository type and
   access protocol) to a form that can be accessed using LDAP.  Remember
   that some new classes needed to be created (that were not part of
   [1]) to implement the LDAP mapping.  These new LDAP-only classes are
   fully documented in this document.

   The formal language for specifying the classes, attributes, and DIT
   structure and content rules is that defined in reference [3].  If
   your implementation does not support auxiliary class inheritance, you
   will have to list auxiliary classes in content rules explicitly or
   define them in another (implementation-specific) way.

   The following notes apply to this section in its entirety.

   Note 1: in the following definitions, the class and attribute
   definitions follow RFC 2252 [3] but they are line-wrapped to enhance
   human readability.

   Note 2: where applicable, the possibilities for specifying DIT
   structure and content rules are noted.  However, care must be taken
   in specifying DIT structure rules.  This is because X.501 [4] states

Top      Up      ToC       Page 20 
   that an entry may only exist in the DIT as a subordinate to another
   superior entry (the superior) if a DIT structure rule exists in the
   governing subschema which:

   1)  indicates a name form for the structural object class of the
       subordinate entry, and
   2)  either includes the entry's superior structure rule as a possible
       superior structure rule, or
   3)  does not specify a superior structure rule.

   If this last case (3) applies, then the entry is defined to be a
   subschema administrative point.  This is not what is desired.
   Therefore, care must be taken in defining structure rules, and in
   particular, they must be locally augmented.

   Note 3: Wherever possible, both an equality and a substring matching
   rule are defined for a particular attribute (as well as an ordering
   match rule to enable sorting of matching results).  This provides two
   different choices for the developer for maximum flexibility.

   For example, consider the pcimRoles attribute (section 5.3).  Suppose
   that a PEP has reported that it is interested in pcimRules for three
   roles R1, R2, and R3.  If the goal is to minimize queries, then the
   PDP can supply three substring filters containing the three role
   names.

   These queries will return all of the pcimRules that apply to the PEP,
   but they may also get some that do not apply (e.g., ones that contain
   one of the roles R1, R2, or R3 and one or more other roles present in
   a role-combination [1]).

   Another strategy would be for the PDP to use only equality filters.
   This approach eliminates the extraneous replies, but it requires the
   PDP to explicitly build the desired role-combinations itself.  It
   also requires extra queries.  Note that this approach is practical
   only because the role names in a role combination are required to
   appear in alphabetical order.

   Note 4: in the following definitions, note that all LDAP matching
   rules are defined in [3] and in [9].  The corresponding X.500
   matching rules are defined in [8].

   Note 5: some of the following attribute definitions specify
   additional constraints on various data types (e.g., this integer has
   values that are valid  from 1..10).  Text has been added to instruct
   servers and applications what to do if a value outside of this range

Top      Up      ToC       Page 21 
   is encountered.  In all cases, if a constraint is violated, then the
   policy rule SHOULD be treated as being disabled, meaning that
   execution of the policy rule SHOULD be stopped.

5.1.  The Abstract Class pcimPolicy

   The abstract class pcimPolicy is a direct mapping of the abstract
   class Policy from the PCIM.  The class value "pcimPolicy" is also
   used as the mechanism for identifying policy-related instances in the
   Directory Information Tree.  An instance of any class may be "tagged"
   with this class value by attaching to it the auxiliary class
   pcimElementAuxClass.  Since pcimPolicy is derived from the class
   dlm1ManagedElement defined in reference [6], this specification has a
   normative dependency on that element of reference [6].

   The class definition is as follows:

       ( 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 that contains
   a set of keywords to assist directory clients in locating the policy
   objects identified by these keywords.  It is defined as follows:

       ( 1.3.6.1.1.6.2.3 NAME 'pcimKeywords'
              DESC 'A set of keywords to assist directory clients in
                    locating the policy objects applicable to them.'
              EQUALITY caseIgnoreMatch
              ORDERING caseIgnoreOrderingMatch
              SUBSTR caseIgnoreSubstringsMatch
              SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
       )

Top      Up      ToC       Page 22 
5.2.  The Three Policy Group Classes

   PCIM [1] defines the PolicyGroup class to serve as a generalized
   aggregation mechanism, enabling PolicyRules and/or PolicyGroups to be
   aggregated together.  PCLS maps this class into three LDAP classes,
   called pcimGroup, pcimGroupAuxClass, and pcimGroupInstance.  This is
   done in order to provide maximum flexibility for the DIT designer.

   The class definitions for the three policy group classes are listed
   below.  These class definitions do not include attributes to realize
   the PolicyRuleInPolicyGroup and PolicyGroupInPolicyGroup associations
   from the PCIM.  This is because a pcimGroup object refers to
   instances of pcimGroup and pcimRule via, respectively, the attribute
   pcimGroupsAuxContainedSet in the pcimGroupContainmentAuxClass object
   class and the attribute pcimRulesAuxContainedSet in the
   pcimRuleContainmentAuxClass object class.

   To maximize flexibility, the pcimGroup class is defined as abstract.
   The subclass pcimGroupAuxClass provides for auxiliary attachment to
   another entry, while the structural subclass pcimGroupInstance is
   available to represent a policy group as a standalone entry.

   The class definitions are as follows.  First, the definition of the
   abstract class pcimGroup:

       ( 1.3.6.1.1.6.1.2 NAME 'pcimGroup'
              DESC 'A container for a set of related pcimRules and/or
                    a set of related pcimGroups.'
              SUP pcimPolicy
              ABSTRACT
              MAY ( pcimGroupName )
       )

   The one attribute of pcimGroup is pcimGroupName.  This attribute is
   used to define a user-friendly name of this policy group, and may be
   used as a naming attribute if desired.  It is defined as follows:

       ( 1.3.6.1.1.6.2.4 NAME 'pcimGroupName'
              DESC 'The user-friendly name of this policy group.'
              EQUALITY caseIgnoreMatch
              ORDERING caseIgnoreOrderingMatch
              SUBSTR caseIgnoreSubstringsMatch
              SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
              SINGLE-VALUE
       )

Top      Up      ToC       Page 23 
   The two subclasses of pcimGroup are defined as follows.  The class
   pcimGroupAuxClass is an auxiliary class that can be used to collect a
   set of related pcimRule and/or pcimGroup classes.  It is defined as
   follows:

       ( 1.3.6.1.1.6.1.3 NAME 'pcimGroupAuxClass'
              DESC 'An auxiliary class that collects a set of related
                    pcimRule and/or pcimGroup entries.'
              SUP pcimGroup
              AUXILIARY
       )

   The class pcimGroupInstance is a structural class that can be used to
   collect a set of related pcimRule and/or pcimGroup classes.  It is
   defined as follows:

       ( 1.3.6.1.1.6.1.4 NAME 'pcimGroupInstance'
              DESC 'A structural class that collects a set of related
                    pcimRule and/or pcimGroup entries.'
              SUP pcimGroup
              STRUCTURAL
       )

   A DIT content rule could be written to enable an instance of
   pcimGroupInstance to have attached to it either references to one or
   more policy groups (using pcimGroupContainmentAuxClass) or references
   to one or more policy rules (using pcimRuleContainmentAuxClass).
   This would be used to formalize the semantics of the PolicyGroup
   class [1].  Since these semantics do not include specifying any
   properties of the PolicyGroup class, the content rule would not need
   to specify any attributes.

   Similarly, three separate DIT structure rules could be written, each
   of which would refer to a specific name form that identified one of
   the three possible naming attributes (i.e., pcimGroupName, cn, and
   orderedCIMKeys) for the pcimGroup object class.  This structure rule
   SHOULD include a superiorStructureRule (see Note 2 at the beginning
   of section 5).  The three name forms referenced by the three
   structure rules would each define one of the three naming attributes.

5.3.  The Three Policy Rule Classes

   The information model defines a PolicyRule class to represent the "If
   Condition then Action" semantics associated with processing policy
   information.  For maximum flexibility, the PCLS maps this class into
   three LDAP classes.

Top      Up      ToC       Page 24 
   To maximize flexibility, the pcimRule class is defined as abstract.
   The subclass pcimRuleAuxClass provides for auxiliary attachment to
   another entry, while the structural subclass pcimRuleInstance is
   available to represent a policy rule as a standalone entry.

   The conditions and actions associated with a policy rule are modeled,
   respectively, with auxiliary subclasses of the auxiliary classes
   pcimConditionAuxClass and pcimActionAuxClass.  Each of these
   auxiliary subclasses is attached to an instance of one of three
   structural classes.  A subclass of pcimConditionAuxClass is attached
   to an instance of pcimRuleInstance, to an instance of
   pcimRuleConditionAssociation, or to an instance of
   pcimPolicyInstance.  Similarly, a subclass of pcimActionAuxClass is
   attached to an instance of pcimRuleInstance, to an instance of
   pcimRuleActionAssociation, or to an instance of pcimPolicyInstance.

   The pcimRuleValidityPeriodList attribute (defined below) realizes the
   PolicyRuleValidityPeriod association defined in the PCIM.  Since this
   association has no additional properties besides those that tie the
   association to its associated objects, this association can be
   realized by simply using an attribute.  Thus, the
   pcimRuleValidityPeriodList attribute is simply a multi-valued
   attribute that provides an unordered set of DN references to one or
   more instances of the pcimTPCAuxClass, indicating when the policy
   rule is scheduled to be active and when it is scheduled to be
   inactive.  A policy rule is scheduled to be active if it is active
   according to AT LEAST ONE of the pcimTPCAuxClass instances referenced
   by this attribute.

   The PolicyConditionInPolicyRule and PolicyActionInPolicyRule
   associations, however, do have additional attributes.  The
   association PolicyActionInPolicyRule defines an integer attribute to
   sequence the actions, and the association PolicyConditionInPolicyRule
   has both an integer attribute to group the condition terms as well as
   a Boolean property to specify whether a condition is to be negated.

   In the PCLS, these additional association attributes are represented
   as attributes of two classes introduced specifically to model these
   associations.  These classes are the pcimRuleConditionAssociation
   class and the pcimRuleActionAssociation class, which are defined in
   Sections 5.4 and 5.5, respectively.  Thus, they do not appear as
   attributes of the class pcimRule.  Instead, the pcimRuleConditionList
   and pcimRuleActionList attributes can be used to reference these
   classes.

Top      Up      ToC       Page 25 
   The class definitions for the three pcimRule classes are as follows.

   The abstract class pcimRule is a base class for representing the "If
   Condition then Action" semantics associated with a policy rule.  It
   is defined as follows:

     ( 1.3.6.1.1.6.1.5 NAME 'pcimRule'
            DESC 'The base class for representing the "If Condition
                  then Action" semantics associated with a policy rule.'
            SUP pcimPolicy
            ABSTRACT
            MAY ( pcimRuleName $ pcimRuleEnabled $
                  pcimRuleConditionListType $ pcimRuleConditionList $
                  pcimRuleActionList $ pcimRuleValidityPeriodList $
                  pcimRuleUsage $ pcimRulePriority $
                  pcimRuleMandatory $ pcimRuleSequencedActions $
                  pcimRoles )
     )

   The PCIM [1] defines seven properties for the PolicyRule class.  The
   PCLS defines eleven attributes for the pcimRule class, which is the
   LDAP equivalent of the PolicyRule class.  Of these eleven attributes,
   seven are mapped directly from corresponding properties in PCIM's
   PolicyRule class.  The remaining four attributes are a class-specific
   optional naming attribute, and three attributes used to realize the
   three associations that the pcimRule class participates in.

   The pcimRuleName attribute is used as a user-friendly name of this
   policy rule, and can also serve as the class-specific optional naming
   attribute.  It is defined as follows:

        ( 1.3.6.1.1.6.2.5 NAME 'pcimRuleName'
               DESC 'The user-friendly name of this policy rule.'
               EQUALITY caseIgnoreMatch
               ORDERING caseIgnoreOrderingMatch
               SUBSTR caseIgnoreSubstringsMatch
               SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
               SINGLE-VALUE
        )

   The pcimRuleEnabled attribute is an integer enumeration indicating
   whether a policy rule is administratively enabled (value=1),
   administratively disabled (value=2), or enabled for debug (value=3).
   It is defined as follows:

        ( 1.3.6.1.1.6.2.6 NAME 'pcimRuleEnabled'
               DESC 'An integer indicating whether a policy rule is
                     administratively enabled (value=1), disabled

Top      Up      ToC       Page 26 
                     (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 is used to indicate whether
   the list of policy conditions associated with this policy rule is in
   disjunctive normal form (DNF, value=1) or conjunctive normal form
   (CNF, value=2).  It is defined as follows:

     ( 1.3.6.1.1.6.2.7 NAME 'pcimRuleConditionListType'
            DESC 'A value of 1 means that this policy rule is in
                  disjunctive normal form; a value of 2 means that this
                  policy rule is in conjunctive normal form.'
            EQUALITY integerMatch
            ORDERING integerOrderingMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
            SINGLE-VALUE
     )

   Note: any value other than 1 or 2 for the pcimRuleConditionListType
   attribute is considered an error.  Administrators SHOULD treat this
   rule as being disabled if an invalid value is found, since it is
   unclear how to structure the condition list.

   The pcimRuleConditionList attribute is a multi-valued attribute that
   is used to realize the policyRuleInPolicyCondition association
   defined in [1].  It contains a set of DNs of
   pcimRuleConditionAssociation entries representing associations
   between this policy rule and its conditions.  No order is implied.
   It is defined as follows:

     ( 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
     )

Top      Up      ToC       Page 27 
   The pcimRuleActionList attribute is a multi-valued attribute that is
   used to realize the policyRuleInPolicyAction association defined in
   [1].  It contains a set of DNs of pcimRuleActionAssociation entries
   representing associations between this policy rule and its actions.
   No order is implied.  It is defined as follows:

     ( 1.3.6.1.1.6.2.9 NAME 'pcimRuleActionList'
            DESC 'Unordered set of DNs of pcimRuleActionAssociation
                  entries representing associations between this policy
                  rule and its actions.'
           EQUALITY distinguishedNameMatch
           SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
     )

   The pcimRuleValidityPeriodList attribute is a multi-valued attribute
   that is used to realize the pcimRuleValidityPeriod association that
   is defined in [1].  It contains a set of DNs of
   pcimRuleValidityAssociation entries that determine when the pcimRule
   is scheduled to be active or inactive.  No order is implied.  It is
   defined as follows:

     ( 1.3.6.1.1.6.2.10 NAME 'pcimRuleValidityPeriodList'
            DESC 'Unordered set of DNs of pcimRuleValidityAssociation
                  entries that determine when the pcimRule is scheduled
                  to be active or inactive.'
            EQUALITY distinguishedNameMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
     )

   The pcimRuleUsage attribute is a free-form string providing
   guidelines on how this policy should be used.  It is defined as
   follows:

     ( 1.3.6.1.1.6.2.11 NAME 'pcimRuleUsage'
            DESC 'This attribute is a free-form sting providing
                  guidelines on how this policy should be used.'
            EQUALITY caseIgnoreMatch
            ORDERING caseIgnoreOrderingMatch
            SUBSTR caseIgnoreSubstringsMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
            SINGLE-VALUE
     )

Top      Up      ToC       Page 28 
   The pcimRulePriority attribute is a non-negative integer that is used
   to prioritize this pcimRule relative to other pcimRules.  A larger
   value indicates a higher priority.  It is defined as follows:

     ( 1.3.6.1.1.6.2.12 NAME 'pcimRulePriority'
            DESC 'A non-negative integer for prioritizing this
                  pcimRule relative to other pcimRules.  A larger
                  value indicates a higher priority.'
            EQUALITY integerMatch
            ORDERING integerOrderingMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
            SINGLE-VALUE
     )

   Note: if the value of the pcimRulePriority field is 0, then it SHOULD
   be treated as "don't care".  On the other hand, if the value is
   negative, then it SHOULD be treated as an error and Administrators
   SHOULD treat this rule as being disabled.

   The pcimRuleMandatory attribute is a Boolean attribute that, if TRUE,
   indicates that for this policy rule, the evaluation of its conditions
   and execution of its actions (if the condition is satisfied) is
   required.  If it is FALSE, then the evaluation of its conditions and
   execution of its actions (if the condition is satisfied) is not
   required.  This attribute is defined as follows:

     ( 1.3.6.1.1.6.2.13 NAME 'pcimRuleMandatory'
            DESC 'If TRUE, indicates that for this policy rule, the
                  evaluation of its conditions and execution of its
                  actions (if the condition is satisfied) is required.'
            EQUALITY booleanMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
            SINGLE-VALUE
     )

   The pcimRuleSequencedActions attribute is an integer enumeration that
   is used to indicate that the ordering of actions defined by the
   pcimActionOrder attribute is either  mandatory(value=1),
   recommended(value=2), or dontCare(value=3).  It is defined as
   follows:

     ( 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

Top      Up      ToC       Page 29 
            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 of this attribute represents a role-combination, which is
   a string of the form:
       <RoleName>[&&<RoleName>]* where the individual role names appear
   in alphabetical order according to the collating sequence for UCS-2.
   This attribute is defined as follows:

     ( 1.3.6.1.1.6.2.15 NAME 'pcimRoles'
            DESC 'Each value of this attribute represents a role-
                  combination.'
            EQUALITY caseIgnoreMatch
            ORDERING caseIgnoreOrderingMatch
            SUBSTR caseIgnoreSubstringsMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
     )

   Note: if the value of the pcimRoles attribute does not conform to the
   format "<RoleName>[&&<RoleName>]*" (see Section 6.3.7 of [1]), then
   this attribute is malformed and its policy rule SHOULD be treated as
   being disabled.

   The two subclasses of the pcimRule class are defined as follows.
   First, the pcimRuleAuxClass is an auxiliary class for representing
   the "If Condition then Action" semantics associated with a policy
   rule.  Its class definition is as follows:

     ( 1.3.6.1.1.6.1.6 NAME 'pcimRuleAuxClass'
            DESC 'An auxiliary class for representing the "If Condition
                 then Action" semantics associated with a policy rule.'
            SUP pcimRule
            AUXILIARY
     )

   The pcimRuleInstance is a structural class for representing the "If
   Condition then Action" semantics associated with a policy rule.  Its
   class definition is as follows:

     ( 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.'

Top      Up      ToC       Page 30 
            SUP pcimRule
            STRUCTURAL
     )

   A DIT content rule could be written to enable an instance of
   pcimRuleInstance to have attached to it either references to one or
   more policy conditions (using pcimConditionAuxClass) or references to
   one or more policy actions (using pcimActionAuxClass).  This would be
   used to formalize the semantics of the PolicyRule class [1].  Since
   these semantics do not include specifying any properties of the
   PolicyRule class, the content rule would not need to specify any
   attributes.

   Similarly, three separate DIT structure rules could be written, each
   of which would refer to a specific name form that identified one of
   its three possible naming attributes (i.e., pcimRuleName, cn, and
   orderedCIMKeys).  This structure rule SHOULD include a
   superiorStructureRule (see Note 2 at the beginning of section 5).
   The three name forms referenced by the three structure rules would
   each define one of the three naming attributes.

5.4.  The Class pcimRuleConditionAssociation

   This class contains attributes to represent the properties of the
   PCIM's PolicyConditionInPolicyRule association.  Instances of this
   class are related to an instance of pcimRule via DIT containment.
   The policy conditions themselves are represented by auxiliary
   subclasses of the auxiliary class pcimConditionAuxClass.  These
   auxiliary classes are attached directly to instances of
   pcimRuleConditionAssociation for rule-specific policy conditions.
   For a reusable policy condition, the policyCondition auxiliary
   subclass is attached to an instance of the class pcimPolicyInstance
   (which is presumably associated with a pcimRepository by DIT
   containment), and the policyConditionDN attribute (of this class) is
   used to reference the reusable policyCondition instance.

   The class definition is as follows:

     ( 1.3.6.1.1.6.1.8 NAME 'pcimRuleConditionAssociation'
            DESC 'This class contains attributes characterizing the
                  relationship between a policy rule and one of its
                  policy conditions.'
            SUP pcimPolicy
            MUST ( pcimConditionGroupNumber $ pcimConditionNegated )
            MAY ( pcimConditionName $ pcimConditionDN )
     )

Top      Up      ToC       Page 31 
   The attributes of this class are defined as follows.

   The pcimConditionGroupNumber attribute is a non-negative integer.  It
   is used to identify the group to which the condition referenced by
   this association is assigned.  This attribute is defined as follows:

     ( 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 is non-negative.  A negative value for this
   attribute is invalid, and any policy rule that refers to an invalid
   entry SHOULD be treated as being disabled.

   The pcimConditionNegated attribute is a Boolean attribute that
   indicates whether this policy condition is to be negated or not.  If
   it is TRUE (FALSE), it indicates that a policy condition IS (IS NOT)
   negated in the DNF or CNF expression associated with a policy rule.
   This attribute is defined as follows:

     ( 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 identifying this
   policy condition, and may be used as a naming attribute if desired.
   This attribute is defined as follows:

     ( 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

Top      Up      ToC       Page 32 
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
            SINGLE-VALUE
     )

   The pcimConditionDN attribute is a DN that references an instance of
   a reusable policy condition.  This attribute is defined as follows:

     ( 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
     )

   A DIT content rule could be written to enable an instance of
   pcimRuleConditionAssociation to have attached to it an instance of
   the auxiliary class pcimConditionAuxClass, or one of its subclasses.
   This would be used to formalize the semantics of the
   PolicyConditionInPolicyRule association.  Specifically, this would be
   used to represent a rule-specific policy condition [1].
   Similarly, three separate DIT structure rules could be written.  Each
   of these DIT structure rules would refer to a specific name form that
   defined two important semantics.  First, each name form would
   identify one of the three possible naming attributes (i.e.,
   pcimConditionName, cn, and orderedCIMKeys) for the
   pcimRuleConditionAssociation object class.  Second, each name form
   would require that an instance of the pcimRuleConditionAssociation
   class have as its superior an instance of the pcimRule class.  This
   structure rule SHOULD also include a superiorStructureRule (see Note
   2 at the beginning of section 5).

5.5.  The Class pcimRuleValidityAssociation

   The policyRuleValidityPeriod aggregation is mapped to the PCLS
   pcimRuleValidityAssociation class.  This class represents the
   scheduled activation and deactivation of a policy rule by binding the
   definition of times that the policy is active to the policy rule
   itself.  The "scheduled" times are either identified through an
   attached auxiliary class pcimTPCAuxClass, or are referenced through
   its pcimTimePeriodConditionDN attribute.

   This class is defined as follows:

     ( 1.3.6.1.1.6.1.9 NAME 'pcimRuleValidityAssociation'
           DESC 'This defines the scheduled activation or deactivation
                 of a policy rule.'

Top      Up      ToC       Page 33 
           SUP pcimPolicy
           STRUCTURAL
           MAY ( pcimValidityConditionName $ pcimTimePeriodConditionDN )
     )

   The attributes of this class are defined as follows:

   The pcimValidityConditionName attribute is used to define a
   user-friendly name of this condition, and may be used as a naming
   attribute if desired.  This attribute is defined as follows:

     ( 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.  It is defined as follows:

     ( 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 to enable an instance of
   pcimRuleValidityAssociation to have attached to it an instance of the
   auxiliary class pcimTPCAuxClass, or one of its subclasses.  This
   would be used to formalize the semantics of the
   PolicyRuleValidityPeriod aggregation [1].

   Similarly, three separate DIT structure rules could be written.  Each
   of these DIT structure rules would refer to a specific name form that
   defined two important semantics.  First, each name form would
   identify one of the three possible naming attributes (i.e.,
   pcimValidityConditionName, cn, and orderedCIMKeys) for the
   pcimRuleValidityAssociation object class.  Second, each name form
   would require that an instance of the pcimRuleValidityAssociation
   class have as its superior an instance of the pcimRule class.  This

Top      Up      ToC       Page 34 
   structure rule SHOULD also include a superiorStructureRule (see Note
   2 at the beginning of section 5).

5.6.  The Class pcimRuleActionAssociation

   This class contains an attribute to represent the one property of the
   PCIM PolicyActionInPolicyRule association, ActionOrder.  This
   property is used to specify an order for executing the actions
   associated with a policy rule.  Instances of this class are related
   to an instance of pcimRule via DIT containment.  The actions
   themselves are represented by auxiliary subclasses of the auxiliary
   class pcimActionAuxClass.

   These auxiliary classes are attached directly to instances of
   pcimRuleActionAssociation for rule-specific policy actions.  For a
   reusable policy action, the pcimAction auxiliary subclass is attached
   to an instance of the class pcimPolicyInstance (which is presumably
   associated with a pcimRepository by DIT containment), and the
   pcimActionDN attribute (of this class) is used to reference the
   reusable pcimCondition instance.

   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 used to define a user-friendly name
   of this action, and may be used as a naming attribute if desired.
   This attribute is defined as follows:

     ( 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
     )

Top      Up      ToC       Page 35 
   The pcimActionOrder attribute is an unsigned integer that is used to
   indicate the relative position of an action in a sequence of actions
   that are associated with a given policy rule.  When this number is
   positive, it indicates a place in the sequence of actions to be
   performed, with smaller values indicating earlier positions in the
   sequence.  If the value is zero, then this indicates that the order
   is irrelevant.  Note that if two or more actions have the same
   non-zero value, they may be performed in any order as long as they
   are each performed in the correct place in the overall sequence of
   actions.  This attribute is defined as follows:

     ( 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 references a reusable policy
   action.  It is defined as follows:

     ( 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 to enable an instance of
   pcimRuleActionAssociation to have attached to it an instance of the
   auxiliary class pcimActionAuxClass, or one of its subclasses.  This
   would be used to formalize the semantics of the
   PolicyActionInPolicyRule association.  Specifically, this would be
   used to represent a rule-specific policy action [1].

   Similarly, three separate DIT structure rules could be written.  Each
   of these DIT structure rules would refer to a specific name form that
   defined two important semantics.  First, each name form would
   identify one of the three possible naming attributes (i.e.,
   pcimActionName, cn, and orderedCIMKeys) for the

Top      Up      ToC       Page 36 
   pcimRuleActionAssociation object class.  Second, each name form would
   require that an instance of the pcimRuleActionAssociation class have
   as its superior an instance of the pcimRule class.  This structure
   rule should also include a superiorStructureRule (see Note 2 at the
   beginning of section 5).

5.7.  The Auxiliary Class pcimConditionAuxClass

   The purpose of a policy condition is to determine whether or not the
   set of actions (contained in the pcimRule that the condition applies
   to) should be executed or not.  This class defines the basic
   organizational semantics of a policy condition, as specified in [1].
   Subclasses of this auxiliary class can be attached to instances of
   three other classes in the PCLS.  When a subclass of this class is
   attached to an instance of pcimRuleConditionAssociation, or to an
   instance of pcimRule, it represents a rule-specific policy condition.
   When a subclass of this class is attached to an instance of
   pcimPolicyInstance, it represents a reusable policy condition.

   Since all of the classes to which subclasses of this auxiliary class
   may be attached are derived from the pcimPolicy class, the attributes
   of pcimPolicy will already be defined for the entries to which these
   subclasses attach.  Thus, this class is derived directly from "top".

   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

   The PCIM defines a time period class, PolicyTimePeriodCondition, to
   provide a means of representing the time periods during which a
   policy rule is valid, i.e., active.  It also defines an aggregation,
   PolicyRuleValidityPeriod, so that time periods can be associated with
   a PolicyRule.  The LDAP mapping also provides two classes, one for
   the time condition itself, and one for the aggregation.

   In the PCIM, the time period class is named
   PolicyTimePeriodCondition. However, the resulting name of the
   auxiliary class in this mapping (pcimTimePeriodConditionAuxClass)
   exceeds the length of a name that some directories can store.
   Therefore, the name has been shortened to pcimTPCAuxClass.

Top      Up      ToC       Page 37 
   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 )
     )

   The attributes of the pcimTPCAuxClass are defined as follows.

   The pcimTPCTime attribute represents the time period that a policy
   rule is enabled for.  This attribute is defined as a string in [1]
   with a special format which defines a time period with a starting
   date and an ending date separated by a forward slash ("/"), as
   follows:

       yyyymmddThhmmss/yyyymmddThhmmss

   where the first date and time may be replaced with the string
   "THISANDPRIOR" or the second date and time may be replaced with the
   string "THISANDFUTURE".  This attribute is defined as follows:

        ( 1.3.6.1.1.6.2.25
               NAME 'pcimTPCTime'
               DESC 'The start and end times on which a policy rule is
                     valid.'
               EQUALITY caseIgnoreMatch
               ORDERING caseIgnoreOrderingMatch
               SUBSTR caseIgnoreSubstringsMatch
               SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
               SINGLE-VALUE
        )

   The value of this attribute SHOULD be checked against its defined
   format ("yyyymmddThhmmss/yyyymmddThhmmss", where the first and second
   date strings may be replaced with the strings "THISANDPRIOR" and
   "THISANDFUTURE").  If the value of this attribute does not conform to
   this syntax, then this SHOULD be considered an error and the policy
   rule SHOULD be treated as being disabled.

   The next four attributes (pcimTPCMonthOfYearMask,
   pcimTPCDayOfMonthMask, pcimTPCDayOfWeekMask, and
   pcimTPCTimeOfDayMask) are all defined as octet strings in [1].
   However, the semantics of each of these attributes are contained in

Top      Up      ToC       Page 38 
   bit strings of various fixed lengths.  Therefore, the PCLS uses a
   syntax of Bit String to represent each of them.  The definition of
   these four attributes are as follows.

   The pcimTPCMonthOfYearMask attribute defines a 12-bit mask
   identifying the months of the year in which a policy rule is valid.
   The format is a bit string of length 12, representing the months of
   the year from January through December.  The definition of this
   attribute is as follows:

     ( 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 of this attribute does not conform to this
   syntax, then this SHOULD be considered an error and the policy rule
   SHOULD be treated as being disabled.

   The pcimTPCMonthOfDayMask attribute defines a mask identifying the
   days of the month on which a policy rule is valid.  The format is a
   bit string of length 62.  The first 31 positions represent the days
   of the month in ascending order, from day 1 to day 31.  The next 31
   positions represent the days of the month in descending order, from
   the last day to the day 31 days from the end.  The definition of this
   attribute is as follows:

     ( 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
     )

Top      Up      ToC       Page 39 
   The value of this attribute SHOULD be checked against its defined
   format.  If the value of this attribute does not conform to this
   syntax, then this SHOULD be considered an error and the policy rule
   SHOULD be treated as being disabled.

   The pcimTPCDayOfWeekMask attribute defines a mask identifying the
   days of the week on which a policy rule is valid.  The format is a
   bit string of length 7, representing the days of the week from Sunday
   through Saturday.  The definition of this attribute is as follows:

     ( 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 of this attribute does not conform to this
   syntax, then this SHOULD be considered an error and the policy rule
   SHOULD be treated as being disabled.

   The pcimTPCTimeOfDayMask attribute defines the range of times at
   which a policy rule is valid.  If the second time is earlier than the
   first, then the interval spans midnight.  The format of the string is
   Thhmmss/Thhmmss.  The definition of this attribute is as follows:

     ( 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 of this attribute does not conform to this
   syntax, then this SHOULD be considered an error and the policy rule
   SHOULD be treated as being disabled.

Top      Up      ToC       Page 40 
   Finally, the pcimTPCLocalOrUtcTime attribute is used to choose
   between local or UTC time representation.  This is mapped as a simple
   integer syntax, with the value of 1 representing local time and the
   value of 2 representing UTC time.  The definition of this attribute
   is as follows:

     ( 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 the pcimTPCLocalOrUtcTime is not 1 or 2, then
   this SHOULD be considered an error and the policy rule SHOULD be
   disabled. If the attribute is not present at all, then all times are
   interpreted as if it were present with the value 2, that is, UTC
   time.

5.9.  The Auxiliary Class pcimConditionVendorAuxClass

   This class provides a general extension mechanism for representing
   policy conditions that have not been modeled with specific
   properties. Instead, its two properties are used to define the
   content and format of the condition, as explained below.  This class
   is intended for vendor-specific extensions that are not amenable to
   using pcimCondition; standardized extensions SHOULD NOT use this
   class.

   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 a multi-valued attribute.
   It provides a general mechanism for representing policy conditions
   that have not been modeled as specific attributes.  This information
   is encoded in a set of octet strings.  The format of the octet

Top      Up      ToC       Page 41 
   strings is identified by the OID stored in the
   pcimVendorConstraintEncoding attribute.  This 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 is used to identify the
   format and semantics for the pcimVendorConstraintData attribute.
   This attribute is 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 purpose of a policy action is to execute one or more operations
   that will affect network traffic and/or systems, devices, etc. in
   order to achieve a desired policy state.  This class is used to
   represent an action to be performed as a result of a policy rule
   whose condition clause was satisfied.

   Subclasses of this auxiliary class can be attached to instances of
   three other classes in the PCLS.  When a subclass of this class is
   attached to an instance of pcimRuleActionAssociation, or to an
   instance of pcimRule, it represents a rule-specific policy action.
   When a subclass of this class is attached to an instance of
   pcimPolicyInstance, it represents a reusable policy action.

   Since all of the classes to which subclasses of this auxiliary class
   may be attached are derived from the pcimPolicy class, the attributes
   of the pcimPolicy class will already be defined for the entries to
   which these subclasses attach.  Thus, this class is derived directly
   from "top".

Top      Up      ToC       Page 42 
   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

   The purpose of this class is to provide a general extension mechanism
   for representing policy actions that have not been modeled with
   specific properties.  Instead, its two properties are used to define
   the content and format of the action, as explained below.

   As its name suggests, this class is intended for vendor-specific
   extensions that are not amenable to using the standard pcimAction
   class.  Standardized extensions SHOULD NOT use this class.

   The class definition is as follows:

     ( 1.3.6.1.1.6.1.15 NAME 'pcimActionVendorAuxClass'
            DESC 'A class that defines a registered means to describe a
                  policy action.'
            SUP pcimActionAuxClass
            AUXILIARY
            MAY ( pcimVendorActionData $ pcimVendorActionEncoding )
     )

   The pcimVendorActionData attribute is a multi-valued attribute.  It
   provides a general mechanism for representing policy actions that
   have not been modeled as specific attributes.  This information is
   encoded in a set of octet strings.  The format of the octet strings
   is identified by the OID stored in the pcimVendorActionEncoding
   attribute.  This attribute is defined as follows:

     ( 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
     )

Top      Up      ToC       Page 43 
   The pcimVendorActionEncoding attribute is used to identify the format
   and semantics for the pcimVendorActionData attribute.  This attribute
   is defined as follows:

     ( 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 is not defined in the PCIM.  Its role is to serve as a
   structural class to which auxiliary classes representing policy
   information are attached when the information is reusable.  For
   auxiliary classes representing policy conditions and policy actions,
   there are alternative structural classes that may be used.  See
   Section 4.4 for a complete discussion of reusable policy conditions
   and actions, and of the role that this class plays in how they are
   represented.

   The class definition is as follows:

     ( 1.3.6.1.1.6.1.16 NAME 'pcimPolicyInstance'
            DESC 'A structural class to which aux classes containing
                  reusable policy information can be attached.'
            SUP pcimPolicy
            MAY ( pcimPolicyInstanceName )
     )

   The pcimPolicyInstanceName attribute is used to define a
   user-friendly name of this class, and may be used as a naming
   attribute if desired.  It is defined as follows:

     ( 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
     )

Top      Up      ToC       Page 44 
   A DIT content rule could be written to enable an instance of
   pcimPolicyInstance to have attached to it either instances of one or
   more of the auxiliary object classes pcimConditionAuxClass and
   pcimActionAuxClass.  Since these semantics do not include specifying
   any properties, the content rule would not need to specify any
   attributes.  Note that other content rules could be defined to enable
   other policy-related auxiliary classes to be attached to
   pcimPolicyInstance.

   Similarly, three separate DIT structure rules could be written.  Each
   of these DIT structure rules would refer to a specific name form that
   defined two important semantics.  First, each name form would
   identify one of the three possible naming attributes (i.e.,
   pcimPolicyInstanceName, cn, and orderedCIMKeys) for this object
   class.  Second, each name form would require that an instance of the
   pcimPolicyInstance class have as its superior an instance of the
   pcimRepository class.  This structure rule SHOULD also include a
   superiorStructureRule (see Note 2 at the beginning of section 5).

5.13.  The Auxiliary Class pcimElementAuxClass

   This class introduces no additional attributes, beyond those defined
   in the class pcimPolicy from which it is derived.  Its role is to
   "tag" an instance of a class defined outside the realm of policy
   information as represented by PCIM as being nevertheless relevant to
   a policy specification.  This tagging can potentially take place at
   two levels:

   -   Every instance to which pcimElementAuxClass is attached becomes
       an instance of the class pcimPolicy, since pcimElementAuxClass is
       a subclass of pcimPolicy.  Searching for object
       class="pcimPolicy" will return the instance.  (As noted earlier,
       this approach does NOT work for some directory implementations.
       To accommodate these implementations, policy-related entries
       SHOULD be tagged with the pcimKeyword "POLICY".)

   -   With the pcimKeywords attribute that it inherits from pcimPolicy,
       an instance to which pcimElementAuxClass is attached can be
       tagged as being relevant to a particular type or category of
       policy information, using standard keywords,
       administrator-defined keywords, or both.

   The class definition is as follows:

     ( 1.3.6.1.1.6.1.17 NAME 'pcimElementAuxClass'
            DESC 'An auxiliary class used to tag instances of classes
                  defined outside the realm of policy as relevant to a
                  particular policy specification.'

Top      Up      ToC       Page 45 
            SUP pcimPolicy
            AUXILIARY
     )

5.14.  The Three Policy Repository Classes

   These classes provide a container for reusable policy information,
   such as reusable policy conditions and/or reusable policy actions.
   This document is concerned with mapping just the properties that
   appear in these classes.  Conceptually, this may be thought of as a
   special location in the DIT where policy information may reside.
   Since pcimRepository is derived from the class dlm1AdminDomain
   defined in reference [6], this specification has a normative
   dependency on that element of reference [6] (as well as on its entire
   derivation hierarchy, which also appears in reference [6]).  To
   maximize flexibility, the pcimRepository class is defined as
   abstract.  A subclass pcimRepositoryAuxClass provides for auxiliary
   attachment to another entry, while a structural subclass
   pcimRepositoryInstance is available to represent a policy repository
   as a standalone entry.

   The definition for the pcimRepository class is as follows:

     ( 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 used to define a user-friendly
   name of this class, and may be used as a naming attribute if desired.
   It is defined as follows:

     ( 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
     )

Top      Up      ToC       Page 46 
   The two subclasses of pcimRepository are defined as follows.  First,
   the pcimRepositoryAuxClass is an auxiliary class that can be used to
   aggregate reusable policy information.  It is defined as follows:

     ( 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
     )

   In cases where structural classes are needed instead of an auxiliary
   class, the pcimRepositoryInstance class is a structural class that
   can be used to aggregate reusable policy information.  It is defined
   as follows:

     ( 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 of these DIT structure rules would refer to a specific name form
   that enabled an instance of the pcimRepository class to be named
   under any superior using one of the three possible naming attributes
   (i.e., pcimRepositoryName, cn, and orderedCIMKeys).  This structure
   rule SHOULD also include a superiorStructureRule (see Note 2 at the
   beginning of section 5).

5.15.  The Auxiliary Class pcimSubtreesPtrAuxClass

   This auxiliary class provides a single, multi-valued attribute that
   references a set of objects that are at the root of DIT subtrees
   containing policy-related information.  By attaching this attribute
   to instances of various other classes, a policy administrator has a
   flexible way of providing an entry point into the directory that
   allows a client to locate and retrieve the policy information
   relevant to it.

   It is intended that these entries are placed in the DIT such that
   well-known DNs can be used to reference a well-known structural entry
   that has the pcimSubtreesPtrAuxClass attached to it.  In effect, this
   defines a set of entry points.  Each of these entry points can
   contain and/or reference all related policy entries for

Top      Up      ToC       Page 47 
   any well-known policy domains.  The pcimSubtreesPtrAuxClass functions
   as a tag to identify portions of the DIT that contain policy
   information.

   This object does not provide the semantic linkages between individual
   policy objects, such as those between a policy group and the policy
   rules that belong to it.  Its only role is to enable efficient bulk
   retrieval of policy-related objects, as described in Section 4.5.

   Once the objects have been retrieved, a directory client can
   determine the semantic linkages by following references contained in
   multi-valued attributes, such as pcimRulesAuxContainedSet.

   Since policy-related objects will often be included in the DIT
   subtree beneath an object to which this auxiliary class is attached,
   a client SHOULD request the policy-related objects from the subtree
   under the object with these references at the same time that it
   requests the references themselves.

   Since clients are expected to behave in this way, the policy
   administrator SHOULD make sure that this subtree does not contain so
   many objects unrelated to policy that an initial search done in this
   way results in a performance problem.  The pcimSubtreesPtrAuxClass
   SHOULD NOT be attached to the partition root for a large directory
   partition containing a relatively few number of policy-related
   objects along with a large number of objects unrelated to policy
   (again, "policy" here refers to the PCIM, not the X.501, definition
   and use of "policy").  A better approach would be to introduce a
   container object immediately below the partition root, attach
   pcimSubtreesPtrAuxClass to this container object, and then place all
   of the policy-related objects in that subtree.

   The class definition is as follows:

     ( 1.3.6.1.1.6.1.21 NAME 'pcimSubtreesPtrAuxClass'
            DESC 'An auxiliary class providing DN references to roots of
                  DIT subtrees containing policy-related objects.'
            SUP top
            AUXILIARY
            MAY ( pcimSubtreesAuxContainedSet )
     )

Top      Up      ToC       Page 48 
   The attribute pcimSubtreesAuxContainedSet provides an unordered set
   of DN references to instances of one or more objects under which
   policy-related information is present.  The objects referenced may or
   may not themselves contain policy-related information.  The attribute
   definition is as follows:

     ( 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
     )

   Note that the cn attribute does NOT need to be defined for this
   class. This is because an auxiliary class is used as a means to
   collect common attributes and treat them as properties of an object.
   A good analogy is a #include file, except that since an auxiliary
   class is a class, all the benefits of a class (e.g., inheritance) can
   be applied to an auxiliary class.

5.16.  The Auxiliary Class pcimGroupContainmentAuxClass

   This auxiliary class provides a single, multi-valued attribute that
   references a set of pcimGroups.  By attaching this attribute to
   instances of various other classes, a policy administrator has a
   flexible way of providing an entry point into the directory that
   allows a client to locate and retrieve the pcimGroups relevant to it.

   As is the case with pcimRules, a policy administrator might have
   several different references to a pcimGroup in the overall directory
   structure. The pcimGroupContainmentAuxClass is the mechanism that
   makes it possible for the policy administrator to define all these
   different references.

   The class definition is as follows:

     ( 1.3.6.1.1.6.1.22 NAME 'pcimGroupContainmentAuxClass'
            DESC 'An auxiliary class used to bind pcimGroups to an
                  appropriate container object.'
            SUP top
            AUXILIARY
            MAY ( pcimGroupsAuxContainedSet )
     )

Top      Up      ToC       Page 49 
   The attribute pcimGroupsAuxContainedSet provides an unordered set of
   references to instances of one or more pcimGroups associated with the
   instance of a structural class to which this attribute has been
   appended.

   The attribute definition is as follows:

     ( 1.3.6.1.1.6.2.38
            NAME 'pcimGroupsAuxContainedSet'
            DESC 'DNs of pcimGroups associated in some way with the
                  instance to which this attribute has been appended.'
            EQUALITY distinguishedNameMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
     )

   Note that the cn attribute does NOT have to be defined for this class
   for the same reasons as those given for the pcimSubtreesPtrAuxClass
   in section 5.15.

5.17.  The Auxiliary Class pcimRuleContainmentAuxClass

   This auxiliary class provides a single, multi-valued attribute that
   references a set of pcimRules.  By attaching this attribute to
   instances of various other classes, a policy administrator has a
   flexible way of providing an entry point into the directory that
   allows a client to locate and retrieve the pcimRules relevant to it.

   A policy administrator might have several different references to a
   pcimRule in the overall directory structure.  For example, there
   might be references to all pcimRules for traffic originating in a
   particular subnet from a directory entry that represents that subnet.
   At the same time, there might be references to all pcimRules related
   to a particular DiffServ setting from an instance of a pcimGroup
   explicitly introduced as a container for DiffServ-related pcimRules.
   The pcimRuleContainmentAuxClass is the mechanism that makes it
   possible for the policy administrator to define all these separate
   references.

   The class definition is as follows:

     ( 1.3.6.1.1.6.1.23 NAME 'pcimRuleContainmentAuxClass'
            DESC 'An auxiliary class used to bind pcimRules to an
                  appropriate container object.'
            SUP top
            AUXILIARY
            MAY ( pcimRulesAuxContainedSet )
     )

Top      Up      ToC       Page 50 
   The attribute pcimRulesAuxContainedSet provides an unordered set of
   references to one or more instances of pcimRules associated with the
   instance of a structural class to which this attribute has been
   appended.  The attribute definition is as follows:

     ( 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
     )

   The cn attribute does NOT have to be defined for this class for the
   same reasons as those given for the pcimSubtreesPtrAuxClass in
   section 5.15.



(page 50 continued on part 3)

Next RFC Part