path: root/doc/rfc/rfc3460.txt

Network Working Group                                      B. Moore, Ed.
Request for Comments: 3460                                           IBM
Updates: 3060                                               January 2003
Category: Standards Track


            Policy Core Information Model (PCIM) Extensions

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This document specifies a number of changes to the Policy Core
   Information Model (PCIM, RFC 3060).  Two types of changes are
   included.  First, several completely new elements are introduced, for
   example, classes for header filtering, that extend PCIM into areas
   that it did not previously cover.  Second, there are cases where
   elements of PCIM (for example, policy rule priorities) are
   deprecated, and replacement elements are defined (in this case,
   priorities tied to associations that refer to policy rules).  Both
   types of changes are done in such a way that, to the extent possible,
   interoperability with implementations of the original PCIM model is
   preserved.  This document updates RFC 3060.

Table of Contents

   1. Introduction....................................................5
   2. Changes since RFC 3060..........................................5
   3. Overview of the Changes.........................................6
      3.1. How to Change an Information Model.........................6
      3.2. List of Changes to the Model...............................6
           3.2.1. Changes to PolicyRepository.........................6
           3.2.2. Additional Associations and Additional Reusable
                  Elements............................................7
           3.2.3. Priorities and Decision Strategies..................7
           3.2.4. Policy Roles........................................8
           3.2.5. CompoundPolicyConditions and
                  CompoundPolicyActions...............................8



Moore                       Standards Track                     [Page 1]
^L
RFC 3460                    PCIM Extensions                 January 2003


           3.2.6. Variables and Values................................9
           3.2.7. Domain-Level Packet Filtering.......................9
           3.2.8. Device-Level Packet Filtering.......................9
   4. The Updated Class and Association Class Hierarchies............10
   5. Areas of Extension to PCIM.....................................13
      5.1. Policy Scope..............................................13
           5.1.1. Levels of Abstraction: Domain- and Device-Level
                  Policies...........................................13
           5.1.2. Administrative and Functional Scopes...............14
      5.2. Reusable Policy Elements..................................15
      5.3. Policy Sets...............................................16
      5.4. Nested Policy Rules.......................................16
           5.4.1. Usage Rules for Nested Rules.......................17
           5.4.2. Motivation.........................................17
      5.5. Priorities and Decision Strategies........................18
           5.5.1. Structuring Decision Strategies....................19
           5.5.2. Side Effects.......................................21
           5.5.3. Multiple PolicySet Trees For a Resource............21
           5.5.4. Deterministic Decisions............................22
      5.6. Policy Roles..............................................23
           5.6.1. Comparison of Roles in PCIM with Roles in
                  snmpconf...........................................23
           5.6.2. Addition of PolicyRoleCollection to PCIMe..........24
           5.6.3. Roles for PolicyGroups.............................25
      5.7. Compound Policy Conditions and Compound Policy Actions....27
           5.7.1. Compound Policy Conditions.........................27
           5.7.2. Compound Policy Actions............................27
      5.8. Variables and Values......................................28
           5.8.1. Simple Policy Conditions...........................29
           5.8.2. Using Simple Policy Conditions.....................29
           5.8.3. The Simple Condition Operator......................31
           5.8.4. SimplePolicyActions................................33
           5.8.5. Policy Variables...................................35
           5.8.6. Explicitly Bound Policy Variables..................36
           5.8.7. Implicitly Bound Policy Variables..................37
           5.8.8. Structure and Usage of Pre-Defined Variables.......38
           5.8.9. Rationale for Modeling Implicit Variables
                  as Classes.........................................39
           5.8.10. Policy Values.....................................40
      5.9. Packet Filtering..........................................41
           5.9.1. Domain-Level Packet Filters........................41
           5.9.2. Device-Level Packet Filters........................42
      5.10. Conformance to PCIM and PCIMe............................43
   6. Class Definitions..............................................44
      6.1. The Abstract Class "PolicySet"............................44
      6.2. Update PCIM's Class "PolicyGroup".........................45
      6.3. Update PCIM's Class "PolicyRule"..........................45
      6.4. The Class "SimplePolicyCondition".........................46



Moore                       Standards Track                     [Page 2]
^L
RFC 3460                    PCIM Extensions                 January 2003


      6.5. The Class "CompoundPolicyCondition".......................47
      6.6. The Class "CompoundFilterCondition".......................47
      6.7. The Class "SimplePolicyAction"............................48
      6.8. The Class "CompoundPolicyAction"..........................48
      6.9. The Abstract Class "PolicyVariable".......................50
      6.10. The Class "PolicyExplicitVariable".......................50
           6.10.1. The Single-Valued Property "ModelClass"...........51
           6.10.2. The Single-Valued Property ModelProperty..........51
      6.11. The Abstract Class "PolicyImplicitVariable"..............51
           6.11.1. The Multi-Valued Property "ValueTypes"............52
      6.12. Subclasses of "PolicyImplicitVariable" Specified
            in PCIMe.................................................52
           6.12.1. The Class "PolicySourceIPv4Variable"..............52
           6.12.2. The Class "PolicySourceIPv6Variable"..............52
           6.12.3. The Class "PolicyDestinationIPv4Variable".........53
           6.12.4. The Class "PolicyDestinationIPv6Variable".........53
           6.12.5. The Class "PolicySourcePortVariable"..............54
           6.12.6. The Class "PolicyDestinationPortVariable".........54
           6.12.7. The Class "PolicyIPProtocolVariable"..............54
           6.12.8. The Class "PolicyIPVersionVariable"...............55
           6.12.9. The Class "PolicyIPToSVariable"...................55
           6.12.10. The Class "PolicyDSCPVariable"...................55
           6.12.11. The Class "PolicyFlowIdVariable".................56
           6.12.12. The Class "PolicySourceMACVariable"..............56
           6.12.13. The Class "PolicyDestinationMACVariable".........56
           6.12.14. The Class "PolicyVLANVariable"...................56
           6.12.15. The Class "PolicyCoSVariable"....................57
           6.12.16. The Class "PolicyEthertypeVariable"..............57
           6.12.17. The Class "PolicySourceSAPVariable"..............57
           6.12.18. The Class "PolicyDestinationSAPVariable".........58
           6.12.19. The Class "PolicySNAPOUIVariable"................58
           6.12.20. The Class "PolicySNAPTypeVariable"...............59
           6.12.21. The Class "PolicyFlowDirectionVariable"..........59
      6.13. The Abstract Class "PolicyValue".........................59
      6.14. Subclasses of "PolicyValue" Specified in PCIMe...........60
           6.14.1. The Class "PolicyIPv4AddrValue"...................60
           6.14.2. The Class "PolicyIPv6AddrValue....................61
           6.14.3. The Class "PolicyMACAddrValue"....................62
           6.14.4. The Class "PolicyStringValue".....................63
           6.14.5. The Class "PolicyBitStringValue"..................63
           6.14.6. The Class "PolicyIntegerValue"....................64
           6.14.7. The Class "PolicyBooleanValue"....................65
      6.15. The Class "PolicyRoleCollection".........................65
           6.15.1. The Single-Valued Property "PolicyRole"...........66
           6.16. The Class "ReusablePolicyContainer".................66
      6.17. Deprecate PCIM's Class "PolicyRepository"................66
      6.18. The Abstract Class "FilterEntryBase".....................67
      6.19. The Class "IpHeadersFilter"..............................67



Moore                       Standards Track                     [Page 3]
^L
RFC 3460                    PCIM Extensions                 January 2003


           6.19.1. The Property HdrIpVersion.........................68
           6.19.2. The Property HdrSrcAddress........................68
           6.19.3. The Property HdrSrcAddressEndOfRange..............68
           6.19.4. The Property HdrSrcMask...........................69
           6.19.5. The Property HdrDestAddress.......................69
           6.19.6. The Property HdrDestAddressEndOfRange.............69
           6.19.7. The Property HdrDestMask..........................70
           6.19.8. The Property HdrProtocolID........................70
           6.19.9. The Property HdrSrcPortStart......................70
           6.19.10. The Property HdrSrcPortEnd.......................70
           6.19.11. The Property HdrDestPortStart....................71
           6.19.12. The Property HdrDestPortEnd......................71
           6.19.13. The Property HdrDSCP.............................72
           6.19.14. The Property HdrFlowLabel.................... ...72
      6.20. The Class "8021Filter"...................................72
           6.20.1. The Property 8021HdrSrcMACAddr....................73
           6.20.2. The Property 8021HdrSrcMACMask....................73
           6.20.3. The Property 8021HdrDestMACAddr...................73
           6.20.4. The Property 8021HdrDestMACMask...................73
           6.20.5. The Property 8021HdrProtocolID....................74
           6.20.6. The Property 8021HdrPriorityValue.................74
           6.20.7. The Property 8021HdrVLANID........................74
      6.21. The Class FilterList.....................................74
           6.21.1. The Property Direction............................75
   7. Association and Aggregation Definitions........................75
      7.1. The Aggregation "PolicySetComponent"......................75
      7.2. Deprecate PCIM's Aggregation "PolicyGroupInPolicyGroup"...76
      7.3. Deprecate PCIM's Aggregation "PolicyRuleInPolicyGroup"....76
      7.4. The Abstract Association "PolicySetInSystem"..............77
      7.5. Update PCIM's Weak Association "PolicyGroupInSystem"......77
      7.6. Update PCIM's Weak Association "PolicyRuleInSystem".......78
      7.7. The Abstract Aggregation "PolicyConditionStructure".......79
      7.8. Update PCIM's Aggregation "PolicyConditionInPolicyRule"...79
      7.9. The Aggregation "PolicyConditionInPolicyCondition"........79
      7.10. The Abstract Aggregation "PolicyActionStructure".........80
      7.11. Update PCIM's Aggregation "PolicyActionInPolicyRule".....80
      7.12. The Aggregation "PolicyActionInPolicyAction".............80
      7.13. The Aggregation "PolicyVariableInSimplePolicyCondition"..80
      7.14. The Aggregation "PolicyValueInSimplePolicyCondition".....81
      7.15. The Aggregation "PolicyVariableInSimplePolicyAction".....82
      7.16. The Aggregation "PolicyValueInSimplePolicyAction"........83
      7.17. The Association "ReusablePolicy".........................83
      7.18. Deprecate PCIM's "PolicyConditionInPolicyRepository".....84
      7.19. Deprecate PCIM's "PolicyActionInPolicyRepository"........84
      7.20. The Association ExpectedPolicyValuesForVariable..........84
      7.21. The Aggregation "ContainedDomain"........................85
      7.22. Deprecate PCIM's "PolicyRepositoryInPolicyRepository"....86
      7.23. The Aggregation "EntriesInFilterList"....................86



Moore                       Standards Track                     [Page 4]
^L
RFC 3460                    PCIM Extensions                 January 2003


           7.23.1. The Reference GroupComponent......................86
           7.23.2. The Reference PartComponent.......................87
           7.23.3. The Property EntrySequence........................87
      7.24. The Aggregation "ElementInPolicyRoleCollection"..........87
      7.25. The Weak Association "PolicyRoleCollectionInSystem"......87
   8. Intellectual Property..........................................88
   9.  Acknowledgements..............................................89
   10. Contributors..................................................89
   11. Security Considerations.......................................91
   12. Normative References..........................................91
   13. Informative References........................................91
   Author's Address..................................................92
   Full Copyright Statement..........................................93

1. Introduction

   This document specifies a number of changes to the Policy Core
   Information Model (PCIM), RFC 3060 [1].  Two types of changes are
   included.  First, several completely new elements are introduced, for
   example, classes for header filtering, that extend PCIM into areas
   that it did not previously cover.  Second, there are cases where
   elements of PCIM (for example, policy rule priorities) are
   deprecated, and replacement elements are defined (in this case,
   priorities tied to associations that refer to policy rules).  Both
   types of changes are done in such a way that, to the extent possible,
   interoperability with implementations of the original PCIM model is
   preserved.

   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 BCP 14, RFC 2119 [8].

2. Changes since RFC 3060

   Section 3.2 contains a short discussion of the changes that this
   document makes to the RFC 3060 information model.  Here is a very
   brief list of the changes:

   1. Deprecate and replace PolicyRepository and its associations.
   2. Clarify and expand the ways that PolicyRules and PolicyGroups are
      aggregated.
   3. Change how prioritization for PolicyRules is represented, and
      introduce administrator-specified decision strategies for rule
      evaluation.
   4. Expand the role of PolicyRoles, and introduce a means of
      associating a PolicyRole with a resource.
   5. Introduce compound policy conditions and compound policy actions
      into the model.



Moore                       Standards Track                     [Page 5]
^L
RFC 3460                    PCIM Extensions                 January 2003


   6. Introduce variables and values into the model.
   7. Introduce variable and value subclasses for packet-header
      filtering.
   8. Introduce classes for device-level packet-header filtering.

3. Overview of the Changes

3.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.

3.2. List of Changes to the Model

   The following subsections provide a very brief overview of the
   changes to PCIM defined in PCIMe.  In several cases, the origin of
   the change is noted, as QPIM [11], ICPM [12], or QDDIM [15].

3.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



Moore                       Standards Track                     [Page 6]
^L
RFC 3460                    PCIM Extensions                 January 2003


   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.

3.2.2. Additional Associations and Additional Reusable Elements

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

3.2.3. Priorities and Decision Strategies

   Drawing from both QPIM and ICPM, the Priority property has been
   deprecated in PolicyRule, and placed instead on the aggregation
   PolicySetComponent.  The QPIM rules for resolving relative priorities
   across nested PolicyGroups and PolicyRules have been 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/PolicyGroup relative to other
   PolicyRules/PolicyGroups, the elements being prioritized must all
   reside in one of three places: in a common PolicyGroup, in a common
   PolicyRule, or in a common System.

   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 has been added to the PolicyGroup and
   PolicyRule classes.  This property allows 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.  (This is accomplished by placing
   the PolicyDecisionStrategy property in an abstract class PolicySet,







Moore                       Standards Track                     [Page 7]
^L
RFC 3460                    PCIM Extensions                 January 2003


   from which PolicyGroup and PolicyRule are derived.)  The QPIM rules
   for applying decision strategies to a nested set of PolicyGroups and
   PolicyRules have also been imported.

3.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 - PolicySet.  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 a nested rule or group.

   It was also observed that there is no mechanism in PCIM for assigning
   roles to resources.  For example, while it is possible in PCIM to
   associate a PolicyRule with the role "FrameRelay&&WAN", there is no
   way to indicate which interfaces match this criterion.  A new
   PolicyRoleCollection class has been 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 the PolicyRoles property of PolicyRules
   and PolicyGroups, and in the PolicyRole property in
   PolicyRoleCollection.

