RFC 3460
Policy Core Information Model (PCIM) Extensions
RFC 3460: Policy Core Information Model (PCIM) Extensions ✨
okay bestie, let's get into it 💖 this one is from January 2003 and it's a Standards Track doc, so it's an actual official Internet protocol spec 🔥
- Request for Comments: 3460
- Network Working Group
- Editor: B. Moore, Ed. (IBM) 🎀
- Date: January 2003
- Category: Standards Track
- Updates: 3060 (it's an update to RFC 3060, which is the original PCIM 🌸)
Status of this Memo 📋
this doc is a standards track protocol spec for the whole Internet community 🌈 it's also asking people to chime in with discussion and suggestions for improvements 💬 if you want to know where this protocol stands officially, check the current edition of "Internet Official Protocol Standards" (STD 1) 🧚 and it's totally open for anyone to share, since distribution of this memo is unlimited 🦋
Copyright Notice ⭐
Copyright (C) The Internet Society (2003). All Rights Reserved. 💅
Abstract 🌸
okay so this doc makes a bunch of changes to the Policy Core Information Model (PCIM, RFC 3060) 🫶 there are two types of changes, and they're both lowkey iconic:
First, a bunch of brand-new elements get introduced, like classes for header filtering 🔥 these stretch PCIM into areas it never covered before ✨
Second, some existing PCIM elements get deprecated and replaced 💀 the example here is policy rule priorities. they're replaced with priorities tied to associations that refer to policy rules 👑
both kinds of changes are done so that, as much as possible, things still interoperate with implementations of the original PCIM model 🫶 so nobody's left behind 🥹 and yes, 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
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
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 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
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..........................................931. Introduction ✨
okay bestie, so this doc is a glow-up for PCIM (the Policy Core Information Model, RFC 3060 [1]) 💅 It makes two kinds of changes. First, it adds a bunch of totally new stuff, like classes for header filtering, that stretches PCIM into areas it never covered before 🦋 Second, some PCIM elements are getting deprecated (like policy rule priorities), and replacement elements get defined to take their place (in this case, priorities tied to associations that refer to policy rules) 🌸 Both kinds of changes are done so that, as far as 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 🎀
ok so Section 3.2 has a short chat about the changes this document makes to the RFC 3060 information model 💖 Here's a super quick rundown:
- Deprecate and replace PolicyRepository and its associations.
- Clarify and expand the ways that PolicyRules and PolicyGroups are aggregated.
- Change how prioritization for PolicyRules is represented, and introduce administrator-specified decision strategies for rule evaluation.
- Expand the role of PolicyRoles, and introduce a means of associating a PolicyRole with a resource.
- Introduce compound policy conditions and compound policy actions into the model.
- Introduce variables and values into the model.
- Introduce variable and value subclasses for packet-header filtering.
- 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 super closely aligned with the DMTF's CIM Core Policy model 💜 There's no separately documented set of rules for writing IETF information models like PCIM, so it's totally reasonable to look at the CIM specs 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.
- Properties may be added to existing classes.
- 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. 🍓 - 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.
- New subclasses may be defined below existing classes.
3.2. List of Changes to the Model
the following subsections give 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
ngl the name "PolicyRepository" is a bad choice 🙈 It's too easy to confuse with the Policy Framework component Policy Repository (from the four-box picture: Policy Management Tool, Policy Repository, PDP, PEP). So the class PolicyRepository is being replaced with the class ReusablePolicyContainer, which is the PCIM class for a container of reusable policy elements. To make this happen, the PCIM class PolicyRepository and its three associations get deprecated, and they're replaced with a new class ReusablePolicyContainer and new associations. As a separate change, the associations for ReusablePolicyContainer are getting broadened, so a ReusablePolicyContainer can contain any reusable policy elements. In PCIM, the only associations defined for a PolicyRepository were for containing 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 bigger "chunks" of reusable policy to place in a ReusablePolicyContainer. They also bring in new semantics for the contextual implications of having one PolicyRule executing within the scope of another PolicyRule 🔥
3.2.3. Priorities and Decision Strategies
okay this one is giving main character energy 👑 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 folded into PCIMe too. Once the Priority property is gone from PolicyRule, there's a new modeling dependency: in order to prioritize a PolicyRule/PolicyGroup relative to other PolicyRules/PolicyGroups, the elements being prioritized must all reside in one of three places: a common PolicyGroup, a common PolicyRule, or a common System.
In the absence of any clear, general criterion for detecting policy conflicts, the PCIM restriction saying priorities only matter 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 lets the policy administrator pick one of two behaviors for 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 works by putting the PolicyDecisionStrategy property in an abstract class PolicySet, which PolicyGroup and PolicyRule are both derived from.) The QPIM rules for applying decision strategies to a nested set of PolicyGroups and PolicyRules have been imported too 🦋
3.2.4. Policy Roles ✨
Okay so policy roles are getting added to PolicyGroups too 💖. They were already a thing on PolicyRule, so now they're coming to the group level as well. To make that happen there's a brand new superclass for both PolicyRules and PolicyGroups called PolicySet 🫶. Nested PolicyRules and PolicyGroups automatically inherit any roles from the outer rule or group, and the nested one can add extra roles of its own 🎀.
It also turned out PCIM had a gap 😭. You could tag a PolicyRule with the role "FrameRelay&&WAN", but there was no way to say which interfaces actually match that. So PCIMe adds a PolicyRoleCollection class 🦋, which represents the collection of resources tied to a particular role. The link between a PolicyRule or PolicyGroup and a set of resources is then an instance of PolicyRoleCollection. Equivalent values should be defined in the PolicyRoles property of PolicyRules and PolicyGroups, and in the PolicyRole property of PolicyRoleCollection 💅.
3.2.5. CompoundPolicyConditions and CompoundPolicyActions 🌈
The CompoundPolicyCondition idea got imported into PCIMe from QPIM 🧚, and it's been glowed up to include a parallel CompoundPolicyAction too. In both cases the vibe is the same: make reusable "chunks" of policy that can live as named elements in a ReusablePolicyContainer 🍓. The "Compound" classes and their associations carry over the condition and action semantics that PCIM defined at the PolicyRule level. That means DNF/CNF for conditions and ordering for actions 🔥.
Compound conditions and actions are built to work with any component conditions and actions. So even though the components may be instances of SimplePolicyCondition and SimplePolicyAction (more on those right below), they don't have to be 👑.
3.2.6. Variables and Values 💜
The SimplePolicyCondition / PolicyVariable / PolicyValue structure got imported into PCIMe from QPIM 🎀. There's now a list of PCIMe-level variables and a list of PCIMe-level values. If needed, other variables and values can be defined in submodels of PCIMe. For example, QPIM defines a set of implicit variables that match up with the fields in RSVP flows 🌸.
There's a matching SimplePolicyAction / PolicyVariable / PolicyValue structure too 🦋. A SimplePolicyCondition means "variable matches value", while a SimplePolicyAction means "set variable to value". Opposite energy, same squad ✨.
3.2.7. Domain-Level Packet Filtering 🧚
For packet filtering specified at the domain level, there's a set of PolicyVariables and PolicyValues that line up with the fields in an IP packet header plus the most common Layer 2 frame header fields 💖. Domain-level policy conditions that filter on these header fields are expected to be expressed as CompoundPolicyConditions built from SimplePolicyConditions that use these variables and values. There's also an extra PolicyVariable called PacketDirection 🫶, which tells you 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 from Section 3.2.7 don't need to be used 🙈. Filter classes derived from the CIM FilterEntryBase class hierarchy are available for these contexts instead. These classes have two big differences from the domain-level ones 👑:
- 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.
- 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 in Sections 6.19 and 6.20, respectively 💅.
4. The Updated Class and Association Class Hierarchies 🌸
The figure below shows the class inheritance hierarchy for PCIMe. Changes from the PCIM hierarchy are noted in parentheses 🦋.
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)
| |
| +--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
The figure below shows the association class hierarchy for PCIMe. As before, changes from PCIM are noted in parentheses ✨.
[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)
| | |
| | +---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
Beyond the changes you can see at the class and association class level, there are other changes from PCIM involving individual class properties 🧁. Sometimes new properties get added to existing classes, and other times existing properties get deprecated (without deprecating the classes that contain them) 🙈.
5. Areas of Extension to PCIM 🦋
The following subsections describe each of the areas where PCIM extensions are being defined 💜.
5.1. Policy Scope 🌈
Policy scopes can 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) all the way down to the specification of a set of rules that apply to devices in a network 🍓. Those latter policies can themselves be classified into at least two groups:
- those policies consumed by a Policy Decision Point (PDP) that specify the rules for an administrative and functional domain, and
- those policies consumed by a Policy Enforcement Point (PEP) that specify the device-specific rules for a functional domain.
The higher-level rules consumed by a PDP, called domain-level policies, may have late binding variables unspecified or specified by a classification 🔥. Device-level rules, on the other hand, are likely to have fewer unresolved bindings 💅.
There is a relationship between these levels of policy specification. It's out of scope for this standards effort, but it's necessary for developing and deploying a usable policy-based configuration system 🫶. An SLA-level policy transformation to the domain-level policy can 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 can be thought of as analogous to a compiler and linkage editor, translating 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, different mechanisms may be more or less appropriate at different levels of abstraction 🌸.
5.1.2. Administrative and Functional Scopes ✨
okay so administrative scopes for policy show up in PCIM and in these PCIM extensions as System subclass instances 💖 usually a domain-level policy gets scoped by an AdminDomain instance (or a whole hierarchy of AdminDomain instances), while a device-level policy might get scoped by a System instance that represents the PEP, like a ComputerSystem instance (see CIM [2]) 🖥️ on top of gathering policies into an administrative domain, these System classes can also bundle up the resources the policies apply to. so cute, right? 🫶
functional scopes (sometimes called functional domains) are mostly defined by the submodels derived from PCIM and PCIMe, and they match up with the service or services the policies apply to 🦋 so Quality of Service could count as a functional scope, or Diffserv and Intserv could each count as one. these scoping decisions live in the structure of the submodels, and they can show up in the number and types of PEP policy client(s), the services, and how the policies interact 💅 policies in different functional scopes get sorted into disjoint sets of policy rules, so they never overlap. different functional domains can share some roles, some conditions, and even some actions 🎀 the rules from different functional domains can even be enforced at the same managed resource, but when it comes to policy evaluation they're totally separate. see section 5.5.3 for more info ✨
The functional scopes MAY be reflected in administrative scopes. that means deployments of policy can use different administrative scopes for different functional scopes, but there is no requirement to do so 🌈
5.2. Reusable Policy Elements 🎀
okay so in PCIM there was a split between reusable PolicyConditions and PolicyActions and the rule-specific ones 💖 there was also a class called PolicyRepository, which was the container for all those reusable elements. honestly the name "PolicyRepository" was kind of a mess 😭 the term is already used in docs like the Policy Framework, where it means the place the PDP pulls all policy specifications from, and where the Policy Management Tool drops all policy specifications. so PolicyRepository is getting deprecated in favor of a new class called ReusablePolicyContainer 🦋
when a class gets deprecated, any associations that point to it must also be deprecated. so we need replacements for PolicyConditionInPolicyRepository, PolicyActionInPolicyRepository, and the aggregation PolicyRepositoryInPolicyRepository 🧚 but PCIMe is also widening the kinds of policy elements that can be reusable, so instead of giving two one-for-one swaps, there's one higher-level association called ReusablePolicy 👑 it lets any policy element (that is, an instance of any subclass of the abstract class Policy) get placed in a ReusablePolicyContainer. iconic ✨
summarizing, these changes in Sections 6 and 7 come from this item:
- The class ReusablePolicyContainer is defined.
- PCIM's PolicyRepository class is deprecated.
- The association ReusablePolicy is defined.
- PCIM's PolicyConditionInPolicyRepository association is deprecated.
- PCIM's PolicyActionInPolicyRepository association is deprecated.
- The aggregation ContainedDomain is defined.
- PCIM's PolicyRepositoryInPolicyRepository aggregation is deprecated.
5.3. Policy Sets 🌸
bestie, a "policy" can be thought of as a coherent set of rules for administering, managing, and controlling access to network resources ("Policy Terminology", reference [10]) 💜 this document makes it easier to structure those coherent sets of rules into subsets. we get into the new options for nesting policy rules in Section 5.4 🫶
there's a new abstract class called PolicySet, which gives us an abstraction for a set of rules. it's derived from Policy, and it's slotted into the inheritance hierarchy above both PolicyGroup and PolicyRule, which reflects the extra structural flexibility and semantic capability both of those subclasses now have 🔥
PolicySet has two properties: PolicyDecisionStrategy and PolicyRoles 🎀 PolicyDecisionStrategy defines how the rules in the policy set are evaluated against each other (see Section 5.5 for more info). PolicyRoles characterizes the resources the PolicySet applies to (see Section 5.6 for more info) ✨
along with PolicySet, there's a brand new concrete aggregation class called PolicySetComponent, which is a subclass of PolicyComponent 🧚 it provides the containment relationship for a PolicySet inside a PolicySet. PolicySetComponent replaces the two PCIM aggregations PolicyGroupInPolicyGroup and PolicyRuleInPolicyGroup, so those two are now deprecated 💀
a PolicySet's relationship to an AdminDomain or some other administrative scoping system (for example, a ComputerSystem) is represented by the PolicySetInSystem abstract association 🦋 this new association is derived from PolicyInSystem. the PolicyGroupInSystem and PolicyRuleInSystem associations now derive from PolicySetInSystem instead of straight from PolicyInSystem. the PolicySetInSystem.Priority property gets its own discussion in Section 5.5.3 💅
5.4. Nested Policy Rules 💅
as we already covered, policy is described by a set of policy rules that can be grouped into subsets 💖 in this section we introduce nested rules, which means defining rules inside rules. nested rules are also called sub-rules, and this document uses both terms interchangeably 🌈 the PolicySetComponent aggregation is how a policy rule gets nested inside another policy rule 🎀
5.4.1. Usage Rules for Nested Rules 🧚
the relationship between rules and sub-rules works like this:
- 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.
- 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.
- 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 actionSuch 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. 🫶
- 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 makes policy more readable, expressive, and reusable 💜 being able to nest policy rules and form sub-rules matters a lot for manageability and scalability, because complex policy rules can be built out of simpler ones 🔥
these enhancements make the policy management tools' job easier, since policy rules can be written in a way that's closer to how humans think 🌸
rule nesting can be used to suggest optimizations in the way policy rules are evaluated (see section 5.5.2 "Side Effects"), but nesting doesn't specify or require any particular order for evaluating conditions. optimization of rule evaluation can happen in the PDP or in the PEP through dedicated code 🧚 it's kind of like the relationship between a high-level language like C and machine code: an optimizer can produce more efficient machine code than a programmer's optimizations in the source code. still, if the PEP or PDP doesn't do optimization, the administrator writing the policy may be able to influence how the policy rules get executed by using rule nesting 👑
nested rules aren't designed for policy repository retrieval optimization 💀 it's assumed that all rules and groups assigned to a role get 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 ✨
okay so a "decision strategy" is basically the evaluation method for the policies in a PolicySet 💅 there are two of them: "FirstMatching" and "AllMatching" 🫶 FirstMatching means the only actions enforced on a given examination of the PolicySet are the ones for the first rule (aka the one with the highest priority) whose conditions evaluate to TRUE. AllMatching means all the rules get evaluated, and for every rule whose conditions evaluate to TRUE, its actions get enforced. Implementations MUST support the FirstMatching decision strategy 🔥; implementations MAY support the AllMatching decision strategy 🌸
as we already talked about, the PolicySet subclasses are PolicyGroup and PolicyRule, and either one can contain PolicySets of either subclass 🎀 loops are a no-go though, and that includes the degenerate case of a PolicySet containing itself 🙈 when PolicySets hold other PolicySets, loops are not allowed. the containment relationship is specified using the PolicySetComponent aggregation 🧚
the relative priority inside a PolicySet is set by the Priority property of the PolicySetComponent aggregation for the contained PolicyGroup and PolicyRule instances. PCIM's PolicyRule.Priority property is now deprecated in favor of this new one 💅 splitting priority off from the rule is a big glow-up for two reasons. first, it generalizes priority so it works for both groups AND rules ✨ second, the priority sits on the relationship between the parent policy set and the subordinate group or rule 🦋 that makes assigning priorities way easier, because the value only matters in relation to other priorities in the same set 💖
together, the PolicySet.PolicyDecisionStrategy and the PolicySetComponent.Priority decide how the rules inside a PolicySet get processed 👑 as before, the larger priority value means the higher priority ⭐ the difference is that PolicySetComponent.Priority MUST have a unique value when compared with the others defined for the same aggregating PolicySet 🔥 that's what makes rule evaluation within a set deterministically specified, so no guessing 🙌
for a FirstMatching decision strategy, the first rule in the set (the one with the highest priority) that evaluates to True is the only rule whose actions get enforced for a particular evaluation pass through the PolicySet 🎯
for an AllMatching decision strategy, all of the matching rules get enforced 🌈 the relative priority decides the order the enforcement point runs the actions in: higher priority rules go first. but here's the tea 🍵 since higher priority actions run first, lower priority rules that also match can get the "last word", which can give a counter-intuitive result 💀 for example, say two rules both evaluate to True, and the higher priority rule sets the DSCP to 3 while the lower priority rule sets the DSCP to 4. the lower priority action runs later, so it "wins" and the DSCP ends up at 4 🙈 that's how conflicts between rules get resolved: by execution order 🫠
an implementation of the rule engine doesn't need to provide the action sequencing, BUT the actions MUST be sequenced by the PEP or PDP on its behalf 🫶 so the rule engine might hand over an ordered list of actions for the PEP to run, and any required serialization then gets handled by the service the rule engine configured. 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 can be nested arbitrarily 🪆 for a FirstMatching decision strategy on a PolicySet, any contained PolicySet that matches satisfies the termination criteria for that FirstMatching strategy 🛑 a PolicySet counts as matching if it's a PolicyRule whose conditions evaluate to True, OR if it's a PolicyGroup and at least one of its contained PolicyGroups or PolicyRules matches 🌸 so the priority attached to the contained PolicySets is what decides when rule evaluation stops in the structured set of rules ✨
in the example in Figure 3, the relative priorities for the nested rules, high to low, are 1A, 1B1, 1X2, 1B3, 1C, 1C1, 1X2 and 1C3 🦋 (quick note: PolicyRule 1X2 shows up in both PolicyGroup 1B and PolicyRule 1C, but with different priorities 👀). of course, which rules get enforced also depends 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 1C3Figure 3. Nested PolicySets with Different Decision Strategies
- because PolicyGroup 1 has a FirstMatching decision strategy, if the conditions of PolicyRule 1A match, its actions get enforced and the evaluation stops 🛑
- if it doesn't match, PolicyGroup 1B gets evaluated using an AllMatching strategy 🌈 since PolicyGroup 1B1 also has an AllMatching strategy, all of the rules and groups of rules inside PolicyGroup 1B1 are evaluated and enforced as appropriate. PolicyRule 1X2 and PolicyRule 1B3 are also evaluated and enforced as appropriate. if any of the sub-rules in the subtrees of PolicyGroup 1B evaluate to True, then PolicyRule 1C is NOT evaluated, because the FirstMatching strategy of PolicyGroup 1 has been satisfied 🙅♀️
- if neither PolicyRule 1A nor PolicyGroup 1B yields a match, then PolicyRule 1C is evaluated 🎀 since it's first matching, rules 1C1, 1X2, and 1C3 are evaluated until the first match, if any 🏁
5.5.2. Side Effects
okay side effects, listen up 👂 although evaluating conditions is sometimes talked about like an ordered set of operations, the rule engine doesn't need to be a procedural language interpreter 🧠 any side effects of condition evaluation or of executing actions MUST NOT affect the result of evaluating other conditions the rule engine evaluates in the same evaluation pass 🔒 that means an implementation of a rule engine MAY evaluate all conditions in any order before it applies the priority and decides which actions get executed 💖
so, no matter how the rule engine is built, it MUST NOT include any side effects of condition evaluation when evaluating conditions for either decision strategy 🚫 for both the AllMatching decision strategy AND for nesting rules within rules (directly or indirectly) where the actions of more than one rule may be enforced, any side effects of enforcing actions MUST NOT be included in condition evaluation on the same evaluation pass 🫶 no sneaky feedback loops, bestie 🙅♀️
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 its own defined set of decision strategies and evaluation priorities 💅 in section 5.6 we talk about some improvements to how PolicyRoles get used, so that the parent PolicySet.PolicyRoles apply to all contained PolicySet instances ✨ BUT a given resource can still have multiple, disjoint PolicySet trees no matter how they're 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's also related to the same managed element 🙅♀️ these PolicySetComponent aggregations get traversed up the tree without regard to how a PolicySet instance ended up related to 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's a required association), but the priority only gets 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 used for QoS policy and the ones used for IKE policy are disjoint, and they are NOT joined in a FirstMatching decision strategy 🙅♀️ instead, they get evaluated independently of one another 🫶
5.5.4. Deterministic Decisions
as we already covered, 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 deterministic behavior based on its decision strategy and its uniquely defined priority 💖
there are definitely cases where rules don't need a unique priority value (where evaluation and execution priority isn't important) 🤷♀️ however, the flexibility gained from this capability isn't considered sufficiently beneficial to justify the possible variations in implementation behavior and the confusion that might result 😭 so, uniqueness it is 👑💅
5.6. Policy Roles ✨
okay so, 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." 🎀 basically it's the label that tells you which stuff a rule is meant for.
In PCIMe, PolicyRoles is a property of PolicySet, and both PolicyRules and PolicyGroups inherit it 💅. This doc also adds PolicyRole as the name for a collection of resources (PolicyRoleCollection), where every element in that collection has the specified role characteristic 🦋.
5.6.1. Comparison of Roles in PCIM with Roles in snmpconf
so the Configuration Management with SNMP (snmpconf) working group has its Policy Based Management MIB [14] 🧚. Over there, policy rules look like this:
if <policyFilter> then <policyAction>The <policyFilter> is a set of conditions that decide whether the policy applies to an object instance 💜. It can compare SNMP variables that are already defined in MIBS, like "ifType == ethernet" 👀.
The policy management MIB in [14] has a Role table that lets you link Roles to elements, and the roles mean the same thing they do in PCIM 🌸. Since a policyFilter can compare SNMP variable values, you can filter elements by their roles through the Role group, and that's honestly so clean 😭.
This is different from PCIM in two ways ✨. First, in PCIM, a set of role(s) gets attached to a policy rule as the value of its PolicyRoles property. The PDP is then expected to actually carry out the role semantics, meaning policies get applied to elements with the right roles 🔥. In [14] though, roles don't need any special processing. They're just treated like any other SNMP variable, and you can compare role values right inside the policy filter of a rule 💖.
Second, PCIM has no formal way to link a role to an object instance. [14] handles this with the Role tables (pmRoleESTable and pmRoleSETable), which associate Role values with elements 🙈.
5.6.2. Addition of PolicyRoleCollection to PCIMe
to fix that second gap in PCIM (no way to link a role to an object instance), PCIMe adds a new class called PolicyRoleCollection, which is derived from the CIM Collection class 🍓. Resources that share a role get grouped by a PolicyRoleCollection instance through the ElementInPolicyRoleCollection aggregation. The role itself lives in the PolicyRole property of that aggregating instance 💅.
A PolicyRoleCollection always exists in the context of a system 🌈. Just like PCIM does for PolicyRules and PolicyGroups, an association called PolicyRoleCollectionInSystem captures that relationship 🫶. And remember, in CIM, System is the base class for describing network devices and administrative domains 🧠.
The association between a PolicyRoleCollection and a system should match the associations that scope the policy rules and groups applied to the resources in that collection ✨. To be specific, a PolicyRoleCollection should be associated with the same System as the applicable PolicyRules and/or PolicyGroups, or with a System higher up in the tree formed by the SystemComponent association 🦋. When a PEP belongs to multiple Systems (AdminDomains) and scoping by a single domain isn't practical, there are two options 💀. One is to arbitrarily limit domain membership to one System/AdminDomain. The other is to define a more global AdminDomain that simply includes the others, and/or that spans the business or enterprise 👑.
here's an example, bestie 🎀. Say there are 20 traffic trunks in a network, and an admin wants to give three of them "gold" service. The admin has also set up several policy rules that describe how "gold" service gets delivered. For those rules, the PolicyRoles property (inherited from PolicySet) is set to "Gold Service" 💜.
To link three traffic trunks to "gold" service, the admin creates an instance of the PolicyRoleCollection class and sets its PolicyRole property to "Gold Service" too 🧚. Then the admin associates the three traffic trunks with that new instance through the ElementInPolicyRoleCollection aggregation 💖. Now a PDP can tell that the "Gold Service" policy rules apply to those three aggregated traffic trunks 🔥.
Roles are mainly there to optimize policy retrieval ⭐. Implementing roles isn't mandatory, and if you do implement them, grouping elements in a PolicyRoleCollection isn't mandatory either 🌸. But if roles are used, then either the collection approach should be implemented, or elements should be able to report their "pre-programmed" roles (the way COPS does it) 🫶.
5.6.3. Roles for PolicyGroups
in PCIM, roles are only attached to policy rules 🙈. But it can be super useful to attach roles to groups of policy rules too 💅. Say a network admin wants a group of rules that only apply to Ethernet interfaces. They can define a policy group with role-combination="Ethernet" and put all the relevant policy rules inside it ✨. (Quick side note: in PCIMe, roles are available to PolicyGroups as well as PolicyRules, because PCIM's PolicyRoles property moves up from PolicyRule to the new abstract class PolicySet. The property is then inherited by both PolicyGroup and PolicyRule 🦋.) Every policy rule in that group implicitly inherits the role-combination from the containing policy group 🌈. A similar implicit inheritance applies to nested policy groups too 🎀.
There's no explicit copying of roles from container to contained entity 💜. Because of that implicit inheritance, it's possible to end up with inconsistent roles (more on that in the example below), and handling those inconsistencies is beyond the scope of PCIMe 💀.
For the example, imagine a PolicyGroup PG1 that contains three PolicyRules, PR1, PR2, and PR3 🧚. PG1 has the roles "Ethernet" and "Fast". The contained rules have the roles shown in Figure 5 👀.
+------------------------------+
| PolicyGroup PG1 |
| PolicyRoles = Ethernet, Fast |
+------------------------------+
|
| +------------------------+
| | PolicyRule PR1 |
|--------| PolicyRoles = Ethernet |
| +------------------------+
|
| +--------------------------+
| | PolicyRule PR2 |
|--------| PolicyRoles = <undefined>|
| +--------------------------+
|
| +------------------------+
| | PolicyRule PR3 |
|--------| PolicyRoles = Slow |
+------------------------+
Figure 5. Inheritance of RolesPR1's PolicyRoles value matches the one in PG1, so it didn't even need to be redefined 🫶. PR2's PolicyRoles value is undefined, so it implicitly inherits its roles from PG1 🌸. PR3's PolicyRoles value is "Slow", which looks like it conflicts with "Fast" from PG1 😭. But honestly, it isn't clear whether these roles are really in conflict 🙈. In one scenario, the policy admin only wanted "Fast"-"Ethernet" rules in the policy group. In another scenario, the admin is saying PR3 applies to all "Ethernet" interfaces, whether they're "Fast" or "Slow" 💅. Only in the first scenario (only "Fast"-"Ethernet" rules in the policy group) is there a role conflict ✨.
You can also override implicitly inherited roles with the right conditions on a PolicyRule 🦋. For example, if PR3 above had defined the following conditions:
(interface is not "Fast") and (interface is "Slow")then that gives PR3 unambiguous semantics 💖.
5.7. Compound Policy Conditions and Compound Policy Actions 🧁
compound policy conditions and compound policy actions get introduced so you can make extra reusable "chunks" of policy 🎀.
5.7.1. Compound Policy Conditions
a CompoundPolicyCondition is a PolicyCondition that represents a Boolean combination of simpler conditions 🧠. The conditions being combined may be SimplePolicyConditions (more on those in Section 6.4), but reusable combinations of policy conditions aren't necessarily limited to simple component conditions 💜.
The PCIM extensions that add compound policy conditions are pretty straightforward 🌈. The point is to apply the DNF / CNF logic from PCIM's PolicyConditionInPolicyRule aggregation to a compound condition that aggregates simpler conditions, so these changes are needed:
- Create a new aggregation PolicyConditionInPolicyCondition, with the same GroupNumber and ConditionNegated properties as PolicyConditionInPolicyRule. The cleanest way to do that is to move those properties up into a new abstract aggregation superclass called PolicyConditionStructure. The existing PolicyConditionInPolicyRule and the new PolicyConditionInPolicyCondition both derive from it 🦋. For now there's no need to re-document the properties themselves, since they're already documented in PCIM as part of the PolicyConditionInPolicyRule aggregation 🫶.
- 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 that PCIM already defines 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 ✨
okay so a compound action is basically a bundle of actions that get applied together as ONE atomic action inside a policy rule 🎀 🫶 It's giving "pack it all up and deliver it as a set." Often actions are related and count as sub-actions of one "logical" action. Like "shape & mark" 🦋 (shape a stream to a set of predefined bandwidth characteristics, then mark those packets with a certain DSCP value). That logical action is really two QoS actions that have to happen in a well-defined order and as a complete set 💅
The CompoundPolicyAction construct lets you make that logical relationship between a bunch of actions and define the activation logic for the whole thing 👑
It's also reusable 🌸 You can store compound actions in a ReusablePolicyContainer and then use them in different policy rules. And ngl this is my favorite part: a compound action can also be aggregated by another compound action 😭 Nested bundles, bestie!!
Just like with CompoundPolicyCondition, the PCIM extensions for compound policy actions are pretty straightforward ✨ The goal is to apply the ActionOrder property from PCIM's PolicyActionInPolicyRule aggregation to a compound action that aggregates simpler actions. Here's what needs to change:
- Create a new aggregation PolicyActionInPolicyAction, with the same ActionOrder property as PolicyActionInPolicyRule. The cleanest move is to lift the property up into a new abstract aggregation superclass called PolicyActionStructure. Then both the existing PolicyActionInPolicyRule and the new PolicyActionInPolicyAction get derived from it 🧚
- You also need a concrete subclass CompoundPolicyAction of PolicyAction, which introduces the SequencedActions property. This one does the same job and works in exactly the same way as the matching property PCIM already defines for the PolicyRule class 🍓
- Finally, a new property ExecutionStrategy is needed for BOTH the PCIM class PolicyRule AND the new class CompoundPolicyAction 🔥 It lets the policy administrator say how the PEP should behave when there are multiple actions aggregated by a PolicyRule or by a CompoundPolicyAction. Main character decision-making, periodt 💜
The class and property definitions for compound policy actions are down below, in Section 6 🦋
5.8. Variables and Values 🌈
okay so this part introduces a few related concepts: PolicyVariables and PolicyValues (plus their many subclasses), SimplePolicyConditions, and SimplePolicyActions 💖
5.8.1. Simple Policy Conditions 🎀
The SimplePolicyCondition class models elementary Boolean expressions of the form (<variable> MATCH <value>). The 'MATCH' relationship is implicit in the model, and how it gets interpreted depends on the variable and the value. Section 5.8.3 explains what the 'MATCH' operator means ✨ You can build arbitrarily complex Boolean expressions by chaining any number of simple conditions together with relational operators, and individual simple conditions can be negated too 🫶 Those big complex expressions are modeled by the class CompoundPolicyCondition (described in Section 5.7.1). Lowkey the whole thing is just Lego for conditions 🧱
For example, the expression SourcePort == 80 can be modeled by a simple condition 🦋 Here, 'SourcePort' is a variable, '==' is the relational operator for equality (which PCIMe generalizes into a "MATCH" relationship), and '80' is an integer value. The full meaning of a simple condition depends on how the variable is bound, and Section 5.8.5 covers variables and their binding rules 💅
The SimplePolicyCondition class takes the basic structure of the PolicyCondition class from PCIM and refines it, using the pair (<variable>, <value>) to form the condition. Quick heads-up: in PCIMe the operator between the variable and the value is always implied. It is NOT part of the formal notation 🙈 (Note: I'm not writing that one in caps because it's just a normal sentence, not a requirement, so ignore the vibes and focus on the meaning, bestie.)
The variable names the attribute of an object that should be matched when the condition gets evaluated. For a QoS model, for example, that object could be the flow being conditioned 🌊 PCIMe introduces a set of predefined variables that cover network attributes people commonly filter on, so everyone can interoperate 🤝 This list covers layer 3 IP attributes like IP network addresses, protocols, and ports, plus some layer 2 attributes (like MAC addresses) ✨
The bound variable gets matched against a value to produce the Boolean result. So for "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 🍓 Simple, iconic, no notes 💀
5.8.2. Using Simple Policy Conditions 💜
Simple conditions can go straight into policy rules, or they can be the building blocks for compound policy conditions 🧚
Simple condition composition MUST enforce the following data-type conformance rule: the ValueTypes property of the variable has to be compatible with the type of the value class being used 🔥 The simplest (and honestly friendliest for users) way to do this is to make the type of the value class match the name of the class. If the ValueTypes property of the variable matches the name of the value class, we know the variable and value instances are compatible with each other 💖
To compose a simple condition, you need an instance of the class SimplePolicyCondition, plus instances of the variable and value classes it uses 🎀 The variable and/or value instances might already exist as reusable objects in an appropriate ReusablePolicyContainer, so check there first, bestie 🌸
Two aggregations create the (<variable>, <value>) pair. The aggregation PolicyVariableInSimplePolicyCondition relates a SimplePolicyCondition to a single variable instance. The aggregation PolicyValueInSimplePolicyCondition does the same for a single value instance. Both aggregations are defined in this document ✨
Figure 6 shows a SimplePolicyCondition with its associated variable and value. It also shows two PolicyValue instances that list the values the variable can take 🦋
+-----------------------+
| SimplePolicyCondition |
+-----------------------+
* @
* @
+------------------+ * @ +---------------+
| (PolicyVariable) |*** @@@| (PolicyValue) |
+------------------+ +---------------+
# #
# ooo #
# #
+---------------+ +---------------+
| (PolicyValue) | ooo | (PolicyValue) |
+---------------+ +---------------+
Aggregation Legend:
**** PolicyVariableInSimplePolicyCondition
@@@@ PolicyValueInSimplePolicyCondition
#### ExpectedPolicyValuesForVariableFigure 6. SimplePolicyCondition 🌈
Note: The class names in parentheses denote subclasses 🧁 The classes named in the figure are abstract, so you can't instantiate them directly. Sorry, no shortcuts, bestie 😭
5.8.3. The Simple Condition Operator ✨
okay so a simple condition is basically an elementary Boolean expression of the form variable MATCHes value 🧠 but here's the tea: the formal notation of the SimplePolicyCondition, together with its associations, only models a pair, (<variable>, <value>) 🎀. The MATCH operator is not directly modeled. It's just implied 🫠, and this implied MATCH carries overloaded semantics, which is a whole mood 💅.
For example, in the simple condition DestinationPort MATCH '80', the MATCH means equality (the 'equal' operator) 🍓. But a different interpretation is needed in these cases:
DestinationPort MATCH {'80', '8080'}-- operator is 'IS SET MEMBER'DestinationPort MATCH {'1 to 255'}-- operator is 'IN INTEGER RANGE'SourceIPAddress MATCH 'MyCompany.com'-- operator is 'IP ADDRESS AS RESOLVED BY DNS'
These examples show how implicit and context-dependent the MATCH operator is 🦋. The interpretation depends on the actual variable and value instances in the simple condition. It's always derived from the bound variable and the value instance associated with the simple condition. Text that comes with the value class and implicit variable definition is used to interpret what the MATCH relationship means 🌸. Below, we define generic (type-independent) matching.
PolicyValues may be multi-fielded, where each field may contain a range of values. The same goes for PolicyVariables too 🌈. Basically, we have to deal with single values (singleton), ranges ([lower bound .. upper bound]), and sets (a,b,c). So no matter the variable or value type, here's the generic set of matching rules for the MATCH operator 👑:
- singleton matches singleton -> the matching rule is defined in the type
- 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
- 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
- ranges [A..B] matches singleton -> is true if A matches B matches singleton
- 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.
- 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]).
- set (a,b,c, ...) match singleton -> is true if a match b match c match ... match singleton
- 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.
- 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). Unless 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 the same type 🔍. If they differ, 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. With this, you can limit a source or destination port to the range 0-200, or limit a source or destination IP address to a specified list of IPv4 address values, and so on 🧚.
+-----------------------+
| 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 SimplePolicyConditionBeing able to express these limits is what lets the model validate a SimplePolicyCondition before it gets deployed to an enforcement point 🛡️. A Policy Management Tool, for example, SHOULD NOT accept the SimplePolicyCondition shown in Figure 7. But if a policy rule with this condition does show up at an enforcement point anyway, the expected values play no role in deciding whether the condition evaluates to True or False 🙈. So 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. When the variable being 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 🙅♀️.
For example, the action "set DSCP to EF" can be modeled by a simple action 🌷. Here, 'DSCP' is an implicit variable that refers to the IP packet header DSCP field, and 'EF' is an integer or bit string value (6 bits). The complete interpretation of a simple action depends on how the variable is bound 🔗.
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. The variable specifies the attribute of an object, and that attribute's value gets set to whatever <value> says 🫶. Picking the object depends on 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. Converting 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 🧩.
Just like with SimplePolicyConditions, the expected values for variables that appear in SimplePolicyActions are there for validation, before the action gets executed. Expected values play no role in action execution 🙃.
Composing a simple action means creating an instance of the class SimplePolicyAction, and making sure the instances of the variable and value classes it uses also exist. The variable and/or value instances may already exist as reusable objects in an appropriate ReusablePolicyContainer ♻️.
Two aggregations are used 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 📸.
+-----------------------+
| SimplePolicyAction |
| |
+-----------------------+
* @
* @
+------------------+ * @ +---------------+
| (PolicyVariable) |*** @@@| (PolicyValue) |
+------------------+ +---------------+
# #
# ooo #
# #
+---------------+ +---------------+
| (PolicyValue) | ooo | (PolicyValue) |
+---------------+ +---------------+
Aggregation Legend:
**** PolicyVariableInSimplePolicyAction
@@@@ PolicyValueInSimplePolicyAction
#### ExpectedPolicyValuesForVariable
Figure 8. SimplePolicyAction5.8.5. Policy Variables 🌟
A variable generically represents information that changes (or "varies"), and that gets set or evaluated by software 💜. In policy, conditions and actions can abstract information as "policy variables" that get 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, you 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 aren't explicitly modeled or instantiated, since there's no perceived value (at this time) in managing at the packet level 📦. So 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 🦄.
5.8.6. Explicitly Bound Policy Variables 🎀
okay so explicitly bound policy variables are the ones that spell out which class and property names are being checked or set. The CIM Schema decides what counts as "appropriate" for the variable (aka the model property), using data types and stuff like class and property qualifiers. 💅
A PolicyExplicitVariable is "explicit" because its model semantics are exactly defined. It is NOT explicit because it's locked to one particular object instance 🙅♀️. If these were tied to instances (through associations, or through an object identification property in the class itself), we'd be forcing element-specific rules on everyone, and that's giving rigid energy 😭. But if we only name the object's model context (class and property name) and leave the binding to the policy framework (for example, through policy roles), you get way more flexibility for both general AND element-specific rules 🦋
Examples, bestie! ✨ An element-specific rule is a condition (a (<variable>, <value>) pair) that defines CIM LogicalDevice DeviceID="12345". Meanwhile, if a PolicyRule's PolicyRoles is "edge device" and the condition (a (<variable>, <value>) pair) is Status="Error", now you've got a general rule for every edge device in error 🌈
Right now, the only binding for a PolicyExplicitVariable defined in PCIMe is to the instances selected by policy roles. For each of those instances, a SimplePolicyCondition that aggregates the PolicyExplicitVariable evaluates to True if and only if ALL of the following are true:
- The instance selected is of the class identified by the variable's
ModelClassproperty, or of a subclass of this class. - The instance selected has the property identified by the variable's
ModelPropertyproperty. - The value of this property in the instance matches the value specified in the
PolicyValueaggregated by the condition.
In all other cases, the SimplePolicyCondition evaluates to False. Not complicated, just precise 🧚
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 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. It's like it got ghosted, but the rest of the rule keeps going 👻💅
Explicit variables would be more powerful if they could reach beyond the instances selected by policy roles, out to related instances. BUT, to represent a policy rule involving those variables in any kind of general way, you'd need something that looks a LOT like a complete policy language 💀. Clearly that's outside the scope of PCIMe, although it might be the subject of a future document 👀
By restricting much of the generality, explicit variables in PCIMe could 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 the goal of the policy rule were both to test a property of that related instance and to set a property of that same instance, then the condition and action of the rule could be represented using PolicyExplicitVariables. Rather than handling this one specific case with explicit variables, though, it was decided to lump them in with the more general case and deal with them if and when a policy language is defined. Honestly? Iconic restraint 🙈
Peep 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. That decides how the variable gets 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 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 in one of two ways: by deriving them directly from the class PolicyImplicitVariable, or by further refining an existing variable class such as SourcePort. When refining a class such as SourcePort, existing binding rules, type or value constraints may be narrowed 🎯
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. Name it like it means it, periodt 💖
PCIMe defines one association and one general-purpose mechanism that together characterize each of the implicitly bound variables it introduces:
- The
ExpectedPolicyValuesForVariableassociation defines the set of value classes that could be matched to this variable. - The list of constraints on the values that the
PolicyVariablecan hold (i.e., values that the variable must match) are defined by the appropriate properties of an associatedPolicyValueclass.
In the example 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 gives you a consistent and extensible set of metadata that defines the semantics of variables 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:
- The
ValueTypesproperty can be used to make sure only proper classes show up in the expression. For example, theSourcePortvariable will never be allowed to be of typePolicyIPv4AddrValue, since source ports have different semantics than IP addresses and may not be matched. However, integer value types are allowed, as the propertyValueTypesholds the string "PolicyIntegerValue", which is the class name for integer values 🙌 - The
ExpectedPolicyValuesForVariableassociation also makes sure variable-specific semantics get enforced (e.g., theSourcePortvariable 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, or an abstract class extended for each individual variable. The reasons for using a class inheritance mechanism for specifying individual implicitly bound variables are these:
- It is easy to extend. A domain-specific information model can easily extend the
PolicyImplicitVariableclass 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 aqosApplicationVariableclass from thePolicyImplicitVariableabstract class 📱 - Introducing 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 😵💫
- 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 📋
- 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 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. So the vibe is: clarity over micro-optimization, every time 💅🌈
5.8.10. Policy Values 🎀
okay so the abstract class PolicyValue is the bestie that models all the values and constants you use in policy conditions 💖 different value types get derived from it so they can represent all the attributes you need ✨ the extensions of PolicyValue defined in this doc give you a list of values for basic network attributes 🌸 values can also stand in for constants as named values, and named values can live in a reusable policy container so multiple conditions can grab them. think well-known ports, well-known protocols, server addresses, and similar stuff 🦋
the PolicyValue subclasses come in three flavors: scalars, ranges and sets 💅 so a well-known port could be a PolicyIntegerValue that's a single value (80 for HTTP), a range (80-88), or a set (80, 82, 8080). the class definition for each value type lives in Section 6.14 of this doc, so go peek there 👀
PCIMe defines these subclasses of the abstract class PolicyValue:
- Classes for general use:
PolicyStringValue,PolicyIntegerValue,PolicyBitStringValuePolicyBooleanValue.
- Classes for layer 3 Network values:
PolicyIPv4AddrValue,PolicyIPv6AddrValue.
- Classes for layer 2 Network values:
PolicyMACAddrValue.
for details, check the class definition section of each class in Section 6.14 of this document 🧚
5.9. Packet Filtering 🍓
okay so PCIMe has two ways to represent packet filters 🫶 the more general one (called the domain-level model) expresses filters using policy variables and policy values. the other one (called the device-level model) expresses filters in a way that maps more directly onto the packet fields the filters act on. you can map between the two, but PCIMe itself doesn't provide a mapping, so that's on you 💀
5.9.1. Domain-Level Packet Filters 🌈
so PCIMe is doing two things here: filling in the holes in the overall Policy infrastructure, and proposing one single mechanism for domain-level packet filters in policy conditions ✨ this came from the fact that the first "wave" of submodels derived from PCIM were all filtering IP packets, but each one was doing it a slightly different way 😭 so PCIMe proposes one common way to express IP packet filters. here's how packet-filtering conditions get expressed in PCIMe:
+---------------------------------+
| CompoundFilterCondition |
| - IsMirrored boolean |
| - ConditionListType (DNF|CNF) |
+---------------------------------+
+ + +
+ + +
+ + +
SimplePC SimplePC SimplePC
* @ * @ * @
* @ * @ * @
* @ * @ * @
FlowDirection "In" SrcIP <addr1> DstIP <addr2>
Aggregation Legend:
++++ PolicyConditionInPolicyCondition
**** PolicyVariableInSimplePolicyCondition
@@@@ PolicyValueInSimplePolicyConditionFigure 9. Packet Filtering in Policy Conditions 🔥
in Figure 9., each SimplePolicyCondition represents a single field you're filtering on: Source IP address, Destination IP address, Source port, and so on 💖 there's also an extra SimplePolicyCondition that says which direction a packet is traveling on an interface, inbound or outbound. because of that FlowDirection condition, you have to be careful when you aggregate a bunch of SimplePolicyConditions into a CompoundFilterCondition 🙈 otherwise the result might match all inbound packets, or all outbound packets, and that's probably not what you meant bestie 😬
individual SimplePolicyConditions can be negated when they get aggregated by a CompoundFilterCondition ✨
CompoundFilterCondition is a subclass of CompoundPolicyCondition, and it adds one extra property: the Boolean property IsMirrored 🦋 the whole point of this one is to let a single CompoundFilterCondition match packets going both ways on a higher-level connection, like a TCP session. when this property is TRUE, extra packets match the filter on top of the ones that would normally match it. let's do an example, it's giving clarity 👑
say we have a CompoundFilterCondition that aggregates these three filters, all ANDed together:
- FlowDirection = "In"
- Source IP = 9.1.1.1
- Source Port = 80
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 🌸 but if IsMirrored is TRUE, an outbound packet will also match if its Destination IP address = 9.1.1.1 and its Destination port = 80. main character energy for the mirror 🪞
IsMirrored "flips" the following Source/Destination packet header fields:
- FlowDirection "In" / FlowDirection "Out"
- Source IP address / Destination IP address
- Source port / Destination port
- Source MAC address / Destination MAC address
- 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 are allowed to define other subclasses of FilterEntryBase on top of these two. ICPM [12], for example, defines subclasses for IPsec-specific filters 🔐
instances of the FilterEntryBase subclasses never get used directly as filters 🙅♀️ they always get aggregated into a FilterList through the aggregation EntriesInFilterList. for PCIMe and its submodels, the EntrySequence property in that aggregation always takes its default value '0', which means the aggregated filter entries are ANDed together ✨
the FilterList class has an enumeration property called Direction, which represents the direction of the traffic flow the FilterList is applied to 💜 the value Mirrored(4) for Direction means exactly the same thing as the IsMirrored boolean in CompoundFilterCondition. see Section 5.9.1 for details 🎀
5.10. Conformance to PCIM and PCIMe 💅
okay this part is so important bestie 😭 PCIM and PCIMe give you the core classes for modeling policies, but they aren't usually enough by themselves to represent actual policy rules 🙈 that's where submodels like QPIM and ICPM come in. they provide the means to express policy rules, either by defining subclasses of the classes in PCIM and PCIMe, or by explaining how the PolicyVariables and PolicyValues defined in PCIMe can express conditions and actions for that submodel 🫶
a particular submodel won't usually need every element defined in PCIM and PCIMe 💖 for the elements it doesn't use, a submodel SHOULD remain silent on whether its implementations must support the element, must not support it, should support it, and so on. 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 just define elements that might be useful to submodels 🧚 these documents stay silent on whether implementations are required to support an element, should support it, and so on.
this model (and the submodels derived from it) defines the conditions and actions that policy rules use 🦋 the conditions and actions here are pretty straightforward and can be presumed to be widely supported. still, as submodels get developed, it's likely that some situations will come up where a specific condition or action isn't supported by some part of the policy execution system 😬 it can also happen that rules contain syntactic or semantic errors.
the behavior and effect of undefined or incorrectly defined conditions or actions is not prescribed by this information model 🙃 it would be helpful if it were, but the variations in implementation limit how much this information model can control the effect. for example, if an implementation only detected that a PEP couldn't enforce a given action on that PEP, it would be very difficult to declare that the failure should affect other PEPs, or the PDP process. on the other hand, if the PDP determines that it can't properly evaluate a condition, that failure may well affect all applications of the containing rules 💀
6. Class Definitions 📚
the following definitions supplement the ones in PCIM itself 💖 PCIM definitions that aren't 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 can 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
PolicyRolesthe PolicyDecisionStrategy property specifies the evaluation method for the 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 hasn't changed from PCIM 🦋 it has just been moved up from the class Policy to the superclass PolicySet 💜
6.2. Update PCIM's Class "PolicyGroup" 🍓
the PolicyGroup class has been moved, so it's 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" ✨
okay bestie, so PolicyRule got a glow-up 💅 It's been moved so it's now derived from PolicySet 🎀 The Priority property is deprecated here, and PolicyRoles gets inherited from the parent class PolicySet 🦋 And there's a brand-new ExecutionStrategy property that matches the one with the same name in 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
ExecutionStrategyThe ExecutionStrategy property decides how the sequenced actions aggregated by this PolicyRule get run 🌸 (Good news: CompoundPolicyAction has its own ExecutionStrategy too, so compound actions get the same vibe 💜) 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.
Do Until Failure - execute actions according to predefined order,
until the first failure in execution of a single
sub-action.Here's the property definition 🧚
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 an ordered triplet, and it looks like this 💖
<Variable> MATCH <Value>No formal modeling of the MATCH operator is provided 🙈 The 'match' relationship is just implied. These simple conditions get evaluated by asking the question:
Does <variable> match <value>?The 'match' relationship gets interpreted by looking at the variable and value instances hooked up to the simple condition ✨
Simple conditions are the building blocks for the fancier Boolean Conditions, which are modeled by the CompoundPolicyCondition class 🦋
The SimplePolicyCondition class is derived from the PolicyCondition class defined in PCIM 🎀
A variable and a value have to be associated with a simple condition to make it a meaningful condition 🫶 You do that with the aggregations PolicyVariableInSimplePolicyCondition and PolicyValueInSimplePolicyCondition respectively.
The class definition is as follows:
NAME SimplePolicyCondition
DERIVED FROM PolicyCondition
ABSTRACT False
PROPERTIES (none)6.5. The Class "CompoundPolicyCondition" 🍓
This class is the compound policy condition, built by aggregating simpler policy conditions together 💅
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 ConditionListTypeThe ConditionListType property says whether the list of policy conditions attached to this compound policy condition is in disjunctive normal form (DNF) or conjunctive normal form (CNF) 👑 If this property isn't present, the list type defaults to DNF ✨ Here's the property definition:
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 adds exactly one new property, the boolean IsMirrored 🔥 That property is the on/off switch for "flipping" the matching 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 IsMirroredThe IsMirrored property says whether packets that "mirror" a compound filter condition should be treated as matching the filter 🦋 Here's the property definition:
NAME IsMirrored
DESCRIPTION Indicates whether packets that mirror the specified
filter are to be treated as matching the filter.
SYNTAX boolean
DEFAULT VALUE FALSE6.7. The Class "SimplePolicyAction" 💜
The SimplePolicyAction class models the most basic set operation, SET <variable> TO <value> 🧚 The set operator MUST overwrite an old value of the variable. Very important, bestie 😭
Two aggregations build the <variable> <value> pair ✨ PolicyVariableInSimplePolicyAction hooks a SimplePolicyAction up to a single variable instance, and PolicyValueInSimplePolicyAction hooks it up 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 represents an expression made of an ordered sequence of action terms 🌈 Each action term is a subclass of the PolicyAction class defined in [PCIM] 💖 Compound actions get built by linking dependent action terms together with 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
ExecutionStrategyThis is a concrete class, so you can make instances of it directly ✨
The SequencedActions property is identical to the SequencedActions property PCIM defines for the class PolicyRule 🦋
The ExecutionStrategy property says how to run the sequenced actions attached to this compound action 🌸 (PolicyRule has its own equivalent ExecutionStrategy property, giving the same kind of instruction for its sequenced actions.) 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.Okay, here's the spicy part 🔥 A CompoundPolicyAction can itself be aggregated by a PolicyRule or by another CompoundPolicyAction, so its success or failure becomes an input to whatever is aggregating it. That's why these rules exist for deciding whether a CompoundPolicyAction succeeds or fails 🧚
If the CompoundPolicyAction's ExecutionStrategy is Do Until Success, then:
- If one component action succeeds, then the CompoundPolicyAction succeeds.
- If all component actions fail, then the CompoundPolicyAction fails.
If the CompoundPolicyAction's ExecutionStrategy is Do All, then:
- If all component actions succeed, then the CompoundPolicyAction succeeds.
- If at least one component action fails, then the CompoundPolicyAction fails.
If the CompoundPolicyAction's ExecutionStrategy is Do Until Failure, then:
- If all component actions succeed, then the CompoundPolicyAction succeeds.
- If at least one component action fails, then the CompoundPolicyAction fails.
Here's the ExecutionStrategy property definition 💅
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 what you use to build individual conditions 💖 A variable says which property of a flow or an event should be matched when the condition gets evaluated 🌈 But not every pairing of a variable and a value makes a meaningful condition, ngl 🙈 For example, a source IP address variable can't be matched against a value that says a port number. A given variable picks out the set of value types it can be matched against 🎀
A variable can also have constraints that narrow down the values, within a particular value type, that can be matched against it in a condition ✨ For example, a source-port variable limits the integer values to the range 0-65535. Integers outside that range can't be matched to the source-port variable, even though they're the right data type 😭 Constraints for a given variable are shown through the ExpectedPolicyValuesForVariable association 🫶
PolicyVariable is an abstract class 🧚 Implicit and explicit context variable classes are defined as subclasses of PolicyVariable, and this document defines a set of implicit variables too 💜
The class definition is as follows:
NAME PolicyVariable
DERIVED FROM Policy
ABSTRACT TRUE
PROPERTIES (none)6.10. The Class "PolicyExplicitVariable" 🌸
Explicitly defined policy variables get evaluated inside the context of the CIM Schema and its modeling constructs 👑 The PolicyExplicitVariable class says exactly which model property is being evaluated or manipulated 🔥 If the values of the ModelClass and ModelProperty properties in an instance of this class don't line up with the characteristics of the model construct being evaluated or updated, see Section 5.8.6 for the full story 🙈
The class definition is as follows:
NAME PolicyExplicitVariable
DERIVED FROM PolicyVariable
ABSTRACT False
PROPERTIES ModelClass, ModelProperty6.10.1. The Single-Valued Property "ModelClass" 🎀
okay so this property is a string that names the class whose property gets evaluated or set as a PolicyVariable 💖
NAME ModelClass
SYNTAX String6.10.2. The Single-Valued Property ModelProperty 🦋
this one is also a string, and it names the property (inside that ModelClass) that gets evaluated or set as a PolicyVariable 🫶
NAME ModelProperty
SYNTAX String6.11. The Abstract Class "PolicyImplicitVariable" 🌸
implicit policy variables get evaluated outside the CIM Schema and its modeling stuff, so it's giving freedom 💅 each subclass gets to decide the data type and semantics of its PolicyVariables.
the meaning can shift depending on where you're using it ✨ like, a "SourceIP" could mean the source address field of an IP packet header, or the sender address that shows up in an RSVP PATH message. same name, different vibe 🧚
NAME PolicyImplicitVariable
DERIVED FROM PolicyVariable
ABSTRACT True
PROPERTIES ValueTypes[ ]6.11.1. The Multi-Valued Property "ValueTypes" 💜
this is a set of strings giving an unordered list of the value/data types this variable can use in simple conditions and actions 🔥 the types are named by their class names (subclasses of PolicyValue, like PolicyStringValue). having the names lets an app search on a specific one and double-check that the variable's data type is the right one 👑
every subclass of PolicyImplicitVariable has its own default ValueTypes list, and that list is written in that variable's definition 🍓
NAME ValueTypes
SYNTAX String6.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe 🌈
the following subclasses of PolicyImplicitVariable are defined in PCIMe, so let's meet the squad 🧚💖
6.12.1. The Class "PolicySourceIPv4Variable" 🎀
this one is the source IPv4 address of the outermost IP packet header ✨ "outermost" means the IP packet as it actually flows on the wire, before any headers have been stripped off it 💅
NAME PolicySourceIPv4Variable
ALLOWED VALUE TYPES
- PolicyIPv4AddrValue
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)6.12.2. The Class "PolicySourceIPv6Variable" 🦋
same energy as the IPv4 one, but for the source IPv6 address of the outermost IP packet header 🌸 "outermost" still means on the wire, before any headers get stripped 🫶
NAME PolicySourceIPv6Variable
ALLOWED VALUE TYPES
- PolicyIPv6AddrValue
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)6.12.3. The Class "PolicyDestinationIPv4Variable" 🌷
this is the destination IPv4 address of the outermost IP packet header 💜 same deal: "outermost" = as it flows on the wire, before headers are stripped 🔥
NAME PolicyDestinationIPv4Variable
ALLOWED VALUE TYPES
- PolicyIPv4AddrValue
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)6.12.4. The Class "PolicyDestinationIPv6Variable" 🌙
the destination IPv6 twin 👯 it's the destination IPv6 address of the outermost IP packet header, and "outermost" is, once again, the on-the-wire view before any stripping 💅
NAME PolicyDestinationIPv6Variable
ALLOWED VALUE TYPES
- PolicyIPv6AddrValue
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)6.12.5. The Class "PolicySourcePortVariable" 🍓
okay ports are the abstraction transport protocols use to tell apart multiple destinations inside one host computer 🖥️✨ for TCP and UDP flows, this variable is logically bound to the source port field of the outermost UDP or TCP packet header 🧚 and yep, "outermost" means the on-the-wire view, before any headers get stripped 💖
NAME PolicySourcePortVariable
ALLOWED VALUE TYPES
- PolicyIntegerValue (0..65535)
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)6.12.6. The Class "PolicyDestinationPortVariable" 🎀
the destination side of the port story 💜 ports are the same abstraction as before, and for TCP and UDP flows this one is logically bound to the destination port field of the outermost UDP or TCP packet header 🦋 "outermost" = on the wire, before stripping 🫶
NAME PolicyDestinationPortVariable
ALLOWED VALUE TYPES
- PolicyIntegerValue (0..65535)
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)6.12.7. The Class "PolicyIPProtocolVariable" 🌈
simple one: this is the IP protocol number ⭐
NAME PolicyIPProtocolVariable
ALLOWED VALUE TYPES
- PolicyIntegerValue (0..255)
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)6.12.8. The Class "PolicyIPVersionVariable" 🌸
this is the IP version number, and the well-known values are 4 and 6 🔥 no notes, we love a clean definition 💅
NAME PolicyIPVersionVariable
ALLOWED VALUE TYPES
- PolicyIntegerValue (0..15)
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)6.12.9. The Class "PolicyIPToSVariable" 🧚
this one is the IP TOS octet 🍓 you can use it as an integer or as an 8-bit bit string, depending on what the definition allows 👑
NAME PolicyIPToSVariable
ALLOWED VALUE TYPES
- PolicyIntegerValue (0..255)
- PolicyBitStringValue (8 bits)
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)6.12.10. The Class "PolicyDSCPVariable" 💖
this is the 6 bit Differentiated Service Code Point 🌷 it can be an integer or a 6-bit bit string ✨
NAME PolicyDSCPVariable
ALLOWED VALUE TYPES
- PolicyIntegerValue (0..63)
- PolicyBitStringValue (6 bits)
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)6.12.11. The Class "PolicyFlowIdVariable" 🦋
this is the flow identifier of the outermost IPv6 packet header 🌈 yup, "outermost" means the on-the-wire packet, before any headers are stripped 🫶
NAME PolicyFlowIdVariable
ALLOWED VALUE TYPES
- PolicyIntegerValue (0..1048575
- PolicyBitStringValue (20 bits)
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)6.12.12. The Class "PolicySourceMACVariable" 🎀
the source MAC address, nothing more, nothing less 💅 it only allows PolicyMACAddrValue 💜
NAME PolicySourceMACVariable
ALLOWED VALUE TYPES
- PolicyMACAddrValue
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)6.12.13. The Class "PolicyDestinationMACVariable" 🌙
the destination MAC address, the other half of the pair 👯 same rule: PolicyMACAddrValue is the only allowed value type 🔥
NAME PolicyDestinationMACVariable
ALLOWED VALUE TYPES
- PolicyMACAddrValue
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)6.12.14. The Class "PolicyVLANVariable" 🌸
this is the virtual Bridged Local Area Network Identifier 🍓 it's a 12-bit field, as defined in IEEE 802.1q, and you can write it as an integer or as a 12-bit bit string ✨
NAME PolicyVLANVariable
ALLOWED VALUE TYPES
- PolicyIntegerValue (0..4095)
- PolicyBitStringValue (12 bits)
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)6.12.15. The Class "PolicyCoSVariable" 💜
Class of Service is a 3-bit field in the layer 2 header that picks the forwarding treatment 🚀 it's bound to the IEEE 802.1q user-priority field 🌈 integer or 3-bit bit string, your choice 💖
NAME PolicyCoSVariable
ALLOWED VALUE TYPES
- PolicyIntegerValue (0..7)
- PolicyBitStringValue (3 bits)
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)6.12.16. The Class "PolicyEthertypeVariable" 🧚
the Ethertype protocol number of Ethernet frames 🦋 it can be an integer, or a 16-bit bit string ⭐
NAME PolicyEthertypeVariable
ALLOWED VALUE TYPES
- PolicyIntegerValue (0..65535)
- PolicyBitStringValue (16 bits)
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)6.12.17. The Class "PolicySourceSAPVariable" 🌷
this is the Source Service Access Point (SAP) number from the IEEE 802.2 LLC header 💅 integer or 8-bit bit string 🎀
NAME PolicySourceSAPVariable
ALLOWED VALUE TYPES
- PolicyIntegerValue (0..255)
- PolicyBitStringValue (8 bits)
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)6.12.18. The Class "PolicyDestinationSAPVariable" 🌈
the Destination Service Access Point (SAP) number from the same IEEE 802.2 LLC header, so it's the other half of the SAP pair 👯 same allowed types as the source one: integer or 8-bit bit string 💖
NAME PolicyDestinationSAPVariable
ALLOWED VALUE TYPES
- PolicyIntegerValue (0..255)
- PolicyBitStringValue (8 bits)
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)6.12.19. The Class "PolicySNAPOUIVariable"
okay bestie, this one is all about the first three octets of the SNAP Protocol Identifier field 🦋 It's an OUI (Organizationally Unique Identifier) for 802.2 SNAP encapsulation, and the full class template is literally giving main character energy:
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)so the vibe is: 00-00-00 means Ethernet frames (RFC 1042) 🌸, 00-00-F8 means the special Ethernet encapsulation by certain bridges (IEEE 802.1H) ✨, and any other values are supported but not further defined here 🍓. The OUI values get read using the endian-notation conventions of IEEE 802 💅. For either of the two Ethernet encapsulations, the rest of the Protocol Identifier field is stored in the PolicySNAPTypeVariable 🫶
the allowed value types are PolicyIntegerValue (0..16777215) and PolicyBitStringValue (24 bits) 💖
6.12.20. The Class "PolicySNAPTypeVariable"
this one is the 4th and 5th octets of that same SNAP Protocol Identifier field 🧚 It only matters when the PolicySNAPOUIVariable is pointing at one of the two Encapsulated Ethernet frame formats, and it's undefined for every other OUI value 🙈
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)the allowed value types are PolicyIntegerValue (0..65535) and PolicyBitStringValue (16 bits) 🎀
6.12.21. The Class "PolicyFlowDirectionVariable"
this is the direction of a flow relative to a network element 🦋 It can be "IN" and/or "OUT", which is so practical ngl 💅
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)the allowed value type is PolicyStringValue ('IN", "OUT") 🌈 and if you want to match on both inbound and outbound flows, the PolicyStringValue object needs two entries in its StringList property: "IN" and "OUT" 👑
6.13. The Abstract Class "PolicyValue"
this is an abstract class and it's the base class for every subclass used to define value objects in the PCIMe 🌸 It's used for defining the values and constants that show up in policy conditions, so basically the building blocks of the whole vibe ✨
NAME PolicyValue
DERIVED FROM Policy
ABSTRACT True
PROPERTIES (none)6.14. Subclasses of "PolicyValue" Specified in PCIMe
the following subsections are the PolicyValue subclasses defined in PCIMe 🧚 Extra subclasses can be defined in models derived from PCIMe, so there's room to grow 🌈
6.14.1. The Class "PolicyIPv4AddrValue"
this class gives you a list of IPv4 addresses, hostnames and address range values to match against in a policy condition 💖
NAME PolicyIPv4AddrValue
DERIVED FROM PolicyValue
ABSTRACT False
PROPERTIES IPv4AddrList[ ]the IPv4AddrList property is an unordered list of strings, and each string is one IPv4 address, a hostname, or an IPv4 address range, following the ABNF definition [6] of an IPv4 address 🦋
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv4prefix = IPv4address "/" 1*2DIGIT
IPv4range = IPv4address"-"IPv4address
IPv4maskedaddress = IPv4address","IPv4address
Hostname (as defined in [4])so each string entry is one of these:
- a single IPv4address in dot notation, like
121.1.1.2🫶 - an IPv4prefix address range, which is an address plus a prefix length separated by
/, like2.3.128.0/15💅 - an IPv4range address range, which is a starting address and an ending address in dot notation separated by
-. The range covers every address between them, and that includes both endpoints, like1.1.22.1-1.1.22.5🌸 - an IPv4maskedaddress address range, which is an address and a mask in dot notation separated by a comma
,. The masked address goes before the comma and the mask goes after it, like2.3.128.0,255.255.248.0✨ - a single Hostname, which follows the guidelines and restrictions in [4], like
www.bigcompany.com🍓
conditions matching IPv4AddrValues evaluate to true using the generic matching rules 🎀 A hostname also gets matched against another valid IPv4address representation by resolving the hostname into an IPv4 address first and then comparing the addresses. Hostnames matched against each other use a plain string comparison of the two names 💜
NAME IPv4AddrList
SYNTAX String
FORMAT IPv4address | IPv4prefix | IPv4range |
IPv4maskedaddress | hostname6.14.2. The Class "PolicyIPv6AddrValue
this class is for defining a list of IPv6 addresses, hostnames, and address range values 🧚
NAME PolicyIPv6AddrValue
DERIVED FROM PolicyValue
ABSTRACT False
PROPERTIES IPv6AddrList[ ]the property IPv6AddrList is an unordered list of strings, and each one is an IPv6 address, a hostname, or a range of IPv6 addresses 🌈 The IPv6 address format 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 one of these:
- a single IPv6address as defined above 💖
- a single Hostname. The hostname format follows the guidelines and restrictions in [4] 🦋
- an IPv6range address range, which is a starting address and an ending address in dot notation separated by
-. The range covers every address between them, including both endpoints 🫶 - an IPv4maskedaddress address range defined above, which is an address and mask in dot notation separated by a comma
,💅 - a single IPv6prefix as defined above 🌸
conditions matching IPv6AddrValues evaluate to true using the generic matching rules ✨ A hostname also gets matched against another valid IPv6address representation by resolving it into an IPv6 address first and then comparing the addresses. Hostnames matched against each other use a plain string comparison of the two names 🍓
6.14.3. The Class "PolicyMACAddrValue"
this class defines a list of MAC addresses and MAC address range values 🎀
NAME PolicyMACAddrValue
DERIVED FROM PolicyValue
ABSTRACT False
PROPERTIES MACAddrList[ ]the property MACAddrList is an unordered list of strings, where each string is a MAC address or a range of MAC addresses 💜 It uses the 802 MAC address canonical format, and the ABNF definition [6] is:
MACaddress = 1*4HEXDIG ":" 1*4HEXDIG ":" 1*4HEXDIG
MACmaskedaddress = MACaddress","MACaddresseach string entry is either:
- a single MAC address, like
0000:00A5:0000🧚 - a MACmaskedaddress address range, specified by an address and a mask. The mask shows the relevant bits in the address. For example,
0000:00A5:0000,FFFF:FFFF:0000defines a range of MAC addresses where the first four octets are equal to0000:00A5🌈
NAME MACAddrList
SYNTAX String
FORMAT MACaddress | MACmaskedaddress6.14.4. The Class "PolicyStringValue"
this class represents a single string value or a set of string values, and each value can have wildcards 💖 The class definition is:
NAME PolicyStringValue
DERIVED FROM PolicyValue
ABSTRACT False
PROPERTIES StringList[ ]the property StringList is an unordered list of strings, where each string is a single string with wildcards 🦋 The asterisk * is the wildcard, and it stands in for any arbitrary substring. For example, "abc*def" matches "abcxyzdef", and "abc*def*" matches "abcxxxdefyyyzzz" ✨ The syntax is identical to the substring assertion syntax defined in [5]. If the asterisk character is needed as part of the string value itself, it MUST be quoted as described in Section 4.3 of [5] 🫶
NAME StringList
SYNTAX String6.14.5. The Class "PolicyBitStringValue"
this class represents a single bit string value or a set of bit string values 🌸
NAME PolicyBitStringValue
DERIVED FROM PolicyValue
ABSTRACT False
PROPERTIES BitStringList[ ]the property BitStringList is an unordered list of strings, and each one is 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, a one-octet variable should have 8 bits specified. If the variable doesn't have a fixed length, the bit string should be matched against the variable's most significant bit string 🎀 The formal grammar is:
binary-digit = "0" / "1"
bitString = 1*binary-digit
maskedBitString = bitString","bitStringeach string entry is either:
- a single bit string, like
00111010💜 - a range of bit strings specified using a bit string and a bit mask. The bit string and mask have the same number of bits. The mask marks the significant bits in the bit string value. For example,
110110,100110and110111would match the maskedBitString100110,101110, but100100would not 🧚
NAME BitStringList
SYNTAX String
FORMAT bitString | maskedBitString6.14.6. The Class "PolicyIntegerValue" 🔢✨
okay bestie, this class is for lists of integers and integer ranges 🧚 and the numbers can be arbitrarily big, like seriously huge 💅 Here's the class:
NAME PolicyIntegerValue
DERIVED FROM PolicyValue
ABSTRACT False
PROPERTIES IntegerList[ ]The IntegerList property is an unordered list of integers and integer ranges, stored as strings 🎀 Each entry takes one of two forms:
- An integer value.
- A range of integers. You write the starting integer and the ending integer, separated by
... The starting integer MUST be less than or equal to the ending integer. The range covers every integer in between, and includes both of the endpoints too 🦋
If you want an unbounded range, use the reserved words -INFINITY and/or INFINITY in place of the starting or ending integer. On top of ordinary integer matches, INFINITY matches INFINITY and -INFINITY matches -INFINITY 🌈
The ABNF definition [6] is:
integer = [-]1*DIGIT | "INFINITY" | "-INFINITY"
integerrange = integer".."integerranges are how you get greater-than, greater-than-or-equal-to, less-than, and less-than-or-equal-to without extra machinery 🙈 For example, "X is- greater-than 5" (X being an integer) can be rewritten as "X matches 6-INFINITY". That keeps the match condition semantics for the SimplePolicyCondition class simple, since it's just the value "match" ✨
The property definition is as follows:
NAME IntegerList
SYNTAX String
FORMAT integer | integerrange6.14.7. The Class "PolicyBooleanValue" ✅❌
this one is simple and iconic 💖 It's used to represent a Boolean value, so TRUE or FALSE. The class definition:
NAME PolicyBooleanValue
DERIVED FROM PolicyValue
ABSTRACT False
PROPERTIES BooleanValueThe property definition:
NAME BooleanValue
SYNTAX boolean6.15. The Class "PolicyRoleCollection" 👯♀️🌸
this class is a collection of managed elements that all share a common role, and it always lives inside a system, linked with the PolicyRoleCollectionInSystem association 🫶 The PolicyRole property holds the role, and it can be matched against the values in the PolicyRoles array in PolicyRules and PolicyGroups. The ManagedElements that share that role get grouped into the collection through the ElementInPolicyRoleCollection association, so they're basically a little friend group 💅
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 PolicyRole6.15.1. The Single-Valued Property "PolicyRole" 🎭
this property is the role attached to a PolicyRoleCollection. Here's how it's defined:
NAME PolicyRole
DESCRIPTION A string representing the role associated with a
PolicyRoleCollection.
SYNTAX string6.16. The Class "ReusablePolicyContainer" 📦💜
the new class ReusablePolicyContainer is defined like this:
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 PolicyRepository class (from PCIM) gets updated, and it's now marked as deprecated 🙃 When a model element is deprecated, its replacement has to be named explicitly, so here the replacement is ReusablePolicyContainer:
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.
DERIVED FROM AdminDomain
ABSTRACT FALSE
PROPERTIES (none)6.18. The Abstract Class "FilterEntryBase" 🧱🔍
FilterEntryBase is the abstract base class that every filter entry class is derived from 🌷 It's the endpoint for the EntriesInFilterList aggregation, which groups filter entries into filter lists. Its properties include the CIM naming attributes and an IsNegated boolean property, which lets you "NOT" the match information in any of its subclasses 🙈
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 IsNegated6.19. The Class "IpHeadersFilter" 🎀🌊
this is the concrete class with the most commonly needed properties for filtering on IP, TCP or UDP headers 💖 Any property that isn't in an IpHeadersFilter instance is treated as "all values," so it matches everything. The HdrIpVersion property says whether the IP addresses are IPv4 or IPv6. Since the source and destination addresses come from the same packet header, they're always the same type, no exceptions 💅
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[ ],
HdrFlowLabel6.19.1. The Property HdrIpVersion 🔖
this is an 8-bit unsigned integer that identifies the version of the IP addresses you're filtering on 🧚 It matches the Version field of the IP packet header, so IPv4 = 4 and IPv6 = 6. Those are the only two values defined for this property ✨
The value here decides how big the OctetStrings are in the six properties HdrSrcAddress, HdrSrcAddressEndOfRange, HdrSrcMask, HdrDestAddress, HdrDestAddressEndOfRange, and HdrDestMask:
- IPv4:
OctetString(SIZE (4)) - IPv6:
OctetString(SIZE (16|20)), depending on whether a scope identifier is present
If no value is given for this property, the filter doesn't care about IP version when picking packets, so IP version matches for all values 🌈 In that case, HdrSrcAddress, HdrSrcAddressEndOfRange, HdrSrcMask, HdrDestAddress, HdrDestAddressEndOfRange, and HdrDestMask must also not be present.
6.19.2. The Property HdrSrcAddress 📍
this is an OctetString, sized by the HdrIpVersion value, and it represents a source IP address 🫶 If there's no HdrSrcAddressEndOfRange value, this is compared to the source address in the IP header, with the HdrSrcMask applied first. (Note that the mask is ANDed with the address.) If there is a HdrSrcAddressEndOfRange value, then this one is the start of the range (so HdrSrcAddress is lower than HdrSrcAddressEndOfRange), and it matches any source address in that range 💜
If no value is given for this property, the filter doesn't consider HdrSrcAddress when picking packets, so HdrSrcAddress matches all values 🌸
6.19.3. The Property HdrSrcAddressEndOfRange 🏁
this is an OctetString, sized by HdrIpVersion, and it's the end of a range of source IP addresses (inclusive), where the start is the HdrSrcAddress value 🎀
If no value is given for HdrSrcAddress, then this property also MUST NOT be provided. If a value is given for this property, then HdrSrcMask MUST NOT be provided.
6.19.4. The Property HdrSrcMask 🎭
this is an OctetString, sized by HdrIpVersion, and it's the mask used to compare the source address in the IP header with the value in HdrSrcAddress 🔍
If no value is given for this property, the filter doesn't consider HdrSrcMask when picking packets. That means the HdrSrcAddress value (or the source address range) has to match the packet's source address exactly 💅 If a value is given for this property, then HdrSrcAddressEndOfRange MUST NOT be provided.
6.19.5. The Property HdrDestAddress 📬
this is an OctetString, sized by HdrIpVersion, and it represents a destination IP address 🦋 If there's no HdrDestAddressEndOfRange value, this is compared to the destination address in the IP header, with the HdrDestMask applied first. (Note that the mask is ANDed with the address.) If there is a HdrDestAddressEndOfRange value, then this one is the start of the range (so HdrDestAddress is lower than HdrDestAddressEndOfRange), and it matches any destination address in that range 🌈
If no value is given for this property, the filter doesn't consider HdrDestAddress when picking packets, so HdrDestAddress matches all values ✨
6.19.6. The Property HdrDestAddressEndOfRange 🏳️🌈
this is an OctetString, sized by HdrIpVersion, and it's the end of a range of destination IP addresses (inclusive), where the start is the HdrDestAddress value 💖
If no value is given for HdrDestAddress, then this property also MUST NOT be provided. If a value is given for this property, then HdrDestMask MUST NOT be provided.
6.19.7. The Property HdrDestMask 🧩
this is an OctetString, sized by HdrIpVersion, and it's the mask used to compare the destination address in the IP header with the value in HdrDestAddress 🌷
If no value is given for this property, the filter doesn't consider HdrDestMask when picking packets. So the HdrDestAddress value (or the destination address range) must match the packet's destination address exactly 🙈 If a value is given for this property, then HdrDestAddressEndOfRange MUST NOT be provided. 💅
6.19.8. The Property HdrProtocolID 🦋
okay so HdrProtocolID is an 8-bit unsigned integer that tells you which IP protocol type you're dealing with 💅 Its value gets compared to the Protocol field in the IP header, bestie.
If you don't give it a value, the filter just ignores HdrProtocolID when picking packets. So it matches for all values ✨
6.19.9. The Property HdrSrcPortStart 🌸
This one is a 16-bit unsigned integer, and it's the bottom end of a range of UDP or TCP source ports 🎀 The top end lives in the HdrSrcPortEnd property. The value of HdrSrcPortStart MUST be no greater than the value of HdrSrcPortEnd, no cap 🧢 And if both are equal, that's just one single port being targeted.
A source port filter checks whether the source port in the IP header lands somewhere in the range from HdrSrcPortStart to HdrSrcPortEnd. Both endpoints count too, so they're included 💖
If you leave this property out, the filter doesn't look at HdrSrcPortStart when picking packets. That means there's no lower bound on the source port values, which is very giving "anything goes" energy 🦋
6.19.10. The Property HdrSrcPortEnd 🌈
HdrSrcPortEnd is also a 16-bit unsigned integer, but this time it's the top end of a range of UDP or TCP source ports 👑 The bottom end is the HdrSrcPortStart property. The value of HdrSrcPortEnd MUST be no less than the value of HdrSrcPortStart. Again, equal values mean one single port ✨
The source port filter test is the same as before: it checks whether the source port in the IP header falls between HdrSrcPortStart and HdrSrcPortEnd, and both endpoints are included 🫶
If there's no value for this property, the filter doesn't consider HdrSrcPortEnd when selecting packets. So there's no upper bound on the source port values 🌸
6.19.11. The Property HdrDestPortStart 🎀
This is a 16-bit unsigned integer that represents the lower end of a range of UDP or TCP destination ports 🧚 The upper end is the HdrDestPortEnd property. The value of HdrDestPortStart MUST be no greater than the value of HdrDestPortEnd. Equal values give you a single port, as usual 💜
A destination port filter checks whether the destination port in the IP header falls within the range from HdrDestPortStart to HdrDestPortEnd. Both endpoints are included, so it's a whole vibe 🌈
If you don't provide a value, the filter ignores HdrDestPortStart when choosing packets. That means there's no lower bound on the destination port values 🍓
6.19.12. The Property HdrDestPortEnd 🦄
This one's a 16-bit unsigned integer too, and it's the upper end of a range of UDP or TCP destination ports 💅 The lower end is HdrDestPortStart. The value of HdrDestPortEnd MUST be no less than the value of HdrDestPortStart. Equal values mean a single port, obviously 🙈
The destination port filter test is the same: the destination port in the IP header has to fall between HdrDestPortStart and HdrDestPortEnd, with both endpoints included 💖
If no value is given, the filter doesn't consider HdrDestPortEnd when selecting packets, so there's no upper bound on the destination port values ✨
6.19.13. The Property HdrDSCP 🍓
HdrDSCP is defined as an array of uint8's, and it's restricted to the range 0..63 🌸 DSCPs are discrete code points with no inherent structure, so there's no meaningful relationship between one DSCP and another. That's why this property has no way to specify a range of DSCPs 🙃
Instead, you can list individual DSCPs, and they get ORed together to form a filter. The array syntax is what makes that possible 🎀
If no value is provided, the filter doesn't look at HdrDSCP when selecting packets. So HdrDSCP matches for all values 💜
6.19.14. The Property HdrFlowLabel 🧚
The 20-bit Flow Label field in the IPv6 header is something a source can use to label sequences of packets that need special handling from IPv6 devices, like non-default quality of service or 'real-time' service ⭐ This property is an octet string of size 3, which is 24 bits. The 20-bit Flow Label sits in the rightmost 20 bits, and it's padded on the left with b'0000' 🫶
If no value is given for this property, the filter doesn't consider HdrFlowLabel when picking packets. So HdrFlowLabel matches for all values 🌈
6.20. The Class "8021Filter" 💜
This concrete class lets you express 802.1.source and destination MAC addresses, along with the 802.1 protocol ID, priority, and VLAN identifier fields, all in a single object 🦋
Here's the class definition:
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,
8021HDRVLANID6.20.1. The Property 8021HdrSrcMACAddr 🌸
This is an OctetString of size 6, representing a 48-bit source MAC address in canonical format 🎀 Its value gets compared to the SourceAddress field in the MAC header, and the mask from the 8021HdrSrcMACMask property applies to that comparison 💅
If no value is provided, the filter doesn't consider 8021HdrSrcMACAddr when selecting packets. So it matches for all values ✨
6.20.2. The Property 8021HdrSrcMACMask 🍓
This is an OctetString of size 6, representing a 48-bit mask. The mask is used when comparing the SourceAddress field in the MAC header with the value in the 8021HdrSrcMACAddr property 🧚
If no value is given, the filter doesn't consider 8021HdrSrcMACMask when selecting packets. In that case, the value of 8021HdrSrcMACAddr has to match the source MAC address in the packet exactly 🔥
6.20.3. The Property 8021HdrDestMACAddr 🦋
This is an OctetString of size 6, representing a 48-bit destination MAC address in canonical format 💖 Its value is compared to the DestinationAddress field in the MAC header, with the mask from the 8021HdrDestMACMask property applied 🫶
If no value is provided, the filter doesn't consider 8021HdrDestMACAddr when choosing packets. So it matches for all values 🌈
6.20.4. The Property 8021HdrDestMACMask 🌟
This is an OctetString of size 6, representing a 48-bit mask. It's used when comparing the DestinationAddress field in the MAC header with the value in the 8021HdrDestMACAddr property 💜
If no value is given, the filter doesn't consider 8021HdrDestMACMask when selecting packets. Then the value of 8021HdrDestMACAddr has to match the destination MAC address in the packet exactly 👑
6.20.5. The Property 8021HdrProtocolID 🎀
This is a 16-bit unsigned integer, representing an Ethernet protocol type 🧚 Its value is compared to the Ethernet Type field in the 802.3 MAC header ⭐
If no value is provided, the filter doesn't consider 8021HdrProtocolID when selecting packets. So it matches for all values 🍓
6.20.6. The Property 8021HdrPriorityValue 🌸
This is an 8-bit unsigned integer, representing an 802.1Q priority 💅 Its value is compared to the Priority field in the 802.1Q header. Since that Priority field is only 3 bits, the values for this property are limited to the range 0..7 🫶
If no value is provided, the filter doesn't consider 8021HdrPriorityValue when selecting packets. So it matches for all values 🌈
6.20.7. The Property 8021HdrVLANID 💖
This is a 32-bit unsigned integer, representing an 802.1Q VLAN Identifier 🦄 Its value is compared to the VLAN ID field in the 802.1Q header. Since that VLAN ID field is 12 bits, the values are limited to the range 0..4095 🌙
If no value is provided, the filter doesn't consider 8021HdrVLANID when selecting packets. So it matches for all values ✨
6.21. The Class FilterList 🌈
This is a concrete class that aggregates instances of (subclasses of) FilterEntryBase through the aggregation EntriesInFilterList. You can mix different types of filters into one FilterList. For example, you could combine packet header filters (represented by the IpHeadersFilter class) with security filters (represented by subclasses of FilterEntryBase defined by IPsec) 🔥
The aggregation property EntriesInFilterList.EntrySequence is always set to 0. That tells you the aggregated filter entries are ANDed together to form a selector for a class of traffic 💅
Here's the class definition:
NAME FilterList
DESCRIPTION A concrete class representing
the aggregation of multiple filters.
DERIVED FROM LogicalElement
TYPE Concrete
PROPERTIES Direction6.21.1. The Property Direction 🦋
This is a 16-bit unsigned integer enumeration, representing the direction of the traffic flow the FilterList applies to 🎀 The defined enumeration values are:
- NotApplicable(0)
- Input(1)
- Output(2)
- Both(3) - This value means the direction doesn't matter. For example, you'd use it to filter on a source subnet whether the flow is inbound or outbound 💜
- Mirrored(4) - This value also applies to both inbound and outbound flow processing, but the filter criteria are applied asymmetrically to traffic in both directions. It reverses the source and destination criteria, instead of treating them as equal the way "Both" does. The match conditions in the aggregated FilterEntryBase subclass instances are defined from the perspective of outbound flows, and they're applied to inbound flows too by reversing the source and destination criteria. For example, take a FilterList with 3 filter entries that specify destination port = 80, and source and destination addresses of a and b, respectively. For the outbound direction, the filter entries match exactly as specified. 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" 💖
Okay so PolicySetComponent is a brand-new aggregation class 🎀, and its whole job is to gather up PolicySet subclasses (PolicyGroups and PolicyRules) into neat, coherent sets of policies. Main character energy ✨
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]]
PriorityThe Priority property is unchanged from how it was defined in [PCIM] 🧚, so nothing new to learn there.
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 07.2. Deprecate PCIM's Aggregation "PolicyGroupInPolicyGroup" 🥀
The new PolicySetComponent aggregation now handles PolicyGroups being aggregated by a higher-level PolicyGroup, all by itself 💅. So PolicyGroupInPolicyGroup isn't needed anymore and can be deprecated. Bye bye 👋
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" 🌸
Same vibe as the last one 🫶. PolicySetComponent now does the job of aggregating PolicyRules into a PolicyGroup directly, so PolicyRuleInPolicyGroup is redundant and can be deprecated.
NAME PolicyRuleInPolicyGroup
DEPRECATED FOR PolicySetComponent
DESCRIPTION A class representing the aggregation of PolicyRules
by a PolicyGroup.
DERIVED FROM PolicyComponent
ABSTRACT FALSE
PROPERTIES GroupComponent[ref PolicyGroup[0..n]]
PartComponent[ref PolicyRule[0..n]]7.4. The Abstract Association "PolicySetInSystem" 🦋
PolicySetInSystem is a new association that links a System to a PolicySet used in that system's administrative scope (think AdminDomain or ComputerSystem) 💜. The Priority property here gives a PolicySet its relative priority within that scope, but only when it isn't already 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]]
PrioritySo here's the deal with Priority: it tells you how to rank the referenced PolicySet against other PolicySet instances that aren't part of a common PolicySet, especially when several of them are applied to one managed resource 🔥. None of those have any other relative priority defined, so this is the one that counts.
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 07.5. Update PCIM's Weak Association "PolicyGroupInSystem" 🍓
Even if a PolicyGroup is a component of another PolicySet, it's still defined within the scope of a System 🌈. This association connects a PolicyGroup to the System whose scope it lives in, and it's a subclass of the abstract PolicySetInSystem association. Here's how it's defined:
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 Antecedent reference comes from PolicySetInSystem, but here its cardinality is narrowed to [1..1] 💅. It points at the System that scopes one or more PolicyGroups. Because this is a weak association, that cardinality is always 1. In other words, every PolicyGroup is defined within the scope of exactly one System, no exceptions 🙅♀️.
The Dependent reference is also inherited from PolicySetInSystem, but it's been overridden to point at a PolicyGroup defined within a System's scope. Heads up: for any single instance of PolicyGroupInSystem, this property is single-valued, like every reference property. The [0..n] cardinality is about how many PolicyGroups a given System can have in its scope, which can be 0, 1, or more than one 🧚.
7.6. Update PCIM's Weak Association "PolicyRuleInSystem" 🎀
Same deal for PolicyRules 💖. Even if a PolicyRule is a component of another PolicySet, it's still defined within the scope of a System. This association links a PolicyRule to the System whose scope it's defined in, and it's a subclass of the abstract PolicySetInSystem association too. Here's the definition:
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 Antecedent reference is inherited from PolicySetInSystem, and its cardinality is restricted to [1..1] 🦋. It points at the System that scopes one or more PolicyRules. Since this is weak, that cardinality is always 1, so a PolicyRule is always defined within the scope of exactly one System.
The Dependent reference is inherited too, and overridden to point at a PolicyRule defined within a System's scope. For any single instance of PolicyRuleInSystem, this property is single-valued, and the [0..n] cardinality means a given System can have 0, 1, or more than one PolicyRules in its scope 🌸.
7.7. The Abstract Aggregation "PolicyConditionStructure" 🌈
PolicyConditionStructure is an abstract aggregation that collects PolicyConditions under one aggregating instance 💜. Here's its shape:
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
ConditionNegated7.8. Update PCIM's Aggregation "PolicyConditionInPolicyRule" 🍓
The PCIM aggregation PolicyConditionInPolicyRule got a glow-up ✨. It's now a subclass of the new abstract aggregation PolicyConditionStructure. That means GroupNumber and ConditionNegated are inherited now, instead of being spelled out explicitly like 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" 🔥
This is the second subclass of PolicyConditionStructure 👑. It handles compounding 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]]7.10. The Abstract Aggregation "PolicyActionStructure" 🧚
PolicyActionStructure is the abstract aggregation for PolicyActions, the same way PolicyConditionStructure works for conditions 🦋.
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]]
ActionOrderThe definition of the ActionOrder property lives in Section 7.8.3 of PCIM [1] 💜, so go check there if you want the full scoop.
7.11. Update PCIM's Aggregation "PolicyActionInPolicyRule" 💖
The PCIM aggregation PolicyActionInPolicyRule got updated too 🎀. It's now a subclass of the new abstract aggregation PolicyActionStructure, so ActionOrder is inherited now, not spelled out explicitly like 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" 👑
This is the second subclass of PolicyActionStructure 🌈. It's for compounding policy actions into a higher-level policy action, which is basically the action version of the condition one we just saw ✨.
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" 🎀
okay so a simple policy condition is basically an ordered triplet, {variable, operator, value} 💅 this aggregation is the link between a SimplePolicyCondition instance and one single PolicyVariable. the aggregation PolicyValueInSimplePolicyCondition does the same job for a PolicyValue 🦋 and the Operator property of SimplePolicyCondition is the third piece of the triplet, the operator. iconic teamwork ✨
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, but it gets overridden so it points to a SimplePolicyCondition that holds exactly one PolicyVariable 🌸 for any one instance of this aggregation, that property is single-valued. the [0..n] cardinality just means a SimplePolicyCondition can be surrounded by 0, 1, or more objects, and any given policy variable object can show up in 0, 1, or more SimplePolicyCondition objects 💜
the reference property "PartComponent" is also inherited from PolicyComponent and overridden, this time to point to a PolicyVariable defined within the scope of a SimplePolicyCondition 🧚 again, for any one instance of this association class, the property (like all reference properties) is single-valued. the [1..1] cardinality means a SimplePolicyCondition has to have exactly one policy variable defined in its scope, or it isn't meaningful. no notes, that's just how it works 🙈
7.14. The Aggregation "PolicyValueInSimplePolicyCondition" 🌈
same energy as 7.13, just swapped 🔁 a simple policy condition is an ordered triplet {variable, operator, value}, and this aggregation links a SimplePolicyCondition instance to one single PolicyValue. the aggregation PolicyVariableInSimplePolicyCondition links that same SimplePolicyCondition to a single PolicyVariable. and the Operator property of SimplePolicyCondition is still 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] ]"GroupComponent" is inherited from PolicyComponent and overridden to become an object reference to a SimplePolicyCondition that contains exactly one PolicyValue ✨ for one instance of this aggregation, it's single-valued. the [0..n] cardinality means there could be 0, 1, or more SimplePolicyCondition objects that contain any given policy value object 🦋
"PartComponent" is inherited from PolicyComponent too, and overridden to point to a PolicyValue defined within the scope of a SimplePolicyCondition 🎀 for any one instance of this association class, the property (like all reference properties) is single-valued. the [1..1] cardinality says a SimplePolicyCondition has to have exactly one policy value defined in its scope to be meaningful 💅
7.15. The Aggregation "PolicyVariableInSimplePolicyAction" 🌸
a simple policy action is a pair, {variable, value} 🧚 this aggregation is the link between a SimplePolicyAction instance and one single PolicyVariable. the aggregation PolicyValueInSimplePolicyAction links that SimplePolicyAction to a single PolicyValue. it's giving two-part harmony 🫶
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] ]"GroupComponent" is inherited from PolicyComponent and overridden to be an object reference to a SimplePolicyAction that contains exactly one PolicyVariable 👑 for any single instance of this aggregation class, it's single-valued. the [0..n] cardinality means a SimplePolicyAction can hold 0, 1, or more objects, and any given policy variable object can be inside 0, 1, or more SimplePolicyAction objects 💜
"PartComponent" is inherited from PolicyComponent and overridden to be an object reference to a PolicyVariable defined within the scope of a SimplePolicyAction ✨ for any single instance of the association class, this property (like all reference properties) is single-valued. the [1..1] cardinality means a SimplePolicyAction must have exactly one policy variable in its scope in order to be meaningful 🙈
7.16. The Aggregation "PolicyValueInSimplePolicyAction" 🍓
a simple policy action is a pair, {variable, value}. this aggregation links a SimplePolicyAction instance to one single PolicyValue, and the aggregation PolicyVariableInSimplePolicyAction links that SimplePolicyAction to a single PolicyVariable. the pair stays together, bestie 🫶
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] ]"GroupComponent" is inherited from PolicyComponent and overridden to become an object reference to a SimplePolicyAction that contains exactly one PolicyValue 🔥 for any single instance of the aggregation class, this property is single-valued. the [0..n] cardinality means there may be 0, 1, or more SimplePolicyAction objects containing any given policy value object 🌈
"PartComponent" is inherited from PolicyComponent and overridden to be an object reference to a PolicyValue defined within the scope of a SimplePolicyAction 🦋 for any single instance of the association class, this property (like all reference properties) is single-valued. the [1..1] cardinality means a SimplePolicyAction has to have exactly one policy value in its scope to be meaningful ✨
7.17. The Association "ReusablePolicy" 🧚
okay the association ReusablePolicy is the thing that lets you put any subclass of the abstract class "Policy" inside a ReusablePolicyContainer 📦💖 main character energy for reusable stuff 👑
NAME ReusablePolicy
DESCRIPTION A class representing the inclusion of a reusable
policy element in a ReusablePolicyContainer.
Reusable elements may be PolicyGroups, PolicyRules,
PolicyConditions, PolicyActions, PolicyVariables,
PolicyValues, or instances of any other subclasses
of the abstract class Policy.
DERIVED FROM PolicyInSystem
ABSTRACT FALSE
PROPERTIES Antecedent[ref ReusablePolicyContainer[0..1]]7.18. Deprecate PCIM's "PolicyConditionInPolicyRepository" 💀
this one's getting deprecated, so the ReusablePolicy association is the replacement for it 🙈 it was a class representing the inclusion of a reusable PolicyCondition in a PolicyRepository 🌸
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" 💀
same deal as 7.18, just for actions 🧚 this class is deprecated for ReusablePolicy, and it used to represent the inclusion of a reusable PolicyAction in a PolicyRepository 🥀
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, and it models the set of expected values for that PolicyVariable 🎀 so a variable can be constrained to only be bound-to/assigned a set of allowed values. example time: say you're modeling an enumerated source port variable. you make an instance of the PolicySourcePortVariable class and link it to the set of values (integers) that represent the allowed enumeration, using an appropriate number of instances of the ExpectedPolicyValuesForVariable association 🍓
ngl the cool part is that one variable can be constrained by any number of values, and one value can constrain any number of variables. that's the n-to-m cardinality of the association, and it's literally giving flexibility 🌈
the purpose of this association is to help validate simple policy conditions and simple policy actions before they get deployed to an enforcement point 🛡️ this association, and the PolicyValue object it points 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, iykyk 🫶
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, but its type and cardinality get overridden to give it the semantics of a variable optionally having value constraints 💖 the [0..n] cardinality means any number of variables can 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 a particular PolicyVariable can have ✨ the [0..n] cardinality means a given policy variable may have 0, 1, or more than one PolicyValues defined to model the set(s) of values it can take 💜
7.21. The Aggregation "ContainedDomain" 🏰
the aggregation ContainedDomain lets you nest one ReusablePolicyContainer inside another one 🪆 it's defined at the level of ReusablePolicyContainer's superclass, AdminDomain, so it isn't just for Core Policy and works for other areas too 🌍
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]]7.22. Deprecate PCIM's "PolicyRepositoryInPolicyRepository" 💅
okay so this one is getting retired, bestie 🥺 it's deprecated for ContainedDomain, which is giving "new and improved" energy ✨ here's the old definition, still iconic in its own way:
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 one is a specialization of the Component aggregation, and its whole job is to define a set of filter entries (subclasses of FilterEntryBase) that get aggregated by a FilterList 🎀
the cardinalities on the aggregation itself are 0..1 on the FilterList end and 0..n on the FilterEntryBase end. so 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 through this aggregation. no cap, that's the only door in 🚪
here's the class definition:
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],
EntrySequence7.23.1. The Reference GroupComponent 💖
this property gets overridden here so it's an object reference to a FilterList object, not the more generic ManagedSystemElement from its superclass. it also tightens the cardinality of the aggregate to 0..1 instead of the more generic 0-or-more. the vibe is that a filter entry always lives inside at most one FilterList, and that's the whole point 💅
7.23.2. The Reference PartComponent ✨
same glow-up here: it's overridden to be an object reference to a FilterEntryBase object instead of a generic ManagedSystemElement. each one is a single filter entry, and a bunch of them can be aggregated together to form the FilterList 🦋
7.23.3. The Property EntrySequence 🌸
this is an unsigned 16-bit integer that tells you where the filter entry sits in order relative to all the others in the FilterList. the default value '0' means order doesn't matter, because the entries in that FilterList are ANDed together 🫶
7.24. The Aggregation "ElementInPolicyRoleCollection" 🍓
this aggregation is how we link ManagedElements to a PolicyRoleCollection, which represents a role those ManagedElements play. think of it as the "these are our girlies and this is their role" aggregation 👑
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, and this weak association links it to the System whose scope it lives in 🫧
when you associate a PolicyRoleCollection with a System, it should be done consistently with the system that scopes the policy rules and groups applied to the resources in that collection. so a PolicyRoleCollection goes with the same system as the applicable PolicyRules and/or PolicyGroups, or with a System higher up in the tree formed by the SystemComponent association. main character energy for the whole hierarchy 🌳
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 it's overridden to be an object reference to a System, with its cardinality restricted to [1..1]. it's the System that gives scope to one or more PolicyRoleCollections. since this is a weak association, that cardinality is always 1, which means a PolicyRoleCollection is always defined within the scope of exactly one System. one parent, zero drama 💅
the reference property Dependent is inherited from Dependency, and it's overridden to be an object reference to a PolicyRoleCollection defined within the scope of a System. for any single instance of the association class PolicyRoleCollectionInSystem, this property (like all Reference properties) is single-valued. the [0..n] cardinality is about the System side: a given System may have 0, 1, or more than one PolicyRoleCollections defined within its scope 🎀
8. Intellectual Property 🔐
the IETF takes no position on 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 on whether any license under those rights might or might not be available. it also doesn't represent that it has made any effort to identify any such rights. info about the IETF's procedures for rights in standards-track and standards-related documentation can be found in BCP-11 📚
copies of claims of rights made available for publication, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this specification to use such proprietary rights 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 send that info to the IETF Executive Director.
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 those documents created the extensions to PCIM, and asked the questions about PCIM, that are reflected in PCIMe. legends, honestly 🙌
10. Contributors 💜
this document includes text written by a number of authors (including the editor), which the editor then merged. 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
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.com11. Security Considerations 🔒
okay, this part is serious bestie, so listen up 🚨 the Policy Core Information Model (PCIM) [1] describes the general security considerations for the general core policy model. the extensions defined in this document do not introduce any additional considerations related to security. so the security story lives in PCIM, and PCIMe doesn't add any new plot twists 🕵️♀️
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.
[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.comFull Copyright Statement ✨
Okay bestie, time for the legal bit, and yes, it's a whole thing 💅 Copyright (C) The Internet Society (2003). All Rights Reserved. 🎀
This document and translations of it may be copied and handed out to others. Derivative works that comment on or explain it, or help people implement it, may be written, copied, published, and distributed, in whole or in part, with no real restrictions 🦋 as long as the copyright notice and this paragraph are included on every copy and every derivative work.
BUT the document itself can't be modified in any way 🙅 That means you can't remove the copyright notice, and you can't remove the references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process must be followed, or when it's being translated into languages other than English.
The permissions above are perpetual, meaning they're forever 💜 The Internet Society or its successors or assigns will not take them back.
And the disclaimer, which is serious: this document and the information in it are provided "AS IS" 🫶 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED. That includes, but isn't limited to, any warranty that using the information here won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose. Nobody is promising anything, so keep that in mind 😭
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you to the Internet Society for keeping the RFC Editor running. We love a supportive sponsor 🫶💖
📦 where this page comes from
- ietf: rfc3460 2003-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms