RFC 3198

Terminology for Policy-Based Management

📅 published November 2001, from ietf

RFC 3198: Terminology for Policy-Based Management ✨

Okay bestie, this one is a glossary 📖💖 It's the policy vocab list that the whole Internet community is supposed to use so everyone's talking the same language. Here's the title-block tea 🫖

  • RFC number: 3198
  • Title: Terminology for Policy-Based Management
  • Category: Informational, so it's giving "here's some info" and not a standard 💅
  • Date: November 2001 🎀
  • Obsoletes / updates: the header doesn't list anything it obsoletes or updates 🙈
  • Authors:
    • A. Westerinen (Cisco Systems)
    • 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 (no affiliation listed)

Status of this Memo 📜

Quick legal-ish bit 🧾 This memo is here to give information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited, so share away 🦋

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

Abstract 💭

Bestie, this doc is a glossary of policy-related terms 🧠 It gives you abbreviations, explanations, and recommendations for using these terms. It's built the same way as RFC 2828, which defines an Internet Security Glossary, so it feels familiar. The whole goal is to make writing about network policy clearer and more consistent, especially in Internet Standards documents (ISDs) 📚✨

Table of Contents 🗂️

   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 doc gives you abbreviations, definitions, and explanations for terms related to network policy 💕 Every definition lives in Section 3, and they're listed alphabetically, so you can find things easily 🔍

The goal is to make Internet Standards documents (ISDs) more comprehensible and consistent 🫶 ISDs are RFCs, Internet-Drafts, and other material produced as part of the Internet Standards Process [RFC2026]. The Introduction to RFC 2828 [RFC2828] lays out the benefits really well, and they're literally the reason this glossary exists:

  • "Clear, Concise, and Easily Understood Documentation" - The set of terms and definitions has to be consistent, self-supporting, and uniform across all ISDs. Main character energy for clarity 👑
  • Technical Excellence - Every ISD uses terminology accurately, precisely, and unambiguously. No vibes-only definitions 🎯
  • Prior Implementation and Testing - Terms get used in their plainest form, private and "made-up" terms are avoided in ISDs, and new definitions can't conflict with established ones 🚫
  • "Openness, Fairness, and Timeliness" - ISDs avoid terms that are proprietary or that favor a particular vendor, and terms that create a bias toward a particular technology or mechanism 🌈

Common and/or controversial policy terms get defined here. They're all directly related to, and specific to, network policy 💅

Wherever possible, this document takes definitions from existing ISDs 📎 A couple of things to know:

  • Expired Internet-Drafts are not referenced, and their terminology and definitions are not used in this document 🙅‍♀️
  • Multiple definitions may exist across the ISDs. Each definition is listed, along with its source 🧾

2. Explanation of Paragraph Markings 🎀

Section 3 uses markers to tell you what kind of term you're looking at 🏷️ Here's how it works:

  • Capitalization: Only terms that are proper nouns get capitalized 🔠
  • Paragraph Marking: Definitions and explanations sit in paragraphs marked like this:
    • "P" marks basic policy-related terms 💜
    • "T" marks 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" marks 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: Policy definitions might use other "technology specific" terms too (for example, ones related to Differentiated Services). Those non-policy terms are not defined in this document, so the reader is requested to check the referenced ISD for more detail 📚

$ AAA See "Authentication, Authorization, Accounting".

$ abstraction levels See "policy abstraction".

$ action See "policy action".

$ Authentication, Authorization, Accounting (AAA) (A) AAA is all about control, authentication, authorization, and accounting of systems and environments, based on policies set by the administrators and users of those systems 🔐 Policy can be implicit here, as defined by RADIUS [RFC2138]. In RADIUS, a network access server sends dial-user credentials to an AAA server and gets back an authentication that the user is who they claim to be, plus a set of attribute-value pairs that authorize various service features. Policy is baked into both: the authentication can be restricted by time of day, number of sessions, calling number, etc., and the attribute-values that get 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 has a Specification that details the abstract modeling constructs and principles of the Information Model, plus a textual language definition for representing the Model. CIM's schemas are defined as a set of files, written in the language of the Specification, and they get graphical renderings using UML [UML]. Sets of classes and associations represent CIM's Core and Common Models. The Core covers general concepts, and the Common Models cover systems, devices, users, software distribution, the physical environment, networks, and policy, all defining an information model for the "enterprise" 🏢 (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] 🤝 COPS is used to outsource policy decisions for RSVP [RFC2749], and it's also used to provision policy [RFC3084]. (See also "Policy Decision Point" and "Policy Enforcement Point".)

$ condition See "policy condition".

