5/27/24, 7:21 AM
`
`ietf.org/rfc/rfc3198.txt
`
`Network Working Group
`Request for Comments: 3198
`Category: Informational
`
`A. Westerinen
`J. Schnizlein
`Cisco Systems
`J. Strassner
`Intelliden Corporation
`M. Scherling
`xCert
`B. Quinn
`Celox Networks
`S. Herzog
`PolicyConsulting
`A. Huynh
`Lucent Technologies
`M. Carlson
`Sun Microsystems
`J. Perry
`Network Appliance
`S. Waldbusser
`November 2001
`
`Terminology for Policy-Based Management
`
`Status of this Memo
`
` This memo provides information for the Internet community. It does
` not specify an Internet standard of any kind. Distribution of this
` memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (2001). All Rights Reserved.
`
`Abstract
`
` This document is a glossary of policy-related terms. It provides
` abbreviations, explanations, and recommendations for use of these
` terms. The document takes the approach and format of RFC 2828, which
` defines an Internet Security Glossary. The intent is to improve the
` comprehensibility and consistency of writing that deals with network
` policy, particularly Internet Standards documents (ISDs).
`
`Westerinen, et al.
`
`Informational
`
`[Page 1]
`
`RFC 3198
`
`Terminology for Policy-Based Management November 2001
`
`Table of Contents
`
`https://www.ietf.org/rfc/rfc3198.txt
`
`1/19
`
`1
`
`SAMSUNG 1044
`
`

`

`5/27/24, 7:21 AM
`ietf.org/rfc/rfc3198.txt
` 1. Introduction................................................... 2
` 2. Explanation of Paragraph Markings.............................. 3
` 3. Terms.......................................................... 3
` 4. Intellectual Property.......................................... 16
` 5. Acknowledgements............................................... 17
` 6. Security Considerations........................................ 17
` 7. References..................................................... 17
` 8. Authors' Addresses............................................. 19
` 9. Full Copyright Statement....................................... 21
`
`1. Introduction
`
` This document provides abbreviations, definitions, and explanations
` of terms related to network policy. All definitions are provided in
` Section 3, with the terms listed in alphabetical order.
`
` The intent is to improve the comprehensibility and consistency of
` Internet Standards documents (ISDs) -- i.e., RFCs, Internet-Drafts,
` and other material produced as part of the Internet Standards Process
` [RFC2026]. Benefits across the ISDs are well-stated in the
` Introduction to RFC 2828 [RFC2828]:
`
` o "Clear, Concise, and Easily Understood Documentation" - Requires
` that the set of terms and definitions be consistent, self-
` supporting and uniform across all ISDs.
`
` o Technical Excellence - Where all ISDs use terminology accurately,
` precisely, and unambiguously.
`
` o Prior Implementation and Testing - Requires that terms are used in
` their plainest form, that private and "made-up" terms are avoided
` in ISDs, and that new definitions are not created that conflict
` with established ones.
`
` o "Openness, Fairness, and Timeliness" - Where ISDs avoid terms that
` are proprietary or otherwise favor a particular vendor, or that
` create a bias toward a particular technology or mechanism.
`
` Common and/or controversial policy terms are defined. These terms
` are directly related and specific to network policy.
`
` Wherever possible, this document takes definitions from existing
` ISDs. It should be noted that:
`
` o Expired Internet-Drafts are not referenced, nor are their
` terminology and definitions used in this document.
`
`Westerinen, et al. Informational [Page 2]
`
`RFC 3198 Terminology for Policy-Based Management November 2001
`
` o Multiple definitions may exist across the ISDs. Each definition
` is listed, with its source.
`
`2. Explanation of Paragraph Markings
`
` Section 3 marks terms and definitions as follows:
`
` o Capitalization: Only terms that are proper nouns are capitalized.
`
` o Paragraph Marking: Definitions and explanations are stated in
` paragraphs that are marked as follows:
`
`https://www.ietf.org/rfc/rfc3198.txt
`
`2/19
`
`2
`
`

