Policy Framework Working Group                                 B. Moore
 INTERNET-DRAFT                                               L. Rafalow
 Updates: 3060                                                       IBM
 Category: Standards Track                                           IBM                                    Y. Ramberg
                                                                 Y. Snir
                                                            J. Strassner
                                                           A. Westerinen
                                                           Cisco Systems
                                                               R. Chadha
                                                  Telcordia Technologies
                                                              M. Brunner
                                                                     NEC
                                                                R. Cohen
                                                               Ntear LLC
                                                          February, 2001
                   Policy Core Information Model Extensions

                      <draft-ietf-policy-pcim-ext-00.txt>
                      Friday, February 23,

                      <draft-ietf-policy-pcim-ext-01.txt>
                       Monday, April 09, 2001, 11:07 11:13 AM

 Status of this Memo

   This document is an Internet-Draft and is in full conformance with all
   provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering Task
   Force (IETF), its areas, and its working groups.  Note that other groups
   may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months and
   may be updated, replaced, or obsoleted by other documents at any time.
   It is inappropriate to use Internet-Drafts as reference material or to
   cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

 Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

 Abstract

   This document proposes a number of changes to the Policy Core Information
   Model (PCIM, RFC 3060).  These changes include both extensions of PCIM
   into areas that it 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 possible, preserves interoperability with
   implementations of the original PCIM model.

   Table of Contents

   1. Introduction......................................................4
   2. Overview of the Changes...........................................4
      2.1. How to Change an Information Model...........................4
      2.2. List of Changes to the Model.................................5
      2.2.1. Changes to PolicyRepository................................5
      2.2.2. Additional Associations and Additional Reusable Elements...5
      2.2.3. Priorities and Decision Strategies.........................5 Strategies.........................6
      2.2.4. Policy Roles...............................................6
      2.2.5. CompoundPolicyConditions and CompoundPolicyActions.........6 CompoundPolicyActions.........7
      2.2.6. Variables and Values.......................................7
      2.2.7. Packet Filtering...........................................7
   3. The Updated Class and Association Class Hierarchies...............7
   4. Areas of Extension to PCIM.......................................11
      4.1. Scope of Policies:  Domain Policies Policy Scope................................................12
      4.1.1. Levels of Abstraction: Domain- and Device-Level Policies..12
      4.1.2. Administrative and Device Policies.....11 Functional Scopes......................12
      4.2. Reusable Policy Elements....................................12 Elements....................................13
      4.3. Policy Sets.................................................13 Sets.................................................14
      4.4. Nested Policy Rules.........................................13 Rules.........................................14
      4.4.1. Usage Rules for Nested Rules..............................13 Rules..............................14
      4.4.2. Motivation................................................14 Motivation................................................15
      4.4.3. Usage Example.............................................15 Example.............................................16
      4.5. Priorities and Decision Strategies..........................16 Strategies..........................18
      4.5.1. Structuring Decision Strategies...........................17 Strategies...........................19
      4.5.2. Deterministic Decisions...................................18 Side Effects..............................................20
      4.5.3. Multiple PolicySet Trees For a Resource...................19 Resource...................20
      4.5.4. Deterministic Decisions...................................21
      4.6. Policy Roles................................................19 Roles................................................21
      4.6.1. Comparison of Roles in PCIM with Roles in snmpconf........19 snmpconf........21
      4.6.2. Addition of PolicyRoleCollection to PCIMe.................20 PCIMe.................22
      4.6.3. Roles for PolicyGroups....................................21 PolicyGroups....................................23
      4.7. Compound Policy Conditions and Compound Policy Actions......22 Actions......24
      4.7.1. Compound Policy Conditions................................23 Conditions................................25
      4.7.2. Compound Policy Actions...................................23 Actions...................................25
      4.8. Variables and Values........................................25 Values........................................27
      4.8.1. Simple Policy Conditions..................................25 Conditions..................................27
      4.8.2. Using Simple Policy Conditions............................26 Conditions............................28
      4.8.3. The Simple Condition Operator.............................27 Operator.............................29
      4.8.4. SimplePolicyActions.......................................28 SimplePolicyActions.......................................31
      4.8.5. Policy Variables..........................................30 Variables..........................................32
      4.8.6. Explicitly Bound Policy Variables.........................30 Variables.........................33
      4.8.7. Implicitly Bound Policy Variables.........................31 Variables.........................33
      4.8.8. Structure and Usage of Pre-Defined Variables..............32 Variables..............34
      4.8.9. Rationale for Modeling Implicit Variables as Classes......33 Classes......35
      4.8.10. Policy Values............................................34 Values............................................36
      4.9. Packet Filtering............................................34 Filtering............................................37
   5. Class Definitions................................................36 Definitions................................................38
      5.1. The Abstract Class "PolicySet"..............................36 "PolicySet"..............................38
      5.2. Updates to Update PCIM's Class "PolicyGroup".......................37 "PolicyGroup"...........................39
      5.3. Updates to Update PCIM's Class "PolicyRule"........................37 "PolicyRule"............................39
      5.4. The Class "SimplePolicyCondition"...........................38 "SimplePolicyCondition"...........................40
      5.5. The Class "CompoundPolicyCondition".........................38 "CompoundPolicyCondition".........................41
      5.6. The Class "CompoundFilterCondition".........................39 "CompoundFilterCondition".........................41
      5.7. The Class "SimplePolicyAction"..............................39 "SimplePolicyAction"..............................42
      5.8. The Class "CompoundPolicyAction"............................40 "CompoundPolicyAction"............................42
      5.9. The Abstract Class "PolicyVariable".........................41 "PolicyVariable".........................43
      5.10. The Class "PolicyExplicitVariable".........................41 "PolicyExplicitVariable".........................44
      5.10.1. The Single-Valued Property "ModelClass"..................42 "ModelClass"..................44
      5.10.2. The Single-Valued Property ModelProperty.................42 ModelProperty.................44
      5.11. The Abstract Class "PolicyImplicitVariable"................42 "PolicyImplicitVariable"................44
      5.11.1. The Multi-Valued Property "ValueTypes"...................42 "ValueTypes"...................45
      5.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe..43 PCIMe..45
      5.12.1. The Class "PolicySourceIPVariable".......................43 "PolicySourceIPv4Variable".....................45
      5.12.2. The Class "PolicyDestinationIPVariable"..................43 "PolicySourceIPv6Variable".....................45
      5.12.3. The Class "PolicySourcePortVariable".....................43 "PolicyDestinationIPv4Variable"................45
      5.12.4. The Class "PolicyDestinationPortVariable"................44 "PolicyDestinationIPv6Variable"................46
      5.12.5. The Class "PolicyIPProtocolVariable".....................44 "PolicySourcePortVariable".....................46
      5.12.6. The Class "PolicyIPVersionVariable"......................44 "PolicyDestinationPortVariable"................46
      5.12.7. The Class "PolicyIPToSVariable"..........................44 "PolicyIPProtocolVariable".....................47
      5.12.8. The Class "PolicyDSCPVariable"...........................45 "PolicyIPVersionVariable"......................47
      5.12.9. The Class "PolicySourceMACVariable"......................45 "PolicyIPToSVariable"..........................47
      5.12.10. The Class "PolicyDestinationMACVariable"................45 "PolicyDSCPVariable"..........................47
      5.12.11. The Class "PolicyVLANVariable"..........................45 "PolicyFlowIdVariable"........................48
      5.12.12. The Class "PolicyCoSVariable"...........................46 "PolicySourceMACVariable".....................48
      5.12.13. The Class "PolicyEthertypeVariable".....................46 "PolicyDestinationMACVariable"................48
      5.12.14. The Class "PolicySourceSAPVariable".....................46 "PolicyVLANVariable"..........................48
      5.12.15. The Class "PolicyDestinationSAPVariable"................46 "PolicyCoSVariable"...........................49
      5.12.16. The Class "PolicySNAPVariable"..........................47 "PolicyEthertypeVariable".....................49
      5.12.17. The Class "PolicyFlowDirectionVariable".................47 "PolicySourceSAPVariable".....................49
      5.12.18. The Class "PolicyDestinationSAPVariable"................49
      5.12.19. The Class "PolicySNAPVariable"..........................50
      5.12.20. The Class "PolicyFlowDirectionVariable".................50
      5.13. The Abstract Class "PolicyValue"...........................47 "PolicyValue"...........................50
      5.14. Subclasses of "PolicyValue" Specified in PCIMe.............48 PCIMe.............51
      5.14.1. The Class "PolicyIPv4AddrValue"..........................48 "PolicyIPv4AddrValue"..........................51
      5.14.2. The Class "PolicyIPv6AddrValue...........................49 "PolicyIPv6AddrValue...........................52
      5.14.3. The Class "PolicyMACAddrValue"...........................50 "PolicyMACAddrValue"...........................53
      5.14.4. The Class "PolicyStringValue"............................50 "PolicyStringValue"............................53
      5.14.5. The Class "PolicyBitStringValue".........................51 "PolicyBitStringValue".........................54
      5.14.6. The Class "PolicyIntegerValue"...........................51 "PolicyIntegerValue"...........................55
      5.14.7. The Class "PolicyBooleanValue"...........................52 "PolicyBooleanValue"...........................56
      5.15. The Class "PolicyRoleCollection"...........................53 "PolicyRoleCollection"...........................56
      5.15.1. The Single-Valued Property "PolicyRole"..................53 "PolicyRole"..................56
      5.16. The Class "ReusablePolicyContainer"........................53 "ReusablePolicyContainer"........................56
      5.17. Deprecation of Deprecate PCIM's Class "PolicyRepository".............53 "PolicyRepository"..................57
   6. Association and Aggregation Definitions..........................54 Definitions..........................57
      6.1. The Abstract Aggregation "PolicySetComponent"...............54 "PolicySetComponent"........................57
      6.2. Update to Deprecate PCIM's Aggregation "PolicyGroupInPolicyGroup".....54 "PolicyGroupInPolicyGroup".....58
      6.3. Update to Deprecate PCIM's Aggregation "PolicyRuleInPolicyGroup"......55 "PolicyRuleInPolicyGroup"......58
      6.4. The Aggregation "PolicyGroupInPolicyRule"...................55 Abstract Association "PolicySetInSystem"................58
      6.5. The Aggregation "PolicyRuleInPolicyRule"....................56 Update PCIM's Weak Association "PolicyGroupInSystem"........59
      6.6. Update PCIM's Weak Association "PolicyRuleInSystem".........60
      6.7. The Abstract Aggregation "CompoundedPolicyCondition"........56
      6.7. "CompoundedPolicyCondition"........60
      6.8. Update to PCIM's Aggregation "PolicyConditionInPolicyRule"..57
      6.8. "PolicyConditionInPolicyRule".....60
      6.9. The Aggregation "PolicyConditionInPolicyCondition"..........57
      6.9. "PolicyConditionInPolicyCondition"..........61
      6.10. The Abstract Aggregation "CompoundedPolicyAction"...........57
      6.10. "CompoundedPolicyAction"..........61
      6.11. Update to PCIM's Aggregation "PolicyActionInPolicyRule"....57
      6.11. The Aggregation "PolicyActionInPolicyAction"...............58 "PolicyActionInPolicyRule".......61
      6.12. The Aggregation "PolicyVariableInSimplePolicyCondition"....58 "PolicyActionInPolicyAction"...............61
      6.13. The Aggregation "PolicyValueInSimplePolicyCondition".......59 "PolicyVariableInSimplePolicyCondition"....62
      6.14. The Aggregation "PolicyVariableInSimplePolicyAction".......59 "PolicyValueInSimplePolicyCondition".......62
      6.15. The Aggregation "PolicyValueInSimplePolicyAction"..........60 "PolicyVariableInSimplePolicyAction".......63
      6.16. The Association "ReusablePolicy"...........................61 Aggregation "PolicyValueInSimplePolicyAction"..........64
      6.17. Deprecate PCIM's "PolicyConditionInPolicyRepository".......61 The Association "ReusablePolicy"...........................64
      6.18. Deprecate PCIM's "PolicyActionInPolicyRepository"..........61 "PolicyConditionInPolicyRepository".......65
      6.19. Deprecate PCIM's "PolicyActionInPolicyRepository"..........65
      6.20. The Association PolicyValueConstraintInVariable............61
      6.20. PolicyValueConstraintInVariable............65
      6.21. The Aggregation "PolicyContainerInPolicyContainer".........62
      6.21. "PolicyContainerInPolicyContainer".........66
      6.22. Deprecate PCIM's "PolicyRepositoryInPolicyRepository"......62
      6.22. "PolicyRepositoryInPolicyRepository"......66
      6.23. The Aggregation "ElementInPolicyRoleCollection"............63
      6.22.1. "ElementInPolicyRoleCollection"............66
      6.24. The Weak Association "PolicyRoleCollectionInSystem"......63 "PolicyRoleCollectionInSystem"........67
   7. Intellectual Property............................................64 Property............................................67
   8. Acknowledgements.................................................64 Acknowledgements.................................................68
   9. Security Considerations..........................................64 Considerations..........................................68
   10. References......................................................64 References......................................................68
   11. Authors' Addresses..............................................65 Addresses..............................................69
   12. Full Copyright Statement........................................67 Statement........................................70
   13. Appendix A: Open Issues.........................................67 Issues.........................................71

 1. Introduction

   This document (PCIM Extensions, abbreviated here to PCIMe) proposes a
   number of changes to the Policy Core Information Model (PCIM, RFC 3060
   [3]).  These changes include both extensions of PCIM into areas that it
   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
   possible, preserves interoperability with implementations of the original
   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",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119, reference [1].

 2. Overview of the Changes

 2.1. How to Change an Information Model

   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
   for specifying IETF information models such as PCIM, it is reasonable to
   look to the CIM specifications for guidance on how to modify and extend
   the model.  Among the CIM rules for changing an information model are the
   following.  Note that everything said here about "classes" applies to
   association classes (including aggregations) as well as to non-
   association classes.

     o   Properties may be added to existing classes.
     o   Classes, and individual properties, may be marked as DEPRECATED.
         If there is a replacement feature for the deprecated class or
         property, it is identified explicitly.  Otherwise the notation "No
         value" is used.  In this document, the notation "DEPRECATED FOR
         <feature-name>" is used to indicate that a feature has been
         deprecated, and to identify its replacement feature.
     o   Classes may be inserted into the inheritance hierarchy above
         existing classes, and properties from the existing classes may
         then be "pulled up" into the new classes.  The net effect is that
         the existing classes have exactly the same properties they had
         before, but the properties are inherited rather than defined
         explicitly in the classes.
     o   New subclasses may be defined below existing classes.

 2.2. List of Changes to the Model

   The following subsections provide a very brief overview of the changes to
   PCIM being proposed in PCIMe.

 2.2.1. Changes to PolicyRepository

   Because of the potential for confusion with the Policy Framework
   component Policy Repository (from the four-box picture: Policy Management
   Tool, Policy Repository, PDP, PEP), "PolicyRepository" is a bad name for
   the PCIM class representing a container of reusable policy elements.
   Thus the class PolicyRepository is being replaced with the class
   ReusablePolicyContainer.  To accomplish this change, it is necessary to
   deprecate the PCIM class PolicyRepository and its three associations, and
   replace them with a new class ReusablePolicyContainer and new
   associations.

   As a separate change, the associations for ReusablePolicyContainer are
   being broadened, to allow a ReusablePolicyContainer to contain any
   reusable policy elements.  In PCIM, the only associations defined for a
   PolicyRepository were for it to contain reusable policy conditions and
   policy actions.

 2.2.2. Additional Associations and Additional Reusable Elements

   The PolicyRuleInPolicyRule and PolicyGroupInPolicyRule aggregations are are,
   in effect, being imported from QPIM.  ("In effect" because these two
   aggregations, as well as PCIM'e two aggregations PolicyGroupInPolicyGroup
   and PolicyRuleInPolicyGroup, are all being combined into a single
   aggregation PolicySetComponent.)  These associations aggregations make it possible to
   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

   Drawing from both QPIM and ICIM, the Priority property is being
   deprecated in PolicyRule, and placed instead on the aggregations
   PolicyRuleInPolicyGroup, PolicyGroupInPolicyGroup,
   PolicyGroupInPolicyRule, and PolicyRuleInPolicyRule.  (This is
   accomplished by placing the Priority property on the abstract aggregation
   PolicySetComponent, from which these four aggregations are derived.)
   PolicySetComponent.  The QPIM rules for resolving relative priorities
   across nested PolicyGroups and PolicyRules are being incorporated into
   PCIMe as well.  With the 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
   conflicts, the PCIM restriction stating that priorities are relevant only
   in the case of conflicts is being removed.  In its place, a
   PolicyDecisionStrategy property is being added to the PolicyGroup and
   PolicyRule classes, to allow the policy administrator to select one of
   two behaviors with respect to rule evaluation: either perform the actions
   for all PolicyRules whose conditions evaluate to TRUE, or perform the
   actions only for the highest-priority PolicyRule whose conditions
   evaluate to TRUE.  (Once again this  (This is accomplished by placing the
   PolicyDecisionStrategy property in an abstract class PolicySet, from
   which PolicyGroup and PolicyRule are derived.)  The QPIM rules for
   applying decision strategies to a nested set of PolicyGroups and
   PolicyRules are also being imported.

 2.2.4. Policy Roles

   The concept of policy roles is added to PolicyGroups (being present
   already in the PolicyRule class).  This is accomplished via a new
   superclass for both PolicyRules and PolicyGroups - PolicySets.  For
   nested PolicyRules and PolicyGroups, any roles associated with the outer
   rule or group are automatically "inherited" by the nested one.
   Additional roles may be added at the level of the nested rule or group.

   It was also observed that there was no mechanism in PCIM for assigning
   roles to resources.  For example, while it was possible to associate a
   PolicyRule with the role "FrameRelay&&WAN", there was no way to indicate
   which interfaces matched this criterion.  A new PolicyRoleCollection
   class is defined in PCIMe, representing the collection of resources
   associated with a particular role.  The linkage between a PolicyRule or
   PolicyGroup and a set of resources is then represented by an instance of
   PolicyRoleCollection.  Equivalent values should be defined in entries in
   the PolicyRoles property, inherited by PolicyRules and PolicyGroups from
   PolicySet, and in the PolicyRole property in PolicyRoleCollection.

 2.2.5. CompoundPolicyConditions and CompoundPolicyActions

   The concept of a CompoundPolicyCondition is also being imported into
   PCIMe from QPIM, and broadened to include a parallel
   CompoundPolicyAction.  In both cases the idea is to create reusable
   "chunks" of policy that can exist as named elements in a
   ReusablePolicyContainer.  The "Compound" classes and their associations
   incorporate the condition and action semantics that PCIM defined at the
   PolicyRule level: DNF/CNF for conditions, and ordering for actions.

   Compound conditions and actions are defined to work with any component
   conditions and actions.  In other words, while the components may be
   instances, respectively, of SimplePolicyCondition and SimplePolicyAction
   (discussed immediately below), they need not be.

 2.2.6. Variables and Values

   The SimplePolicyCondition / PolicyVariable / PolicyValue structure is
   being imported into PCIMe from QPIM.  A list of PCIMe-level variables is
   defined, as well as a list of PCIMe-level values.  Other variables and
   values may, if necessary, be defined in submodels of PCIMe.

   A corresponding SimplePolicyAction / PolicyVariable / PolicyValue
   structure is also defined.  While the semantics of a
   SimplePolicyCondition are "variable matches value", a SimplePolicyAction
   has the semantics "set variable to value".

 2.2.7. Packet Filtering

   For packet filtering done in specified at the context of a PolicyCondition, domain level, a set of
   PolicyVariables and PolicyValues are defined, corresponding to the fields
   in an IP packet header plus the most common Layer 2 frame header fields.
   It is expected that domain-level policy conditions that filter on these
   header fields will be expressed in terms of CompoundPolicyConditions
   built up from SimplePolicyConditions that use these variables and values.
   An additional PolicyVariable, PacketDirection, is also defined, to
   indicate whether a packet being filtered is traveling inbound or outbound
   on an interface.

   For packet filtering in other contexts (specifically, for expressed at the device level, including the packet
   classifier filters modeled in QDDIM), QDDIM, these variables and values need not
   be used.  Filter classes derived from the CIM FilterEntryBase class
   hierarchy may still be used in these contexts.

 3. The Updated Class and Association Class Hierarchies

   The following figure shows the class inheritance hierarchy for PCIMe.
   Changes from the PCIM hierarchy are noted parenthetically.

   ManagedElement (abstract)
      |
      +--Policy (abstract)
      |  |
      |  +---PolicySet (abstract -- new - 4.3)
      |  |   |
      |  |   +---PolicyGroup (moved - 4.3)
      |  |   |
      |  |   +---PolicyRule (moved - 4.3)
      |  |
      |  +---PolicyCondition (abstract)
      |  |   |
      |  |   +---PolicyTimePeriodCondition
      |  |   |
      |  |   +---VendorPolicyCondition
      |  |   |
      |  |   +---SimplePolicyCondition (new - 4.8.1)
      |  |   |
      |  |   +---CompoundPolicyCondition (new - 4.7.1)
      |  |       |
      |  |       +---CompoundFilterCondition (new - 4.9)
      |  |
      |  +---PolicyAction (abstract)
      |  |   |
      |  |   +---VendorPolicyAction
      |  |   |
      |  |   +---SimplePolicyAction (new - 4.8.4)
      |  |   |
      |  |   +---CompoundPolicyAction (new - 4.7.2)
      |  |
      |  +---PolicyVariable (abstract -- new - 4.8.5)
      |  |   |
      |  |   +---PolicyExplicitVariable (new - 4.8.6)
      |  |   |
      |  |   +---PolicyImplicitVariable (abstract -- new - 4.8.7)
      |  |       |
      |  |       +---(subtree of more specific classes -- new - 5.12)
      |  |
      |  +---PolicyValue (abstract -- new - 4.8.10)
      |      |
      |      +---(subtree of more specific classes -- new - 5.14)
      |
      +--Collection (abstract -- newly referenced)
      |  |
      |  +--PolicyRoleCollection (new - 4.6.2)
   (continued on following page)
   (continued from previous page)
   ManagedElement(abstract)
      |
      +--ManagedSystemElement (abstract)
         |
         +--LogicalElement (abstract)
            |
            +--System (abstract)
               |
               +--AdminDomain (abstract)
                  |
                  +---ReusablePolicyContainer (new - 4.2)
                  |
                  +---PolicyRepository (deprecated - 4.2)

   Figure 1.    Class Inheritance Hierarchy for PCIMe
   The following figure shows the association class hierarchy for PCIMe.  As
   before, changes from PCIM are noted parenthetically.

   [unrooted]
      |
      +---PolicyComponent (abstract)
      |   |
      |   +---PolicySetComponent (abstract -- new (new - 4.3)
      |   |
      |
      |   |   +---PolicyGroupInPolicyGroup (moved (deprecated - 4.3)
      |   |
      |
      |   |   +---PolicyRuleInPolicyGroup (moved - 4.3)
      |   |    |
      |   |    +---PolicyGroupInPolicyRule (new - 4.3)
      |   |    |
      |   |    +---PolicyRuleInPolicyRule (new (deprecated - 4.3)
      |   |
      |   +---CompoundedPolicyCondition (abstract -- new - 4.7.1)
      |   |    |
      |   |    +---PolicyConditionInPolicyRule  (moved - 4.7.1)
      |   |    |
      |   |    +---PolicyConditionInPolicyCondition (new - 4.7.1)
      |   |
      |   +---PolicyRuleValidityPeriod
      |   |
      |   +---CompoundedPolicyAction (abstract -- new - 4.7.2)
      |   |    |
      |   |    +---PolicyActionInPolicyRule  (moved - 4.7.2)
      |   |    |
      |   |    +---PolicyActionInPolicyAction (new - 4.7.2)
      |   |
      |   +---PolicyVariableInSimplePolicyCondition (new - 4.8.2)
      |   |
      |   +---PolicyValueInSimplePolicyCondition (new - 4.8.2)
      |   |
      |   +---PolicyVariableInSimplePolicyAction (new - 4.8.4)
      |   |
      |   +---PolicyValueInSimplePolicyAction (new - 4.8.4)

   (continued on following page)
   (continued from previous page)
   [unrooted]
      |
      +---Dependency (abstract)
      |   |
      |   +---PolicyInSystem (abstract)
      |   |   |
      |   |   +---PolicySetInSystem (abstract, new - 4.3)
      |   |   |   |
      |   |   |   +---PolicyGroupInSystem
      |   |   |   |
      |   |   |   +---PolicyRuleInSystem
      |   |   |
      |   |   +---ReusablePolicy (new - 4.2)
      |   |   |
      |   |   +---PolicyConditionInPolicyRepository (deprecated - 4.2)
      |   |   |
      |   |   +---PolicyActionInPolicyRepository (deprecated - 4.2)
      |   |
      |   +---PolicyValueConstraintInVariable (new - 4.8)
      |   |
      |   +---PolicyRoleCollectionInSystem (new - 4.6.2)
      |
      +---Component (abstract)
      |   |
      |   +---SystemComponent
      |       |
      |       +---PolicyContainerInPolicyContainer (new - 4.2)
      |       |
      |       +---PolicyRepositoryInPolicyRepository (deprecated - 4.2)
      |
      +---MemberOfCollection (newly referenced)
          |
          +--- ElementInPolicyRoleCollection (new - 4.6.2)

   Figure 2.    Association Class Inheritance Hierarchy for PCIMe

   In addition to these changes that show up at the class and association
   class level, there are other changes from PCIM involving individual class
   properties.  In some cases new properties are introduced into existing
   classes, and in other cases existing properties are deprecated (without
   deprecating the classes that contain them).

 4. Areas of Extension to PCIM

   The following subsections describe each of the areas for which PCIM
   extensions are being defined.

 4.1. Policy Scope

   Policy scopes may be thought of Policies:  Domain Policies 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 Device-Level Policies

   Policies vary in level of abstraction, from the business-level expression
   of service level agreements (SLAs) to the specification of a set of rules
   that apply to devices in a network.  Those latter policies can,
   themselves, be classified into at least two groups: those policies
   consumed by a Policy Decision Point (PDP) that specify the rules for an
   administrative and functional domain, and those policies consumed by a
   Policy Enforcement Point (PEP) that specify the device-specific rules for
   a functional domain.  The higher-level rules consumed by a PDP PDP, called
   domain-level policies, may have late binding variables unspecified, or
   specified by a classification, whereas the device-level rules are likely
   to have fewer unresolved bindings.

   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
   development and deployment of a usable policy-based configuration system.
   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
   develops a programmatic rule specification.  The relationship between the
   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
   rules into specific instructions that can be executed on a specific type
   of platform.

   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
   abstraction, different mechanisms may be more or less appropriate.

 4.2. Reusable Policy Elements

   In PCIM, a distinction was drawn between reusable PolicyConditions

 4.1.2. Administrative and
   PolicyActions Functional Scopes

   Administrative scopes for policy are represented in PCIM and rule-specific 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

   In PCIM, a distinction was drawn between reusable PolicyConditions and
   PolicyActions and rule-specific ones.  The PolicyRepository class was
   also defined, to serve as a container for these reusable elements.  The
   name "PolicyRepository" has proven to be an unfortunate choice for the
   class that serves as a container for reusable policy elements.  This term
   is already used in documents like the Policy Framework, to denote the
   location from which the PEP retrieves all policy specifications, and into
   which the Policy Management Tool places all policy specifications.
   Consequently, the PolicyRepository class is being deprecated, in favor of
   a new class ReusablePolicyContainer.

   When a class is deprecated, any associations that refer to it must also
   be deprecated.  So replacements are needed for the two associations
   PolicyConditionInPolicyRepository and PolicyActionInPolicyRepository, as
   well as for the aggregation PolicyRepositoryInPolicyRepository.  In
   addition to renaming the PolicyRepository class to
   ReusablePolicyContainer, however, PCIMe is also broadening the types of
   policy elements that can be reusable.  Consequently, rather than
   providing one-for-one replacements for the two associations, a single
   higher-level association ReusablePolicy is defined.  This new association
   allows any policy element (that is, an instance of any subclass of the
   abstract class Policy) to be placed in a ReusablePolicyContainer.

   Summarizing, the following changes in Sections 5 and 6 are the result of
   this item:

     o The class ReusablePolicyContainer is defined.
     o PCIM's PolicyRepository class is deprecated.
     o The association ReusablePolicy is defined.
     o PCIM's PolicyConditionInPolicyRepository association is deprecated.
     o PCIM's PolicyActionInPolicyRepository association is deprecated.
     o The aggregation PolicyContainerInPolicyContainer is defined.
     o PCIM's PolicyRepositoryInPolicyRepository aggregation is deprecated.

 4.3. Policy Sets

   A "policy" can be thought of as a coherent set of rules to administer,
   manage, and control access to network resources (PolTerm, reference
   [12]).  The structuring of these coherent sets of rules into subsets is
   enhanced in this document.  In section 4.4, we discuss the new options
   for the nesting of policy rules.

   A new abstract class, PolicySet, is introduced to provide an abstraction
   for a set of rules.  It is derived from Policy, and it is inserted into
   the inheritance hierarchy above both PolicyGroup and PolicyRule.  This
   reflects the additional structure flexibility and semantic capability of
   both subclasses.

   Two properties are defined in PolicySet: PolicyDecisionStrategy and
   PolicyRoles.  PolicyDecisionStrategy is added to PolicySet to define the
   evaluation relationship between the rules in the policy set.  See section
   4.5 for more information.  PolicyRoles is added to PolicySet to name the
   retrieval sets.  See section 4.6 for more information.

   Along with the definition of the PolicySet class, a new abstract concrete
   aggregation class is defined that will also be discussed in the following
   sections.  PolicySetComponent is defined as a subclass of
   PolicyComponent; it provides the containment relationship for a PolicySet
   in a PolicySet.  PolicySetComponent replaces the two PCIM aggregations
   PolicyGroupInPolicyGroup and PolicyRuleInPolicyGroup PolicyRuleInPolicyGroup, so these two
   aggregations are
   modified deprecated.

   The PolicySet relationship to subclass from PolicySetComponent.  PolicyGroupInPolicyRule
   and PolicyRuleInPolicyRule, discussed an AdminDomain or other administrative
   scoping system (e.g., a ComputerSystem) is defined in the next section,
   PolicySetInSystem abstract association.  This new association is derived
   from PolicyInSystem, and the PolicyGroupInSystem and PolicyRuleInSystem
   associations are also
   defined as subclasses now derived from PolicySetInSystem instead of PolicySetComponent. directly
   from PolicyInSystem.  The PolicySetInSystem.Priority property is
   discussed in section 4.5.

 4.4. Nested 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
   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
   document interchangeably.  Two new aggregations are defined for this
   purpose: PolicyRuleInPolicyRule and PolicyGroupInPolicyRule.  The aggregation PolicySetComponent is used to
   represent the nesting of a policy rule in another policy rule.

 4.4.1. Usage Rules for Nested Rules

   The relationship between rules and sub-rules is defined as follows:

     o   The parent rule's condition clause is a pre-condition for
         evaluation of all nested rules. If the parent rule's condition
         clause evaluates to FALSE, all sub-rules SHALL be skipped and
         their condition clauses SHALL NOT be evaluated.
     o   If the parent rule's condition evaluates to TRUE, the set of sub-
         rules SHALL BE executed according to the decision strategy and
         priorities as discussed in Section 4.5.
     o   If the parent rule's condition evaluates to TRUE, the parent
         rule's set of actions is executed BEFORE the evaluation and execution of the sub-rules. sub-
         rulesÆ actions.  The parent rule's actions are not to be confused
         with default actions.  A default action is one that is to be
         executed only if none of the more specific sub-rules are executed.
         If a default action needs to be specified, it needs to be defined
         as an action that is part of a catchall sub-rule associated with
         the parent rule.  The association linking the default action(s) in
         this special sub-rule should have the lowest priority relative to
         all other sub-rule associations:

                if precondition then parent rule's action
                      if condA then actA
                      if condB then ActB
                      if True then default action

         Default actions have meaning when FirstMatching decision
         strategies are in effect (see section 4.5).

    o    Policy rules have an implicit context in which they are executed.
         For example, the context of a policy rule could be all packets
         running on an interface or set of interfaces on which the rule is
         applied.  Similarly, a parent rule provides a context to all of
         its sub-rules.  The context of the sub-rules is the restriction of
         the context of the parent rule to the set of cases that match the
         parent rule's condition clause.

 4.4.2. Motivation

   The motivation for introducing nested rules includes enhancing the
   definition of Policy, defining and reusing context hierarchies,
   optimizing how a rule is evaluated, and providing finer-grained control
   over condition evaluation.

   Rule nesting enhances Policy readability, expressiveness and reusability.
   The ability to nest policy rules and form sub-rules is important for
   manageability and scalability, as it enables complex policy rules to be
   constructed from multiple simpler policy rules.  These enhancements ease
   the policy management tools' task, allowing policy rules to be expressed
   in a way closer to how humans think.

   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
   parent rules.  This scoping, or context of evaluation and execution, is a
   powerful tool in enabling the policy designer to obtain the fine-grained
   control needed to appropriately manage resources for certain
   applications.  The example in the following section demonstrates that
   expressing relative bandwidth allocation rules can be done very naturally
   using a hierarchical rule structure.

   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
   FALSE, all sub-rules are skipped, optimizing the number of lookups
   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
   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
   optimizer can create a more efficient machine code than any optimization
   done by the programmer within the source code.  Nevertheless, if the PEP
   or PDP does not do optimization, the administrator writing the policy can
   optimize the policy rules for execution using rule nesting.

   In

   Evaluation of some conditions does not require simple examination of a model where
   field within a packet.  For example, condition evaluation may have side effects, nesting
   rules allow control of condition evaluation, as sub-rule conditions SHALL
   NOT be evaluated if require a
   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 of the parent
   evaluations should be minimized, as they cause delay in rule evaluates to FALSE. evaluation,
   load the network and other resources, and may have undesirable side
   effects.

   Nested rules are not designed for policy repository retrieval
   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
   enforced.  Optimizing the number of rules retrieved should be done by
   clever selection of roles.

 4.4.3. Usage Example

   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.
   Consider the following example, where a set of rules is used to specify
   the minimal bandwidth allocations on an interface.  The policy reads:

         On any interface on which these rules apply, allocate guarantee at least
         30% of the interface bandwidth to UDP flows, and at least 40% of
         the interface bandwidth to TCP flows.

   This single

   When formatted in the condition and action rule is translated to a set of two rules: structure, the policy
   reads:

     If (IP protocol is UDP) THEN Set MinBW to (guarantee 30% of available BW) (1)
     If (IP protocol is TCP) THEN Set MinBW to (guarantee 40% of available BW) (2)

   Now, let's add some sub-rules to further differentiate how bandwidth
   should be allocated to specific UDP and TCP applications (indentation
   indicates rule nesting):

     If (IP protocol is UDP) THEN Set MinBW to (guarantee 30% of available BW) (1)
           If (protocol is TFTP) THEN Set MinBW to (guarantee 10% of available BW)     (1a)
           If (protocol is NFS) THEN Set MinBW to (guarantee 40% of available BW) (1b)
     If (IP protocol is TCP) THEN Set MinBW to (guarantee 40% of available BW) (2)
           If (protocol is HTTP) THEN Set MinBW to guarantee 20% of available BW) (2a)
           If (protocol is FTP) THEN Set MinBW to (guarantee 30% of available BW) (2b)
   This means that for

   The UDP flows, sub-rules specify that TFTP should be allocated 10% of the
   bandwidth allocated to UDP while NFS should be allocated 40%. 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)
   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:
   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
   flows only.  Similar functionality applies for the hierarchy of rules
   treating TCP flows.

   A context hierarchy enhances reusability.  The rules that divide
   bandwidth between TFTP and NFS can be re-used and associated to rules
   that allocate different percentages of the bandwidth for different
   interfaces (or even for the same interface, but under different
   conditions) for UDP.

 4.5. Priorities

   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 Decision Strategies

   A "decision strategy" is used the rest of UDP packets to specify the evaluation 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

   A "decision strategy" is used to specify the evaluation method for the
   policies in a PolicySet.  Two decision strategies are defined:
   "FirstMatching" and "AllMatching."  The FirstMatching strategy is used to
   cause the evaluation of the rules in a set such that the actions of only
   the first rule that matches are actions
   enforced on a given examination of the
   PolicySet. PolicySet are those for the first
   rule (that is, the rule with the highest priority) that has its
   conditions evaluate to TRUE.  The AllMatching strategy is used to cause
   the evaluation of all rules in a set; for all of the rules that match, whose
   conditions evaluate to TRUE, the actions are enforced.  (Strawman:  Implementations
   MUST support the FirstMatching decision strategy; implementations MAY
   support the AllMatching decision
   strategy.) strategy.

   As previously discussed, the PolicySet subclasses are PolicyGroup and
   PolicyRule, and
   PolicyRule: either subclass may contain PolicySets of either subclass.
   Loops, including the degenerate case of a PolicySet that contains itself,
   are not allowed when PolicySets contain other PolicySets.  The
   containment relationship is specified using the PolicySetComponent subclasses: PolicyGroupInPolicyGroup,
   PolicyRuleInPolicyGroup, PolicyGroupInPolicyRule and
   PolicyRuleInPolicyRule.
   aggregation.

   The order of evaluation relative priority within a PolicySet is established by the Priority
   property of the PolicySetComponent aggregation.  Instances of the
   subclasses of PolicySetComponent specify the relative priority aggregation of the contained policy groups PolicyGroup
   and rules within the containing group or rule. PolicyRule instances.  The use of PCIM's PolicyRule.Priority property
   is deprecated in favor of this new property.  The separation of the
   priority property from the rule has two advantages.  First, it
   generalizes the concept of priority, so it can be used for both groups
   and rules; and, second, it places the priority on the relationship
   between the parent policy set and the subordinate policy group or rule.
   The assignment of a priority value, 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
   PolicySetComponent.Priority determine the processing for the rules
   contained in a PolicySet.  As before, the larger priority value
   represents the higher priority.  Unlike the earlier definition,
   PolicySetComponent.Priority MUST have a unique value when compared with
   others defined for the aggregating PolicySet.  Thus, the evaluation of
   rules within a set is deterministically specified.

   For a FirstMatching decision strategy, the order of evaluation, then, is
   high to low priority.  The first rule (i.e., the one with
   the highest priority) in the set that evaluates to True, is the only rule
   whose actions are enforced for a particular evaluation pass through the
   PolicySet.

   For an AllMatching decision strategy, the order of evaluation is also
   from high priority to low priority; however, all of the matching rules are executed.  Although
   enforced.  The relative priority of the rules is used to determine the
   order in which the actions are to be executed by the enforcement point:
   the actions of the higher priority rules are evaluated executed first.    Since the
   actions of higher priority rules are executed first, lower priority rules
   that also match may get the "last word." word," and thus produce a counter-
   intuitive result.  So, for example, if two rules both evaluate to True,
   and the higher priority rule sets the DSCP to 3 and the lower priority
   rule sets the DSCP to 4, the action of the lower priority rule will be evaluated
   executed later and, therefore, will "win," in this example, setting the
   DSCP to 4.  Thus, conflicts between rules are resolved by this evaluation 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

   When policy sets are nested, as shown in Figure 3, the decision
   strategies may be nested arbitrarily.  In this example, the evaluation
   order relative
   priorities for the nested rules is rules, high to low, are 1A, 1B1, 1X2, 1B3, 1C,
   1C1, 1X2 and 1C3.  (Note that PolicyRule 1X2 is included in both
   PolicyGroup 1B and PolicyRule 1C, but with different priorities.)  Of
   course, the evaluation
   order which rules are enforced is also dependent on which rules, if
   any, match.

   PolicyGroup 1: FirstMatching
     |
     +-- Pri=6 -- PolicyRule 1A
     |
     +-- Pri=5 -- PolicyGroup 1B: AllMatching
     |              |
     |              +-- Pri=5 -- PolicyGroup 1B1: AllMatching
     |              |              |
     |              |              +---- etc.
     |              |
     |              +-- Pri=4 -- PolicyRule 1X2
     |              |
     |              +-- Pri=3 -- PolicyRule 1B3: FirstMatching
     |                             |
     |                             +---- etc.
     |
     +-- Pri=4 -- PolicyRule 1C: FirstMatching
                    |
                    +-- Pri=4 -- PolicyRule 1C1
                    |
                    +-- Pri=3 -- PolicyRule 1X2
                    |
                    +-- Pri=2 -- PolicyRule 1C3

   Figure 3.    Nested PolicySets with Different Decision Strategies
     o   Because PolicyGroup 1 has a FirstMatching decision strategy, if
         the conditions of PolicyRule 1A match, its actions are enforced
         and the evaluation stops.

     o   If it does not match, PolicyGroup 1B is evaluated using an
         AllMatching strategy.  Since PolicyGroup 1B1 also has an
         AllMatching strategy all of the rules and groups of rules
         contained in PolicyGroup 1B1 are evaluated and enforced as
         appropriate. PolicyRule 1X2 and PolicyRule 1B3 are also evaluated
         and enforced as appropriate.  If any of the sub-rules in the
         subtrees of PolicyGroup 1B evaluate to True, then PolicyRule 1C is
         not evaluated because the FirstMatching strategy of PolicyGroup 1
         has been satisfied.

     o   If neither PolicyRule 1A nor PolicyGroup 1B yield a match, then
         PolicyRule 1C is evaluated.  Since it is first matching, rules
         1C1, 1X2, and 1C3 are evaluated until the first match, if any.

 4.5.2. Deterministic Decisions

   As mentioned above, we propose that Priority values are to be unique
   within a containing PolicySet. Side Effects

   Although there are certainly cases where
   rules evaluation of conditions is sometimes discussed as an ordered
   set of operations, the rule engine need not have be implemented as a unique priority value (i.e., where
   procedural language interpreter. Any side effects of condition evaluation and
   or the execution order is not important), it is believed that of actions MUST NOT affect the flexibility
   gained result of the evaluation
   of other conditions evaluated by this capability is not sufficiently beneficial to justify the
   possible variations rule engine in implementation behavior and the resulting
   confusion that might occur.

   Therefore, same evaluation
   pass.  That is, an implementation of a rule engine MAY evaluate all PolicySetComponent.Priority values MUST be unique among
   the values
   conditions in any order before applying the aggregating PolicySet.  Each PolicySet, then, has priority and determining
   which actions are to be executed.

   So, regardless of how a
   deterministic behavior based upon rule engine is implemented, it MUST NOT include
   any side effects of condition evaluation in the evaluation of conditions
   for either of the decision strategies.  For both the AllMatching decision
   strategy and uniquely
   defined order for the nesting of evaluation. 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

   As shown in the example in Figure 3, PolicySet trees are defined by the
   PolicySet subclass instances and the PolicySetComponent subclass aggregation
   instances between them.  Each PolicySet tree has a defined set of
   decision strategies and evaluation orders. priorities.  In section 4.6 we discuss
   some improvements in the use of PolicyRoles that cause the parent
   PolicySet.PolicyRoles to be applied to all contained PolicySet instances.
   However, a given resource may still have multiple, disjoint PolicySet trees; we need a join
   algorithm
   trees that describes the decision strategy are collected from different roles and evaluation order among
   the role combinations.
   Note that these top-level PolicySet instances (called "unrooted") PolicySet instances.  (Note that an
   unrooted PolicySet instance may
   only be unrooted in a given context.)

   <<Solution under discussion - see Open Issue 9>>

 4.6. Policy Roles

   A policy role context.

   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 [12] as "an administratively specified
   characteristic of a managed element (for example, an interface).  It the PolicySetInSystem
   association.

   The FirstMatching strategy is used among all PolicySet instances that
   apply to a
   selector given resource for a given functional domain.  So, for
   example, the PolicySet instances that are used for QOS policy rules and PRovisioning Classes (PRCs), to determine
   the applicability of the rule/PRC to a particular managed element."

   In PCIMe,
   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

   A policy role is defined in [12] as "an administratively specified
   characteristic of a managed element (for example, an interface).  It is a
   selector for policy rules and PRovisioning Classes (PRCs), to determine
   the applicability of the rule/PRC to a particular managed element."

   In PCIMe, PolicyRoles is defined as a property of PolicySet, which is
   inherited by both PolicyRules and PolicyGroups.  In this draft, we also
   add PolicyRole as the identifying name of a collection of resources
   (PolicyRoleCollection), where each element in the collection has the
   specified role characteristic.

 4.6.1. Comparison of Roles in PCIM with Roles in snmpconf

   In the Configuration Management with SNMP (snmpconf) working group's
   Policy Based Management MIB [13], policy rules are of the form

     if <policyFilter> then <policyAction>

   where <policyFilter> is a set of conditions that are used to determine
   whether or not the policy applies to an object instance. The policy
   filter can perform comparison operations on SNMP variables already
   defined in MIBS (e.g., "ifType == ethernet").

   The policy management MIB defined in [13] defines a Role table that
   enables one to associate Roles with elements, where roles have the same
   semantics as in PCIM. Then, since the policyFilter in a policy allows one
   to define conditions based on the comparison of the values of SNMP
   variables, one can filter elements based on their roles as defined in the
   Role group.

   This approach differs from that adopted in PCIM in the following ways.
   First, in PCIM, a set of role(s) is associated with a policy rule as the
   values of the PolicyRoles property of a policy rule. The semantics of
   role(s) are then expected to be implemented by the PDP (i.e. policies are
   applied to the elements with the appropriate roles). In [draft-ietf-
   snmpconf-pm-04], however, no special processing is required for realizing
   the semantics of roles; roles are treated just as any other SNMP
   variables and comparisons of role values can be included in the policy
   filter of a policy rule.

   Secondly, in PCIM, there is no formally defined way of associating a role
   with an object instance, whereas in [13] this is done via the use of the
   Role tables (pmRoleESTable and pmRoleSETable). The Role tables associate
   Role values with elements.

 4.6.2. Addition of PolicyRoleCollection to PCIMe

   In order to remedy the latter shortcoming in PCIM (i.e. the lack of a way
   of associating a role with an object instance), we define a new class
   PolicyRoleCollection that subclasses from the CIM Collection class.
   Resources that share a common role belong to a PolicyRoleCollection
   instance.  Membership in this collection is indicated using the
   aggregation ElementInPolicyRoleCollection.  The resource's role is
   specified in the PolicyRole property of the PolicyRoleCollection class.

   A PolicyRoleCollection always exists in the context of a system.  As was
   done in PCIM for PolicyRules and PolicyGroups, this is captured by an
   association, PolicyRoleCollectionInSystem.  Remember that in PCIM, a
   System is a base class for describing network devices and administrative
   domains.

   When associating a PolicyRoleCollection with a System, this should be
   done consistently with the system that scopes the policy rules/groups
   that are applied to the resources in that collection.  A
   PolicyRoleCollection is associated with the same system as the applicable
   PolicyRules and/or PolicyGroups, or to a System higher in the tree formed
   by the SystemComponent association.  When a PEP belongs to multiple
   Systems (i.e., AdminDomains), and scoping by a single domain is
   impractical, two alternatives exist.  One is to arbitrarily limit domain
   membership to one System/AdminDomain.  The other option is to define a
   more global AdminDomain that simply includes the others, and/or that
   spans the business or enterprise.

   As an example, suppose that there are 20 traffic trunks in a network, and
   that an administrator would like to assign three of them to provide
   "gold" service.  Also, the administrator has defined several policy rules
   which specify how the "gold" service is delivered.  For these rules, the
   PolicyRoles property (inherited from PolicySet) is set to "Gold Service".

   In order to associate three traffic trunks with "gold" service, an
   instance of the PolicyRoleCollection class is created and its PolicyRole
   property is also set to "Gold Service".  Following this, the
   administrator associates three traffic trunks with the new instance of
   PolicyRoleCollection via the ElementInPolicyRoleCollection aggregation.
   This enables a PDP to determine that the "Gold Service" policy rules
   apply to the three aggregated traffic trunks.

   Note that roles are used to optimize policy retrieval.  It is not
   mandatory to implement roles or, if they have been implemented, to group
   elements in a PolicyRoleCollection.  However, if roles are used, then
   either the collection approach should be implemented, or elements should
   be capable of reporting their "pre-programmed" roles (as is done in
   COPS).

 4.6.3. Roles for PolicyGroups

   In PCIM, role(s) are only associated with policy rules.  However, it may
   be desirable to associate role(s) with groups of policy rules.  For
   example, a network administrator may want to define a group of rules that
   apply only to Ethernet interfaces.  A policy group can be defined with a
   role-combination="Ethernet", and all the relevant policy rules can be
   placed in this policy group.  (Note that in PCIMe, role(s) are made
   available to PolicyGroups as well as to PolicyRules by moving PCIM's
   PolicyRoles property up from PolicyRule to the new abstract class
   PolicySet.  The property is then inherited by both PolicyGroup and
   PolicyRule.)  Then every policy rule in this policy group implicitly
   inherits this role-combination from the containing policy group.  A
   similar implicit inheritance applies to nested policy groups.

   Note that there is no explicit copying of role(s) from container to
   contained entity.  Obviously, this implicit inheritance of role(s) leads
   to the possibility of defining inconsistent role(s) (as explained in the
   example below); the handling of such inconsistencies is beyond the scope
   of PCIMe.

   As an example, suppose that there is a PolicyGroup PG1 that contains
   three PolicyRules, PR1, PR2, and PR3.  Assume that PG1 has the roles
   "Ethernet" and "Fast".  Also, assume that the contained policy rules have
   the role(s) shown below:

   +------------------------------+
   | PolicyGroup PG1              |
   | PolicyRoles = Ethernet, Fast |
   +------------------------------+
              |
              |        +------------------------+
              |        | PolicyRule PR1         |
              |--------| PolicyRoles = Ethernet |
              |        +------------------------+
              |
              |        +--------------------------+
              |        | PolicyRule PR2           |
              |--------| PolicyRoles = <undefined>|
              |        +--------------------------+
              |
              |        +------------------------+
              |        | PolicyRule PR3         |
              |--------| PolicyRoles = Slow     |
                       +------------------------+

   Figure 4.    Inheritance of Roles

   In this example, the PolicyRoles property value for PR1 is consistent
   with the value in PG1, and in fact, did not need to be redefined.  The
   value of PolicyRoles for PR2 is undefined.  Its roles are implicitly
   inherited from PG1. Lastly, the value of PolicyRoles for PR3 is "Slow".
   This appears to be in conflict with the role, "Fast," defined in PG1.
   However, whether these roles are actually in conflict is not clear.  In
   one scenario, the policy administrator may have wanted only "Fast"-
   "Ethernet" rules in the policy group.  In another scenario, the
   administrator may be indicating that PR3 applies to all "Ethernet"
   interfaces regardless of whether they are "Fast" or "Slow."  Only in the
   former scenario (only "Fast"-"Ethernet" rules in the policy group) is
   there a role conflict.

   Note that it is possible to override implicitly inherited roles via
   appropriate conditions on a PolicyRule.  For example, suppose that PR3
   above had defined the following conditions:

     (interface is not "Fast") and (interface is "Slow")

   This results in unambiguous semantics for PR3.

 4.7. Compound Policy Conditions and Compound Policy Actions

   Compound policy conditions and compound policy actions are introduced to
   provide additional reusable "chunks" of policy.

 4.7.1. Compound Policy Conditions

   A CompoundPolicyCondition is a PolicyCondition representing a Boolean
   combination of simpler conditions.  The conditions being combined may be
   SimplePolicyConditions (discussed below in section 4.7), but the utility
   of reusable combinations of policy conditions is not necessarily limited
   to the case where the component conditions are simple ones.

   The PCIM extensions to introduce compound policy conditions are
   relatively straightforward.  Since the purpose of the extension is to
   apply the DNF / CNF logic from PCIM's PolicyConditionInPolicyRule
   aggregation to a compound condition that aggregates simpler conditions,
   the following changes are required:

      o Create a new aggregation PolicyConditionInPolicyCondition, with the
        same GroupNumber and ConditionNegated properties as
        PolicyConditionInPolicyRule.  The cleanest way to do this is to
        move the properties up to a new abstract aggregation superclass
        CompoundedPolicyCondition, from which the existing aggregation
        PolicyConditionInPolicyRule and a new aggregation
        PolicyConditionInPolicyCondition are derived.  For now there is no
        need to re-document the properties themselves, since they are
        already documented in PCIM as part of the definition of the
        PolicyConditionInPolicyRule aggregation.
      o It is also necessary to define a concrete subclass
        CompoundPolicyCondition of PolicyCondition, to introduce the
        ConditionListType property.  This property has the same function,
        and works in exactly the same way, as the corresponding property
        currently defined in PCIM for the PolicyRule class.

   The class and property definitions for representing compound policy
   conditions are below, in Section 5.

 4.7.2. Compound Policy Actions

   A compound action is a convenient construct to represent a sequence of
   actions to be applied as a single atomic action within a policy rule.  In
   many cases, actions are related to each other and should be looked upon
   as sub-actions of one "logical" action.  An example of such a logical
   action is "shape & mark" (i.e., shape a certain stream to a set of
   predefined bandwidth characteristics and then mark these packets with a
   certain DSCP value).  This logical action is actually composed of two
   different QoS actions, which should be performed in a well-defined order
   and as a complete set.

   The CompoundPolicyAction construct allows one to create a logical
   relationship between a number of actions, and to define the activation
   logic associated with this logical action.

   The CompoundPolicyAction construct allows the reusability of these
   complex actions, by storing them in a ReusablePolicyContainer and reusing
   them in different policy rules.  Note that a compound action may also be
   aggregated by another compound action.

   As was the case with CompoundPolicyCondition, the PCIM extensions to
   introduce compound policy actions are relatively straightforward.  This
   time the goal is to apply the property ActionOrder from PCIM's
   PolicyActionInPolicyRule aggregation to a compound action that aggregates
   simpler actions.  The following changes are required:

      o Create a new aggregation PolicyActionInPolicyAction, with the same
        ActionOrder property as PolicyActionInPolicyRule.  The cleanest way
        to do this is to move the property up to a new abstract aggregation
        superclass CompoundedPolicyAction, from which the existing
        aggregation PolicyActionInPolicyRule and a new aggregation
        PolicyActionInPolicyAction are derived.  For now there is no need
        to re-document the ActionOrder property itself, since it is already
        documented in PCIM as part of the definition of the
        PolicyActionInPolicyRule aggregation.
      o It is also necessary to define a concrete subclass
        CompoundPolicyAction of PolicyAction, to introduce the
        SequencedActions property.  This property has the same function,
        and works in exactly the same way, as the corresponding property
        currently defined in PCIM for the PolicyRule class.
      o Finally, a new property ExecutionStrategy is needed for both the
        PCIM class PolicyRule and the new class CompoundPolicyAction.  This
        property allows the policy administrator to specify how the PEP
        should behave in the case where there are multiple actions
        aggregated by a PolicyRule or by a CompoundPolicyAction.

   The class and property definitions for representing compound policy
   actions are below, in Section 5.

   Compound actions allow the definition of logically complex policy rules
   and action behavior.  The following example illustrates two advantages of
   using compound actions.

   A QoS policy domain may include a rule that defines the following
   behavior:

     If (CONDITION) Then Do:
       "Shape traffic to <X> and Set DSCP to EF (high priority traffic);
        if canÆt shape than Set DSCP to BE (best effort)."

   This rule can be realized by defining two CompoundPolicyAction instances,
   A and B.  Two sub-actions are grouped into CompoundPolicyAction A:

        Shape traffic to <X>
        Mark to EF (DSCP).

   The ExecutionStrategy property of CompoundPolicyAction A would be defined
   as "Mandatory Do all".  This means that if shaping or marking cannot both
   be done, then nothing should be done.

   A second action, CompoundPolicyAction B, would hold the Mark to BE sub-
   action.

   CompoundPolicyAction A and CompoundPolicyAction B would be aggregated
   into the policy rule using the PolicyActionInPolicyRule aggregation.  The
   CompoundPolicyAction A will be ordered for execution before the
   CompoundPolicyAction B.  The PolicyRule's ExecutionStrategy property
   would be set to "Do until success".  In this way, CompoundPolicyAction A
   will be enforced on all PEPs that support shaping, while
   CompoundPolicyAction B will be enforced otherwise.

 4.8. Variables and Values

   The following subsections introduce several related concepts, including
   PolicyVariables and PolicyValues (and their numerous subclasses),
   SimplePolicyConditions, and SimplePolicyActions.

 4.8.1. Simple Policy Conditions

   The SimplePolicyCondition class models elementary Boolean conditional
   expressions of the form: "If (<variable> MATCH <value>)".  The "If"
   clause and the "MATCH" are implied in the formal notation.  The
   relationship is always 'MATCH' and is interpreted based on the variable
   and the value.  Section 4.8.3 explains the semantics of the operator and
   how to extend them.  Arbitrarily complex Boolean expressions can be
   formed by chaining together any number of simple conditions using
   relational operators.  Individual simple conditions can be negated as
   well.  Arbitrarily complex Boolean expressions are modeled by the class
   CompoundPolicyCondition (described in section 4.7.1).

   For example, the expression "If SourcePort == 80" can be modeled by a
   simple condition.  In this example, 'SourcePort' is a variable, '==' is
   the relational operator denoting the equality relationship (which is
   generalized by PCIMe to a "match" relationship), and '80' is an integer
   value.  The complete interpretation of a simple condition depends on the
   binding of the variable.  Section 4.8.5 describes variables and their
   binding rules.

   The SimplePolicyCondition class refines the basic structure of the
   PolicyCondition class defined in PCIM by using the pair <variable> and
   <value> to form the condition.  Note that the operator between the
   variable and the value is always implied in PCIMe: it is not a part of
   the formal notation.

   The variable specifies the attribute of an object that should be matched
   when evaluating the condition.  For example, for a QoS derivation, this
   object could represent the flow that is being conditioned.  A set of
   predefined variables that cover network attributes that are commonly used
   for filtering is introduced here in PCIMe to encourage interoperability.
   This list covers layer 3 IP attributes such as IP network addresses,
   protocols and ports, as well as a set of layer 2 attributes (e.g., MAC
   addresses).

   The PCIMe defines a single operator, "match", as explained in section
   4.8.3.

   The bound variable is matched against a value to produce the Boolean
   result.  For example, in the condition "If the source IP address of the
   flow belongs to the 10.1.x.x subnet", a source IP address variable is
   matched against a 10.1.x.x subnet value.  The operator specifies the type
   of relation between the variable and the value evaluated in the
   condition.

 4.8.2. Using Simple Policy Conditions

   Simple conditions can be used in policy rules directly, or as building
   blocks for creating compound policy conditions.

   Simple condition composition MUST enforce the following data-type
   conformance rule: The ValueTypes property of the variable must be
   compatible with the type of the value class used.  The simplest (and
   friendliest, from a user point-of-view) is to equate the type of the
   value class with the name of the class.  By ensuring that the ValueTypes
   property of the variable matches the name of the value class used, we
   know that the variable and value instance values are compatible with each
   other.

   Composing a simple condition requires that an instance of the class
   SimplePolicyCondition be created, and that instances of the variable and
   value classes that it uses also exist.  Note that the variable and/or
   value instances may already exist as reusable objects in an appropriate
   ReusablePolicyContainer.

   Two aggregations are used in order to create the pair <variable>,
   <value>.  The aggregation PolicyVariableInSimplePolicyCondition relates a
   SimplePolicyCondition to a single variable instance.  Similarly, the
   aggregation PolicyValueInSimplePolicyCondition relates a
   SimplePolicyCondition to a single value instance.  Both aggregations are
   defined in this document.

   Figure 5 depicts a SimplePolicyCondition with its associated variable and
   value.

                              +-----------------------+
                              | SimplePolicyCondition |
                              +-----------------------+
                                    *         @
                                    *         @
              +------------------+  *         @  +---------------+
              | (PolicyVariable) |***         @@@| (PolicyValue) |
              +------------------+               +---------------+
                 #            #
                 #    ooo     #
                 #            #
   +---------------+        +---------------+
   | (PolicyValue) |  ooo   | (PolicyValue) |
   +---------------+        +---------------+

   Aggregation Legend:
     ****  PolicyVariableInSimplePolicyCondition
     @@@@  PolicyValueInSimplePolicyCondition
     ####  PolicyValueConstraintInVariable

   Figure 5.    SimplePolicyCondition

   Note:  The class names in parenthesis denote subclasses.  The named
   classes in the figure are abstract and cannot, therefore, be
   instantiated.

 4.8.3. The Simple Condition Operator

   A simple condition models an elementary Boolean expression conditional
   clause of the form "If variable MATCHes value".  However, the formal
   notation of the SimplePolicyCondition, together with its associations,
   models only a pair, {variable, value}.  The "If" term and the "MATCH"
   operator are not directly modeled -- they are implied.  The implied MATCH
   operator carries an overloaded semantics.

   For example, in the simple condition "If DestinationPort MATCH '80'" the
   interpretation of the MATCH operator is equality (the 'equal' operator).
   Clearly, a different interpretation is needed in the following cases:

     o   "If DestinationPort MATCH {'80', '8080'}"  -- operator is 'IS SET
         MEMBER'

     o   "If DestinationPort MATCH {'1 to 255'}" -- operator is 'IN INTEGER
         RANGE'

     o   "If SourceIPAddress MATCH 'MyCompany.com'" -- operator is 'IP
         ADDRESS AS RESOLVED BY DNS'

   The examples above illustrate the implicit, context dependant nature of
   the interpretation of the MATCH operator.  The interpretation depends on
   the actual variable and value instances in the simple condition.  PCIMe
   does not contain text to explicitly detail the possible interpretations
   of MATCH operations.  The
   interpretation is always derived from the bound variable and the value
   instance associated with the simple condition.  Text accompanying the
   value class and implicit variable definition SHOULD be is used as a guideline for interpreting the
   semantics of the MATCH relationship.

   The PolicyValueConstraintInVariable association specifies additional
   constraints on  In the possible values that can following we define generic
   (type-independent) matching.

   PolicyValues may be matched with a variable
   within a simple condition.  Using this association multi-fielded, where each field may contain a source or
   destination port can be constrained range
   of values.  The same equally holds for PolicyVariables.  Basically, we
   have to be matched against integer deal with single values
   in (singleton), ranges ([lower bound ..
   upper bound]), and sets (a,b,c).  So independent of the range 0-65535.  A source or destination IP address can be
   constrained to be matched against a specified list variable and
   value type, the following set of IPv4 address
   values, etc.  In order 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 check whether true, if the singleton matches the lower
         bound or the upper bound or a value X can 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 used with a
   variable singleton or range again

     o   ranges [A..B] matches singleton -> is true if A constrained by value Y, matches B matches
         singleton

     o   range [A..B] matches range [X..Y] -> the following conformance test should
   be made.  If matching evaluates to
         true, if all events for which values of the SimplePolicyCondition (A range [A..B] are also in the range
         [X..Y].  For instance, [3..5] match X) [1..6] evaluates to TRUE also evaluate to TRUE for the SimplePolicyCondition (A true,
         whereas [3..5] match Y), than X conforms [4..6] evaluates to false.

     o   range [A..B] matches set (a,b,c, ...) -> the constraint Y.  If multiple matching evaluates to
         true, if all values Y1,
   Y2, ..., Yn constrain a variable, then in the conformance test involves
   checking against range [A..B] are part of the condition (A set.  For
         instance, range [2..3] match Y1) OR (A 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 Y2) OR ... OR (A match Yn).

 4.8.4. SimplePolicyActions

   The SimplePolicyAction class models the elementary singleton

     o   set operation. "SET
   <variable> TO <value>".  The match range -> the matching evaluates to true, if all values
         in the set operator MUST overwrite an old value are part of the variable. range.  For example, the action  "set DSCP to EF" can be modeled by a simple
   action.  In this example, 'DSCP' is an implicit variable referring set (2,3) match
         range [1..4] evaluates to true.

     o   set (a,b,c,...) match set (x,y,z,...) -> the
   IP packet header DSCP field.  'EF' is an integer or bit string value (6
   bits).  The complete interpretation of a simple action depends on the
   binding of the variable.  Section [4.8.4] describes variables and their
   binding rules for conditions.

   The SimplePolicyAction class refines matching evaluates to
         true, if all values in the basic structure set (a,b,c,...) are part of the
   PolicyAction class defined in PCIM, by specifying 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 contents type of the
   action using the <variable> <value> pair value bound to form the action.  The variable specifies at condition
   evaluation time and the attribute value type of an object that has passed the
   condition by evaluating PolicyValue instance need to true.  This means the binding be
   of the variable
   is delayed until same type.  If they differ the condition evaluates to true for one or more objects.
   The value of the object's attribute is set to <value>.

   SimplePolicyActions can be used in policy FALSE.

   Matching rules directly, or as building
   blocks for creating CompoundPolicyActions.

   SimplePolicyAction execution MUST enforce the following data value type
   conformance and translation rule: specific matching see below.

   The ValueTypes property of PolicyValueConstraintInVariable association specifies additional
   constraints on the variable
   must possible values and value types that can be compatible matched
   with a variable within a simple condition.  Using this association, a
   source or destination port can be constrained to be matched against
   integer values in the type of the value class used.  The following
   table shows the compatibility and transformation rules.  'ND' means the
   transformation is not defined.

   +------------------------------------------------------------------+
   |variable  | range 0-65535.  A source or destination IP address
   can be constrained to be matched against a specified list of IPv4 address
   values, etc.  In order to check whether a 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 can be used with a simple action requires that an instance of
   variable A constrained by value Y, the class
   SimplePolicyAction following conformance test should
   be created, and that instances of made.  If all events for which the variable and
   value classes that it uses SimplePolicyCondition (A match X)
   evaluates to TRUE also exist.  Note that the variable and/or
   value instances may already exist as reusable objects in an appropriate
   ReusablePolicyContainer.

   Two aggregations are used in order evaluate to create TRUE for the pair <variable> <value>.
   The aggregation PolicyVariableInSimplePolicyAction relates a
   SimplePolicyAction SimplePolicyCondition (A
   match Y), than X conforms to a single variable instance.  Similarly, the
   aggregation PolicyValueInSimplePolicyAction relates constraint Y.  If multiple values Y1,
   Y2, ..., Yn constrain a variable, then the conformance test involves
   checking against the condition (A match Y1) OR (A match Y2) OR ... OR (A
   match Yn).

 4.8.4. SimplePolicyActions

   The SimplePolicyAction class models the elementary set operation. "SET
   <variable> TO <value>".  The set operator MUST overwrite an old value of
   the variable.

   For example, the action  "set DSCP to EF" can be modeled by a single value instance.  Both aggregations are defined in simple
   action.  In this
   document.

   Figure 6 depicts a SimplePolicyAction with its associated variable and
   value.

                                 +-----------------------+
                                 | SimplePolicyAction    |
                                 |                       |
                                 +-----------------------+
                                       *         @
                                       *         @
                 +------------------+  *         @  +---------------+
                 | (PolicyVariable) |***         @@@| (PolicyValue) |
                 +------------------+               +---------------+
                    #            #
                    #    ooo     #
                    #            #
      +---------------+        +---------------+
      | (PolicyValue) |  ooo   | (PolicyValue) |
      +---------------+        +---------------+

      Aggregation Legend:
        ****  PolicyVariableInSimplePolicyAction
        @@@@  PolicyValueInSimplePolicyAction
        ####  PolicyValueConstraintInVariable

   Figure 6.    SimplePolicyAction

 4.8.5. Policy Variables

   A variable generically represents information that changes (or "varies"),
   and that example, 'DSCP' is set or evaluated by software.  In policy, conditions and
   actions can abstract information as "policy variables" an implicit variable referring to be evaluated in
   logical expressions, the
   IP packet header DSCP field.  'EF' is an integer or set by actions.

   PCIMe defines two types bit string value (6
   bits).  The complete interpretation of PolicyVariables, a PolicyImplicitVariable and
   a PolicyExplicitVariable.  The semantic difference between these classes
   is based simple action depends on modeling context.  Explicit variables are bound to exact
   model constructs, while implicit the
   binding of the variable.  Section [4.8.4] describes variables are defined and evaluated
   outside of a model, in a more subjective context.  For example, one can
   imagine a PolicyCondition testing their
   binding rules for a CIM ManagedSystemElement's Status
   property set to "Error." conditions.

   The Status property is an explicitly defined
   PolicyVariable (i.e., it is defined in SimplePolicyAction class refines the context basic structure of the CIM Schema and
   evaluated
   PolicyAction class defined in PCIM, by specifying the context contents of a specific instance).  On the other hand,
   network packets are not explicitly modeled or instantiated, since there
   is no perceived value (at this time) in managing at
   action using the packet level.
   Therefore, a PolicyCondition can make no explicit reference <variable> <value> pair to a model
   construct that represents a network packet's source address.  In this
   case, form the action.  The
   variable specifies the attribute of an implicit PolicyVariable is defined object that has passed the
   condition by evaluating to allow evaluation true.  This means the binding of a
   packet's source address.

 4.8.6. Explicitly Bound Policy Variables

   Explicitly bound policy variables indicate the class and property names variable
   is delayed until the condition evaluates to true for one or more objects.
   The value of the model construct object's attribute is set to <value>.

   SimplePolicyActions can be evaluated used in policy rules directly, or set.  The CIM Schema defines
   and constrains "appropriate" values as building
   blocks for creating CompoundPolicyActions.

   The set operation is only valid if the variable (i.e., model
   property) using data list of types and other information such as class/property
   qualifiers.

   A PolicyExplicitVariable of the variable
   (ValueTypes property of PolicyImplicitVariable) includes the specified
   type of the value.  Conversion of values from one representation into
   another is "explicit" because its model semantics are
   exactly not defined.  It is NOT explicit due to an exact binding to  E.g., a
   particular object.  If PolicyExplicitVariable is only tied variable of IPv4Address type may not be
   set to instances
   (either via association or by a object identification property in the
   class itself), then we string containing a DNS name.  Conversions are forcing element-specific rules.  On part of an
   implementation-specific mapping of the other
   hand, if we only specify model.

   Composing a simple action requires that an instance of the object's model context (class class
   SimplePolicyAction be created, and property
   name), but leave the binding to the policy framework (for example, using
   policy roles), then greater flexibility results for either general or
   element-specific rules.

   For example, an element-specific rule is obtained by a condition
   (variable/operator/value triplet) that defines, for example, CIM
   LogicalDevice DeviceID="12345".  Alternately, if a PolicyRule's
   PolicyRoles is "edge device" and your condition (variable/operator/value
   triplet) is Status="Error", then a general rule results for all edge
   devices in error.

   Refer to Section 5.10 for the formal definition instances of the class
   PolicyExplicitVariable.

 4.8.7. Implicitly Bound Policy Variables

   Implicitly bound policy variables define the data type variable and semantics of a
   variable.  This determines how
   value classes that it uses also exist.  Note that the variable is bound to a value in a
   condition clause.  Further instructions are provided for specifying data
   type and/or
   value constraints for implicitly bound variables.

   Implicitly bound variables can be interpreted by different sub-models to
   mean different things, depending on the particular context instances may already exist as reusable objects in which they
   are used.  For example, an implicitly bound variable named "SourceIP" may
   be interpreted by a QoS policy information model to denote the source
   address field appropriate
   ReusablePolicyContainer.

   Two aggregations are used in order to create the IP header of a packet if pair <variable> <value>.
   The aggregation PolicyVariableInSimplePolicyAction relates a device is configured
   SimplePolicyAction to
   select certain packets for particular treatment.  The same a single variable may
   be bound to instance.  Similarly, the sender address delivered by
   aggregation PolicyValueInSimplePolicyAction relates a RSVP PATH message for SimplePolicyAction
   to a
   decision by single value instance.  Both aggregations are defined in this
   document.

   Figure 6 depicts a policy server.  It is incumbent upon the particular domain-
   specific SimplePolicyAction with its associated variable and

   value.

                                 +-----------------------+
                                 | SimplePolicyAction    |
                                 |                       |
                                 +-----------------------+
                                       *         @
                                       *         @
                 +------------------+  *         @  +---------------+
                 | (PolicyVariable) |***         @@@| (PolicyValue) |
                 +------------------+               +---------------+
                    #            #
                    #    ooo     #
                    #            #
      +---------------+        +---------------+
      | (PolicyValue) |  ooo   | (PolicyValue) |
      +---------------+        +---------------+

      Aggregation Legend:
        ****  PolicyVariableInSimplePolicyAction
        @@@@  PolicyValueInSimplePolicyAction
        ####  PolicyValueConstraintInVariable

   Figure 6.    SimplePolicyAction

 4.8.5. Policy Variables

   A variable generically represents information model to provide full that changes (or "varies"),
   and unambiguous interpretation
   details (binding rules, type that is set or evaluated by software.  In policy, conditions and value constraints) for the implicitly
   bound variables it uses.

   PCIMe introduces an
   actions can abstract class, PolicyImplicitVariable, information as "policy variables" to model
   implicitly bound variables.  This class is derived from the abstract
   class PolicyVariable also defined be evaluated in PCIMe.  Each of the implicitly bound
   variables introduced
   logical expressions, or set by actions.

   PCIMe (and those that are introduced by domain-
   specific sub-models) MUST be derived from the defines two types of PolicyVariables, a PolicyImplicitVariable
   class. and
   a PolicyExplicitVariable.  The rationale for using this mechanism for modeling semantic difference between these classes
   is explained
   below in Section 4.8.9.

   A domain-specific policy information model that extends PCIMe may define
   additional implicitly based on modeling context.  Explicit variables are bound to exact
   model constructs, while implicit variables either by deriving them directly
   from the class PolicyImplicitVariable, or by further refining an existing
   variable class such as SourcePort.  When refining a class such as
   SourcePort, existing binding rules, type or value constraints may be
   narrowed.

 4.8.8. Structure are defined and Usage evaluated
   outside of Pre-Defined Variables

   A class derived from PolicyImplicitVariable to model a particular
   implicitly bound variable SHOULD be constructed so that its name depicts
   the meaning of the variable. model, in a more subjective context.  For example, one can
   imagine a class defined to model the
   source port of PolicyCondition testing for a TCP/UDP flow SHOULD be named 'SourcePort'.

   PCIMe defines one association and one general-purpose mechanism that
   together characterize each of the implicitly bound variables that it
   introduces:

     1.  The PolicyValueConstraintInVariable association defines the CIM ManagedSystemElement's Status
   property set of
         value classes that could be matched to this variable.

     2. "Error."  The list of constraints on the values that the Status property is an explicitly defined
   PolicyVariable can
         hold (i.e., values that the variable must match) are it is defined by in the appropriate properties context of an associated PolicyValue class.

   In the example presented above, a PolicyImplicitVariable represents CIM Schema and
   evaluated in the
   SourcePort of incoming traffic.  The ValueTypes property context of a specific instance).  On the other hand,
   network packets are not explicitly modeled or instantiated, since there
   is no perceived value (at this time) in managing at the packet level.
   Therefore, a PolicyCondition can make no explicit reference to a model
   construct that represents a network packet's source address.  In this
   case, an instance implicit PolicyVariable is defined to allow evaluation of this class will hold a
   packet's source address.

 4.8.6. Explicitly Bound Policy Variables

   Explicitly bound policy variables indicate the class name PolicyIntegerValue.  This by
   itself constrains the data type and property names
   of the SourcePort instance model construct to be an
   integer.  However, we can further constrain the particular evaluated or set.  The CIM Schema defines
   and constrains "appropriate" values that for the SourcePort variable can hold (i.e., model
   property) using data types and other information such as class/property
   qualifiers.

   A PolicyExplicitVariable is "explicit" because its model semantics are
   exactly defined.  It is NOT explicit due to an exact binding to a
   particular object.  If PolicyExplicitVariable is only tied to instances
   (either via association or by entering valid ranges a object identification property in the
   IntegerList property of
   class itself), then we are forcing element-specific rules.  On the PolicyIntegerValue instance (0 - 65535 in
   this document).

   The combination of other
   hand, if we only specify the VariableName object's model context (class and property
   name), but leave the
   PolicyValueConstraintInVariable association provide binding to the policy framework (for example, using
   policy roles), then greater flexibility results for either general or
   element-specific rules.

   For example, an element-specific rule is obtained by a consistent condition
   (variable/operator/value triplet) that defines, for example, CIM
   LogicalDevice DeviceID="12345".  Alternately, if a PolicyRule's
   PolicyRoles is "edge device" and
   extensible set your condition (variable/operator/value
   triplet) is Status="Error", then a general rule results for all edge
   devices in error.

   Refer to Section 5.10 for the formal definition of metadata that the class
   PolicyExplicitVariable.

 4.8.7. Implicitly Bound Policy Variables

   Implicitly bound policy variables define the data type and semantics of variables that
   are used to form policy conditions.  Since a
   variable.  This determines how the
   PolicyValueConstraintInVariable association points variable is bound to another class, any
   of the properties a value in the PolicyValue class a
   condition clause.  Further instructions are provided for specifying data
   type and/or value constraints for implicitly bound variables.

   Implicitly bound variables can be used interpreted by different sub-models to constrain
   values that
   mean different things, depending on the PolicyImplicitVariable can hold. For example:

     o   The ValueTypes property can be used to ensure that only proper
         classes are used particular context in the expression. which they
   are used.  For example, the SourcePort an implicitly bound variable will not be allowed to ever be of type
         PolicyIPv4AddrValue, since source ports have different semantics
         than IP addresses and named "SourceIP" may not
   be matched.  However, integer value
         types are allowed as interpreted by a QoS policy information model to denote the property ValueTypes holds source
   address field in the string
         "PolicyIntegerValue", which IP header of a packet if a device is the class name configured to
   select certain packets for integer values.

     o particular treatment.  The PolicyValueConstraintInVariable association also ensures that
         variable-specific semantics are enforced (e.g., the SourcePort same variable may include a constraint association
   be bound to the sender address delivered by a value object
         defining RSVP PATH message for a
   decision by a policy server.  It is incumbent upon the particular domain-
   specific integer range that should be matched).

 4.8.9. Rationale information model to provide full and unambiguous interpretation
   details (binding rules, type and value constraints) for Modeling Implicit Variables as Classes

 An the implicitly
   bound variable can be modeled in one of several ways,
 including a single class with variables it uses.

   PCIMe introduces an enumerator for each individual abstract class, PolicyImplicitVariable, to model
   implicitly bound variable and an variables.  This class is derived from the abstract
   class extended for each individual variable. PolicyVariable also defined in PCIMe.  Each of the implicitly bound
   variables introduced by PCIMe (and those that are introduced by domain-
   specific sub-models) MUST be derived from the PolicyImplicitVariable
   class.  The reasons rationale for using a class inheritance this mechanism for specifying
 individual implicitly bound variables are these:

     1.  It modeling is easy to extend. explained
   below in Section 4.8.9.

   A domain-specific policy information model can
         easily extend that extends PCIMe may define
   additional implicitly bound variables either by deriving them directly
   from the PolicyImplicitVariable class PolicyImplicitVariable, or its subclasses
         to define domain-specific and context-specific variables.  For
         example, by further refining an existing
   variable class such as SourcePort.  When refining a domain-specific QoS policy information model class such as
   SourcePort, existing binding rules, type or value constraints may
         introduce an be
   narrowed.

 4.8.8. Structure and Usage of Pre-Defined Variables

   A class derived from PolicyImplicitVariable to model a particular
   implicitly bound variable SHOULD be constructed so that its name depicts
   the meaning of the variable.  For example, a class defined to model applications
         by deriving a qosApplicationVariable class from the
         PolicyImplicitVariable abstract class.

     2.  Introduction
   source port of a single structural class for TCP/UDP flow SHOULD be named 'SourcePort'.

   PCIMe defines one association and one general-purpose mechanism that
   together characterize each of the implicitly bound variables would have to include an enumerator property that
         contains all possible individual implicitly bound variables.  This
         means it
   introduces:

     1.  The PolicyValueConstraintInVariable association defines the set of
         value classes that a domain-specific information model wishing could be matched to
         introduce an implicitly bound variable must extend the enumerator
         itself.  This results in multiple definitions this variable.

     2.  The list of constraints on the same class,
         differing in values that the PolicyVariable can
         hold (i.e., values available in that the enumerator variable must match) are defined by
         the appropriate properties of an associated PolicyValue class.  One
         definition, in this document, would include

   In the common implicitly
         bound variables' names, while example presented above, a second definition, in the domain-
         specific information model document, may include additional values
         ('qosApplicationVariable' in the example above).  It wouldnÆt even
         be obvious to PolicyImplicitVariable represents the application developer that multiple
   SourcePort of incoming traffic.  The ValueTypes property of an instance
   of this class
         definitions existed.  It would be harder still for the application
         developer to actually find will hold the correct class to use.

     3.  In addition, an enumerator-based definition would require each
         additional value to be registered with IANA to ascertain adherence
         to standards. name PolicyIntegerValue.  This would make by
   itself constrains the process cumbersome.

     4.  A possible argument against data type of the inheritance mechanism would cite SourcePort instance to be an
   integer.  However, we can further constrain the fact particular values that this approach results
   the SourcePort variable can hold by entering valid ranges in an explosion the
   IntegerList property of class
         definitions compared to an enumerator class, which only introduces
         a single class.  While, by itself, the PolicyIntegerValue instance (0 - 65535 in
   this is not document).

   The combination of the VariableName and the
   PolicyValueConstraintInVariable association provide a strike against consistent and
   extensible set of metadata that define the approach, it may be argued semantics of variables that data models implemented, which
   are mapped to this information model, may be more difficult used to
         optimize for applications.  This argument is rejected on form policy conditions.  Since the
         grounds that application optimization is of lesser value for an
         information model than clarity and ease
   PolicyValueConstraintInVariable association points to another class, any
   of extension.  In
         addition, it is hard the properties in the PolicyValue class can be used to claim constrain
   values that the inheritance model places an
         absolute burden on PolicyImplicitVariable can hold. For example:

     o   The ValueTypes property can be used to ensure that only proper
         classes are used in the optimization. expression.  For example, a data model
         may still use enumeration the SourcePort
         variable will not be allowed to denote instances ever be of pre-defined
         variables type
         PolicyIPv4AddrValue, since source ports have different semantics
         than IP addresses and claim PCIMe compliance, as long may not be matched.  However, integer value
         types are allowed as the data moel can
         be mapped correctly to property ValueTypes holds the definitions specified in this document.
         Furthermore, string
         "PolicyIntegerValue", which is the very nature of class name for integer values.

     o   The PolicyValueConstraintInVariable association also ensures that
         variable-specific semantics are enforced (e.g., the SourcePort
         variable may include a constraint association to a value object
         defining a specific integer range that should be matched).

 4.8.9. Rationale for Modeling Implicit Variables as Classes

 An implicitly bound variables is to variable can be interpreted modeled in context.  This means that unless one of several ways,
 including a single class with an additional enumerator for each individual implicitly
 bound variable is required by a sub-model (in which case both approaches
         result in some overhead), there's and an upper limit on the abstract class
         explosion.  After all, once properly documented, no need exists extended for each individual variable.
 The reasons for using a sub-model class inheritance mechanism for specifying
 individual implicitly bound variables are these:

     1.  It is easy to add a extend.  A domain-specific information model can
         easily extend the PolicyImplicitVariable class definition.  The implementation
         needs only or its subclasses
         to cite define domain-specific and use the PCIMe variable, but impose the
         documented context-dependent semantics.

 4.8.10. Policy Values

   The abstract class PolicyValue is used for modeling values and constants
   used in context-specific variables.  For
         example, a domain-specific QoS policy conditions.  Different value types are derived from this
   class, information model may
         introduce an implicitly bound variable class to represent the various attributes required.  Extensions of model applications
         by deriving a qosApplicationVariable class from the
         PolicyImplicitVariable abstract class PolicyValue, defined in this document, provide a list class.

     2.  Introduction of
   values a single structural class for representing basic network attributes.  Values can be used implicitly bound
         variables would have to
   represent constants as named values.  Named values can be kept in include an enumerator property that
         contains all possible individual implicitly bound variables.  This
         means that a
   reusable policy container domain-specific information model wishing to be reused by
         introduce an implicitly bound variable must extend the enumerator
         itself.  This results in multiple conditions.  Examples
   of constants include well-known ports, well-known protocols, server
   addresses, and other similar concepts.

   The PolicyValue subclasses define three basic types definitions of values: scalars,
   ranges and sets.  For example, a well-known port number could be defined
   using the PolicyIntegerValue same class, defining a single value (80 for
   HTTP), a range (80-88), or a set (80, 82, 8080) of ports, respectively.
   For details, please see
         differing in the class definition for each value type values available in the enumerator class.  One
         definition, in
   Section 5.12 of this document.

   PCIMe defines document, would include the following subclasses of common implicitly
         bound variables' names, while a second definition, in the abstract class PolicyValue:

   Classes for general use:

     - PolicyStringValue,
     - PolicyIntegerValue,
     - PolicyBitStringValue
     - PolicyBooleanValue.

   Classes for layer 3 Network values:

     - PolicyIPv4AddrValue,
     - PolicyIPv6AddrValue.

   Classes domain-
         specific information model document, may include additional values
         ('qosApplicationVariable' in the example above).  It wouldnÆt even
         be obvious to the application developer that multiple class
         definitions existed.  It would be harder still for layer 2 Network values:

     - PolicyMACAddrValue.

   For details, please see the application
         developer to actually find the correct class to use.

     3.  In addition, an enumerator-based definition section of would require each class in
   Section 5.14 of this document.

 4.9. Packet Filtering

   In addition
         additional value to filling in be registered with IANA to ascertain adherence
         to standards. This would make the holes in process cumbersome.

     4.  A possible argument against the overall Policy infrastructure,
   PCIMe proposes inheritance mechanism would cite
         the fact that this approach results in an explosion of class
         definitions compared to an enumerator class, which only introduces
         a single mechanism class.  While, by itself, this is not a strike against
         the approach, it may be argued that data models implemented, which
         are mapped to this information model, may be more difficult to
         optimize for expressing packet filters in policy
   conditions. applications.  This argument is being done in response rejected on the
         grounds that application optimization is of lesser value for an
         information model than clarity and ease of extension.  In
         addition, it is hard to concerns claim that even though the initial "wave" of submodels derived from PCIM were all filtering inheritance model places an
         absolute burden on
   IP packets, each was doing it in a slightly different way.  PCIMe
   proposes the optimization.  For example, a common way data model
         may still use enumeration to express IP packet filters.  The following figure
   illustrates how packet-filtering conditions are expressed in PCIMe.

                    +---------------------------------+
                    | CompoundFilterCondition         |
                    |   - IsMirrored   boolean        |
                    |   - ConditionListType (DNF|CNF) |
                    +---------------------------------+
                     +               +               +
                     +               +               +
                     +               +               +
                 SimplePC        SimplePC        SimplePC
                 *      @        *      @        *      @
                 *      @        *      @        *      @
                 *      @        *      @        *      @
     FlowDirection    "In"     SrcIP  <addr1>  DstIP  <addr2>

   Aggregation Legend:
     ++++  PolicyConditionInPolicyCondition
     ****  PolicyVariableInSimplePolicyCondition
     @@@@  PolicyValueInSimplePolicyCondition

   Figure 7.    Packet Filtering in Policy Conditions

   In Figure 7, each SimplePolicyCondition represents a single field to be
   filtered on: Source IP address, Destination IP address, Source port, etc.
   An additional SimplePolicyCondition indicates the direction that a packet
   is traveling on an interface: inbound or outbound.  Because denote instances of pre-defined
         variables and claim PCIMe compliance, as long as the
   FlowDirection condition, care must data moel can
         be taken in aggregating a set of
   SimplePolicyConditions into a CompoundFilterCondition.  Otherwise, mapped correctly to the
   resulting CompoundPolicyCondition may match all inbound packets, or all
   outbound packets, when definitions specified in this is probably not what was intended.

   Individual SimplePolicyConditions may be negated when they are aggregated
   by a CompoundFilterCondition.

   CompoundFilterCondition is a subclass of CompoundPolicyCondition.  It
   introduces one additional property, document.
         Furthermore, the Boolean property IsMirrored.  The
   purpose very nature of this property implicitly bound variables is to allow a single CompoundFilterCondition to
   match packets traveling
         be interpreted in context.  This means that unless an additional
         variable is required by a sub-model (in which case both directions approaches
         result in some overhead), there's an upper limit on the class
         explosion.  After all, once properly documented, no need exists
         for a higher-level connection
   such as a TCP session.  When this property is TRUE, additional packets
   match a filter, beyond those that would ordinarily match it.  An example
   will illustrate how this property works.

   Suppose we have sub-model to add a CompoundFilterCondition that aggregates the following
   three filters, which are ANDed together:

     o   FlowDirection = "In"
     o   Source IP = 9.1.1.1
     o   Source Port = 80
   Regardless of whether IsMirrored is TRUE or FALSE, inbound packets will
   match this CompoundFilterCondition if their Source IP address = 9.1.1.1 class definition.  The implementation
         needs only to cite and their Source port = 80.  If IsMirrored is TRUE, however, an outbound
   packet will also match use the CompoundFilterCondition if its Destination IP
   address = 9.1.1.1 and its Destination port = 80.

   IsMirrored "flips" PCIMe variable, but impose the following Source/Destination packet header fields:

     o   FlowDirection "In" / FlowDirection "Out"
     o   Source IP address / Destination IP address
     o   Source port / Destination port
     o   Source MAC address / Destination MAC address
     o   Source [layer-2] SAP / Destination [layer-2] SAP.

 5. Class Definitions
         documented context-dependent semantics.

 4.8.10. Policy Values

   The following definitions supplement those abstract class PolicyValue is used for modeling values and constants
   used in PCIM itself.  PCIM
   definitions that are not DEPRECATED here policy conditions.  Different value types are still current parts derived from this
   class, to represent the various attributes required.  Extensions of the
   overall Policy Core Information Model.

 5.1. The Abstract Class "PolicySet"

   PolicySet is an
   abstract class that may group policies into PolicyValue, defined in this document, provide a structured
   set list of policies.

     NAME             PolicySet
     DESCRIPTION      An abstract class that represents
   values for representing basic network attributes.  Values can be used to
   represent constants as named values.  Named values can be kept in a set
   reusable policy container to be reused by multiple conditions.  Examples
   of policies
                      that form a coherent set. constants include well-known ports, well-known protocols, server
   addresses, and other similar concepts.

   The set PolicyValue subclasses define three basic types of contained
                      policies has a common decision strategy values: scalars,
   ranges and sets.  For example, a common
                      set of policy roles.  Subclasses include PolicyGroup
                      and PolicyRule.
     DERIVED FROM     Policy
     ABSTRACT         TRUE
     PROPERTIES       PolicyDecisionStrategy
                      PolicyRoles

   The PolicyDecisionStrategy property specifies well-known port number could be defined
   using the evaluation method PolicyIntegerValue class, defining a single value (80 for
   policy groups and rules contained within
   HTTP), a range (80-88), or a set (80, 82, 8080) of ports, respectively.
   For details, please see the policy set.

     NAME             PolicyDecisionStrategy
     DESCRIPTION      The evaluation method used class definition for policies contained each value type in
                      the PolicySet.  FirstMatching enforces the actions
   Section 5.12 of this document.

   PCIMe defines the first rule that evaluates to TRUE; AllMatching
                      enforces the actions following subclasses of all rules that evaluate to
                      TRUE.
     SYNTAX           uint16
     VALUES           1 [FirstMatching], the abstract class PolicyValue:

   Classes for general use:

     - PolicyStringValue,
     - PolicyIntegerValue,
     - PolicyBitStringValue
     - PolicyBooleanValue.

   Classes for layer 3 Network values:

     - PolicyIPv4AddrValue,
     - PolicyIPv6AddrValue.

   Classes for layer 2 [AllMatching]
     DEFAULT VALUE    1 [FirstMatching]

   The Network values:

     - PolicyMACAddrValue.

   For details, please see the class definition section of PolicyRoles is unchanged from PCIM.  It is, however,
   moved from the each class Policy up in
   Section 5.14 of this document.

 4.9. Packet Filtering

   In addition to filling in the superclass PolicySet.

 5.2. Updates to PCIM's Class "PolicyGroup"

   The PolicyGroup class holes in the overall Policy infrastructure,
   PCIMe proposes a single mechanism for expressing packet filters in policy
   conditions.  This is modified being done in response to be concerns that even though
   the initial "wave" of submodels derived from PolicySet.

     NAME             PolicyGroup
     DESCRIPTION      A container for PCIM were all filtering on
   IP packets, each was doing it in a set of related PolicyRules and
                      PolicyGroups.
     DERIVED FROM     PolicySet
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.3. Updates slightly different way.  PCIMe
   proposes a common way to PCIM's Class "PolicyRule" express IP packet filters.  The PolicyRule class is modified following figure
   illustrates how packet-filtering conditions are expressed in PCIMe.

                    +---------------------------------+
                    | CompoundFilterCondition         |
                    |   - IsMirrored   boolean        |
                    |   - ConditionListType (DNF|CNF) |
                    +---------------------------------+
                     +               +               +
                     +               +               +
                     +               +               +
                 SimplePC        SimplePC        SimplePC
                 *      @        *      @        *      @
                 *      @        *      @        *      @
                 *      @        *      @        *      @
     FlowDirection    "In"     SrcIP  <addr1>  DstIP  <addr2>

   Aggregation Legend:
     ++++  PolicyConditionInPolicyCondition
     ****  PolicyVariableInSimplePolicyCondition
     @@@@  PolicyValueInSimplePolicyCondition

   Figure 7.    Packet Filtering in Policy Conditions

   In Figure 7, each SimplePolicyCondition represents a single field to be derived from PolicySet, and to
   deprecate the use of Priority in the rule.  PolicyRoles is now inherited
   from
   filtered on: Source IP address, Destination IP address, Source port, etc.
   An additional SimplePolicyCondition indicates the parent class PolicySet.  Finally, direction that a new property
   ExecutionStrategy packet
   is introduced, paralleling the property traveling on an interface: inbound or outbound.  Because of the same
   name
   FlowDirection condition, care must be taken in aggregating a set of
   SimplePolicyConditions into a CompoundFilterCondition.  Otherwise, the class CompoundPolicyAction.

     NAME             PolicyRule
     DESCRIPTION      The central class for representing the "If Condition
                      then Action" semantics associated with a policy rule.
     DERIVED FROM     PolicySet
     ABSTRACT         FALSE
     PROPERTIES       Enabled
                      ConditionListType
                      RuleUsage
                      Priority DEPRECATED FOR PolicySetComponent.Priority
                      Mandatory
                      SequencedActions
                      ExecutionStrategy

   The property ExecutionStrategy defines the execution strategy to be used
   upon the sequenced actions aggregated by
   resulting CompoundPolicyCondition may match all inbound packets, or all
   outbound packets, when this PolicyRule. (An equivalent
   ExecutionStrategy property is also defined for the CompoundPolicyAction
   class, to provide the same indication for the sequenced actions probably not what was intended.

   Individual SimplePolicyConditions may be negated when they are aggregated
   by a CompoundPolicyAction.)  This draft defines four execution
   strategies:

     Mandatory Do all û execute ALL actions that are part CompoundFilterCondition.

   CompoundFilterCondition is a subclass of the modeled
                        set.  If CompoundPolicyCondition.  It
   introduces one or more of additional property, the actions cannot be
                        executed, none Boolean property IsMirrored.  The
   purpose of the actions should be executed.
     Do until success û execute actions according this property is to predefined order, until
                        successful execution of allow a single action.
     Do All -           execute ALL actions which are part of the modeled
                        set, according to their predefined order. Continue
                        doing this, even if one or more of the actions
                        fails.
     Do until Failure - execute actions according CompoundFilterCondition to predefined order, until
                        the first failure
   match packets traveling in execution of both directions on a single sub-
                        action.

   The higher-level connection
   such as a TCP session.  When this property definition is as follows:

     NAME             ExecutionStrategy
     DESCRIPTION TRUE, additional packets
   match a filter, beyond those that would ordinarily match it.  An enumeration indicating example
   will illustrate how to interpret the action
                      ordering for the actions aggregated by this
                      PolicyRule.
     SYNTAX           uint16 (ENUM, {1=Mandatory Do All, 2=Do Until Success,
                      3=Do All, 4=Do Until Failure} )
     DEFAULT VALUE    Do All (3)

 5.4. The Class "SimplePolicyCondition"

   A simple policy condition is composed of an ordered triplet:

     <Variable>  MATCH  <Value>

   No formal modeling of property works.

   Suppose we have a CompoundFilterCondition that aggregates the MATCH operator is provided.  The 'match'
   relationship is implied.  Such simple conditions following
   three filters, which are evaluated by
   answering the question:

     Does <variable> ANDed together:

     o   FlowDirection = "In"
     o   Source IP = 9.1.1.1
     o   Source Port = 80

   Regardless of whether IsMirrored is TRUE or FALSE, inbound packets will
   match <value>?

   The 'match' relationship this CompoundFilterCondition if their Source IP address = 9.1.1.1
   and their Source port = 80.  If IsMirrored is to be interpreted by analyzing TRUE, however, an outbound
   packet will also match the variable CompoundFilterCondition if its Destination IP
   address = 9.1.1.1 and value instances associated with its Destination port = 80.

   IsMirrored "flips" the simple condition.

   Simple conditions following Source/Destination packet header fields:

     o   FlowDirection "In" / FlowDirection "Out"
     o   Source IP address / Destination IP address
     o   Source port / Destination port
     o   Source MAC address / Destination MAC address
     o   Source [layer-2] SAP / Destination [layer-2] SAP.

 5. Class Definitions

   The following definitions supplement those in PCIM itself.  PCIM
   definitions that are building blocks for more complex Boolean
   Conditions, modeled by not DEPRECATED here are still current parts of the CompoundPolicyCondition class.
   overall Policy Core Information Model.

 5.1. The SimplePolicyCondition class Abstract Class "PolicySet"

   PolicySet is derived from the PolicyCondition an abstract class
   defined in PCIM.

   A variable and a value must be associated with a simple condition to make
   it that may group policies into a meaningful condition, using, respectively, the aggregations
   PolicyVariableInSimplePolicyCondition and
   PolicyValueInSimplePolicyCondition.

   The class definition is as follows: structured
   set of policies.

     NAME             SimplePolicyCondition
     DERIVED FROM     PolicyCondition
     ABSTRACT         False
     PROPERTIES       (none)

 5.5. The Class "CompoundPolicyCondition"

   This             PolicySet
     DESCRIPTION      An abstract class that represents a compound policy condition, formed by aggregation
   of simpler policy conditions.

     NAME             CompoundPolicyCondition
     DESCRIPTION      A subclass set of PolicyCondition policies
                      that introduces the
                      ConditionListType property, used for assigning DNF /
                      CNF semantics to subordinate form a coherent set.  The set of contained
                      policies has a common decision strategy and a common
                      set of policy conditions. roles.  Subclasses include PolicyGroup
                      and PolicyRule.
     DERIVED FROM     PolicyCondition     Policy
     ABSTRACT         FALSE         TRUE
     PROPERTIES       ConditionListType       PolicyDecisionStrategy
                      PolicyRoles
   The ConditionListType PolicyDecisionStrategy property is used to specify whether specifies the list of
   policy conditions associated with this compound evaluation method for
   policy condition is in
   disjunctive normal form (DNF) or conjunctive normal form (CNF).  If this
   property is not present, groups and rules contained within the list type defaults to DNF.  The property
   definition is as follows: policy set.

     NAME             ConditionListType             PolicyDecisionStrategy
     DESCRIPTION      Indicates whether      The evaluation method used for policies contained in
                      the list PolicySet.  FirstMatching enforces the actions of policy conditions
                      associated with this policy
                      the first rule is in disjunctive
                      normal form (DNF) or conjunctive normal form (CNF). that evaluates to TRUE; AllMatching
                      enforces the actions of all rules that evaluate to
                      TRUE.
     SYNTAX           uint16
     VALUES           DNF(1), CNF(2)           1 [FirstMatching], 2 [AllMatching]
     DEFAULT VALUE    DNF(1)

 5.6.    1 [FirstMatching]

   The Class "CompoundFilterCondition"

   This subclass definition of CompoundPolicyCondition introduces one additional
   property, the boolean IsMirrored.  This property turns on or off the
   "flipping" of corresponding source and destination fields in a filter
   specification.

     NAME             CompoundFilterCondition
     DESCRIPTION      A subclass of CompoundPolicyCondition that introduces
                      the IsMirrored property.
     DERIVED FROM     CompoundPolicyCondition
     ABSTRACT         FALSE
     PROPERTIES       IsMirrored

   The IsMirrored property indicates whether packets that "mirror" a
   compound filter condition should be treated as matching the filter.  The
   property definition PolicyRoles is as follows:

     NAME             IsMirrored
     DESCRIPTION      Indicates whether packets that mirror unchanged from PCIM.  It is, however,
   moved from the specified
                      filter are class Policy up to be treated as matching the filter.
     SYNTAX           boolean
     DEFAULT VALUE    FALSE

 5.7. The superclass PolicySet.

 5.2. Update PCIM's Class "SimplePolicyAction" "PolicyGroup"

   The SimplePolicyAction PolicyGroup class models the elementary set operation. "SET
   <variable> TO <value>".  The set operator MUST overwrite an old value of
   the variable.

   Two aggregations are used in order to create the pair <variable> <value>.
   The aggregation PolicyVariableInSimplePolicyAction relates a
   SimplePolicyAction to a single variable instance.  Similarly, the
   aggregation PolicyValueInSimplePolicyAction relates a SimplePolicyAction is modified to a single value instance.  Both aggregations are defined in this
   document. be derived from PolicySet.

     NAME             SimplePolicyAction             PolicyGroup
     DESCRIPTION      A subclass of PolicyAction that introduces the notion container for a set of "SET variable TO value". related PolicyRules and
                      PolicyGroups.
     DERIVED FROM     PolicyAction     PolicySet
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.8. The

 5.3. Update PCIM's Class "CompoundPolicyAction" "PolicyRule"

   The CompoundPolicyAction PolicyRule class is used modified to represent an expression
   consisting of an ordered sequence be derived from PolicySet, and to
   deprecate the use of action terms.  Each action term Priority in the rule.  PolicyRoles is
   represented as now inherited
   from the parent class PolicySet.  Finally, a subclass new property
   ExecutionStrategy is introduced, paralleling the property of the PolicyAction class, defined same
   name in [PCIM].
   Compound actions are constructed by associating dependent action terms
   together using the PolicyActionInPolicyAction aggregation.

   The class definition is as follows: CompoundPolicyAction.

     NAME             CompoundPolicyAction             PolicyRule
     DESCRIPTION      A      The central class for representing sequenced action terms.  Each
                      action term is defined to be a subclass of the
                      PolicyAction class. "If Condition
                      then Action" semantics associated with a policy rule.
     DERIVED FROM     PolicyAction     PolicySet
     ABSTRACT         FALSE
     PROPERTIES       Enabled
                      ConditionListType
                      RuleUsage
                      Priority DEPRECATED FOR PolicySetComponent.Priority
                                    AND FOR PolicySetInSystem.Priority
                      Mandatory
                      SequencedActions
                      ExecutionStrategy

   This is a concrete class, and is therefore directly instantiable.

   The Property SequencedActions is identical to the SequencedActions
   property defined in PCIM for the class PolicyRule.

   The property ExecutionStrategy defines the execution strategy to be used
   upon the sequenced actions associated with aggregated by this compound action. PolicyRule. (An equivalent
   ExecutionStrategy property is also defined for the PolicyRule CompoundPolicyAction
   class, to provide the same indication for the sequenced actions
   associated with
   aggregated by a PolicyRule.) CompoundPolicyAction.)  This draft defines four three
   execution strategies:

     Mandatory Do all û execute ALL actions that are part of the modeled
                        set.  If one or more of the sub-actions cannot be
                        executed, none of the actions should be executed.

     Do until success Until Success û execute actions according to predefined order, until
                        successful execution of a single sub-action. action.
     Do All -           execute ALL actions which are part of the modeled
                        set, according to their predefined order. Continue
                        doing this, even if one or more of the sub-actions actions
                        fails.
     Do until Until Failure - execute actions according to predefined order, until
                        the first failure in execution of a single sub-
                        action.

   The property definition is as follows:

     NAME             ExecutionStrategy
     DESCRIPTION      An enumeration indicating how to interpret the action
                      ordering for the actions aggregated by this
                      CompoundPolicyAction.
                      PolicyRule.
     SYNTAX           uint16 (ENUM, {1=Mandatory Do All, 2=Do {1=Do Until Success,
                      3=Do 2=Do All, 4=Do 3=Do
                      Until Failure} )
     DEFAULT VALUE    Do All (3)

 5.9. (2)

 5.4. The Abstract Class "PolicyVariable"

   Variables are used for building individual conditions.  The variable
   specifies the property "SimplePolicyCondition"

   A simple policy condition is composed of a flow or an event that should ordered triplet:

     <Variable>  MATCH  <Value>

   No formal modeling of the MATCH operator is provided.  The 'match'
   relationship is implied.  Such simple conditions are evaluated by
   answering the question:

     Does <variable> match <value>?

   The 'match' relationship is to be matched when
   evaluating interpreted by analyzing the condition.  However, not every combination of a variable
   and a value creates a meaningful instances associated with the simple condition. For example, a source IP
   address variable can not be matched against a value that specifies a port
   number.  A given variable selects

   Simple conditions are building blocks for more complex Boolean
   Conditions, modeled by the set of matchable value types. CompoundPolicyCondition class.

   The SimplePolicyCondition class is derived from the PolicyCondition class
   defined in PCIM.

   A variable can have constraints that limit the set of values within and a
   particular value type that can must be matched against it in a condition.  For
   example, associated with a source-port variable limits the set of values to represent
   integers to the range of 0-65535.  Integers outside this range cannot be
   matched simple condition to the source-port variable, even though they are of the correct
   data type.  Constraints for make
   it a given variable are indicated through meaningful condition, using, respectively, the
   PolicyValueConstraintInVariable association.

   The PolicyVariable is an abstract class.  Implicit aggregations
   PolicyVariableInSimplePolicyCondition and explicit context
   variable classes are defined as sub classes of the PolicyVariable class.
   A set of implicit variables is defined in this document as well.
   PolicyValueInSimplePolicyCondition.

   The class definition is as follows:

     NAME             PolicyVariable             SimplePolicyCondition
     DERIVED FROM     Policy     PolicyCondition
     ABSTRACT         TRUE         False
     PROPERTIES       (none)

 5.10.

 5.5. The Class "PolicyExplicitVariable"

   Explicitly defined "CompoundPolicyCondition"

   This class represents a compound policy variables are evaluated within the context condition, formed by aggregation
   of simpler policy conditions.

     NAME             CompoundPolicyCondition
     DESCRIPTION      A subclass of PolicyCondition that introduces the CIM Schema and its modeling constructs.  The PolicyExplicitVariable
   class indicates the exact model property
                      ConditionListType property, used for assigning DNF /
                      CNF semantics to be evaluated or manipulated.

   The class definition is as follows:

     NAME             PolicyExplicitVariable subordinate policy conditions.
     DERIVED FROM     PolicyVariable     PolicyCondition
     ABSTRACT         False         FALSE
     PROPERTIES       ModelClass, ModelProperty

 5.10.1.       ConditionListType

   The Single-Valued Property "ModelClass"

   This ConditionListType property is a string specifying used to specify whether the class name whose property is
   evaluated or set as a PolicyVariable.  The property list of
   policy conditions associated with this compound policy condition is defined as
   follows:

     NAME             ModelClass
     SYNTAX           String

 5.10.2. The Single-Valued Property ModelProperty

   This in
   disjunctive normal form (DNF) or conjunctive normal form (CNF).  If this
   property is a string specifying the property name, within not present, the
   ModelClass, which is evaluated or set as a PolicyVariable. list type defaults to DNF.  The property
   definition is defined as follows:

     NAME             ModelProperty             ConditionListType
     DESCRIPTION      Indicates whether the list of policy conditions
                      associated with this policy rule is in disjunctive
                      normal form (DNF) or conjunctive normal form (CNF).
     SYNTAX           String

 5.11.           uint16
     VALUES           DNF(1), CNF(2)
     DEFAULT VALUE    DNF(1)

 5.6. The Abstract Class "PolicyImplicitVariable"

   Implicitly defined policy variables are evaluated outside of the context "CompoundFilterCondition"

   This subclass of CompoundPolicyCondition introduces one additional
   property, the CIM Schema and its modeling constructs.  Subclasses specify boolean IsMirrored.  This property turns on or off the
   data type and semantics
   "flipping" of the PolicyVariables.

   Interpretation corresponding source and evaluation of a PolicyImplicitVariable can vary,
   depending on the particular context destination fields in which it is used.  For example, a
   "SourceIP" address may denote the source address field filter
   specification.

     NAME             CompoundFilterCondition
     DESCRIPTION      A subclass of an IP packet
   header, or CompoundPolicyCondition that introduces
                      the sender address delivered by an RSVP PATH message.

   The class definition is as follows:

     NAME             PolicyImplicitVariable IsMirrored property.
     DERIVED FROM     PolicyVariable     CompoundPolicyCondition
     ABSTRACT         True         FALSE
     PROPERTIES       ValueTypes[ ]

 5.11.1.       IsMirrored

   The Multi-Valued Property "ValueTypes"

   This IsMirrored property is a set of strings specifying an unordered list of
   possible value/data types indicates whether packets that can "mirror" a
   compound filter condition should be used in simple conditions and
   actions, with this variable.  The value types are specified by their
   class names (subclasses of PolicyValue such as PolicyStringValue).  The
   list of class names enables an application to search on a specific name,
   as well as to ensure that the data type of the variable is of the correct
   type.

   The list of default ValueTypes for each subclass of
   PolicyImplicitVariable is specified within that variable's definition. treated as matching the filter.  The
   property definition is defined as follows:

     NAME             ValueTypes
     SYNTAX           String

 5.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe

   The following subclasses of PolicyImplicitVariable are defined in PCIMe.

 5.12.1. The Class "PolicySourceIPVariable"

     NAME             PolicySourceIPVariable             IsMirrored
     DESCRIPTION      The source IP address.

                      ALLOWED      Indicates whether packets that mirror the specified
                      filter are to be treated as matching the filter.
     SYNTAX           boolean
     DEFAULT VALUE TYPES:
                        - PolicyIPv4AddrValue
                        - PolicyIPv6AddrValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT    FALSE
     PROPERTIES       (none)

 5.12.2.

 5.7. The Class "PolicyDestinationIPVariable"

     NAME             PolicyDestinationIPVariable
     DESCRIPTION "SimplePolicyAction"

   The destination IP address.

                      ALLOWED VALUE TYPES:
                        - PolicyIPv4AddrValue
                        - PolicyIPv6AddrValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.3. SimplePolicyAction class models the elementary set operation. "SET
   <variable> TO <value>".  The Class "PolicySourcePortVariable"

     NAME             PolicySourcePortVariable
     DESCRIPTION      Ports set operator MUST overwrite an old value of
   the variable.

   Two aggregations are defined as used in order to create the abstraction that transport
                      protocols use pair <variable> <value>.
   The aggregation PolicyVariableInSimplePolicyAction relates a
   SimplePolicyAction to distinguish among multiple
                      destinations within a given host computer.  For TCP
                      and UDP flows, single variable instance.  Similarly, the PolicySourcePortVariable is
                      logically bound
   aggregation PolicyValueInSimplePolicyAction relates a SimplePolicyAction
   to a single value instance.  Both aggregations are defined in this
   document.

     NAME             SimplePolicyAction
     DESCRIPTION      A subclass of PolicyAction that introduces the source port field.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue
                        - PolicyBitStringValue notion
                      of "SET variable TO value".
     DERIVED FROM     PolicyImplicitVariable     PolicyAction
     ABSTRACT         FALSE
     PROPERTIES       (none)
 5.12.4.

 5.8. The Class "PolicyDestinationPortVariable"

     NAME             PolicyDestinationPortVariable
     DESCRIPTION      Ports are defined as the abstraction that transport
                      protocols use "CompoundPolicyAction"

   The CompoundPolicyAction class is used to distinguish among multiple
                      destinations within represent an expression
   consisting of an ordered sequence of action terms.  Each action term is
   represented as a given host computer.  For TCP
                      and UDP flows, subclass of the PolicyDestinationPortVariable is
                      logically bound to PolicyAction class, defined in [PCIM].
   Compound actions are constructed by associating dependent action terms
   together using the destination port field.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue
                        - PolicyBitStringValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.5. PolicyActionInPolicyAction aggregation.

   The Class "PolicyIPProtocolVariable" class definition is as follows:

     NAME             PolicyIPProtocolVariable             CompoundPolicyAction
     DESCRIPTION      The IP protocol number.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue
                        - PolicyBitStringValue      A class for representing sequenced action terms.  Each
                      action term is defined to be a subclass of the
                      PolicyAction class.
     DERIVED FROM     PolicyImplicitVariable     PolicyAction
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.6. The Class "PolicyIPVersionVariable"

     NAME             PolicyIPVersionVariable
     DESCRIPTION      The IP version number.  The well-known values are 4       SequencedActions
                      ExecutionStrategy

   This is a concrete class, and 6.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue
                        - PolicyBitStringValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.7. The Class "PolicyIPToSVariable"

     NAME             PolicyIPToSVariable
     DESCRIPTION      The IP TOS octet.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue
                        - PolicyBitStringValue
     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.8. The Class "PolicyDSCPVariable"

     NAME             PolicyDSCPVariable
     DESCRIPTION      The 6 bit Differentiated Service Code Point.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue
                        - PolicyBitStringValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.9. is therefore directly instantiable.

   The Class "PolicySourceMACVariable"

     NAME             PolicySourceMACVariable
     DESCRIPTION Property SequencedActions is identical to the SequencedActions
   property defined in PCIM for the class PolicyRule.

   The source MAC address.

                      ALLOWED VALUE TYPES:
                        - PolicyMACAddrValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.10. The Class "PolicyDestinationMACVariable"

     NAME             PolicyDestinationMACVariable
     DESCRIPTION      The destination MAC address.

                      ALLOWED VALUE TYPES:
                        - PolicyMACAddrValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.11. The Class "PolicyVLANVariable"

     NAME             PolicyVLANVariable
     DESCRIPTION      The virtual Bridged Local Area Network Identifier, a
                      12-bit field as property ExecutionStrategy defines the execution strategy to be used
   upon the sequenced actions associated with this compound action. (An
   equivalent ExecutionStrategy property is also defined in for the IEEE 802.1q standard.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue
                        - PolicyBitStringValue
     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.12. The Class "PolicyCoSVariable"

     NAME             PolicyCoSVariable
     DESCRIPTION      Class PolicyRule
   class, to provide the same indication for the sequenced actions
   associated with a PolicyRule.)  This draft defines three execution
   strategies:

     Do Until Success û execute actions according to predefined order, until
                        successful execution of Service, a 3-bit field, used in single sub-action.
     Do All -           execute ALL actions which are part of the layer 2
                      header modeled
                        set, according to select their predefined order. Continue
                        doing this, even if one or more of the forwarding treatment.  Bound sub-actions
                        fails.
     Do Until Failure - execute actions according to predefined order, until
                        the IEEE 802.1q user-priority field.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue
                        - PolicyBitStringValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.13. The Class "PolicyEthertypeVariable"

     NAME             PolicyEthertypeVariable
     DESCRIPTION      The Ethertype protocol number first failure in execution of Ethernet frames.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue
                        - PolicyBitStringValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.14. a single sub-
                        action.

   The Class "PolicySourceSAPVariable" property definition is as follows:

     NAME             PolicySourceSAPVariable             ExecutionStrategy
     DESCRIPTION      The Source SAP number.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue
                        - PolicyBitStringValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.15. The Class "PolicyDestinationSAPVariable"

     NAME             PolicyDestinationSAPVariable
     DESCRIPTION      The Destination SAP number.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue
                        - PolicyBitStringValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.16. The Class "PolicySNAPVariable"

     NAME             PolicySNAPVariable
     DESCRIPTION      The protocol number over a SNAP SAP encapsulation.

                      ALLOWED      An enumeration indicating how to interpret the action
                      ordering for the actions aggregated by this
                      CompoundPolicyAction.
     SYNTAX           uint16 (ENUM, {1=Do Until Success, 2=Do All, 3=Do
                      Until Failure} )
     DEFAULT VALUE TYPES:
                        - PolicyIntegerValue
                        - PolicyBitStringValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.17.    Do All (2)

 5.9. The Abstract Class "PolicyFlowDirectionVariable"

     NAME             PolicyFlowDirectionVariable
     DESCRIPTION "PolicyVariable"

   Variables are used for building individual conditions.  The direction variable
   specifies the property of a flow relative to a network element.
                      Direction may or an event that should be "IN" and/or "OUT".

                      ALLOWED VALUE TYPES:
                        - PolicyStringValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

   To match on both inbound and outbound flows, matched when
   evaluating the associated
   PolicyStringValue object has two entries in its StringList property: "IN" condition.  However, not every combination of a variable
   and "OUT".

 5.13. The Abstract Class "PolicyValue"

   This is an abstract class a value creates a meaningful condition. For example, a source IP
   address variable can not be matched against a value that serves as specifies a port
   number.  A given variable selects the base class for all
   subclasses that are used to define set of matchable value objects in types.

   A variable can have constraints that limit the PCIMe.  It is
   used for defining set of values and constants used in policy conditions.  The
   class definition is within a
   particular value type that can be matched against it in a condition.  For
   example, a source-port variable limits the set of values to represent
   integers to the range of 0-65535.  Integers outside this range cannot be
   matched to the source-port variable, even though they are of the correct
   data type.  Constraints for a given variable are indicated through the
   PolicyValueConstraintInVariable association.

   The PolicyVariable is an abstract class.  Implicit and explicit context
   variable classes are defined as sub classes of the PolicyVariable class.
   A set of implicit variables is defined in this document as well.

   The class definition is as follows:

     NAME             PolicyValue             PolicyVariable
     DERIVED FROM     Policy
     ABSTRACT         True         TRUE
     PROPERTIES       (none)
 5.14. Subclasses of "PolicyValue" Specified in PCIMe

   The following subsections contain the PolicyValue subclasses defined in
   PCIMe.  Additional subclasses may be defined in models derived from
   PCIMe.

 5.14.1.
 5.10. The Class "PolicyIPv4AddrValue"

   This class is used to provide a list "PolicyExplicitVariable"

   Explicitly defined policy variables are evaluated within the context of IPv4Addresses, hostnames
   the CIM Schema and
   address range values its modeling constructs.  The PolicyExplicitVariable
   class indicates the exact model property to be matched against in a policy condition. evaluated or manipulated.

   The class definition is as follows:

     NAME             PolicyIPv4AddrValue             PolicyExplicitVariable
     DERIVED FROM     PolicyValue     PolicyVariable
     ABSTRACT         False
     PROPERTIES       IPv4AddrList[ ]       ModelClass, ModelProperty

 5.10.1. The IPv4AddrList Single-Valued Property "ModelClass"

   This property provides an unordered list of strings, each is a string specifying the class name whose property is
   evaluated or set as a single IPv4 address, PolicyVariable.  The property is defined as
   follows:

     NAME             ModelClass
     SYNTAX           String

 5.10.2. The Single-Valued Property ModelProperty

   This property is a hostname, string specifying the property name, within the
   ModelClass, which is evaluated or set as a range of IPv4
   addresses, according to the ABNF definition [8] of an IPv4 address, as
   specified below:

       IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
       IPv4prefix  = IPv4address "/" 1*2DIGIT
       IPv4range = IPv4address"-"IPv4address
       IPv4maskedaddress = IPv4address","IPv4address
       Hostname (as defined in [9])

   In the above definition, each string entry PolicyVariable.  The property
   is either:

     1.  A single Ipv4address in dot notation, as defined above.  Example:
         121.1.1.2

     2.  An IPv4prefix address range, as defined above, specified by an
         address and a prefix length, separated by "/".  Example:
         2.3.128.0/15

     3.  An IPv4range address range defined above, specified by a starting
         address in dot notation and an ending address in dot notation,
         separated by "-". follows:

     NAME             ModelProperty
     SYNTAX           String

 5.11. The range includes all addresses between Abstract Class "PolicyImplicitVariable"

   Implicitly defined policy variables are evaluated outside of the
         range's starting context
   of the CIM Schema and ending addresses, including these two
         addresses.  Example: 1.1.22.1-1.1.22.5

     4.  An IPv4maskedaddress address range, as defined above, specified by
         an address its modeling constructs.  Subclasses specify the
   data type and mask.  The address semantics of the PolicyVariables.

   Interpretation and mask are represented evaluation of a PolicyImplicitVariable can vary,
   depending on the particular context in dot
         notation, separated by which it is used.  For example, a comma ",".  The masked
   "SourceIP" address appears
         before the comma, and the mask appears after may denote the comma.  Example:
         2.3.128.0,255.255.248.0.

     5.  A single Hostname.  The Hostname format follows source address field of an IP packet
   header, or the guidelines and
         restrictions specified in [9].  Example: www.bigcompany.com. sender address delivered by an RSVP PATH message.

   The property class definition is as follows:

     NAME             IPv4AddrList
     SYNTAX           String
     FORMAT           IPv4address | IPv4prefix | IPv4range |
                      IPv4maskedaddress | hostname

 5.14.2.             PolicyImplicitVariable
     DERIVED FROM     PolicyVariable
     ABSTRACT         True
     PROPERTIES       ValueTypes[ ]
 5.11.1. The Class "PolicyIPv6AddrValue Multi-Valued Property "ValueTypes"

   This class property is used to define a set of strings specifying an unordered list of IPv6 addresses, hostnames,
   possible value/data types that can be used in simple conditions and
   address range values.
   actions, with this variable.  The value types are specified by their
   class definition names (subclasses of PolicyValue such as PolicyStringValue).  The
   list of class names enables an application to search on a specific name,
   as well as to ensure that the data type of the variable is of the correct
   type.

   The list of default ValueTypes for each subclass of
   PolicyImplicitVariable is specified within that variable's definition.

   The property is defined as follows:

     NAME             PolicyIPv6AddrValue             ValueTypes
     SYNTAX           String

 5.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe

   The following subclasses of PolicyImplicitVariable are defined in PCIMe.

 5.12.1. The Class "PolicySourceIPv4Variable"

     NAME             PolicySourceIPv4Variable
     DESCRIPTION      The source IPv4 address. of the outermost IP packet
                      header.

                      ALLOWED VALUE TYPES:
                        - PolicyIPv4AddrValue

     DERIVED FROM     PolicyValue     PolicyImplicitVariable
     ABSTRACT         False         FALSE
     PROPERTIES       IPv6AddrList[ ]       (none)

 5.12.2. The property IPv6AddrList provides an unordered list of strings, each
   specifying an Class "PolicySourceIPv6Variable"

     NAME             PolicySourceIPv6Variable
     DESCRIPTION      The source IPv6 address, a hostname, or a range address of IPv6 addresses.
   IPv6 the outermost IP packet
                      header.

                      ALLOWED VALUE TYPES:
                        - PolicyIPv6AddrValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.3. The Class "PolicyDestinationIPv4Variable"

     NAME             PolicyDestinationIPv4Variable
     DESCRIPTION      The destination IPv4 address format definition uses of the standard outermost IP
                      packet header.

                      ALLOWED VALUE TYPES:
                        - PolicyIPv4AddrValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.4. The Class "PolicyDestinationIPv6Variable"

     NAME             PolicyDestinationIPv6Variable
     DESCRIPTION      The destination IPv6 address format defined
   in [10]. of the outermost IP
                      packet header.

                      ALLOWED VALUE TYPES:
                        - PolicyIPv6AddrValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.5. The ABNF definition [8] as specified in [10] is:

       IPv6address = hexpart [ ":" IPv4address ]
       IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
       IPv6prefix  = hexpart "/" 1*2DIGIT
       hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
       hexseq  = hex4 *( ":" hex4)
       hex4    = 1*4HEXDIG
       IPv6range = IPv6address"-"IPv6address
       IPv6maskedaddress = IPv6address","IPv6address
       Hostname (as defines in [NAMES])

   Each string entry is either:

     1.  A single IPv6address as Class "PolicySourcePortVariable"

     NAME             PolicySourcePortVariable
     DESCRIPTION      Ports are defined above.

     2.  A single Hostname.  Hostname format follows guidelines and
         restrictions specified in [9].

     3.  An IPv6range address range, specified by as the abstraction that transport
                      protocols use to distinguish among multiple
                      destinations within a starting address in dot
         notation given host computer.  For TCP
                      and an ending address in dot notation, separated by "-".
         The range includes all addresses between UDP flows, the range's starting and
         ending addresses, including these two addresses.

     4.  An IPv4maskedaddress address range defined above specified by an
         address and mask. The address and mask are represented in dot
         notation separated by a comma ",".

     5.  A single IPv6prefix as defined above.

 5.14.3. The Class "PolicyMACAddrValue"

   This class PolicySourcePortVariable is used
                      logically bound to define a list the source port field of MAC addresses and MAC address
   range values.  The class definition is as follows:

     NAME             PolicyMACAddrValue the
                      outermost UDP or TCP packet header.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue (0..65535)

     DERIVED FROM     PolicyValue     PolicyImplicitVariable
     ABSTRACT         False         FALSE
     PROPERTIES       MACAddrList[ ]

   The property MACAddrList provides an unordered list of strings, each
   specifying a MAC address or a range of MAC addresses.       (none)

 5.12.6. The 802 MAC
   address canonical format is used. The ABNF definition [8] is:

       MACaddress  = 1*4HEXDIG ":" 1*4HEXDIG ":" 1*4HEXDIG
       MACmaskedaddress = MACaddress","MACaddress

   Each string entry is either:

     1.  A single MAC address. Example: 0000:00A5:0000

     2.  A MACmaskedaddress address range Class "PolicyDestinationPortVariable"

     NAME             PolicyDestinationPortVariable
     DESCRIPTION      Ports are defined specified by an address as the abstraction that transport
                      protocols use to distinguish among multiple
                      destinations within a given host computer.  For TCP
                      and mask.  The mask specifies UDP flows, the relevant bits in PolicyDestinationPortVariable is
                      logically bound to the address.
         Example: 0000:00A5:0000,FFFF:FFFF:0000 defines a range destination port field of MAC
         addresses in which the first four octets are equal to 0000:00A5.
                      outermost UDP or TCP packet header.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue (0..65535)
     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.7. The property definition is as follows: Class "PolicyIPProtocolVariable"

     NAME             MACAddrList
     SYNTAX           String
     FORMAT           MACaddress | MACmaskedaddress

 5.14.4.             PolicyIPProtocolVariable
     DESCRIPTION      The IP protocol number.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.8. The Class "PolicyStringValue"

   This class is used to represent a single string value, or a set of string
   values.  Each value can have wildcards. "PolicyIPVersionVariable"

     NAME             PolicyIPVersionVariable
     DESCRIPTION      The class definition is as
   follows: IP version number.  The well-known values are 4
                      and 6.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.9. The Class "PolicyIPToSVariable"

     NAME             PolicyStringValue             PolicyIPToSVariable
     DESCRIPTION      The IP TOS octet.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue (0..7)
                        - PolicyBitStringValue

     DERIVED FROM     PolicyValue     PolicyImplicitVariable
     ABSTRACT         False         FALSE
     PROPERTIES       StringList[ ]       (none)

 5.12.10. The property StringList provides an unordered list of strings, each
   representing a single string with wildcards. Class "PolicyDSCPVariable"

     NAME             PolicyDSCPVariable
     DESCRIPTION      The asterisk character "*"
   is used as a wildcard, and represents an arbitrary substring replacement.
   For example, the value "abc*def" matches the string "abcxyzdef", and the
   value "abc*def*" matches the string "abcxxxdefyyyzzz". 6 bit Differentiated Service Code Point.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue (0..63)
                        - PolicyBitStringValue
     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.11. The syntax
   definition is identical to the substring assertion syntax defined in
   [11].  If the asterisk character is required as part Class "PolicyFlowIdVariable"

     NAME             PolicyFlowIdVariable
     DESCRIPTION      The flow identifer of the string value
   itself, it MUST be quoted as described in section 4.3 of [11]. outermost IPv6 packet
                      header.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue
                        - PolicyBitStringValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.12. The property definition is as follows: Class "PolicySourceMACVariable"

     NAME                 StringList
     SYNTAX               String

 5.14.5.             PolicySourceMACVariable
     DESCRIPTION      The source MAC address.

                      ALLOWED VALUE TYPES:
                        - PolicyMACAddrValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.13. The Class "PolicyBitStringValue"

   This class is used to represent a single bit string value, or a set of
   bit string values. "PolicyDestinationMACVariable"

     NAME             PolicyDestinationMACVariable
     DESCRIPTION      The class definition is as follows: destination MAC address.

                      ALLOWED VALUE TYPES:
                        - PolicyMACAddrValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.14. The Class "PolicyVLANVariable"

     NAME             PolicyVLANVariable
     DESCRIPTION      The virtual Bridged Local Area Network Identifier, a
                      12-bit field as defined in the IEEE 802.1q standard.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue
                        - PolicyBitStringValue
     DERIVED FROM     PolicyValue     PolicyImplicitVariable
     ABSTRACT         False         FALSE
     PROPERTIES       BitStringList[ ]       (none)

 5.12.15. The property BitStringList provides an unordered list Class "PolicyCoSVariable"

     NAME             PolicyCoSVariable
     DESCRIPTION      Class of strings, each
   representing a single bit string or Service, a set of bit strings.  The number of
   bits specified SHOULD equal the number of bits of 3-bit field, used in the expected variable.
   For example, for a one-octet variable, 8 bits should be specified.  If
   the variable does not have a fixed length, layer 2
                      header to select the bit string should be
   matched against forwarding treatment.  Bound to
                      the variable's most significant bit string. IEEE 802.1q user-priority field.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue
                        - PolicyBitStringValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.16. The formal
   definition of a bit string is:

       binary-digit = "0" / "1"
       bitString = 1*binary-digit
       maskedBitString = bitString","bitString

   Each string entry is either:

     1.  A single bit string. Example: 00111010

     2.  A range of bit strings specified using a bit string and a bit
         mask. Class "PolicyEthertypeVariable"

     NAME             PolicyEthertypeVariable
     DESCRIPTION      The bit string and mask fields have the same Ethertype protocol number of bits
         specified.  The mask bit string specifies the significant bits in
         the bit string value.  For example, 110110, 100110 and 110111
         would match the maskedBitString 100110,101110 but 100100 would
         not. Ethernet frames.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue
                        - PolicyBitStringValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.17. The property definition is as follows: Class "PolicySourceSAPVariable"

     NAME             BitStringList
     SYNTAX           String
     FORMAT           bitString | maskedBitString

 5.14.6.             PolicySourceSAPVariable
     DESCRIPTION      The Class "PolicyIntegerValue"

   This class provides a list of integer and integer range values.  Integers Source Service Access Point (SAP) number of arbitrary sizes can be represented.  The class definition is as
   follows:

     NAME the
                      IEEE 802.2 LLC header.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue
                        - PolicyBitStringValue

     DERIVED FROM     PolicyValue     PolicyImplicitVariable
     ABSTRACT         False         FALSE
     PROPERTIES       IntegerList[ ]       (none)

 5.12.18. The property IntegerList provides an unordered list of integers and
   integer range values, represented as strings. Class "PolicyDestinationSAPVariable"

     NAME             PolicyDestinationSAPVariable
     DESCRIPTION      The format of this
   property takes one Destination Service Access Point (SAP) number of
                      the following forms:

     1.  An integer value.

     2.  A range of integers. IEEE 802.2 LLC header.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue
                        - PolicyBitStringValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.19. The range is specified by Class "PolicySNAPVariable"

     NAME             PolicySNAPVariable
     DESCRIPTION      The protocol number over a starting integer
         and an ending integer, separated by '-'. Sub-Network Access Protocol
                      (SNAP) SAP encapsulation.

                      ALLOWED VALUE TYPES:
                        - PolicyIntegerValue
                        - PolicyBitStringValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

 5.12.20. The starting integer
         MUST be less than or equal to the ending integer. Class "PolicyFlowDirectionVariable"

     NAME             PolicyFlowDirectionVariable
     DESCRIPTION      The range
         includes all integers between the starting direction of a flow relative to a network element.
                      Direction may be "IN" and/or "OUT".

                      ALLOWED VALUE TYPES:
                        - PolicyStringValue

     DERIVED FROM     PolicyImplicitVariable
     ABSTRACT         FALSE
     PROPERTIES       (none)

   To match on both inbound and ending integers,
         including these outbound flows, the associated
   PolicyStringValue object has two integers.  Care must be taken entries in reading
         integer ranges involving negative integers, since the unary minus its StringList property: "IN"
   and the range indicator are the same character '-'.

   To represent a range of integers that "OUT".

 5.13. The Abstract Class "PolicyValue"

   This is not bounded, an abstract class that serves as the reserved words
   -INFINITY and/or INFINITY can be base class for all
   subclasses that are used to define value objects in place of the starting PCIMe.  It is
   used for defining values and ending
   integers. constants used in policy conditions.  The ABNF definition [8] is:

     integer = [-]1*DIGIT | "INFINITY" | "-INFINITY"
     integerrange = integer"-"integer

   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-
   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
   for the SimplePolicyCondition class to be kept simple (i.e., just the
   value "match").

   The property
   class definition is as follows:

     NAME             IntegerList
     SYNTAX           String
     FORMAT           integer | integerrange

 5.14.7.             PolicyValue
     DERIVED FROM     Policy
     ABSTRACT         True
     PROPERTIES       (none)
 5.14. Subclasses of "PolicyValue" Specified in PCIMe

   The following subsections contain the PolicyValue subclasses defined in
   PCIMe.  Additional subclasses may be defined in models derived from
   PCIMe.

 5.14.1. The Class "PolicyBooleanValue" "PolicyIPv4AddrValue"

   This class is used to represent provide a Boolean (TRUE/FALSE) value. list of IPv4Addresses, hostnames and
   address range values to be matched against in a policy condition.  The
   class definition is as follows:

     NAME             PolicyBooleanValue             PolicyIPv4AddrValue
     DERIVED FROM     PolicyValue
     ABSTRACT         False
     PROPERTIES       BooleanValue       IPv4AddrList[ ]

   The IPv4AddrList property definition is as follows:

     NAME             BooleanValue
     SYNTAX           boolean

 5.15. The Class "PolicyRoleCollection"

   This class represents a collection provides an unordered list of managed elements that share strings, each
   specifying a
   common role. The PolicyRoleCollection always exists in the context of single IPv4 address, a
   system, specified using the PolicyRoleCollectionInSystem association.
   The value hostname, or a range of IPv4
   addresses, according to the PolicyRole property in this class specifies the role,
   and can be matched with the value(s) in the PolicyRoles array in
   PolicyRules and PolicyGroups.  ManagedElements that share the role ABNF definition [8] of an IPv4 address, as
   specified below:

       IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
       IPv4prefix  = IPv4address "/" 1*2DIGIT
       IPv4range = IPv4address"-"IPv4address
       IPv4maskedaddress = IPv4address","IPv4address
       Hostname (as defined in this collection are aggregated into the collection via [9])

   In the
   association ElementInPolicyRoleCollection.

     NAME             PolicyRoleCollection
     DESCRIPTION above definition, each string entry is either:

     1.  A subclass of the CIM Collection class used to group
                      together managed elements that share single IPv4address in dot notation, as defined above.  Example:
         121.1.1.2

     2.  An IPv4prefix address range, as defined above, specified by an
         address and a role.
     DERIVED FROM     Collection
     ABSTRACT         FALSE
     PROPERTIES       PolicyRole

 5.15.1. prefix length, separated by "/".  Example:
         2.3.128.0/15

     3.  An IPv4range address range defined above, specified by a starting
         address in dot notation and an ending address in dot notation,
         separated by "-".  The Single-Valued Property "PolicyRole"

   This property represents range includes all addresses between the role associated with
         range's starting and ending addresses, including these two
         addresses.  Example: 1.1.22.1-1.1.22.5

     4.  An IPv4maskedaddress address range, as defined above, specified by
         an address and mask.  The address and mask are represented in dot
         notation, separated by a PolicyRoleCollection. comma ",".  The masked address appears
         before the comma, and the mask appears after the comma.  Example:
         2.3.128.0,255.255.248.0.

     5.  A single Hostname.  The Hostname format follows the guidelines and
         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:

     NAME             PolicyRole
     DESCRIPTION      A string representing the role associated with a
                      PolicyRoleCollection.             IPv4AddrList
     SYNTAX           string

 5.16.           String
     FORMAT           IPv4address | IPv4prefix | IPv4range |
                      IPv4maskedaddress | hostname

 5.14.2. The Class "ReusablePolicyContainer" "PolicyIPv6AddrValue

   This class is used to define a list of IPv6 addresses, hostnames, and
   address range values. The new class ReusablePolicyContainer definition is defined as follows:

     NAME             ReusablePolicyContainer
     DESCRIPTION      A class representing an administratively defined
                      container for reusable policy-related information.
                      This class does not introduce any additional
                      properties beyond those in its superclass AdminDomain.
                      It does, however, participate in a number of unique
                      associations.             PolicyIPv6AddrValue
     DERIVED FROM     AdminDomain     PolicyValue
     ABSTRACT         FALSE         False
     PROPERTIES       (none)

 5.17. Deprecation of PCIM's Class "PolicyRepository"       IPv6AddrList[ ]

   The class definition of PolicyRepository (from PCIM) is updated as
   follows, with property IPv6AddrList provides an indication that the class has been deprecated.  Note
   that when unordered list of strings, each
   specifying an element IPv6 address, a hostname, or a range of IPv6 addresses.
   IPv6 address format definition uses the model is deprecated, its replacement element standard address format defined
   in [10].  The ABNF definition [8] as specified in [10] is:

       IPv6address = hexpart [ ":" IPv4address ]
       IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
       IPv6prefix  = hexpart "/" 1*2DIGIT
       hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
       hexseq  = hex4 *( ":" hex4)
       hex4    = 1*4HEXDIG
       IPv6range = IPv6address"-"IPv6address
       IPv6maskedaddress = IPv6address","IPv6address
       Hostname (as defines in [NAMES])

   Each string entry is identified explicitly.

     NAME             PolicyRepository
     DEPRECATED FOR   ReusablePolicyContainer
     DESCRIPTION either:

     1.  A class representing an administratively single IPv6address as defined
                      container for reusable policy-related information.
                      This class does not introduce any additional
                      properties beyond those in its superclass AdminDomain.
                      It does, however, participate above.

     2.  A single Hostname.  Hostname format follows guidelines and
         restrictions specified in [9].

     3.  An IPv6range address range, specified by a number of unique
                      associations.
     DERIVED FROM     AdminDomain
     ABSTRACT         FALSE
     PROPERTIES       (none)

 6. Association starting address in dot
         notation and Aggregation Definitions

   The following definitions supplement those an ending address in PCIM itself.  PCIM
   definitions that are not DEPRECATED here are still current parts of the
   overall Policy Core Information Model.

 6.1. dot notation, separated by "-".
         The Abstract Aggregation "PolicySetComponent"

   PolicySetComponent is a new abstract aggregation class that collects
   instances of PolicySet subclasses (PolicyGroups range includes all addresses between the range's starting and PolicyRules) into
   coherent sets of policies.

     NAME             PolicySetComponent
     DESCRIPTION
         ending addresses, including these two addresses.

     4.  An abstract class representing IPv4maskedaddress address range defined above specified by an
         address and mask. The address and mask are represented in dot
         notation separated by a comma ",".

     5.  A single IPv6prefix as defined above.

   Conditions matching IPv6AddrValues evaluate to true according to the components of
   generic matching rules.  Additionally, a
                      policy set that have hostname is matched against
   another valid IPv6address representation by resolving the same decision strategy, hostname into
   an IPv6 address first, and
                      are prioritized within then comparing the set.
     DERIVED FROM     PolicyComponent
     ABSTRACT         TRUE
     PROPERTIES       GroupComponent[ref PolicySet[0..n]]
                      PartComponent[ref PolicySet[0..n]]
                      Priority

   The definition addresses afterwards.
   Matching hostnames against each other is done using a string comparison
   of the Priority property two names.

 5.14.3. The Class "PolicyMACAddrValue"

   This class is unchanged from its previous
   definition in [PCIM].

     NAME             Priority
     DESCRIPTION      A non-negative integer for prioritizing this PolicySet
                      component relative used to other components of the same
                      PolicySet.  A larger value indicates define a higher
                      priority.
     SYNTAX           uint16
     DEFAULT VALUE    0

 6.2. Update to PCIM's Aggregation "PolicyGroupInPolicyGroup" list of MAC addresses and MAC address
   range values.  The PolicyGroupInPolicyGroup aggregation class definition is modified to be derived
 from PolicySetComponent. as follows:

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

 6.3. Update to PCIM's Aggregation "PolicyRuleInPolicyGroup"       MACAddrList[ ]

   The PolicyRuleInPolicyGroup aggregation class is modified to be derived
   from PolicySetComponent.

     NAME             PolicyRuleInPolicyGroup
     DESCRIPTION      A class representing the aggregation property MACAddrList provides an unordered list of PolicyRules by strings, each
   specifying a PolicyGroup.
     DERIVED FROM     PolicySetComponent
     ABSTRACT         FALSE
     PROPERTIES       GroupComponent[ref PolicyGroup[0..n]]
                      PartComponent[ref PolicyRule[0..n]]

 6.4. The Aggregation "PolicyGroupInPolicyRule"

   A policy rule may aggregate one MAC address or more policy groups, via the
   PolicyGroupInPolicyRule aggregation.  Grouping of policy groups and their
   subclasses into a policy rule range of MAC addresses.  The 802 MAC
   address canonical format is for administrative convenience,
   scalability and manageability, as it enables more complex policies to be
   constructed from multiple simpler policies.

   Policy rules do not have to contain policy groups.  In addition, a policy
   group may also be used used. The ABNF definition [8] is:

       MACaddress  = 1*4HEXDIG ":" 1*4HEXDIG ":" 1*4HEXDIG
       MACmaskedaddress = MACaddress","MACaddress

   Each string entry is either:

     1.  A single MAC address. Example: 0000:00A5:0000

     2.  A MACmaskedaddress address range defined specified by itself, without belonging to a policy rule, an address
         and
   policy rules may be individually aggregated by other policy rules by mask.  The mask specifies the
   PolicyRuleInPolicyRule aggregation.  Note that it relevant bits in the address.
         Example: 0000:00A5:0000,FFFF:FFFF:0000 defines a range of MAC
         addresses in which the first four octets are equal to 0000:00A5.

   The property definition is assumed that this
   aggregation as follows:

     NAME             MACAddrList
     SYNTAX           String
     FORMAT           MACaddress | MACmaskedaddress

 5.14.4. The Class "PolicyStringValue"

   This class is used to form directed acyclic graphs and NOT ring
   structures. represent a single string value, or a set of string
   values.  Each value can have wildcards. The class definition for this aggregation is as
   follows:

     NAME             PolicyGroupInPolicyRule             PolicyStringValue
     DERIVED FROM     PolicySetComponent     PolicyValue
     ABSTRACT         False
     PROPERTIES       GroupComponent[ref PolicyRule[0..n]]
                      PartComponent[ref PolicyGroup[0..n]]       StringList[ ]

   The reference property "GroupComponent" is inherited from
   PolicySetComponent, and overridden to become StringList provides an object reference to unordered list of strings, each
   representing 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. string with wildcards.  The reference property "PartComponent" asterisk character "*"
   is inherited from
   PolicySetComponent, used as a wildcard, and overridden to become represents an object reference to a
   PolicyGroup contained by one or more PolicyRules.  Note that for any
   single instance of arbitrary substring replacement.
   For example, the aggregation class PolicyGroupInPolicyRule, this
   property (like all reference properties) is single-valued.  The [0..n]
   cardinality indicates that a given PolicyRule may contain 0, 1, or more
   than one PolicyGroup.

 6.5. The Aggregation "PolicyRuleInPolicyRule"

   A policy rule may aggregate one or more policy rules, via value "abc*def" matches the
   PolicyRuleInPolicyRule aggregation. string "abcxyzdef", and the
   value "abc*def*" matches the string "abcxxxdefyyyzzz".  The ability syntax
   definition is identical to nest policy rules and
   form sub-rules the substring assertion syntax defined in
   [11].  If the asterisk character is important for manageability and scalability, required as it
   enables complex policy rules to be constructed from multiple simpler
   policy rules.

   A policy rule does not have to contain sub-rules.  A policy rule may
   contain a group part of sub-rules using the PolicyGroupInPolicyRule
   aggregation.  Note that string value
   itself, it is assumed that this aggregation is used to
   form directed a-cyclic graphs and NOT ring structures. MUST be quoted as described in section 4.3 of [11].

   The class property definition for this aggregation is as follows:

     NAME             PolicyRuleInPolicyRule
     DERIVED FROM     PolicySetComponent                 StringList
     SYNTAX               String

 5.14.5. The Class "PolicyBitStringValue"

   This class is used to represent a single bit string value, or a set of
   bit string values.  The class definition is as follows:

     NAME             PolicyBitStringValue
     DERIVED FROM     PolicyValue
     ABSTRACT         False
     PROPERTIES       GroupComponent[ref PolicyRule[0..n]]
                      PartComponent[ref PolicyRule[0..n]]       BitStringList[ ]

   The reference property "GroupComponent" is inherited from
   PolicySetComponent, and overridden to become BitStringList provides an object reference to unordered list of strings, each
   representing a
   PolicyRule that contains one single bit string or more PolicyRules.  Each contained
   PolicyRule can be conceptualized as a sub-rule set of bit strings.  The number of
   bits specified SHOULD equal the containing
   PolicyRule.  This nesting can number of bits of the expected variable.
   For example, for a one-octet variable, 8 bits should be done to any desired level.  However, specified.  If
   the
   deeper variable does not have a fixed length, the nesting, bit string should be
   matched against the more complex variable's most significant bit string.  The formal
   definition of a bit string is:

       binary-digit = "0" / "1"
       bitString = 1*binary-digit
       maskedBitString = bitString","bitString

   Each string entry is either:

     1.  A single bit string. Example: 00111010

     2.  A range of bit strings specified using a bit string and a bit
         mask.  The bit string and mask fields have the results same number of bits
         specified.  The mask bit string specifies the decisions taken
   by significant bits in
         the nested rules.

   Note that for any single instance of bit string value.  For example, 110110, 100110 and 110111
         would match the aggregation class
   PolicyRuleInPolicyRule, this maskedBitString 100110,101110 but 100100 would
         not.

   The property definition is single-valued. as follows:

     NAME             BitStringList
     SYNTAX           String
     FORMAT           bitString | maskedBitString

 5.14.6. The [0..n]
   cardinality indicates that there may be 0, 1  or more than one
   PolicyRules that contain any given PolicyRule.

   The reference property "PartComponent" is inherited from
   PolicySetComponent, and overridden to become an object reference to a
   PolicyRule contained by Class "PolicyIntegerValue"

   This class provides a PolicyRule.  Note that for any single instance list of the aggregation integer and integer range values.  Integers
   of arbitrary sizes can be represented.  The class PolicyRuleInPolicyRule, this property definition is single-
   valued.  The [0..n] cardinality indicates that a given PolicyRule may
   contain 0, 1, or more than one other PolicyRules.

 6.6. The Abstract Aggregation "CompoundedPolicyCondition" as
   follows:

     NAME             CompoundedPolicyCondition
     DESCRIPTION      A class representing the aggregation of
                      PolicyConditions by an aggregating instance.             PolicyIntegerValue
     DERIVED FROM     PolicyComponent     PolicyValue
     ABSTRACT         TRUE         False
     PROPERTIES       PartComponent[ref PolicyCondition[0..n]]
                      GroupNumber
                      ConditionNegated

 6.7. Update to PCIM's Aggregation "PolicyConditionInPolicyRule"       IntegerList[ ]

   The PCIM aggregation "PolicyConditionInPolicyRule" is updated, to make it
   a subclass property IntegerList provides an unordered list of the new abstract aggregation CompoundedPolicyCondition.
   The properties GroupNumber integers and ConditionNegated are now inherited, rather
   than specified explicitly
   integer range values, represented as they were in PCIM.

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

 6.8. strings.  The Aggregation "PolicyConditionInPolicyCondition"

   A second subclass format of CompoundedPolicyCondition is defined, representing
   the compounding this
   property takes one of policy conditions into a higher-level policy
   condition.

     NAME             PolicyConditionInPolicyCondition
     DESCRIPTION      A class representing the aggregation of
                      PolicyConditions by another PolicyCondition.
     DERIVED FROM     CompoundedPolicyCondition
     ABSTRACT         FALSE
     PROPERTIES       GroupComponent[ref PolicyCondition[0..n]]

 6.9. The Abstract Aggregation "CompoundedPolicyAction"

     NAME             CompoundedPolicyAction
     DESCRIPTION following forms:

     1.  An integer value.

     2.  A class representing the aggregation range of PolicyActions integers. The range is specified by a starting integer
         and an aggregating instance.
     DERIVED FROM     PolicyComponent
     ABSTRACT         TRUE
     PROPERTIES       PartComponent[ref PolicyAction[0..n]]
                      ActionOrder

 6.10. Update ending integer, separated by '..'.  The starting integer
         MUST be less than or equal to PCIM's Aggregation "PolicyActionInPolicyRule" the ending integer.  The PCIM aggregation "PolicyActionInPolicyRule" range
         includes all integers between the starting and ending integers,
         including these two integers.

   To represent a range of integers that is updated, not bounded, the reserved words
   -INFINITY and/or INFINITY can be used in place of the starting and ending
   integers.  In addition to make it a
   subclass ordinary integer matches, INFINITY matches
   INFINITY and -INFINITY matches -INFINITY.

   The ABNF definition [8] is:

     integer = [-]1*DIGIT | "INFINITY" | "-INFINITY"
     integerrange = integer".."integer

   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-
   greater-than 5" (where X is an integer) can be translated to "X matches
   6-INFINITY".  This enables the match condition semantics of the new abstract aggregation CompoundedPolicyAction. operator
   for the SimplePolicyCondition class to be kept simple (i.e., just the
   value "match").

   The property ActionOrder definition is now inherited, rather than specified explicitly as it was in PCIM. follows:

     NAME             PolicyActionInPolicyRule
     DESCRIPTION      A             IntegerList
     SYNTAX           String
     FORMAT           integer | integerrange
 5.14.7. The Class "PolicyBooleanValue"

   This class representing the aggregation of PolicyActions
                      by is used to represent a PolicyRule. Boolean (TRUE/FALSE) value.  The class
   definition is as follows:

     NAME             PolicyBooleanValue
     DERIVED FROM     CompoundedPolicyAction     PolicyValue
     ABSTRACT         FALSE         False
     PROPERTIES       GroupComponent[ref PolicyRule[0..n]]

 6.11.       BooleanValue

   The Aggregation "PolicyActionInPolicyAction"

   A second subclass of CompoundedPolicyAction property definition is defined, representing the
   compounding of policy actions into a higher-level policy action. as follows:

     NAME             PolicyActionInPolicyAction
     DESCRIPTION      A             BooleanValue
     SYNTAX           boolean

 5.15. The Class "PolicyRoleCollection"

   This class representing the aggregation represents a collection of PolicyActions
                      by another PolicyAction. managed elements that share a
   common role. The PolicyRoleCollection always exists in the context of a
   system, specified using the PolicyRoleCollectionInSystem association.
   The value of the PolicyRole property in this class specifies the role,
   and can be matched with the value(s) in the PolicyRoles array in
   PolicyRules and PolicyGroups.  ManagedElements that share the role
   defined in this collection are aggregated into the collection via the
   association ElementInPolicyRoleCollection.

     NAME             PolicyRoleCollection
     DESCRIPTION      A subclass of the CIM Collection class used to group
                      together managed elements that share a role.
     DERIVED FROM     CompoundedPolicyAction     Collection
     ABSTRACT         FALSE
     PROPERTIES       GroupComponent[ref PolicyAction[0..n]]

 6.12.       PolicyRole

 5.15.1. The Aggregation "PolicyVariableInSimplePolicyCondition"

   A simple policy condition is represented as an ordered triplet {variable,
   operator, value}. Single-Valued Property "PolicyRole"

   This aggregation provides property represents the linkage between a
   SimplePolicyCondition instance and role associated with a single PolicyVariable. PolicyRoleCollection.
   The
   aggregation PolicyValueInSimplePolicyCondition links property definition is as follows:

     NAME             PolicyRole
     DESCRIPTION      A string representing the
   SimplePolicyCondition to role associated with a single PolicyValue.
                      PolicyRoleCollection.
     SYNTAX           string

 5.16. The Operator property of
   SimplePolicyCondition represents the third element of the triplet, the
   operator. Class "ReusablePolicyContainer"

   The new class definition for this aggregation ReusablePolicyContainer is defined as follows:

     NAME             PolicyVariableInSimplePolicyCondition             ReusablePolicyContainer
     DESCRIPTION      A class representing an administratively defined
                      container for reusable policy-related information.
                      This class does not introduce any additional
                      properties beyond those in its superclass AdminDomain.

                      It does, however, participate in a number of unique
                      associations.
     DERIVED FROM     PolicyComponent     AdminDomain
     ABSTRACT         False         FALSE
     PROPERTIES       GroupComponent[ref SimplePolicyCondition[0..n]]
                      PartComponent[ref PolicyVariable[1..1] ]       (none)

 5.17. Deprecate PCIM's Class "PolicyRepository"

   The reference property "GroupComponent" class definition of PolicyRepository (from PCIM) is inherited from
   PolicyComponent, and overridden to become updated as
   follows, with an object reference to a
   SimplePolicyCondition indication that contains exactly one PolicyVariable. the class has been deprecated.  Note
   that for any single instance when an element of the aggregation class
   PolicyVariableInSimplePolicyCondition, this property model is single-valued.
   The [0..n] cardinality indicates that there may be 0, 1, or more
   SimplePolicyCondition objects that contain any given policy variable
   object.

   The reference property "PartComponent" deprecated, its replacement element
   is inherited from PolicyComponent,
   and overridden to become identified explicitly.

     NAME             PolicyRepository
     DEPRECATED FOR   ReusablePolicyContainer
     DESCRIPTION      A class representing an object reference to a PolicyVariable that is administratively defined within the scope of a SimplePolicyCondition.  Note that
                      container for reusable policy-related information.
                      This class does not introduce any
   single instance additional
                      properties beyond those in its superclass AdminDomain.
                      It does, however, participate in a number of the association class
   PolicyVariableInSimplePolicyCondition, this property (like all reference
   properties) is single-valued. unique
                      associations.
     DERIVED FROM     AdminDomain
     ABSTRACT         FALSE
     PROPERTIES       (none)

 6. Association and Aggregation Definitions

   The [1..1] cardinality indicates that a
   SimplePolicyCondition must have exactly one policy variable defined
   within its scope following definitions supplement those in order to be meaningful.

 6.13. PCIM itself.  PCIM
   definitions that are not DEPRECATED here are still current parts of the
   overall Policy Core Information Model.

 6.1. The Aggregation "PolicyValueInSimplePolicyCondition"

   A simple policy condition "PolicySetComponent"

   PolicySetComponent is represented as an ordered triplet {variable,
   operator, value}.  This aggregation provides the linkage between a
   SimplePolicyCondition instance and a single PolicyValue.  The new aggregation
   PolicyVariableInSimplePolicyCondition links the SimplePolicyCondition to
   a single PolicyVariable.  The Operator property class that collects instances of SimplePolicyCondition
   represents
   PolicySet subclasses (PolicyGroups and PolicyRules) into coherent sets of
   policies.

     NAME             PolicySetComponent
     DESCRIPTION      A concrete class representing the third element components of a
                      policy set that have the triplet, same decision strategy, and
                      are prioritized within the operator. set.
     DERIVED FROM     PolicyComponent
     ABSTRACT         FALSE
     PROPERTIES       GroupComponent[ref PolicySet[0..n]]
                      PartComponent[ref PolicySet[0..n]]
                      Priority

   The class definition of the Priority property is unchanged from its previous
   definition in [PCIM].

     NAME             Priority
     DESCRIPTION      A non-negative integer for prioritizing this PolicySet
                      component relative to other components of the same
                      PolicySet.  A larger value indicates a higher
                      priority.
     SYNTAX           uint16
     DEFAULT VALUE    0

 6.2. Deprecate PCIM's Aggregation "PolicyGroupInPolicyGroup"

 The new aggregation PolicySetComponent is as follows: used directly to represent
 aggregation of PolicyGroups by a higher-level PolicyGroup.  Thus the
 aggregation PolicyGroupInPolicyGroup is no longer needed, and can be
 deprecated.

     NAME             PolicyValueInSimplePolicyCondition             PolicyGroupInPolicyGroup
     DEPRECATED FOR   PolicySetComponent
     DESCRIPTION      A class representing the aggregation of PolicyGroups
                      by a higher-level PolicyGroup.
     DERIVED FROM     PolicyComponent
     ABSTRACT         False         FALSE
     PROPERTIES       GroupComponent[ref SimplePolicyCondition[0..n]] PolicyGroup[0..n]]
                      PartComponent[ref PolicyValue[1..1] ] PolicyGroup[0..n]]

 6.3. Deprecate PCIM's Aggregation "PolicyRuleInPolicyGroup"

   The reference property "GroupComponent" new aggregation PolicySetComponent is inherited from
   PolicyComponent, and overridden to become an object reference used directly to a
   SimplePolicyCondition that contains exactly one PolicyValue.  Note that
   for any single instance represent
   aggregation of PolicyRules by a PolicyGroup.  Thus the aggregation class
   PolicyValueInSimplePolicyCondition, this property
   PolicyRuleInPolicyGroup is single-valued.  The
   [0..n] cardinality indicates that there may no longer needed, and can be 0, 1, or more
   SimplePolicyCondition objects that contain any given policy value object. deprecated.

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

 6.4. The reference property "PartComponent" Abstract Association "PolicySetInSystem"

   PolicySetInSystem is inherited from PolicyComponent,
   and overridden to become an object reference to a PolicyValue new association that is
   defined within defines a relationship
   between a System and a PolicySet used in the administrative scope of a SimplePolicyCondition.  Note that for any
   single instance of the association class
   PolicyValueInSimplePolicyCondition, this
   system (e.g., AdminDomain, ComputerSystem).  The Priority property (like all reference
   properties) is single-valued.  The [1..1] cardinality indicates that
   used to assign a
   SimplePolicyCondition must have exactly one policy value defined relative priority to a PolicySet within
   its the
   administrative scope in order to be meaningful.

 6.14. The Aggregation "PolicyVariableInSimplePolicyAction"

   A simple policy action contexts where it is represented as not a pair {variable, value}. This
   aggregation provides component of another
   PolicySet.

     NAME             PolicySetInSystem
     DESCRIPTION      An abstract class representing the linkage relationship
                      between a SimplePolicyAction instance System and a single PolicyVariable.  The aggregation
   PolicyValueInSimplePolicyAction links the SimplePolicyAction to a single
   PolicyValue.

   The class definition for this aggregation PolicySet that is as follows:

     NAME             PolicyVariableInSimplePolicyAction used in the
                      administrative scope of the System.
     DERIVED FROM     PolicyComponent     PolicyInSystem
     ABSTRACT         False         TRUE
     PROPERTIES       GroupComponent[ref SimplePolicyAction[0..n]]
                      PartComponent[ref PolicyVariable[1..1] ]       Antecedent[ref System[0..1]]
                      Dependent [ref PolicySet[0..n]]
                      Priority

   The reference Priority property "GroupComponent" is inherited from
   PolicyComponent, and overridden to become an object reference used to a
   SimplePolicyAction that contains exactly one PolicyVariable.  Note that
   for any single instance specify the relative priority of the aggregation class
   PolicyVariableInSimplePolicyAction, this property is single-valued.  The
   [0..n] cardinality indicates that
   referenced PolicySet when there may be 0, 1, or are more
   SimplePolicyAction objects that contain any given policy variable object.

   The reference property "PartComponent" is inherited from PolicyComponent,
   and overridden to become an object reference than one PolicySet instances
   applied to a PolicyVariable managed resource that is
   defined within are not PolicySetComponents and,
   therefore, have no other relative priority defined.

     NAME             Priority
     DESCRIPTION      A non-negative integer for prioritizing the scope of a SimplePolicyAction.  Note referenced
                      PolicySet among other PolicySet instances that for any
   single instance are not
                      components of the association class
   PolicyVariableInSimplePolicyAction, this property (like all reference
   properties) is single-valued.  The [1..1] cardinality a common PolicySet.  A larger value
                      indicates that a
   SimplePolicyAction must have exactly one policy variable higher priority.
     SYNTAX           uint16
     DEFAULT VALUE    0

 6.5. Update PCIM's Weak Association "PolicyGroupInSystem"

   Regardless of whether it a component of another PolicySet, a PolicyGroup
   is itself defined within
   its the scope in order to be meaningful.

 6.15. The Aggregation "PolicyValueInSimplePolicyAction"

   A simple policy action is represented as of a pair {variable, value}. System.  This
   aggregation provides the linkage between a SimplePolicyAction instance
   and a single PolicyValue.  The aggregation
   PolicyVariableInSimplePolicyAction association links the SimplePolicyAction a
   PolicyGroup to the System in whose scope the PolicyGroup is defined. It
   is a
   single PolicyVariable. subclass of the abstract PolicySetInSystem association. The class
   definition for this aggregation the association is as follows:

     NAME             PolicyValueInSimplePolicyAction             PolicyGroupInSystem
     DESCRIPTION      A class representing the fact that a PolicyGroup is
                      defined within the scope of a System.
     DERIVED FROM     PolicyComponent     PolicySetInSystem
     ABSTRACT         False         FALSE
     PROPERTIES       GroupComponent[ref SimplePolicyAction[0..n]]
                      PartComponent[ref PolicyValue[1..1] ]       Antecedent[ref System[1..1]]
                      Dependent     [ref PolicyGroup[weak]]

   The reference property "GroupComponent" Reference "Antecedent" is inherited from
   PolicyComponent, PolicySetInSystem, and
   overridden to become restrict its cardinality to [1..1]. It serves as an object
   reference to a
   SimplePolicyAction that contains exactly one PolicyValue.  Note System that provides a scope for
   any single instance of the aggregation class
   PolicyValueInSimplePolicyAction, one or more PolicyGroups.
   Since this property is single-valued.  The
   [0..n] a weak association, the cardinality indicates that there may be 0, for this object
   reference is always 1, or more
   SimplePolicyAction objects that contain any given policy value object. is, a PolicyGroup is always defined within
   the scope of exactly one System.

   The reference property "PartComponent" Reference "Dependent" is inherited from PolicyComponent, PolicySetInSystem, and
   overridden to become an object reference to a PolicyValue that is PolicyGroup defined within
   the scope of a SimplePolicyAction. System. Note that for any single instance of the
   association class PolicyValueInSimplePolicyAction, PolicyGroupInSystem, this property (like all reference
   properties) is single-valued. The
   [1..1] [0..n] cardinality indicates that a SimplePolicyAction must
   given System may have exactly 0, 1, or more than one policy value PolicyGroups defined within
   its scope in order to be meaningful.

 6.16. The scope.

 6.6. Update PCIM's Weak Association "ReusablePolicy"

   The association ReusablePolicy makes "PolicyRuleInSystem"

   Regardless of whether it possible to include any subclass a component of the abstract class "Policy" in another PolicySet, a ReusablePolicyContainer.

     NAME             ReusablePolicy
     DESCRIPTION      A class representing PolicyRule
   is itself defined within the inclusion scope of a reusable
                      policy element System.  This association links a
   PolicyRule to the System in whose scope the PolicyRule is defined. It is
   a ReusablePolicyContainer.  Reusable
                      elements may be PolicyGroups, PolicyRules,
                      PolicyConditions, PolicyActions, PolicyVariables,
                      PolicyValues, or instances of any other subclasses subclass of the abstract PolicySetInSystem association. The class Policy.
     DERIVED FROM     PolicyInSystem
     ABSTRACT         FALSE
     PROPERTIES       Antecedent[ref ReusablePolicyContainer[0..1]]

 6.17. Deprecate PCIM's "PolicyConditionInPolicyRepository"
   definition for the association is as follows:

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

 6.18. Deprecate PCIM's "PolicyActionInPolicyRepository"

     NAME             PolicyActionInPolicyRepository
     DEPRECATED FOR   ReusablePolicy
     DESCRIPTION      A class representing PolicyRule is
                      defined within the inclusion scope of a reusable
                      PolicyAction in a PolicyRepository. System.
     DERIVED FROM     PolicyInSystem     PolicySetInSystem
     ABSTRACT         FALSE
     PROPERTIES       Antecedent[ref PolicyRepository[0..1]] System[1..1]]
                      Dependent[ref PolicyAction[0..n]]

 6.19. PolicyRule[weak]]

   The Association PolicyValueConstraintInVariable

   This association links a PolicyValue Reference "Antecedent" is inherited from PolicySetInSystem, and
   overridden to restrict its cardinality to [1..1]. It serves as an object
   reference to a PolicyVariable object,
   modeling specific value constraints.  Using System that provides a scope for one or more PolicyRules.
   Since this association, is a variable
   (instance) may be constrained to be bound-to/assigned only weak association, the cardinality for this object
   reference is always 1, that is, a set PolicyRule is always defined within the
   scope of
   allowed values.  For example, modeling an enumerated source port
   variable, exactly one creates an instance of the PolicySourcePortVariable class System.

   The Reference "Dependent" is inherited from PolicySetInSystem, and associates it with the set of values (integers) representing the
   allowed enumeration, using appropriate number of instances of the
   PolicyValueConstraintInVariable association.

   Note that a single variable instance may be constrained by any number of
   values and a single value may be used
   overridden to constrain any number of
   variables.  These relationships are manifested by the n-to-m cardinality
   of the association.

   The class definition for the association is as follows:

     NAME             PolicyValueConstraintInVariable
     DESCRIPTION      A class representing the association of a constraints become an object to a variable object.
     DERIVED FROM     Dependency
     ABSTRACT         FALSE
     PROPERTIES       Antecedent [ref PolicyVariable[0..n]]
                      Dependent [ref PolicyValue [0..n]]

   The reference property Antecedent is inherited from Dependency.  Its type
   and cardinality are overridden to provide a PolicyRule defined within
   the semantics scope of a variable
   optionally having value constraints.  The [0..n] cardinality indicates System. Note that for any number single instance of variables may be constrained by a given value.

   The reference the
   association class PolicyRuleInSystem, this property "Dependent" is inherited from Dependency, and
   overridden to become an object reference to a PolicyValue that (like all Reference
   properties) is used to
   constrain the values that a particular PolicyVariable can have. single-valued. The [0..n] cardinality indicates that a
   given policy variable System may have 0, 1 1, or more than one PolicyValues PolicyRules defined to model the constraints on the
   values that the policy variable can take.

 6.20. within
   its scope.

 6.7. The Abstract Aggregation "PolicyContainerInPolicyContainer"

   The aggregation PolicyContainerInPolicyContainer provides for nesting of
   one ReusablePolicyContainer inside another one. "CompoundedPolicyCondition"

     NAME             PolicyContainerInPolicyContainer             CompoundedPolicyCondition
     DESCRIPTION      A class representing the aggregation of
                      ReusablePolicyContainers
                      PolicyConditions by a higher-level
                      ReusablePolicyContainer. an aggregating instance.
     DERIVED FROM     SystemComponent     PolicyComponent
     ABSTRACT         FALSE         TRUE
     PROPERTIES       GroupComponent[ref ReusablePolicyContainer [0..n]]       PartComponent[ref ReusablePolicyContainer [0..n]]

 6.21. Deprecate PolicyCondition[0..n]]
                      GroupNumber
                      ConditionNegated

 6.8. Update PCIM's "PolicyRepositoryInPolicyRepository"

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

 6.22. The Aggregation "ElementInPolicyRoleCollection" "PolicyConditionInPolicyRule"

   The following PCIM aggregation "PolicyConditionInPolicyRule" is used updated, to associate ManagedElements with a
   PolicyRoleCollection object that represents make it
   a role played by these
   ManagedElements. subclass of the new abstract aggregation CompoundedPolicyCondition.
   The properties GroupNumber and ConditionNegated are now inherited, rather
   than specified explicitly as they were in PCIM.

     NAME             ElementInPolicyRoleCollection             PolicyConditionInPolicyRule
     DESCRIPTION      A class representing the inclusion aggregation of
                      PolicyConditions by a ManagedElement
                      in a collection, specified as having a given role.
                      All the managed elements in the collection share the
                      same role. PolicyRule.
     DERIVED FROM     MemberOfCollection     CompoundedPolicyCondition
     ABSTRACT         FALSE
     PROPERTIES       Collection[ref PolicyRoleCollection [0..n]]
                      Member[ref ManagedElement [0..n]]

 6.22.1.       GroupComponent[ref PolicyRule[0..n]]

 6.9. The Weak Association "PolicyRoleCollectionInSystem" Aggregation "PolicyConditionInPolicyCondition"

   A PolicyRoleCollection second subclass of CompoundedPolicyCondition is defined within defined, representing
   the scope compounding of policy conditions into a System.  This
   association links a PolicyRoleCollection to the System in whose scope it
   is defined.

   When associating a PolicyRoleCollection with a System, this should be
   done consistently with the system that scopes the higher-level policy rules/groups
   that are applied to the resources in that collection.
   condition.

     NAME             PolicyConditionInPolicyCondition
     DESCRIPTION      A
   PolicyRoleCollection is associated with the same system as the applicable
   PolicyRules and/or PolicyGroups, or to a System higher in class representing the tree formed aggregation of
                      PolicyConditions by the SystemComponent association. another PolicyCondition.
     DERIVED FROM     CompoundedPolicyCondition
     ABSTRACT         FALSE
     PROPERTIES       GroupComponent[ref CompoundPolicyCondition[0..n]]

 6.10. The class definition for the association is as follows: Abstract Aggregation "CompoundedPolicyAction"

     NAME             PolicyRoleCollectionInSystem             CompoundedPolicyAction
     DESCRIPTION      A class representing the fact that a
                      PolicyRoleCollection is defined within the scope aggregation of a
                      System. PolicyActions
                      by an aggregating instance.
     DERIVED FROM     Dependency     PolicyComponent
     ABSTRACT         FALSE         TRUE
     PROPERTIES       Antecedent[ref System[1..1]]
                      Dependent[ref PolicyRoleCollection[weak]]       PartComponent[ref PolicyAction[0..n]]
                      ActionOrder

 6.11. Update PCIM's Aggregation "PolicyActionInPolicyRule"

   The reference property Antecedent PCIM aggregation "PolicyActionInPolicyRule" is inherited from Dependency, and
   overridden to restrict its cardinality to [1..1].  It serves as an object
   reference updated, to make it a System that provides
   subclass of the new abstract aggregation CompoundedPolicyAction.  The
   property ActionOrder is now inherited, rather than specified explicitly
   as it was in PCIM.

     NAME             PolicyActionInPolicyRule
     DESCRIPTION      A class representing the aggregation of PolicyActions
                      by a scope for one or more
   PolicyRoleCollections.  Since this PolicyRule.
     DERIVED FROM     CompoundedPolicyAction
     ABSTRACT         FALSE
     PROPERTIES       GroupComponent[ref PolicyRule[0..n]]

 6.12. The Aggregation "PolicyActionInPolicyAction"

   A second subclass of CompoundedPolicyAction is defined, representing the
   compounding of policy actions into a weak association, higher-level policy action.

     NAME             PolicyActionInPolicyAction
     DESCRIPTION      A class representing the cardinality
   for this object reference aggregation of PolicyActions
                      by another PolicyAction.
     DERIVED FROM     CompoundedPolicyAction
     ABSTRACT         FALSE
     PROPERTIES       GroupComponent[ref CompoundPolicyAction[0..n]]

 6.13. The Aggregation "PolicyVariableInSimplePolicyCondition"

   A simple policy condition is always 1, that is, represented as an ordered triplet {variable,
   operator, value}.  This aggregation provides the linkage between a PolicyRoleCollection is
   always defined within
   SimplePolicyCondition instance and a single PolicyVariable.  The
   aggregation PolicyValueInSimplePolicyCondition links the scope
   SimplePolicyCondition to a single PolicyValue.  The Operator property of exactly one System.
   SimplePolicyCondition represents the third element of the triplet, the
   operator.

   The class definition for this aggregation is as follows:

     NAME             PolicyVariableInSimplePolicyCondition
     DERIVED FROM     PolicyComponent
     ABSTRACT         False
     PROPERTIES       GroupComponent[ref SimplePolicyCondition[0..n]]
                      PartComponent[ref PolicyVariable[1..1] ]

   The reference property Dependent "GroupComponent" is inherited from Dependency,
   PolicyComponent, and overridden to become an object reference to a PolicyRoleCollection
   defined within the scope of a System.
   SimplePolicyCondition that contains exactly one PolicyVariable.  Note
   that for any single instance of the association aggregation class PolicyRoleCollectionInSystem,
   PolicyVariableInSimplePolicyCondition, this property
   (like all Reference properties) is single-valued.
   The [0..n] cardinality indicates that a given System there may have be 0, 1, or more than one
   PolicyRoleCollections defined within its scope.

 7. Intellectual Property

   The IETF takes no position regarding the validity or scope of
   SimplePolicyCondition objects that contain any
   intellectual given policy variable
   object.

   The reference property or other rights that might be claimed "PartComponent" is inherited from PolicyComponent,
   and overridden to pertain become an object reference to a PolicyVariable that is
   defined within the implementation or use scope of a SimplePolicyCondition.  Note that for any
   single instance of the technology described in association class
   PolicyVariableInSimplePolicyCondition, this document or
   the extent to which any license under such rights might or might not be
   available; neither does it represent property (like all reference
   properties) is single-valued.  The [1..1] cardinality indicates that it has made any effort a
   SimplePolicyCondition must have exactly one policy variable defined
   within its scope in order to
   identify any such rights.  Information on be meaningful.

 6.14. The Aggregation "PolicyValueInSimplePolicyCondition"

   A simple policy condition is represented as an ordered triplet {variable,
   operator, value}.  This aggregation provides the IETF's procedures with
   respect to rights in standards-track linkage between a
   SimplePolicyCondition instance and standards-related documentation
   can be found in BCP-11.

   Copies a single PolicyValue.  The aggregation
   PolicyVariableInSimplePolicyCondition links the SimplePolicyCondition to
   a single PolicyVariable.  The Operator property of claims SimplePolicyCondition
   represents the third element of rights made available the triplet, the operator.

   The class definition for publication this aggregation is as follows:

     NAME             PolicyValueInSimplePolicyCondition
     DERIVED FROM     PolicyComponent
     ABSTRACT         False
     PROPERTIES       GroupComponent[ref SimplePolicyCondition[0..n]]
                      PartComponent[ref PolicyValue[1..1] ]

   The reference property "GroupComponent" is inherited from
   PolicyComponent, and any
   assurances of licenses overridden to be made available, or the result of become an attempt
   made object reference to obtain a general license or permission
   SimplePolicyCondition that contains exactly one PolicyValue.  Note that
   for the use any single instance of such
   proprietary rights by implementers or users of this specification can be
   obtained from the IETF Secretariat. aggregation class
   PolicyValueInSimplePolicyCondition, this property is single-valued.  The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary rights
   which may cover technology
   [0..n] cardinality indicates that there may be required 0, 1, or more
   SimplePolicyCondition objects that contain any given policy value object.

   The reference property "PartComponent" is inherited from PolicyComponent,
   and overridden to practice this
   standard.  Please address the information become an object reference to a PolicyValue that is
   defined within the IETF Executive Director.

 8. Acknowledgements

   The starting point scope of a SimplePolicyCondition.  Note that for this document was PCIM itself [3], and the first
   three submodels derived from it [5], [6], [7].  The authors any
   single instance of these
   documents created the extensions to PCIM, and asked the questions about
   PCIM, association class
   PolicyValueInSimplePolicyCondition, this property (like all reference
   properties) is single-valued.  The [1..1] cardinality indicates that are reflected a
   SimplePolicyCondition must have exactly one policy value defined within
   its scope in PCIMe.

 9. Security Considerations

   The Policy Core Information Model (PCIM) [3] describes the general
   security considerations related order to the general core be meaningful.

 6.15. The Aggregation "PolicyVariableInSimplePolicyAction"

   A simple policy model. action is represented as a pair {variable, value}. This
   aggregation provides the linkage between a SimplePolicyAction instance
   and a single PolicyVariable.  The
   extensions defined in this document do not introduce any additional
   considerations related aggregation
   PolicyValueInSimplePolicyAction links the SimplePolicyAction to security.

 10. References

 [1]  Bradner, S., "Key words a single
   PolicyValue.

   The class definition for use in RFCs to Indicate Requirement this aggregation is as follows:

     NAME             PolicyVariableInSimplePolicyAction
     DERIVED FROM     PolicyComponent
     ABSTRACT         False
     PROPERTIES       GroupComponent[ref SimplePolicyAction[0..n]]
                      PartComponent[ref PolicyVariable[1..1] ]

   The reference property "GroupComponent" is inherited from
   PolicyComponent, and overridden to become an object reference to a
   SimplePolicyAction that contains exactly one PolicyVariable.  Note that
   for any single instance of the aggregation class
   PolicyVariableInSimplePolicyAction, this property is single-valued.  The
   [0..n] cardinality indicates that there may be 0, 1, or more
   SimplePolicyAction objects that contain any given policy variable object.

   The reference property "PartComponent" is inherited from PolicyComponent,
   and overridden to become an object reference to a PolicyVariable that is
   defined within the scope of a SimplePolicyAction.  Note that for any
   single instance of the association class
   PolicyVariableInSimplePolicyAction, this property (like all reference
   properties) is single-valued.  The [1..1] cardinality indicates that a
   SimplePolicyAction must have exactly one policy variable defined within
   its scope in order to be meaningful.

 6.16. The Aggregation "PolicyValueInSimplePolicyAction"

   A simple policy action is represented as a pair {variable, value}.  This
   aggregation provides the linkage between a SimplePolicyAction instance
   and a single PolicyValue.  The aggregation
   PolicyVariableInSimplePolicyAction links the SimplePolicyAction to a
   single PolicyVariable.

   The class definition for this aggregation is as follows:

     NAME             PolicyValueInSimplePolicyAction
     DERIVED FROM     PolicyComponent
     ABSTRACT         False
     PROPERTIES       GroupComponent[ref SimplePolicyAction[0..n]]
                      PartComponent[ref PolicyValue[1..1] ]

   The reference property "GroupComponent" is inherited from
   PolicyComponent, and overridden to become an object reference to a
   SimplePolicyAction that contains exactly one PolicyValue.  Note that for
   any single instance of the aggregation class
   PolicyValueInSimplePolicyAction, this property is single-valued.  The
   [0..n] cardinality indicates that there may be 0, 1, or more
   SimplePolicyAction objects that contain any given policy value object.

   The reference property "PartComponent" is inherited from PolicyComponent,
   and overridden to become an object reference to a PolicyValue that is
   defined within the scope of a SimplePolicyAction.  Note that for any
   single instance of the association class PolicyValueInSimplePolicyAction,
   this property (like all reference properties) is single-valued.  The
   [1..1] cardinality indicates that a SimplePolicyAction must have exactly
   one policy value defined within its scope in order to be meaningful.

 6.17. The Association "ReusablePolicy"

   The association ReusablePolicy makes it possible to include any subclass
   of the abstract class "Policy" in a ReusablePolicyContainer.

     NAME             ReusablePolicy
     DESCRIPTION      A class representing the inclusion of a reusable
                      policy element in a ReusablePolicyContainer.  Reusable
                      elements may be PolicyGroups, PolicyRules,
                      PolicyConditions, PolicyActions, PolicyVariables,
                      PolicyValues, or instances of any other subclasses of
                      the abstract class Policy.

     DERIVED FROM     PolicyInSystem
     ABSTRACT         FALSE
     PROPERTIES       Antecedent[ref ReusablePolicyContainer[0..1]]

 6.18. Deprecate PCIM's "PolicyConditionInPolicyRepository"

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

 6.19. Deprecate PCIM's "PolicyActionInPolicyRepository"

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

 6.20. The Association PolicyValueConstraintInVariable

   This association links a PolicyValue object to a PolicyVariable object,
   modeling specific value constraints.  Using this association, a variable
   (instance) may be constrained to be bound-to/assigned only a set of
   allowed values.  For example, modeling an enumerated source port
   variable, one creates an instance of the PolicySourcePortVariable class
   and associates it with the set of values (integers) representing the
   allowed enumeration, using appropriate number of instances of the
   PolicyValueConstraintInVariable association.

   Note that a single variable instance may be constrained by any number of
   values and a single value may be used to constrain any number of
   variables.  These relationships are manifested by the n-to-m cardinality
   of the association.

   The class definition for the association is as follows:

     NAME             PolicyValueConstraintInVariable
     DESCRIPTION      A class representing the association of a constraints
                      object to a variable object.
     DERIVED FROM     Dependency
     ABSTRACT         FALSE
     PROPERTIES       Antecedent [ref PolicyVariable[0..n]]
                      Dependent [ref PolicyValue [0..n]]
   The reference property Antecedent is inherited from Dependency.  Its type
   and cardinality are overridden to provide the semantics of a variable
   optionally having value constraints.  The [0..n] cardinality indicates
   that any number of variables may be constrained by a given value.

   The reference property "Dependent" is inherited from Dependency, and
   overridden to become an object reference to a PolicyValue that is used to
   constrain the values that a particular PolicyVariable can have.  The
   [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
   values that the policy variable can take.

 6.21. The Aggregation "PolicyContainerInPolicyContainer"

   The aggregation PolicyContainerInPolicyContainer provides for nesting of
   one ReusablePolicyContainer inside another one.

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

 6.22. Deprecate PCIM's "PolicyRepositoryInPolicyRepository"

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

 6.23. The Aggregation "ElementInPolicyRoleCollection"

   The following aggregation is used to associate ManagedElements with a
   PolicyRoleCollection object that represents a role played by these
   ManagedElements.

     NAME             ElementInPolicyRoleCollection
     DESCRIPTION      A class representing the inclusion of a ManagedElement
                      in a collection, specified as having a given role.
                      All the managed elements in the collection share the
                      same role.
     DERIVED FROM     MemberOfCollection
     ABSTRACT         FALSE
     PROPERTIES       Collection[ref PolicyRoleCollection [0..n]]
                      Member[ref ManagedElement [0..n]]

 6.24. The Weak Association "PolicyRoleCollectionInSystem"

   A PolicyRoleCollection is defined within the scope of a System.  This
   association links a PolicyRoleCollection to the System in whose scope it
   is defined.

   When associating a PolicyRoleCollection with a System, this should be
   done consistently with the system that scopes the policy rules/groups
   that are applied to the resources in that collection.  A
   PolicyRoleCollection is associated with the same system as the applicable
   PolicyRules and/or PolicyGroups, or to a System higher in the tree formed
   by the SystemComponent association.

   The class definition for the association is as follows:

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

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

   The reference property Dependent is inherited from Dependency, and
   overridden to become an object reference to a PolicyRoleCollection
   defined within the scope of a System.  Note that for any single instance
   of the association class PolicyRoleCollectionInSystem, 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
   PolicyRoleCollections defined within its scope.

 7. Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to pertain to
   the implementation or use of the technology described in this document or
   the extent to which any license under such rights might or might not be
   available; neither does it represent that it has made any effort to
   identify any such rights.  Information on the IETF's procedures with
   respect to rights in standards-track and standards-related documentation
   can be found in BCP-11.

   Copies of claims of rights made available for publication and any
   assurances of licenses to be made available, or the result of an attempt
   made to obtain a general license or permission for the use of such
   proprietary rights by implementers or users of this specification can be
   obtained from the IETF Secretariat.

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

 8. Acknowledgements

   The starting point for this document was PCIM itself [3], and the first
   three submodels derived from it [5], [6], [7].  The authors of these
   documents created the extensions to PCIM, and asked the questions about
   PCIM, that are reflected in PCIMe.

 9. Security Considerations

   The Policy Core Information Model (PCIM) [3] describes the general
   security considerations related to the general core policy model.  The
   extensions defined in this document do not introduce any additional
   considerations related to security.

 10. References

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

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

 [3]  Strassner, J., and E. Ellesson, B. Moore, A. Westerinen, "Policy Core
      Information Model -- Version 1 Specification", RFC 3060, February
      2001.

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

 [5]  Snir, Y., and Y. Ramberg, J. Strassner, R. Cohen, "Policy Framework
      QoS Information Model", work in progress, draft-ietf-policy-qos-info-
      model-02.txt, November 2000.

 [6]  Jason, J., and L. Rafalow, E. Vyncke, "IPsec Configuration Policy
      Model", work in progress, draft-ietf-ipsp-config-policy-model-02.txt,
      March 2001.

 [7]  Chadha, R., and M. Brunner, M. Yoshida, J. Quittek, G. Mykoniatis, A.
      Poylisher, R. Vaidyanathan, A. Kind, F. Reichmeyer, "Policy Framework
      MPLS Information Model for QoS and TE", work in progress, draft-
      chadha-policy-mpls-te-01.txt, December 2000.

 [8]  Crocker, D., and P. Overell, "Augmented BNF for Syntax Specifications:
      ABNF", RFC 2234, November 1997.

 [9]  P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
      RFC1035, November 1987.

 [10] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture",
      RFC2373, July 1998.

 [11] M. Wahl, A. Coulbeck, "Lightweight Directory Access Protocol (v3):
      Attribute Syntax Definitions", RFC 2252.

 [12] A. Westerinen, et al., "Policy Terminology", <draft-ietf-policy-
      terminology-01.txt>, November 2000.

 [13] S. Waldbusser, and J. Saperia, T. Hongal, "Policy Based Management
      MIB", <draft-ietf-snmpconf-pm-04.txt>, November 2000.

 11. Authors' Addresses

   Bob Moore
       IBM Corporation, BRQA/502
       4205 S. Miami Blvd.
       Research Triangle Park, NC 27709
       Phone:   +1 919-254-4436
       Fax:     +1 919-254-6243
       E-mail:  remoore@us.ibm.com

   Lee Rafalow
       IBM Corporation, BRQA/502
       4205 S. Miami Blvd.
       Research Triangle Park, NC 27709
       Phone:   +1 919-254-4455
       Fax:     +1 919-254-6243
       E-mail:  rafalow@us.ibm.com

   Yoram Ramberg
       Cisco Systems
       4 Maskit Street
       Herzliya Pituach, Israel  46766
       Phone:  +972-9-970-0081
       Fax:    +972-9-970-0219
       E-mail:  yramberg@cisco.com

   Yoram Snir
       Cisco Systems
       4 Maskit Street
       Herzliya Pituach, Israel  46766
       Phone:  +972-9-970-0085
       Fax:    +972-9-970-0366
       E-mail:  ysnir@cisco.com

   John Strassner
       Cisco Systems
       Building 20
       725 Alder Drive
       Milpitas, CA  95035
       Phone:  +1-408-527-1069
       Fax:    +1-408-527-2477
       E-mail:  johns@cisco.com

   Andrea Westerinen
       Cisco Systems
       Building 20
       725 Alder Drive
       Milpitas, CA  95035
       Phone:  +1-408-853-8294
       Fax:    +1-408-527-6351
       E-mail:  andreaw@cisco.com

   Ritu Chadha
       Telcordia Technologies
       MCC 1J-218R
       445 South Street
       Morristown NJ 07960.
       Phone:  +1-973-829-4869
       Fax:    +1-973-829-5889
       E-mail: chadha@research.telcordia.com

   Marcus Brunner
       NEC Europe Ltd.
       C&C Research Laboratories
       Adenauerplatz 6
       D-69115 Heidelberg, Germany
       Phone: +49 (0)6221 9051129
       Fax:   +49 (0)6221 9051155
       E-mail: brunner@ccrle.nec.de

   Ron Cohen
       Ntear LLC
       Phone:
       Fax:
       E-mail:  ronc@ntear.com

 12. Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved. (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it or
   assist in its implementation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are included
   on all such copies and derivative works.  However, this document itself
   may not be modified in any way, such as by removing the copyright notice
   or references to the Internet Society or other Internet organizations,
   except as needed for the purpose of developing Internet standards in
   which case the procedures for copyrights defined in the Internet
   Standards process must be followed, or as required to translate it into
   languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and translations of it may be copied and furnished to
   others, the information contained herein is provided on an "AS
   IS" basis and derivative works that comment THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
   FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
   LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
   INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
   FITNESS FOR A PARTICULAR PURPOSE.

 13. Appendix A: Open Issues

   The PCIMe authors do not all agree with everything included in the -00
   draft of the document.  Input is solicited from the working group as a
   whole on or otherwise explain it or
   assist the following open issues:

     1.  Unrestricted use of DNF/CNF for CompoundPolicyConditions.
         Alternative: for the conditions aggregated by a
         CompoundPolicyCondition, allow only ANDing, with negation of
         individual conditions.  Note that this is sufficient to build
         multi-field packet filters from single-field
         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 its implementation may be prepared, copied, published a SimplePolicyCondition, restrict the set
         of possible values both via associated PolicyValue objects (tied
         in with the PolicyValueConstraintInVariable association) and
   distributed, via
         the ValueTypes property in the PolicyVariable class.  Alternative:
         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
         ExecutionStrategy property in whole or PolicyRule and in part, without restriction of any kind,
   provided
         CompoundPolicyAction.  Alternative: have only 'Do until success'
         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 above copyright notice preferred way to do
         packet filtering in a PolicyCondition.  Alternative:  make
         CompoundFilterConditions and this paragraph are included
   on all such copies FilterEntries available to submodels,
         with no stated (or implied) preference.

         RESOLUTION: Recommendations for use of CompoundFilterConditions
         and derivative works.  However, this document itself
   may not be modified in any way, such FilterEntries are retained, but they have been recast
         slightly.  CompoundFilterConditions are now positioned as by removing the copyright notice
   or references to
         recommended approach for domain-level models.  FilterEntries are
         the Internet Society or other Internet organizations,
   except as needed recommended approach for device-level models.

     5.  Prohibiting equal values for Priority within a PolicySet.
         Alternative: allow equal values, with resulting indeterminacy in
         PEP behavior.

         RESOLUTION: PCIMe will continue to prohibit equal Priority values.

     6.  Modeling a SimplePolicyAction with just a related PolicyVariable
         and PolicyValue -- the purpose of developing Internet standards "set" or "apply" operation is implicit.
         Alternative: include an Operation property in
   which case SimplePolicyAction,
         similar to the procedures for copyrights defined Operation property in SimplePolicyCondition.

         RESOLUTION: This issue has been resolved by a change in the Internet
   Standards process must
         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
         be followed, or represented only as required strings (as in LDAP), or natively (e.g., an
         IPv4 address would be a four-octet field) with mappings to translate it into
   languages other than English.
         representations such as strings?

         RESOLUTION: Mappings have been eliminated.  Each value type has a
         single representation specified for it.

     8.  The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document nesting of rules and the information contained herein is provided on an "AS
   IS" basis groups within rules introduces
         significant change and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
   FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
   LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
   INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
   FITNESS FOR A PARTICULAR PURPOSE.

 13. Appendix A: Open Issues

   The PCIMe authors do not all agree with everything included complexity in the -00
   draft of the document.  Input is solicited from model.  This nesting
         introduces program state (procedural language) into the working group as model
         (heretofore a
   whole declarative model) as well as implicit hierarchical
         contexts on which the following open issues:

     1.  Unrestricted use of DNF/CNF for CompoundPolicyConditions. rules operate.  These require a much more
         sophisticated rule-evaluation engine than in the past.

         Alternative:  for Maintain the conditions aggregated declarative model, by prohibiting
         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
         CompoundPolicyCondition, allow only ANDing, significant new limitation: actions
         associated with negation of
         individual conditions. 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 this is sufficient to build
         multi-field packet filters from single-field
         SimplePolicyConditions.

     2.  For a PolicyVariable in it has been a SimplePolicyCondition, restrict the set feature of possible values both via
         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 PolicyValue objects (tied
         in with the PolicyValueConstraintInVariable association) and via
         the ValueTypes property in the PolicyVariable class.  Alternative:
         restrict values only via associated PolicyValue objects.

     3.  Transactional semantics, including rollback, nesting that has
         been changed.  Rather than having separate aggregations
         (PolicyGroupInPolicyGroup, etc.) for each of the
         ExecutionStrategy property in PolicyRule and in
         CompoundPolicyAction.  Alternative: have only 'Do until success'
         and 'Do all'.

     4.  Stating that CompoundFilterConditions are four nesting
         varieties, the preferred way single aggregation PolicySetComponent is now used
         as a concrete aggregation class.

      9. Need to do
         packet filtering in specify a PolicyCondition.  Alternative:  make
         CompoundFilterConditions join algorithm for disjoint rule sets.

         RESOLUTION: PCIMe now states that for different functional domains
         (e.g., QoS and FilterEntries available to submodels,
         with IKE), there is no stated (or implied) preference.

     5.  Prohibiting equal values for Priority within a PolicySet.
         Alternative: allow equal values, with resulting indeterminacy join algorithm.  Each domain, in
         PEP behavior.

     6.  Modeling a SimplePolicyAction with just
         effect, has its own rule engine, which operates independently of
         the other domains' engine(s).  Within a related PolicyVariable
         and PolicyValue -- functional domain,
         disjoint PolicySets are joined by the "set" or "apply" operation is implicit.
         Alternative: include an Operation Priority property in SimplePolicyAction,
         similar the
         PolicySetInSystem association.  In this case the decision strategy
         is specified to be FirstMatching.

      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 Operation property IPv4 source address in SimplePolicyCondition.

     7.  Representation of PolicyValues: should values like the outermost packet header.  IPv4 and
         IPv6 addresses
         be represented only as strings (as will require separate subclasses of
         PolicyImplicitVariable.  We understand the downside of this
         approach: a potential explosion in LDAP), or natively (e.g., the number of subclasses of
         PolicyImplicitVariable.

         ALTERNATIVE: At this time the authors are still discussing an
         IPv4 address
         alternative approach, in which variable types would be a four-octet field) with mappings to other
         representations such as strings?

     8.  The nesting represented
         by enumerated values rather than by separate subclasses of rules and groups within rules introduces
         significant change and complexity
         PolicyImplicitVariable.  This approach can greatly reduce the
         number of classes in the model.  This nesting model, but it introduces program state (procedural language) into an IANA
         dependency for managing the model
         (heretofore a declarative model) as well as implicit hierarchical
         contexts on which enumerated values.

      11.  Clarify PolicyExplicitVariables.

         NON-RESOLUTION: This issue is still not resolved at all.  The
         authors continue to believe that we need the rules operate.  These require capability of
         indicating that a much more
         sophisticated rule-evaluation engine than condition should compare against (or an action
         should set) a particular property in a particular object instance.
         But we do not believe that the past.

         Alternative: Maintain current mechanism of specifying a
         target object class and property name is sufficient.  For the declarative model, by prohibiting
         program state in rule evaluation (i.e., no rules within rules).

      9. Need next
         version of PCIMe, we need to specify either find a join algorithm for disjoint rule sets.

      10.  Clarify PolicyImplicitVariables.

      11.  Clarify PolicyExplicitVariables. 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.