Internet Engineering Task Force                         John Strassner
INTERNET DRAFT                                           Cisco Systems
23 June 1999                                               Ed Ellesson
                                                                   IBM

           Terminology for describing network policy and services
                      draft-ietf-policy-terms-00.txt

Status of 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
     http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

Abstract

Recent work in the IETF has led to multiple protocols which support
the classification of packets for the purposes of treating certain
classes or flows of packets in a particular way compared to other
packets. The successful wide-scale deployment of these protocols
depends on the ability to administer and distribute consistent policy
information to the multiple devices in the network which perform the
classification and packet conditioning or treatment. As a result,
there is a clear need to develop a scalable framework for policy
administration and distribution that will enable interoperability
among multiple devices and device types that must work together to
achieve a consistent implementation of policy.

Unfortunately, terms like "policy" and "service" are not
currently defined in sufficient detail as to enable the definition,
specification, and implementation of policy servers and how policy is
recognized and enforced at the device level. At present, both "policy"
and "service" (as well as other related terms) are overloaded with
multiple (often conflicting) meanings. This makes communication about
policy in general and specifically policy-based networking cumbersome
and difficult. In addition, information modeling approaches, like CIM
[CIM], define specific meanings for these terms that must be
coordinated with the IETF community.





Strassner and Ellesson      Expires 23 December 1999           [Page 1]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999


This document defines a set of terms that the Internet community can
use to exchange ideas on how policy creation, administration,
management, and distribution could work among policy servers and
multiple device types.


Definition of Key Word Usage

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  and "MAY" in this document
are to be interpreted as described in RFC 2119 [TERMS]. These words
will be capitalized to ensure that their intent in this context is
easily discernible.

Table of Contents

       Status of this memo                                           1
       Abstract                                                      1
       Definition of Key Word Usage                                  2
       Table of Contents                                             2
1.     Introduction and Motivation                                   4
2.     Previously Defined Terminology                                5
3.     Areas of Terminology Conflict                                 9
4.     Policy Mental Model                                          10
4.1    General Policy Architecture                                  11
4.2    How Policy Decisions Are Made                                13
4.3    What Is A Policy (In General Terms)                          13
4.4    Real-World Requirements of Policy                            14
4.4.1  Applicable to Large-Scale Solutions                          14
4.4.2  Secure                                                       15
4.4.3  Easy to Detect Conflicts                                     15
4.5    Policy Components                                            15
4.6    Policy-Based Applications And Network Policy                 16
4.7    Difference Between Policy And Service                        16
4.8    Need For Canonical Representation Of Policy                  17
5.     Policy Terminology                                           17
5.1    Policy Group                                                 17
5.2    Policy Rule                                                  18
5.3    Policy Condition                                             18
5.4    Policy Action                                                19
5.5    Policy Decision                                              19
5.6    Policy Behavior                                              19
5.7    Policy State                                                 20
5.8    Effect of Executing a Policy                                 20
5.9    Policy Domain                                                20
5.10   Policy Conflict                                              21
5.10.1 Global Conflict Detection                                    21
5.10.2 Local Conflict Detection                                     21
5.11   Service Level Agreement                                      22
5.12   Service Level Objective                                      22
5.13   Policy Event                                                 22
5.14   Policy Evaluation                                            22

Strassner and Ellesson      Expires 23 December 1999           [Page 2]


INTERNET DRAFT     draft-strassner-policy-terms-02.txt     23 June 1999

Table of Contents (continued)

5.15   Policy Enforcement                                           23
5.16   Policy Policing                                              23
5.17   Policy Agent                                                 23
5.18   Policy-Driven Service                                        23
5.19   Policy Audit                                                 23
5.20   Policy Consistency Checking                                  24
5.21   Policy Discrepancy                                           24
5.22   Policy Mechanism                                             24
5.23   Policy Verification                                          24
5.24   Policy Restoration                                           24
5.25   Roles                                                        24
5.25.1 Role Combinations                                            25
6.     Policy Example                                               25
7.     Terminology For Implementing Policy GUIs                     26
7.1    Types Of Policies                                            26
7.2    How A Policy Is Used - Service And Usage Policies            27
7.3    Classifying Policies Based On Attributes                     27
8.     Security Considerations                                      27
9.     Acknowledgements                                             27
10.    References                                                   28
11.    Authors' Addresses                                           29
12.    Full Copyright Statement                                     29






























Strassner and Ellesson      Expires 23 December 1999           [Page 3]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

1. Introduction and Motivation

Recent work in the IETF has led to protocols which support the
classification of packets for the purposes of treating certain
classes or flows of packets in a particular way compared to other
packets.  The purpose of such classification may include preferential
queuing or dropping, admitting or denying access, or encrypting the
packet's payload, to cite just a few examples. Protocols that
explicitly support some or all of these functions include COPS,
RADIUS, RSVP, and IPSEC. In addition, the IntServ [ISWG], DiffServ [DSWG], RAP [RAPWG], ISSLL [ISSLLWG] and IPSEC [IPSECWG] working groups are defining approaches to using these protocols.

The successful wide-scale deployment these and other protocols depends
on the ability for the administrator of a network domain to administer
and distribute consistent policy information to the multiple devices
in the network which perform the classification and packet
conditioning or treatment.  Protocols that could be used for the
distribution of the policy include LDAP, COPS, SNMP, and TELNET/CLI.
The multiple types of devices that must work in concert across even a
single domain to achieve the desired policy can include hosts (clients
and servers), routers, switches, firewalls, bandwidth brokers, subnet
bandwidth managers, network access servers, and policy servers, to name
just a few.

As a result, there is a clear need to develop a scalable framework for
policy administration and distribution that will allow interoperability
among the multiple devices and device types that must work together to
achieve a consistent implementation of the network administrator's
policy. Unfortunately, terms like "policy" and "service" are not
currently defined in sufficient detail as to enable the definition,
specification, and implementation of policy servers and how policy is
recognized and enforced at the device level. At present, both "policy"
and "service" (as well as other related terms) are overloaded with
multiple (often conflicting) meanings. This makes communication about
policy in general and specifically policy-based networking cumbersome
and difficult.

This document defines a set of terms that the Internet community can
use to exchange ideas on how policy creation, administration,
management, and distribution could work among policy servers and
multiple device types.












Strassner and Ellesson      Expires 23 December 1999           [Page 4]


INTERNET DRAFT     draft-strassner-policy-terms-02.txt     23 June 1999

2. Previously Defined Terminology