3.2.5. CompoundPolicyConditions and CompoundPolicyActions

   The concept of a CompoundPolicyCondition has also been 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.










Moore                       Standards Track                     [Page 8]
^L
RFC 3460                    PCIM Extensions                 January 2003


3.2.6. Variables and Values

   The SimplePolicyCondition / PolicyVariable / PolicyValue structure
   has been 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.  For example, QPIM defines a set of implicit variables
   corresponding to fields in RSVP flows.

   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".

3.2.7. Domain-Level Packet Filtering

   For packet filtering specified at the 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.

3.2.8. Device-Level Packet Filtering

   For packet filtering expressed at the device level, including the
   packet classifier filters modeled in QDDIM, the variables and values
   discussed in Section 3.2.7 need not be used.  Filter classes derived
   from the CIM FilterEntryBase class hierarchy are available for use in
   these contexts.  These latter classes have two important differences
   from the domain-level classes:

   o  They support specification of filters for all of the fields in a
      particular protocol header in a single object instance.  With the
      domain-level classes, separate instances are needed for each
      header field.

   o  They provide native representations for the filter values, as
      opposed to the string representation used by the domain-level
      classes.

   Device-level filter classes for the IP-related headers (IP, UDP, and
   TCP) and the 802 MAC headers are defined, respectively, in Sections
   6.19 and 6.20.




Moore                       Standards Track                     [Page 9]
^L
RFC 3460                    PCIM Extensions                 January 2003


4. 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 - 5.3)
      |  |   |
      |  |   +---PolicyGroup (moved - 5.3)
      |  |   |
      |  |   +---PolicyRule (moved - 5.3)
      |  |
      |  +---PolicyCondition (abstract)
      |  |   |
      |  |   +---PolicyTimePeriodCondition
      |  |   |
      |  |   +---VendorPolicyCondition
      |  |   |
      |  |   +---SimplePolicyCondition (new - 5.8.1)
      |  |   |
      |  |   +---CompoundPolicyCondition (new - 5.7.1)
      |  |       |
      |  |       +---CompoundFilterCondition (new - 5.9)
      |  |
      |  +---PolicyAction (abstract)
      |  |   |
      |  |   +---VendorPolicyAction
      |  |   |
      |  |   +---SimplePolicyAction (new - 5.8.4)
      |  |   |
      |  |   +---CompoundPolicyAction (new - 5.7.2)
      |  |
      |  +---PolicyVariable (abstract -- new - 5.8.5)
      |  |   |
      |  |   +---PolicyExplicitVariable (new - 5.8.6)
      |  |   |
      |  |   +---PolicyImplicitVariable (abstract -- new - 5.8.7)
      |  |       |
      |  |       +---(subtree of more specific classes -- new - 6.12)
      |  |
      |  +---PolicyValue (abstract -- new - 5.8.10)
      |      |
      |      +---(subtree of more specific classes -- new - 6.14)
      |
      +--Collection (abstract -- newly referenced)



Moore                       Standards Track                    [Page 10]
^L
RFC 3460                    PCIM Extensions                 January 2003


      |  |
      |  +--PolicyRoleCollection (new - 5.6.2)
   ManagedElement(abstract)
      |
      +--ManagedSystemElement (abstract)
         |
         +--LogicalElement (abstract)
            |
            +--System (abstract)
            |  |
            |  +--AdminDomain (abstract)
            |     |
            |     +---ReusablePolicyContainer (new - 5.2)
            |     |
            |     +---PolicyRepository (deprecated - 5.2)
            |
            +--FilterEntryBase (abstract -- new - 6.18)
            |  |
            |  +--IpHeadersFilter (new - 6.19)
            |  |
            |  +--8021Filter (new - 6.20)
            |
            +--FilterList (new - 6.21)

   Figure 1.    Class Inheritance Hierarchy for PCIMe


























Moore                       Standards Track                    [Page 11]
^L
RFC 3460                    PCIM Extensions                 January 2003


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

   [unrooted]
      |
      +---PolicyComponent (abstract)
      |   |
      |   +---PolicySetComponent (new - 5.3)
      |   |
      |   +---PolicyGroupInPolicyGroup (deprecated - 5.3)
      |   |
      |   +---PolicyRuleInPolicyGroup (deprecated - 5.3)
      |   |
      |   +---PolicyConditionStructure (abstract -- new - 5.7.1)
      |   |    |
      |   |    +---PolicyConditionInPolicyRule  (moved - 5.7.1)
      |   |    |
      |   |    +---PolicyConditionInPolicyCondition (new - 5.7.1)
      |   |
      |   +---PolicyRuleValidityPeriod
      |   |
      |   +---PolicyActionStructure (abstract -- new - 5.7.2)
      |   |    |
      |   |    +---PolicyActionInPolicyRule  (moved - 5.7.2)
      |   |    |
      |   |    +---PolicyActionInPolicyAction (new - 5.7.2)
      |   |
      |   +---PolicyVariableInSimplePolicyCondition (new - 5.8.2)
      |   |
      |   +---PolicyValueInSimplePolicyCondition (new - 5.8.2)
      |   |
      |   +---PolicyVariableInSimplePolicyAction (new - 5.8.4)
      |   |
      |   +---PolicyValueInSimplePolicyAction (new - 5.8.4)
   [unrooted]
      |
      +---Dependency (abstract)
      |   |
      |   +---PolicyInSystem (abstract)
      |   |   |
      |   |   +---PolicySetInSystem (abstract, new - 5.3)
      |   |   |   |
      |   |   |   +---PolicyGroupInSystem
      |   |   |   |
      |   |   |   +---PolicyRuleInSystem
      |   |   |
      |   |   +---ReusablePolicy (new - 5.2)
      |   |   |



Moore                       Standards Track                    [Page 12]
^L
RFC 3460                    PCIM Extensions                 January 2003


      |   |   +---PolicyConditionInPolicyRepository (deprecated - 5.2)
      |   |   |
      |   |   +---PolicyActionInPolicyRepository (deprecated - 5.2)
      |   |
      |   +---ExpectedPolicyValuesForVariable (new - 5.8)
      |   |
      |   +---PolicyRoleCollectionInSystem (new - 5.6.2)
      |
      +---Component (abstract)
      |   |
      |   +---SystemComponent
      |   |   |
      |   |   +---ContainedDomain (new - 5.2)
      |   |   |
      |   |   +---PolicyRepositoryInPolicyRepository (deprecated - 5.2)
      |   |
      |   +---EntriesInFilterList (new - 7.23)
      |
      +---MemberOfCollection (newly referenced)
          |
          +--- ElementInPolicyRoleCollection (new - 5.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).

5. Areas of Extension to PCIM

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

5.1. Policy Scope

   Policy scopes may be thought of in two dimensions: 1) the level of
   abstraction of the policy specification and 2) the applicability of
   policies to a set of managed resources.

5.1.1. Levels of Abstraction: Domain- and 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:



Moore                       Standards Track                    [Page 13]
^L
RFC 3460                    PCIM Extensions                 January 2003


   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, 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.

   PCIM and PCIMe 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.

5.1.2. Administrative and Functional Scopes

   Administrative scopes for policy are represented in PCIM and in these
   extensions to PCIM as System subclass instances.  Typically, a
   domain-level policy would be scoped by an AdminDomain instance (or by
   a hierarchy of AdminDomain instances) whereas a device-level policy
   might be scoped by a System instance that represents the PEP (e.g.,
   an instance of ComputerSystem, see CIM [2]).  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 submodels derived from PCIM and PCIMe, 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 represented by the structure of
   the submodels derived from PCIM and PCIMe, 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 into disjoint sets of policy rules.  Different
   functional domains may share 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



Moore                       Standards Track                    [Page 14]
^L
RFC 3460                    PCIM Extensions                 January 2003


   policy evaluation they are separate.  See section 5.5.3 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.

5.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 PDP
   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 6 and 7 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 ContainedDomain is defined.
   o  PCIM's PolicyRepositoryInPolicyRepository aggregation is
      deprecated.




Moore                       Standards Track                    [Page 15]
^L
RFC 3460                    PCIM Extensions                 January 2003


5.3. Policy Sets

   A "policy" can be thought of as a coherent set of rules to
   administer, manage, and control access to network resources ("Policy
   Terminology", reference [10]).  The structuring of these coherent
   sets of rules into subsets is enhanced in this document.  In Section
   5.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 structural flexibility and
   semantic capability of both subclasses.

   Two properties are defined in PolicySet: PolicyDecisionStrategy and
   PolicyRoles.  The PolicyDecisionStrategy property is included in
   PolicySet to define the evaluation relationship among the rules in
   the policy set.  See Section 5.5 for more information.  The
   PolicyRoles property is included in PolicySet to characterize the
   resources to which the PolicySet applies.  See Section 5.6 for more
   information.

   Along with the definition of the PolicySet class, a new 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, so
   these two aggregations are deprecated.

   A PolicySet's relationship to an AdminDomain or other administrative
   scoping system (for example, a ComputerSystem) is represented by the
   PolicySetInSystem abstract association.  This new association is
   derived from PolicyInSystem, and the PolicyGroupInSystem and
   PolicyRuleInSystem associations are now derived from
   PolicySetInSystem instead of directly from PolicyInSystem.  The
   PolicySetInSystem.Priority property is discussed in Section 5.5.3.

5.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.  The aggregation PolicySetComponent is used
   to represent the nesting of a policy rule in another policy rule.





Moore                       Standards Track                    [Page 16]
^L
RFC 3460                    PCIM Extensions                 January 2003


5.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 condition for evaluation
      of all nested rules; that is, the conditions of the parent are
      logically ANDed to the conditions of the sub-rules.  If the parent
      rule's condition clause evaluates to FALSE, sub-rules MAY be
      skipped since they also evaluate to FALSE.

   o  If the parent rule's condition evaluates to TRUE, the set of sub-
      rules SHALL BE evaluated according to the decision strategy and
      priorities as discussed in Section 5.5.

   o  If the parent rule's condition evaluates to TRUE, the parent
      rule's set of actions is executed BEFORE execution of the 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 parent-condition then parent rule's action
                   if condA then actA
                   if condB then ActB
                   if True then default action

      Such a default action functions as a default when FirstMatching
      decision strategies are in effect (see section 5.5).  If
      AllMatching applies, the "default" action is always performed.

   o  Policy rules have a context in which they are executed.  The rule
      engine evaluates and applies the policy rules in the context of
      the managed resource(s) that are identified by the policy roles
      (or by an explicit association).  Submodels MAY add additional
      context to policy rules based on rule structure; any such
      additional context is defined by the semantics of the action
      classes of the submodel.

5.4.2. Motivation

   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.



Moore                       Standards Track                    [Page 17]
^L
RFC 3460                    PCIM Extensions                 January 2003


   These enhancements ease the policy management tools' task, allowing
   policy rules to be expressed in a way closer to how humans think.

   Although rule nesting can be used to suggest optimizations in the way
   policy rules are evaluated, as discussed in section 5.5.2 "Side
   Effects," nesting does not specify nor does it require any particular
   order of evaluation of conditions.  Optimization of rule evaluation
   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 may be able to
   influence the evaluation of the policy rules for execution using rule
   nesting.

   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.

5.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 only
   actions enforced on a given examination of the 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 whose conditions evaluate to TRUE, the actions are enforced.
   Implementations MUST support the FirstMatching decision strategy;
   implementations MAY support the AllMatching decision strategy.

   As previously discussed, the PolicySet subclasses are PolicyGroup 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 aggregation.

   The relative priority within a PolicySet is established by the
   Priority property of the PolicySetComponent aggregation of the
   contained PolicyGroup and 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



Moore                       Standards Track                    [Page 18]
^L
RFC 3460                    PCIM Extensions                 January 2003


   two advantages.  First, it generalizes the concept of priority, so
   that it can be used for both groups and rules.  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 same aggregating PolicySet.  Thus, the
   evaluation of rules within a set is deterministically specified.

   For a FirstMatching decision strategy, the first rule (that is, 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, all of the matching rules are
   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 executed first.
   Since the actions of higher priority rules are executed first, lower
   priority rules that also match may get the "last 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 executed later and, therefore, will
   "win," in this example, setting the DSCP to 4.  Thus, conflicts
   between rules are resolved by this execution order.

   An implementation of the rule engine need not provide the action
   sequencing but the actions MUST be sequenced by the PEP or PDP on its
   behalf.  So, for example, the rule engine may provide an ordered list
   of actions to be executed by the PEP and any required serialization
   is then provided by the service configured by the rule engine.  See
   Section 5.5.2 for a discussion of side effects.

5.5.1. Structuring Decision Strategies

   As discussed in Sections 5.3 and 5.4, PolicySet instances may be
   nested arbitrarily.  For a FirstMatching decision strategy on a
   PolicySet, any contained PolicySet that matches satisfies the
   termination criteria for the FirstMatching strategy.  A PolicySet is
   considered to match if it is a PolicyRule and its conditions evaluate
   to True, or if the PolicySet is a PolicyGroup and at least one of its



Moore                       Standards Track                    [Page 19]
^L
RFC 3460                    PCIM Extensions                 January 2003


   contained PolicyGroups or PolicyRules match.  The priority associated
   with contained PolicySets, then, determines when to terminate rule
   evaluation in the structured set of rules.

   In the example shown in Figure 3, the relative priorities for the
   nested 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, 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





Moore                       Standards Track                    [Page 20]
^L
RFC 3460                    PCIM Extensions                 January 2003


      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.

5.5.2. Side Effects

   Although evaluation of conditions is sometimes discussed as an
   ordered set of operations, the rule engine need not be implemented as
   a procedural language interpreter.  Any side effects of condition
   evaluation or the execution of actions MUST NOT affect the result of
   the evaluation of other conditions evaluated by the rule engine in
   the same evaluation pass.  That is, an implementation of a rule
   engine MAY evaluate all conditions in any order before applying the
   priority and determining which actions are to be executed.

   So, regardless of how a 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 for the nesting of rules within
   rules (either directly or indirectly) where the actions of more than
   one rule may be enforced, any side effects of the enforcement of
   actions MUST NOT be included in condition evaluation on the same
   evaluation pass.

5.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
   aggregation instances between them.  Each PolicySet tree has a
   defined set of decision strategies and evaluation priorities.  In
   section 5.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 regardless of how they are
   collected.  These top-level PolicySet instances are called "unrooted"
   relative to the given resource.

   So, a PolicySet instance is defined to be rooted or unrooted in the
   context of a particular managed element; the relationship to the
   managed element is usually established by the policy roles of the
   PolicySet instance and of the managed element (see 5.6 "Policy
   Roles").  A PolicySet instance is unrooted in that context if and
   only if there is no PolicySetComponent association to a parent
   PolicySet that is also related to the same managed element.  These



Moore                       Standards Track                    [Page 21]
^L
RFC 3460                    PCIM Extensions                 January 2003


   PolicySetComponent aggregations are traversed up the tree without
   regard to how a PolicySet instance came to be related with the
   ManagedElement.  Figure 4. shows an example where instance A has role
   A, instance B has role B and so on.  In this example, in the context
   of interface X, instances B, and C are unrooted and instances D, E,
   and F are all rooted.  In the context of interface Y, instance A is
   unrooted and instances B, C, D, E and F are all rooted.

         +---+            +-----------+   +-----------+
         | A |            |   I/F X   |   |   I/F Y   |
         +---+            | has roles |   | has roles |
          / \             |   B & C   |   |   A & B   |
         /   \            +-----------+   +-----------+
      +---+ +---+
      | B | | C |
      +---+ +---+
       / \     \
      /   \     \
   +---+ +---+ +---+
   | D | | E | | F |
   +---+ +---+ +---+

   Figure 4.    Unrooted PolicySet Instances

   For those cases where there are multiple unrooted PolicySet instances
   that apply to the same managed resource (i.e., not in a common
   PolicySetComponent tree), the decision strategy among these disjoint
   PolicySet instances is the FirstMatching strategy.  The priority used
   with this FirstMatching strategy is defined in the PolicySetInSystem
   association.  The PolicySetInSystem subclass instances are present
   for all PolicySet instances (it is a required association) but the
   priority is only used as a default for unrooted PolicySet instances
   in a given ManagedElement context.

   The FirstMatching strategy is used among all unrooted PolicySet
   instances that apply to a given resource for a given functional
   domain.  So, for example, the PolicySet instances that are used for
   QoS policy and the instances that are used for IKE policy, although
   they are disjoint, are not joined in a FirstMatching decision
   strategy.  Instead, they are evaluated independently of one another.

5.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.



Moore                       Standards Track                    [Page 22]
^L
RFC 3460                    PCIM Extensions                 January 2003


   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.

5.6. Policy Roles

   A policy role is defined in [10] 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 document, 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.

5.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 [14], 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 [14] 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 [14], however, no special processing is required for





Moore                       Standards Track                    [Page 23]
^L
RFC 3460                    PCIM Extensions                 January 2003


   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 [14] this is done via the
   use of the Role tables (pmRoleESTable and pmRoleSETable).  The Role
   tables associate Role values with elements.

5.6.2. Addition of PolicyRoleCollection to PCIMe

   In order to remedy the latter shortcoming in PCIM (the lack of a way
   of associating a role with an object instance), PCIMe has a new class
   PolicyRoleCollection derived from the CIM Collection class.
   Resources that share a common role are aggregated by a
   PolicyRoleCollection instance, via the ElementInPolicyRoleCollection
   aggregation.  The role is specified in the PolicyRole property of the
   aggregating PolicyRoleCollection instance.

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

   The association between a PolicyRoleCollection and a system should be
   consistent with the associations that scope the policy rules/groups
   that are applied to the resources in that collection.  Specifically,
   a PolicyRoleCollection should be 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



Moore                       Standards Track                    [Page 24]
^L
RFC 3460                    PCIM Extensions                 January 2003


   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).

5.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.

   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.


















Moore                       Standards Track                    [Page 25]
^L
RFC 3460                    PCIM Extensions                 January 2003


   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 5.    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.




Moore                       Standards Track                    [Page 26]
^L
RFC 3460                    PCIM Extensions                 January 2003


5.7. Compound Policy Conditions and Compound Policy Actions

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

5.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 6.4), 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
      PolicyConditionStructure, 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 6.

5.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



Moore                       Standards Track                    [Page 27]
^L
RFC 3460                    PCIM Extensions                 January 2003


   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 PolicyActionStructure, from which the
      existing aggregation PolicyActionInPolicyRule and a new
      aggregation PolicyActionInPolicyAction are derived.

   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 6.

5.8. Variables and Values

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





Moore                       Standards Track                    [Page 28]
^L
RFC 3460                    PCIM Extensions                 January 2003


5.8.1. Simple Policy Conditions

   The SimplePolicyCondition class models elementary Boolean expressions
   of the form: "(<variable> MATCH <value>)".  The relationship 'MATCH',
   which is implicit in the model, is interpreted based on the variable
   and the value.  Section 5.8.3 explains the semantics of the 'MATCH'
   operator.  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 5.7.1).

   For example, the expression "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 5.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>,
   <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 model,
   this object could represent the flow that is being conditioned.  A
   set of predefined variables that cover network attributes commonly
   used for filtering is introduced 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 bound variable is matched against a value to produce the Boolean
   result.  For example, in the condition "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.