$ configuration (P) "Configuration" can be defined from two perspectives, and both are valid vibes ✨

  • The set of parameters in network elements and other systems that determine their function and operation. Some parameters are static, like packet queue assignment, and can be predefined and downloaded to a network element. Others are more dynamic, like the actions a network device takes when some event occurs. The line between static (predefined) "configuration" and the dynamic state of network elements gets blurry as setting parameters becomes more responsive and signaling controls more of a network device's behavior 🌀
  • A static setup of a network element, done before shipment to a customer, that the customer cannot modify 🔒

The first one is the accepted usage in the Internet community, so that's the one you'll see most 💅

$ COPS See "Common Open Policy Service".

$ data model (T) A mapping of the contents of an information model into a form that's specific to a particular type of data store or repository 🗄️ Basically, a "data model" is an information model rendered 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's 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). Policy can also be used to specify how packets get routed based on various classification criteria 🗺️ (See also "Quality of Service" and "filter".)

$ 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 how they get mapped and stored 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) Okay so a filter is a set of terms and/or criteria used for separating or categorizing things 🧚. It works through single- or multi-field matching of traffic header and/or payload data. Filters get manipulated and used all the time in network operation and policy 💅. For example, packet filters specify the criteria for matching a pattern (for example, IP or 802 criteria) to tell apart 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 vendor specific configurations, status and statistics. (See also "Simple Network Management Protocol" and "Structure of Management Information".)

$ MIB

See "Management Information Base" 🫶.

$ 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) So this is an execution model where a policy enforcement device sends out a query to hand off a decision for a specific policy event to another component that lives outside of it 🫧. For example, in RSVP, when a new RSVP message shows up at a PEP it needs a fast policy decision (so the end-to-end setup doesn't get delayed). 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].

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

$ policy conversion

See "policy translation" 🎀.

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

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

$ 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. Bestie, that's the whole glossary ✨💅

$ policy translation 🦋 (P) okay so this is the transformation of a policy from one representation and/or level of abstraction to another representation or level of abstraction. For example, it may be necessary to convert PIB 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) bestie, this is an abstraction in the Policy Core Information Model [RFC3060]. It's a class representing a container, aggregating either policy rules or other policy groups. It lets you group rules into a Policy, and refine high-level Policies down to lower-level or different (i.e., converted or translated) peer groups ✨

$ PRC 🌸 See "PRovisioning Class".

$ PRI 🌸 See "PRovisioning Instance".

$ provisioned policy 🧚 (P) this is an execution model where network elements are pre-configured, based on policy, before they process events. Configuration gets pushed to the network device, e.g., based on time of day or at initial booting of the device. The focus is on distributing configuration information, and the classic example is Differentiated Services [RFC2475]. Based on events received, devices use downloaded (pre-provisioned) 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) 👑 (A) okay, at a high level of abstraction, "Quality of Service" means 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 let a service provider 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 limits 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 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, it's also 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 💅

$ 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 final set of rules/PRCs for enforcement is defined by the policy system, as appropriate for the specified role combination of the managed element 🧚

$ RSVP 🌸 See "Resource reSerVation Protocol".

$ rule 🍓 See "policy rule".

$ rule based engine 💜 (T) a rule based engine is able to evaluate policy condition(s) and trigger appropriate policy actions. A particular rule based engine may only be capable of acting upon policy rules that are formatted in a specified way or adhere to a specific language 🤓

$ schema 🌈 (T) okay, there are two different perspectives of schema defined here:

  • A set of rules that determines what data can be stored in a database or directory service [DirServs]
  • A collection of data models that are each bound to the same type of repository.

The latter is the preferred and recommended one for Internet Standards documents. (See also "data model".) 👑

$ service 🦋 (P) the behavior or functionality provided by a network, network element or host [DMTF, RFC2216]. Quoting from RFC 2216 [RFC2216], in order to completely specify a "service", one must define the "functions to be performed ..., the information required ... to perform these functions, and the information made available by the element to other elements of the system". Policy can be used to configure a "service" in a network or on a network element/host, invoke its functionality, and/or coordinate services in an interdomain or end-to-end environment ✨

$ Service Level Agreement (SLA) 🔥 (P) the documented result of a negotiation between a customer/consumer and a provider of a service, that specifies the levels of availability, serviceability, performance, operation or other attributes of the service [RFC2475]. (See also "Service Level Objective".) 💖

$ Service Level Objective (SLO) 🎀 (P) partitions an SLA into individual metrics and operational information to enforce and/or monitor the SLA. "Service Level Objectives" may be defined as part of an SLA, an SLS, or in a separate document. It is a set of parameters and their values. The actions of enforcing and reporting monitored compliance can be implemented as one or more policies. (See also "Service Level Agreement".) 🫶