The following terms have been previously defined in other Internet
Drafts and are used in this draft to better define policy and policy-
based networking terms.

Definitions taken from RFC2474 (Definition of the DS Field):

   Classifier: an entity which selects packets based on the content of
   packet headers according to defined rules.

   Differentiated Services Boundary: the edge of a DS domain, where
   classifiers and traffic conditioners are likely to be deployed.  A
   differentiated services boundary can be further sub-divided into
   ingress and egress nodes, where the ingress/egress nodes are the
   downstream/upstream nodes of a boundary link in a given traffic
   direction. A differentiated services boundary typically is found at
   the ingress to the first-hop differentiated services-compliant
   router (or network node) that a host's packets traverse, or at the
   egress of the last-hop differentiated services-compliant router or
   network node that packets traverse before arriving at a host. This
   is sometimes referred to as the boundary at a leaf router.  A
   differentiated services boundary may be co-located with a host,
   subject to local policy.

   Differentiated Services-Compliant: in compliance with the
   requirements specified in [RFC2474].

   Differentiated Services Domain: a contiguous portion of the Internet
   over which a consistent set of differentiated services policies are
   administered in a coordinated fashion.  A differentiated services
   domain can represent different administrative domains or autonomous
   systems, different trust regions, different network technologies
   (e.g., cell/frame), hosts and routers, etc.

   Differentiated Services Field: the IPv4 header TOS octet or the IPv6
   Traffic Class octet when interpreted in conformance with the
   definition given in this document (RFC2474).

   Mechanism:  The implementation of one or more per-hop behaviors
   according to a particular algorithm.

   Per-hop Behavior (PHB): a description of the externally observable
   forwarding treatment applied at a differentiated services-compliant
   node to a behavior aggregate. The description of a PHB SHOULD be
   sufficiently detailed to allow the construction of predictable
   services, as documented in [RFC2475].

   Per-hop Behavior Group: a set of one or more PHBs that can only be
   meaningfully specified and implemented simultaneously, due to a
   common constraint applying to all PHBs in the set such as a queue
   servicing or queue management policy.


Strassner and Ellesson      Expires 23 December 1999           [Page 5]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

   Traffic Conditioning: control functions that can be applied to a
   behavior aggregate, application flow, or other operationally useful
   subset of traffic, e.g., routing updates.  These MAY include
   metering, policing, shaping, and packet marking.  Traffic
   conditioning is used to enforce agreements between domains and to
   condition traffic to receive a differentiated service within a
   domain by marking packets with the appropriate codepoint in the DS
   field and by monitoring and altering the temporal characteristics of
   the aggregate where necessary.

   Traffic Conditioner: an entity that performs traffic conditioning
   functions and which MAY contain meters, policers, shapers, and
   markers.  Traffic conditioners are typically deployed in DS boundary
   nodes (i.e., not in interior nodes of a DS domain).

   Service: a description of the overall treatment of (a subset of) a
   customer's traffic across a particular domain, across a set of
   interconnected DS domains, or end-to-end.  Service descriptions are
   covered by administrative policy and services are constructed by
   applying traffic conditioning to create behavior aggregates which
   experience a known PHB at each node within the DS domain.  Multiple
   services can be supported by a single per-hop behavior used in
   concert with a range of traffic conditioners.

Definitions taken from RFC2475 (Differentiated Services Architecture):

  - DS boundary node: a DS node that connects one DS domain to a
    node either in another DS domain or in a domain that is not
    DS-capable.

  - DS-capable: capable of implementing differentiated services
    as described in this architecture [RFC2475]; usually used in
    reference to a domain consisting of DS-compliant nodes.

  - DS codepoint: a specific value of the DSCP portion of the
    DS field, used to select a PHB.

  - DS-compliant: enabled to support differentiated services
    functions and behaviors as defined in [DSFIELD], this document
    (DS Architecture), and other differentiated services documents;
    usually used in reference to a node or device.

  - DS domain: a DS-capable domain; a contiguous set of nodes which
    operate with a common set of service provisioning policies and PHB
    definitions.









Strassner and Ellesson      Expires 23 December 1999           [Page 6]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

  - DS egress node: a DS boundary node in its role in handling traffic
    as it leaves a DS domain.

  - DS ingress node: a DS boundary node in its role in handling traffic
    as it enters a DS domain.

  - DS interior node: a DS node that is not a DS boundary node.

  - Marking: the process of setting the DS codepoint in a packet based
    on defined rules; pre-marking, re-marking.

  - Mechanism: a specific algorithm or operation (e.g., queueing
    discipline) that is implemented in a node to realize a set of
    one or more per-hop behaviors.

  - Metering: the process of measuring the temporal properties (e.g.,
    rate) of a traffic stream selected by a classifier.  The
    instantaneous state of this process may be used to affect the
    operation of a marker, shaper, or dropper, and/or may be used for
    accounting and measurement purposes.

  - Policing: the process of discarding packets (by a dropper) within a
    traffic stream in accordance with the state of a corresponding
    meter enforcing a traffic profile.

  - Service: the overall treatment of a defined subset of a customer's
    traffic within a DS domain or end-to-end.

  - Service Level Agreement: a service contract between a customer and
    a service provider that specifies the forwarding service a customer
    should receive.  A customer may be a user organization (source
    domain) or another DS domain (upstream domain).  A SLA may include
    traffic conditioning rules which constitute a TCA in whole or
    in part.

  - Service Provisioning Policy: a policy which defines how traffic
    conditioners are configured on DS boundary nodes and how traffic
    streams are mapped to DS behavior aggregates to achieve a range
    of services.

  - Shaping: the process of delaying packets within a traffic stream
    to cause it to conform to some defined traffic profile.

  - Traffic conditioning: control functions performed to enforce
    rules specified in a TCA, including metering, marking, shaping,
    and policing.








Strassner and Ellesson      Expires 23 December 1999           [Page 7]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

  - Traffic Conditioning Agreement (TCA): an agreement specifying
    classifier rules and any corresponding traffic profiles and
    metering, marking, discarding and/or shaping rules which are to
    apply to the traffic streams selected by the classifier. A TCA
    encompasses all of the traffic conditioning rules explicitly
    specified within a SLA along with all of the rules implicit from
    the relevant service requirements and/or from a DS domain's
    service provisioning policy.

  - Traffic profile: a description of the temporal properties of a
    traffic stream such as rate and burst size.

  - Traffic stream: an administratively significant set of one or
    more microflows which traverse a path segment.  A traffic stream
    may consist of the set of active microflows which are selected by
    a particular classifier.