5.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



Moore                       Standards Track                    [Page 29]
^L
RFC 3460                    PCIM Extensions                 January 2003


   friendliest, from a user point-of-view) way to do this 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 6. depicts a SimplePolicyCondition with its associated
   variable and value.  Also shown are two PolicyValue instances that
   identify the values that the variable can assume.

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

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

   Figure 6.    SimplePolicyCondition

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



Moore                       Standards Track                    [Page 30]
^L
RFC 3460                    PCIM Extensions                 January 2003


5.8.3. The Simple Condition Operator

   A simple condition models an elementary Boolean expression of the
   form "variable MATCHes value".  However, the formal notation of the
   SimplePolicyCondition, together with its associations, models only a
   pair, (<variable>, <value>).  The 'MATCH' operator is not directly
   modeled -- it is implied.  Furthermore, this implied 'MATCH' operator
   carries overloaded semantics.

   For example, in the simple condition "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  "DestinationPort MATCH {'80', '8080'}"  -- operator is 'IS SET
      MEMBER'

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

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

   The examples above illustrate the implicit, context-dependent nature
   of the 'MATCH' operator.  The interpretation depends on the actual
   variable and value instances in the simple condition.  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 is used
   for interpreting the semantics of the 'MATCH' relationship.  In the
   following list, we define generic (type-independent) matching.

   PolicyValues may be multi-fielded, where each field may contain a
   range of values.  The same equally holds for PolicyVariables.
   Basically, we have to deal with single values (singleton), ranges
   ([lower bound ..  upper bound]), and sets (a,b,c).  So independent of
   the variable and value type, the following set of generic matching
   rules for the 'MATCH' operator are defined.

   o  singleton matches singleton -> the matching rule is defined in the
      type

   o  singleton matches range [lower bound .. upper bound] -> the
      matching evaluates to true, if the singleton matches the lower
      bound or the upper bound or a value in between






Moore                       Standards Track                    [Page 31]
^L
RFC 3460                    PCIM Extensions                 January 2003


   o  singleton matches set -> the matching evaluates to true, if the
      value of the singleton matches one of the components in the set,
      where a component may be a singleton or range again

   o  ranges [A..B] matches singleton -> is true if A matches B matches
      singleton

   o  range [A..B] matches range [X..Y] -> the matching evaluates to
      true, if all values of the range [A..B] are also in the range
      [X..Y].  For instance, [3..5] match [1..6] evaluates to true,
      whereas [3..5] match [4..6] evaluates to false.

   o  range [A..B] matches set (a,b,c, ...) -> the matching evaluates to
      true, if all values in the range [A..B] are part of the set.  For
      instance, range [2..3] match set ([1..2],3) evaluates to true, as
      well as range [2..3] match set (2,3), and range [2..3] match set
      ([1..2],[3..5]).

   o  set (a,b,c, ...) match singleton -> is true if a match b match c
      match ... match singleton

   o  set match range -> the matching evaluates to true, if all values
      in the set are part of the range.  For example, set (2,3) match
      range [1..4] evaluates to true.

   o  set (a,b,c,...) match set (x,y,z,...) -> the matching evaluates to
      true, if all values in the set (a,b,c,...) are part of the set
      (x,y,z,...).  For example, set (1,2,3) match set (1,2,3,4)
      evaluates to true.  Set (1,2,3) match set (1,2) evaluates to
      false.

   Variables may contain various types (Section 6.11.1).  When not
   stated otherwise, the type of the value bound to the variable at
   condition evaluation time and the value type of the PolicyValue
   instance need to be of the same type.  If they differ, then the
   condition evaluates to FALSE.

   The ExpectedPolicyValuesForVariable association specifies an expected
   set of values that can be matched with a variable within a simple
   condition.  Using this association, a source or destination port can
   be limited to the range 0-200, a source or destination IP address can
   be limited to a specified list of IPv4 address values, etc.









Moore                       Standards Track                    [Page 32]
^L
RFC 3460                    PCIM Extensions                 January 2003


                          +-----------------------+
                          | SimplePolicyCondition |
                          +-----------------------+
                              *               @
                              *               @
                              *               @
   +-----------------------------------+   +--------------------------+
   | Name=SmallSourcePorts             |   | Name=Port300             |
   | Class=PolicySourcePortVariable    |   | Class=PolicyIntegerValue |
   | ValueTypes=[PolicyIntegerValue]   |   | IntegerList = [300]      |
   +-----------------------------------+   +--------------------------+
                #
                #
                #
   +-------------------------+
   |Name=SmallPortsValues    |
   |Class=PolicyIntegerValue |
   |IntegerList=[1..200]     |
   +-------------------------+

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

   Figure 7.    An Invalid SimplePolicyCondition

   The ability to express these limitations appears in the model to
   support validation of a SimplePolicyCondition prior to its deployment
   to an enforcement point.  A Policy Management Tool, for example
   SHOULD NOT accept the SimplePolicyCondition shown in Figure 7.  If,
   however, a policy rule containing this condition does appear at an
   enforcement point, the expected values play no role in the
   determination of whether the condition evaluates to True or False.
   Thus in this example, the SimplePolicyCondition evaluates to True if
   the source port for the packet under consideration is 300, and it
   evaluates to False otherwise.

5.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.  In the case where the variable to be updated
   is multi- valued, the only update operation defined is a complete
   replacement of all previous values with a new set.  In other words,
   there are no Add or Remove [to/from the set of values] operations
   defined for SimplePolicyActions.




Moore                       Standards Track                    [Page 33]
^L
RFC 3460                    PCIM Extensions                 January 2003


   For example, the action  "set DSCP to EF" can be modeled by a simple
   action.  In this example, 'DSCP' is an implicit variable referring to
   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.

   The SimplePolicyAction class refines the basic structure of the
   PolicyAction class defined in PCIM, by specifying the contents of the
   action using the (<variable>, <value>) pair to form the action.  The
   variable specifies the attribute of an object. The value of  this
   attribute is set to the value specified in <value>.  Selection of the
   object is a function of the type of variable involved.  See Sections
   5.8.6 and 5.8.7, respectively, for details on object selection for
   explicitly bound and implicitly bound policy variables.

   SimplePolicyActions can be used in policy rules directly, or as
   building blocks for creating CompoundPolicyActions.

   The set operation is only valid if the list of types of the variable
   (ValueTypes property of PolicyImplicitVariable) includes the
   specified type of the value.  Conversion of values from one
   representation into another is not defined.  For example, a variable
   of IPv4Address type may not be set to a string containing a DNS name.
   Conversions are part of an implementation-specific mapping of the
   model.

   As was the case with SimplePolicyConditions, the role of expected
   values for the variables that appear in SimplePolicyActions is for
   validation, prior to the time when an action is executed.  Expected
   values play no role in action execution.

   Composing a simple action requires that an instance of the class
   SimplePolicyAction 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 PolicyVariableInSimplePolicyAction relates
   a SimplePolicyAction to a single variable instance.  Similarly, the
   aggregation PolicyValueInSimplePolicyAction relates a
   SimplePolicyAction to a single value instance.  Both aggregations are
   defined in this document.

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





Moore                       Standards Track                    [Page 34]
^L
RFC 3460                    PCIM Extensions                 January 2003


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

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

   Figure 8.    SimplePolicyAction

