7. Association and Aggregation Definitions

   The first two subsections of this section introduce associations and
   aggregations as they are used in CIM.  The remaining subsections
   present the class definitions for the associations and aggregations
   that are part of the Policy Core Information Model.

7.1. Associations

   An association is a CIM construct representing a relationship between
   two (or theoretically more) objects.  It is modeled as a class
   containing typically two object references.  Associations can be
   defined between classes without affecting any of the related classes.
   That is, addition of an association does not affect the interface of
   the related classes.

7.2. Aggregations

   An aggregation is a strong form of an association, which usually
   represents a "whole-part" or a "collection" relationship.  For
   example, CIM uses an aggregation to represent the containment
   relationship between a system and the components that make up the
   system.  Aggregation as a "whole-part" relationship often implies,
   but does not require, that the aggregated objects have mutual
   dependencies.

7.3. The Abstract Aggregation "PolicyComponent

   This abstract aggregation defines two object references that will be
   overridden in each of five subclasses, to become references to the
   concrete policy classes PolicyGroup, PolicyRule, PolicyCondition,
   PolicyAction, and PolicyTimePeriodCondition.  The value of the
   abstract superclass is to convey that all five subclasses have the
   same "whole- part" semantics, and for ease of query to locate all
   "components" of a PolicyGroup or PolicyRule.

   The class definition for the aggregation is as follows:

      NAME             PolicyComponent
      DESCRIPTION      A generic aggregation used to establish 'part of'
                       relationships between the subclasses of
                       Policy.  For example, the
                       PolicyConditionInPolicyRule aggregation defines
                       that PolicyConditions are part of a PolicyRule.
      ABSTRACT         TRUE
      PROPERTIES       GroupComponent[ref Policy[0..n]]
                       PartComponent[ref Policy[0..n]]

7.4. The Aggregation "PolicyGroupInPolicyGroup"

   The PolicyGroupInPolicyGroup aggregation enables policy groups to be
   nested.  This is critical for scalability and manageability, as it
   enables complex policies to be constructed from multiple simpler

   policies for administrative convenience.  For example, a policy group
   representing policies for the US might have nested within it policy
   groups for the Eastern and Western US.

   A PolicyGroup may aggregate other PolicyGroups via this aggregation,
   or it may aggregate PolicyRules via the PolicyRuleInPolicyGroup
   aggregation.  Note that it is assumed that this aggregation is used
   to form directed acyclic graphs and NOT ring structures.The class
   definition for the aggregation is as follows:

      NAME             PolicyGroupInPolicyGroup
      DESCRIPTION      A class representing the aggregation of
                       PolicyGroups by a higher-level PolicyGroup.
      DERIVED FROM     PolicyComponent
      ABSTRACT         FALSE
      PROPERTIES       GroupComponent[ref PolicyGroup[0..n]]
                       PartComponent[ref PolicyGroup[0..n]]

7.4.1. The Reference "GroupComponent"

   This property is inherited from PolicyComponent, and overridden to
   become an object reference to a PolicyGroup that contains one or more
   other PolicyGroups.  Note that for any single instance of the
   aggregation class PolicyGroupInPolicyGroup, this property (like all
   Reference properties) is single-valued.  The [0..n] cardinality
   indicates that there may be 0, 1, or more than one PolicyGroups that
   contain any given PolicyGroup.

7.4.2. The Reference "PartComponent"

   This property is inherited from PolicyComponent, and overridden to
   become an object reference to a PolicyGroup contained by one or more
   other PolicyGroups.  Note that for any single instance of the
   aggregation class PolicyGroupInPolicyGroup, this property (like all
   Reference properties) is single-valued.  The [0..n] cardinality
   indicates that a given PolicyGroup may contain 0, 1, or more than one
   other PolicyGroups.