`

`5/27/24, 7:21 AM
`
`ietf.org/rfc/rfc3198.txt
`
` - "P" identifies basic policy-related terms.
`
` - "T" identifies various techniques to create or convey policy-
` related information in a network. For example, COPS and an
` "Information Model" are two techniques for communicating and
` describing policy-related data. SNMP and MIBs are another.
`
` - "A" identifies specific Work Groups and general "areas of use"
` of policy. For example, AAA and QoS are two "areas of use"
` where policy concepts are extremely important to their function
` and operation.
`
`3. Terms
`
` Note: In providing policy definitions, other "technology specific"
` terms (for example, related to Differentiated Services) may be used
` and referenced. These non-policy terms will not be defined in this
` document, and the reader is requested to go to the referenced ISD for
` additional detail.
`
` $ AAA
` See "Authentication, Authorization, Accounting".
`
` $ abstraction levels
` See "policy abstraction".
`
` $ action
` See "policy action".
`
` $ Authentication, Authorization, Accounting (AAA)
` (A) AAA deals with control, authentication, authorization and
` accounting of systems and environments based on policies set
` by the administrators and users of the systems. The use of
` policy may be implicit - as defined by RADIUS [RFC2138]. In
` RADIUS, a network access server sends dial-user credentials to
` an AAA server, and receives authentication that the user is
`
`Westerinen, et al. Informational [Page 3]
`
`RFC 3198 Terminology for Policy-Based Management November 2001
`
` who he/she claims, along with a set of attribute-value pairs
` authorizing various service features. Policy is implied in
` both the authentication, which can be restricted by time of
` day, number of sessions, calling number, etc., and the
` attribute-values authorized.
`
` $ CIM
` See "Common Information Model".
`
` $ Common Information Model (CIM)
` (T) An object-oriented information model published by the DMTF
` (Distributed Management Task Force) [DMTF]. It consists of a
` Specification detailing the abstract modeling constructs and
` principles of the Information Model, and a textual language
` definition to represent the Model. CIM's schemas are defined
` as a set of files, written in the language of the
` Specification, with graphical renderings using UML [UML].
` Sets of classes and associations represent CIM's Core and
` Common Models, defining an information model for the
` "enterprise" - addressing general concepts (in Core), and
`
`https://www.ietf.org/rfc/rfc3198.txt
`
`3/19
`
`3
`
`