5.8.5. Policy Variables

   A variable generically represents information that changes (or
   "varies"), and that is set or evaluated by software.  In policy,
   conditions and actions can abstract information as "policy variables"
   to be evaluated in logical expressions, or set by actions.

   PCIMe defines two types of PolicyVariables, PolicyImplicitVariables
   and PolicyExplicitVariables.  The semantic difference between these
   classes is based on modeling context.  Explicit variables are bound
   to exact model constructs, while implicit variables are defined and
   evaluated outside of a model.  For example, one can imagine a
   PolicyCondition testing whether a CIM ManagedSystemElement's Status
   property has the value "Error."  The Status property is an explicitly
   defined PolicyVariable (i.e., it is defined in the context of the CIM
   Schema, and evaluated in the 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 implicit PolicyVariable is
   defined, to allow evaluation or modification of a packet's source
   address.





Moore                       Standards Track                    [Page 35]
^L
RFC 3460                    PCIM Extensions                 January 2003


5.8.6. Explicitly Bound Policy Variables

   Explicitly bound policy variables indicate the class and property
   names of the model construct to be evaluated or set.  The CIM Schema
   defines and constrains "appropriate" values for the variable (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 instance.  If PolicyExplicitVariables were tied to
   instances (either via associations or by an object identification
   property in the class itself), then we would be forcing element-
   specific rules.  On the other hand, if we only specify the object's
   model context (class 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>, <value>) pair) that defines CIM LogicalDevice
   DeviceID="12345".  Alternately, if a PolicyRule's PolicyRoles is
   "edge device" and the condition ((<variable>, <value>) pair) is
   Status="Error", then a general rule results for all edge devices in
   error.

   Currently, the only binding for a PolicyExplicitVariable defined in
   PCIMe is to the instances selected by policy roles.  For each such
   instance, a SimplePolicyCondition that aggregates the
   PolicyExplicitVariable evaluates to True if and only if ALL of the
   following are true:

   o  The instance selected is of the class identified by the variable's
      ModelClass property, or of a subclass of this class.
   o  The instance selected has the property identified by the
      variable's ModelProperty property.
   o  The value of this property in the instance matches the value
      specified in the PolicyValue aggregated by the condition.

   In all other cases, the SimplePolicyCondition evaluates to False.

   For the case where a SimplePolicyAction aggregates a
   PolicyExplicitVariable, the indicated property in the selected
   instance is set to the value represented by the PolicyValue that the
   SimplePolicyAction also aggregates.  However, if the selected
   instance is not of the class identified by the variable's ModelClass
   property, or of a subclass of this class, then the action is not
   performed.  In this case the SimplePolicyAction is not treated either
   as a successfully executed action (for the execution strategy Do



Moore                       Standards Track                    [Page 36]
^L
RFC 3460                    PCIM Extensions                 January 2003


   Until Success) or as a failed action (for the execution strategy Do
   Until Failure).  Instead, the remaining actions for the policy rule,
   if any, are executed as if this SimplePolicyAction were not present
   at all in the list of actions aggregated by the rule.

   Explicit variables would be more powerful if they could reach beyond
   the instances selected by policy roles, to related instances.
   However, to represent a policy rule involving such variables in any
   kind of general way requires something that starts to resemble very
   much a complete policy language.  Clearly such a language is outside
   the scope of PCIMe, although it might be the subject of a future
   document.

   By restricting much of the generality, it would be possible for
   explicit variables in PCIMe to reach slightly beyond a selected
   instance.  For example, if a selected instance were related to
   exactly one instance of another class via a particular association
   class, and if the goal of the policy rule were both to test a
   property of this related instance and to set a property of that same
   instance, then it would be possible to represent the condition and
   action of the rule using PolicyExplicitVariables.  Rather than
   handling this one specific case with explicit variables, though, it
   was decided to lump them with the more general case, and deal with
   them if and when a policy language is defined.

   Refer to Section 6.10 for the formal definition of the class
   PolicyExplicitVariable.

5.8.7. Implicitly Bound Policy Variables

   Implicitly bound policy variables define the data type and semantics
   of a variable.  This determines how the variable is bound to a value
   in a condition or an action.  Further instructions are provided for
   specifying data type and/or value constraints for implicitly bound
   variables.

   PCIMe introduces an abstract class, PolicyImplicitVariable, to model
   implicitly bound variables.  This class is derived from the abstract
   class 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 rationale for using this mechanism
   for modeling is explained below in Section 5.8.9.

   A domain-specific policy information model that extends PCIMe may
   define additional implicitly bound variables either by deriving them
   directly from the class PolicyImplicitVariable, or by further




Moore                       Standards Track                    [Page 37]
^L
RFC 3460                    PCIM Extensions                 January 2003


   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.

5.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 the source port of a TCP/UDP flow SHOULD have 'SourcePort' in
   its name.

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

   1. The ExpectedPolicyValuesForVariable association defines the set of
      value classes that could be matched to this variable.

   2. The list of constraints on the values that the PolicyVariable can
      hold (i.e., values that the variable must match) are defined by
      the appropriate properties of an associated PolicyValue class.

   In the example presented above, a PolicyImplicitVariable represents
   the SourcePort of incoming traffic.  The ValueTypes property of an
   instance of this class will hold the class name PolicyIntegerValue.
   This by itself constrains the data type of the SourcePort instance to
   be an integer.  However, we can further constrain the particular
   values that the SourcePort variable can hold by entering valid ranges
   in the IntegerList property of the PolicyIntegerValue instance (0 -
   65535 in this document).

   The combination of the VariableName and the
   ExpectedPolicyValuesForVariable association provide a consistent and
   extensible set of metadata that define the semantics of variables
   that are used to form policy conditions.  Since the
   ExpectedPolicyValuesForVariable association points to a PolicyValue
   instance, any of the values expressible in the PolicyValue class can
   be used to constrain values that the PolicyImplicitVariable can hold.
   For example:

   o  The ValueTypes property can be used to ensure that only proper
      classes are used in the expression.  For example, the SourcePort
      variable will not be allowed to ever be of type
      PolicyIPv4AddrValue, since source ports have different semantics
      than IP addresses and may not be matched.  However, integer value
      types are allowed as the property ValueTypes holds the string
      "PolicyIntegerValue", which is the class name for integer values.



Moore                       Standards Track                    [Page 38]
^L
RFC 3460                    PCIM Extensions                 January 2003


   o  The ExpectedPolicyValuesForVariable 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).

5.8.9. Rationale for Modeling Implicit Variables as Classes

   An implicitly bound variable can be modeled in one of several ways,
   including a single class with an enumerator for each individual
   implicitly bound variable and an abstract class extended for each
   individual variable.  The reasons for using a class inheritance
   mechanism for specifying individual implicitly bound variables are
   these:

   1. It is easy to extend.  A domain-specific information model can
      easily extend the PolicyImplicitVariable class or its subclasses
      to define domain-specific and context-specific variables.  For
      example, a domain-specific QoS policy information model may
      introduce an implicitly bound variable class to model applications
      by deriving a qosApplicationVariable class from the
      PolicyImplicitVariable abstract class.

   2. Introduction of a single structural class for implicitly bound
      variables would have to include an enumerator property that
      contains all possible individual implicitly bound variables.  This
      means that a domain-specific information model wishing to
      introduce an implicitly bound variable must extend the enumerator
      itself.  This results in multiple definitions of the same class,
      differing in the values available in the enumerator class.  One
      definition, in this document, would include the common implicitly
      bound variables' names, while 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 the application developer that multiple class
      definitions existed.  It would be harder still for the application
      developer to actually find 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.  This would make the process cumbersome.

   4. A possible argument against the 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 class.  While, by itself, this is not a strike against
      the approach, it may be argued that data models derived from this
      information model may be more difficult to optimize for
      applications.  This argument is rejected on the grounds that



Moore                       Standards Track                    [Page 39]
^L
RFC 3460                    PCIM Extensions                 January 2003


      application optimization is of lesser value for an information
      model than clarity and ease of extension.  In addition, it is hard
      to claim that the inheritance model places an absolute burden on
      the optimization.  For example, a data model may still use
      enumeration to denote instances of pre-defined variables and claim
      PCIMe compliance, as long as the data model can be mapped
      correctly to the definitions specified in this document.

5.8.10. Policy Values

   The abstract class PolicyValue is used for modeling values and
   constants used in policy conditions.  Different value types are
   derived from this class, to represent the various attributes
   required.  Extensions of the abstract class PolicyValue, defined in
   this document, provide a list of values for basic network attributes.
   Values can be used to represent constants as named values.  Named
   values can be kept in a reusable policy container to be reused by
   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 of values:
   scalars, ranges and sets.  For example, a well-known port number
   could be defined using the PolicyIntegerValue 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 the class definition
   for each value type in Section 6.14 of this document.

   PCIMe defines the following subclasses of the abstract class
   PolicyValue:

   Classes for general use:

      - PolicyStringValue,
      - PolicyIntegerValue,
      - PolicyBitStringValue
      - PolicyBooleanValue.

   Classes for layer 3 Network values:

      - PolicyIPv4AddrValue,
      - PolicyIPv6AddrValue.

   Classes for layer 2 Network values:

      - PolicyMACAddrValue.

   For details, please see the class definition section of each class in
   Section 6.14 of this document.



Moore                       Standards Track                    [Page 40]
^L
RFC 3460                    PCIM Extensions                 January 2003


5.9. Packet Filtering

   PCIMe contains two mechanisms for representing packet filters.  The
   more general of these, termed here the domain-level model, expresses
   packet filters in terms of policy variables and policy values.  The
   other mechanism, termed here the device-level model, expresses packet
   filters in a way that maps more directly to the packet fields to
   which the filters are being applied.  While it is possible to map
   between these two representations of packet filters, no mapping is
   provided in PCIMe itself.

5.9.1. Domain-Level Packet Filters

   In addition to filling in the holes in the overall Policy
   infrastructure, PCIMe proposes a single mechanism for expressing
   domain-level packet filters in policy conditions.  This is being done
   in response to concerns that even though the initial "wave" of
   submodels derived from PCIM were all filtering on IP packets, each
   was doing it in a slightly different way.  PCIMe proposes a common
   way 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 9.    Packet Filtering in Policy Conditions

   In Figure 9., 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 of the FlowDirection condition, care must be taken



Moore                       Standards Track                    [Page 41]
^L
RFC 3460                    PCIM Extensions                 January 2003


   in aggregating a set of SimplePolicyConditions into a
   CompoundFilterCondition.  Otherwise, the resulting
   CompoundPolicyCondition may match all inbound packets, or all
   outbound packets, when 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, the Boolean property IsMirrored.
   The purpose of this property is to allow a single
   CompoundFilterCondition to match packets traveling in both directions
   on 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 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 and their Source port = 80.  If IsMirrored is TRUE, however,
   an outbound packet will also match the CompoundFilterCondition if its
   Destination IP address = 9.1.1.1 and its Destination port = 80.

   IsMirrored "flips" 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.9.2. Device-Level Packet Filters

   At the device level, packet header filters are represented by two
   subclasses of the abstract class FilterEntryBase: IpHeadersFilter and
   8021Filter.  Submodels of PCIMe may define other subclasses of
   FilterEntryBase in addition to these two; ICPM [12], for example,
   defines subclasses for IPsec-specific filters.





Moore                       Standards Track                    [Page 42]
^L
RFC 3460                    PCIM Extensions                 January 2003


   Instances of the subclasses of FilterEntryBase are not used directly
   as filters.  They are always aggregated into a FilterList, by the
   aggregation EntriesInFilterList.  For PCIMe and its submodels, the
   EntrySequence property in this aggregation always takes its default
   value '0', indicating that the aggregated filter entries are ANDed
   together.

   The FilterList class includes an enumeration property Direction,
   representing the direction of the traffic flow to which the
   FilterList is to be applied.  The value Mirrored(4) for Direction
   represents exactly the same thing as the IsMirrored boolean does in
   CompoundFilterCondition.  See Section 5.9.1 for details.

5.10. Conformance to PCIM and PCIMe

   Because PCIM and PCIMe provide the core classes for modeling
   policies, they are not in general sufficient by themselves for
   representing actual policy rules.  Submodels, such as QPIM and ICPM,
   provide the means for expressing policy rules, by defining subclasses
   of the classes defined in PCIM and PCIMe, and/or by indicating how
   the PolicyVariables and PolicyValues defined in PCIMe can be used to
   express conditions and actions applicable to the submodel.

   A particular submodel will not, in general, need to use every element
   defined in PCIM and PCIMe.  For the elements it does not use, a
   submodel SHOULD remain silent on whether its implementations must
   support the element, must not support the element, should support the
   element, etc.  For the elements it does use, a submodel SHOULD
   indicate which elements its implementations must support, which
   elements they should support, and which elements they may support.

   PCIM and PCIMe themselves simply define elements that may be of use
   to submodels.  These documents remain silent on whether
   implementations are required to support an element, should support
   it, etc.

   This model (and derived submodels) defines conditions and actions
   that are used by policy rules.  While the conditions and actions
   defined herein are straightforward and may be presumed to be widely
   supported, as submodels are developed it is likely that situations
   will arise in which specific conditions or actions are not supported
   by some part of the policy execution system.  Similarly, situations
   may also occur where rules contain syntactic or semantic errors.

   It should be understood that the behavior and effect of undefined or
   incorrectly defined conditions or actions is not prescribed by this
   information model.  While it would be helpful if it were prescribed,
   the variations in implementation restrict the ability for this



Moore                       Standards Track                    [Page 43]
^L
RFC 3460                    PCIM Extensions                 January 2003


   information model to control the effect.  For example, if an
   implementation only detected that a PEP could not enforce a given
   action on that PEP, it would be very difficult to declare that such a
   failure should affect other PEPs, or the PDP process.  On the other
   hand, if the PDP determines that it cannot properly evaluate a
   condition, that failure may well affect all applications of the
   containing rules.

6. Class Definitions

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

6.1. The Abstract Class "PolicySet"

   PolicySet is an abstract class that may group policies into a
   structured set of policies.

   NAME             PolicySet
   DESCRIPTION      An abstract class that represents a set of policies
                    that form a coherent set.  The set of contained
                    policies has a common decision strategy and a
                    common set of policy roles.  Subclasses include
                    PolicyGroup and PolicyRule.
   DERIVED FROM     Policy
   ABSTRACT         TRUE
   PROPERTIES       PolicyDecisionStrategy
                    PolicyRoles

   The PolicyDecisionStrategy property specifies the evaluation method
   for policy groups and rules contained within the policy set.

   NAME             PolicyDecisionStrategy
   DESCRIPTION      The evaluation method used for policies contained in
                    the PolicySet.  FirstMatching enforces the actions
                    of the first rule that evaluates to TRUE;
                    All Matching enforces the actions of all rules
                    that evaluate to TRUE.
   SYNTAX           uint16
   VALUES           1 [FirstMatching], 2 [AllMatching]
   DEFAULT VALUE    1 [FirstMatching]

   The definition of PolicyRoles is unchanged from PCIM.  It is,
   however, moved from the class Policy up to the superclass PolicySet.






Moore                       Standards Track                    [Page 44]
^L
RFC 3460                    PCIM Extensions                 January 2003


6.2. Update PCIM's Class "PolicyGroup"

   The PolicyGroup class is moved, so that it is now derived from
   PolicySet.

   NAME             PolicyGroup
   DESCRIPTION      A container for a set of related PolicyRules and
                    PolicyGroups.
   DERIVED FROM     PolicySet
   ABSTRACT         FALSE
   PROPERTIES       (none)

6.3. Update PCIM's Class "PolicyRule"

   The PolicyRule class is moved, so that it is now derived from
   PolicySet.  The Priority property is also deprecated in PolicyRule,
   and PolicyRoles is now inherited from the parent class PolicySet.
   Finally, a new property ExecutionStrategy is introduced, paralleling
   the property of the same name in 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
                                  AND FOR PolicySetInSystem.Priority
                    Mandatory
                    SequencedActions
                    ExecutionStrategy

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

   Do Until Success - execute actions according to predefined order,
                      until successful execution of 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.



Moore                       Standards Track                    [Page 45]
^L
RFC 3460                    PCIM Extensions                 January 2003


   Do 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
                    PolicyRule.
   SYNTAX           uint16 (ENUM, {1=Do Until Success, 2=Do All, 3=Do
                    Until Failure} )
   DEFAULT VALUE    Do All (2)

6.4. The Class "SimplePolicyCondition"

   A simple policy condition is composed of an 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 interpreted by analyzing the
   variable and value instances associated with the simple condition.

   Simple conditions are building blocks for more complex Boolean
   Conditions, modeled by the CompoundPolicyCondition class.

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

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

   The class definition is as follows:

   NAME             SimplePolicyCondition
   DERIVED FROM     PolicyCondition
   ABSTRACT         False
   PROPERTIES       (none)





Moore                       Standards Track                    [Page 46]
^L
RFC 3460                    PCIM Extensions                 January 2003


6.5. The Class "CompoundPolicyCondition"

   This class represents a compound policy condition, formed by
   aggregation of simpler policy conditions.

   NAME             CompoundPolicyCondition
   DESCRIPTION      A subclass of PolicyCondition that introduces the
                    ConditionListType property, used for assigning DNF /
                    CNF semantics to subordinate policy conditions.
   DERIVED FROM     PolicyCondition
   ABSTRACT         FALSE
   PROPERTIES       ConditionListType

   The ConditionListType property is used to specify whether the list of
   policy conditions associated with this compound policy condition is
   in disjunctive normal form (DNF) or conjunctive normal form (CNF).
   If this property is not present, the list type defaults to DNF.  The
   property definition is as follows:

   NAME             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           uint16
   VALUES           DNF(1), CNF(2)
   DEFAULT VALUE    DNF(1)