7.5. The Aggregation "PolicyRuleInPolicyGroup"

   A policy group may aggregate one or more policy rules, via the
   PolicyRuleInPolicyGroup aggregation.  Grouping of policy rules into a
   policy group is again for administrative convenience; a policy rule
   may also be used by itself, without belonging to a policy group.

   A PolicyGroup may aggregate PolicyRules via this aggregation, or it
   may aggregate other PolicyGroups via the PolicyGroupInPolicyGroup
   aggregation.

   The class definition for the aggregation is as follows:

      NAME             PolicyRuleInPolicyGroup
      DESCRIPTION      A class representing the aggregation of
                       PolicyRules by a PolicyGroup.
      DERIVED FROM     PolicyComponent
      ABSTRACT         FALSE
      PROPERTIES       GroupComponent[ref PolicyGroup[0..n]]
                       PartComponent[ref PolicyRule[0..n]]

7.5.1. The Reference "GroupComponent"

   This property is inherited from PolicyComponent, and overridden to
   become an object reference to a PolicyGroup that contains one or more
   PolicyRules.  Note that for any single instance of the aggregation
   class PolicyRuleInPolicyGroup, this property (like all Reference
   properties) is single-valued.  The [0..n] cardinality indicates that
   there may be 0, 1, or more than one PolicyGroups that contain any
   given PolicyRule.

7.5.2. The Reference "PartComponent"

   This property is inherited from PolicyComponent, and overridden to
   become an object reference to a PolicyRule contained by one or more
   PolicyGroups.  Note that for any single instance of the aggregation
   class PolicyRuleInPolicyGroup, this property (like all Reference
   properties) is single-valued.  The [0..n] cardinality indicates that
   a given PolicyGroup may contain 0, 1, or more than one PolicyRules.

7.6. The Aggregation "PolicyConditionInPolicyRule"

   A policy rule aggregates zero or more instances of the
   PolicyCondition class, via the PolicyConditionInPolicyRule
   association.  A policy rule that aggregates zero policy conditions
   must indicate in its class definition what "triggers" the performance
   of its actions.  In short, it must describe its implicit
   PolicyConditions, since none are explicitly associated.  For example,
   there might be a subclass of PolicyRule named "HttpPolicyRule", where
   the class definition assumes that the condition, "If HTTP traffic,"
   is true before the rule's actions would be performed.  There is no
   need to formalize and instantiate this condition, since it is obvious
   in the semantics of the PolicyRule.

   The conditions aggregated by a policy rule are grouped into two
   levels of lists: either an ORed set of ANDed sets of conditions (DNF,
   the default) or an ANDed set of ORed sets of conditions (CNF).
   Individual conditions in these lists may be negated.  The property
   ConditionListType (in PolicyRule) specifies which of these two

   grouping schemes applies to a particular PolicyRule.  The conditions
   are used to determine whether to perform the actions associated with
   the PolicyRule.

   One or more policy time periods may be among the conditions
   associated with a policy rule via the PolicyConditionInPolicyRule
   association.  In this case, the time periods are simply additional
   conditions to be evaluated along with any other conditions specified
   for the rule.

   The class definition for the aggregation is as follows:

      NAME             PolicyConditionInPolicyRule
      DESCRIPTION      A class representing the aggregation of
                       PolicyConditions by a PolicyRule.
      DERIVED FROM     PolicyComponent
      ABSTRACT         FALSE
      PROPERTIES       GroupComponent[ref PolicyRule[0..n]]
                       PartComponent[ref PolicyCondition[0..n]]
                       GroupNumber
                       ConditionNegated

7.6.1. The Reference "GroupComponent"

   This property is inherited from PolicyComponent, and overridden to
   become an object reference to a PolicyRule that contains one or more
   PolicyConditions.  Note that for any single instance of the
   aggregation class PolicyConditionInPolicyRule, this property (like
   all Reference properties) is single-valued.  The [0..n] cardinality
   indicates that there may be 0, 1, or more than one PolicyRules that
   contain any given PolicyCondition.