Definitions taken from the Differentiated Services Working Group Charter:

   Differentiated Services: The differentiated services approach to
   providing quality of service in networks employs a small, well-
   defined set of building blocks from which a variety of services may
   be built.

Definitions taken from draft-ietf-rap-framework-01.txt:

  - Administrative Domain: A collection of network elements under the
    same administrative control and grouped together for administrative
    purposes.

  - Installed State: A new and unique request made from a PEP to a PDP
    that must be explicitly deleted.

  - Network Element (also called a Node): A networking device, such as
    a router, a switch, or a hub, where resource allocation decisions
    have to be made and the decisions have to be enforced.

  - QoS Signaling Protocol: A signaling protocol that carries an
    admission control request for a bandwidth resource, e.g., RSVP.

  - Policy: The combination of rules and services where rules define
    the criteria for resource access and usage.

  - Policy control: The application of rules to determine whether or
    not access to a particular resource should be granted.

  - Policy Object:  Contains policy-related info such as policy
    elements and is carried in a request or response related to
    resource allocation decision.





Strassner and Ellesson      Expires 23 December 1999           [Page 8]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

 -  Policy Element: Subdivision of policy objects; contains single
    units of information necessary for the evaluation of policy rules.
    A single policy element carries an user or application
    identification whereas another policy element may carry user
    credentials or credit card information.  Examples of policy
    elements include identity of the requesting user or application,
    user/app credentials, etc.  The policy elements themselves are
    expected to be independent of which QoS signaling protocol is used.

 -  Policy Decision Point (PDP): The point where policy decisions are
    made.

 -  Policy Enforcement Point (PEP): The point where the policy
    decisions are actually enforced.

 -  Policy Ignorant Node (PIN): A network element that does not
    explicitly support policy control using the mechanisms defined in
    this document (RAP Framework).

 -  Resource: Something of value in a network infrastructure to which
    rules or policy criteria are first applied before access is
    granted. Examples of resources include the buffers in a router and
    bandwidth on an interface.

 -  Service Provider: Controls the network infrastructure and may be
    responsible for the charging and accounting of services.

 -  Trusted Node: A node that is within the boundaries of an
    administrative domain (AD) and is trusted in the sense that the
    admission control requests from such a node do not necessarily need
    a PDP decision.


3. Areas of Terminology Conflict

Section 2 listed previously-defined terms that are related to the
definition of policy and policy-based networking. Of these terms, the
following terms that have been previously defined need more definition
in order to satisfy the goals of this document, and will be redefined
in subsequent sections of this document:














Strassner and Ellesson      Expires 23 December 1999           [Page 9]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

 NAME OF THE TERM   DEFINED IN      PROBLEM WITH DEFINITION
  Service           [DIFFSERV],   Tied directly to network traffic;
                    [DIFFARCH]    needs to be defined more generally

  Policing          [DIFFARCH]    Too specific to traffic conditioning

  Service Level     [DIFFARCH]    Too specific to forwarding of network
  Agreement (SLA)                           traffic and traffic conditioning

  Service           [DIFFARCH]    Too specific to Differentiated
  Provisioning                    Services architecture

  Policy            [RAPFRAME]    Too simplistic a definition; too
                                            focused on network resource control

  Policy control    [RAPFRAME]    Too simplistic a definition; too
                                            focused on network resource control

  Policy Object     [RAPFRAME]    Too specific to using QoS
                                  signaling protocol as transport; too
                                            focused on network resource control

  PDP               [RAPFRAME]    Too RSVP-specific.  Needs to add
                                  clarification that policy decisions
                                  can also be made at the PEP.

  Policy Element          [RAPFRAME]    Not just for evaluation of policy
                                            Rules

  Domain            [DIFFSERV]    Specific to just treatment of
                                  Traffic using DiffServ; needs to
                                  be generalized

4. Policy Mental Model

In the general sense, policies represent business goals and objectives,
and describe how resources are allocated to meet these goals and
objectives. In the general sense, a "resource" is any object that can
potentially be in short supply, due to many different clients
simultaneously requesting it. With respect to the Policy Framework
working group, we will differentiate between "resources" as defined
above and "network resources", which refers explicitly to resources
of a network element (e.g., interface bandwidth). Thus, the term
"network resources" matches the definitions of previous documents
referenced above.

Again, with respect to networking, policy refers to the ability to
administer, manage, and control access to the network resources of
network elements in order to provide a set of services to clients
of the network. "Clients" in this context refer to users as well as
applications and services.



Strassner and Ellesson      Expires 23 December 1999          [Page 10]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

An underlying assumption of this draft is that policy is stored in a
centralized repository. This repository may be, but is not limited to,
a directory accessed using the LDAP protocol [LDAP]. The rest of this
section defines the underlying mental model to support this definition
of policy and policy-based networking.


4.1  General Policy Architecture

A general architecture is shown in Figure 1 below.


       Policy Specifications
                |
+ - - - - - - - | - - - - - - - + Multi-role policy server
                V
|     +--------------------+    |
      |      Policy        |
|     |  Management Tool   |    |
      +----*----+----------+
|          *    +               |
           *    +++++++++++++++++++++++++++++++
|            *                    |             +
           *                        +---------+----------+
|          *                    |   | Policy Repository  |
           *                        | (Directory Server, | <-- Policy
|          *                    |   |  Database, etc. )  |     rules
           *                        +---------+----------+
|            *                          |             +
           *    +++++++++++++++++++++++++++++++
|          *    +               |
      +----*----+----------+
|     |   Policy Decision  |    |
      |     Point (PDP)    |
|     +---------+----------+    |
                #
+ - - - - - - - # - - - - - - - +
                #
                # <--- Policy Protocol for communicating control
                #      of device policy mechanisms to the PEP
                #
      +---------+----------+    +++++++++ Repository Access Protocol
      | Policy Enforcement |              (e.g., LDAP) - REQUIRED
      |     Point (PEP)    |    ********* OPTIONAL communication path
      +--------------------+    ######### Policy Protocol
                                          (e.g., COPS) - REQUIRED

                Figure 1. Architectural Overview

The above diagram illustrates one common implementation that combines
the use of a policy management tool, a policy repository, a PDP, and
a PEP.


Strassner and Ellesson      Expires 23 December 1999          [Page 11]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

This diagram is not meant to imply that these entities must be
located in physically separate devices, nor is it meant to imply that
the only protocols used for communicating policy are those illustrated.
Rather, it is simply meant to show one possible implementation for the
purpose of defining the four important entities fundamental to policy:
a policy entry/management tool, a policy repository, a PDP, and a PEP.
Please refer to [PLYARCH] for a description of how these entities are
used and interact with each other.

Note the use of the term "multi-role policy server". This refers to the ability of the policy server to manage and distribute policies of a variety of disciplines, not just those pertaining to networking. However, this document, and the focus of the Policy Framework working group, is limited specifically to networking.

Note also how the policy repository spans the policy server and the rest of the environment. This reinforces thinking of the policy repository as a logically centralized (but possibly physically distributed) repository. It also emphasizes one of the prime goals of the work being done in the Policy Framework working group:  interoperability. This is shown explicitly in Figure 2 below.

               Policy Specifications
                         |
        _________________|_____________________
       |                                       |
       V                                       V
 +-------------+     +------------+     +-------------+
 |   POLICY    |<--->|   POLICY   |<--->|    POLICY   |
 |  SERVER A   |     | REPOSITORY |     |   SERVER B  |
 +-------------+     +------------+     +-------------+
       |                                       |
       |                                       |
       V                                       V
 +-------------+                        +-------------+
 |   POLICY    |-+                      |    POLICY   |-+
 |   DEVICES   | |                      |    DEVICES  | |
 +-------------+ |                      +-------------+ |
   |             |                        |             |
   +-------------+                        +-------------+

            Figure 2. Logically Centralized Policy
                      Repository for Interoperability

Specifically, the above figure provides the flexibility for two
different policy servers (A and B) to manage their own devices, while
still enabling the policy servers to exchange policy information. The
two policy servers could represent different vendors or the same vendor.
The latter may be required because of physical location reasons, or
because the types of devices that Policy Server A manages are very
different than those managed by Policy Server B (e.g., QoS policy vs.
firewall policy).


Strassner and Ellesson      Expires 23 December 1999          [Page 12]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

Although Figure 2 does not show it, the architecture described in Figure 1 also is intended to support the case where a  multi-role policy server is not used, and the policy management tool is supplied by one vendor, while the PDP(s) are supplied by another.

Again, the point of interoperability in this case, as well as in the
the multiple multi-role policy server case, is the Policy Repository.
This is discussed further in [PLYARCH].

It has been previously assumed that all policy decisions will always be
made in the PDP and implemented in the PEP. In other words, the PEP is
not able to make decisions on its own. This is too simplistic a
definition. The problem is that policies that are a function of packet
conditions can not be evaluated in the PDP, if the PDP is physically
separate from the PEP.  This is discussed further in [PLYARCH].

The Repository Access Protocol and the Policy Protocol are in general
different protocols. If the Policy Repository is a directory, then LDAP
is one example of a Repository Access Protocol. However, the Policy
Protocol could be any combination of COPS, SNMP, and Telnet/CLI. In fact, different policy protocols could be used between different devices that are governed by the same PDP.

4.2  How Policy Decisions Are Made

Any PEP that encounters an event requiring a policy-based decision that
it can not make by itself first asks its PDP how to handle this request.
This results in one or more policy decisions made by the PDP that are
in turn communicated to the PEP. A policy decision results in a specific
set of operations that either provide a service that was contracted for,
or implement a change in state (e.g., in the network) to provide a
service. For example, if the network is designed to support
differentiated classes of service for handling different types of
traffic, network elements could send requests to a policy server asking
how to map a given type of traffic, or these network elements could
be configured via the policy server or PDP that provides this mapping.
Policy decisions would then be made instructing what type of queuing
mechanisms to use to handle that traffic (as an example).

4.3  What Is A Policy (In General Terms)

A policy is formally defined as an aggregation of policy rules. Each
policy rule is comprised of a set of conditions and a corresponding set
of actions. The conditions define when the policy rule is applicable.
Once a policy rule is so activated, one or more actions contained by
that policy rule may then be executed. These actions are associated
with either meeting or not meeting the set of conditions specified in
the policy rule.

Policies can contain policies. This notion of hierarchy is crucial, as
it enables complex policies to be built from a set of simpler policies,
thereby simplifying their management. It also enables reuse of policy
building blocks (policy rules, conditions and actions).

Strassner and Ellesson      Expires 23 December 1999          [Page 13]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

This definition of policy can be enhanced in several different ways.
However, it is the feelings of the authors that as simple as possible
(but no simpler) a definition must first be used and put into practice
before more complicated definitions of policy are deployed. Otherwise,
it will be much harder to achieve interoperability of policy servers,
or other policy entities.

Policy is a relationship among the attributes of the objects maintained
by a policy application that control and manages one or more aspects of
a set of PEPs. These PEPs are used to provide a set of services that
are regulated by one or more policies. Key to this definition is the
ability to separate the specification of the set of services to be
provided in a vendor-independent manner from the implementation of
vendor-specific mechanisms that are applied to vendor-specific network
elements to supply those services.


4.4 Real-World Requirements of Policy

There are several important requirements of policy. Principal among these are that it must be:

  - able to be used for large-scale distributed systems as well as
    small point solutions
  - widely available to those entities that need access to it
  - secure
  - easy to detect conflicts

4.4.1  Applicable to Large-Scale Solutions

Nothing in the definition of policy, the architecture that is recommended for managing and distributing policy, or the structure of policy itself should prohibit its applicability to large numbers of objects. By large, we mean potentially millions of objects (e.g., IP phones).

Policy should be able to be put into a form that enables it to be easily distributed to objects in a domain that need it. One way of accomplishing this is to be able to group policy information and objects into policy domains. The existing use of the word domain has been constrained mostly to refer to a set of contiguous network
devices that are under common administrative control. This set of common devices are used to provide a common and consistent set of differentiated services, which are administered in a coordinated fashion.

The term domain, as used in the Policy Framework working group, will be expanded to describe a grouping of not necessarily contiguous devices that are administered in a common way. Here, device is also expanded to encompass hosts, firewalls, and other network resources.






Strassner and Ellesson      Expires 23 December 1999          [Page 14]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

4.4.2  Secure

Security is extremely important for objects that are controlled using policies. This is because limited resources are controlled by policies, and unauthorized access can lead to unfair, or illegal, delegation of and access to these resources. Extra precautions must be taken for managers and policy agents to be authenticated and authorized to perform management actions, in order to protect the system being managed.

4.4.3  Easy to Detect Conflicts