6.6. The Class "CompoundFilterCondition"

   This subclass 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 is as follows:







Moore                       Standards Track                    [Page 47]
^L
RFC 3460                    PCIM Extensions                 January 2003


   NAME             IsMirrored
   DESCRIPTION      Indicates whether packets that mirror the specified
                    filter are to be treated as matching the filter.
   SYNTAX           boolean
   DEFAULT VALUE    FALSE

6.7. The Class "SimplePolicyAction"

   The SimplePolicyAction 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 to a single value instance.  Both aggregations are
   defined in this document.

   NAME             SimplePolicyAction
   DESCRIPTION      A subclass of PolicyAction that introduces the
                    notion of "SET variable TO value".
   DERIVED FROM     PolicyAction
   ABSTRACT         FALSE
   PROPERTIES       (none)

6.8. The Class "CompoundPolicyAction"

   The CompoundPolicyAction class is used to represent an expression
   consisting of an ordered sequence of action terms.  Each action term
   is represented as a subclass of the PolicyAction class, defined in
   [PCIM].  Compound actions are constructed by associating dependent
   action terms together using the PolicyActionInPolicyAction
   aggregation.

   The class definition is as follows:

   NAME             CompoundPolicyAction
   DESCRIPTION      A class for representing sequenced action terms.
                    Each action term is defined to be a subclass of the
                    PolicyAction class.
   DERIVED FROM     PolicyAction
   ABSTRACT         FALSE
   PROPERTIES       SequencedActions
                    ExecutionStrategy

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




Moore                       Standards Track                    [Page 48]
^L
RFC 3460                    PCIM Extensions                 January 2003


   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 this compound action.
   (An equivalent ExecutionStrategy property is also defined for the
   PolicyRule class, to provide the same indication for the sequenced
   actions associated with a PolicyRule.)  This document defines three
   execution strategies:

   Do Until Success - execute actions according to predefined order,
                      until successful execution of a single sub-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 fails.
   Do Until Failure - execute actions according to predefined order,
                      until the first failure in execution of a single
                      sub-action.

   Since a CompoundPolicyAction may itself be aggregated either by a
   PolicyRule or by another CompoundPolicyAction, its success or failure
   will be an input to the aggregating entity's execution strategy.
   Consequently, the following rules are specified, for determining
   whether a CompoundPolicyAction succeeds or fails:

   If the CompoundPolicyAction's ExecutionStrategy is Do Until Success,
   then:

      o  If one component action succeeds, then the CompoundPolicyAction
         succeeds.
      o  If all component actions fail, then the CompoundPolicyAction
         fails.

   If the CompoundPolicyAction's ExecutionStrategy is Do All, then:

      o  If all component actions succeed, then the CompoundPolicyAction
         succeeds.
      o  If at least one component action fails, then the
         CompoundPolicyAction fails.

   If the CompoundPolicyAction's ExecutionStrategy is Do Until Failure,
   then:

      o  If all component actions succeed, then the CompoundPolicyAction
         succeeds.
      o  If at least one component action fails, then the
         CompoundPolicyAction fails.



Moore                       Standards Track                    [Page 49]
^L
RFC 3460                    PCIM Extensions                 January 2003


   The definition of the ExecutionStrategy property is as follows:

   NAME             ExecutionStrategy
   DESCRIPTION      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    Do All (2)

6.9. The Abstract Class "PolicyVariable"

   Variables are used for building individual conditions.  The variable
   specifies the property of a flow or an event that should be matched
   when evaluating the condition.  However, not every combination of a
   variable and a value creates a meaningful condition.  For example, a
   source IP address variable can not be matched against a value that
   specifies a port number.  A given variable selects the set of
   matchable value types.

   A variable can have constraints that limit the set of values 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 ExpectedPolicyValuesForVariable 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             PolicyVariable
   DERIVED FROM     Policy
   ABSTRACT         TRUE
   PROPERTIES       (none)

6.10. The Class "PolicyExplicitVariable"

   Explicitly defined policy variables are evaluated within the context
   of the CIM Schema and its modeling constructs.  The
   PolicyExplicitVariable class indicates the exact model property to be
   evaluated or manipulated.  See Section 5.8.6 for a complete
   discussion of what happens when the values of the ModelClass and




Moore                       Standards Track                    [Page 50]
^L
RFC 3460                    PCIM Extensions                 January 2003


   ModelProperty properties in an instance of this class do not
   correspond to the characteristics of the model construct being
   evaluated or updated.

   The class definition is as follows:

   NAME             PolicyExplicitVariable
   DERIVED FROM     PolicyVariable
   ABSTRACT         False
   PROPERTIES       ModelClass, ModelProperty

6.10.1. The Single-Valued Property "ModelClass"

   This property is a string specifying the class name whose property is
   evaluated or set as a PolicyVariable.

   The property is defined as follows:

   NAME             ModelClass
   SYNTAX           String

6.10.2. The Single-Valued Property ModelProperty

   This property is a string specifying the property name, within the
   ModelClass, which is evaluated or set as a PolicyVariable.  The
   property is defined as follows:

   NAME             ModelProperty
   SYNTAX           String

6.11. The Abstract Class "PolicyImplicitVariable"

   Implicitly defined policy variables are evaluated outside of the
   context of the CIM Schema and its modeling constructs.  Subclasses
   specify the data type and semantics of the PolicyVariables.

   Interpretation and evaluation of a PolicyImplicitVariable can vary,
   depending on the particular context in which it is used.  For
   example, a "SourceIP" address may denote the source address field of
   an IP packet header, or the sender address delivered by an RSVP PATH
   message.

   The class definition is as follows:

   NAME             PolicyImplicitVariable
   DERIVED FROM     PolicyVariable
   ABSTRACT         True
   PROPERTIES       ValueTypes[ ]



Moore                       Standards Track                    [Page 51]
^L
RFC 3460                    PCIM Extensions                 January 2003


6.11.1. The Multi-Valued Property "ValueTypes"

   This property is a set of strings specifying an unordered list of
   possible value/data types that can 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.

   The property is defined as follows:

   NAME             ValueTypes
   SYNTAX           String

6.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe

   The following subclasses of PolicyImplicitVariable are defined in
   PCIMe.

6.12.1. The Class "PolicySourceIPv4Variable"

   NAME             PolicySourceIPv4Variable
   DESCRIPTION      The source IPv4 address. of the outermost IP packet
                    header.  "Outermost" here refers to the IP packet as
                    it flows on the wire, before any headers have been
                    stripped from it.

                    ALLOWED VALUE TYPES:
                      - PolicyIPv4AddrValue

   DERIVED FROM     PolicyImplicitVariable
   ABSTRACT         FALSE
   PROPERTIES       (none)

6.12.2. The Class "PolicySourceIPv6Variable"

   NAME             PolicySourceIPv6Variable
   DESCRIPTION      The source IPv6 address of the outermost IP packet
                    header.  "Outermost" here refers to the IP packet as
                    it flows on the wire, before any headers have been
                    stripped from it.





Moore                       Standards Track                    [Page 52]
^L
RFC 3460                    PCIM Extensions                 January 2003


                    ALLOWED VALUE TYPES:
                      - PolicyIPv6AddrValue

   DERIVED FROM     PolicyImplicitVariable
   ABSTRACT         FALSE
   PROPERTIES       (none)

6.12.3. The Class "PolicyDestinationIPv4Variable"

   NAME             PolicyDestinationIPv4Variable
   DESCRIPTION      The destination IPv4 address of the outermost IP
                    packet header.  "Outermost" here refers to the IP
                    packet as it flows on the wire, before any headers
                    have been stripped from it.

                    ALLOWED VALUE TYPES:
                      - PolicyIPv4AddrValue

   DERIVED FROM     PolicyImplicitVariable
   ABSTRACT         FALSE
   PROPERTIES       (none)

6.12.4. The Class "PolicyDestinationIPv6Variable"

   NAME             PolicyDestinationIPv6Variable
   DESCRIPTION      The destination IPv6 address of the outermost IP
                    packet header.  "Outermost" here refers to the IP
                    packet as it flows on the wire, before any headers
                    have been stripped from it.

                    ALLOWED VALUE TYPES:
                    - PolicyIPv6AddrValue

   DERIVED FROM     PolicyImplicitVariable
   ABSTRACT         FALSE
   PROPERTIES       (none)















Moore                       Standards Track                    [Page 53]
^L
RFC 3460                    PCIM Extensions                 January 2003


6.12.5. The Class "PolicySourcePortVariable"

   NAME             PolicySourcePortVariable
   DESCRIPTION      Ports are defined as the abstraction that transport
                    protocols use to distinguish among multiple
                    destinations within a given host computer.  For TCP
                    and UDP flows, the PolicySourcePortVariable is
                    logically bound to the source port field of the
                    outermost UDP or TCP packet header.  "Outermost"
                    here refers to the IP packet as it flows on the
                    wire, before any headers have been stripped from
                    it.
                    ALLOWED VALUE TYPES:
                      - PolicyIntegerValue (0..65535)

   DERIVED FROM     PolicyImplicitVariable
   ABSTRACT         FALSE
   PROPERTIES       (none)

6.12.6. The Class "PolicyDestinationPortVariable"

   NAME             PolicyDestinationPortVariable
   DESCRIPTION      Ports are defined as the abstraction that transport
                    protocols use to distinguish among multiple
                    destinations within a given host computer.  For TCP
                    and UDP flows, the PolicyDestinationPortVariable is
                    logically bound to the destination port field of the
                    outermost UDP or TCP packet header.  "Outermost"
                    here refers to the IP packet as it flows on the
                    wire, before any headers have been stripped from it.

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

   DERIVED FROM     PolicyImplicitVariable
   ABSTRACT         FALSE
   PROPERTIES       (none)

6.12.7. The Class "PolicyIPProtocolVariable"

   NAME             PolicyIPProtocolVariable
   DESCRIPTION      The IP protocol number.

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






Moore                       Standards Track                    [Page 54]
^L
RFC 3460                    PCIM Extensions                 January 2003


   DERIVED FROM     PolicyImplicitVariable
   ABSTRACT         FALSE
   PROPERTIES       (none)

6.12.8. The Class "PolicyIPVersionVariable"

   NAME             PolicyIPVersionVariable
   DESCRIPTION      The IP version number.  The well-known values are 4
                    and 6.

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

   DERIVED FROM     PolicyImplicitVariable
   ABSTRACT         FALSE
   PROPERTIES       (none)

6.12.9. The Class "PolicyIPToSVariable"

   NAME             PolicyIPToSVariable
   DESCRIPTION      The IP TOS octet.

                    ALLOWED VALUE TYPES:
                      - PolicyIntegerValue (0..255)
                      - PolicyBitStringValue (8 bits)

   DERIVED FROM     PolicyImplicitVariable
   ABSTRACT         FALSE
   PROPERTIES       (none)

6.12.10. The Class "PolicyDSCPVariable"

   NAME             PolicyDSCPVariable
   DESCRIPTION      The 6 bit Differentiated Service Code Point.

                    ALLOWED VALUE TYPES:
                      - PolicyIntegerValue (0..63)
                      - PolicyBitStringValue (6 bits)

   DERIVED FROM     PolicyImplicitVariable
   ABSTRACT         FALSE
   PROPERTIES       (none)









Moore                       Standards Track                    [Page 55]
^L
RFC 3460                    PCIM Extensions                 January 2003