7.6.2. The Reference "PartComponent"

   This property is inherited from PolicyComponent, and overridden to
   become an object reference to a PolicyCondition contained by one or
   more PolicyRules.  Note that for any single instance of the
   aggregation class PolicyConditionInPolicyRule, this property (like
   all Reference properties) is single-valued.  The [0..n] cardinality
   indicates that a given PolicyRule may contain 0, 1, or more than one
   PolicyConditions.

7.6.3. The Property "GroupNumber"

   This property contains an integer identifying the group to which the
   condition referenced by the PartComponent property is assigned in
   forming the overall conditional expression for the policy rule
   identified by the GroupComponent reference.

   The property is defined as follows:

      NAME             GroupNumber
      DESCRIPTION      Unsigned integer indicating the group to which
                       the condition identified by the PartComponent
                       property is to be assigned.
      SYNTAX           uint16
      DEFAULT          0

7.6.4. The Property "ConditionNegated"

   This property is a boolean, indicating whether the condition
   referenced by the PartComponent property is negated in forming the
   overall conditional expression for the policy rule identified by the
   GroupComponent reference.

   The property is defined as follows:

      NAME             ConditionNegated
      DESCRIPTION      Indication of whether the condition identified by
                       the PartComponent property is negated.  (TRUE
                       indicates that the condition is negated, FALSE
                       indicates that it is not negated.)
      SYNTAX           boolean
      DEFAULT          FALSE

7.7. The Aggregation "PolicyRuleValidityPeriod"

   A different relationship between a policy rule and a policy time
   period (than PolicyConditionInPolicyRule) is represented by the
   PolicyRuleValidityPeriod aggregation.  The latter describes scheduled
   activation and deactivation of the policy rule.

   If a policy rule is associated with multiple policy time periods via
   this association, then the rule is active if at least one of the time
   periods indicates that it is active.  (In other words, the time
   periods are ORed to determine whether the rule is active.)  A policy
   time period may be aggregated by multiple policy rules.  A rule that
   does not point to a policy time period via this aggregation is, from
   the point of view of scheduling, always active.  It may, however, be
   inactive for other reasons.

   Time periods are a general concept that can be used in other
   applications.  However, they are mentioned explicitly here in this
   specification since they are frequently used in policy applications.

   The class definition for the aggregation is as follows:

      NAME             PolicyRuleValidityPeriod
      DESCRIPTION      A class representing the aggregation of
                       PolicyTimePeriodConditions by a PolicyRule.
      DERIVED FROM     PolicyComponent
      ABSTRACT         FALSE
      PROPERTIES       GroupComponent[ref PolicyRule[0..n]]
                       PartComponent[ref PolicyTimePeriodCondition[0..n]]

7.7.1. The Reference "GroupComponent"

   This property is inherited from PolicyComponent, and overridden to
   become an object reference to a PolicyRule that contains one or more
   PolicyTimePeriodConditions.  Note that for any single instance of the
   aggregation class PolicyRuleValidityPeriod, this property (like all
   Reference properties) is single-valued.  The [0..n] cardinality
   indicates that there may be 0, 1, or more than one PolicyRules that
   contain any given PolicyTimePeriodCondition.

7.7.2. The Reference "PartComponent"

   This property is inherited from PolicyComponent, and overridden to
   become an object reference to a PolicyTimePeriodCondition contained
   by one or more PolicyRules.  Note that for any single instance of the
   aggregation class PolicyRuleValidityPeriod, this property (like all
   Reference properties) is single-valued.  The [0..n] cardinality
   indicates that a given PolicyRule may contain 0, 1, or more than one
   PolicyTimePeriodConditions.