`

`5/27/24, 7:21 AM
`ietf.org/rfc/rfc3198.txt
` systems, devices, users, software distribution, the physical
` environment, networks and policy (in the Common Models). (See
` also "information model".)
`
` $ Common Open Policy Service (COPS)
` (T) A simple query and response TCP-based protocol that can be
` used to exchange policy information between a Policy Decision
` Point (PDP) and its clients (Policy Enforcement Points, PEPs)
` [RFC2748]. The COPS protocol is used to provide for the
` outsourcing of policy decisions for RSVP [RFC2749]. Another
` usage is for the provisioning of policy [RFC3084]. (See also
` "Policy Decision Point" and "Policy Enforcement Point".)
`
` $ condition
` See "policy condition".
`
` $ configuration
` (P) "Configuration" can be defined from two perspectives:
` - The set of parameters in network elements and other systems
` that determine their function and operation. Some
` parameters are static, such as packet queue assignment and
` can be predefined and downloaded to a network element.
` Others are more dynamic, such as the actions taken by a
` network device upon the occurrence of some event. The
` distinction between static (predefined) "configuration" and
` the dynamic state of network elements blurs as setting
` parameters becomes more responsive, and signaling controls
` greater degrees of a network device's behavior.
`
`Westerinen, et al. Informational [Page 4]
`
`RFC 3198 Terminology for Policy-Based Management November 2001
`
` - A static setup of a network element, done before shipment
` to a customer and which cannot be modified by the customer.
` The first is the accepted usage in the Internet community.
`
` $ COPS
` See "Common Open Policy Service".
`
` $ data model
` (T) A mapping of the contents of an information model into a form
` that is specific to a particular type of data store or
` repository. A "data model" is basically the rendering of an
` information model according to a specific set of mechanisms
` for representing, organizing, storing and handling data. It
` has three parts [DecSupp]:
` - A collection of data structures such as lists, tables,
` relations, etc.
` - A collection of operations that can be applied to the
` structures such as retrieval, update, summation, etc.
` - A collection of integrity rules that define the legal
` states (set of values) or changes of state (operations on
` values).
` (See also "information model".)
`
` $ DEN
` See "Directory Enabled Networks".
`
` $ Differentiated Services (DS)
` (T) The IP header field, called the DS-field. In IPv4, it defines
` the layout of the ToS (Type of Service) octet; in IPv6, it is
`
`https://www.ietf.org/rfc/rfc3198.txt
`
`4/19
`
`4
`
`

`

`5/27/24, 7:21 AM
` the Traffic Class octet [RFC2474].
` (A) "Differentiated Services" is also an "area of use" for QoS
` policies. It requires policy to define the correspondence
` between codepoints in the packet's DS-field and individual
` per-hop behaviors (to achieve a specified per-domain
` behavior). In addition, policy can be used to specify the
` routing of packets based on various classification criteria.
` (See also "Quality of Service" and "filter".)
`
`ietf.org/rfc/rfc3198.txt
`
` $ diffserv
` See "Differentiated Services".
`
` $ Directory Enabled Networks (DEN)
` (T) A data model that is the LDAP mapping of CIM (the Common
` Information Model). Its goals are to enable the deployment
` and use of policy by starting with common service and user
` concepts (defined in the information model), specifying their
`
`Westerinen, et al. Informational [Page 5]
`
`RFC 3198 Terminology for Policy-Based Management November 2001
`
` mapping/storage in an LDAP-based repository, and using these
` concepts in vendor/device-independent policy rules [DMTF].
` (See also "Common Information Model" and "data model".)
`
` $ domain
` (P) A collection of elements and services, administered in a
` coordinated fashion. (See also "policy domain".)
`
` $ DS
` See "Differentiated Services".
`
` $ filter
` (T) A set of terms and/or criteria used for the purpose of
` separating or categorizing. This is accomplished via single-
` or multi-field matching of traffic header and/or payload data.
` "Filters" are often manipulated and used in network operation
` and policy. For example, packet filters specify the criteria
` for matching a pattern (for example, IP or 802 criteria) to
` distinguish separable classes of traffic.
`
` $ goal
` See "policy goal".
`
` $ information model
` (T) An abstraction and representation of the entities in a managed
` environment, their properties, attributes and operations, and
` the way that they relate to each other. It is independent of
` any specific repository, software usage, protocol, or
` platform.
`
` $ Management Information Base (MIB)
` (T) A collection of information that can be accessed via the
` Simple Network Management Protocol. Management information is
` defined in MIB modules using the rules contained in SNMP's
` Structure of Management Information (SMI) specifications
` [RFC2570]. Management information is an abstract concept, and
` definitions can be created for high level policy
` specifications, low level policy, as well as technology and
`
`https://www.ietf.org/rfc/rfc3198.txt
`
`5/19
`
`5
`
`

`

`5/27/24, 7:21 AM
`ietf.org/rfc/rfc3198.txt
` vendor specific configurations, status and statistics. (See
` also "Simple Network Management Protocol" and "Structure of
` Management Information".)
`
` $ MIB
` See "Management Information Base".
`
`Westerinen, et al. Informational [Page 6]
`
`RFC 3198 Terminology for Policy-Based Management November 2001
`
` $ MPLS
` See "Multiprotocol Label Switching". (Also, MPLS may refer to
` Multi-Protocol Lambda Switching in optical networks. But, this is
` unrelated to policy and not discussed further in this document.)
`
` $ Multiprotocol Label Switching (MPLS)
` (T) Integrates a label swapping and switching framework with
` network layer routing [RFC2702]. The basic idea involves
` assigning short fixed length labels to packets at the ingress
` to an MPLS cloud. Throughout the interior of the MPLS domain,
` the labels attached to packets are used to make forwarding
` decisions (usually without recourse to the original packet
` headers).
`
` $ outsourced policy
` (P) An execution model where a policy enforcement device issues a
` query to delegate a decision for a specific policy event to
` another component, external to it. For example, in RSVP, the
` arrival of a new RSVP message to a PEP requires a fast policy
` decision (not to delay the end-to-end setup). The PEP may use
` COPS-RSVP to send a query to the PDP, asking for a policy
` decision [RFC2205, RFC2748]. "Outsourced policy" is
` contrasted with "provisioned policy", but they are not
` mutually exclusive and operational systems may combine the
` two.
`
` $ PCIM
` See "Policy Core Information Model".
`
` $ PDP
` See "Policy Decision Point".
`
` $ PEP
` See "Policy Enforcement Point".
`
` $ PIB
` See "Policy Information Base".
`
` $ policy
` (P) "Policy" can be defined from two perspectives:
` - A definite goal, course or method of action to guide and
` determine present and future decisions. "Policies" are
` implemented or executed within a particular context (such
` as policies defined within a business unit).
` - Policies as a set of rules to administer, manage, and
` control access to network resources [RFC3060].
`
`https://www.ietf.org/rfc/rfc3198.txt
`
`6/19
`
`6
`
`

`

`5/27/24, 7:21 AM
`
`ietf.org/rfc/rfc3198.txt
`
`Westerinen, et al. Informational [Page 7]
`
`RFC 3198 Terminology for Policy-Based Management November 2001
`
` Note that these two views are not contradictory since
` individual rules may be defined in support of business goals.
` (See also "policy goal", "policy abstraction" and "policy
` rule".)
`
` $ policy abstraction
` (P) Policy can be represented at different levels, ranging from
` business goals to device-specific configuration parameters.
` Translation between different levels of "abstraction" may
` require information other than policy, such as network and
` host parameter configuration and capabilities. Various
` documents and implementations may specify explicit levels of
` abstraction. However, these do not necessarily correspond to
` distinct processing entities or the complete set of levels in
` all environments. (See also "configuration" and "policy
` translation".)
`
` $ policy action
` (P) Definition of what is to be done to enforce a policy rule,
` when the conditions of the rule are met. Policy actions may
` result in the execution of one or more operations to affect
` and/or configure network traffic and network resources.
` - In [RFC3060], a rule's actions may be ordered.
`
` $ policy condition
` (P) A representation of the necessary state and/or prerequisites
` that define whether a policy rule's actions should be
` performed. This representation need not be completely
` specified, but may be implicitly provided in an implementation
` or protocol. When the policy condition(s) associated with a
` policy rule evaluate to TRUE, then (subject to other
` considerations such as rule priorities and decision
` strategies) the rule should be enforced.
` (T) In [RFC3060], a rule's conditions can be expressed as either
` an ORed set of ANDed sets of statements (disjunctive normal
` form), or an ANDed set of ORed sets of statements (conjunctive
` normal form). Individual condition statements can also be
` negated.
`
` $ policy conflict
` (P) Occurs when the actions of two rules (that are both satisfied
` simultaneously) contradict each other. The entity
` implementing the policy would not be able to determine which
` action to perform. The implementers of policy systems must
` provide conflict detection and avoidance or resolution
` mechanisms to prevent this situation. "Policy conflict" is
` contrasted with "policy error".
`
`Westerinen, et al. Informational [Page 8]
`
`RFC 3198 Terminology for Policy-Based Management November 2001
`
`https://www.ietf.org/rfc/rfc3198.txt
`
`7/19
`
`7
`
`

`

`5/27/24, 7:21 AM
` $ policy conversion
` See "policy translation".
`
`ietf.org/rfc/rfc3198.txt
`
` $ Policy Core Information Model (PCIM) [RFC3060]
` (T) An information model describing the basic concepts of policy
` groups, rules, conditions, actions, repositories and their
` relationships. This model is described as a "core" model
` since it cannot be applied without domain-specific extensions
` (for example, extensions for QoS or IPsec). PCIM is "core"
` with respect to the area of policy. However, it is a "Common
` Model," with respect to CIM - in that it extends the basic CIM
` concepts for policy. (See also "Common Information Model".)
`
` $ policy decision
` (P) Two perspectives of "policy decision" exist:
` - A "process" perspective that deals with the evaluation of a
` policy rule's conditions
` - A "result" perspective that deals with the actions for
` enforcement, when the conditions of a policy rule are TRUE
`
` $ Policy Decision Point (PDP)
` (P) A logical entity that makes policy decisions for itself or for
` other network elements that request such decisions [RFC2753].
` (See also "policy decision".)
`
` $ policy domain
` (P) A collection of elements and services, and/or a portion of an
` Internet over which a common and consistent set of policies
` are administered in a coordinated fashion [RFC2474]. This
` definition of a policy domain does not preclude multiple
` sources of policy creation within an organization, but does
` require that the resultant policies be coordinated.
` - Policies defined in the context of one domain may need to
` be communicated or negotiated outside of that domain. (See
` also "policy negotiation".)
`
` $ policy enforcement
` (P) The execution of a policy decision.
`
` $ Policy Enforcement Point (PEP)
` (P) A logical entity that enforces policy decisions [RFC2753].
` (See also "policy enforcement".)
`
` $ policy error
` (P) "Policy errors" occur when attempts to enforce policy actions
` fail, whether due to temporary state or permanent mismatch
` between the policy actions and the device enforcement
` capabilities. This is contrasted with "policy conflict".
`
`Westerinen, et al. Informational [Page 9]
`
`RFC 3198 Terminology for Policy-Based Management November 2001
`
` $ policy goal
` (P) Goals are the business objectives or desired state intended to
` be maintained by a policy system. As the highest level of
` abstraction of policy, these goals are most directly described
` in business rather than technical terms. For example, a goal
` might state that a particular application operate on a network
` as though it had its own dedicated network, despite using a
` shared infrastructure. 'Policy goals' can include the
` objectives of a service level agreement, as well as the
`
`https://www.ietf.org/rfc/rfc3198.txt
`
`8/19
`
`8
`
`

`