A critical part of the underlying mental model is that it must be easy
to detect conflicts between different policies and resolve them. The
simplest view of a policy is that it specifies a set of actions
that MUST be performed if a set of associated conditions is met.
Therefore, the ability to detect and resolve conflicts between policy
definitions (conditions as well as actions that are taken when a
set of conditions are met) is crucial.

There are many reasons that policies can conflict. A policy can be a member of multiple policy domains, and multiple policies can apply to the same domain. Conflict detection can be done before implementation by syntactic analysis, which will catch the large majority of conflicts. Peculiar cases can occur, such as two policies that appear to conflict but actually don't because they are applied when different situations occur.

One way of doing this is by imposing a priority on both the satisfaction of policy conditions as well as the execution of policy actions. However, it should be noted that priority is a fundamental concepts of distributed systems and MUST be supported irrespective of being used to supply a means for policy conflict resolution.

4.5 Policy Components

Policy is comprised of the following three functions:

  1. Decision-making. This compares the current state of the network to
     a desired state described by an application-specific policy and
     decides how to achieve or maintain the desired state.
  2. Enforcement. This implements a desired policy state through a set
     of management commands; when applied to network elements, these
     management commands change the configuration of the device using
     one or more mechanisms. These mechanisms MAY be vendor-specific.
  3. Monitoring: This is an on-going active or passive examination of the
     network and its constituent devices for checking network health,
     whether policies are being satisfied, and whether clients are
     taking unfair advantage of network services.







Strassner and Ellesson      Expires 23 December 1999          [Page 15]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

Decision-making uses static and/or dynamic data to determine if a type
of policy is being satisfied and, if not, what steps are needed to
satisfy that policy. Enforcement refers to the interpretation and
execution of policies by consumers who are assumed to be trustworthy.
Policing is the auditing of policy compliance to verify that the policy
consumers properly implement policies.

4.6 Policy-Based Applications and Network Policy

Policy is defined in terms of applications or processes that monitor
and manipulate one or more entities in order to achieve a desired goal.
To make the following discussion simpler to understand, this paper
focuses on network policies.

A network policy defines the relationships between clients that desire
services of the network and the network elements that provide those
services. Network Policy applications model two important things:
1) the state of the SLAs that they are enforcing, and/or
2) some part of the state of the (overall) network in order to
     ensure that their clients will obtain the services they require
     of (that portion of) the network.

Such applications will maintain a number of objects of various types,
each with one or more attributes. Each of these objects either models
the state of one or more network elements or maintains some part of the
internal state of the policy application.

These applications contain the mapping of services desired by users to the network elements that provide those services. A network policy, then, is a relationship among attributes of the objects maintained by the policy application that controls and manages some aspect of the network in terms of one or more services that the network provides.  Since the application models some part of the state of the entity, it is also accurate to say that a policy is a statement about the desired state of the entity (e.g., the requirements to maintain its current state or the need to transition to a different state).

4.7 Difference Between Policy And Service

Service is a very overloaded word. In CIM, a "service" is used to abstract and manage functionality. Service objects represent the management aspects of the functionality provided by an entity (CIM also defines ServiceAccessPoints, which manage the consumption (or access) of that functionality). The functionality is provided by some other object (e.g., a device and/or software feature object).

The information model of the Policy Framework working group is based on CIM and DEN. A service is therefore the abstraction of managing functionality provided by one or more other objects. It is NOT the functionality itself. Furthermore, a policy is a statement that controls the access to and/or utilization of resources. A policy can be used to configure and control a service, but it is not the service itself.



Strassner and Ellesson      Expires 23 December 1999          [Page 16]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

4.8 Need For Canonical Representation of Policy

Policies represent business functions and goals. These correspond to
network services, which are provided by vendor-specific network
elements. The problem is that vendors will describe the same business
function in different ways. This is because business functions are
described at a necessarily high level, and are therefore subject to
different interpretation. Since the network will implement the services
that correspond to these business functions, differences in network
elements will exacerbate this mapping.

A partial solution is to enforce a consistent representation of policy. All policies MUST consist of a set of policy rules, and all policy rules MUST consist of a set of policy conditions and policy actions. This provides a consistent meta-structure for describing policy, enabling a vendor-independent exchange of policy information.

The policy structure should be amenable to implementing simple policies in a correspondingly lightweight fashion. Hence, simple policy rules are rules whose conditions and actions can be embedded in the policy rule directly. Complex policy rules view the policy rule as a container, in which separate policy condition and/or policy action objects are aggregated.

This structure provides a flexible and extensible representation of policy. However, it does not guarantee interoperability. One possible solution is to use a canonical representation of policy rules, policy conditions and policy actions. This in turn requires a categorization of policy rule, policy condition, and policy action into a set of application-specific domains (e.g., RSVP and Differentiated Services would have separate policy conditions and actions that identify their applicability).

Given a class-based implementation of policy, the above could be
implemented easily through defining subclasses that corresponded to
the different policies, policy rules, policy conditions, and policy
actions that were under control of the PDP. This will be discussed more in [PLYARCH].


5. Policy Terminology

The following is a set of policy terminology definitions.

5.1 Policy Group

A PolicyGroup is a named object that represents an aggregation of
PolicyRules. The policy encompassed within a PolicyGroup can describe
the overall business function(s) to be accomplished, while the set of
policy rules define how those business functions will be met. In this
case, the business function(s) correspond to one or more SLOs of an SLA.





Strassner and Ellesson      Expires 23 December 1999          [Page 17]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

Alternatively, the PolicyGroup aggregation could be used to group
PolicyRules or other PolicyGroups for the purposes of scoping the
jursidiction of the policies, or for the purpose of making the
administration of the policies more conveniently accessible to those
who are assigned to perform this administration.

5.2 PolicyRule

A PolicyRule is composed of a set of conditions and a corresponding
set of actions. This combination in effect defines a sequence of
actions to be executed when the corresponding set of conditions is
either satisfied or not satisfied. For simplicity, it is recommended
that positive (satisfaction) and negative (unable to meet) conditions
be realized as separate rules that are folded into a single PolicyRule object.

Each PolicyRule is a declarative statement consisting of a Boolean
expression that describes a situation to which the policy applies.
In its most general form, when the expression is true, one set of
actions is initiated, and when false, a different set of actions is
initiated. This version of the document will only consider the expression of a rule as a condition statement (e.g., IF some set of conditions are met, THEN take this set of actions).

5.3 Policy Condition

Policy Conditions consist of two parts, a policy condition type and a
policy condition element. This structure is aimed at satisfying the
need for a canonical representation of a policy condition.