7.8. The Aggregation "PolicyActionInPolicyRule"

   A policy rule may aggregate zero or more policy actions.  A policy
   rule that aggregates zero policy actions must indicate in its class
   definition what actions are taken when the rule's conditions evaluate
   to TRUE.  In short, it must describe its implicit PolicyActions,
   since none are explicitly associated.  For example, there might be a
   subclass of PolicyRule representing a Diffserv absolute dropper,
   where the subclass itself indicates the action to be taken.  There is
   no need to formalize and instantiate this action, since it is obvious
   in the semantics of the PolicyRule.

   The actions associated with a PolicyRule may be given a required
   order, a recommended order, or no order at all.  For actions
   represented as separate objects, the PolicyActionInPolicyRule
   aggregation can be used to express an order.

   This aggregation does not indicate whether a specified action order
   is required, recommended, or of no significance; the property
   SequencedActions in the aggregating instance of PolicyRule provides
   this indication.

   The class definition for the aggregation is as follows:

      NAME             PolicyActionInPolicyRule
      DESCRIPTION      A class representing the aggregation of
                       PolicyActions by a PolicyCondition.
      DERIVED FROM     PolicyComponent
      ABSTRACT         FALSE
      PROPERTIES       GroupComponent[ref PolicyRule[0..n]]
                       PartComponent[ref PolicyAction[0..n]]
                       ActionOrder

7.8.1. The Reference "GroupComponent"

   This property is inherited from PolicyComponent, and overridden to
   become an object reference to a PolicyRule that contains one or more
   PolicyActions.  Note that for any single instance of the aggregation
   class PolicyActionInPolicyRule, this property (like all Reference
   properties) is single-valued.  The [0..n] cardinality indicates that
   there may be 0, 1, or more than one PolicyRules that contain any
   given PolicyAction.

7.8.2. The Reference "PartComponent"

   This property is inherited from PolicyComponent, and overridden to
   become an object reference to a PolicyAction contained by one or more
   PolicyRules.  Note that for any single instance of the aggregation
   class PolicyActionInPolicyRule, this property (like all Reference
   properties) is single-valued.  The [0..n] cardinality indicates that
   a given PolicyRule may contain 0, 1, or more than one  PolicyActions.

7.8.3. The Property "ActionOrder"

   This property provides an unsigned integer 'n' that indicates the
   relative position of an action in the sequence of actions associated
   with a policy rule.  When 'n' is a positive integer, it indicates a
   place in the sequence of actions to be performed, with smaller
   integers indicating earlier positions in the sequence.  The special
   value '0' indicates "don't care".  If two or more actions have the
   same non-zero sequence number, they may be performed in any order,
   but they must all be performed at the appropriate place in the
   overall action sequence.

   A series of examples will make ordering of actions clearer:

   o  If all actions have the same sequence number, regardless of
      whether it is '0' or non-zero, any order is acceptable.

   o  The values

      1:ACTION A
      2:ACTION B
      1:ACTION C
      3:ACTION D

      indicate two acceptable orders:  A,C,B,D or C,A,B,D, since A and C
      can be performed in either order, but only at the '1' position.

   o  The values

      0:ACTION A
      2:ACTION B
      3:ACTION C
      3:ACTION D

      require that B,C, and D occur either as B,C,D or as B,D,C.  Action
      A may appear at any point relative to B,C, and D.  Thus the
      complete set of acceptable orders is:  A,B,C,D; B,A,C,D; B,C,A,D;
      B,C,D,A; A,B,D,C; B,A,D,C; B,D,A,C; B,D,C,A.

      Note that the non-zero sequence numbers need not start with '1',
      and they need not be consecutive.  All that matters is their
      relative magnitude.

      The property is defined as follows:

      NAME             ActionOrder
      DESCRIPTION      Unsigned integer indicating the relative position
                       of an action in the sequence of actions aggregated
                       by a policy rule.
      SYNTAX           uint16

7.9. The Abstract Association "PolicyInSystem"

   This abstract association inherits two object references from a
   higher- level CIM association class, Dependency.  It overrides these
   object references to make them references to instances of the classes
   System and Policy.  Subclasses of PolicyInSystem then override these
   object references again, to make them references to concrete policy
   classes.

   The value of the abstract superclass is to convey that all subclasses
   have the same "dependency" semantics, and for ease of query to locate
   all policy "dependencies" on a System.  These dependencies are
   related to scoping or hosting of the Policy.

   The class definition for the association is as follows:

      NAME             PolicyInSystem
      DESCRIPTION      A generic association used to establish
                       dependency relationships between Policies and the
                       Systems that host them.
      DERIVED FROM     Dependency
      ABSTRACT         TRUE
      PROPERTIES       Antecedent[ref System[0..1]]
                       Dependent[ref Policy[0..n]]

