Internet DRAFT - draft-ietf-policy-terminology


 Policy Framework Working Group                      A. Westerinen  
 INTERNET-DRAFT                                      J. Schnizlein 
 Category: Informational                             Cisco Systems 
                                                    John Strassner 
                                                    Mark Scherling 
                                                         Bob Quinn 
                                                    Celox Networks 
                                                       Shai Herzog 
                                                        IP Highway 
                                                       An-Ni Huynh 
                                               Lucent Technologies 
                                                      Mark Carlson 
                                                  Sun Microsystems 
                                                         Jay Perry 
                                                  Steve Waldbusser 
                                                         July 2001 
               Terminology for Policy-Based Management 

                    Friday, July 20, 2001, 9:06 AM 

 Status of this Memo 

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

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

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

   The list of current Internet-Drafts can be accessed at  

   The list of Internet-Draft Shadow Directories can be accessed at 

 Copyright Notice 

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

 Westerinen, et al.     Expires: Jul 2001 + 6 months        [Page 1] 
 Internet Draft     Terminology for Policy-Based Mgmt      July 2001 


   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 RFC2828 [R2828], 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). 


 Table of Contents 

   1. Introduction.................................................3 
   2. Explanation of Paragraph Markings............................4 
   3. Terms........................................................4 
   4. Intellectual Property.......................................17 
   5. Acknowledgements............................................17 
   6. Security Considerations.....................................17 
   7. References..................................................18 
   8. Authors' Addresses..........................................19 
   9. Full Copyright Statement....................................21 

 Westerinen, et al.      Expires: Jul 2001 + 6 months      [Page 2] 
 Internet Draft     Terminology for Policy-Based Mgmt      July 2001 

 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 

   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 [R2026]. Benefits across the ISDs are well-
   stated in the Introduction to RFC2828 [R2828]: 

    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 

  Common and/or controversial policy terms are defined.  These 
  terms are directly related and specific to network policy.     
  Wherever possible, this draft 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.   

    o Multiple definitions may exist across the ISDs.  Each 
      definition is listed, with its source. 


 Westerinen, et al.      Expires: Jul 2001 + 6 months      [Page 3] 
 Internet Draft     Terminology for Policy-Based Mgmt      July 2001 

 2. Explanation of Paragraph Markings 

   Section 3 marks terms and definitions as follows: 

    o Capitalization: Only terms that are proper nouns are 

    o Paragraph Marking: Definitions and explanations are stated in 
      paragraphs that are marked as follows: 

       - "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 [R2138]. 
        In RADIUS, a network access server sends dial-user 
        credentials to an AAA server, and receives authentication 
        that the user is 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 

 Westerinen, et al.      Expires: Jul 2001 + 6 months      [Page 4] 
 Internet Draft     Terminology for Policy-Based Mgmt      July 2001 

        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 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). [R2748] The COPS protocol is used to provide 
        for the outsourcing of policy decisions for RSVP. [R2749]  
        Another usage is for the provisioning of policy. [R3084] 
        (See also "Policy Decision Point" and "Policy Enforcement 
  $ 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. 
        - 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. 

 Westerinen, et al.      Expires: Jul 2001 + 6 months      [Page 5] 
 Internet Draft     Terminology for Policy-Based Mgmt      July 2001 

  $ 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 the Traffic Class octet. [R2474] 
      (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.")  
  $ 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 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.") 

 Westerinen, et al.      Expires: Jul 2001 + 6 months      [Page 6] 
 Internet Draft     Terminology for Policy-Based Mgmt      July 2001 

  $ 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 

  $ 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. [R2570]  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 
  $ 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 
  $ Multiprotocol Label Switching (MPLS) 
      (T) Integrates a label swapping and switching framework with 
        network layer routing [R2702]. The basic idea involves 
        assigning short fixed length labels to packets at the 
        ingress to an MPLS cloud. Throughout the interior of the 

 Westerinen, et al.      Expires: Jul 2001 + 6 months      [Page 7] 
 Internet Draft     Terminology for Policy-Based Mgmt      July 2001 
        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. [R2205, R2748] "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. [R3060] 
        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 

 Westerinen, et al.      Expires: Jul 2001 + 6 months      [Page 8] 
 Internet Draft     Terminology for Policy-Based Mgmt      July 2001 

        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 
        - In [R3060], 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 [R3060], 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) [R3060] 
      (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.") 

 Westerinen, et al.      Expires: Jul 2001 + 6 months      [Page 9] 
 Internet Draft     Terminology for Policy-Based Mgmt      July 2001 

  $ 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 
  $ Policy Decision Point (PDP) 
      (P) A logical entity that makes policy decisions for itself 
        or for other network elements that request such decisions. 
        [R2753] (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. [R2474] 
        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 
        - 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. [R2753] 
        (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 
  $ 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 

 Westerinen, et al.      Expires: Jul 2001 + 6 months      [Page 10] 
 Internet Draft     Terminology for Policy-Based Mgmt      July 2001 

        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 
        - 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 
        - 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 [R3060], 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." 
        [R2753] (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. [R3060]   
  $ policy server 
      (P) A marketing term whose definition is imprecise.  
        Originally, [R2753] 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 

 Westerinen, et al.      Expires: Jul 2001 + 6 months      [Page 11] 
 Internet Draft     Terminology for Policy-Based Mgmt      July 2001 

        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 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 
  $ PolicyGroup 
      (T) An abstraction in the Policy Core Information Model 
        [R3060]. 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 
        [R2475].  Based on events received, devices use downloaded 
        (pre-provisioned) mechanisms to implement policy. 
        "Provisioned policy" is contrasted with "outsourced 
  $ 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 

 Westerinen, et al.      Expires: Jul 2001 + 6 months      [Page 12] 
 Internet Draft     Terminology for Policy-Based Mgmt      July 2001 

        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) 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 [R1633], and Differentiated 
        Service [R2475]. 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 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. [R2205]  
        And, a signaling mechanism for managing application 
        traffic's QoS in a Differentiated Service network. 

 Westerinen, et al.      Expires: Jul 2001 + 6 months      [Page 13] 
 Internet Draft     Terminology for Policy-Based Mgmt      July 2001 

  $ 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 [R3060] 
           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. [R3060] 
        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 
  $ 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. 
        [R3060]  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 are 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 

 Westerinen, et al.      Expires: Jul 2001 + 6 months      [Page 14] 
 Internet Draft     Terminology for Policy-Based Mgmt      July 2001 

        upon policy rules that are formatted in a specified way or 
        adhere to a specific language. 
  $ schema 
      (T) Two different perspectives of schema are defined: 
        - 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, R2216]. Quoting from RFC 
        2216 [R2216], 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. 
        (See also "Service Level Objective.") [R2475] 
  $ 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 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.") 

 Westerinen, et al.      Expires: Jul 2001 + 6 months      [Page 15] 
 Internet Draft     Terminology for Policy-Based Mgmt      July 2001 

  $ Simple Network Management Protocol (SNMP) 
      (T) SNMP is a framework (including a protocol) for managing 
        systems in a network environment. [R2570]  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. (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. [R2578] 
  $ subject 
      (P) An entity, or collection of entities, which originates a 
        request, and is verified as authorized/not authorized to 
        perform that request.  
  $ target 
      (P) An entity, or collection of entities, which is affected 
        by a policy. For example, the "targets" of a policy to 
        reconfigure a network device are the individual services 
        that are updated and configured.    

 Westerinen, et al.      Expires: Jul 2001 + 6 months      [Page 16] 
 Internet Draft     Terminology for Policy-Based Mgmt      July 2001 

 4. Intellectual Property 

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

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

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

 5. Acknowledgements 

   This document builds on the work of previous terminology drafts.  
   The authors of these drafts were Fran Reichmeyer, Dan Grossman, 
   John Strassner, Ed Ellesson and Matthew Condell.  Also, 
   definitions for the general concepts of policy and policy rule 
   include input from Predrag Spasic.  Very helpful comments and 
   suggestions were received from Juergen Schoenwaelder, Joe 
   Salowey, Jon Saperia, Ravi Sahita, Bob Moore, Guus Sliepen,  
   T.H. Jonatan and Dave Perkins. 

 6. Security Considerations 

   This document only defines policy-related terms. It does not 
   describe in detail the vulnerabilities of, threats to, or 
   mechanisms that protect specific policy implementations or 
   policy-related Internet protocols. 

 Westerinen, et al.      Expires: Jul 2001 + 6 months      [Page 17] 
 Internet Draft     Terminology for Policy-Based Mgmt      July 2001 

 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:  

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

   [R2026] The Internet Standards Process -- Revision 3.  S. 
       Bradner.  October 1996. 
   [R2138] Remote Authentication Dial In User Service (RADIUS).  C. 
       Rigney, A. Rubens, W. Simpson, and S. Willens.  April 1997. 
   [R2205] Resource ReSerVation Protocol (RSVP) -- Version 1 
       Functional Specification.  R. Braden, L. Zhang, S. Berson, 
       S. Herzog, and S. Jamin. September 1997. 
   [R2216] Network Element Service Specification Template.  S. 
       Shenker, and J. Wroclawski. September 1997. 
   [R2474] Definition of the Differentiated Services Field (DS 
       Field) in the IPv4 and IPv6 Headers.  K. Nichols, S. Blake, 
       F. Baker, and D. Black.  December 1998. 
   [R2475] An Architecture for Differentiated Service.  S. Blake, 
       D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss.  
       December 1998. 

   [R2570] Introduction to Version 3 of the Internet-standard 
       Network Management Framework. J. Case, R. Mundy, D. Partain, 
       and B. Stewart.  April 1999. 
   [R2578] Structure of Management Information Version 2 (SMIv2).  
       K. McGloughrie, D. Perkins, J. Schoenwaelder, J. Case, M. 
       Rose, and S. Waldbusser.  April 1999. 
   [R2702] Requirements for Traffic Engineering Over MPLS.  D. 
       Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus.  
       September 1999.  

 Westerinen, et al.      Expires: Jul 2001 + 6 months      [Page 18] 
 Internet Draft     Terminology for Policy-Based Mgmt      July 2001 

   [R2748] The COPS (Common Open Policy Service) Protocol.  D. 
       Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, and A. 
       Sastry.  January 2000. 
   [R2749] COPS Usage for RSVP. J. Boyle, R. Cohen, D. Durham, S. 
       Herzog, R. Rajan, and A. Sastry.  January 2000.  
   [R2753] A Framework for Policy-based Admission Control.  R. 
       Yavatkar, D. Pendarakis, and R. Guerin.  January 2000. 
   [R2828] Internet Security Glossary.  R. Shirey.  May 2000. 
   [R3060] Policy Core Information Model -- Version 1 
       Specification. B. Moore, E. Ellesson, J. Strassner, and A. 
       Westerinen.  February 2001. 

   [R3084] COPS Usage for Policy Provisioning (COPS-PR). K. Chan, 
       J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. 
       Reichmeyer, R. Yavatkar, and A. Smith.  March 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 

   Andrea Westerinen 
       Cisco Systems, Bldg 20 
       725 Alder Drive 
       Milpitas, CA 95035 
   John Schnizlein  
       Cisco Systems 
       9123 Loughran Road 
       Fort Washington, MD  20744 
   John Strassner 
       IntelliDEN, Inc. 
       90 South Cascade Avenue 
       Colorado Springs, CO  80903 
       Phone:   +1-719-785-0648 

 Westerinen, et al.      Expires: Jul 2001 + 6 months      [Page 19] 
 Internet Draft     Terminology for Policy-Based Mgmt      July 2001 

   Mark Scherling 
       Xcert International Inc. 
       Suite 300 
       505 Burrard Street 
       Vancouver, BC 
       V7X 1M3     
   Bob Quinn 
       Celox Networks 
       One Cabot Road 
       Hudson, MA  01749 
   Jay Perry  
   Shai Herzog  
       55 New York Avenue 
      Framingham, MA  01701 
   An-Ni Huynh  
       Lucent Technologies 
      2139 Route 35  
      Holmdel, NJ 07733 
   Mark Carlson  
      Sun Microsystems 
      3030 S. Technology Ct. Bldg B. 
      Broomfield, CO 80021 
  Steve Waldbusser 

 Westerinen, et al.      Expires: Jul 2001 + 6 months      [Page 20] 
 Internet Draft     Terminology for Policy-Based Mgmt      July 2001 

 9. Full Copyright Statement 

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

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

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

   This document and the information contained herein is provided 

 Westerinen, et al.      Expires: Jul 2001 + 6 months      [Page 21]