A policy condition type is a set of predefined conditions that can be
attached to a policy rule for evaluation. This canonical set of
conditions represent common conditions that all network vendors can
implement. By including this canonical representation of policy
conditions, the resulting set of policy conditions can be exchanged
between multiple vendors' policy servers. This is necessary for
interoperability as well as for a policy server to be able to parse
rules to determine if any rules conflict may potentially conflict
with each other. A policy condition element is a policy condition type
instance that is being evaluated. Policy condition
elements are related together to form a Boolean expression. The
relations can be one of the following operators:  in, not in, equal,
not equal, less than, less than or equal, greater than, and greater
than or equal.  (Note:  These operators are to be captured in the
ExpressionCondition object of the information model current at the
time of this writing, as well as in discipline-specific schema
subclassed from the core information model that are yet to be defined).








Strassner and Ellesson      Expires 23 December 1999          [Page 18]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

5.4 Policy Action

A policy action is the changing of the configuration of one or more
network elements in order to achieve a desired policy state. This (new)
policy state provides one or more (new) behaviors. As with policy
conditions, a policy action is comprised of two parts, a policy action
type and a policy action element. The policy action type defines a
canonical set of operations or treatments that can be given to traffic
flowing into the network element (e.g., deny, change code point, etc.)
that is vendor-independent. Similarly, the policy action element
specifies the type of mechanism and/or attribute values to be used to provide the specified operation or treatment.

5.5 Policy Decision

A policy decision is the abstraction of activating and evaluating one
or more policy rules. Each policy rule is interpreted in the context
of a specific request (implied or explicit) for accessing and/or using
one or more resources. It connotes taking one or more pre-determined
actions based on whether or not a given set of policy conditions were
satisfied.

5.6 Policy Behavior

A policy behavior controls how traffic is treated, what network
resources must be utilized, and/or what network services are provided.
Policy behaviors define one or more mechanisms that are used to
implement the policy. Therefore, different devices can carry out the
same policy using different behaviors.

For example, one router might use a dropping behavior and another might use a queuing behavior during times of congestion in order to satisfy an overall delivery goal. Policy behaviors can include one or more of the following:

  - permit or deny forwarding of traffic based on:
    - source and destination address
    - source and destination port number
    - protocol type and options
    - other factors specific to vendor implementations, such as host
      name and/or time of day
  - permit or deny access to a requested resource or service
  - encrypt the header and/or the payload
  - mark or remark the packet
  - start or stop accounting and/or auditing
  - start or stop logging









Strassner and Ellesson      Expires 23 December 1999          [Page 19]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

5.7  Policy State

A policy state is a description of the settings of one or more network
elements. These settings correspond to providing the set of services to
be provided by the network. For example, a Service Level Agreement can
describe services contracted for by subscribers - this corresponds to a
state that various network elements must be put into in order to
provide those services.


5.8 Effect of Executing a Policy

A policy determines the behavior of one or more objects that it affects. This behavior takes one of three basic forms:

  - allocate (or deny) resources to a given requestor
  - add or remove resources to a client already using a service that
    the policy controls
  - allow or prohibit access to a resource

The first two types of policy are contractual policies - they provide resources for a service. The last is an authorization policy - it defines what clients are permitted to do.

5.9  Policy Domain

A policy domain is a collection of objects that have been explicitly grouped together in order to administratively share the same policies. Domains can be nested, in order to reflect hierarchical semantics. Examples are organizational structures, subnets, and a grouping of policies that supply (for example) increasing freedom and/or privileges at lower and lower levels.

A domain does not encapsulate the objects it contains; rather, it holds references to objects that it contains. A domain is thus very similar in concept to a directory or folder in a file system.

Domains can be nested within domains. Note, however, that a nested domain is not necessarily a subset of the parent domain, because an object in the nested domain may not be a direct member of its parent domain.

Policy domains provide a convenient abstraction for specifying policy for individual objects within a large system. Policy domains separate the policy from the entities that the policy affects. This enables the domain membership to be changed without having to change the policy, and vice-versa. It also provides the flexibility to add and remove objects from a policy domain without changing the definition of the policy itself.








Strassner and Ellesson      Expires 23 December 1999          [Page 20]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

5.10  Policy Conflict

A policy conflict occurs when the conditions of two or more policies
can be simultaneously satisfied, but the actions of at least one of
the policies can not be simultaneously executed. This implies
several things:

  - one or more policy rules of each of the policies is satisfied by
    the same request
  - each condition of each of the conflicting policy rules is satisfied
    by the same request
  - one or more actions specified by one policy conflict with one or
    more actions specified by the other policy

Policy conflicts can be resolved in a number of different ways. The
simplest is to change the conditions and/or actions of one of the
policies so that it no longer conflicts with the other policies.
However, if the policies must remain inherently conflicting, then there
are a number of ways to resolve the conflict on an individual event
basis, including the following:

  - apply a "match-first" criteria, wherein conflicts are resolved by
    matching the first policy that is found
  - apply a priority order criteria, wherein conflicts are resolved by
    finding all policy rules which match a given event and selecting
    only the rule with the highest priority
  - use additional metadata to determine which rule or rules should be
    applied.


5.10.1 Global Conflict Detection

Global conflict detection refers to the ability to detect conflicts that do not affect any one specific object. For example, two policies both select the same user; one gives him GOLD service and the other gives him Bronze service. Another example: one policy says that engineers get GOLD service, and a second policy says that FTP traffic gets Bronze service; what happens when an engineer uses FTP? Since these types of global conflicts do not affect any one specific object, they can be resolved by a centralized component or by each individual PDP.

5.10.2  Local Conflict Detection

Local conflict detection refers to conflicts that affect specific devices, and/or topology-specific conditions that have conflicting actions. In either case, this type of conflict does affect specific objects. For example, one policy could specify a PHB with 3 queues, while a second policy could specify a PHB with 6 queues. If both of these policies are assigned to the same interface, then there is a local conflict. Note that the global conflict detection component would not have caught this, because it appears that these two policies do not conflict (one has 3 queues and one has 6 queues). It is only when the policies are applied to the network element that this conflict can be detected.

Strassner and Ellesson      Expires 23 December 1999          [Page 21]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

5.11 Service Level Agreement (SLA)

An SLA is a service contract between a customer and a Service Provider
that specifies the expected operational characteristics of their
relationship. Example operational characteristics include the details
of the treatment which a customer's traffic and/or requests for
service should receive. The details of the operational characteristics
are defined in terms of Service Level Objectives (SLOs). The SLA
documents the agreed levels and parameters of services provided, and
can cover a wide range of parameters including items that effect
the network element and items that don't (e.g., service hours and
availability, user support levels, etc.).