7.10. The Weak Association "PolicyGroupInSystem"

   This association links a PolicyGroup to the System in whose scope the
   PolicyGroup is defined.

   The class definition for the association is as follows:

      NAME             PolicyGroupInSystem
      DESCRIPTION      A class representing the fact that a PolicyGroup
                       is defined within the scope of a System.
      DERIVED FROM     PolicyInSystem
      ABSTRACT         FALSE
      PROPERTIES       Antecedent[ref System[1..1]]
                       Dependent[ref PolicyGroup[weak]]

7.10.1. The Reference "Antecedent"

   This property is inherited from PolicyInSystem, and overridden to
   restrict its cardinality to [1..1].  It serves as an object reference
   to a System that provides a scope for one or more PolicyGroups.
   Since this is a weak association, the cardinality for this object
   reference is always 1, that is, a PolicyGroup is always defined
   within the scope of exactly one System.

7.10.2. The Reference "Dependent"

   This property is inherited from PolicyInSystem, and overridden to
   become an object reference to a PolicyGroup defined within the scope
   of a System.  Note that for any single instance of the association
   class PolicyGroupInSystem, this property (like all Reference

   properties) is single-valued.  The [0..n] cardinality indicates that
   a given System may have 0, 1, or more than one PolicyGroups defined
   within its scope.

7.11. The Weak Association "PolicyRuleInSystem"

   Regardless of whether it belongs to a PolicyGroup (or to multiple
   PolicyGroups), a PolicyRule is itself defined within the scope of a
   System.  This association links a PolicyRule to the System in whose
   scope the PolicyRule is defined.

   The class definition for the association is as follows:

      NAME             PolicyRuleInSystem
      DESCRIPTION      A class representing the fact that a PolicyRule
                       is defined within the scope of a System.
      DERIVED FROM     PolicyInSystem
      ABSTRACT         FALSE
      PROPERTIES       Antecedent[ref System[1..1]]
                       Dependent[ref PolicyRule[weak]]

7.11.1. The Reference "Antecedent"

   This property is inherited from PolicyInSystem, and overridden to
   restrict its cardinality to [1..1].  It serves as an object reference
   to a System that provides a scope for one or more PolicyRules.  Since
   this is a weak association, the cardinality for this object reference
   is always 1, that is, a PolicyRule is always defined within the scope
   of exactly one System.

7.11.2. The Reference "Dependent"

   This property is inherited from PolicyInSystem, and overridden to
   become an object reference to a PolicyRule defined within the scope
   of a System.  Note that for any single instance of the association
   class PolicyRuleInSystem, this property (like all Reference
   properties) is single-valued.  The [0..n] cardinality indicates that
   a given System may have 0, 1, or more than one PolicyRules defined
   within its scope.

7.12. The Association "PolicyConditionInPolicyRepository"

   A reusable policy condition is always related to a single
   PolicyRepository, via the PolicyConditionInPolicyRepository
   association.  This is not true for all PolicyConditions, however.  An
   instance of PolicyCondition that represents a rule-specific condition
   is not related to any policy repository via this association.

   The class definition for the association is as follows:

      NAME             PolicyConditionInPolicyRepository
      DESCRIPTION      A class representing the inclusion of a reusable
                       PolicyCondition in a PolicyRepository.
      DERIVED FROM     PolicyInSystem
      ABSTRACT         FALSE
      PROPERTIES       Antecedent[ref PolicyRepository[0..1]]
                       Dependent[ref PolicyCondition[0..n]]

