Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3060

Policy Core Information Model -- Version 1 Specification

Pages: 100
Proposed Standard
Updated by:  3460
Part 4 of 5 – Pages 46 to 64
First   Prev   Next

Top   ToC   RFC3060 - Page 46   prevText

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.
Top   ToC   RFC3060 - Page 47

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
Top   ToC   RFC3060 - Page 48
   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.
Top   ToC   RFC3060 - Page 49
   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
Top   ToC   RFC3060 - Page 50
   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.
Top   ToC   RFC3060 - Page 51
   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.
Top   ToC   RFC3060 - Page 52
   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.
Top   ToC   RFC3060 - Page 53
   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.
Top   ToC   RFC3060 - Page 54
   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.
Top   ToC   RFC3060 - Page 55
   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
Top   ToC   RFC3060 - Page 56
   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.
Top   ToC   RFC3060 - Page 57
   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]]
Top   ToC   RFC3060 - Page 58

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
Top   ToC   RFC3060 - Page 59
   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
Top   ToC   RFC3060 - Page 60
   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.
Top   ToC   RFC3060 - Page 61
   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.
Top   ToC   RFC3060 - Page 62
   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.
Top   ToC   RFC3060 - Page 63
   [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
Top   ToC   RFC3060 - Page 64

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


(next page on part 5)

Next Section