$ Service Level Specification (SLS) 🧚 (P) specifies handling of a customer's traffic by a network provider. It is negotiated between a customer and the provider, and (for example) in a DiffServ environment, defines parameters such as specific Code Points and the Per-Hop-Behavior, profile characteristics and treatment of the traffic for those Code Points. An SLS is a specific SLA (a negotiated agreement) and its SLOs (the individual metrics and operational data to enforce) to guarantee quality of service for network traffic. (See also "Service Level Agreement" and "Service Level Objective".) 🌸

$ Simple Network Management Protocol (SNMP) 🍓 (T) SNMP is a framework (including a protocol) for managing systems in a network environment [RFC2570]. It can be used for policy-based configuration and control using a specific MIB Module designed to execute policies on managed elements via scripts. The elements (instances) in a network device are evaluated using a policy filter, to determine where policy will be applied 💜

$ SLA 🌈 See "Service Level Agreement".

$ SLO 👑 See "Service Level Objective".

$ SLS 🦋 See "Service Level Specification".

$ SMIv2 ✨ See "Structure of Management Information".

$ SNMP 🔥 See "Simple Network Management Protocol".

$ SPPI 💖 See "Structure of Policy Provisioning Information".

$ Structure of Policy Provisioning Information (SPPI) 🎀 (T) an adapted subset of SNMP's Structure of Management Information (SMIv2) that is used to encode collections of related PRovisioning Classes as a PIB [RFC3159]. (See also "Policy Information Base" and "PRovisioning Class".) 🫶

$ Structure of Management Information, version 2 (SMIv2) 🧚 (T) an adapted subset of OSI's Abstract Syntax Notation One, ASN.1 (1988), used to encode collections of related objects as SNMP Management Information Base (MIB) modules [RFC2578] 🌸

$ subject (P) 💖 An entity, or collection of entities, that originates a request and gets checked as authorized or not authorized to perform that request. Bestie, this is the one asking for the thing, and then the bouncer checks the guest list. 🎀

$ target (P) 🧚 An entity, or collection of entities, that gets affected by a policy. For example, the "targets" of a policy that reconfigures a network device are the individual services that get updated and configured. 🌸

4. Intellectual Property ✨

Okay, so the IETF is not picking a side on whether any intellectual property rights claimed for this technology are valid, how far they reach, or whether anyone can get a license for them. 🙈 It also doesn't say it has tried to find any of those rights. If you want the details on how the IETF handles rights for standards-track and standards-related documents, check BCP-11. 📚

Copies of any rights claims that were made available for publication, plus any promised licenses, or the results of anyone trying to get a general license or permission for implementers or users to use these proprietary rights, can be requested from the IETF Secretariat. 💌

The IETF invites anyone interested to tell it about any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to practice this standard. 🫶 Send that info to the IETF Executive Director. Slay for transparency! 👑

5. Acknowledgements 🌈

This document builds on the work of earlier terminology drafts. Those drafts were written by Fran Reichmeyer, Dan Grossman, John Strassner, Ed Ellesson and Matthew Condell, so big thanks to them! 🦋 The general concepts of policy and policy rule also got input from Predrag Spasic. 💜

Huge thank-yous too to Juergen Schoenwaelder, Joe Salowey, Jon Saperia, Ravi Sahita, Bob Moore, Guus Sliepen, T.H. Jonatan and Dave Perkins, who gave really helpful comments and suggestions. 🥹✨

6. Security Considerations 💀

Warning, bestie: this document only defines policy-related terms. 🚨

It does not go into detail about the vulnerabilities of, the threats to, or the mechanisms that protect specific policy implementations or policy-related Internet protocols. Those topics are NOT covered here, so please don't assume they are. 🙅‍♀️💅