7.12.1. The Reference "Antecedent"

   This property is inherited from PolicyInSystem, and overridden to
   become an object reference to a PolicyRepository containing one or
   more PolicyConditions.  A reusable PolicyCondition is always related
   to exactly one PolicyRepository via the
   PolicyConditionInPolicyRepository association.  The [0..1]
   cardinality for this property covers the two types of
   PolicyConditions:  0 for a rule-specific PolicyCondition, 1 for a
   reusable one.

7.12.2. The Reference "Dependent"

   This property is inherited from PolicyInSystem, and overridden to
   become an object reference to a PolicyCondition included in a
   PolicyRepository.  Note that for any single instance of the
   association class PolicyConditionInPolicyRepository, this property
   (like all Reference properties) is single-valued.  The [0..n]
   cardinality indicates that a given PolicyRepository may contain 0, 1,
   or more than one PolicyConditions.

7.13. The Association "PolicyActionInPolicyRepository"

   A reusable policy action is always related to a single
   PolicyRepository, via the PolicyActionInPolicyRepository association.
   This is not true for all PolicyActions, however.  An instance of
   PolicyAction that represents a rule-specific action is not related to
   any policy repository via this association.

   The class definition for the association is as follows:

      NAME             PolicyActionInPolicyRepository
      DESCRIPTION      A class representing the inclusion of a reusable
                       PolicyAction in a PolicyRepository.
      DERIVED FROM     PolicyInSystem
      ABSTRACT         FALSE
      PROPERTIES       Antecedent[ref PolicyRepository[0..1]]
                       Dependent[ref PolicyAction[0..n]]

7.13.1. The Reference "Antecedent"

   This property is inherited from PolicyInSystem, and overridden to
   become an object reference to a PolicyRepository containing one or
   more PolicyActions.  A reusable PolicyAction is always related to
   exactly one PolicyRepository via the PolicyActionInPolicyRepository
   association.  The [0..1] cardinality for this property covers the two
   types of PolicyActions:  0 for a rule-specific PolicyAction, 1 for a
   reusable one.

7.13.2. The Reference "Dependent"

   This property is inherited from PolicyInSystem, and overridden to
   become an object reference to a PolicyAction included in a
   PolicyRepository.  Note that for any single instance of the
   association class PolicyActionInPolicyRepository, this property (like
   all Reference properties) is single-valued.  The [0..n] cardinality
   indicates that a given PolicyRepository may contain 0, 1, or more
   than one PolicyActions.

7.14. The Aggregation "PolicyRepositoryInPolicyRepository"

   The PolicyRepositoryInPolicyRepository aggregation enables policy
   repositories to be nested.  This derives from the higher level CIM
   association, CIM_SystemComponent, describing that Systems contain
   other ManagedSystemElements.  This superclass could not be used for
   the other Policy aggregations, since Policies are not
   ManagedSystemElements, but ManagedElements.  Note that it is assumed
   that this aggregation is used to form directed acyclic graphs and NOT
   ring structures.

   The class definition for the aggregation is as follows:

      NAME             PolicyRepositoryInPolicyRepository
      DESCRIPTION      A class representing the aggregation of
                       PolicyRepositories by a higher-level
                       PolicyRepository.
      DERIVED FROM     SystemComponent
      ABSTRACT         FALSE
      PROPERTIES       GroupComponent[ref PolicyRepository[0..n]]
                         PartComponent[ref PolicyRepository[0..n]]

7.14.1. The Reference "GroupComponent"

   This property is inherited from the CIM class SystemComponent, and
   overridden to become an object reference to a PolicyRepository that
   contains one or more other PolicyRepositories.  Note that for any
   single instance of the aggregation class
   PolicyRepositoryInPolicyRepository, this property (like all Reference

   properties) is single-valued.  The [0..n] cardinality indicates that
   there may be 0, 1, or more than one PolicyRepositories that contain
   any given PolicyRepository.