6.12.11. The Class "PolicyFlowIdVariable"

   NAME             PolicyFlowIdVariable
   DESCRIPTION      The flow identifier of the outermost IPv6 packet
                    header.  "Outermost" here refers to the IP packet as
                    it flows on the wire, before any headers have been
                    stripped from it.

                    ALLOWED VALUE TYPES:
                      - PolicyIntegerValue (0..1048575
                      - PolicyBitStringValue (20 bits)

   DERIVED FROM     PolicyImplicitVariable
   ABSTRACT         FALSE
   PROPERTIES       (none)

6.12.12. The Class "PolicySourceMACVariable"

   NAME             PolicySourceMACVariable
   DESCRIPTION      The source MAC address.

                    ALLOWED VALUE TYPES:
                      - PolicyMACAddrValue

   DERIVED FROM     PolicyImplicitVariable
   ABSTRACT         FALSE
   PROPERTIES       (none)

6.12.13. The Class "PolicyDestinationMACVariable"

   NAME             PolicyDestinationMACVariable
   DESCRIPTION      The destination MAC address.

                    ALLOWED VALUE TYPES:
                      - PolicyMACAddrValue

   DERIVED FROM     PolicyImplicitVariable
   ABSTRACT         FALSE
   PROPERTIES       (none)

6.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.






Moore                       Standards Track                    [Page 56]
^L
RFC 3460                    PCIM Extensions                 January 2003


                    ALLOWED VALUE TYPES:
                      - PolicyIntegerValue (0..4095)
                      - PolicyBitStringValue (12 bits)

   DERIVED FROM     PolicyImplicitVariable
   ABSTRACT         FALSE
   PROPERTIES       (none)

6.12.15. The Class "PolicyCoSVariable"

   NAME             PolicyCoSVariable
   DESCRIPTION      Class of Service, a 3-bit field, used in the layer 2
                    header to select the forwarding treatment.  Bound to
                    the IEEE 802.1q user-priority field.

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

   DERIVED FROM     PolicyImplicitVariable
   ABSTRACT         FALSE
   PROPERTIES       (none)

6.12.16. The Class "PolicyEthertypeVariable"

   NAME             PolicyEthertypeVariable
   DESCRIPTION      The Ethertype protocol number of Ethernet frames.

                    ALLOWED VALUE TYPES:
                      - PolicyIntegerValue (0..65535)
                      - PolicyBitStringValue (16 bits)

   DERIVED FROM     PolicyImplicitVariable
   ABSTRACT         FALSE
   PROPERTIES       (none)

6.12.17. The Class "PolicySourceSAPVariable"

   NAME             PolicySourceSAPVariable
   DESCRIPTION      The Source Service Access Point (SAP) number of the
                    IEEE 802.2 LLC header.

                    ALLOWED VALUE TYPES:
                      - PolicyIntegerValue (0..255)
                      - PolicyBitStringValue (8 bits)






Moore                       Standards Track                    [Page 57]
^L
RFC 3460                    PCIM Extensions                 January 2003


   DERIVED FROM     PolicyImplicitVariable
   ABSTRACT         FALSE
   PROPERTIES       (none)

6.12.18. The Class "PolicyDestinationSAPVariable"

   NAME             PolicyDestinationSAPVariable
   DESCRIPTION      The Destination Service Access Point (SAP) number of
                    the IEEE 802.2 LLC header.

                    ALLOWED VALUE TYPES:
                      - PolicyIntegerValue (0..255)
                      - PolicyBitStringValue (8 bits)

   DERIVED FROM     PolicyImplicitVariable
   ABSTRACT         FALSE
   PROPERTIES       (none)

6.12.19. The Class "PolicySNAPOUIVariable"

   NAME PolicySNAPOUIVariable
   DESCRIPTION      The value of the first three octets of the Sub-
                    Network Access Protocol (SNAP) Protocol Identifier
                    field for 802.2 SNAP encapsulation, containing an
                    Organizationally Unique Identifier (OUI).  The value
                    00-00-00 indicates the encapsulation of Ethernet
                    frames (RFC 1042).  OUI value 00-00-F8 indicates the
                    special encapsulation of Ethernet frames by certain
                    types of bridges (IEEE 802.1H).  Other values are
                    supported, but are not further defined here.  These
                    OUI values are to be interpreted according to the
                    endian-notation conventions of IEEE 802.  For either
                    of the two Ethernet encapsulations, the remainder of
                    the Protocol Identifier field is represented by the
                    PolicySNAPTypeVariable.

                    ALLOWED VALUE TYPES:
                    - PolicyIntegerValue (0..16777215)
                    - PolicyBitStringValue (24 bits)

   DERIVED          FROM PolicyImplicitVariable
   ABSTRACT         FALSE
   PROPERTIES       (none)








Moore                       Standards Track                    [Page 58]
^L
RFC 3460                    PCIM Extensions                 January 2003


6.12.20. The Class "PolicySNAPTypeVariable"

   NAME             PolicySNAPTypeVariable
   DESCRIPTION      The value of the 4th and 5th octets of the Sub-
                    Network Access Protocol (SNAP) Protocol Identifier
                    field for IEEE 802 SNAP encapsulation when the
                    PolicySNAPOUIVariable indicates one of the two
                    Encapsulated Ethernet frame formats.  This value is
                    undefined for other values of PolicySNAPOUIVariable.

                    ALLOWED VALUE TYPES:
                      - PolicyIntegerValue (0..65535)
                      - PolicyBitStringValue (16 bits)

   DERIVED FROM     PolicyImplicitVariable
   ABSTRACT         FALSE
   PROPERTIES       (none)

6.12.21. The Class "PolicyFlowDirectionVariable"

   NAME             PolicyFlowDirectionVariable
   DESCRIPTION      The direction of a flow relative to a network
                    element.  Direction may be "IN" and/or "OUT".

                    ALLOWED VALUE TYPES:
                      - PolicyStringValue ('IN", "OUT")

   DERIVED FROM     PolicyImplicitVariable
   ABSTRACT         FALSE
   PROPERTIES       (none)

   To match on both inbound and outbound flows, the associated
   PolicyStringValue object has two entries in its StringList property:
   "IN" and "OUT".

6.13. The Abstract Class "PolicyValue"

   This is an abstract class that serves as the base class for all
   subclasses that are used to define value objects in the PCIMe.  It is
   used for defining values and constants used in policy conditions.
   The class definition is as follows:

   NAME             PolicyValue
   DERIVED FROM     Policy
   ABSTRACT         True
   PROPERTIES       (none)





Moore                       Standards Track                    [Page 59]
^L
RFC 3460                    PCIM Extensions                 January 2003


6.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.

6.14.1. The Class "PolicyIPv4AddrValue"

   This class is used to provide a list of IPv4Addresses, hostnames and
   address range values to be matched against in a policy condition.
   The class definition is as follows:

   NAME             PolicyIPv4AddrValue
   DERIVED FROM     PolicyValue
   ABSTRACT         False
   PROPERTIES       IPv4AddrList[ ]

   The IPv4AddrList property provides an unordered list of strings, each
   specifying a single IPv4 address, a hostname, or a range of IPv4
   addresses, according to the ABNF definition [6] 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 [4])

   In the above definition, each string entry 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 "-".  The range includes all addresses between the
      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 comma ",".  The masked address appears
      before the comma, and the mask appears after the comma.  Example:
      2.3.128.0,255.255.248.0.



Moore                       Standards Track                    [Page 60]
^L
RFC 3460                    PCIM Extensions                 January 2003


   5. A single Hostname.  The Hostname format follows the guidelines and
      restrictions specified in [4].  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             IPv4AddrList
   SYNTAX           String
   FORMAT           IPv4address | IPv4prefix | IPv4range |
                    IPv4maskedaddress | hostname

6.14.2. The Class "PolicyIPv6AddrValue

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

   NAME             PolicyIPv6AddrValue
   DERIVED FROM     PolicyValue
   ABSTRACT         False
   PROPERTIES       IPv6AddrList[ ]

   The property IPv6AddrList provides an unordered list of strings, each
   specifying an IPv6 address, a hostname, or a range of IPv6 addresses.
   IPv6 address format definition uses the standard address format
   defined in [7].  The ABNF definition [6] as specified in [7] 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 defined above.

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



Moore                       Standards Track                    [Page 61]
^L
RFC 3460                    PCIM Extensions                 January 2003


   3. An IPv6range address range, specified by a starting address in dot
      notation and an ending address in dot notation, separated by "-".
      The range includes all addresses between 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.

   Conditions matching IPv6AddrValues evaluate to true according to the
   generic matching rules.  Additionally, a hostname is matched against
   another valid IPv6address representation by resolving the hostname
   into an IPv6 address first, and then comparing the addresses
   afterwards.  Matching hostnames against each other is done using a
   string comparison of the two names.

6.14.3. The Class "PolicyMACAddrValue"

   This class is used to define a list of MAC addresses and MAC address
   range values.  The class definition is as follows:

   NAME             PolicyMACAddrValue
   DERIVED FROM     PolicyValue
   ABSTRACT         False
   PROPERTIES       MACAddrList[ ]

   The property MACAddrList provides an unordered list of strings, each
   specifying a MAC address or a range of MAC addresses.  The 802 MAC
   address canonical format is used.  The ABNF definition [6] 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 an address
      and mask.  The mask specifies the 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.








Moore                       Standards Track                    [Page 62]
^L
RFC 3460                    PCIM Extensions                 January 2003


   The property definition is as follows:

   NAME             MACAddrList
   SYNTAX           String
   FORMAT           MACaddress | MACmaskedaddress

6.14.4. The Class "PolicyStringValue"

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

   NAME             PolicyStringValue
   DERIVED FROM     PolicyValue
   ABSTRACT         False
   PROPERTIES       StringList[ ]

   The property StringList provides an unordered list of strings, each
   representing a single string with wildcards.  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".  The syntax definition is identical to the
   substring assertion syntax defined in [5].  If the asterisk character
   is required as part of the string value itself, it MUST be quoted as
   described in Section 4.3 of [5].

   The property definition is as follows:

   NAME                 StringList
   SYNTAX               String

6.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       BitStringList[ ]

   The property BitStringList provides an unordered list of strings,
   each representing a single bit string or a set of bit strings.  The
   number of bits specified SHOULD equal the number of bits of the
   expected variable.  For example, for a one-octet variable, 8 bits





Moore                       Standards Track                    [Page 63]
^L
RFC 3460                    PCIM Extensions                 January 2003


   should be specified.  If the variable does not have a fixed length,
   the bit string should be matched against the 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 same 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.

   The property definition is as follows:

   NAME             BitStringList
   SYNTAX           String
   FORMAT           bitString | maskedBitString

6.14.6. The Class "PolicyIntegerValue"

   This class provides a list of integer and integer range values.
   Integers of arbitrary sizes can be represented.  The class definition
   is as follows:

   NAME             PolicyIntegerValue
   DERIVED FROM     PolicyValue
   ABSTRACT         False
   PROPERTIES       IntegerList[ ]

   The property IntegerList provides an unordered list of integers and
   integer range values, represented as strings.  The format of this
   property takes one of the following forms:

   1. An integer value.

   2. A range of integers. The range is specified by a starting integer
      and an ending integer, separated by '..'.  The starting integer
      MUST be less than or equal to the ending integer.  The range
      includes all integers between the starting and ending integers,
      including these two integers.




Moore                       Standards Track                    [Page 64]
^L
RFC 3460                    PCIM Extensions                 January 2003


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

   The ABNF definition [6] 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 definition is as follows:

   NAME             IntegerList
   SYNTAX           String
   FORMAT           integer | integerrange

6.14.7. The Class "PolicyBooleanValue"

   This class is used to represent a Boolean (TRUE/FALSE) value.  The
   class definition is as follows:

   NAME             PolicyBooleanValue
   DERIVED FROM     PolicyValue
   ABSTRACT         False
   PROPERTIES       BooleanValue

   The property definition is as follows:

   NAME             BooleanValue
   SYNTAX           boolean

6.15. The Class "PolicyRoleCollection"

   This class represents a collection of 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.



Moore                       Standards Track                    [Page 65]
^L
RFC 3460                    PCIM Extensions                 January 2003


   NAME             PolicyRoleCollection
   DESCRIPTION      A subclass of the CIM Collection class used to group
                    together managed elements that share a role.
   DERIVED FROM     Collection
   ABSTRACT         FALSE

   PROPERTIES       PolicyRole

6.15.1. The Single-Valued Property "PolicyRole"

   This property represents the role associated with a
   PolicyRoleCollection.  The property definition is as follows:

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

6.16. The Class "ReusablePolicyContainer"

   The new class ReusablePolicyContainer 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.
   DERIVED FROM     AdminDomain
   ABSTRACT         FALSE
   PROPERTIES       (none)

6.17. Deprecate PCIM's Class "PolicyRepository"

   The class definition of PolicyRepository (from PCIM) is updated as
   follows, with an indication that the class has been deprecated.  Note
   that when an element of the model is deprecated, its replacement
   element is identified explicitly.

   NAME             PolicyRepository
   DEPRECATED FOR   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.



Moore                       Standards Track                    [Page 66]
^L
RFC 3460                    PCIM Extensions                 January 2003


   DERIVED FROM     AdminDomain
   ABSTRACT         FALSE
   PROPERTIES       (none)

6.18. The Abstract Class "FilterEntryBase"

   FilterEntryBase is the abstract base class from which all filter
   entry classes are derived.  It serves as the endpoint for the
   EntriesInFilterList aggregation, which groups filter entries into
   filter lists.  Its properties include CIM naming attributes and an
   IsNegated boolean property (to easily "NOT" the match information
   specified in an instance of one of its subclasses).

   The class definition is as follows:

   NAME                FilterEntryBase
   DESCRIPTION         An abstract class representing a single
                       filter that is aggregated into a
                       FilterList via the aggregation
                       EntriesInFilterList.
   DERIVED FROM        LogicalElement
   TYPE                Abstract
   PROPERTIES          IsNegated

6.19. The Class "IpHeadersFilter"

   This concrete class contains the most commonly required properties
   for performing filtering on IP, TCP or UDP headers.  Properties not
   present in an instance of IPHeadersFilter are treated as 'all
   values'.  A property HdrIpVersion identifies whether the IP addresses
   in an instance are IPv4 or IPv6 addresses.  Since the source and
   destination IP addresses come from the same packet header, they will
   always be of the same type.

   The class definition is as follows:

   NAME                IpHeadersFilter
   DESCRIPTION         A class representing an entire IP
                       header filter, or any subset of one.
   DERIVED FROM        FilterEntryBase
   TYPE                Concrete
   PROPERTIES          HdrIpVersion, HdrSrcAddress,
                       HdrSrcAddressEndOfRange, HdrSrcMask,
                       HdrDestAddress, HdrDestAddressEndOfRange,
                       HdrDestMask, HdrProtocolID,
                       HdrSrcPortStart, HdrSrcPortEnd,
                       HdrDestPortStart, HdrDestPortEnd, HdrDSCP[ ],
                       HdrFlowLabel



Moore                       Standards Track                    [Page 67]
^L
RFC 3460                    PCIM Extensions                 January 2003


6.19.1. The Property HdrIpVersion

   This property is an 8-bit unsigned integer, identifying the version
   of the IP addresses to be filtered on.  IP versions are identified as
   they are in the Version field of the IP packet header - IPv4 = 4,
   IPv6 = 6.  These two values are the only ones defined for this
   property.

   The value of this property determines the sizes of the OctetStrings
   in the six properties HdrSrcAddress, HdrSrcAddressEndOfRange,
   HdrSrcMask, HdrDestAddress, HdrDestAddressEndOfRange, and
   HdrDestMask, as follows:

   o  IPv4:  OctetString(SIZE (4))

   o  IPv6:  OctetString(SIZE (16|20)), depending on whether a scope
      identifier is present

   If a value for this property is not provided, then the filter does
   not consider IP version in selecting matching packets, i.e., IP
   version matches for all values.  In this case, the HdrSrcAddress,
   HdrSrcAddressEndOfRange, HdrSrcMask, HdrDestAddress,
   HdrDestAddressEndOfRange, and HdrDestMask must also not be present.

6.19.2. The Property HdrSrcAddress

   This property is an OctetString, of a size determined by the value of
   the HdrIpVersion property, representing a source IP address.  When
   there is no HdrSrcAddressEndOfRange value, this value is compared to
   the source address in the IP header, subject to the mask represented
   in the HdrSrcMask property.  (Note that the mask is ANDed with the
   address.)  When there is a HdrSrcAddressEndOfRange value, this value
   is the start of the specified range (i.e., the HdrSrcAddress is lower
   than the HdrSrcAddressEndOfRange) that is compared to the source
   address in the IP header and matches on any value in the range.

   If a value for this property is not provided, then the filter does
   not consider HdrSrcAddress in selecting matching packets, i.e.,
   HdrSrcAddress matches for all values.

6.19.3. The Property HdrSrcAddressEndOfRange

   This property is an OctetString, of a size determined by the value of
   the HdrIpVersion property, representing the end of a range of source
   IP addresses (inclusive), where the start of the range is the
   HdrSrcAddress property value.





Moore                       Standards Track                    [Page 68]
^L
RFC 3460                    PCIM Extensions                 January 2003


   If a value for HdrSrcAddress is not provided, then this property also
   MUST NOT be provided.  If a value for this property is provided, then
   HdrSrcMask MUST NOT be provided.

6.19.4. The Property HdrSrcMask

   This property is an OctetString, of a size determined by the value of
   the HdrIpVersion property, representing a mask to be used in
   comparing the source address in the IP header with the value
   represented in the HdrSrcAddress property.

   If a value for this property is not provided, then the filter does
   not consider HdrSrcMask in selecting matching packets, i.e., the
   value of HdrSrcAddress or the source address range must match the
   source address in the packet exactly.  If a value for this property
   is provided, then HdrSrcAddressEndOfRange MUST NOT be provided.

6.19.5. The Property HdrDestAddress

   This property is an OctetString, of a size determined by the value of
   the HdrIpVersion property, representing a destination IP address.
   When there is no HdrDestAddressEndOfRange value, this value is
   compared to the destination address in the IP header, subject to the
   mask represented in the HdrDestMask property.  (Note that the mask is
   ANDed with the address.)  When there is a HdrDestAddressEndOfRange
   value, this value is the start of the specified range (i.e., the
   HdrDestAddress is lower than the HdrDestAddressEndOfRange) that is
   compared to the destination address in the IP header and matches on
   any value in the range.

   If a value for this property is not provided, then the filter does
   not consider HdrDestAddress in selecting matching packets, i.e.,
   HdrDestAddress matches for all values.

6.19.6. The Property HdrDestAddressEndOfRange

   This property is an OctetString, of a size determined by the value of
   the HdrIpVersion property, representing the end of a range of
   destination IP addresses (inclusive), where the start of the range is
   the HdrDestAddress property value.

   If a value for HdrDestAddress is not provided, then this property
   also MUST NOT be provided.  If a value for this property is provided,
   then HdrDestMask MUST NOT be provided.







Moore                       Standards Track                    [Page 69]
^L
RFC 3460                    PCIM Extensions                 January 2003


6.19.7. The Property HdrDestMask

   This property is an OctetString, of a size determined by the value of
   the HdrIpVersion property, representing a mask to be used in
   comparing the destination address in the IP header with the value
   represented in the HdrDestAddress property.

   If a value for this property is not provided, then the filter does
   not consider HdrDestMask in selecting matching packets, i.e., the
   value of HdrDestAddress or the destination address range must match
   the destination address in the packet exactly.  If a value for this
   property is provided, then HdrDestAddressEndOfRange MUST NOT be
   provided.

6.19.8. The Property HdrProtocolID

   This property is an 8-bit unsigned integer, representing an IP
   protocol type.  This value is compared to the Protocol field in the
   IP header.

   If a value for this property is not provided, then the filter does
   not consider HdrProtocolID in selecting matching packets, i.e.,
   HdrProtocolID matches for all values.

6.19.9. The Property HdrSrcPortStart

   This property is a 16-bit unsigned integer, representing the lower
   end of a range of UDP or TCP source ports.  The upper end of the
   range is represented by the HdrSrcPortEnd property.  The value of
   HdrSrcPortStart MUST be no greater than the value of HdrSrcPortEnd.
   A single port is indicated by equal values for HdrSrcPortStart and
   HdrSrcPortEnd.

   A source port filter is evaluated by testing whether the source port
   identified in the IP header falls within the range of values between
   HdrSrcPortStart and HdrSrcPortEnd, including these two end points.

   If a value for this property is not provided, then the filter does
   not consider HdrSrcPortStart in selecting matching packets, i.e.,
   there is no lower bound in matching source port values.

6.19.10. The Property HdrSrcPortEnd

   This property is a 16-bit unsigned integer, representing the upper
   end of a range of UDP or TCP source ports.  The lower end of the
   range is represented by the HdrSrcPortStart property.  The value of





Moore                       Standards Track                    [Page 70]
^L
RFC 3460                    PCIM Extensions                 January 2003


   HdrSrcPortEnd MUST be no less than the value of HdrSrcPortStart.  A
   single port is indicated by equal values for HdrSrcPortStart and
   HdrSrcPortEnd.

   A source port filter is evaluated by testing whether the source port
   identified in the IP header falls within the range of values between
   HdrSrcPortStart and HdrSrcPortEnd, including these two end points.

   If a value for this property is not provided, then the filter does
   not consider HdrSrcPortEnd in selecting matching packets, i.e., there
   is no upper bound in matching source port values.

6.19.11. The Property HdrDestPortStart

   This property is a 16-bit unsigned integer, representing the lower
   end of a range of UDP or TCP destination ports.  The upper end of the
   range is represented by the HdrDestPortEnd property.  The value of
   HdrDestPortStart MUST be no greater than the value of HdrDestPortEnd.
   A single port is indicated by equal values for HdrDestPortStart and
   HdrDestPortEnd.

   A destination port filter is evaluated by testing whether the
   destination port identified in the IP header falls within the range
   of values between HdrDestPortStart and HdrDestPortEnd, including
   these two end points.

   If a value for this property is not provided, then the filter does
   not consider HdrDestPortStart in selecting matching packets, i.e.,
   there is no lower bound in matching destination port values.

6.19.12. The Property HdrDestPortEnd

   This property is a 16-bit unsigned integer, representing the upper
   end of a range of UDP or TCP destination ports.  The lower end of the
   range is represented by the HdrDestPortStart property.  The value of
   HdrDestPortEnd MUST be no less than the value of HdrDestPortStart.  A
   single port is indicated by equal values for HdrDestPortStart and
   HdrDestPortEnd.

   A destination port filter is evaluated by testing whether the
   destination port identified in the IP header falls within the range
   of values between HdrDestPortStart and HdrDestPortEnd, including
   these two end points.

   If a value for this property is not provided, then the filter does
   not consider HdrDestPortEnd in selecting matching packets, i.e.,
   there is no upper bound in matching destination port values.




Moore                       Standards Track                    [Page 71]
^L
RFC 3460                    PCIM Extensions                 January 2003


6.19.13. The Property HdrDSCP

   The property HdrDSCP is defined as an array of uint8's, restricted to
   the range 0..63.  Since DSCPs are defined as discrete code points,
   with no inherent structure, there is no semantically significant
   relationship between different DSCPs.  Consequently, there is no
   provision for specifying a range of DSCPs in this property.  However,
   a list of individual DSCPs, which are ORed together to form a filter,
   is supported by the array syntax.

   If a value for this property is not provided, then the filter does
   not consider HdrDSCP in selecting matching packets, i.e., HdrDSCP
   matches for all values.

6.19.14. The Property HdrFlowLabel

   The 20-bit Flow Label field in the IPv6 header may be used by a
   source to label sequences of packets for which it requests special
   handling by IPv6 devices, such as non-default quality of service or
   'real-time' service.  This property is an octet string of size 3
   (that is, 24 bits), in which the 20-bit Flow Label appears in the
   rightmost 20 bits, padded on the left with b'0000'.

   If a value for this property is not provided, then the filter does
   not consider HdrFlowLabel in selecting matching packets, i.e.,
   HdrFlowLabel matches for all values.

6.20. The Class "8021Filter"

   This concrete class allows 802.1.source and destination MAC
   addresses, as well as the 802.1 protocol ID, priority, and VLAN
   identifier fields, to be expressed in a single object

   The class definition is as follows:

   NAME                8021Filter
   DESCRIPTION         A class that allows 802.1 source
                       and destination MAC address and
                       protocol ID, priority, and VLAN
                       identifier filters to be
                       expressed in a single object.
   DERIVED FROM        FilterEntryBase
   TYPE                Concrete
   PROPERTIES          8021HdrSrcMACAddr, 8021HdrSrcMACMask,
                       8021HdrDestMACAddr, 8021HdrDestMACMask,
                       8021HdrProtocolID, 8021HdrPriorityValue,
                       8021HDRVLANID




Moore                       Standards Track                    [Page 72]
^L
RFC 3460                    PCIM Extensions                 January 2003


6.20.1. The Property 8021HdrSrcMACAddr

   This property is an OctetString of size 6, representing a 48-bit
   source MAC address in canonical format.  This value is compared to
   the SourceAddress field in the MAC header, subject to the mask
   represented in the 8021HdrSrcMACMask property.

   If a value for this property is not provided, then the filter does
   not consider 8021HdrSrcMACAddr in selecting matching packets, i.e.,
   8021HdrSrcMACAddr matches for all values.

6.20.2. The Property 8021HdrSrcMACMask

   This property is an OctetString of size 6, representing a 48-bit mask
   to be used in comparing the SourceAddress field in the MAC header
   with the value represented in the 8021HdrSrcMACAddr property.

   If a value for this property is not provided, then the filter does
   not consider 8021HdrSrcMACMask in selecting matching packets, i.e.,
   the value of 8021HdrSrcMACAddr must match the source MAC address in
   the packet exactly.

6.20.3. The Property 8021HdrDestMACAddr

   This property is an OctetString of size 6, representing a 48-bit
   destination MAC address in canonical format.  This value is compared
   to the DestinationAddress field in the MAC header, subject to the
   mask represented in the 8021HdrDestMACMask property.

   If a value for this property is not provided, then the filter does
   not consider 8021HdrDestMACAddr in selecting matching packets, i.e.,
   8021HdrDestMACAddr matches for all values.

6.20.4. The Property 8021HdrDestMACMask

   This property is an OctetString of size 6, representing a 48-bit mask
   to be used in comparing the DestinationAddress field in the MAC
   header with the value represented in the 8021HdrDestMACAddr property.

   If a value for this property is not provided, then the filter does
   not consider 8021HdrDestMACMask in selecting matching packets, i.e.,
   the value of 8021HdrDestMACAddr must match the destination MAC
   address in the packet exactly.








Moore                       Standards Track                    [Page 73]
^L
RFC 3460                    PCIM Extensions                 January 2003


6.20.5. The Property 8021HdrProtocolID

   This property is a 16-bit unsigned integer, representing an Ethernet
   protocol type.  This value is compared to the Ethernet Type field in
   the 802.3 MAC header.

   If a value for this property is not provided, then the filter does
   not consider 8021HdrProtocolID in selecting matching packets, i.e.,
   8021HdrProtocolID matches for all values.

6.20.6. The Property 8021HdrPriorityValue

   This property is an 8-bit unsigned integer, representing an 802.1Q
   priority.  This value is compared to the Priority field in the 802.1Q
   header.  Since the 802.1Q Priority field consists of 3 bits, the
   values for this property are limited to the range 0..7.

   If a value for this property is not provided, then the filter does
   not consider 8021HdrPriorityValue in selecting matching packets,
   i.e., 8021HdrPriorityValue matches for all values.

6.20.7. The Property 8021HdrVLANID

   This property is a 32-bit unsigned integer, representing an 802.1Q
   VLAN Identifier.  This value is compared to the VLAN ID field in the
   802.1Q header.  Since the 802.1Q VLAN ID field consists of 12 bits,
   the values for this property are limited to the range 0..4095.

   If a value for this property is not provided, then the filter does
   not consider 8021HdrVLANID in selecting matching packets, i.e.,
   8021HdrVLANID matches for all values.

6.21. The Class FilterList

   This is a concrete class that aggregates instances of (subclasses of)
   FilterEntryBase via the aggregation EntriesInFilterList.  It is
   possible to aggregate different types of filters into a single
   FilterList - for example, packet header filters (represented by the
   IpHeadersFilter class) and security filters (represented by
   subclasses of FilterEntryBase defined by IPsec).

   The aggregation property EntriesInFilterList.EntrySequence is always
   set to 0, to indicate that the aggregated filter entries are ANDed
   together to form a selector for a class of traffic.







Moore                       Standards Track                    [Page 74]
^L
RFC 3460                    PCIM Extensions                 January 2003


   The class definition is as follows:

   NAME                FilterList
   DESCRIPTION         A concrete class representing
                       the aggregation of multiple filters.
   DERIVED FROM        LogicalElement
   TYPE                Concrete
   PROPERTIES          Direction

6.21.1. The Property Direction

   This property is a 16-bit unsigned integer enumeration, representing
   the direction of the traffic flow to which the FilterList is to be
   applied.  Defined enumeration values are

   o  NotApplicable(0)
   o  Input(1)
   o  Output(2)
   o  Both(3) - This value is used to indicate that the direction is
      immaterial, e.g., to filter on a source subnet regardless of
      whether the flow is inbound or outbound
   o  Mirrored(4) - This value is also applicable to both inbound and
      outbound flow processing, but it indicates that the filter
      criteria are applied asymmetrically to traffic in both directions
      and, thus, specifies the reversal of source and destination
      criteria (as opposed to the equality of these criteria as
      indicated by "Both").  The match conditions in the aggregated
      FilterEntryBase subclass instances are defined from the
      perspective of outbound flows and applied to inbound flows as well
      by reversing the source and destination criteria.  So, for
      example, consider a FilterList with 3 filter entries indicating
      destination port = 80, and source and destination addresses of a
      and b, respectively.  Then, for the outbound direction, the filter
      entries match as specified and the 'mirror' (for the inbound
      direction) matches on source port = 80 and source and destination
      addresses of b and a, respectively.

7. Association and Aggregation Definitions

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

7.1. The Aggregation "PolicySetComponent"

   PolicySetComponent is a new aggregation class that collects instances
   of PolicySet subclasses (PolicyGroups and PolicyRules) into coherent
   sets of policies.



Moore                       Standards Track                    [Page 75]
^L
RFC 3460                    PCIM Extensions                 January 2003


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

   The 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

7.2. Deprecate PCIM's Aggregation "PolicyGroupInPolicyGroup"

   The new aggregation PolicySetComponent is 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             PolicyGroupInPolicyGroup
   DEPRECATED FOR   PolicySetComponent
   DESCRIPTION      A class representing the aggregation of PolicyGroups
                    by a higher-level PolicyGroup.
   DERIVED FROM     PolicyComponent
   ABSTRACT         FALSE
   PROPERTIES       GroupComponent[ref PolicyGroup[0..n]]
                    PartComponent[ref PolicyGroup[0..n]]

7.3. Deprecate PCIM's Aggregation "PolicyRuleInPolicyGroup"

   The new aggregation PolicySetComponent is used directly to represent
   aggregation of PolicyRules by a PolicyGroup.  Thus the aggregation
   PolicyRuleInPolicyGroup is no longer needed, and can be deprecated.

   NAME             PolicyRuleInPolicyGroup
   DEPRECATED FOR   PolicySetComponent
   DESCRIPTION      A class representing the aggregation of PolicyRules
                    by a PolicyGroup.
   DERIVED FROM     PolicyComponent



Moore                       Standards Track                    [Page 76]
^L
RFC 3460                    PCIM Extensions                 January 2003


   ABSTRACT         FALSE
   PROPERTIES       GroupComponent[ref PolicyGroup[0..n]]
                    PartComponent[ref PolicyRule[0..n]]

7.4. The Abstract Association "PolicySetInSystem"

   PolicySetInSystem is a new association that defines a relationship
   between a System and a PolicySet used in the administrative scope of
   that system (e.g., AdminDomain, ComputerSystem).  The Priority
   property is used to assign a relative priority to a PolicySet within
   the administrative scope in contexts where it is not a component of
   another PolicySet.

   NAME             PolicySetInSystem
   DESCRIPTION      An abstract class representing the relationship
                    between a System and a PolicySet that is used in the
                    administrative scope of the System.
   DERIVED FROM     PolicyInSystem
   ABSTRACT         TRUE
   PROPERTIES       Antecedent[ref System[0..1]]
                    Dependent [ref PolicySet[0..n]]
                    Priority

   The Priority property is used to specify the relative priority of the
   referenced PolicySet when there are more than one PolicySet instances
   applied to a managed resource that are not PolicySetComponents and,
   therefore, have no other relative priority defined.

   NAME             Priority
   DESCRIPTION      A non-negative integer for prioritizing the
                    referenced PolicySet among other PolicySet
                    instances that are not components of a common
                    PolicySet.  A larger value indicates a higher
                    priority.
   SYNTAX           uint16
   DEFAULT VALUE    0

7.5. Update PCIM's Weak Association "PolicyGroupInSystem"

   Regardless of whether it a component of another PolicySet, a
   PolicyGroup is itself defined within the scope of a System.  This
   association links a PolicyGroup to the System in whose scope the
   PolicyGroup is defined.  It is a subclass of the abstract
   PolicySetInSystem association.  The class definition for the
   association is as follows:






Moore                       Standards Track                    [Page 77]
^L
RFC 3460                    PCIM Extensions                 January 2003


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

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

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

7.6. Update PCIM's Weak Association "PolicyRuleInSystem"

   Regardless of whether it a component of another PolicySet, a
   PolicyRule is itself defined within the scope of a System.  This
   association links a PolicyRule to the System in whose scope the
   PolicyRule is defined.  It is a subclass of the abstract
   PolicySetInSystem association. The class definition for the
   association is as follows:

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

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





Moore                       Standards Track                    [Page 78]
^L
RFC 3460                    PCIM Extensions                 January 2003


   The Reference "Dependent" is inherited from PolicySetInSystem, and
   overridden to become an object reference to a PolicyRule defined
   within the scope of a System.  Note that for any single instance of
   the association class PolicyRuleInSystem, this property (like all
   Reference properties) is single-valued.  The [0..n] cardinality
   indicates that a given System may have 0, 1, or more than one
   PolicyRules defined within its scope.

7.7. The Abstract Aggregation "PolicyConditionStructure"

   NAME             PolicyConditionStructure
   DESCRIPTION      A class representing the aggregation of
                    PolicyConditions by an aggregating instance.
   DERIVED FROM     PolicyComponent
   ABSTRACT         TRUE
   PROPERTIES       PartComponent[ref PolicyCondition[0..n]]
                    GroupNumber
                    ConditionNegated
7.8. Update PCIM's Aggregation "PolicyConditionInPolicyRule"

   The PCIM aggregation "PolicyConditionInPolicyRule" is updated, to
   make it a subclass of the new abstract aggregation
   PolicyConditionStructure.  The properties GroupNumber and
   ConditionNegated are now inherited, rather than specified explicitly
   as they were in PCIM.

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

7.9. The Aggregation "PolicyConditionInPolicyCondition"

   A second subclass of PolicyConditionStructure is defined,
   representing the compounding of policy conditions into a higher-level
   policy condition.

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






Moore                       Standards Track                    [Page 79]
^L
RFC 3460                    PCIM Extensions                 January 2003


7.10. The Abstract Aggregation "PolicyActionStructure"

   NAME             PolicyActionStructure
   DESCRIPTION      A class representing the aggregation of
                    PolicyActions by an aggregating instance.
   DERIVED FROM     PolicyComponent
   ABSTRACT         TRUE
   PROPERTIES       PartComponent[ref PolicyAction[0..n]]
                    ActionOrder

   The definition of the ActionOrder property appears in Section 7.8.3
   of PCIM [1].

7.11. Update PCIM's Aggregation "PolicyActionInPolicyRule"

   The PCIM aggregation "PolicyActionInPolicyRule" is updated, to make
   it a subclass of the new abstract aggregation PolicyActionStructure.
   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 PolicyRule.
   DERIVED FROM     PolicyActionStructure
   ABSTRACT         FALSE
   PROPERTIES       GroupComponent[ref PolicyRule[0..n]]

7.12. The Aggregation "PolicyActionInPolicyAction"

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

   NAME             PolicyActionInPolicyAction
   DESCRIPTION      A class representing the aggregation of
                    PolicyActions by another PolicyAction.
   DERIVED FROM     PolicyActionStructure
   ABSTRACT         FALSE
   PROPERTIES       GroupComponent[ref CompoundPolicyAction[0..n]]

7.13. The Aggregation "PolicyVariableInSimplePolicyCondition"

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



Moore                       Standards Track                    [Page 80]
^L
RFC 3460                    PCIM Extensions                 January 2003


   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 "GroupComponent" is inherited from
   PolicyComponent, and overridden to become an object reference to a
   SimplePolicyCondition that contains exactly one PolicyVariable.  Note
   that for any single instance of the aggregation class
   PolicyVariableInSimplePolicyCondition, this property 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" is inherited from
   PolicyComponent, and overridden to become an object reference to a
   PolicyVariable that is defined within the scope of a
   SimplePolicyCondition.  Note that for any single instance of the
   association class PolicyVariableInSimplePolicyCondition, this
   property (like all reference properties) is single-valued.  The
   [1..1] cardinality indicates that a SimplePolicyCondition must have
   exactly one policy variable defined within its scope in order to be
   meaningful.

7.14. The Aggregation "PolicyValueInSimplePolicyCondition"

   A simple policy condition is represented as an ordered triplet
   {variable, operator, value}.  This aggregation provides the linkage
   between a SimplePolicyCondition instance and a single PolicyValue.
   The aggregation PolicyVariableInSimplePolicyCondition links the
   SimplePolicyCondition to a single PolicyVariable.  The Operator
   property of SimplePolicyCondition represents the third element of the
   triplet, the operator.

   The class definition for 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 overridden to become an object reference to a
   SimplePolicyCondition that contains exactly one PolicyValue.  Note



Moore                       Standards Track                    [Page 81]
^L
RFC 3460                    PCIM Extensions                 January 2003


   that for any single instance of the aggregation class
   PolicyValueInSimplePolicyCondition, this property is single-valued.
   The [0..n] cardinality indicates that there may be 0, 1, or more
   SimplePolicyCondition 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
   SimplePolicyCondition.  Note that for any single instance of the
   association class PolicyValueInSimplePolicyCondition, this property
   (like all reference properties) is single-valued.  The [1..1]
   cardinality indicates that a SimplePolicyCondition must have exactly
   one policy value defined within its scope in order to be meaningful.

7.15. The Aggregation "PolicyVariableInSimplePolicyAction"

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

   The class definition for 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.



Moore                       Standards Track                    [Page 82]
^L
RFC 3460                    PCIM Extensions                 January 2003


7.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.

7.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.





Moore                       Standards Track                    [Page 83]
^L
RFC 3460                    PCIM Extensions                 January 2003


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

7.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]]

