rfc3060.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,389 行 · 第 1/5 页
TXT
1,389 行
Moore, et al. Standards Track [Page 10]
RFC 3060 Policy Core Information Model February 2001
+-----------+
| System |
..... +--^-----^--+ .....
. . 1. 1. . .
*.(a).* .(b) .(c) *.(d).*
+--v---v---------+ . . +-v---v------------+
| PolicyGroup <........ . | PolicyRepository |
| | w * . | |
+------^---------+ . +-----^---------^--+
*. . 0..1 . 0..1 .
.(e) . .(f) .(g)
*. . . .
+------v------+ w * . . .
| <................. . .
| PolicyRule | . .
| | . .
| | . .
| <........................ . .
| |* (h) . . .
| | . . .
| | . . .
| | . . .
| | . . .
| | . . .
| | . . .
| | .* .* .
| | +---------v-------v--+ .
| | | PolicyCondition | .
| | *+--------------------+ .
| | (i) ^ .
| <.............. I .
| |* . I .
| | .* ^ .
| | +----v----------------------+ .
| | | PolicyTimePeriodCondition | .
| | +---------------------------+ .
| | (j) .
| <......................... .
| |* . .
| | .* .
| | +----------v---------+* .
| | | PolicyAction <.......
+-------------+ +--------------------+
Figure 1. Overview of the Core Policy Classes and Relationships
Moore, et al. Standards Track [Page 11]
RFC 3060 Policy Core Information Model February 2001
In this figure the boxes represent the classes, and the dotted arrows
represent the associations. The following associations appear:
(a) PolicyGroupInPolicyGroup
(b) PolicyGroupInSystem
(c) PolicyRuleInSystem
(d) PolicyRepositoryInPolicyRepository
(e) PolicyRuleInPolicyGroup
(f) PolicyConditionInPolicyRepository
(g) PolicyActionInPolicyRepository
(h) PolicyConditionInPolicyRule
(i) PolicyRuleValidityPeriod
(j) PolicyActionInPolicyRule
An association always connects two classes. The "two" classes may,
however, be the same class, as is the case with the
PolicyGroupInPolicyGroup association, which represents the recursive
containment of PolicyGroups in other PolicyGroups. The
PolicyRepositoryInPolicyRepository association is recursive in the
same way.
An association includes cardinalities for each of the related
classes. These cardinalities indicate how many instances of each
class may be related to an instance of the other class. For example,
the PolicyRuleInPolicyGroup association has the cardinality range "*'
(that is, "0..n") for both the PolicyGroup and PolicyRule classes.
These ranges are interpreted as follows:
o The "*" written next to PolicyGroup indicates that a PolicyRule
may be related to no PolicyGroups, to one PolicyGroup, or to more
than one PolicyGroup via the PolicyRuleInPolicyGroup association.
In other words, a PolicyRule may be contained in no PolicyGroups,
in one PolicyGroups, or in more than one PolicyGroup.
o The "*" written next to PolicyRule indicates that a PolicyGroup
may be related to no PolicyRules, to one PolicyRule, or to more
than one PolicyRule via the PolicyRuleInPolicyGroup association.
In other words, a PolicyGroup may contain no PolicyRules, one
PolicyRule, or more than one PolicyRule.
Moore, et al. Standards Track [Page 12]
RFC 3060 Policy Core Information Model February 2001
The "w" written next to the PolicyGroupInSystem and
PolicyRuleInSystem indicates that these are what CIM terms
"aggregations with weak references", or more briefly, "weak
aggregations". A weak aggregation is simply an indication of a
naming scope. Thus these two aggregations indicate that an instance
of a PolicyGroup or PolicyRule is named within the scope of a System
object. A weak aggregation implicitly has the cardinality 1..1 at
the end opposite the 'w'.
The associations shown in Figure 1 are discussed in more detail in
Section 7.
4. Inheritance Hierarchies for the Policy Core Information Model
The following diagram illustrates the inheritance hierarchy for the
core policy classes:
ManagedElement (abstract)
|
+--Policy (abstract)
| |
| +---PolicyGroup
| |
| +---PolicyRule
| |
| +---PolicyCondition (abstract)
| | |
| | +---PolicyTimePeriodCondition
| | |
| | +---VendorPolicyCondition
| |
| +---PolicyAction (abstract)
| |
| +---VendorPolicyAction
|
+--ManagedSystemElement (abstract)
|
+--LogicalElement (abstract)
|
+--System (abstract)
|
+--AdminDomain (abstract)
|
+---PolicyRepository
Figure 2. Inheritance Hierarchy for the Core Policy Classes
Moore, et al. Standards Track [Page 13]
RFC 3060 Policy Core Information Model February 2001
ManagedElement, ManagedSystemElement, LogicalElement, System, and
AdminDomain are defined in the CIM schema [1]. These classes are not
discussed in detail in this document.
In CIM, associations are also modeled as classes. For the Policy
Core Information Model, the inheritance hierarchy for the
associations is as follows:
[unrooted]
|
+---PolicyComponent (abstract)
| |
| +---PolicyGroupInPolicyGroup
| |
| +---PolicyRuleInPolicyGroup
| |
| +---PolicyConditionInPolicyRule
| |
| +---PolicyRuleValidityPeriod
| |
| +---PolicyActionInPolicyRule
|
+---Dependency (abstract)
| |
| +---PolicyInSystem (abstract)
| |
| +---PolicyGroupInSystem
| |
| +---PolicyRuleInSystem
| |
| +---PolicyConditionInPolicyRepository
| |
| +---PolicyActionInPolicyRepository
|
+---Component (abstract)
|
+---SystemComponent
|
+---PolicyRepositoryInPolicyRepository
Figure 3. Inheritance Hierarchy for the Core Policy Associations
The Dependency, Component, and SystemComponent associations are
defined in the CIM schema [1], and are not discussed further in this
document.
Moore, et al. Standards Track [Page 14]
RFC 3060 Policy Core Information Model February 2001
4.1. Implications of CIM Inheritance
From the CIM schema, both properties and associations are inherited
to the Policy classes. For example, the class ManagedElement is
referenced in the associations Dependency, Statistics and
MemberOfCollection. And, the Dependency association is in turn
referenced in the DependencyContext association. At this very
abstract and high level in the inheritance hierarchy, the number of
these associations is very small and their semantics are quite
general.
Many of these inherited associations convey additional semantics that
are not needed in understanding the Policy Core Information Model.
In fact, they are defined as OPTIONAL in the CIM Schema - since their
cardinality is "0..n" on all references. The PCIM document
specifically discusses what is necessary to support and instantiate.
For example, through subclassing of the Dependency association, the
exact Dependency semantics in PCIM are described.
So, one may wonder what to do with these other inherited
associations. The answer is "ignore them unless you need them". You
would need them to describe additional information and semantics for
policy data. For example, it may be necessary to capture statistical
data for a PolicyRule (either for the rule in a repository or for
when it is executing in a policy system). Some examples of
statistical data for a rule are the number of times it was
downloaded, the number of times its conditions were evaluated, and
the number of times its actions were executed. (These types of data
would be described in a subclass of CIM_StatisticalInformation.) In
these cases, the Statistics association inherited from ManagedElement
to PolicyRule may be used to describe the tie between an instance of
a PolicyRule and the set of statistics for it.
5. Details of the Model
The following subsections discuss several specific issues related to
the Policy Core Information Model.
5.1. Reusable versus Rule-Specific Conditions and Actions
Policy conditions and policy actions can be partitioned into two
groups: ones associated with a single policy rule, and ones that are
reusable, in the sense that they may be associated with more than one
policy rule. Conditions and actions in the first group are termed
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?