7. References 📚

   [DecSupp]    Building Effective Decision Support Systems.  R.
                Sprague, and E. Carleson.  Prentice Hall, 1982.

   [DirServs]   Understanding and Deploying LDAP Directory Services. T.
                Howes, M. Smith, and G. Good.  MacMillan Technical
                Publications, 1999.

   [DMTF]       Common Information Model (CIM) Schema, version 2.x.
                Distributed Management Task Force, Inc. The components
                of the CIM v2.x schema are available via links on the
                following DMTF web page:
                http://www.dmtf.org/standards/standard_cim.php.

   [RFC1633]    Braden, R., Clark, D. and S. Shenker, "Integrated
                Services in the Internet Architecture: An Overview", RFC
                1633, June 1994.

   [RFC2026]    Bradner, S., "The Internet Standards Process -- Revision
                3", BCP 9, RFC 2026, October 1996.

   [RFC2138]    Rigney, C., Rubens, A., Simpson, W. and S. Willens,
                "Remote Authentication Dial In User Service (RADIUS)",
                RFC 2138, April 1997.

   [RFC2205]    Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
                Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
                1 Functional Specification", RFC 2205, September 1997.

   [RFC2216]    Shenker, S. and J. Wroclawski, "Network Element Service
                Specification Template", September 1997.

   [RFC2474]    Nichols, K., Blake, S., Baker, F. and D. Black,
                "Definition of the Differentiated Services Field (DS
                Field) in the IPv4 and IPv6 Headers", RFC 2474, December
                1998.

   [RFC2475]    Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
                and W. Weiss, "An Architecture for Differentiated
                Service", RFC 2475, December 1998.

   [RFC2570]    Case, J., Mundy, R., Partain, D. and B. Stewart,
                "Introduction to Version 3 of the Internet-standard
                Network Management Framework", RFC 2570, April 1999.

   [RFC2578]    McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
                J., Rose, M. and S.Waldbusser, "Structure of Management
                Information Version 2 (SMIv2)", RFC 2578, April 1999.

   [RFC2702]    Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J.
                McManus, "Requirements for Traffic Engineering Over
                MPLS", RFC 2702, September 1999.

   [RFC2748]    Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R.
                and A. Sastry, "The COPS (Common Open Policy Service)
                Protocol", RFC 2748, January 2000.

   [RFC2749]    Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R.
                and A. Sastry, "COPS Usage for RSVP", RFC 2749, January
                2000.

   [RFC2753]    Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework
                for Policy-based Admission Control", RFC 2753, January
                2000.

   [RFC2828]    Shirey, R., "Internet Security Glossary", FYI 36, RFC
                2828, May 2000.

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

   [RFC3084]    Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie,
                K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A.
                Smith, "COPS Usage for Policy Provisioning (COPS-PR)",
                RFC 3084, February 2001.

   [RFC3159]    McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn,
                S., Sahita, R., Smith, A. and F. Reichmeyer, "Structure
                of Policy Provisioning Information," RFC 3159, August
                2001.

   [UML]        The Unified Modeling Language User Guide.  G. Booch, J.
                Rumbaugh, and I. Jacobson.  Addison-Wesley, 1999.

   [X.500]      Data Communications Networks Directory, Recommendations
                X.500-X.521, Volume VIII - Fascicle VIII.8.  CCITT, IXth
                Plenary Assembly, Melbourne.  November 1988.

8. Authors' Addresses 🎀

Here are the authors and how to reach them, all in one spot. 💌

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

   EMail: andreaw@cisco.com


   John Schnizlein
   Cisco Systems
   9123 Loughran Road
   Fort Washington, MD  20744

   EMail: john.schnizlein@cisco.com


   John Strassner
   Intelliden Corporation
   90 South Cascade Avenue
   Colorado Springs, CO  80903
   Phone:   +1-719-785-0648

   EMail:   john.strassner@intelliden.com


   Mark Scherling
   Xcert International Inc.
   Suite 300
   505 Burrard Street
   Vancouver, BC
   V7X 1M3

   EMail: mscherling@xcert.com
   Bob Quinn
   Celox Networks
   2 Park Central Drive
   Southborough, MA 01772

   EMail: bquinn@celoxnetworks.com


   Jay Perry
   Network Appliance
   495 East Java Drive
   Sunnyvale, CA 94089

   EMail: jay.perry@netapp.com


   Shai Herzog
   PolicyConsulting.com
   200 Clove Rd.
   New Rochelle, NY 10801

   EMail: herzog@PolicyConsulting.com


   An-Ni Huynh
   Lucent Technologies
   2139 Route 35
   Holmdel, NJ 07733


   Mark Carlson
   Sun Microsystems, Inc.
   500 Eldorado Boulevard
   Broomfield, CO 80021

   EMail: mark.carlson@sun.com


   Steve Waldbusser

   Phone: +1-650-948-6500
   Fax:   +1-650-745-0671
   EMail: waldbusser@nextbeacon.com

Copyright (C) The Internet Society (2001). All rights reserved. 💖

Anyone can copy and share this document and translations of it, and can write derivative works that comment on or explain it, or that help people implement it. Those derivative works can be prepared, copied, published and distributed, in whole or in part, with no restrictions of any kind, as long as the copyright notice above and this paragraph are included on every copy and derivative work. ✨

The document itself, though, may NOT be modified in any way. That includes removing the copyright notice or references to the Internet Society or other Internet organizations. There are exceptions: you can make changes as needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process must be followed, or you can translate it into languages other than English. 🦋

The limited permissions above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Forever and ever, periodt! 💅

This document and the information in it are provided on an "AS IS" basis, and the disclaimer below applies. 🙈

THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, ISOC, you're literally iconic! 👑🌈

📦 where this page comes from