draft-ietf-policy-pcim-ext-00.txt   draft-ietf-policy-pcim-ext-01.txt 
Policy Framework Working Group B. Moore Policy Framework Working Group B. Moore
INTERNET-DRAFT L. Rafalow INTERNET-DRAFT L. Rafalow
Category: Standards Track IBM Updates: 3060 IBM
Y. Ramberg Category: Standards Track Y. Ramberg
Y. Snir Y. Snir
J. Strassner J. Strassner
A. Westerinen A. Westerinen
Cisco Systems Cisco Systems
R. Chadha R. Chadha
Telcordia Technologies Telcordia Technologies
M. Brunner M. Brunner
NEC NEC
R. Cohen R. Cohen
Ntear LLC Ntear LLC
February, 2001
Policy Core Information Model Extensions Policy Core Information Model Extensions
<draft-ietf-policy-pcim-ext-00.txt> <draft-ietf-policy-pcim-ext-01.txt>
Friday, February 23, 2001, 11:07 AM Monday, April 09, 2001, 11:13 AM
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 13 skipping to change at page 2, line 13
implementations of the original PCIM model. implementations of the original PCIM model.
Table of Contents Table of Contents
1. Introduction......................................................4 1. Introduction......................................................4
2. Overview of the Changes...........................................4 2. Overview of the Changes...........................................4
2.1. How to Change an Information Model...........................4 2.1. How to Change an Information Model...........................4
2.2. List of Changes to the Model.................................5 2.2. List of Changes to the Model.................................5
2.2.1. Changes to PolicyRepository................................5 2.2.1. Changes to PolicyRepository................................5
2.2.2. Additional Associations and Additional Reusable Elements...5 2.2.2. Additional Associations and Additional Reusable Elements...5
2.2.3. Priorities and Decision Strategies.........................5 2.2.3. Priorities and Decision Strategies.........................6
2.2.4. Policy Roles...............................................6 2.2.4. Policy Roles...............................................6
2.2.5. CompoundPolicyConditions and CompoundPolicyActions.........6 2.2.5. CompoundPolicyConditions and CompoundPolicyActions.........7
2.2.6. Variables and Values.......................................7 2.2.6. Variables and Values.......................................7
2.2.7. Packet Filtering...........................................7 2.2.7. Packet Filtering...........................................7
3. The Updated Class and Association Class Hierarchies...............7 3. The Updated Class and Association Class Hierarchies...............7
4. Areas of Extension to PCIM.......................................11 4. Areas of Extension to PCIM.......................................11
4.1. Scope of Policies: Domain Policies and Device Policies.....11 4.1. Policy Scope................................................12
4.2. Reusable Policy Elements....................................12 4.1.1. Levels of Abstraction: Domain- and Device-Level Policies..12
4.3. Policy Sets.................................................13 4.1.2. Administrative and Functional Scopes......................12
4.4. Nested Policy Rules.........................................13 4.2. Reusable Policy Elements....................................13
4.4.1. Usage Rules for Nested Rules..............................13 4.3. Policy Sets.................................................14
4.4.2. Motivation................................................14 4.4. Nested Policy Rules.........................................14
4.4.3. Usage Example.............................................15 4.4.1. Usage Rules for Nested Rules..............................14
4.5. Priorities and Decision Strategies..........................16 4.4.2. Motivation................................................15
4.5.1. Structuring Decision Strategies...........................17 4.4.3. Usage Example.............................................16
4.5.2. Deterministic Decisions...................................18 4.5. Priorities and Decision Strategies..........................18
4.5.3. Multiple PolicySet Trees For a Resource...................19 4.5.1. Structuring Decision Strategies...........................19
4.6. Policy Roles................................................19 4.5.2. Side Effects..............................................20
4.6.1. Comparison of Roles in PCIM with Roles in snmpconf........19 4.5.3. Multiple PolicySet Trees For a Resource...................20
4.6.2. Addition of PolicyRoleCollection to PCIMe.................20 4.5.4. Deterministic Decisions...................................21
4.6.3. Roles for PolicyGroups....................................21 4.6. Policy Roles................................................21
4.7. Compound Policy Conditions and Compound Policy Actions......22 4.6.1. Comparison of Roles in PCIM with Roles in snmpconf........21
4.7.1. Compound Policy Conditions................................23 4.6.2. Addition of PolicyRoleCollection to PCIMe.................22
4.7.2. Compound Policy Actions...................................23 4.6.3. Roles for PolicyGroups....................................23
4.8. Variables and Values........................................25 4.7. Compound Policy Conditions and Compound Policy Actions......24
4.8.1. Simple Policy Conditions..................................25 4.7.1. Compound Policy Conditions................................25
4.8.2. Using Simple Policy Conditions............................26 4.7.2. Compound Policy Actions...................................25
4.8.3. The Simple Condition Operator.............................27 4.8. Variables and Values........................................27
4.8.4. SimplePolicyActions.......................................28 4.8.1. Simple Policy Conditions..................................27
4.8.5. Policy Variables..........................................30 4.8.2. Using Simple Policy Conditions............................28
4.8.6. Explicitly Bound Policy Variables.........................30 4.8.3. The Simple Condition Operator.............................29
4.8.7. Implicitly Bound Policy Variables.........................31 4.8.4. SimplePolicyActions.......................................31
4.8.8. Structure and Usage of Pre-Defined Variables..............32 4.8.5. Policy Variables..........................................32
4.8.9. Rationale for Modeling Implicit Variables as Classes......33 4.8.6. Explicitly Bound Policy Variables.........................33
4.8.10. Policy Values............................................34 4.8.7. Implicitly Bound Policy Variables.........................33
4.9. Packet Filtering............................................34 4.8.8. Structure and Usage of Pre-Defined Variables..............34
5. Class Definitions................................................36 4.8.9. Rationale for Modeling Implicit Variables as Classes......35
5.1. The Abstract Class "PolicySet"..............................36 4.8.10. Policy Values............................................36
5.2. Updates to PCIM's Class "PolicyGroup".......................37 4.9. Packet Filtering............................................37
5.3. Updates to PCIM's Class "PolicyRule"........................37 5. Class Definitions................................................38
5.4. The Class "SimplePolicyCondition"...........................38 5.1. The Abstract Class "PolicySet"..............................38
5.5. The Class "CompoundPolicyCondition".........................38 5.2. Update PCIM's Class "PolicyGroup"...........................39
5.6. The Class "CompoundFilterCondition".........................39 5.3. Update PCIM's Class "PolicyRule"............................39
5.7. The Class "SimplePolicyAction"..............................39 5.4. The Class "SimplePolicyCondition"...........................40
5.8. The Class "CompoundPolicyAction"............................40 5.5. The Class "CompoundPolicyCondition".........................41
5.9. The Abstract Class "PolicyVariable".........................41 5.6. The Class "CompoundFilterCondition".........................41
5.10. The Class "PolicyExplicitVariable".........................41 5.7. The Class "SimplePolicyAction"..............................42
5.10.1. The Single-Valued Property "ModelClass"..................42 5.8. The Class "CompoundPolicyAction"............................42
5.10.2. The Single-Valued Property ModelProperty.................42 5.9. The Abstract Class "PolicyVariable".........................43
5.11. The Abstract Class "PolicyImplicitVariable"................42 5.10. The Class "PolicyExplicitVariable".........................44
5.11.1. The Multi-Valued Property "ValueTypes"...................42 5.10.1. The Single-Valued Property "ModelClass"..................44
5.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe..43 5.10.2. The Single-Valued Property ModelProperty.................44
5.12.1. The Class "PolicySourceIPVariable".......................43 5.11. The Abstract Class "PolicyImplicitVariable"................44
5.12.2. The Class "PolicyDestinationIPVariable"..................43 5.11.1. The Multi-Valued Property "ValueTypes"...................45
5.12.3. The Class "PolicySourcePortVariable".....................43 5.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe..45
5.12.4. The Class "PolicyDestinationPortVariable"................44 5.12.1. The Class "PolicySourceIPv4Variable".....................45
5.12.5. The Class "PolicyIPProtocolVariable".....................44 5.12.2. The Class "PolicySourceIPv6Variable".....................45
5.12.6. The Class "PolicyIPVersionVariable"......................44 5.12.3. The Class "PolicyDestinationIPv4Variable"................45
5.12.7. The Class "PolicyIPToSVariable"..........................44 5.12.4. The Class "PolicyDestinationIPv6Variable"................46
5.12.8. The Class "PolicyDSCPVariable"...........................45 5.12.5. The Class "PolicySourcePortVariable".....................46
5.12.9. The Class "PolicySourceMACVariable"......................45 5.12.6. The Class "PolicyDestinationPortVariable"................46
5.12.10. The Class "PolicyDestinationMACVariable"................45 5.12.7. The Class "PolicyIPProtocolVariable".....................47
5.12.11. The Class "PolicyVLANVariable"..........................45 5.12.8. The Class "PolicyIPVersionVariable"......................47
5.12.12. The Class "PolicyCoSVariable"...........................46 5.12.9. The Class "PolicyIPToSVariable"..........................47
5.12.13. The Class "PolicyEthertypeVariable".....................46 5.12.10. The Class "PolicyDSCPVariable"..........................47
5.12.14. The Class "PolicySourceSAPVariable".....................46 5.12.11. The Class "PolicyFlowIdVariable"........................48
5.12.15. The Class "PolicyDestinationSAPVariable"................46 5.12.12. The Class "PolicySourceMACVariable".....................48
5.12.16. The Class "PolicySNAPVariable"..........................47 5.12.13. The Class "PolicyDestinationMACVariable"................48
5.12.17. The Class "PolicyFlowDirectionVariable".................47 5.12.14. The Class "PolicyVLANVariable"..........................48
5.13. The Abstract Class "PolicyValue"...........................47 5.12.15. The Class "PolicyCoSVariable"...........................49
5.14. Subclasses of "PolicyValue" Specified in PCIMe.............48 5.12.16. The Class "PolicyEthertypeVariable".....................49
5.14.1. The Class "PolicyIPv4AddrValue"..........................48 5.12.17. The Class "PolicySourceSAPVariable".....................49
5.14.2. The Class "PolicyIPv6AddrValue...........................49 5.12.18. The Class "PolicyDestinationSAPVariable"................49
5.14.3. The Class "PolicyMACAddrValue"...........................50 5.12.19. The Class "PolicySNAPVariable"..........................50
5.14.4. The Class "PolicyStringValue"............................50 5.12.20. The Class "PolicyFlowDirectionVariable".................50
5.14.5. The Class "PolicyBitStringValue".........................51 5.13. The Abstract Class "PolicyValue"...........................50
5.14.6. The Class "PolicyIntegerValue"...........................51 5.14. Subclasses of "PolicyValue" Specified in PCIMe.............51
5.14.7. The Class "PolicyBooleanValue"...........................52 5.14.1. The Class "PolicyIPv4AddrValue"..........................51
5.15. The Class "PolicyRoleCollection"...........................53 5.14.2. The Class "PolicyIPv6AddrValue...........................52
5.15.1. The Single-Valued Property "PolicyRole"..................53 5.14.3. The Class "PolicyMACAddrValue"...........................53
5.16. The Class "ReusablePolicyContainer"........................53 5.14.4. The Class "PolicyStringValue"............................53
5.17. Deprecation of PCIM's Class "PolicyRepository".............53 5.14.5. The Class "PolicyBitStringValue".........................54
6. Association and Aggregation Definitions..........................54 5.14.6. The Class "PolicyIntegerValue"...........................55
6.1. The Abstract Aggregation "PolicySetComponent"...............54 5.14.7. The Class "PolicyBooleanValue"...........................56
6.2. Update to PCIM's Aggregation "PolicyGroupInPolicyGroup".....54 5.15. The Class "PolicyRoleCollection"...........................56
6.3. Update to PCIM's Aggregation "PolicyRuleInPolicyGroup"......55 5.15.1. The Single-Valued Property "PolicyRole"..................56
6.4. The Aggregation "PolicyGroupInPolicyRule"...................55 5.16. The Class "ReusablePolicyContainer"........................56
6.5. The Aggregation "PolicyRuleInPolicyRule"....................56 5.17. Deprecate PCIM's Class "PolicyRepository"..................57
6.6. The Abstract Aggregation "CompoundedPolicyCondition"........56 6. Association and Aggregation Definitions..........................57
6.7. Update to PCIM's Aggregation "PolicyConditionInPolicyRule"..57 6.1. The Aggregation "PolicySetComponent"........................57
6.8. The Aggregation "PolicyConditionInPolicyCondition"..........57 6.2. Deprecate PCIM's Aggregation "PolicyGroupInPolicyGroup".....58
6.9. The Abstract Aggregation "CompoundedPolicyAction"...........57 6.3. Deprecate PCIM's Aggregation "PolicyRuleInPolicyGroup"......58
6.10. Update to PCIM's Aggregation "PolicyActionInPolicyRule"....57 6.4. The Abstract Association "PolicySetInSystem"................58
6.11. The Aggregation "PolicyActionInPolicyAction"...............58 6.5. Update PCIM's Weak Association "PolicyGroupInSystem"........59
6.12. The Aggregation "PolicyVariableInSimplePolicyCondition"....58 6.6. Update PCIM's Weak Association "PolicyRuleInSystem".........60
6.13. The Aggregation "PolicyValueInSimplePolicyCondition".......59 6.7. The Abstract Aggregation "CompoundedPolicyCondition"........60
6.14. The Aggregation "PolicyVariableInSimplePolicyAction".......59 6.8. Update PCIM's Aggregation "PolicyConditionInPolicyRule".....60
6.15. The Aggregation "PolicyValueInSimplePolicyAction"..........60 6.9. The Aggregation "PolicyConditionInPolicyCondition"..........61
6.16. The Association "ReusablePolicy"...........................61 6.10. The Abstract Aggregation "CompoundedPolicyAction"..........61
6.17. Deprecate PCIM's "PolicyConditionInPolicyRepository".......61 6.11. Update PCIM's Aggregation "PolicyActionInPolicyRule".......61
6.18. Deprecate PCIM's "PolicyActionInPolicyRepository"..........61 6.12. The Aggregation "PolicyActionInPolicyAction"...............61
6.19. The Association PolicyValueConstraintInVariable............61 6.13. The Aggregation "PolicyVariableInSimplePolicyCondition"....62
6.20. The Aggregation "PolicyContainerInPolicyContainer".........62 6.14. The Aggregation "PolicyValueInSimplePolicyCondition".......62
6.21. Deprecate PCIM's "PolicyRepositoryInPolicyRepository"......62 6.15. The Aggregation "PolicyVariableInSimplePolicyAction".......63
6.22. The Aggregation "ElementInPolicyRoleCollection"............63 6.16. The Aggregation "PolicyValueInSimplePolicyAction"..........64
6.22.1. The Weak Association "PolicyRoleCollectionInSystem"......63 6.17. The Association "ReusablePolicy"...........................64
7. Intellectual Property............................................64 6.18. Deprecate PCIM's "PolicyConditionInPolicyRepository".......65
8. Acknowledgements.................................................64 6.19. Deprecate PCIM's "PolicyActionInPolicyRepository"..........65
9. Security Considerations..........................................64 6.20. The Association PolicyValueConstraintInVariable............65
10. References......................................................64 6.21. The Aggregation "PolicyContainerInPolicyContainer".........66
11. Authors' Addresses..............................................65 6.22. Deprecate PCIM's "PolicyRepositoryInPolicyRepository"......66
12. Full Copyright Statement........................................67 6.23. The Aggregation "ElementInPolicyRoleCollection"............66
13. Appendix A: Open Issues.........................................67 6.24. The Weak Association "PolicyRoleCollectionInSystem"........67
7. Intellectual Property............................................67
8. Acknowledgements.................................................68
9. Security Considerations..........................................68
10. References......................................................68
11. Authors' Addresses..............................................69
12. Full Copyright Statement........................................70
13. Appendix A: Open Issues.........................................71
1. Introduction 1. Introduction
This document (PCIM Extensions, abbreviated here to PCIMe) proposes a This document (PCIM Extensions, abbreviated here to PCIMe) proposes a
number of changes to the Policy Core Information Model (PCIM, RFC 3060 number of changes to the Policy Core Information Model (PCIM, RFC 3060
[3]). These changes include both extensions of PCIM into areas that it [3]). These changes include both extensions of PCIM into areas that it
did not previously cover, and changes to the existing PCIM classes and did not previously cover, and changes to the existing PCIM classes and
associations. Both sets of changes are done in a way that, to the extent associations. Both sets of changes are done in a way that, to the extent
possible, preserves interoperability with implementations of the original possible, preserves interoperability with implementations of the original
PCIM model. PCIM model.
EDITOR'S NOTE: In its -01 release, this document is still at a
preliminary stage of development. Elements may be added and/or elements
may be removed prior to the document's advancement to Proposed Standard.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119, reference [1]. document are to be interpreted as described in RFC 2119, reference [1].
2. Overview of the Changes 2. Overview of the Changes
2.1. How to Change an Information Model 2.1. How to Change an Information Model
The Policy Core Information Model is closely aligned with the DMTF's CIM The Policy Core Information Model is closely aligned with the DMTF's CIM
Core Policy model. Since there is no separately documented set of rules Core Policy model. Since there is no separately documented set of rules
skipping to change at page 5, line 40 skipping to change at page 5, line 51
associations. associations.
As a separate change, the associations for ReusablePolicyContainer are As a separate change, the associations for ReusablePolicyContainer are
being broadened, to allow a ReusablePolicyContainer to contain any being broadened, to allow a ReusablePolicyContainer to contain any
reusable policy elements. In PCIM, the only associations defined for a reusable policy elements. In PCIM, the only associations defined for a
PolicyRepository were for it to contain reusable policy conditions and PolicyRepository were for it to contain reusable policy conditions and
policy actions. policy actions.
2.2.2. Additional Associations and Additional Reusable Elements 2.2.2. Additional Associations and Additional Reusable Elements
The PolicyRuleInPolicyRule and PolicyGroupInPolicyRule aggregations are The PolicyRuleInPolicyRule and PolicyGroupInPolicyRule aggregations are,
being imported from QPIM. These associations make it possible to define in effect, being imported from QPIM. ("In effect" because these two
larger "chunks" of reusable policy to place in a ReusablePolicyContainer. aggregations, as well as PCIM'e two aggregations PolicyGroupInPolicyGroup
These aggregations also introduce new semantics representing the and PolicyRuleInPolicyGroup, are all being combined into a single
contextual implications of having one PolicyRule executing within the aggregation PolicySetComponent.) These aggregations make it possible to
scope of another PolicyRule. define larger "chunks" of reusable policy to place in a
ReusablePolicyContainer. These aggregations also introduce new semantics
representing the contextual implications of having one PolicyRule
executing within the scope of another PolicyRule.
2.2.3. Priorities and Decision Strategies 2.2.3. Priorities and Decision Strategies
Drawing from both QPIM and ICIM, the Priority property is being Drawing from both QPIM and ICIM, the Priority property is being
deprecated in PolicyRule, and placed instead on the aggregations deprecated in PolicyRule, and placed instead on the aggregation
PolicyRuleInPolicyGroup, PolicyGroupInPolicyGroup, PolicySetComponent. The QPIM rules for resolving relative priorities
PolicyGroupInPolicyRule, and PolicyRuleInPolicyRule. (This is across nested PolicyGroups and PolicyRules are being incorporated into
accomplished by placing the Priority property on the abstract aggregation PCIMe as well. With the removal of the Priority property from
PolicySetComponent, from which these four aggregations are derived.) The PolicyRule, a new modeling dependency is introduced: in order to
QPIM rules for resolving relative priorities across nested PolicyGroups prioritize a PolicyRule relative to other PolicyRules, the rules must be
and PolicyRules are being incorporated into PCIMe as well. With the placed in either a common PolicyGroup or a common PolicyRule.
removal of the Priority property from PolicyRule, a new modeling
dependency is introduced: in order to prioritize a PolicyRule relative to
other PolicyRules, the rules must be placed in either a common
PolicyGroup or a common PolicyRule.
In the absence of any clear, general criterion for detecting policy In the absence of any clear, general criterion for detecting policy
conflicts, the PCIM restriction stating that priorities are relevant only conflicts, the PCIM restriction stating that priorities are relevant only
in the case of conflicts is being removed. In its place, a in the case of conflicts is being removed. In its place, a
PolicyDecisionStrategy property is being added to the PolicyGroup and PolicyDecisionStrategy property is being added to the PolicyGroup and
PolicyRule classes, to allow the policy administrator to select one of PolicyRule classes, to allow the policy administrator to select one of
two behaviors with respect to rule evaluation: either perform the actions two behaviors with respect to rule evaluation: either perform the actions
for all PolicyRules whose conditions evaluate to TRUE, or perform the for all PolicyRules whose conditions evaluate to TRUE, or perform the
actions only for the highest-priority PolicyRule whose conditions actions only for the highest-priority PolicyRule whose conditions
evaluate to TRUE. (Once again this is accomplished by placing the evaluate to TRUE. (This is accomplished by placing the
PolicyDecisionStrategy property in an abstract class PolicySet, from PolicyDecisionStrategy property in an abstract class PolicySet, from
which PolicyGroup and PolicyRule are derived.) The QPIM rules for which PolicyGroup and PolicyRule are derived.) The QPIM rules for
applying decision strategies to a nested set of PolicyGroups and applying decision strategies to a nested set of PolicyGroups and
PolicyRules are also being imported. PolicyRules are also being imported.
2.2.4. Policy Roles 2.2.4. Policy Roles
The concept of policy roles is added to PolicyGroups (being present The concept of policy roles is added to PolicyGroups (being present
already in the PolicyRule class). This is accomplished via a new already in the PolicyRule class). This is accomplished via a new
superclass for both PolicyRules and PolicyGroups - PolicySets. For superclass for both PolicyRules and PolicyGroups - PolicySets. For
skipping to change at page 7, line 24 skipping to change at page 7, line 34
defined, as well as a list of PCIMe-level values. Other variables and defined, as well as a list of PCIMe-level values. Other variables and
values may, if necessary, be defined in submodels of PCIMe. values may, if necessary, be defined in submodels of PCIMe.
A corresponding SimplePolicyAction / PolicyVariable / PolicyValue A corresponding SimplePolicyAction / PolicyVariable / PolicyValue
structure is also defined. While the semantics of a structure is also defined. While the semantics of a
SimplePolicyCondition are "variable matches value", a SimplePolicyAction SimplePolicyCondition are "variable matches value", a SimplePolicyAction
has the semantics "set variable to value". has the semantics "set variable to value".
2.2.7. Packet Filtering 2.2.7. Packet Filtering
For packet filtering done in the context of a PolicyCondition, a set of For packet filtering specified at the domain level, a set of
PolicyVariables and PolicyValues are defined, corresponding to the fields PolicyVariables and PolicyValues are defined, corresponding to the fields
in an IP packet header plus the most common Layer 2 frame header fields. in an IP packet header plus the most common Layer 2 frame header fields.
It is expected that policy conditions that filter on these header fields It is expected that domain-level policy conditions that filter on these
will be expressed in terms of CompoundPolicyConditions built up from header fields will be expressed in terms of CompoundPolicyConditions
SimplePolicyConditions that use these variables and values. An built up from SimplePolicyConditions that use these variables and values.
additional PolicyVariable, PacketDirection, is also defined, to indicate An additional PolicyVariable, PacketDirection, is also defined, to
whether a packet being filtered is traveling inbound or outbound on an indicate whether a packet being filtered is traveling inbound or outbound
interface. on an interface.
For packet filtering in other contexts (specifically, for the packet For packet filtering expressed at the device level, including the packet
classifier filters modeled in QDDIM), these variables and values need not classifier filters modeled in QDDIM, these variables and values need not
be used. Filter classes derived from the CIM FilterEntryBase class be used. Filter classes derived from the CIM FilterEntryBase class
hierarchy may still be used in these contexts. hierarchy may still be used in these contexts.
3. The Updated Class and Association Class Hierarchies 3. The Updated Class and Association Class Hierarchies
The following figure shows the class inheritance hierarchy for PCIMe. The following figure shows the class inheritance hierarchy for PCIMe.
Changes from the PCIM hierarchy are noted parenthetically. Changes from the PCIM hierarchy are noted parenthetically.
ManagedElement (abstract) ManagedElement (abstract)
| |
skipping to change at page 8, line 48 skipping to change at page 8, line 48
| | | | | |
| | +---PolicyImplicitVariable (abstract -- new - 4.8.7) | | +---PolicyImplicitVariable (abstract -- new - 4.8.7)
| | | | | |
| | +---(subtree of more specific classes -- new - 5.12) | | +---(subtree of more specific classes -- new - 5.12)
| | | |
| +---PolicyValue (abstract -- new - 4.8.10) | +---PolicyValue (abstract -- new - 4.8.10)
| | | |
| +---(subtree of more specific classes -- new - 5.14) | +---(subtree of more specific classes -- new - 5.14)
| |
+--Collection (abstract -- newly referenced) +--Collection (abstract -- newly referenced)
| | |
+--PolicyRoleCollection (new - 4.6.2) | +--PolicyRoleCollection (new - 4.6.2)
(continued on following page) (continued on following page)
(continued from previous page) (continued from previous page)
ManagedElement(abstract) ManagedElement(abstract)
| |
+--ManagedSystemElement (abstract) +--ManagedSystemElement (abstract)
| |
+--LogicalElement (abstract) +--LogicalElement (abstract)
| |
+--System (abstract) +--System (abstract)
| |
skipping to change at page 10, line 11 skipping to change at page 10, line 11
+---PolicyRepository (deprecated - 4.2) +---PolicyRepository (deprecated - 4.2)
Figure 1. Class Inheritance Hierarchy for PCIMe Figure 1. Class Inheritance Hierarchy for PCIMe
The following figure shows the association class hierarchy for PCIMe. As The following figure shows the association class hierarchy for PCIMe. As
before, changes from PCIM are noted parenthetically. before, changes from PCIM are noted parenthetically.
[unrooted] [unrooted]
| |
+---PolicyComponent (abstract) +---PolicyComponent (abstract)
| | | |
| +---PolicySetComponent (abstract -- new - 4.3) | +---PolicySetComponent (new - 4.3)
| | | | |
| | +---PolicyGroupInPolicyGroup (moved - 4.3) | +---PolicyGroupInPolicyGroup (deprecated - 4.3)
| | | | |
| | +---PolicyRuleInPolicyGroup (moved - 4.3) | +---PolicyRuleInPolicyGroup (deprecated - 4.3)
| | |
| | +---PolicyGroupInPolicyRule (new - 4.3)
| | |
| | +---PolicyRuleInPolicyRule (new - 4.3)
| | | |
| +---CompoundedPolicyCondition (abstract -- new - 4.7.1) | +---CompoundedPolicyCondition (abstract -- new - 4.7.1)
| | | | | |
| | +---PolicyConditionInPolicyRule (moved - 4.7.1) | | +---PolicyConditionInPolicyRule (moved - 4.7.1)
| | | | | |
| | +---PolicyConditionInPolicyCondition (new - 4.7.1) | | +---PolicyConditionInPolicyCondition (new - 4.7.1)
| | | |
| +---PolicyRuleValidityPeriod | +---PolicyRuleValidityPeriod
| | | |
| +---CompoundedPolicyAction (abstract -- new - 4.7.2) | +---CompoundedPolicyAction (abstract -- new - 4.7.2)
skipping to change at page 11, line 11 skipping to change at page 11, line 11
| +---PolicyValueInSimplePolicyAction (new - 4.8.4) | +---PolicyValueInSimplePolicyAction (new - 4.8.4)
(continued on following page) (continued on following page)
(continued from previous page) (continued from previous page)
[unrooted] [unrooted]
| |
+---Dependency (abstract) +---Dependency (abstract)
| | | |
| +---PolicyInSystem (abstract) | +---PolicyInSystem (abstract)
| | | | | |
| | +---PolicyGroupInSystem | | +---PolicySetInSystem (abstract, new - 4.3)
| | | | | | |
| | +---PolicyRuleInSystem | | | +---PolicyGroupInSystem
| | | |
| | | +---PolicyRuleInSystem
| | | | | |
| | +---ReusablePolicy (new - 4.2) | | +---ReusablePolicy (new - 4.2)
| | | | | |
| | +---PolicyConditionInPolicyRepository (deprecated - 4.2) | | +---PolicyConditionInPolicyRepository (deprecated - 4.2)
| | | | | |
| | +---PolicyActionInPolicyRepository (deprecated - 4.2) | | +---PolicyActionInPolicyRepository (deprecated - 4.2)
| | | |
| +---PolicyValueConstraintInVariable (new - 4.8) | +---PolicyValueConstraintInVariable (new - 4.8)
| | | |
| +---PolicyRoleCollectionInSystem (new - 4.6.2) | +---PolicyRoleCollectionInSystem (new - 4.6.2)
skipping to change at page 11, line 50 skipping to change at page 12, line 5
class level, there are other changes from PCIM involving individual class class level, there are other changes from PCIM involving individual class
properties. In some cases new properties are introduced into existing properties. In some cases new properties are introduced into existing
classes, and in other cases existing properties are deprecated (without classes, and in other cases existing properties are deprecated (without
deprecating the classes that contain them). deprecating the classes that contain them).
4. Areas of Extension to PCIM 4. Areas of Extension to PCIM
The following subsections describe each of the areas for which PCIM The following subsections describe each of the areas for which PCIM
extensions are being defined. extensions are being defined.
4.1. Scope of Policies: Domain Policies and Device Policies 4.1. Policy Scope
Policy scopes may be thought of in two dimensions: 1) the level of
abstraction of the policy specification and 2) the applicability of
policies to a set of managed resources.
4.1.1. Levels of Abstraction: Domain- and Device-Level Policies
Policies vary in level of abstraction, from the business-level expression Policies vary in level of abstraction, from the business-level expression
of service level agreements (SLAs) to the specification of a set of rules of service level agreements (SLAs) to the specification of a set of rules
that apply to devices in a network. Those latter policies can, that apply to devices in a network. Those latter policies can,
themselves, be classified into at least two groups: those policies themselves, be classified into at least two groups: those policies
consumed by a Policy Decision Point (PDP) that specify the rules for an consumed by a Policy Decision Point (PDP) that specify the rules for an
administrative and functional domain, and those policies consumed by a administrative and functional domain, and those policies consumed by a
Policy Enforcement Point (PEP) that specify the device-specific rules for Policy Enforcement Point (PEP) that specify the device-specific rules for
a functional domain. The higher-level rules consumed by a PDP may have a functional domain. The higher-level rules consumed by a PDP, called
late binding variables unspecified, or specified by a classification, domain-level policies, may have late binding variables unspecified, or
whereas the device-level rules are likely to have fewer unresolved specified by a classification, whereas the device-level rules are likely
bindings. to have fewer unresolved bindings.
There is a relationship between these levels of policy specification that There is a relationship between these levels of policy specification that
is out of scope for this standards effort, but that is necessary in the is out of scope for this standards effort, but that is necessary in the
development and deployment of a usable policy-based configuration system. development and deployment of a usable policy-based configuration system.
An SLA-level policy transformation to the domain-level policy may be An SLA-level policy transformation to the domain-level policy may be
thought of as analogous to a visual builder that takes human input and thought of as analogous to a visual builder that takes human input and
develops a programmatic rule specification. The relationship between the develops a programmatic rule specification. The relationship between the
domain-level policy and the device-level policy may be thought of as domain-level policy and the device-level policy may be thought of as
analogous to that of a compiler and linkage editor that translates the analogous to that of a compiler and linkage editor that translates the
rules into specific instructions that can be executed on a specific type rules into specific instructions that can be executed on a specific type
of platform. of platform.
The policy core information model may be used to specify rules at any and The policy core information model may be used to specify rules at any and
all of these levels of abstraction. However, at different levels of all of these levels of abstraction. However, at different levels of
abstraction, different mechanisms may be more or less appropriate. abstraction, different mechanisms may be more or less appropriate.
4.1.2. Administrative and Functional Scopes
Administrative scopes for policy are represented in PCIM and in these
extensions to PCIM as System subclass instances. Typically, a domain-
level policy would be scoped by an AdminDomain instance (or by a
hierarchy of AdminDomain instances) whereas a device-level policy might
be scoped by a System instance that represents the PEP (e.g.,
ComputerSystem, see CIM [4]). In addition to collecting policies into an
administrative domain, these System classes may also aggregate the
resources to which the policies apply.
Functional scopes (sometimes referred to as functional domains) are
generally defined by the derivation from the policy framework and
correspond to the service or services to which the policies apply. So,
for example, Quality of Service may be thought of as a functional scope
or Diffserv and Intserv may each be thought of as functional scopes,
these scoping decisions are made by the derivation of the framework and
may be reflected in the number and types of PEP policy client(s),
services and the interaction between policies. Policies in different
functional scopes are organized in disjoint sets of policy rules.
Different functional domains may share the use of some roles, some
conditions, and even some actions. The rules from different functional
domains may even be enforced at the same managed resource but for the
purposes of policy evaluation they are separate. See section 4.5 for
more information.
The functional scopes MAY be reflected in administrative scopes. That
is, deployments of policy may have different administrative scopes for
different functional scopes, but there is no requirement to do so.
4.2. Reusable Policy Elements 4.2. Reusable Policy Elements
In PCIM, a distinction was drawn between reusable PolicyConditions and In PCIM, a distinction was drawn between reusable PolicyConditions and
PolicyActions and rule-specific ones. The PolicyRepository class was PolicyActions and rule-specific ones. The PolicyRepository class was
also defined, to serve as a container for these reusable elements. The also defined, to serve as a container for these reusable elements. The
name "PolicyRepository" has proven to be an unfortunate choice for the name "PolicyRepository" has proven to be an unfortunate choice for the
class that serves as a container for reusable policy elements. This term class that serves as a container for reusable policy elements. This term
is already used in documents like the Policy Framework, to denote the is already used in documents like the Policy Framework, to denote the
location from which the PEP retrieves all policy specifications, and into location from which the PEP retrieves all policy specifications, and into
which the Policy Management Tool places all policy specifications. which the Policy Management Tool places all policy specifications.
skipping to change at page 13, line 33 skipping to change at page 14, line 25
the inheritance hierarchy above both PolicyGroup and PolicyRule. This the inheritance hierarchy above both PolicyGroup and PolicyRule. This
reflects the additional structure flexibility and semantic capability of reflects the additional structure flexibility and semantic capability of
both subclasses. both subclasses.
Two properties are defined in PolicySet: PolicyDecisionStrategy and Two properties are defined in PolicySet: PolicyDecisionStrategy and
PolicyRoles. PolicyDecisionStrategy is added to PolicySet to define the PolicyRoles. PolicyDecisionStrategy is added to PolicySet to define the
evaluation relationship between the rules in the policy set. See section evaluation relationship between the rules in the policy set. See section
4.5 for more information. PolicyRoles is added to PolicySet to name the 4.5 for more information. PolicyRoles is added to PolicySet to name the
retrieval sets. See section 4.6 for more information. retrieval sets. See section 4.6 for more information.
Along with the definition of the PolicySet class, a new abstract Along with the definition of the PolicySet class, a new concrete
aggregation class is defined that will also be discussed in the following aggregation class is defined that will also be discussed in the following
sections. PolicySetComponent is defined as a subclass of sections. PolicySetComponent is defined as a subclass of
PolicyComponent; it provides the containment relationship for a PolicyComponent; it provides the containment relationship for a PolicySet
PolicySet. PolicyGroupInPolicyGroup and PolicyRuleInPolicyGroup are in a PolicySet. PolicySetComponent replaces the two PCIM aggregations
modified to subclass from PolicySetComponent. PolicyGroupInPolicyRule PolicyGroupInPolicyGroup and PolicyRuleInPolicyGroup, so these two
and PolicyRuleInPolicyRule, discussed in the next section, are also aggregations are deprecated.
defined as subclasses of PolicySetComponent.
The PolicySet relationship to an AdminDomain or other administrative
scoping system (e.g., a ComputerSystem) is defined in the
PolicySetInSystem abstract association. This new association is derived
from PolicyInSystem, and the PolicyGroupInSystem and PolicyRuleInSystem
associations are now derived from PolicySetInSystem instead of directly
from PolicyInSystem. The PolicySetInSystem.Priority property is
discussed in section 4.5.
4.4. Nested Policy Rules 4.4. Nested Policy Rules
As previously discussed, policy is described by a set of policy rules As previously discussed, policy is described by a set of policy rules
that may be grouped into subsets. In this section we introduce the that may be grouped into subsets. In this section we introduce the
notion of nested rules, or the ability to define rules within rules. notion of nested rules, or the ability to define rules within rules.
Nested rules are also called sub-rules, and we use both terms in this Nested rules are also called sub-rules, and we use both terms in this
document interchangeably. Two new aggregations are defined for this document interchangeably. The aggregation PolicySetComponent is used to
purpose: PolicyRuleInPolicyRule and PolicyGroupInPolicyRule. represent the nesting of a policy rule in another policy rule.
4.4.1. Usage Rules for Nested Rules 4.4.1. Usage Rules for Nested Rules
The relationship between rules and sub-rules is defined as follows: The relationship between rules and sub-rules is defined as follows:
o The parent rule's condition clause is a pre-condition for o The parent rule's condition clause is a pre-condition for
evaluation of all nested rules. If the parent rule's condition evaluation of all nested rules. If the parent rule's condition
clause evaluates to FALSE, all sub-rules SHALL be skipped and clause evaluates to FALSE, all sub-rules SHALL be skipped and
their condition clauses SHALL NOT be evaluated. their condition clauses SHALL NOT be evaluated.
o If the parent rule's condition evaluates to TRUE, the set of sub- o If the parent rule's condition evaluates to TRUE, the set of sub-
rules SHALL BE executed according to the decision strategy and rules SHALL BE executed according to the decision strategy and
priorities as discussed in Section 4.5. priorities as discussed in Section 4.5.
o If the parent rule's condition evaluates to TRUE, the parent o If the parent rule's condition evaluates to TRUE, the parent
rule's set of actions is executed BEFORE the evaluation and rule's set of actions is executed BEFORE execution of the sub-
execution of the sub-rules. The parent rule's actions are not to rules actions. The parent rule's actions are not to be confused
be confused with default actions. A default action is one that is with default actions. A default action is one that is to be
to be executed only if none of the more specific sub-rules are executed only if none of the more specific sub-rules are executed.
executed. If a default action needs to be specified, it needs to If a default action needs to be specified, it needs to be defined
be defined as an action that is part of a catchall sub-rule as an action that is part of a catchall sub-rule associated with
associated with the parent rule. The association linking the the parent rule. The association linking the default action(s) in
default action(s) in this special sub-rule should have the lowest this special sub-rule should have the lowest priority relative to
priority relative to all other sub-rule associations: all other sub-rule associations:
if precondition then parent rule's action if precondition then parent rule's action
if condA then actA if condA then actA
if condB then ActB if condB then ActB
if True then default action if True then default action
Default actions have meaning when FirstMatching decision Default actions have meaning when FirstMatching decision
strategies are in effect (see section 4.5). strategies are in effect (see section 4.5).
o Policy rules have an implicit context in which they are executed. o Policy rules have an implicit context in which they are executed.
skipping to change at page 15, line 4 skipping to change at page 16, line 4
constructed from multiple simpler policy rules. These enhancements ease constructed from multiple simpler policy rules. These enhancements ease
the policy management tools' task, allowing policy rules to be expressed the policy management tools' task, allowing policy rules to be expressed
in a way closer to how humans think. in a way closer to how humans think.
Sub-rules enable the policy designer to define a hierarchy of rules. Sub-rules enable the policy designer to define a hierarchy of rules.
This hierarchy has the property that sub-rules can be scoped by their This hierarchy has the property that sub-rules can be scoped by their
parent rules. This scoping, or context of evaluation and execution, is a parent rules. This scoping, or context of evaluation and execution, is a
powerful tool in enabling the policy designer to obtain the fine-grained powerful tool in enabling the policy designer to obtain the fine-grained
control needed to appropriately manage resources for certain control needed to appropriately manage resources for certain
applications. The example in the following section demonstrates that applications. The example in the following section demonstrates that
expressing relative bandwidth allocation rules can be done very naturally expressing relative bandwidth allocation rules can be done naturally
using a hierarchical rule structure. using a hierarchical rule structure.
Rule nesting can be used to optimize the way policy rules are evaluated Rule nesting can be used to optimize the way policy rules are evaluated
and executed. Once the parent rule's condition clause is evaluated to and executed. Once the parent rule's condition clause is evaluated to
FALSE, all sub-rules are skipped, optimizing the number of lookups FALSE, all sub-rules are skipped, optimizing the number of lookups
required. Note that this is not the prime reason for rule nesting, but required. Note that this is not the prime reason for rule nesting, but
rather a side benefit. Optimization of rule execution can be done in the rather a side benefit. Optimization of rule execution can be done in the
PDP or in the PEP by dedicated code. This is similar to the relation PDP or in the PEP by dedicated code. This is similar to the relation
between a high level programming language like C and machine code. An between a high level programming language like C and machine code. An
optimizer can create a more efficient machine code than any optimization optimizer can create a more efficient machine code than any optimization
done by the programmer within the source code. Nevertheless, if the PEP done by the programmer within the source code. Nevertheless, if the PEP
or PDP does not do optimization, the administrator writing the policy can or PDP does not do optimization, the administrator writing the policy can
optimize the policy rules for execution using rule nesting. optimize the policy rules for execution using rule nesting.
In a model where condition evaluation may have side effects, nesting Evaluation of some conditions does not require simple examination of a
rules allow control of condition evaluation, as sub-rule conditions SHALL field within a packet. For example, condition evaluation may require a
NOT be evaluated if the condition of the parent rule evaluates to FALSE. PDP (or a PEP) to access an external database (e.g., a directory), query
an external PDP (e.g., Kerberos) or possibly investigate a state within
the network (e.g., issue an SNMP query). These non-local condition
evaluations should be minimized, as they cause delay in rule evaluation,
load the network and other resources, and may have undesirable side
effects.
Nested rules are not designed for policy repository retrieval Nested rules are not designed for policy repository retrieval
optimization. It is assumed that all rules and groups that are assigned optimization. It is assumed that all rules and groups that are assigned
to a role are retrieved by the PDP or PEP from the policy repository and to a role are retrieved by the PDP or PEP from the policy repository and
enforced. Optimizing the number of rules retrieved should be done by enforced. Optimizing the number of rules retrieved should be done by
clever selection of roles. clever selection of roles.
4.4.3. Usage Example 4.4.3. Usage Example
This section provides a usage example that aims to clarify the motivation This section provides a usage example that aims to clarify the motivation
for the definition of rule nesting and the use of the relative context. for the definition of rule nesting and the use of the relative context.
Consider the following example, where a set of rules is used to specify Consider the following example, where a set of rules is used to specify
the minimal bandwidth allocations on an interface. The policy reads: the minimal bandwidth allocations on an interface. The policy reads:
On any interface on which these rules apply, allocate at On any interface on which these rules apply, guarantee at least
least 30% of the interface bandwidth to UDP flows, and at 30% of the interface bandwidth to UDP flows, and at least 40% of
least 40% of the interface bandwidth to TCP flows. the interface bandwidth to TCP flows.
This single rule is translated to a set of two rules: When formatted in the condition and action rule structure, the policy
reads:
If (IP protocol is UDP) THEN Set MinBW to 30% (1) If (IP protocol is UDP) THEN (guarantee 30% of available BW) (1)
If (IP protocol is TCP) THEN Set MinBW to 40% (2) If (IP protocol is TCP) THEN (guarantee 40% of available BW) (2)
Now, let's add some sub-rules to further differentiate how bandwidth Now, let's add some sub-rules to further differentiate how bandwidth
should be allocated to specific UDP and TCP applications (indentation should be allocated to specific UDP and TCP applications (indentation
indicates rule nesting): indicates rule nesting):
If (IP protocol is UDP) THEN Set MinBW to 30% (1) If (IP protocol is UDP) THEN (guarantee 30% of available BW) (1)
If (protocol is TFTP) THEN Set MinBW to 10% (1a) If (protocol is TFTP) (guarantee 10% of available BW) (1a)
If (protocol is NFS) THEN Set MinBW to 40% (1b) If (protocol is NFS) THEN (guarantee 40% of available BW) (1b)
If (IP protocol is TCP) THEN Set MinBW to 40% (2) If (IP protocol is TCP) THEN (guarantee 40% of available BW) (2)
If (protocol is HTTP) THEN Set MinBW to 20% (2a) If (protocol is HTTP) THEN guarantee 20% of available BW) (2a)
If (protocol is FTP) THEN Set MinBW to 30% (2b) If (protocol is FTP) THEN (guarantee 30% of available BW) (2b)
This means that for UDP flows, TFTP should be allocated 10% of the
bandwidth while NFS should be allocated 40%. For TCP flows, HTTP should The UDP sub-rules specify that TFTP should be allocated 10% of the
be allocated 20% of the bandwidth while FTP should be allocated 30%. bandwidth allocated to UDP while NFS should be allocated 40% of the UDP
portion. For TCP flows, HTTP should be allocated 20% of the TCP
bandwidth while FTP should be allocated 30%.
The context of each of the two high-level rules (those marked (1) and (2) The context of each of the two high-level rules (those marked (1) and (2)
above) is all flows running on an interface. The two sub-rules of the above) is all flows running on an interface. The two sub-rules of the
UDP rule, marked (1a) and (1b) above specify a more granular context: UDP rule, marked (1a) and (1b) above specify a more granular context:
within UDP flows, TFTP should be allocated 10% of the bandwidth while NFS within UDP flows, TFTP should be allocated 10% of the bandwidth while NFS
should be allocated 40%. The context of these sub-rules is therefore UDP should be allocated 40%. The context of these sub-rules is therefore UDP
flows only. Similar functionality applies for the hierarchy of rules flows only. Similar functionality applies for the hierarchy of rules
treating TCP flows. treating TCP flows.
A context hierarchy enhances reusability. The rules that divide A context hierarchy enhances reusability. The rules that divide
bandwidth between TFTP and NFS can be re-used and associated to rules bandwidth between TFTP and NFS can be re-used and associated to rules
that allocate different percentages of the bandwidth for different that allocate different percentages of the bandwidth for different
interfaces (or even for the same interface, but under different interfaces (or even for the same interface, but under different
conditions) for UDP. conditions) for UDP.
This set of rules can be implemented using a hierarchical scheduler.
Classifiers map TFTP packets to one queue, NFS packets to a second queue
and the rest of UDP packets to the third queue. The first (UDP)
scheduler assigns weights to each queue according to the guaranteed
bandwidth percentages defined in sub-rules (1a) and (1b).
The second scheduler similarly assigns weights to 3 other queues
according to the guaranteed bandwidth percentages defined in sub-rules
(2a) and (2b). The UDP scheduler places packets into a UDP output queue.
The TCP scheduler places packets on a TCP output queue. The rest of the
traffic is placed on a third queue. A scheduler extracts packets from
each of these three queues for transmission. The UDP queue is assigned a
30% weight according to rule (1), while the TCP queue is assigned a 40%
weight according to rule (2).
This example shows how rule nesting helps in specifying policy without
the need to describe the mechanisms (queues and schedulers) used to
implement it. The rule specification allows the policy administrator to
express the policies he or she wants to enforce on the domain, and allows
the PDP or the PEP to map these policies to its mechanisms. This is an
example of a mapping between a rule based policy information model and a
data path model [QDDIM].
4.5. Priorities and Decision Strategies 4.5. Priorities and Decision Strategies
A "decision strategy" is used to specify the evaluation method for the A "decision strategy" is used to specify the evaluation method for the
policies in a PolicySet. Two decision strategies are defined: policies in a PolicySet. Two decision strategies are defined:
"FirstMatching" and "AllMatching." The FirstMatching strategy is used to "FirstMatching" and "AllMatching." The FirstMatching strategy is used to
cause the evaluation of the rules in a set such that the actions of only cause the evaluation of the rules in a set such that the only actions
the first rule that matches are enforced on a given examination of the enforced on a given examination of the PolicySet are those for the first
PolicySet. The AllMatching strategy is used to cause the evaluation of rule (that is, the rule with the highest priority) that has its
all rules in a set; for all of the rules that match, the actions are conditions evaluate to TRUE. The AllMatching strategy is used to cause
enforced. (Strawman: Implementations MUST support the FirstMatching the evaluation of all rules in a set; for all of the rules whose
decision strategy; implementations MAY support the AllMatching decision conditions evaluate to TRUE, the actions are enforced. Implementations
strategy.) MUST support the FirstMatching decision strategy; implementations MAY
support the AllMatching decision strategy.
As previously discussed, the PolicySet subclasses are PolicyGroup and As previously discussed, the PolicySet subclasses are PolicyGroup and
PolicyRule, and either subclass may contain PolicySets of either PolicyRule: either subclass may contain PolicySets of either subclass.
subclass. Loops, including the degenerate case of a PolicySet that Loops, including the degenerate case of a PolicySet that contains itself,
contains itself, are not allowed when PolicySets contain other are not allowed when PolicySets contain other PolicySets. The
PolicySets. The containment relationship is specified using the containment relationship is specified using the PolicySetComponent
PolicySetComponent subclasses: PolicyGroupInPolicyGroup, aggregation.
PolicyRuleInPolicyGroup, PolicyGroupInPolicyRule and
PolicyRuleInPolicyRule.
The order of evaluation within a PolicySet is established by the Priority The relative priority within a PolicySet is established by the Priority
property of the PolicySetComponent aggregation. Instances of the property of the PolicySetComponent aggregation of contained PolicyGroup
subclasses of PolicySetComponent specify the relative priority of the and PolicyRule instances. The use of PCIM's PolicyRule.Priority property
contained policy groups and rules within the containing group or rule. is deprecated in favor of this new property. The separation of the
The use of PCIM's PolicyRule.Priority property is deprecated in favor of priority property from the rule has two advantages. First, it
this new property. The separation of the priority property from the rule generalizes the concept of priority, so it can be used for both groups
has two advantages. First, it generalizes the concept of priority, so it and rules; and, second, it places the priority on the relationship
can be used for both groups and rules; and, second, it places the between the parent policy set and the subordinate policy group or rule.
priority on the relationship between the parent policy set and the The assignment of a priority value, then, becomes much easier in that the
subordinate policy group or rule. The assignment of a priority value, value is used only in relationship to other priorities in the same set.
then, becomes much easier in that the value is used only in relationship
to other priorities in the same set.
Together, the PolicySet.PolicyDecisionStrategy and Together, the PolicySet.PolicyDecisionStrategy and
PolicySetComponent.Priority determine the processing for the rules PolicySetComponent.Priority determine the processing for the rules
contained in a PolicySet. As before, the larger priority value contained in a PolicySet. As before, the larger priority value
represents the higher priority. Unlike the earlier definition, represents the higher priority. Unlike the earlier definition,
PolicySetComponent.Priority MUST have a unique value when compared with PolicySetComponent.Priority MUST have a unique value when compared with
others defined for the aggregating PolicySet. Thus, the evaluation of others defined for the aggregating PolicySet. Thus, the evaluation of
rules within a set is deterministically specified. rules within a set is deterministically specified.
For a FirstMatching decision strategy, the order of evaluation, then, is For a FirstMatching decision strategy, the first rule (i.e., the one with
high to low priority. The first rule (i.e., the one with the highest the highest priority) in the set that evaluates to True, is the only rule
priority) in the set that evaluates to True, is the only rule whose whose actions are enforced for a particular evaluation pass through the
actions are enforced for a particular evaluation pass through the
PolicySet. PolicySet.
For an AllMatching decision strategy, the order of evaluation is also For an AllMatching decision strategy, all of the matching rules are
from high priority to low priority; however, all of the matching rules enforced. The relative priority of the rules is used to determine the
are executed. Although higher priority rules are evaluated first, lower order in which the actions are to be executed by the enforcement point:
priority rules may get the "last word." So, for example, if two rules the actions of the higher priority rules are executed first. Since the
both evaluate to True, and the higher priority rule sets the DSCP to 3 actions of higher priority rules are executed first, lower priority rules
and the lower priority rule sets the DSCP to 4, the lower priority rule that also match may get the "last word," and thus produce a counter-
will be evaluated later and, therefore, will "win," in this example, intuitive result. So, for example, if two rules both evaluate to True,
setting the DSCP to 4. Thus, conflicts between rules are resolved by and the higher priority rule sets the DSCP to 3 and the lower priority
this evaluation order. rule sets the DSCP to 4, the action of the lower priority rule will be
executed later and, therefore, will "win," in this example, setting the
DSCP to 4. Thus, conflicts between rules are resolved by this execution
order.
An implementation of the rule engine need not provide the action
sequencing but the actions MUST be sequenced by the PEP or PDP on its
behalf. So, for example, the rule engine may provide an ordered list of
actions to be executed by the PEP and any required serialization is then
provided by the service configured by the rule engine. See section 4.5.2
for a discussion of side effects.
4.5.1. Structuring Decision Strategies 4.5.1. Structuring Decision Strategies
When policy sets are nested, as shown in Figure 3, the decision When policy sets are nested, as shown in Figure 3, the decision
strategies may be nested arbitrarily. In this example, the evaluation strategies may be nested arbitrarily. In this example, the relative
order for the nested rules is 1A, 1B1, 1X2, 1B3, 1C, 1C1, 1X2 and 1C3. priorities for the nested rules, high to low, are 1A, 1B1, 1X2, 1B3, 1C,
(Note that PolicyRule 1X2 is included in both PolicyGroup 1B and 1C1, 1X2 and 1C3. (Note that PolicyRule 1X2 is included in both
PolicyRule 1C, but with different priorities.) Of course, the evaluation PolicyGroup 1B and PolicyRule 1C, but with different priorities.) Of
order is also dependent on which rules, if any, match. course, which rules are enforced is also dependent on which rules, if
any, match.
PolicyGroup 1: FirstMatching PolicyGroup 1: FirstMatching
| |
+-- Pri=6 -- PolicyRule 1A +-- Pri=6 -- PolicyRule 1A
| |
+-- Pri=5 -- PolicyGroup 1B: AllMatching +-- Pri=5 -- PolicyGroup 1B: AllMatching
| | | |
| +-- Pri=5 -- PolicyGroup 1B1: AllMatching | +-- Pri=5 -- PolicyGroup 1B1: AllMatching
| | | | | |
| | +---- etc. | | +---- etc.
skipping to change at page 18, line 49 skipping to change at page 20, line 22
appropriate. PolicyRule 1X2 and PolicyRule 1B3 are also evaluated appropriate. PolicyRule 1X2 and PolicyRule 1B3 are also evaluated
and enforced as appropriate. If any of the sub-rules in the and enforced as appropriate. If any of the sub-rules in the
subtrees of PolicyGroup 1B evaluate to True, then PolicyRule 1C is subtrees of PolicyGroup 1B evaluate to True, then PolicyRule 1C is
not evaluated because the FirstMatching strategy of PolicyGroup 1 not evaluated because the FirstMatching strategy of PolicyGroup 1
has been satisfied. has been satisfied.
o If neither PolicyRule 1A nor PolicyGroup 1B yield a match, then o If neither PolicyRule 1A nor PolicyGroup 1B yield a match, then
PolicyRule 1C is evaluated. Since it is first matching, rules PolicyRule 1C is evaluated. Since it is first matching, rules
1C1, 1X2, and 1C3 are evaluated until the first match, if any. 1C1, 1X2, and 1C3 are evaluated until the first match, if any.
4.5.2. Deterministic Decisions 4.5.2. Side Effects
As mentioned above, we propose that Priority values are to be unique Although evaluation of conditions is sometimes discussed as an ordered
within a containing PolicySet. Although there are certainly cases where set of operations, the rule engine need not be implemented as a
rules need not have a unique priority value (i.e., where evaluation and procedural language interpreter. Any side effects of condition evaluation
execution order is not important), it is believed that the flexibility or the execution of actions MUST NOT affect the result of the evaluation
gained by this capability is not sufficiently beneficial to justify the of other conditions evaluated by the rule engine in the same evaluation
possible variations in implementation behavior and the resulting pass. That is, an implementation of a rule engine MAY evaluate all
confusion that might occur. conditions in any order before applying the priority and determining
which actions are to be executed.
Therefore, all PolicySetComponent.Priority values MUST be unique among So, regardless of how a rule engine is implemented, it MUST NOT include
the values in the aggregating PolicySet. Each PolicySet, then, has a any side effects of condition evaluation in the evaluation of conditions
deterministic behavior based upon the decision strategy and uniquely for either of the decision strategies. For both the AllMatching decision
defined order of evaluation. strategy and for the nesting of rules within rules (either directly or
indirectly) where the actions of more than one rule may be enforced, any
side effects of the enforcement of actions MUST NOT be included in
condition evaluation on the same evaluation pass.
4.5.3. Multiple PolicySet Trees For a Resource 4.5.3. Multiple PolicySet Trees For a Resource
As shown in the example in Figure 3, PolicySet trees are defined by the As shown in the example in Figure 3, PolicySet trees are defined by the
PolicySet subclass instances and the PolicySetComponent subclass PolicySet subclass instances and the PolicySetComponent aggregation
aggregation instances between them. Each PolicySet tree has a defined instances between them. Each PolicySet tree has a defined set of
set of decision strategies and evaluation orders. However, a given decision strategies and evaluation priorities. In section 4.6 we discuss
resource may have multiple, disjoint PolicySet trees; we need a join some improvements in the use of PolicyRoles that cause the parent
algorithm that describes the decision strategy and evaluation order among PolicySet.PolicyRoles to be applied to all contained PolicySet instances.
the top-level (called "unrooted") PolicySet instances. (Note that an However, a given resource may still have multiple, disjoint PolicySet
unrooted PolicySet instance may only be unrooted in a given context.) trees that are collected from different roles and role combinations.
Note that these top-level PolicySet instances (called "unrooted") may
only be unrooted in a given context.
<<Solution under discussion - see Open Issue 9>> For those cases where there are multiple unrooted PolicySet instances
that apply to the same managed resource (i.e., not in a common
PolicySetComponent tree), the decision strategy among these disjoint
PolicySet instances is the FirstMatching strategy. The priority used
with this FirstMatching strategy is defined in the PolicySetInSystem
association.
The FirstMatching strategy is used among all PolicySet instances that
apply to a given resource for a given functional domain. So, for
example, the PolicySet instances that are used for QOS policy and the
instances that are used for IKE policy, although they are disjoint, are
not joined in a FirstMatching decision strategy. Instead, they are
evaluated independently of one another.
4.5.4. Deterministic Decisions
As previously discussed, PolicySetComponent.Priority values MUST be
unique within a containing PolicySet and PolicySetInSystem.Priority
values MUST be unique for an associated System. Each PolicySet, then, has
a deterministic behavior based upon the decision strategy and uniquely
defined priority.
There are certainly cases where rules need not have a unique priority
value (i.e., where evaluation and execution priority is not important).
However, it is believed that the flexibility gained by this capability is
not sufficiently beneficial to justify the possible variations in
implementation behavior and the resulting confusion that might occur.
4.6. Policy Roles 4.6. Policy Roles
A policy role is defined in [12] as "an administratively specified A policy role is defined in [12] as "an administratively specified
characteristic of a managed element (for example, an interface). It is a characteristic of a managed element (for example, an interface). It is a
selector for policy rules and PRovisioning Classes (PRCs), to determine selector for policy rules and PRovisioning Classes (PRCs), to determine
the applicability of the rule/PRC to a particular managed element." the applicability of the rule/PRC to a particular managed element."
In PCIMe, PolicyRoles is defined as a property of PolicySet, which is In PCIMe, PolicyRoles is defined as a property of PolicySet, which is
inherited by both PolicyRules and PolicyGroups. In this draft, we also inherited by both PolicyRules and PolicyGroups. In this draft, we also
skipping to change at page 27, line 37 skipping to change at page 29, line 37
Note: The class names in parenthesis denote subclasses. The named Note: The class names in parenthesis denote subclasses. The named
classes in the figure are abstract and cannot, therefore, be classes in the figure are abstract and cannot, therefore, be
instantiated. instantiated.
4.8.3. The Simple Condition Operator 4.8.3. The Simple Condition Operator
A simple condition models an elementary Boolean expression conditional A simple condition models an elementary Boolean expression conditional
clause of the form "If variable MATCHes value". However, the formal clause of the form "If variable MATCHes value". However, the formal
notation of the SimplePolicyCondition, together with its associations, notation of the SimplePolicyCondition, together with its associations,
models only a pair, {variable, value}. The "If" term and the "MATCH" models only a pair, {variable, value}. The "If" term and the "MATCH"
operator are not directly modeled -- they are implied. operator are not directly modeled -- they are implied. The implied MATCH
operator carries an overloaded semantics.
The implied MATCH operator carries an overloaded semantics. For example, For example, in the simple condition "If DestinationPort MATCH '80'" the
in the simple condition "If DestinationPort MATCH '80'" the
interpretation of the MATCH operator is equality (the 'equal' operator). interpretation of the MATCH operator is equality (the 'equal' operator).
Clearly, a different interpretation is needed in the following cases: Clearly, a different interpretation is needed in the following cases:
o "If DestinationPort MATCH {'80', '8080'}" -- operator is 'IS SET o "If DestinationPort MATCH {'80', '8080'}" -- operator is 'IS SET
MEMBER' MEMBER'
o "If DestinationPort MATCH {'1 to 255'}" -- operator is 'IN INTEGER o "If DestinationPort MATCH {'1 to 255'}" -- operator is 'IN INTEGER
RANGE' RANGE'
o "If SourceIPAddress MATCH 'MyCompany.com'" -- operator is 'IP o "If SourceIPAddress MATCH 'MyCompany.com'" -- operator is 'IP
ADDRESS AS RESOLVED BY DNS' ADDRESS AS RESOLVED BY DNS'
The examples above illustrate the implicit, context dependant nature of The examples above illustrate the implicit, context dependant nature of
the interpretation of the MATCH operator. The interpretation depends on the interpretation of the MATCH operator. The interpretation depends on
the actual variable and value instances in the simple condition. PCIMe the actual variable and value instances in the simple condition. The
does not contain text to explicitly detail the possible interpretations interpretation is always derived from the bound variable and the value
of MATCH operations. The interpretation is always derived from the value
instance associated with the simple condition. Text accompanying the instance associated with the simple condition. Text accompanying the
value class definition SHOULD be used as a guideline for interpreting the value class and implicit variable definition is used for interpreting the
semantics of the MATCH relationship. semantics of the MATCH relationship. In the following we define generic
(type-independent) matching.
PolicyValues may be multi-fielded, where each field may contain a range
of values. The same equally holds for PolicyVariables. Basically, we
have to deal with single values (singleton), ranges ([lower bound ..
upper bound]), and sets (a,b,c). So independent of the variable and
value type, the following set of generic matching rules for the MATCH
operator are defined.
o singleton matches singleton -> the matching rule is defined in the
type
o singleton matches range [lower bound .. upper bound] -> the
matching evaluates to true, if the singleton matches the lower
bound or the upper bound or a value in between
o singleton matches set -> the matching evaluates to true, if the
value of the singleton matches one of the components in the set,
where a component may be a singleton or range again
o ranges [A..B] matches singleton -> is true if A matches B matches
singleton
o range [A..B] matches range [X..Y] -> the matching evaluates to
true, if all values of the range [A..B] are also in the range
[X..Y]. For instance, [3..5] match [1..6] evaluates to true,
whereas [3..5] match [4..6] evaluates to false.
o range [A..B] matches set (a,b,c, ...) -> the matching evaluates to
true, if all values in the range [A..B] are part of the set. For
instance, range [2..3] match set ([1..2],3) evaluates to true, as
well as range [2..3] match set (2,3), and range [2..3] match set
([1..2],[3..5]).
o set (a,b,c, ...) match singleton -> is true if a match b match c
match ... match singleton
o set match range -> the matching evaluates to true, if all values
in the set are part of the range. For example, set (2,3) match
range [1..4] evaluates to true.
o set (a,b,c,...) match set (x,y,z,...) -> the matching evaluates to
true, if all values in the set (a,b,c,...) are part of the set
(x,y,z,...). For example, set (1,2,3) match set (1,2,3,4)
evaluates to true. Set (1,2,3) match set (1,2) evaluates to
false.
Variables may contain various types (section XXX). When not stated
otherwise, the type of the value bound to the variable at condition
evaluation time and the value type of the PolicyValue instance need to be
of the same type. If they differ the condition evaluates to FALSE.
Matching rules for value type specific matching see below.
The PolicyValueConstraintInVariable association specifies additional The PolicyValueConstraintInVariable association specifies additional
constraints on the possible values that can be matched with a variable constraints on the possible values and value types that can be matched
within a simple condition. Using this association a source or with a variable within a simple condition. Using this association, a
destination port can be constrained to be matched against integer values source or destination port can be constrained to be matched against
in the range 0-65535. A source or destination IP address can be integer values in the range 0-65535. A source or destination IP address
constrained to be matched against a specified list of IPv4 address can be constrained to be matched against a specified list of IPv4 address
values, etc. In order to check whether a value X can be used with a values, etc. In order to check whether a value X can be used with a
variable A constrained by value Y, the following conformance test should variable A constrained by value Y, the following conformance test should
be made. If all events for which the SimplePolicyCondition (A match X) be made. If all events for which the SimplePolicyCondition (A match X)
evaluates to TRUE also evaluate to TRUE for the SimplePolicyCondition (A evaluates to TRUE also evaluate to TRUE for the SimplePolicyCondition (A
match Y), than X conforms to the constraint Y. If multiple values Y1, match Y), than X conforms to the constraint Y. If multiple values Y1,
Y2, ..., Yn constrain a variable, then the conformance test involves Y2, ..., Yn constrain a variable, then the conformance test involves
checking against the condition (A match Y1) OR (A match Y2) OR ... OR (A checking against the condition (A match Y1) OR (A match Y2) OR ... OR (A
match Yn). match Yn).
4.8.4. SimplePolicyActions 4.8.4. SimplePolicyActions
skipping to change at page 28, line 48 skipping to change at page 31, line 48
PolicyAction class defined in PCIM, by specifying the contents of the PolicyAction class defined in PCIM, by specifying the contents of the
action using the <variable> <value> pair to form the action. The action using the <variable> <value> pair to form the action. The
variable specifies the attribute of an object that has passed the variable specifies the attribute of an object that has passed the
condition by evaluating to true. This means the binding of the variable condition by evaluating to true. This means the binding of the variable
is delayed until the condition evaluates to true for one or more objects. is delayed until the condition evaluates to true for one or more objects.
The value of the object's attribute is set to <value>. The value of the object's attribute is set to <value>.
SimplePolicyActions can be used in policy rules directly, or as building SimplePolicyActions can be used in policy rules directly, or as building
blocks for creating CompoundPolicyActions. blocks for creating CompoundPolicyActions.
SimplePolicyAction execution MUST enforce the following data type The set operation is only valid if the list of types of the variable
conformance and translation rule: The ValueTypes property of the variable (ValueTypes property of PolicyImplicitVariable) includes the specified
must be compatible with the type of the value class used. The following type of the value. Conversion of values from one representation into
table shows the compatibility and transformation rules. 'ND' means the another is not defined. E.g., a variable of IPv4Address type may not be
transformation is not defined. set to a string containing a DNS name. Conversions are part of an
implementation-specific mapping of the model.
+------------------------------------------------------------------+
|variable | value type |
|type | |
+------------------------------------------------------------------+
| |String |Integer|BitString| IPv4Addr | IPv6Addr |MACAddr|
+------------------------------------------------------------------+
| String | X |to text| [0|1] | A.B.C.D | dotted | X:X.. |
+------------------------------------------------------------------+
| Integer |"atoi" | X |BinaryVal| 32bit int| ND | ND |
+------------------------------------------------------------------+
| BitString|convert|convert| X | ND | ND | ND |
+------------------------------------------------------------------+
| IPv4Addr |convert|convert| ND | X | ND | ND
+------------------------------------------------------------------+
| IPv6Addr |convert| ND | ND | v4 format| X | ND |
+------------------------------------------------------------------+
| MACAddr | ND | ND | ND | ND | ND | X |
+------------------------------------------------------------------+
Composing a simple action requires that an instance of the class Composing a simple action requires that an instance of the class
SimplePolicyAction be created, and that instances of the variable and SimplePolicyAction be created, and that instances of the variable and
value classes that it uses also exist. Note that the variable and/or value classes that it uses also exist. Note that the variable and/or
value instances may already exist as reusable objects in an appropriate value instances may already exist as reusable objects in an appropriate
ReusablePolicyContainer. ReusablePolicyContainer.
Two aggregations are used in order to create the pair <variable> <value>. Two aggregations are used in order to create the pair <variable> <value>.
The aggregation PolicyVariableInSimplePolicyAction relates a The aggregation PolicyVariableInSimplePolicyAction relates a
SimplePolicyAction to a single variable instance. Similarly, the SimplePolicyAction to a single variable instance. Similarly, the
skipping to change at page 37, line 5 skipping to change at page 39, line 20
the first rule that evaluates to TRUE; AllMatching the first rule that evaluates to TRUE; AllMatching
enforces the actions of all rules that evaluate to enforces the actions of all rules that evaluate to
TRUE. TRUE.
SYNTAX uint16 SYNTAX uint16
VALUES 1 [FirstMatching], 2 [AllMatching] VALUES 1 [FirstMatching], 2 [AllMatching]
DEFAULT VALUE 1 [FirstMatching] DEFAULT VALUE 1 [FirstMatching]
The definition of PolicyRoles is unchanged from PCIM. It is, however, The definition of PolicyRoles is unchanged from PCIM. It is, however,
moved from the class Policy up to the superclass PolicySet. moved from the class Policy up to the superclass PolicySet.
5.2. Updates to PCIM's Class "PolicyGroup" 5.2. Update PCIM's Class "PolicyGroup"
The PolicyGroup class is modified to be derived from PolicySet. The PolicyGroup class is modified to be derived from PolicySet.
NAME PolicyGroup NAME PolicyGroup
DESCRIPTION A container for a set of related PolicyRules and DESCRIPTION A container for a set of related PolicyRules and
PolicyGroups. PolicyGroups.
DERIVED FROM PolicySet DERIVED FROM PolicySet
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.3. Updates to PCIM's Class "PolicyRule" 5.3. Update PCIM's Class "PolicyRule"
The PolicyRule class is modified to be derived from PolicySet, and to The PolicyRule class is modified to be derived from PolicySet, and to
deprecate the use of Priority in the rule. PolicyRoles is now inherited deprecate the use of Priority in the rule. PolicyRoles is now inherited
from the parent class PolicySet. Finally, a new property from the parent class PolicySet. Finally, a new property
ExecutionStrategy is introduced, paralleling the property of the same ExecutionStrategy is introduced, paralleling the property of the same
name in the class CompoundPolicyAction. name in the class CompoundPolicyAction.
NAME PolicyRule NAME PolicyRule
DESCRIPTION The central class for representing the "If Condition DESCRIPTION The central class for representing the "If Condition
then Action" semantics associated with a policy rule. then Action" semantics associated with a policy rule.
DERIVED FROM PolicySet DERIVED FROM PolicySet
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES Enabled PROPERTIES Enabled
ConditionListType ConditionListType
RuleUsage RuleUsage
Priority DEPRECATED FOR PolicySetComponent.Priority Priority DEPRECATED FOR PolicySetComponent.Priority
AND FOR PolicySetInSystem.Priority
Mandatory Mandatory
SequencedActions SequencedActions
ExecutionStrategy ExecutionStrategy
The property ExecutionStrategy defines the execution strategy to be used The property ExecutionStrategy defines the execution strategy to be used
upon the sequenced actions aggregated by this PolicyRule. (An equivalent upon the sequenced actions aggregated by this PolicyRule. (An equivalent
ExecutionStrategy property is also defined for the CompoundPolicyAction ExecutionStrategy property is also defined for the CompoundPolicyAction
class, to provide the same indication for the sequenced actions class, to provide the same indication for the sequenced actions
aggregated by a CompoundPolicyAction.) This draft defines four execution aggregated by a CompoundPolicyAction.) This draft defines three
strategies: execution strategies:
Mandatory Do all execute ALL actions that are part of the modeled Do Until Success execute actions according to predefined order, until
set. If one or more of the actions cannot be
executed, none of the actions should be executed.
Do until success execute actions according to predefined order, until
successful execution of a single action. successful execution of a single action.
Do All - execute ALL actions which are part of the modeled Do All - execute ALL actions which are part of the modeled
set, according to their predefined order. Continue set, according to their predefined order. Continue
doing this, even if one or more of the actions doing this, even if one or more of the actions
fails. fails.
Do until Failure - execute actions according to predefined order, until Do Until Failure - execute actions according to predefined order, until
the first failure in execution of a single sub- the first failure in execution of a single sub-
action. action.
The property definition is as follows: The property definition is as follows:
NAME ExecutionStrategy NAME ExecutionStrategy
DESCRIPTION An enumeration indicating how to interpret the action DESCRIPTION An enumeration indicating how to interpret the action
ordering for the actions aggregated by this ordering for the actions aggregated by this
PolicyRule. PolicyRule.
SYNTAX uint16 (ENUM, {1=Mandatory Do All, 2=Do Until Success, SYNTAX uint16 (ENUM, {1=Do Until Success, 2=Do All, 3=Do
3=Do All, 4=Do Until Failure} ) Until Failure} )
DEFAULT VALUE Do All (3) DEFAULT VALUE Do All (2)
5.4. The Class "SimplePolicyCondition" 5.4. The Class "SimplePolicyCondition"
A simple policy condition is composed of an ordered triplet: A simple policy condition is composed of an ordered triplet:
<Variable> MATCH <Value> <Variable> MATCH <Value>
No formal modeling of the MATCH operator is provided. The 'match' No formal modeling of the MATCH operator is provided. The 'match'
relationship is implied. Such simple conditions are evaluated by relationship is implied. Such simple conditions are evaluated by
answering the question: answering the question:
skipping to change at page 40, line 42 skipping to change at page 43, line 5
This is a concrete class, and is therefore directly instantiable. This is a concrete class, and is therefore directly instantiable.
The Property SequencedActions is identical to the SequencedActions The Property SequencedActions is identical to the SequencedActions
property defined in PCIM for the class PolicyRule. property defined in PCIM for the class PolicyRule.
The property ExecutionStrategy defines the execution strategy to be used The property ExecutionStrategy defines the execution strategy to be used
upon the sequenced actions associated with this compound action. (An upon the sequenced actions associated with this compound action. (An
equivalent ExecutionStrategy property is also defined for the PolicyRule equivalent ExecutionStrategy property is also defined for the PolicyRule
class, to provide the same indication for the sequenced actions class, to provide the same indication for the sequenced actions
associated with a PolicyRule.) This draft defines four execution associated with a PolicyRule.) This draft defines three execution
strategies: strategies:
Mandatory Do all execute ALL actions that are part of the modeled Do Until Success execute actions according to predefined order, until
set. If one or more of the sub-actions cannot be
executed, none of the actions should be executed.
Do until success execute actions according to predefined order, until
successful execution of a single sub-action. successful execution of a single sub-action.
Do All - execute ALL actions which are part of the modeled Do All - execute ALL actions which are part of the modeled
set, according to their predefined order. Continue set, according to their predefined order. Continue
doing this, even if one or more of the sub-actions doing this, even if one or more of the sub-actions
fails. fails.
Do Until Failure - execute actions according to predefined order, until
Do until Failure - execute actions according to predefined order, until
the first failure in execution of a single sub- the first failure in execution of a single sub-
action. action.
The property definition is as follows: The property definition is as follows:
NAME ExecutionStrategy NAME ExecutionStrategy
DESCRIPTION An enumeration indicating how to interpret the action DESCRIPTION An enumeration indicating how to interpret the action
ordering for the actions aggregated by this ordering for the actions aggregated by this
CompoundPolicyAction. CompoundPolicyAction.
SYNTAX uint16 (ENUM, {1=Mandatory Do All, 2=Do Until Success, SYNTAX uint16 (ENUM, {1=Do Until Success, 2=Do All, 3=Do
3=Do All, 4=Do Until Failure} ) Until Failure} )
DEFAULT VALUE Do All (3) DEFAULT VALUE Do All (2)
5.9. The Abstract Class "PolicyVariable" 5.9. The Abstract Class "PolicyVariable"
Variables are used for building individual conditions. The variable Variables are used for building individual conditions. The variable
specifies the property of a flow or an event that should be matched when specifies the property of a flow or an event that should be matched when
evaluating the condition. However, not every combination of a variable evaluating the condition. However, not every combination of a variable
and a value creates a meaningful condition. For example, a source IP and a value creates a meaningful condition. For example, a source IP
address variable can not be matched against a value that specifies a port address variable can not be matched against a value that specifies a port
number. A given variable selects the set of matchable value types. number. A given variable selects the set of matchable value types.
skipping to change at page 43, line 14 skipping to change at page 45, line 26
The property is defined as follows: The property is defined as follows:
NAME ValueTypes NAME ValueTypes
SYNTAX String SYNTAX String
5.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe 5.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe
The following subclasses of PolicyImplicitVariable are defined in PCIMe. The following subclasses of PolicyImplicitVariable are defined in PCIMe.
5.12.1. The Class "PolicySourceIPVariable" 5.12.1. The Class "PolicySourceIPv4Variable"
NAME PolicySourceIPVariable NAME PolicySourceIPv4Variable
DESCRIPTION The source IP address. DESCRIPTION The source IPv4 address. of the outermost IP packet
header.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIPv4AddrValue - PolicyIPv4AddrValue
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)
5.12.2. The Class "PolicySourceIPv6Variable"
NAME PolicySourceIPv6Variable
DESCRIPTION The source IPv6 address of the outermost IP packet
header.
ALLOWED VALUE TYPES:
- PolicyIPv6AddrValue - PolicyIPv6AddrValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.2. The Class "PolicyDestinationIPVariable" 5.12.3. The Class "PolicyDestinationIPv4Variable"
NAME PolicyDestinationIPVariable NAME PolicyDestinationIPv4Variable
DESCRIPTION The destination IP address. DESCRIPTION The destination IPv4 address of the outermost IP
packet header.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIPv4AddrValue - PolicyIPv4AddrValue
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)
5.12.4. The Class "PolicyDestinationIPv6Variable"
NAME PolicyDestinationIPv6Variable
DESCRIPTION The destination IPv6 address of the outermost IP
packet header.
ALLOWED VALUE TYPES:
- PolicyIPv6AddrValue - PolicyIPv6AddrValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.3. The Class "PolicySourcePortVariable" 5.12.5. The Class "PolicySourcePortVariable"
NAME PolicySourcePortVariable NAME PolicySourcePortVariable
DESCRIPTION Ports are defined as the abstraction that transport DESCRIPTION Ports are defined as the abstraction that transport
protocols use to distinguish among multiple protocols use to distinguish among multiple
destinations within a given host computer. For TCP destinations within a given host computer. For TCP
and UDP flows, the PolicySourcePortVariable is and UDP flows, the PolicySourcePortVariable is
logically bound to the source port field. logically bound to the source port field of the
outermost UDP or TCP packet header.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIntegerValue - PolicyIntegerValue (0..65535)
- PolicyBitStringValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.4. The Class "PolicyDestinationPortVariable"
5.12.6. The Class "PolicyDestinationPortVariable"
NAME PolicyDestinationPortVariable NAME PolicyDestinationPortVariable
DESCRIPTION Ports are defined as the abstraction that transport DESCRIPTION Ports are defined as the abstraction that transport
protocols use to distinguish among multiple protocols use to distinguish among multiple
destinations within a given host computer. For TCP destinations within a given host computer. For TCP
and UDP flows, the PolicyDestinationPortVariable is and UDP flows, the PolicyDestinationPortVariable is
logically bound to the destination port field. logically bound to the destination port field of the
outermost UDP or TCP packet header.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIntegerValue - PolicyIntegerValue (0..65535)
- PolicyBitStringValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.5. The Class "PolicyIPProtocolVariable" 5.12.7. The Class "PolicyIPProtocolVariable"
NAME PolicyIPProtocolVariable NAME PolicyIPProtocolVariable
DESCRIPTION The IP protocol number. DESCRIPTION The IP protocol number.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIntegerValue - PolicyIntegerValue
- PolicyBitStringValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.6. The Class "PolicyIPVersionVariable" 5.12.8. The Class "PolicyIPVersionVariable"
NAME PolicyIPVersionVariable NAME PolicyIPVersionVariable
DESCRIPTION The IP version number. The well-known values are 4 DESCRIPTION The IP version number. The well-known values are 4
and 6. and 6.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIntegerValue - PolicyIntegerValue
- PolicyBitStringValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.7. The Class "PolicyIPToSVariable" 5.12.9. The Class "PolicyIPToSVariable"
NAME PolicyIPToSVariable NAME PolicyIPToSVariable
DESCRIPTION The IP TOS octet. DESCRIPTION The IP TOS octet.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIntegerValue - PolicyIntegerValue (0..7)
- PolicyBitStringValue - PolicyBitStringValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.8. The Class "PolicyDSCPVariable" 5.12.10. The Class "PolicyDSCPVariable"
NAME PolicyDSCPVariable NAME PolicyDSCPVariable
DESCRIPTION The 6 bit Differentiated Service Code Point. DESCRIPTION The 6 bit Differentiated Service Code Point.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..63)
- PolicyBitStringValue
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)
5.12.11. The Class "PolicyFlowIdVariable"
NAME PolicyFlowIdVariable
DESCRIPTION The flow identifer of the outermost IPv6 packet
header.
ALLOWED VALUE TYPES:
- PolicyIntegerValue - PolicyIntegerValue
- PolicyBitStringValue - PolicyBitStringValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.9. The Class "PolicySourceMACVariable" 5.12.12. The Class "PolicySourceMACVariable"
NAME PolicySourceMACVariable NAME PolicySourceMACVariable
DESCRIPTION The source MAC address. DESCRIPTION The source MAC address.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyMACAddrValue - PolicyMACAddrValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.10. The Class "PolicyDestinationMACVariable" 5.12.13. The Class "PolicyDestinationMACVariable"
NAME PolicyDestinationMACVariable NAME PolicyDestinationMACVariable
DESCRIPTION The destination MAC address. DESCRIPTION The destination MAC address.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyMACAddrValue - PolicyMACAddrValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.11. The Class "PolicyVLANVariable" 5.12.14. The Class "PolicyVLANVariable"
NAME PolicyVLANVariable NAME PolicyVLANVariable
DESCRIPTION The virtual Bridged Local Area Network Identifier, a DESCRIPTION The virtual Bridged Local Area Network Identifier, a
12-bit field as defined in the IEEE 802.1q standard. 12-bit field as defined in the IEEE 802.1q standard.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIntegerValue - PolicyIntegerValue
- PolicyBitStringValue - PolicyBitStringValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.12. The Class "PolicyCoSVariable" 5.12.15. The Class "PolicyCoSVariable"
NAME PolicyCoSVariable NAME PolicyCoSVariable
DESCRIPTION Class of Service, a 3-bit field, used in the layer 2 DESCRIPTION Class of Service, a 3-bit field, used in the layer 2
header to select the forwarding treatment. Bound to header to select the forwarding treatment. Bound to
the IEEE 802.1q user-priority field. the IEEE 802.1q user-priority field.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIntegerValue - PolicyIntegerValue
- PolicyBitStringValue - PolicyBitStringValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.13. The Class "PolicyEthertypeVariable" 5.12.16. The Class "PolicyEthertypeVariable"
NAME PolicyEthertypeVariable NAME PolicyEthertypeVariable
DESCRIPTION The Ethertype protocol number of Ethernet frames. DESCRIPTION The Ethertype protocol number of Ethernet frames.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIntegerValue - PolicyIntegerValue
- PolicyBitStringValue - PolicyBitStringValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.14. The Class "PolicySourceSAPVariable" 5.12.17. The Class "PolicySourceSAPVariable"
NAME PolicySourceSAPVariable NAME PolicySourceSAPVariable
DESCRIPTION The Source SAP number. DESCRIPTION The Source Service Access Point (SAP) number of the
IEEE 802.2 LLC header.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIntegerValue - PolicyIntegerValue
- PolicyBitStringValue - PolicyBitStringValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.15. The Class "PolicyDestinationSAPVariable" 5.12.18. The Class "PolicyDestinationSAPVariable"
NAME PolicyDestinationSAPVariable NAME PolicyDestinationSAPVariable
DESCRIPTION The Destination SAP number. DESCRIPTION The Destination Service Access Point (SAP) number of
the IEEE 802.2 LLC header.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIntegerValue - PolicyIntegerValue
- PolicyBitStringValue - PolicyBitStringValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.16. The Class "PolicySNAPVariable" 5.12.19. The Class "PolicySNAPVariable"
NAME PolicySNAPVariable NAME PolicySNAPVariable
DESCRIPTION The protocol number over a SNAP SAP encapsulation. DESCRIPTION The protocol number over a Sub-Network Access Protocol
(SNAP) SAP encapsulation.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIntegerValue - PolicyIntegerValue
- PolicyBitStringValue - PolicyBitStringValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.17. The Class "PolicyFlowDirectionVariable" 5.12.20. The Class "PolicyFlowDirectionVariable"
NAME PolicyFlowDirectionVariable NAME PolicyFlowDirectionVariable
DESCRIPTION The direction of a flow relative to a network element. DESCRIPTION The direction of a flow relative to a network element.
Direction may be "IN" and/or "OUT". Direction may be "IN" and/or "OUT".
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyStringValue - PolicyStringValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
skipping to change at page 48, line 34 skipping to change at page 51, line 34
specified below: specified below:
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv4prefix = IPv4address "/" 1*2DIGIT IPv4prefix = IPv4address "/" 1*2DIGIT
IPv4range = IPv4address"-"IPv4address IPv4range = IPv4address"-"IPv4address
IPv4maskedaddress = IPv4address","IPv4address IPv4maskedaddress = IPv4address","IPv4address
Hostname (as defined in [9]) Hostname (as defined in [9])
In the above definition, each string entry is either: In the above definition, each string entry is either:
1. A single Ipv4address in dot notation, as defined above. Example: 1. A single IPv4address in dot notation, as defined above. Example:
121.1.1.2 121.1.1.2
2. An IPv4prefix address range, as defined above, specified by an 2. An IPv4prefix address range, as defined above, specified by an
address and a prefix length, separated by "/". Example: address and a prefix length, separated by "/". Example:
2.3.128.0/15 2.3.128.0/15
3. An IPv4range address range defined above, specified by a starting 3. An IPv4range address range defined above, specified by a starting
address in dot notation and an ending address in dot notation, address in dot notation and an ending address in dot notation,
separated by "-". The range includes all addresses between the separated by "-". The range includes all addresses between the
range's starting and ending addresses, including these two range's starting and ending addresses, including these two
skipping to change at page 49, line 5 skipping to change at page 52, line 5
4. An IPv4maskedaddress address range, as defined above, specified by 4. An IPv4maskedaddress address range, as defined above, specified by
an address and mask. The address and mask are represented in dot an address and mask. The address and mask are represented in dot
notation, separated by a comma ",". The masked address appears notation, separated by a comma ",". The masked address appears
before the comma, and the mask appears after the comma. Example: before the comma, and the mask appears after the comma. Example:
2.3.128.0,255.255.248.0. 2.3.128.0,255.255.248.0.
5. A single Hostname. The Hostname format follows the guidelines and 5. A single Hostname. The Hostname format follows the guidelines and
restrictions specified in [9]. Example: www.bigcompany.com. restrictions specified in [9]. Example: www.bigcompany.com.
Conditions matching IPv4AddrValues evaluate to true according to the
generic matching rules. Additionally, a hostname is matched against
another valid IPv4address representation by resolving the hostname into
an IPv4 address first, and then comparing the addresses afterwards.
Matching hostnames against each other is done using a string comparison
of the two names.
The property definition is as follows: The property definition is as follows:
NAME IPv4AddrList NAME IPv4AddrList
SYNTAX String SYNTAX String
FORMAT IPv4address | IPv4prefix | IPv4range | FORMAT IPv4address | IPv4prefix | IPv4range |
IPv4maskedaddress | hostname IPv4maskedaddress | hostname
5.14.2. The Class "PolicyIPv6AddrValue 5.14.2. The Class "PolicyIPv6AddrValue
This class is used to define a list of IPv6 addresses, hostnames, and This class is used to define a list of IPv6 addresses, hostnames, and
skipping to change at page 50, line 5 skipping to change at page 53, line 11
notation and an ending address in dot notation, separated by "-". notation and an ending address in dot notation, separated by "-".
The range includes all addresses between the range's starting and The range includes all addresses between the range's starting and
ending addresses, including these two addresses. ending addresses, including these two addresses.
4. An IPv4maskedaddress address range defined above specified by an 4. An IPv4maskedaddress address range defined above specified by an
address and mask. The address and mask are represented in dot address and mask. The address and mask are represented in dot
notation separated by a comma ",". notation separated by a comma ",".
5. A single IPv6prefix as defined above. 5. A single IPv6prefix as defined above.
Conditions matching IPv6AddrValues evaluate to true according to the
generic matching rules. Additionally, a hostname is matched against
another valid IPv6address representation by resolving the hostname into
an IPv6 address first, and then comparing the addresses afterwards.
Matching hostnames against each other is done using a string comparison
of the two names.
5.14.3. The Class "PolicyMACAddrValue" 5.14.3. The Class "PolicyMACAddrValue"
This class is used to define a list of MAC addresses and MAC address This class is used to define a list of MAC addresses and MAC address
range values. The class definition is as follows: range values. The class definition is as follows:
NAME PolicyMACAddrValue NAME PolicyMACAddrValue
DERIVED FROM PolicyValue DERIVED FROM PolicyValue
ABSTRACT False ABSTRACT False
PROPERTIES MACAddrList[ ] PROPERTIES MACAddrList[ ]
skipping to change at page 52, line 14 skipping to change at page 55, line 29
ABSTRACT False ABSTRACT False
PROPERTIES IntegerList[ ] PROPERTIES IntegerList[ ]
The property IntegerList provides an unordered list of integers and The property IntegerList provides an unordered list of integers and
integer range values, represented as strings. The format of this integer range values, represented as strings. The format of this
property takes one of the following forms: property takes one of the following forms:
1. An integer value. 1. An integer value.
2. A range of integers. The range is specified by a starting integer 2. A range of integers. The range is specified by a starting integer
and an ending integer, separated by '-'. The starting integer and an ending integer, separated by '..'. The starting integer
MUST be less than or equal to the ending integer. The range MUST be less than or equal to the ending integer. The range
includes all integers between the starting and ending integers, includes all integers between the starting and ending integers,
including these two integers. Care must be taken in reading including these two integers.
integer ranges involving negative integers, since the unary minus
and the range indicator are the same character '-'.
To represent a range of integers that is not bounded, the reserved words To represent a range of integers that is not bounded, the reserved words
-INFINITY and/or INFINITY can be used in place of the starting and ending -INFINITY and/or INFINITY can be used in place of the starting and ending
integers. integers. In addition to ordinary integer matches, INFINITY matches
INFINITY and -INFINITY matches -INFINITY.
The ABNF definition [8] is: The ABNF definition [8] is:
integer = [-]1*DIGIT | "INFINITY" | "-INFINITY" integer = [-]1*DIGIT | "INFINITY" | "-INFINITY"
integerrange = integer"-"integer integerrange = integer".."integer
Using ranges, the operators greater-than, greater-than-or-equal-to, less- Using ranges, the operators greater-than, greater-than-or-equal-to, less-
than, and less-than-or-equal-to can be expressed. For example, "X is- than, and less-than-or-equal-to can be expressed. For example, "X is-
greater-than 5" (where X is an integer) can be translated to "X matches greater-than 5" (where X is an integer) can be translated to "X matches
6-INFINITY". This enables the match condition semantics of the operator 6-INFINITY". This enables the match condition semantics of the operator
for the SimplePolicyCondition class to be kept simple (i.e., just the for the SimplePolicyCondition class to be kept simple (i.e., just the
value "match"). value "match").
The property definition is as follows: The property definition is as follows:
skipping to change at page 53, line 43 skipping to change at page 57, line 4
5.16. The Class "ReusablePolicyContainer" 5.16. The Class "ReusablePolicyContainer"
The new class ReusablePolicyContainer is defined as follows: The new class ReusablePolicyContainer is defined as follows:
NAME ReusablePolicyContainer NAME ReusablePolicyContainer
DESCRIPTION A class representing an administratively defined DESCRIPTION A class representing an administratively defined
container for reusable policy-related information. container for reusable policy-related information.
This class does not introduce any additional This class does not introduce any additional
properties beyond those in its superclass AdminDomain. properties beyond those in its superclass AdminDomain.
It does, however, participate in a number of unique It does, however, participate in a number of unique
associations. associations.
DERIVED FROM AdminDomain DERIVED FROM AdminDomain
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.17. Deprecation of PCIM's Class "PolicyRepository" 5.17. Deprecate PCIM's Class "PolicyRepository"
The class definition of PolicyRepository (from PCIM) is updated as The class definition of PolicyRepository (from PCIM) is updated as
follows, with an indication that the class has been deprecated. Note follows, with an indication that the class has been deprecated. Note
that when an element of the model is deprecated, its replacement element that when an element of the model is deprecated, its replacement element
is identified explicitly. is identified explicitly.
NAME PolicyRepository NAME PolicyRepository
DEPRECATED FOR ReusablePolicyContainer DEPRECATED FOR ReusablePolicyContainer
DESCRIPTION A class representing an administratively defined DESCRIPTION A class representing an administratively defined
container for reusable policy-related information. container for reusable policy-related information.
skipping to change at page 54, line 23 skipping to change at page 57, line 36
DERIVED FROM AdminDomain DERIVED FROM AdminDomain
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
6. Association and Aggregation Definitions 6. Association and Aggregation Definitions
The following definitions supplement those in PCIM itself. PCIM The following definitions supplement those in PCIM itself. PCIM
definitions that are not DEPRECATED here are still current parts of the definitions that are not DEPRECATED here are still current parts of the
overall Policy Core Information Model. overall Policy Core Information Model.
6.1. The Abstract Aggregation "PolicySetComponent" 6.1. The Aggregation "PolicySetComponent"
PolicySetComponent is a new abstract aggregation class that collects PolicySetComponent is a new aggregation class that collects instances of
instances of PolicySet subclasses (PolicyGroups and PolicyRules) into PolicySet subclasses (PolicyGroups and PolicyRules) into coherent sets of
coherent sets of policies. policies.
NAME PolicySetComponent NAME PolicySetComponent
DESCRIPTION An abstract class representing the components of a DESCRIPTION A concrete class representing the components of a
policy set that have the same decision strategy, and policy set that have the same decision strategy, and
are prioritized within the set. are prioritized within the set.
DERIVED FROM PolicyComponent DERIVED FROM PolicyComponent
ABSTRACT TRUE ABSTRACT FALSE
PROPERTIES GroupComponent[ref PolicySet[0..n]] PROPERTIES GroupComponent[ref PolicySet[0..n]]
PartComponent[ref PolicySet[0..n]] PartComponent[ref PolicySet[0..n]]
Priority Priority
The definition of the Priority property is unchanged from its previous The definition of the Priority property is unchanged from its previous
definition in [PCIM]. definition in [PCIM].
NAME Priority NAME Priority
DESCRIPTION A non-negative integer for prioritizing this PolicySet DESCRIPTION A non-negative integer for prioritizing this PolicySet
component relative to other components of the same component relative to other components of the same
PolicySet. A larger value indicates a higher PolicySet. A larger value indicates a higher
priority. priority.
SYNTAX uint16 SYNTAX uint16
DEFAULT VALUE 0 DEFAULT VALUE 0
6.2. Update to PCIM's Aggregation "PolicyGroupInPolicyGroup" 6.2. Deprecate PCIM's Aggregation "PolicyGroupInPolicyGroup"
The PolicyGroupInPolicyGroup aggregation class is modified to be derived The new aggregation PolicySetComponent is used directly to represent
from PolicySetComponent. aggregation of PolicyGroups by a higher-level PolicyGroup. Thus the
aggregation PolicyGroupInPolicyGroup is no longer needed, and can be
deprecated.
NAME PolicyGroupInPolicyGroup NAME PolicyGroupInPolicyGroup
DEPRECATED FOR PolicySetComponent
DESCRIPTION A class representing the aggregation of PolicyGroups DESCRIPTION A class representing the aggregation of PolicyGroups
by a higher-level PolicyGroup. by a higher-level PolicyGroup.
DERIVED FROM PolicySetComponent DERIVED FROM PolicyComponent
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES GroupComponent[ref PolicyGroup[0..n]] PROPERTIES GroupComponent[ref PolicyGroup[0..n]]
PartComponent[ref PolicyGroup[0..n]] PartComponent[ref PolicyGroup[0..n]]
6.3. Update to PCIM's Aggregation "PolicyRuleInPolicyGroup" 6.3. Deprecate PCIM's Aggregation "PolicyRuleInPolicyGroup"
The PolicyRuleInPolicyGroup aggregation class is modified to be derived The new aggregation PolicySetComponent is used directly to represent
from PolicySetComponent. aggregation of PolicyRules by a PolicyGroup. Thus the aggregation
PolicyRuleInPolicyGroup is no longer needed, and can be deprecated.
NAME PolicyRuleInPolicyGroup NAME PolicyRuleInPolicyGroup
DEPRECATED FOR PolicySetComponent
DESCRIPTION A class representing the aggregation of PolicyRules by DESCRIPTION A class representing the aggregation of PolicyRules by
a PolicyGroup. a PolicyGroup.
DERIVED FROM PolicySetComponent DERIVED FROM PolicyComponent
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES GroupComponent[ref PolicyGroup[0..n]] PROPERTIES GroupComponent[ref PolicyGroup[0..n]]
PartComponent[ref PolicyRule[0..n]] PartComponent[ref PolicyRule[0..n]]
6.4. The Aggregation "PolicyGroupInPolicyRule" 6.4. The Abstract Association "PolicySetInSystem"
A policy rule may aggregate one or more policy groups, via the PolicySetInSystem is a new association that defines a relationship
PolicyGroupInPolicyRule aggregation. Grouping of policy groups and their between a System and a PolicySet used in the administrative scope of that
subclasses into a policy rule is for administrative convenience, system (e.g., AdminDomain, ComputerSystem). The Priority property is
scalability and manageability, as it enables more complex policies to be used to assign a relative priority to a PolicySet within the
constructed from multiple simpler policies. administrative scope in contexts where it is not a component of another
PolicySet.
Policy rules do not have to contain policy groups. In addition, a policy NAME PolicySetInSystem
group may also be used by itself, without belonging to a policy rule, and DESCRIPTION An abstract class representing the relationship
policy rules may be individually aggregated by other policy rules by the between a System and a PolicySet that is used in the
PolicyRuleInPolicyRule aggregation. Note that it is assumed that this administrative scope of the System.
aggregation is used to form directed acyclic graphs and NOT ring DERIVED FROM PolicyInSystem
structures. ABSTRACT TRUE
PROPERTIES Antecedent[ref System[0..1]]
Dependent [ref PolicySet[0..n]]
Priority
The class definition for this aggregation is as follows: The Priority property is used to specify the relative priority of the
referenced PolicySet when there are more than one PolicySet instances
applied to a managed resource that are not PolicySetComponents and,
therefore, have no other relative priority defined.
NAME PolicyGroupInPolicyRule NAME Priority
DERIVED FROM PolicySetComponent DESCRIPTION A non-negative integer for prioritizing the referenced
ABSTRACT False PolicySet among other PolicySet instances that are not
PROPERTIES GroupComponent[ref PolicyRule[0..n]] components of a common PolicySet. A larger value
PartComponent[ref PolicyGroup[0..n]] indicates a higher priority.
SYNTAX uint16
DEFAULT VALUE 0
The reference property "GroupComponent" is inherited from 6.5. Update PCIM's Weak Association "PolicyGroupInSystem"
PolicySetComponent, and overridden to become an object reference to a
PolicyRule that contains one or more PolicyGroups. Note that for any
single instance of the aggregation class PolicyGroupInPolicyRule, 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 PolicyGroup.
The reference property "PartComponent" is inherited from Regardless of whether it a component of another PolicySet, a PolicyGroup
PolicySetComponent, and overridden to become an object reference to a is itself defined within the scope of a System. This association links a
PolicyGroup contained by one or more PolicyRules. Note that for any PolicyGroup to the System in whose scope the PolicyGroup is defined. It
single instance of the aggregation class PolicyGroupInPolicyRule, this is a subclass of the abstract PolicySetInSystem association. The class
property (like all reference properties) is single-valued. The [0..n] definition for the association is as follows:
cardinality indicates that a given PolicyRule may contain 0, 1, or more
than one PolicyGroup.
6.5. The Aggregation "PolicyRuleInPolicyRule" NAME PolicyGroupInSystem
DESCRIPTION A class representing the fact that a PolicyGroup is
defined within the scope of a System.
DERIVED FROM PolicySetInSystem
ABSTRACT FALSE
PROPERTIES Antecedent[ref System[1..1]]
Dependent [ref PolicyGroup[weak]]
A policy rule may aggregate one or more policy rules, via the The Reference "Antecedent" is inherited from PolicySetInSystem, and
PolicyRuleInPolicyRule aggregation. The ability to nest policy rules and overridden to restrict its cardinality to [1..1]. It serves as an object
form sub-rules is important for manageability and scalability, as it reference to a System that provides a scope for one or more PolicyGroups.
enables complex policy rules to be constructed from multiple simpler Since this is a weak association, the cardinality for this object
policy rules. reference is always 1, that is, a PolicyGroup is always defined within
the scope of exactly one System.
A policy rule does not have to contain sub-rules. A policy rule may The Reference "Dependent" is inherited from PolicySetInSystem, and
contain a group of sub-rules using the PolicyGroupInPolicyRule overridden to become an object reference to a PolicyGroup defined within
aggregation. Note that it is assumed that this aggregation is used to the scope of a System. Note that for any single instance of the
form directed a-cyclic graphs and NOT ring structures. 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.
The class definition for this aggregation is as follows: 6.6. Update PCIM's Weak Association "PolicyRuleInSystem"
NAME PolicyRuleInPolicyRule Regardless of whether it a component of another PolicySet, a PolicyRule
DERIVED FROM PolicySetComponent is itself defined within the scope of a System. This association links a
ABSTRACT False PolicyRule to the System in whose scope the PolicyRule is defined. It is
PROPERTIES GroupComponent[ref PolicyRule[0..n]] a subclass of the abstract PolicySetInSystem association. The class
PartComponent[ref PolicyRule[0..n]] definition for the association is as follows:
The reference property "GroupComponent" is inherited from NAME PolicyRuleInSystem
PolicySetComponent, and overridden to become an object reference to a DESCRIPTION A class representing the fact that a PolicyRule is
PolicyRule that contains one or more PolicyRules. Each contained defined within the scope of a System.
PolicyRule can be conceptualized as a sub-rule of the containing DERIVED FROM PolicySetInSystem
PolicyRule. This nesting can be done to any desired level. However, the ABSTRACT FALSE
deeper the nesting, the more complex the results of the decisions taken PROPERTIES Antecedent[ref System[1..1]]
by the nested rules. Dependent[ref PolicyRule[weak]]
Note that for any single instance of the aggregation class The Reference "Antecedent" is inherited from PolicySetInSystem, and
PolicyRuleInPolicyRule, this property is single-valued. The [0..n] overridden to restrict its cardinality to [1..1]. It serves as an object
cardinality indicates that there may be 0, 1 or more than one reference to a System that provides a scope for one or more PolicyRules.
PolicyRules that contain any given PolicyRule. 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.
The reference property "PartComponent" is inherited from The Reference "Dependent" is inherited from PolicySetInSystem, and
PolicySetComponent, and overridden to become an object reference to a overridden to become an object reference to a PolicyRule defined within
PolicyRule contained by a PolicyRule. Note that for any single instance the scope of a System. Note that for any single instance of the
of the aggregation class PolicyRuleInPolicyRule, this property is single- association class PolicyRuleInSystem, this property (like all Reference
valued. The [0..n] cardinality indicates that a given PolicyRule may properties) is single-valued. The [0..n] cardinality indicates that a
contain 0, 1, or more than one other PolicyRules. given System may have 0, 1, or more than one PolicyRules defined within
its scope.
6.6. The Abstract Aggregation "CompoundedPolicyCondition" 6.7. The Abstract Aggregation "CompoundedPolicyCondition"
NAME CompoundedPolicyCondition NAME CompoundedPolicyCondition
DESCRIPTION A class representing the aggregation of DESCRIPTION A class representing the aggregation of
PolicyConditions by an aggregating instance. PolicyConditions by an aggregating instance.
DERIVED FROM PolicyComponent DERIVED FROM PolicyComponent
ABSTRACT TRUE ABSTRACT TRUE
PROPERTIES PartComponent[ref PolicyCondition[0..n]] PROPERTIES PartComponent[ref PolicyCondition[0..n]]
GroupNumber GroupNumber
ConditionNegated ConditionNegated
6.7. Update to PCIM's Aggregation "PolicyConditionInPolicyRule" 6.8. Update PCIM's Aggregation "PolicyConditionInPolicyRule"
The PCIM aggregation "PolicyConditionInPolicyRule" is updated, to make it The PCIM aggregation "PolicyConditionInPolicyRule" is updated, to make it
a subclass of the new abstract aggregation CompoundedPolicyCondition. a subclass of the new abstract aggregation CompoundedPolicyCondition.
The properties GroupNumber and ConditionNegated are now inherited, rather The properties GroupNumber and ConditionNegated are now inherited, rather
than specified explicitly as they were in PCIM. than specified explicitly as they were in PCIM.
NAME PolicyConditionInPolicyRule NAME PolicyConditionInPolicyRule
DESCRIPTION A class representing the aggregation of DESCRIPTION A class representing the aggregation of
PolicyConditions by a PolicyRule. PolicyConditions by a PolicyRule.
DERIVED FROM CompoundedPolicyCondition DERIVED FROM CompoundedPolicyCondition
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES GroupComponent[ref PolicyRule[0..n]] PROPERTIES GroupComponent[ref PolicyRule[0..n]]
6.8. The Aggregation "PolicyConditionInPolicyCondition" 6.9. The Aggregation "PolicyConditionInPolicyCondition"
A second subclass of CompoundedPolicyCondition is defined, representing A second subclass of CompoundedPolicyCondition is defined, representing
the compounding of policy conditions into a higher-level policy the compounding of policy conditions into a higher-level policy
condition. condition.
NAME PolicyConditionInPolicyCondition NAME PolicyConditionInPolicyCondition
DESCRIPTION A class representing the aggregation of DESCRIPTION A class representing the aggregation of
PolicyConditions by another PolicyCondition. PolicyConditions by another PolicyCondition.
DERIVED FROM CompoundedPolicyCondition DERIVED FROM CompoundedPolicyCondition
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES GroupComponent[ref PolicyCondition[0..n]] PROPERTIES GroupComponent[ref CompoundPolicyCondition[0..n]]
6.9. The Abstract Aggregation "CompoundedPolicyAction" 6.10. The Abstract Aggregation "CompoundedPolicyAction"
NAME CompoundedPolicyAction NAME CompoundedPolicyAction
DESCRIPTION A class representing the aggregation of PolicyActions DESCRIPTION A class representing the aggregation of PolicyActions
by an aggregating instance. by an aggregating instance.
DERIVED FROM PolicyComponent DERIVED FROM PolicyComponent
ABSTRACT TRUE ABSTRACT TRUE
PROPERTIES PartComponent[ref PolicyAction[0..n]] PROPERTIES PartComponent[ref PolicyAction[0..n]]
ActionOrder ActionOrder
6.10. Update to PCIM's Aggregation "PolicyActionInPolicyRule" 6.11. Update PCIM's Aggregation "PolicyActionInPolicyRule"
The PCIM aggregation "PolicyActionInPolicyRule" is updated, to make it a The PCIM aggregation "PolicyActionInPolicyRule" is updated, to make it a
subclass of the new abstract aggregation CompoundedPolicyAction. The subclass of the new abstract aggregation CompoundedPolicyAction. The
property ActionOrder is now inherited, rather than specified explicitly property ActionOrder is now inherited, rather than specified explicitly
as it was in PCIM. as it was in PCIM.
NAME PolicyActionInPolicyRule NAME PolicyActionInPolicyRule
DESCRIPTION A class representing the aggregation of PolicyActions DESCRIPTION A class representing the aggregation of PolicyActions
by a PolicyRule. by a PolicyRule.
DERIVED FROM CompoundedPolicyAction DERIVED FROM CompoundedPolicyAction
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES GroupComponent[ref PolicyRule[0..n]] PROPERTIES GroupComponent[ref PolicyRule[0..n]]
6.11. The Aggregation "PolicyActionInPolicyAction" 6.12. The Aggregation "PolicyActionInPolicyAction"
A second subclass of CompoundedPolicyAction is defined, representing the A second subclass of CompoundedPolicyAction is defined, representing the
compounding of policy actions into a higher-level policy action. compounding of policy actions into a higher-level policy action.
NAME PolicyActionInPolicyAction NAME PolicyActionInPolicyAction
DESCRIPTION A class representing the aggregation of PolicyActions DESCRIPTION A class representing the aggregation of PolicyActions
by another PolicyAction. by another PolicyAction.
DERIVED FROM CompoundedPolicyAction DERIVED FROM CompoundedPolicyAction
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES GroupComponent[ref PolicyAction[0..n]] PROPERTIES GroupComponent[ref CompoundPolicyAction[0..n]]
6.12. The Aggregation "PolicyVariableInSimplePolicyCondition" 6.13. The Aggregation "PolicyVariableInSimplePolicyCondition"
A simple policy condition is represented as an ordered triplet {variable, A simple policy condition is represented as an ordered triplet {variable,
operator, value}. This aggregation provides the linkage between a operator, value}. This aggregation provides the linkage between a
SimplePolicyCondition instance and a single PolicyVariable. The SimplePolicyCondition instance and a single PolicyVariable. The
aggregation PolicyValueInSimplePolicyCondition links the aggregation PolicyValueInSimplePolicyCondition links the
SimplePolicyCondition to a single PolicyValue. The Operator property of SimplePolicyCondition to a single PolicyValue. The Operator property of
SimplePolicyCondition represents the third element of the triplet, the SimplePolicyCondition represents the third element of the triplet, the
operator. operator.
The class definition for this aggregation is as follows: The class definition for this aggregation is as follows:
skipping to change at page 59, line 11 skipping to change at page 62, line 46
The reference property "PartComponent" is inherited from PolicyComponent, The reference property "PartComponent" is inherited from PolicyComponent,
and overridden to become an object reference to a PolicyVariable that is and overridden to become an object reference to a PolicyVariable that is
defined within the scope of a SimplePolicyCondition. Note that for any defined within the scope of a SimplePolicyCondition. Note that for any
single instance of the association class single instance of the association class
PolicyVariableInSimplePolicyCondition, this property (like all reference PolicyVariableInSimplePolicyCondition, this property (like all reference
properties) is single-valued. The [1..1] cardinality indicates that a properties) is single-valued. The [1..1] cardinality indicates that a
SimplePolicyCondition must have exactly one policy variable defined SimplePolicyCondition must have exactly one policy variable defined
within its scope in order to be meaningful. within its scope in order to be meaningful.
6.13. The Aggregation "PolicyValueInSimplePolicyCondition" 6.14. The Aggregation "PolicyValueInSimplePolicyCondition"
A simple policy condition is represented as an ordered triplet {variable, A simple policy condition is represented as an ordered triplet {variable,
operator, value}. This aggregation provides the linkage between a operator, value}. This aggregation provides the linkage between a
SimplePolicyCondition instance and a single PolicyValue. The aggregation SimplePolicyCondition instance and a single PolicyValue. The aggregation
PolicyVariableInSimplePolicyCondition links the SimplePolicyCondition to PolicyVariableInSimplePolicyCondition links the SimplePolicyCondition to
a single PolicyVariable. The Operator property of SimplePolicyCondition a single PolicyVariable. The Operator property of SimplePolicyCondition
represents the third element of the triplet, the operator. represents the third element of the triplet, the operator.
The class definition for this aggregation is as follows: The class definition for this aggregation is as follows:
skipping to change at page 59, line 45 skipping to change at page 63, line 30
The reference property "PartComponent" is inherited from PolicyComponent, The reference property "PartComponent" is inherited from PolicyComponent,
and overridden to become an object reference to a PolicyValue that is and overridden to become an object reference to a PolicyValue that is
defined within the scope of a SimplePolicyCondition. Note that for any defined within the scope of a SimplePolicyCondition. Note that for any
single instance of the association class single instance of the association class
PolicyValueInSimplePolicyCondition, this property (like all reference PolicyValueInSimplePolicyCondition, this property (like all reference
properties) is single-valued. The [1..1] cardinality indicates that a properties) is single-valued. The [1..1] cardinality indicates that a
SimplePolicyCondition must have exactly one policy value defined within SimplePolicyCondition must have exactly one policy value defined within
its scope in order to be meaningful. its scope in order to be meaningful.
6.14. The Aggregation "PolicyVariableInSimplePolicyAction" 6.15. The Aggregation "PolicyVariableInSimplePolicyAction"
A simple policy action is represented as a pair {variable, value}. This A simple policy action is represented as a pair {variable, value}. This
aggregation provides the linkage between a SimplePolicyAction instance aggregation provides the linkage between a SimplePolicyAction instance
and a single PolicyVariable. The aggregation and a single PolicyVariable. The aggregation
PolicyValueInSimplePolicyAction links the SimplePolicyAction to a single PolicyValueInSimplePolicyAction links the SimplePolicyAction to a single
PolicyValue. PolicyValue.
The class definition for this aggregation is as follows: The class definition for this aggregation is as follows:
NAME PolicyVariableInSimplePolicyAction NAME PolicyVariableInSimplePolicyAction
skipping to change at page 60, line 28 skipping to change at page 64, line 11
The reference property "PartComponent" is inherited from PolicyComponent, The reference property "PartComponent" is inherited from PolicyComponent,
and overridden to become an object reference to a PolicyVariable that is and overridden to become an object reference to a PolicyVariable that is
defined within the scope of a SimplePolicyAction. Note that for any defined within the scope of a SimplePolicyAction. Note that for any
single instance of the association class single instance of the association class
PolicyVariableInSimplePolicyAction, this property (like all reference PolicyVariableInSimplePolicyAction, this property (like all reference
properties) is single-valued. The [1..1] cardinality indicates that a properties) is single-valued. The [1..1] cardinality indicates that a
SimplePolicyAction must have exactly one policy variable defined within SimplePolicyAction must have exactly one policy variable defined within
its scope in order to be meaningful. its scope in order to be meaningful.
6.15. The Aggregation "PolicyValueInSimplePolicyAction" 6.16. The Aggregation "PolicyValueInSimplePolicyAction"
A simple policy action is represented as a pair {variable, value}. This A simple policy action is represented as a pair {variable, value}. This
aggregation provides the linkage between a SimplePolicyAction instance aggregation provides the linkage between a SimplePolicyAction instance
and a single PolicyValue. The aggregation and a single PolicyValue. The aggregation
PolicyVariableInSimplePolicyAction links the SimplePolicyAction to a PolicyVariableInSimplePolicyAction links the SimplePolicyAction to a
single PolicyVariable. single PolicyVariable.
The class definition for this aggregation is as follows: The class definition for this aggregation is as follows:
NAME PolicyValueInSimplePolicyAction NAME PolicyValueInSimplePolicyAction
skipping to change at page 61, line 8 skipping to change at page 64, line 43
SimplePolicyAction objects that contain any given policy value object. SimplePolicyAction objects that contain any given policy value object.
The reference property "PartComponent" is inherited from PolicyComponent, The reference property "PartComponent" is inherited from PolicyComponent,
and overridden to become an object reference to a PolicyValue that is and overridden to become an object reference to a PolicyValue that is
defined within the scope of a SimplePolicyAction. Note that for any defined within the scope of a SimplePolicyAction. Note that for any
single instance of the association class PolicyValueInSimplePolicyAction, single instance of the association class PolicyValueInSimplePolicyAction,
this property (like all reference properties) is single-valued. The this property (like all reference properties) is single-valued. The
[1..1] cardinality indicates that a SimplePolicyAction must have exactly [1..1] cardinality indicates that a SimplePolicyAction must have exactly
one policy value defined within its scope in order to be meaningful. one policy value defined within its scope in order to be meaningful.
6.16. The Association "ReusablePolicy" 6.17. The Association "ReusablePolicy"
The association ReusablePolicy makes it possible to include any subclass The association ReusablePolicy makes it possible to include any subclass
of the abstract class "Policy" in a ReusablePolicyContainer. of the abstract class "Policy" in a ReusablePolicyContainer.
NAME ReusablePolicy NAME ReusablePolicy
DESCRIPTION A class representing the inclusion of a reusable DESCRIPTION A class representing the inclusion of a reusable
policy element in a ReusablePolicyContainer. Reusable policy element in a ReusablePolicyContainer. Reusable
elements may be PolicyGroups, PolicyRules, elements may be PolicyGroups, PolicyRules,
PolicyConditions, PolicyActions, PolicyVariables, PolicyConditions, PolicyActions, PolicyVariables,
PolicyValues, or instances of any other subclasses of PolicyValues, or instances of any other subclasses of
skipping to change at page 61, line 20 skipping to change at page 65, line 4
The association ReusablePolicy makes it possible to include any subclass The association ReusablePolicy makes it possible to include any subclass
of the abstract class "Policy" in a ReusablePolicyContainer. of the abstract class "Policy" in a ReusablePolicyContainer.
NAME ReusablePolicy NAME ReusablePolicy
DESCRIPTION A class representing the inclusion of a reusable DESCRIPTION A class representing the inclusion of a reusable
policy element in a ReusablePolicyContainer. Reusable policy element in a ReusablePolicyContainer. Reusable
elements may be PolicyGroups, PolicyRules, elements may be PolicyGroups, PolicyRules,
PolicyConditions, PolicyActions, PolicyVariables, PolicyConditions, PolicyActions, PolicyVariables,
PolicyValues, or instances of any other subclasses of PolicyValues, or instances of any other subclasses of
the abstract class Policy. the abstract class Policy.
DERIVED FROM PolicyInSystem DERIVED FROM PolicyInSystem
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES Antecedent[ref ReusablePolicyContainer[0..1]] PROPERTIES Antecedent[ref ReusablePolicyContainer[0..1]]
6.17. Deprecate PCIM's "PolicyConditionInPolicyRepository" 6.18. Deprecate PCIM's "PolicyConditionInPolicyRepository"
NAME PolicyConditionInPolicyRepository NAME PolicyConditionInPolicyRepository
DEPRECATED FOR ReusablePolicy DEPRECATED FOR ReusablePolicy
DESCRIPTION A class representing the inclusion of a reusable DESCRIPTION A class representing the inclusion of a reusable
PolicyCondition in a PolicyRepository. PolicyCondition in a PolicyRepository.
DERIVED FROM PolicyInSystem DERIVED FROM PolicyInSystem
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES Antecedent[ref PolicyRepository[0..1]] PROPERTIES Antecedent[ref PolicyRepository[0..1]]
Dependent[ref PolicyCondition[0..n]] Dependent[ref PolicyCondition[0..n]]
6.18. Deprecate PCIM's "PolicyActionInPolicyRepository" 6.19. Deprecate PCIM's "PolicyActionInPolicyRepository"
NAME PolicyActionInPolicyRepository NAME PolicyActionInPolicyRepository
DEPRECATED FOR ReusablePolicy DEPRECATED FOR ReusablePolicy
DESCRIPTION A class representing the inclusion of a reusable DESCRIPTION A class representing the inclusion of a reusable
PolicyAction in a PolicyRepository. PolicyAction in a PolicyRepository.
DERIVED FROM PolicyInSystem DERIVED FROM PolicyInSystem
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES Antecedent[ref PolicyRepository[0..1]] PROPERTIES Antecedent[ref PolicyRepository[0..1]]
Dependent[ref PolicyAction[0..n]] Dependent[ref PolicyAction[0..n]]
6.19. The Association PolicyValueConstraintInVariable 6.20. The Association PolicyValueConstraintInVariable
This association links a PolicyValue object to a PolicyVariable object, This association links a PolicyValue object to a PolicyVariable object,
modeling specific value constraints. Using this association, a variable modeling specific value constraints. Using this association, a variable
(instance) may be constrained to be bound-to/assigned only a set of (instance) may be constrained to be bound-to/assigned only a set of
allowed values. For example, modeling an enumerated source port allowed values. For example, modeling an enumerated source port
variable, one creates an instance of the PolicySourcePortVariable class variable, one creates an instance of the PolicySourcePortVariable class
and associates it with the set of values (integers) representing the and associates it with the set of values (integers) representing the
allowed enumeration, using appropriate number of instances of the allowed enumeration, using appropriate number of instances of the
PolicyValueConstraintInVariable association. PolicyValueConstraintInVariable association.
skipping to change at page 62, line 34 skipping to change at page 66, line 16
optionally having value constraints. The [0..n] cardinality indicates optionally having value constraints. The [0..n] cardinality indicates
that any number of variables may be constrained by a given value. that any number of variables may be constrained by a given value.
The reference property "Dependent" is inherited from Dependency, and The reference property "Dependent" is inherited from Dependency, and
overridden to become an object reference to a PolicyValue that is used to overridden to become an object reference to a PolicyValue that is used to
constrain the values that a particular PolicyVariable can have. The constrain the values that a particular PolicyVariable can have. The
[0..n] cardinality indicates that a given policy variable may have 0, 1 [0..n] cardinality indicates that a given policy variable may have 0, 1
or more than one PolicyValues defined to model the constraints on the or more than one PolicyValues defined to model the constraints on the
values that the policy variable can take. values that the policy variable can take.
6.20. The Aggregation "PolicyContainerInPolicyContainer" 6.21. The Aggregation "PolicyContainerInPolicyContainer"
The aggregation PolicyContainerInPolicyContainer provides for nesting of The aggregation PolicyContainerInPolicyContainer provides for nesting of
one ReusablePolicyContainer inside another one. one ReusablePolicyContainer inside another one.
NAME PolicyContainerInPolicyContainer NAME PolicyContainerInPolicyContainer
DESCRIPTION A class representing the aggregation of DESCRIPTION A class representing the aggregation of
ReusablePolicyContainers by a higher-level ReusablePolicyContainers by a higher-level
ReusablePolicyContainer. ReusablePolicyContainer.
DERIVED FROM SystemComponent DERIVED FROM SystemComponent
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES GroupComponent[ref ReusablePolicyContainer [0..n]] PROPERTIES GroupComponent[ref ReusablePolicyContainer [0..n]]
PartComponent[ref ReusablePolicyContainer [0..n]] PartComponent[ref ReusablePolicyContainer [0..n]]
6.21. Deprecate PCIM's "PolicyRepositoryInPolicyRepository" 6.22. Deprecate PCIM's "PolicyRepositoryInPolicyRepository"
NAME PolicyRepositoryInPolicyRepository NAME PolicyRepositoryInPolicyRepository
DEPRECATED FOR PolicyContainerInPolicyContainer DEPRECATED FOR PolicyContainerInPolicyContainer
DESCRIPTION A class representing the aggregation of DESCRIPTION A class representing the aggregation of
PolicyRepositories by a higher-level PolicyRepository. PolicyRepositories by a higher-level PolicyRepository.
DERIVED FROM SystemComponent DERIVED FROM SystemComponent
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES GroupComponent[ref PolicyRepository[0..n]] PROPERTIES GroupComponent[ref PolicyRepository[0..n]]
PartComponent[ref PolicyRepository[0..n]] PartComponent[ref PolicyRepository[0..n]]
6.22. The Aggregation "ElementInPolicyRoleCollection" 6.23. The Aggregation "ElementInPolicyRoleCollection"
The following aggregation is used to associate ManagedElements with a The following aggregation is used to associate ManagedElements with a
PolicyRoleCollection object that represents a role played by these PolicyRoleCollection object that represents a role played by these
ManagedElements. ManagedElements.
NAME ElementInPolicyRoleCollection NAME ElementInPolicyRoleCollection
DESCRIPTION A class representing the inclusion of a ManagedElement DESCRIPTION A class representing the inclusion of a ManagedElement
in a collection, specified as having a given role. in a collection, specified as having a given role.
All the managed elements in the collection share the All the managed elements in the collection share the
same role. same role.
DERIVED FROM MemberOfCollection DERIVED FROM MemberOfCollection
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES Collection[ref PolicyRoleCollection [0..n]] PROPERTIES Collection[ref PolicyRoleCollection [0..n]]
Member[ref ManagedElement [0..n]] Member[ref ManagedElement [0..n]]
6.22.1. The Weak Association "PolicyRoleCollectionInSystem" 6.24. The Weak Association "PolicyRoleCollectionInSystem"
A PolicyRoleCollection is defined within the scope of a System. This A PolicyRoleCollection is defined within the scope of a System. This
association links a PolicyRoleCollection to the System in whose scope it association links a PolicyRoleCollection to the System in whose scope it
is defined. is defined.
When associating a PolicyRoleCollection with a System, this should be When associating a PolicyRoleCollection with a System, this should be
done consistently with the system that scopes the policy rules/groups done consistently with the system that scopes the policy rules/groups
that are applied to the resources in that collection. A that are applied to the resources in that collection. A
PolicyRoleCollection is associated with the same system as the applicable PolicyRoleCollection is associated with the same system as the applicable
PolicyRules and/or PolicyGroups, or to a System higher in the tree formed PolicyRules and/or PolicyGroups, or to a System higher in the tree formed
skipping to change at page 68, line 7 skipping to change at page 71, line 41
draft of the document. Input is solicited from the working group as a draft of the document. Input is solicited from the working group as a
whole on the following open issues: whole on the following open issues:
1. Unrestricted use of DNF/CNF for CompoundPolicyConditions. 1. Unrestricted use of DNF/CNF for CompoundPolicyConditions.
Alternative: for the conditions aggregated by a Alternative: for the conditions aggregated by a
CompoundPolicyCondition, allow only ANDing, with negation of CompoundPolicyCondition, allow only ANDing, with negation of
individual conditions. Note that this is sufficient to build individual conditions. Note that this is sufficient to build
multi-field packet filters from single-field multi-field packet filters from single-field
SimplePolicyConditions. SimplePolicyConditions.
RESOLUTION: The same DNF/CNF capabilities present for aggregating
PolicyConditions into a PolicyRule have been retained for
aggregating PolicyConditions into a CompoundPolicyCondition.
2. For a PolicyVariable in a SimplePolicyCondition, restrict the set 2. For a PolicyVariable in a SimplePolicyCondition, restrict the set
of possible values both via associated PolicyValue objects (tied of possible values both via associated PolicyValue objects (tied
in with the PolicyValueConstraintInVariable association) and via in with the PolicyValueConstraintInVariable association) and via
the ValueTypes property in the PolicyVariable class. Alternative: the ValueTypes property in the PolicyVariable class. Alternative:
restrict values only via associated PolicyValue objects. restrict values only via associated PolicyValue objects.
RESOLUTION: PCIMe continues to allow both mechanisms for
restricting the values of a PolicyVariable.
3. Transactional semantics, including rollback, for the 3. Transactional semantics, including rollback, for the
ExecutionStrategy property in PolicyRule and in ExecutionStrategy property in PolicyRule and in
CompoundPolicyAction. Alternative: have only 'Do until success' CompoundPolicyAction. Alternative: have only 'Do until success'
and 'Do all'. and 'Do all'.
RESOLUTION: No transactional semantics for action execution. The
value 'Mandatory Do All(1)' has been removed from the two
ExecutionStrategy properties.
4. Stating that CompoundFilterConditions are the preferred way to do 4. Stating that CompoundFilterConditions are the preferred way to do
packet filtering in a PolicyCondition. Alternative: make packet filtering in a PolicyCondition. Alternative: make
CompoundFilterConditions and FilterEntries available to submodels, CompoundFilterConditions and FilterEntries available to submodels,
with no stated (or implied) preference. with no stated (or implied) preference.
RESOLUTION: Recommendations for use of CompoundFilterConditions
and FilterEntries are retained, but they have been recast
slightly. CompoundFilterConditions are now positioned as the
recommended approach for domain-level models. FilterEntries are
the recommended approach for device-level models.
5. Prohibiting equal values for Priority within a PolicySet. 5. Prohibiting equal values for Priority within a PolicySet.
Alternative: allow equal values, with resulting indeterminacy in Alternative: allow equal values, with resulting indeterminacy in
PEP behavior. PEP behavior.
RESOLUTION: PCIMe will continue to prohibit equal Priority values.
6. Modeling a SimplePolicyAction with just a related PolicyVariable 6. Modeling a SimplePolicyAction with just a related PolicyVariable
and PolicyValue -- the "set" or "apply" operation is implicit. and PolicyValue -- the "set" or "apply" operation is implicit.
Alternative: include an Operation property in SimplePolicyAction, Alternative: include an Operation property in SimplePolicyAction,
similar to the Operation property in SimplePolicyCondition. similar to the Operation property in SimplePolicyCondition.
RESOLUTION: This issue has been resolved by a change in the
opposite direction. The operations are now implicit for BOTH
SimplePolicyCondition and SimplePolicyAction. See Sections 4.8.3
and 4.8.4, respectively, for discussions of
SimplePolicyCondition's implicit MATCH operator and
SimplePolicyAction's implicit SET operator.
7. Representation of PolicyValues: should values like IPv4 addresses 7. Representation of PolicyValues: should values like IPv4 addresses
be represented only as strings (as in LDAP), or natively (e.g., an be represented only as strings (as in LDAP), or natively (e.g., an
IPv4 address would be a four-octet field) with mappings to other IPv4 address would be a four-octet field) with mappings to other
representations such as strings? representations such as strings?
RESOLUTION: Mappings have been eliminated. Each value type has a
single representation specified for it.
8. The nesting of rules and groups within rules introduces 8. The nesting of rules and groups within rules introduces
significant change and complexity in the model. This nesting significant change and complexity in the model. This nesting
introduces program state (procedural language) into the model introduces program state (procedural language) into the model
(heretofore a declarative model) as well as implicit hierarchical (heretofore a declarative model) as well as implicit hierarchical
contexts on which the rules operate. These require a much more contexts on which the rules operate. These require a much more
sophisticated rule-evaluation engine than in the past. sophisticated rule-evaluation engine than in the past.
Alternative: Maintain the declarative model, by prohibiting Alternative: Maintain the declarative model, by prohibiting
program state in rule evaluation (i.e., no rules within rules). program state in rule evaluation (i.e., no rules within rules).
RESOLUTION: Nesting of rules and groups within rules has been
retained, but with a significant new limitation: actions
associated with a rule do not have side effects that would impact
condition evaluation for subsequent rules. "Subsequent rules"
here includes both rules nested within the rule whose actions are
under discussion, and rules at the same nesting level as this rule
that are evaluated after it. Note that it has been a feature of
PCIM (RFC 3060) all along that condition evaluation has no side
effects that would influence condition evaluation for subsequent
rules.
There is also one modeling detail associated with nesting that has
been changed. Rather than having separate aggregations
(PolicyGroupInPolicyGroup, etc.) for each of the four nesting
varieties, the single aggregation PolicySetComponent is now used
as a concrete aggregation class.
9. Need to specify a join algorithm for disjoint rule sets. 9. Need to specify a join algorithm for disjoint rule sets.
RESOLUTION: PCIMe now states that for different functional domains
(e.g., QoS and IKE), there is no join algorithm. Each domain, in
effect, has its own rule engine, which operates independently of
the other domains' engine(s). Within a functional domain,
disjoint PolicySets are joined by the Priority property in the
PolicySetInSystem association. In this case the decision strategy
is specified to be FirstMatching.
10. Clarify PolicyImplicitVariables. 10. Clarify PolicyImplicitVariables.
RESOLUTION: Each subclass of PolicyImplicitVariable will identify
the exact source of the variable data. For example, there will be
a subclass of PolicyImplicitVariable that specifically identifies
the IPv4 source address in the outermost packet header. IPv4 and
IPv6 addresses will require separate subclasses of
PolicyImplicitVariable. We understand the downside of this
approach: a potential explosion in the number of subclasses of
PolicyImplicitVariable.
ALTERNATIVE: At this time the authors are still discussing an
alternative approach, in which variable types would be represented
by enumerated values rather than by separate subclasses of
PolicyImplicitVariable. This approach can greatly reduce the
number of classes in the model, but it introduces an IANA
dependency for managing the enumerated values.
11. Clarify PolicyExplicitVariables. 11. Clarify PolicyExplicitVariables.
NON-RESOLUTION: This issue is still not resolved at all. The
authors continue to believe that we need the capability of
indicating that a condition should compare against (or an action
should set) a particular property in a particular object instance.
But we do not believe that the current mechanism of specifying a
target object class and property name is sufficient. For the next
version of PCIMe, we need to either find a way to make this work
in general; or find a way to make it work in some cases, and then
describe clearly what these cases are; or remove
PolicyExplicitVariables from PCIMe entirely.
 End of changes. 159 change blocks. 
461 lines changed or deleted 753 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/