`5/27/24, 7:21 AM
`ietf.org/rfc/rfc3198.txt
` assignment of resources to applications or individuals. A
` policy system may be created that automatically strives to
` achieve a goal through feedback regarding whether the goal
` (such as a service level) is being met.
`
` $ Policy Information Base (PIB)
` (T) Collections of related PRovisioning Classes (PRCs), defined as
` a module. (See also "PRovisioning Class".)
`
` $ policy mapping
` See "policy translation".
`
` $ policy negotiation
` (P) Exposing the desired or appropriate part of a policy to
` another domain. This is necessary to support partial
` interconnection between domains, which are operating with
` different sets of policies.
`
` $ policy repository
` (P) "Policy repository" can be defined from three perspectives:
` - A specific data store that holds policy rules, their
` conditions and actions, and related policy data. A
` database or directory would be an example of such a store.
` - A logical container representing the administrative scope
` and naming of policy rules, their conditions and actions,
` and related policy data. A "QoS policy" domain would be an
` example of such a container.
` - In [RFC3060], a more restrictive definition than the prior
` one exists. A PolicyRepository is a model abstraction
` representing an administratively defined, logical container
` for reusable policy elements.
`
` $ policy request
` (P) A message requesting a policy-related service. This may refer
` to a request to retrieve a specific set of policy rules, to
` determine the actions to enforce, or other policy requests.
` When sent by a PEP to a PDP, it is more accurately qualified
` as a "policy decision request" [RFC2753]. (See also "policy
` decision".)
`
`Westerinen, et al. Informational [Page 10]
`
`RFC 3198 Terminology for Policy-Based Management November 2001
`
` $ policy rule
` (P) A basic building block of a policy-based system. It is the
` binding of a set of actions to a set of conditions - where the
` conditions are evaluated to determine whether the actions are
` performed [RFC3060].
`
` $ policy server
` (P) A marketing term whose definition is imprecise. Originally,
` [RFC2753] referenced a "policy server". As the RFC evolved,
` this term became more precise and known as the Policy Decision
` Point (PDP). Today, the term is used in marketing and other
` literature to refer specifically to a PDP, or for any entity
` that uses/services policy.
`
` $ policy translation
` (P) The transformation of a policy from a representation and/or
` level of abstraction, to another representation or level of
` abstraction. For example, it may be necessary to convert PIB
`
`https://www.ietf.org/rfc/rfc3198.txt
`
`9/19
`
`9
`
`

`

`5/27/24, 7:21 AM
`ietf.org/rfc/rfc3198.txt
` data to a command line format. In this "conversion," the
` translation to the new representation is likely to require a
` change in the level of abstraction (becoming more or less
` specific). Although these are logically distinct tasks, they
` are (in most cases) blurred in the act of
` translating/converting/mapping. Therefore, this is also known
` as "policy conversion" or "policy mapping".
`
` $ PolicyGroup
` (T) An abstraction in the Policy Core Information Model [RFC3060].
` It is a class representing a container, aggregating either
` policy rules or other policy groups. It allows the grouping
` of rules into a Policy, and the refinement of high-level
` Policies to lower-level or different (i.e., converted or
` translated) peer groups.
`
` $ PRC
` See "PRovisioning Class".
`
` $ PRI
` See "PRovisioning Instance".
`
` $ provisioned policy
` (P) An execution model where network elements are pre-configured,
` based on policy, prior to processing events. Configuration is
` pushed to the network device, e.g., based on time of day or at
` initial booting of the device. The focus of this model is on
` the distribution of configuration information, and is
` exemplified by Differentiated Services [RFC2475]. Based on
` events received, devices use downloaded (pre-provisioned)
`
`Westerinen, et al. Informational [Page 11]
`
`RFC 3198 Terminology for Policy-Based Management November 2001
`
` mechanisms to implement policy. "Provisioned policy" is
` contrasted with "outsourced policy".
`
` $ PRovisioning Class (PRC)
` (T) An ordered set of attributes representing a type of policy
` data. PRCs are defined in PIB modules (encoded using SPPI)
` and registered in the Object Identifier tree. Instances of
` each PRC are organized in tables, similar to conceptual tables
` in SMIv2. (See also "Structure of Policy Provisioning
` Information" and "Policy Information Base".)
` The acronym, PRC, has evolved from "policy rule class" to
` "provisioning class". The reason for the change is that a
` discrepancy existed between the use of the words, "policy
` rule" in the PRC context versus other uses in PCIM and the
` industry. In the latter, rules are If/Then statements - a
` binding of conditions to actions. PRCs are not "rules" by
` this definition, but the encoding of (network-wide)
` configuration information for a device.
`
` $ PRovisioning Instance (PRI)
` (T) An instantiation of a PRovisioning Class. (See also
` "PRovisioning Class".)
`
` $ QoS
` See "Quality of Service".
`
` $ Quality of Service (QoS)
`
`https://www.ietf.org/rfc/rfc3198.txt
`
`10/19
`
`10
`
`

`

