Policy Framework Working Group                      A. Westerinen
 INTERNET-DRAFT                                      J. Schnizlein
 Category: Informational                              J. Strassner
                                                     Cisco Systems
                                                    Mark Scherling
                                                         Bob Quinn
                                                    Celox Networks
                                                       Shai Herzog
                                                        IP Highway
                                                       An-Ni Huynh
                                               Lucent Technologies
                                                      Mark Carlson
                                                  Sun Microsystems
                                                         Jay Perry
                                                  Steve Waldbusser
                                                        April 2001
                  Thursday, April 19, 2001, 3:53 PM
 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: Apr 2001 + 6 months        [Page 1]

 Internet Draft         Policy Terminology                April 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.......................................16
   5. Acknowledgements............................................17
   6. Security Considerations.....................................17
   7. References..................................................17
   8. Authors' Addresses..........................................18
   9. Full Copyright Statement....................................20
 Westerinen, et al.      Expires: Apr 2001 + 6 months      [Page 2]

 Internet Draft         Policy Terminology                April 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: Apr 2001 + 6 months      [Page 3]

 Internet Draft         Policy Terminology                April 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.
       - "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 efforts in the IETF have focused on the most widely
        deployed use of authentication: Remote Authentication Dial
        In User Service (RADIUS), and its expansion in Diameter (a
        "radius" pun and not an acronym). Referencing the RADIUS
        RFC [R2138], 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
        for that user. Policy is implied in both the
        authentication, which can be restricted by time of day,
 Westerinen, et al.      Expires: Apr 2001 + 6 months      [Page 4]

 Internet Draft         Policy Terminology                April 2001
        number of sessions, calling number, etc., and the
        attribute-values authorized. AAA efforts in the IRTF are
        wider, for control, authentication, authorization and
        accounting of systems and environments based on policies
        set by the administrators and users of the systems.
  $ 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). [RFC 2748] (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.
        - 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: Apr 2001 + 6 months      [Page 5]

 Internet Draft         Policy Terminology                April 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). (See also "Quality of Service.")
  $ 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
      A collection of elements and services, administered in a
      coordinated fashion.  (See also "policy domain.")
  $ DS
      See "Differentiated Services."
 Westerinen, et al.      Expires: Apr 2001 + 6 months      [Page 6]

 Internet Draft         Policy Terminology                April 2001
  $ 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, application,
        protocol, or platform.
  $ MIB
      See "Policy 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
        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."
 Westerinen, et al.      Expires: Apr 2001 + 6 months      [Page 7]

 Internet Draft         Policy Terminology                April 2001
  $ 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
        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.
 Westerinen, et al.      Expires: Apr 2001 + 6 months      [Page 8]

 Internet Draft         Policy Terminology                April 2001
        - 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.")
  $ 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 coordinated.
 Westerinen, et al.      Expires: Apr 2001 + 6 months      [Page 9]

 Internet Draft         Policy Terminology                April 2001
        - 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
        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 Management Information Base (MIB)
      (T) Collections of policy-related managed objects, defined as
        a module and accessed via an SNMP framework.
  $ 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.
 Westerinen, et al.      Expires: Apr 2001 + 6 months      [Page 10]

 Internet Draft         Policy Terminology                April 2001
  $ 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 service. 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
        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
 Westerinen, et al.      Expires: Apr 2001 + 6 months      [Page 11]

 Internet Draft         Policy Terminology                April 2001
        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
        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
 Westerinen, et al.      Expires: Apr 2001 + 6 months      [Page 12]

 Internet Draft         Policy Terminology                April 2001
        capabilities that allow a service provider to prioritize
        traffic, and 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. Policy controls the set of
        configuration parameters 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.
  $ 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.
        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
 Westerinen, et al.      Expires: Apr 2001 + 6 months      [Page 13]

 Internet Draft         Policy Terminology                April 2001
  $ role combination
      (P) An unordered 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, or may require
        that PRCs explicitly match the role combination specified
        for the managed element.  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
        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.")
  $ Security Policy Specification Language (SPSL)
      (T) A language designed to express security policies,
        security domains, and the entities that manage those
        policies and domains. It supports policies for packet
        filtering, IP Security (IPsec), and IKE exchanges, but may
        be extended to express other types of policies.
  $ 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
 Westerinen, et al.      Expires: Apr 2001 + 6 months      [Page 14]

 Internet Draft         Policy Terminology                April 2001
        "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, 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 defines DiffServ parameters (such as specific
        Code Points and Per-Hop-Behaviors, profile characteristics
        and treatment of the traffic for those Code Points).
        An SLS is a combination of an SLA (a negotiated agreement)
        and its SLOs (the individual metrics and operational
        data to enforce). (See also "Service Level Agreement"
        and "Service Level Objective.")
  $ SLA
      See "Service Level Agreement."
  $ SLO
      See "Service Level Objective."
  $ SLS
      See "Service Level Specification."
  $ SMIv2
      See "Structure of Management Information."
  $ SPPI
      See "Structure of Policy Provisioning Information."
  $ SPSL
      See "Security Policy Specification Language."
  $ 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
 Westerinen, et al.      Expires: Apr 2001 + 6 months      [Page 15]

 Internet Draft         Policy Terminology                April 2001
        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.
 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.
 Westerinen, et al.      Expires: Apr 2001 + 6 months      [Page 16]

 Internet Draft         Policy Terminology                April 2001
 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 and Jon Saperia.
 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.
 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/spec/cim_schema_v24.html.
   [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.
 Westerinen, et al.      Expires: Apr 2001 + 6 months      [Page 17]

 Internet Draft         Policy Terminology                April 2001
   [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.
   [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.
   [R2748] The COPS (Common Open Policy Service) Protocol.  D.
       Durham, J. Boyle, R. Cohen, 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.
   [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
       E-mail: andreaw@cisco.com
   John Schnizlein
       Cisco Systems
       9123 Loughran Road
       Fort Washington, MD  20744
       E-mail: john.schnizlein@cisco.com
 Westerinen, et al.      Expires: Apr 2001 + 6 months      [Page 18]

 Internet Draft         Policy Terminology                April 2001
   John Strassner
       Cisco Systems, Bldg 20
       725 Alder Drive
       Milpitas, CA 95035
       E-mail: johns@cisco.com
   Mark Scherling
       Xcert International Inc.
       Suite 300
       505 Burrard Street
       Vancouver, BC
       V7X 1M3
       E-mail: mscherling@xcert.com
   Bob Quinn
       Celox Networks
       One Cabot Road
       Hudson, MA  01749
       E-mail: bquinn@celoxnetworks.com
   Jay Perry
       E-mail: jay@jandg.net
   Shai Herzog
       55 New York Avenue
       Framingham, MA  01701
       E-mail: herzog@iphighway.com
   An-Ni Huynh
       Lucent Technologies
       2139 Route 35
       Holmdel, NJ 07733
       E-mail: ahuynh@lucent.com
   Mark Carlson
       Sun Microsystems
       3030 S. Technology Ct. Bldg B.
       Broomfield, CO 80021
       Email: mark.carlson@sun.com
  Steve Waldbusser
       Email: waldbusser@nextbeacon.com
 Westerinen, et al.      Expires: Apr 2001 + 6 months      [Page 19]

 Internet Draft         Policy Terminology                April 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: Apr 2001 + 6 months      [Page 20]