7.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]]

7.20. The Association ExpectedPolicyValuesForVariable

   This association links a PolicyValue object to a PolicyVariable
   object, modeling the set of expected values for that PolicyVariable.
   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 with it the set
   of values (integers) representing the allowed enumeration, using
   appropriate number of instances of the
   ExpectedPolicyValuesForVariable 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 purpose of this association is to support validation of simple
   policy conditions and simple policy actions, prior to their
   deployment to an enforcement point.  This association, and the





Moore                       Standards Track                    [Page 84]
^L
RFC 3460                    PCIM Extensions                 January 2003


   PolicyValue object that it refers to, plays no role when a PDP or a
   PEP is evaluating a simple policy condition, or executing a simple
   policy action.  See Section 5.8.3 for more details on this point.

   The class definition for the association is as follows:

   NAME             ExpectedPolicyValuesForVariable
   DESCRIPTION      A class representing the association of a set of
                    expected values 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
   representing 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 set(s)
   of values that the policy variable can take.

7.21. The Aggregation "ContainedDomain"

   The aggregation ContainedDomain provides a means of nesting of one
   ReusablePolicyContainer inside another one.  The aggregation is
   defined at the level of ReusablePolicyContainer's superclass,
   AdminDomain, to give it applicability to areas other than Core
   Policy.

   NAME             ContainedDomain
   DESCRIPTION      A class representing the aggregation of lower level
                    administrative domains by a higher-level
                    AdminDomain.
   DERIVED FROM     SystemComponent
   ABSTRACT         FALSE
   PROPERTIES       GroupComponent[ref AdminDomain [0..n]]
                    PartComponent[ref AdminDomain [0..n]]








