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, RFC2119, March 1997.
[4] Hovey, R. and S. Bradner, "The Organizations Involved in the
IETF Standards Process", BCP 11, RFC2028, 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", RFC2591, May 1999.
[9] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for
Policy-based Admission Control", RFC2753, January 2000.
[10] Dawson, F. and D. Stenerson, "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", RFC2445,
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, RFC2828, 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
13. Appendix A: Class Identification in a Native CIM Implementation
While the CommonName property is present in the abstract superclass
Policy, and is thus available in all of its instantiable subclasses,
CIM does not use this property for naming instances. The following
subsections discuss how naming is handled in a native CIM
implementation for each of the instantiable classes in the Policy
Core Information Model.
Two things should be noted regarding CIM naming:
o When a CIM association is specified as "weak", this is a statement
about naming scopes: an instance of the class at the weak end of
the association is named within the scope of an instance of the
class at the other end of the association. This is accomplished
by propagation of keys from the instance of the scoping class to
the instance of the weak class. Thus the weak class has, via key
propagation, all the keys from the scoping class, and it also has
one or more additional keys for distinguishing instances of the
weak class, within the context of the scoping class.
o All class names in CIM are limited to alphabetic and numeric
characters plus the underscore, with the restriction that the
first character cannot be numeric. Refer to Appendix F "Unicode
Usage" in reference [2] for an exact specification of how CIM
class names are encoded in CIM strings.
13.1. Naming Instances of PolicyGroup and PolicyRule
A policy group always exists in the context of a system. In the
Policy Core Information Model, this is captured by the weak
aggregation PolicyGroupInSystem between a PolicyGroup and a System.
Note that System serves as the base class for describing network
devices and administrative domains.
A policy rule also exists in the context of a system. In the Policy
Core Information Model, this is captured by the weak association
PolicyRuleInSystem between a PolicyRule and a System.
The following sections define the CIM keys for PolicyGroup and
PolicyRule.
13.1.1. PolicyGroup's CIM Keys
The CIM keys of the PolicyGroup class are:
o SystemCreationClassName (A CIM_System key, propagated due to the
weak association, PolicyGroupInSystem)
o SystemName (A CIM_System key, propagated due to the weak
association, PolicyGroupInSystem)
o CreationClassName
o PolicyGroupName
They are defined in Reference [1] as follows:
NAME SystemCreationClassName
DESCRIPTION SystemCreationClassName represents the class name of
the CIM System object providing the naming scope for
the instance of PolicyGroup.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME SystemName
DESCRIPTION SystemName represent the individual name of the
particular System object, providing the naming scope
for the instance of PolicyGroup.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME CreationClassName
DESCRIPTION This property is set to "CIM_PolicyGroup", if the
PolicyGroup object is directly instantiated. Or, it
is equal to the class name of the PolicyGroup
subclass that is instantiated.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME PolicyGroupName
DESCRIPTION The identifying name of this policy group.
SYNTAX string [MaxLen 256]
QUALIFIER key
13.1.2. PolicyRule's CIM Keys
The CIM keys of the PolicyRule class are:
o SystemCreationClassName (A CIM_System key, propagated due to the
weak association PolicyRuleInSystem)
o SystemName (A CIM_System key, propagated due to the weak
association PolicyRuleInSystem)
o CreationClassName
o PolicyRuleName
SystemCreationClassName and SystemName work the same as defined for
the class PolicyGroup. See Section 13.1.1 for details.
The other two properties are defined in Reference [1] as follows:
NAME CreationClassName
DESCRIPTION This property is set to "CIM_PolicyRule", if the
PolicyRule object is directly instantiated. Or,
it is equal to the class name of the PolicyRule
subclass that is instantiated.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME PolicyRuleName
DESCRIPTION The identifying name of this policy rule.
SYNTAX string [MaxLen 256]
QUALIFIER key
13.2. Naming Instances of PolicyCondition and Its Subclasses
The CIM keys of the PolicyCondition class are:
o SystemCreationClassName
o SystemName
o PolicyRuleCreationClassName
o PolicyRuleName
o CreationClassName
o PolicyConditionName
Note that none of the keys are defined as propagated, although they
appear to fit this convention. The reason for this difference is
because (as indicated in Sections 5.1 and 6.4) the PolicyCondition
class is used to represent both reusable and rule-specific
conditions. This, in turn, affects what associations are valid for
an instance of PolicyCondition, and how that instance is named.
In an ideal world, an instance of the PolicyCondition class would be
scoped either by its PolicyRepository (for a reusable condition) or
by its PolicyRule (for a rule-specific condition). However, CIM has
the restriction that a given class can only be "weak" to one other
class (i.e., defined by one weak association).
To work within the restrictions of CIM naming, it is necessary to
"simulate" weak associations between PolicyCondition and PolicyRule,
and between PolicyCondition and PolicyRepository, through a technique
we'll call manual key propagation. Strictly speaking, manual key
propagation isn't key propagation at all. But it has the same effect
as (true) key propagation, so the name fits.
Figure 9 illustrates how manual propagation works in the case of
PolicyCondition. (Note that only the key properties are shown for
each of the classes.) In the figure, the line composed of 'I's
indicates class inheritance, the one composed of 'P's indicates
(true) key propagation via the weak aggregation PolicyRuleInSystem,
and the ones composed of 'M's indicate manual key propagation.
+------------------+
| System |
+------------------+
|CreationClassName |
|Name |
+------------------+
^ P
I PPPPPPPPPPPPPPPPPPPPPPPPPPPP
I P
+------------------+ +---------------v--------------+
| AdminDomain | | PolicyRule |
+------------------+ +------------------------------+
|CreationClassName | | System.CreationClassName |
|Name | | System.Name |
+------------------+ | CreationClassName |
^ | PolicyRuleName |
I +------------------------------+
I M
I M
+------------------+ M
| PolicyRepository | M
+------------------+ M
|CreationClassName | M
|Name | M
+------------------+ M
M M
M M
M M
+----v-------------------v----+
| PolicyCondition |
+-----------------------------+
| SystemCreationClassName |
| SystemName |
| PolicyRuleCreationClassName |
| PolicyRuleName |
| CreationClassName |
| PolicyConditionName |
+-----------------------------+
Figure 9. Manual Key Propagation for Naming PolicyConditions
Looking at Figure 9, we see that two key properties,
CreationClassName and Name, are defined in the System class, and
inherited by its subclasses AdminDomain and PolicyRepository. Since
PolicyRule is weak to System, these two keys are propagated to it; it
also has its own keys CreationClassName and PolicyRuleName.
A similar approach, though not automatic, is used in "manual key
propagation". Here is the approach for rule-specific and reusable
PolicyConditions:
o The manual propagation of keys from PolicyRule to PolicyCondition
involves copying the values of PolicyRule's four key properties
into four similarly named key properties in PolicyCondition. From
the point of view of the CIM specification language, the property
SystemName in PolicyCondition is a completely new key property.
However, the relationship to the Name property in System is
defined in the description of SystemName.
o The manual propagation of keys from PolicyRepository to
PolicyCondition works in exactly the same way for the first two
key properties. However, since PolicyRepository doesn't include
PolicyRule properties, the PolicyRuleCreationClassName and
PolicyRuleName have no values. A special value, "No Rule", is
assigned to both of these properties in this case, indicating that
this instance of PolicyCondition is not named within the scope of
any particular policy rule.
The following section defines the specific CIM keys for
PolicyCondition.
13.2.1. PolicyCondition's CIM Keys
PolicyCondition's key properties are defined in Reference [1] as
follows:
NAME SystemCreationClassName
DESCRIPTION SystemCreationClassName represents the class
name of the CIM System object providing the
naming scope for the instance of PolicyCondition.
For a rule-specific policy condition, this is the
type of system (e.g., the name of the class that
created this instance) in whose context the policy
rule is defined. For a reusable policy condition,
this is set to "CIM_PolicyRepository", if the
PolicyRepository object is directly instantiated.
Or, it is equal to the class name of the
PolicyRepository subclass that is instantiated.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME SystemName
DESCRIPTION The name of the System object in whose scope this
policy condition is defined. This property
completes the identification of the System object.
For a rule-specific policy condition, this is the
name of the instance of the system in whose
context the policy rule is defined. For a
reusable policy condition, this is name of the
instance of PolicyRepository that holds the policy
condition.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME PolicyRuleCreationClassName
DESCRIPTION For a rule-specific policy condition, this
property identifies the class name of the policy
rule instance, in whose scope this instance of
PolicyCondition exists. For a reusable policy
condition, this property is set to a special
value, "No Rule", indicating that this instance
of PolicyCondition is not unique to one policy
rule.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME PolicyRuleName
DESCRIPTION For a rule-specific policy condition,
PolicyRuleName completes the identification of
the PolicyRule object with which this condition
is associated. For a reusable policy condition,
a special value, "No Rule", is used to indicate
that this condition is reusable.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME CreationClassName
DESCRIPTION The class name of the PolicyCondition subclass
that is instantiated.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME PolicyConditionName
DESCRIPTION The identifying name of this policy condition.
SYNTAX string [MaxLen 256]
QUALIFIER key
13.3. Naming Instances of PolicyAction and Its Subclasses
From the point of view of naming, the PolicyAction class and its
subclasses work exactly like the PolicyCondition class and its
subclasses. See Section 13.2 and 13.2.1 for details.
Specifically, the CIM keys of PolicyAction are:
o SystemCreationClassName
o SystemName
o PolicyRuleCreationClassName
o PolicyRuleName
o CreationClassName
o PolicyActionName
They are defined in Reference [1] as follows:
NAME SystemCreationClassName
DESCRIPTION SystemCreationClassName represents the class name
of the CIM System object providing the naming
scope for the instance of PolicyAction. For a
rule-specific policy action, this is the type of
system (e.g., the name of the class that created
this instance) in whose context the policy rule
is defined. For a reusable policy action, this
is set to "CIM_PolicyRepository", if the
PolicyRepository object is directly instantiated.
Or, it is equal to the class name of the
PolicyRepository subclass that is instantiated.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME SystemName
DESCRIPTION The name of the System object in whose scope this
policy action is defined. This property completes
the identification of the System object. For a
rule-specific policy action, this is the name of
the instance of the system in whose context the
policy rule is defined. For a reusable policy
action, this is name of the instance of
PolicyRepository that holds the policy action.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME PolicyRuleCreationClassName
DESCRIPTION For a rule-specific policy action, this property
identifies the class name of the policy rule