7.14.2. The Reference "PartComponent"

   This property is inherited from the CIM class SystemComponent, and
   overridden to become an object reference to a PolicyRepository
   contained by one or more other PolicyRepositories.  Note that for any
   single instance of the aggregation class
   PolicyRepositoryInPolicyRepository, this property (like all Reference
   properties) is single-valued.  The [0..n] cardinality indicates that
   a given PolicyRepository may contain 0, 1, or more than one other
   PolicyRepositories.

8. Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.

   Copies of claims of rights made available for publication 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 Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

9. Acknowledgements

   The Policy Core Information Model in this document is closely based
   on the work of the DMTF's Service Level Agreements working group, so
   thanks are due to the members of that working group.  Several of the
   policy classes in this model first appeared in early drafts on IPSec
   policy and QoS policy.  The authors of these drafts were Partha
   Bhattacharya, Rob Adams, William Dixon, Roy Pereira, Raju Rajan,
   Jean-Christophe Martin, Sanjay Kamat, Michael See, Rajiv Chaudhury,
   Dinesh Verma, George Powers, and Raj Yavatkar.  Some other elements

   of the model originated in work done by Yoram Snir, Yoram Ramberg,
   and Ron Cohen.  In addition, we would like to thank Harald Alvestrand
   for conducting a thorough review of this document and providing many
   helpful suggestions, and Luis Sanchez and Russ Mundy for their help
   with the document's Security Considerations.

10. Security Considerations

   The Policy Core Information Model (PCIM) presented in this document
   provides an object-oriented model for describing policy information.
   It provides a basic framework for describing the structure of policy
   information, in a form independent of any specific repository or
   access protocol, for use by an operational system.  PCIM is not
   intended to represent any particular system design or implementation,
   nor does it define a protocol, and as such it does not have any
   specific security requirements.

   However, it should also be noted that certain derivative documents,
   which use PCIM as a base, will need to convey more specific security
   considerations.  In order to communicate the nature of what will be
   expected in these follow-on derivative documents, it is necessary to
   review the reasons that PCIM, as defined in this document, is neither
   implementable, nor representative of any real-world system, as well
   as the nature of the expected follow-on extensions and mappings.

   There are three independent reasons that PCIM, as defined here, is
   neither implementable nor representative of any real-world system:

      1. Its classes are independent of any specific repository that
         uses any specific access protocol.  Therefore, its classes are
         designed not to be implemented directly.  PCIM should instead
         be viewed as a schematic that directs how information should be
         represented, independent of any specific model implementation
         constraints.

      2. Its classes were designed to be independent of any specific
         policy domain.  For example, DiffServ and IPSec represent two
         different policy domains.  Each document which extends PCIM to
         one of these domains will derive subclasses from the classes
         and relationships defined in PCIM, in order to represent
         extensions of a generic model to cover specific technical
         domains.

      3. It's an information model, which must be mapped to a specific
         data model (native CIM schema, LDAP schema, MIB, whatever)
         before it can be implemented.  Derivative documents will map
         the extended information models noted in item 2, above, to
         specific types of data model implementations.

   Even though specific security requirements are not appropriate for
   PCIM, specific security requirements MUST be defined for each
   operational real- world application of PCIM.  Just as there will be a
   wide range of operational, real-world systems using PCIM, there will
   also be a wide range of security requirements for these systems.
   Some operational, real-world systems that are deployed using PCIM may
   have extensive security requirements that impact nearly all classes
   and subclasses utilized by such a system, while other systems'
   security requirements might have very little impact.

   The derivative documents, discussed above, will create the context
   for applying operational, real-world, system-level security
   requirements against the various models which derive from PCIM.

   For example, in some real-world scenarios, the values associated with
   certain properties, within certain instantiated classes, may
   represent information associated with scarce, and/or costly (and
   therefore valuable) resources.  It may be the case that these values
   must not be disclosed to, or manipulated by, unauthorized parties.
   As long as the derived model remains an information model (as opposed
   to a data model), it is not possible to discuss the data model-
   specific tools and mechanisms that are available for achieving the
   authentication and authorization implicit in a requirement that
   restricts read and/or read- write access to these values.  Therefore,
   these mechanisms will need to be discussed in each of the data models
   to which the derived information models are mapped.  If there are any
   general security requirements that can be identified and can be
   applied across multiple types of data models, it would be appropriate
   to discuss those at the information model level, rather than the data
   model level.  In any case, any identified security requirements that
   are not dealt with in the information model document, MUST be dealt
   with in the derivative data model documents.

   We can illustrate these points by extending the example from Section
   2.  A real-world system that provides QoS Gold Service to John would
   likely need to provide at least the following security-related
   capabilities and mechanisms (see [12] for definitions of security
   related terms):

   o  Data integrity for the information (e.g., property values and
      instantiated relationships) that specify that John gets QoS Gold
      Service, from the point(s) that the information is entered into
      the system to the point(s) where network components actually
      provide that Service.

   o  Authentication and Authorization methods to ensure that only
      system administrators (and not John or other engineers) can
      remotely administer components of the system.

   o  An Authentication method to insure that John receives Gold
      Service, and the other members of the engineering group receive
      Bronze Service.

   These are one possible set of requirements associated with an example
   real-world system which delivers Gold Service, and the appropriate
   place to document these would be in some combination of the
   information model and the derivative data models for QoS Policy.
   Each of the data models would also need to discuss how these
   requirements are satisfied, using the mechanisms typically available
   to such a data model, given the particular technology or set of
   technologies which it may employ.