`5/27/24, 7:21 AM
`ietf.org/rfc/rfc3198.txt
` (A) At a high level of abstraction, "Quality of Service" refers to
` the ability to deliver network services according to the
` parameters specified in a Service Level Agreement. "Quality"
` is characterized by service availability, delay, jitter,
` throughput and packet loss ratio. At a network resource
` level, "Quality of Service" refers to a set of capabilities
` that allow a service provider to prioritize traffic, control
` bandwidth, and network latency. There are two different
` approaches to "Quality of Service" on IP networks: Integrated
` Services [RFC1633], and Differentiated Service [RFC2475].
` Integrated Services require policy control over the creation
` of signaled reservations, which provide specific quantitative
` end-to-end behavior for a (set of) flow(s). In contrast,
` Differentiated Services require policy to define the
` correspondence between codepoints in the packet's DS-field and
` individual per-hop behaviors (to achieve a specified per-
` domain behavior). A maximum of 64 per-hop behaviors limit the
` number of classes of service traffic that can be marked at any
` point in a domain. These classes of service signal the
` treatment of the packets with respect to various QoS aspects,
` such as flow priority and packet drop precedence. In
`
`Westerinen, et al. Informational [Page 12]
`
`RFC 3198 Terminology for Policy-Based Management November 2001
`
` addition, policy can be used to specify the routing of packets
` based on various classification criteria. Policy controls the
` set of configuration parameters and routing for each class in
` Differentiated Service, and the admission conditions for
` reservations in Integrated Services. (See also "policy
` abstraction" and "Service Level Agreement".)
`
` $ Resource reSerVation Protocol (RSVP)
` (T) A setup protocol designed for an Integrated Services Internet,
` to reserve network resources for a path [RFC2205]. And, a
` signaling mechanism for managing application traffic's QoS in
` a Differentiated Service network.
`
` $ role
` (P) "Role" is defined from three perspectives:
` - A business position or function, to which people and
` logical entities are assigned [X.500]
` - The labeled endpoints of a UML (Unified Modeling Language)
` association. Quoting from [UML], "When a class
` participates in an association, it has a specific role that
` it plays in that relationship; a role is just the face the
` class at the near end of the association presents to the
` class at the other end of the association". The Policy
` Core Information Model [RFC3060] uses UML to depict its
` class hierarchy. Relationships/associations are significant
` in the model.
` - 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 [RFC3060].
` Only the third definition (roles as selectors of policy) is
` directly related to the management of network policy. However,
` the first definition (roles as business positions and
` functions) may be referenced in policy conditions and actions.
`
`https://www.ietf.org/rfc/rfc3198.txt
`
`11/19
`
`11
`
`

`

`ietf.org/rfc/rfc3198.txt
`
`5/27/24, 7:21 AM
` $ role combination
` (P) A lexicographically ordered set of roles that characterize
` managed elements and indicate the applicability of policy
` rules and PRovisioning Classes (PRCs). A policy system uses
` the set of roles reported by the managed element to determine
` the correct rules/PRCs to be sent for enforcement. That
` determination may examine all applicable policy rules
` identified by the role combination, its sub-combinations and
` the individual roles in the combination [RFC3060]. In the
` case of PRCs, a PRC must explicitly match the role combination
` of the managed element in order to be applicable and/or
` enforced. (The comparison is typically case-sensitive.) The
`
`Westerinen, et al. Informational [Page 13]
`
`RFC 3198 Terminology for Policy-Based Management November 2001
`
` final set of rules/PRCs for enforcement are defined by the
` policy system, as appropriate for the specified role
` combination of the managed element.
`
` $ RSVP
` See "Resource reSerVation Protocol".
`
` $ rule
`