5.12  Service Level Objective (SLO)

An SLO partitions an SLA into individual objectives that can be mapped
into policies that can be executed. The SLOs define metrics to enforce,
police, and/or monitor the SLA. Some commonly used metrics to determine
whether or not an SLA is being fulfilled include component system
availability (e.g., up-time and MTBF), performance (e.g., response
time), and serviceability (e.g., MTTR).


5.13 Policy Event

A policy event is a notification that triggers one or more policy
evaluations. A particular event may or may not initiate a policy
decision and/or a policy enforcement action.  (Note that events are
not explicitly recognized in the schema or framework at the time of
this writing.  Events can be thought of as implicitly requesting
a policy evaluation, when appropriate.)


5.14 Policy Evaluation

Policy evaluation is the determination of whether or not the network
(or a part of it) is in a desired policy state. This is usually
determined by processing static and/or dynamic data against one or more
policy rules, the key point being that the decision is made by
comparing definitional data stored in the policy repository with
current data from the network that does not have to be stored in the
policy repository. If it is found that the network elements are not in
the desired policy state, then one or more policy actions will be taken
to move the network elements from their current state to the desired
state. This is called policy enforcement.








Strassner and Ellesson      Expires 23 December 1999          [Page 22]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

5.15 Policy Enforcement

Policy enforcement is the action of placing the network (or a part of
the network) in a desired policy state using a set of management
commands. When this definition is applied to network elements, these
management commands change the configuration of the device(s) using
one or more mechanisms. Enforcement is carried out in the context of a
policy rule.


5.16 Policy Monitoring

Policy monitoring is an on-going active or passive examination of the
network and its constituent devices for checking network health,
whether policies are being satisfied, and whether clients are taking
unfair advantage of network services. This is done for one or more
of the following reasons:

  - to ensure that clients are receiving the services that they have
    contracted for
  - to monitor network statistics as part of checking network health
  - to monitor network statistics as part of checking whether policies
    that are currently in use are being satisfied
  - to ensure that clients of a given set of policies are not abusing
    their privileges


5.17 Policy Agent

A policy agent is a software module that generates and responds to
policy events, evaluates policies, and enforces policies.


5.18 Policy-Driven Service

A policy-driven service is a set of cooperating policy agents that
define, manage, enforce, and monitor a particular policy.


5.19 Policy Audit

A policy audit examines conditions in one or more active policies
to determine if their actions are being executed correctly and the
desired result (e.g., flow of traffic) is being carried out. This
is equivalent to checking the state of the network to determine the set
of policies that are and are not being satisfied.








Strassner and Ellesson      Expires 23 December 1999          [Page 23]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

5.20 Policy Consistency Checking

Policy consistency checking is an analysis of currently active policies
to determine their consistency or possible inconsistency with each
other.  When an inconsistency is discovered, a policy discrepancy is
reported.

5.21 Policy Discrepancy

A policy discrepancy is a notification that two or more policies are in
actual or potential conflict in the sense that implementation of one
policy may prevent or otherwise adversely effect the implementation of
the other policies.

5.22 Policy Mechanism

A policy mechanism is a set of vendor-specific commands that configures
a network element to put a policy rule into effect.

5.23 Policy Verification

Policy verification is an analysis of a policy to determine if the
desired state can be established and maintained for the duration of
the corresponding policy rule being active.

5.24 Policy Restoration

Policy Restoration is one or more actions taken to restore the system
to a desired policy state. This could be invoked because of a policy
action in response to an event, or because the current state got
corrupted.


5.25 Roles

In the most general sense, a role describes the duties, rights, and
permissions of an object with respect to the rest of the managed environment.

Specifically for the Policy Framework working group, a role is realized
via the collection object in the policy information model.  This collection object aggregates a network object with other objects that a policy is to be applied to. A role is therefore a means of grouping together a set of objects, so that one or more policies can be specified as being applied to the entire group of objects. This provides a better means of abstraction that relying on one or more attribute values to group the objects.

For example, the role (collection object, in our info model) "edge interface" can be assigned to the interface of devices to distinguish them for other interfaces, such as "backbone interface", that perform different functions. This enables all devices that have interfaces matching one of these roles to be referred to by using the descriptive role name, as opposed to having to list a set of IP addresses with their masks.


Strassner and Ellesson      Expires 23 December 1999          [Page 24]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

Roles can be used to identify specific objects (e.g., device interfaces) that should be configured in a common manner using one or more policies. These interfaces may be defined by the purpose that they play in the network (e.g., "edge" vs. "backbone"), the characteristics of the object (e.g., frame relay interfaces require a different configuration than ATM interfaces), or other factors.

"Roles" provide a powerful abstraction mechanism. They enable new policies to be specified for a single role, and have them applied to the devices that use that role. This is much more efficient and less error prone than having to specify a new policy for each and every individual network component. In addition, it enables policies to be modified at the (single) role level, instead of having to search for every occurrence of every policy and individually modify the policy.
But most importantly, it enables the devices and their interfaces to be abstracted from the Policy Server. In other words, the Policy Server no longer needs to have intimate knowledge of each and every device (let alone each and every device interface!) in the network.

At the device (PEP) level, a role is modeled as a collection of interfaces with common interface functions,  or collection of objects that contain the common interfaces. In either case, more than one role per object can be defined (see Role Combinations, section 5.25.1, below).


5.25.1 Role Combinations

Role combinations enable an interface to be described by multiple roles. Thus, an object could belong to multiple roles, which is implemented as. multiple collection objects (e.g., "IP Interface", "Classification", and "Edge"). Each of these roles identify particular functions that the object performs in the network, which has its own set of configuration,
or authorization, or other specific functions that are controlled by policy.


6. Policy Example

This section will provide an example of the canonical use of
policies, policy rules, policy conditions and policy actions.
(Note that we are making assumptions here regarding discipline-specific
subclasses of PolicyCondition and PolicyAction, for the purposes
of this example. At the time of this writing, these discipline-specific
subclasses have not yet been defined.)

Assume that the following business rule is to be implemented as
a policy:

   Provide the JitterFreeMPEG2 video service for authorized users
    between authorized points, but only at agreed-upon times





Strassner and Ellesson      Expires 23 December 1999          [Page 25]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

This rule can be loosely translated as:

        IF user IN ApprovedUsers AND service IN VideoServices AND
        source IN VideoSources AND destination IN VideoDestinations
        AND time IN ApprovedTimePeriods
        THEN provide JitterFreeMPEG2