Moore                       Standards Track                    [Page 85]
^L
RFC 3460                    PCIM Extensions                 January 2003


7.22. Deprecate PCIM's "PolicyRepositoryInPolicyRepository"

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

7.23. The Aggregation "EntriesInFilterList"

   This aggregation is a specialization of the Component aggregation; it
   is used to define a set of filter entries (subclasses of
   FilterEntryBase) that are aggregated by a FilterList.

   The cardinalities of the aggregation itself are 0..1 on the
   FilterList end, and 0..n on the FilterEntryBase end.  Thus in the
   general case, a filter entry can exist without being aggregated into
   any FilterList.  However, the only way a filter entry can figure in
   the PCIMe model is by being aggregated into a FilterList by this
   aggregation.

   The class definition for the aggregation is as follows:

   NAME              EntriesInFilterList
   DESCRIPTION       An aggregation used to define a set of
                     filter entries (subclasses of
                     FilterEntryBase) that are aggregated by
                     a particular FilterList.
   DERIVED FROM      Component
   ABSTRACT          False
   PROPERTIES        GroupComponent[ref
                        FilterList[0..1]],
                     PartComponent[ref
                        FilterEntryBase[0..n],
                     EntrySequence

7.23.1. The Reference GroupComponent

   This property is overridden in this aggregation to represent an
   object reference to a FilterList object (instead of to the more
   generic ManagedSystemElement object defined in its superclass).  It
   also restricts the cardinality of the aggregate to 0..1 (instead of
   the more generic 0-or-more), representing the fact that a filter
   entry always exists within the context of at most one FilterList.



Moore                       Standards Track                    [Page 86]
^L
RFC 3460                    PCIM Extensions                 January 2003


7.23.2. The Reference PartComponent

   This property is overridden in this aggregation to represent an
   object reference to a FilterEntryBase object (instead of to the more
   generic ManagedSystemElement object defined in its superclass).  This
   object represents a single filter entry, which may be aggregated with
   other filter entries to form the FilterList.

7.23.3. The Property EntrySequence

   An unsigned 16-bit integer indicating the order of the filter entry
   relative to all others in the FilterList.  The default value '0'
   indicates that order is not significant, because the entries in this
   FilterList are ANDed together.

7.24. 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]]

7.25. 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:






Moore                       Standards Track                    [Page 87]
^L
RFC 3460                    PCIM Extensions                 January 2003


   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 become an object reference to a System, and 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.

8. Intellectual Property

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

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

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




Moore                       Standards Track                    [Page 88]
^L
RFC 3460                    PCIM Extensions                 January 2003


9. Acknowledgements

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

10. Contributors

   This document includes text written by a number of authors (including
   the editor), that was subsequently merged by the editor.  The
   following people contributed text to this document:

   Lee Rafalow
   IBM Corporation, BRQA/501
   4205 S. Miami Blvd.
   Research Triangle Park, NC 27709

   Phone: +1 919-254-4455
   Fax: +1 919-254-6243
   EMail: 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
   EMail: yramberg@cisco.com


   Yoram Snir
   Cisco Systems
   4 Maskit Street
   Herzliya Pituach, Israel  46766

   Phone: +972-9-970-0085
   Fax:  +972-9-970-0366
   EMail: ysnir@cisco.com










Moore                       Standards Track                    [Page 89]
^L
RFC 3460                    PCIM Extensions                 January 2003


   Andrea Westerinen
   Cisco Systems
   Building 20
   725 Alder Drive
   Milpitas, CA  95035

   Phone: +1-408-853-8294
   Fax: +1-408-527-6351
   EMail: 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
   EMail: 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
   EMail: brunner@ccrle.nec.de


   Ron Cohen
   Ntear LLC

   EMail: ronc@ntear.com


   John Strassner
   INTELLIDEN, Inc.
   90 South Cascade Avenue
   Colorado Springs, CO  80903

   Phone: +1-719-785-0648
   EMail: john.strassner@intelliden.com





Moore                       Standards Track                    [Page 90]
^L
RFC 3460                    PCIM Extensions                 January 2003


11. Security Considerations

   The Policy Core Information Model (PCIM) [1] 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.

12. Normative References

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

   [2]  Distributed Management Task Force, Inc., "DMTF Technologies: CIM
        Standards  CIM Schema: Version 2.5", available at
        http://www.dmtf.org/standards/cim_schema_v25.php.

   [3]  Distributed Management Task Force, Inc., "Common Information
        Model (CIM) Specification: Version 2.2", June 14, 1999,
        available at
        http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf.

   [4]  Mockapetris, P., "Domain Names - implementation and
        specification", STD 13, RFC 1035, November 1987.

   [5]  Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
        Directory Access Protocol (v3): Attribute Syntax Definitions",
        RFC 2252, December 1997.

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

   [7]  Hinden, R. and S. Deering, "IP Version 6 Addressing
        Architecture", RFC 2373, July 1998.

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

13. Informative References

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

   [10] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
        Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and
        Waldbusser, "Terminology for Policy-Based Management", RFC 3198,
        November 2001.




Moore                       Standards Track                    [Page 91]
^L
RFC 3460                    PCIM Extensions                 January 2003


   [11] Snir, Y., and Y. Ramberg, J. Strassner, R. Cohen, "Policy QoS
        Information Model", Work in Progress.

   [12] Jason, J., and L. Rafalow, E. Vyncke, "IPsec Configuration
        Policy Model", Work in Progress.

   [13] 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.

   [14] S. Waldbusser, and J. Saperia, T. Hongal, "Policy Based
        Management MIB", Work in Progress.

   [15] B. Moore, and D. Durham, J. Halpern, J. Strassner, A.
        Westerinen, W.  Weiss, "Information Model for Describing Network
        Device QoS Datapath Mechanisms", Work in Progress.

Author's Address

   Bob Moore
   IBM Corporation, BRQA/501
   4205 S. Miami Blvd.
   Research Triangle Park, NC 27709

   Phone: +1 919-254-4436
   Fax: +1 919-254-6243
   EMail: remoore@us.ibm.com























Moore                       Standards Track                    [Page 92]
^L
RFC 3460                    PCIM Extensions                 January 2003


Full Copyright Statement

   Copyright (C) The Internet Society (2003).  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 the information contained herein is provided on an
   "AS IS" basis 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Moore                       Standards Track                    [Page 93]
^L