11. References

   [1]  Distributed Management Task Force, Inc., "DMTF Technologies: CIM
        Standards << CIM Schema: Version 2.4", available via links on
        the following DMTF web page:
        http://www.dmtf.org/spec/cim_schema_v24.html.

   [2]  Distributed Management Task Force, Inc., "Common Information
        Model (CIM) Specification, version 2.2, June 1999.  This
        document is available on the following DMTF web page:
        http://www.dmtf.org/spec/cims.html.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [4]  Hovey, R. and S. Bradner, "The Organizations Involved in the
        IETF Standards Process", BCP 11, RFC 2028, October 1996.

   [5]  J. Strassner and S. Judd, "Directory-Enabled Networks", version
        3.0c5 (August 1998).  A PDF file is available at
        http://www.murchiso.com/den/#denspec.

   [6]  J. Strassner, 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.

   [7]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
        2279, January 1998.

   [8]  Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects
        for Scheduling Management Operations", RFC 2591, May 1999.

   [9]  Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for
        Policy-based Admission Control", RFC 2753, January 2000.

   [10] Dawson, F. and D. Stenerson, "Internet Calendaring and
        Scheduling Core Object Specification (iCalendar)", RFC 2445,
        November 1998.

   [11] Strassner, J., and E. Ellesson, B. Moore, R. Moats, "Policy Core
        LDAP Schema", Work in Progress.

   [12] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May
        2000.

   Note: the CIM 2.4 Schema specification is defined by the following
   set of MOF files, available from the following URL:

      http://www.dmtf.org/spec/CIM_Schema24/CIM_Schema24.zip

12. Authors' Addresses

   Ed Ellesson
   LongBoard, Inc.
   2505 Meridian Pkwy, #100
   Durham, NC 27713

   Phone:   +1 919-361-3230
   Fax:     +1 919-361-3299
   EMail:  eellesson@lboard.com


   Bob Moore
   IBM Corporation, BRQA/502
   4205 S. Miami Blvd.
   Research Triangle Park, NC 27709

   Phone:   +1 919-254-4436
   Fax:     +1 919-254-6243
   EMail:  remoore@us.ibm.com


   John Strassner
   Cisco Systems, Bldg 15
   170 West Tasman Drive
   San Jose, CA 95134

   Phone:   +1 408-527-1069
   Fax:     +1 408-527-6351
   EMail:  johns@cisco.com


   Andrea Westerinen
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA 95134

   Phone:   +1 408-853-8294
   Fax:     +1 408-527-6351
   EMail:  andreaw@cisco.com