The policy condition is loosely translated as:
        IF the user is a member of an approved group (ApprovedUsers)
          that are authorized to have this service)
        AND the service requested is one supported (VideoServicesgroup)
        AND the source of the request is approved (in the VideoSources
          group or has been authenticated)
        AND the destination is approved (in the VideoDestinations group
          or has been authenticated)
        AND the time requested is OK (in ApprovedTimePeriods)

Here, the policy condition types are:
    user, service, source, destination, and time
and the policy condition elements are:
    ApprovedUsers, VideoServices, VideoSources, VideoDestinations,
    and ApprovedTimePeriods, which are all instances of pre-defined
    groups of objects.

The policy action is:
    IF the conditions are satisfied
       THEN provide the user with video having a QoS defined by the
            JitterFreeMPEG2 service

Note that this policy could require "sub-policies" in order for it to
be implemented. For example, RSVP requests might be used to
precondition the path between VideoSources and VideoDestinations.


7. Terminology For Implementing Policy GUIs

Part of the task of defining policy terminology is to enable policies
to be represented in a user-friendly GUI. This section provides
guidelines for doing this through the introduction of additional
terminology designed expressly for this purpose.


7.1 Types Of Policies

An effective policy GUI MUST be able to categorize and sort policies in
ways that are meaningful to the user. There are three broad means of
doing this, based on differentiating between how a policy is used,
how a policy is triggered, and the attributes of the policy.






Strassner and Ellesson      Expires 23 December 1999          [Page 26]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

7.2 How A Policy Is Used - Service And Usage Policies

Service and Usage Policies are a means of categorizing policies by what
they do and how they are used. Service policies describe services
available in the network. Usage policies describe which policies will
use which services when the conditions of the usage policies are satisfied. Usage policies describe particular mechanism(s) employed to either maintain the current state of the object, or to transition an object from one state to a new state, in order to utilize the specified services.

For example, the fact that a user can get a particular conditioning
treatment, or can use IPSEC to encrypt the payloads of traffic, are
both services that are provided and are represented as service
policies. On the other hand, differentiating between two flows and
assigning different services to the flows is an example of using usage
policies to differentiate the handling of the flows.


7.3 Classifying Policies Based On Attributes

Policies can be classified by the attributes that they possess. This
includes what the policy applies to (e.g., a class of user or a certain
type of application) as well as certain attributes that fundamentally
change the applicability (conditions) and effect (actions) of the
policy. Examples of these include physical location. For example, if a
user is connected to his or her corporate Intranet through the public
internet, then a different security policy might be applied to that
communication and different restrictions may be placed on accessing
resources than when that user connects through the corporate network.


8. Security Considerations

Security and denial of service considerations are not explicitly
Considered in this memo, as they are appropriate for the underlying
policy architecture and not for its terminology. However, the policy
architecture must be secure as far as the following aspects are concerned.
First, the mechanisms proposed under the framework must minimize theft
and denial of service threats. Second, it must be ensured that the entities
(such as PEPs and PDPs) involved in policy control can verify each other's
identity and establish necessary trust before communicating. This terminology
draft reinforces the need for policies to be secure.


9. Acknowledegments

Many thanks to the useful discussions and suggestions from the Internet
Community at large but especially to Andrea Westerinen, John Lee,
Lee Rafalow, Steve Schleimer and Fred Baker.





Strassner and Ellesson      Expires 23 December 1999          [Page 27]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

10. References

 [TERMS]    S. Bradner, "Key words for use in RFCs to Indicate
            Requirement Levels", Internet RFC 2119, March 1997.
 [DIFFARCH] D. Black, S. Blake, M. Carlson, E. Davies, Z. Whang,
            W. Weiss, "An Architecture for Differentiated Services",
            RFC2475,
            December 1998
 [DIFFSERV] K. Nichols and S. Blake, "Definition of the
            Differentiated Services Field (DS Byte) in the
            IPv4 and IPv6 Headers", RFC2474, December 1998
 [DSFIELD]  K. Nichols and S. Blake, "Definition of the Differentiated
            Services Field (DS Byte) in the IPv4 and IPv6 Headers",
            Internet Draft <draft-ietf-diffserv-header-00.txt>,
            May 1998.
 [LDAP]     This refers to the current collection of LDAP RFCs
            (2251 - 2256) but especially to RFC 2251 (the protocol).
 [RAPFRAME] R. Yavatkar, D. Pendarakis, R. Guerin, "A Framework for
            Policy-based Admission Control", Internet Draft,
            <draft-ietf-rap-framework-01.txt>, May 1998
 [PLYARCH]  G. Waters, et. al., Policy Framework Architecture,
            Internet Draft, <draft-ietf-policy-arch-00.txt>,
            June 1999, and subsequent revisions/replacements of this
            document.
 [CIM]  CIM Specification and CIM Schemata are available at:
                http://www.dmtf.org/spec/cims.html

 [ISWG] Integrated Services Working Group, whose home page is:
            http://www.ietf.org/html.charters/intserv-charter.html

 [DSWG] Differentiated Services Working Group, whose home page is:
                http://www.ietf.org/html.charters/diffserv-charter.html

 [RAPWG]        RSVP Admission Policy Working Group, whose home page is:
                http://www.ietf.org/html.charters/rap-charter.html

 [ISSLLWG]      Integrated Services over Specific Link Layers,
            whose home page is:
            http://www.ietf.org/html.charters/issll-charter.html

 [IPSECWG]      IP Security Protocol Working Group, whose home page is:
                http://www.ietf.org/html.charters/ipsec-charter.html












Strassner and Ellesson      Expires 23 December 1999          [Page 28]


INTERNET DRAFT        draft-ietf-policy-terms-02.txt       23 June 1999

11.  Authors' Addresses

John Strassner
    Cisco Systems
    Bldg E
    190 West Tasman Drive
    San Jose, CA 95134
    Phone:  +1-408-527-1069
    Fax:    +1-408-527-2477
    E-mail:  johns@cisco.com

Ed Ellesson
   JDGA/501
   IBM Corporation
   4205 S. Miami Blvd.
   Research Triangle Park, NC 27709
   Phone: +1-919-254-4115
   Fax:   +1-919-254-6243
   E-mail: ellesson@raleigh.ibm.com

12. Full Copyright Statement

Copyright (C) The Internet Society (1999).  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 on an
   "AS IS" basis and 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.






Strassner and Ellesson      Expires 23 December 1999          [Page 29]