[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

   INTERNET-DRAFT                                          Fran Reichmeyer
   Expires: June 2000                                           IP Highway
   Document: draft-reichmeyer-polterm-terminology-00.txt      Dan Grossman
                                                                  Motorola
                                                            John Strassner
                                                                     Cisco
                                                           Matthew Condell
                                                          BBN Technologies



                  A Common Terminology for Policy Management

                   <draft-reichmeyer-polterm-terminology-00.txt>
                      Thursday, March 09, 2000, 10:52 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 made obsolete 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.


   Copyright Notice

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

   Abstract

     This memo defines a common vocabulary for describing concepts and
     components related to policy management.  It is intended to be used
     to align terminology and concepts in architecture and framework
     documents that either address policy management or which specify
     components and services that are subject to policy management.









   Reichmeyer, et. al.     Expires: September 2000                [Page 1]


   Internet Draft   draft-reichmeyer-polterm-terminology-00.txt   March 2000

     Table of Contents

     1. Introduction.....................................................3
     2. Terms for Describing Approaches to Policy........................4
        2.1. Policy......................................................4
        2.2. Policy Management...........................................4
        2.3. Policy Administration.......................................4
        2.4. Policy Management Area......................................4
        2.5. Policy Domain...............................................5
        2.6. Meta-policy.................................................5
        2.6.1. Introduction..............................................5
        2.6.2. Definition................................................6
     3. Terms describing Policy-based Network Management Models..........6
        3.1. Introduction................................................6
        3.2. Outsourced Policy...........................................6
        3.3. Provisioned Policy..........................................6
        3.4. Interactive Policy..........................................6
     4. Policy Abstraction and Scoping...................................7
        4.1. Introduction................................................7
        4.2. Levels of abstraction.......................................7
        4.2.1. Administrator-defined policy..............................7
        4.2.2. Device-independent policy.................................8
        4.2.3. Device-dependent policy...................................8
        4.3. Scoping with Roles..........................................8
     5. Terms Concerning Modeling and Representation of Policy...........8
        5.1. Information Model...........................................8
        5.2. Data Model..................................................9
        5.3. Schema......................................................9
        5.4. Composition of policies.....................................9
        5.4.1. Policy Group..............................................9
        5.4.2. Policy Rule...............................................9
        5.4.3. Policy Condition..........................................9
        5.4.4. Policy Action.............................................9
        5.5. Policy Meta-data...........................................10
     6. Terms for Describing Policy Functions...........................10
        6.1. Introduction...............................................10
        6.2. Policy Storage and Retrieval...............................10
        6.3. Policy Conversion..........................................10
        6.4. Policy Discovery...........................................11
        6.5. Policy Resolution..........................................11
        6.6. Policy Translation.........................................11
        6.7. Policy Control.............................................11
        6.7.1. Policy Conflict..........................................11
        6.7.2. Policy Conflict Resolution...............................12
        6.7.3. Policy Satisfiability....................................12
        6.7.4. Policy Feasibility.......................................12
        6.8. Policy Decorreltation......................................12
     7. Terms for describing Functional Elements and Policy Topologies..12
        7.1. Introduction...............................................12
        7.2. Policy Administrator.......................................13
        7.3. Policy Repository..........................................13


   Reichmeyer, et. al.          September 2000                    [Page 2]


   Internet Draft   draft-reichmeyer-polterm-terminology-00.txt March 2000

     8. Terms Describing Interactions Between Policy Components.........13
        8.1. Access Protocol(s).........................................13
        8.2. Policy Requests............................................13
        8.3. Policy Decisions...........................................13
        8.4. Policy Evaluation..........................................13
        8.5. Policy Enforcement.........................................14
        8.6. Policy Monitoring..........................................14
        8.7. Policy Feedback............................................14
     9. Terms describing specific policies..............................14
        9.1. Introduction...............................................14
        9.2. Terms related to Service Levels............................14
        9.2.1. Service Level Agreement (SLA)............................15
        9.2.2. Service Level Specification (SLS)........................15
        9.3. Terms related to security policies.........................15
     10. Security Considerations........................................15
     11. Author's Addresses.............................................15
     12. References.....................................................16
     13. Full Copyright Statement.......................................16



   1. Introduction

     A policy management framework must be realized to provision and
     configure operational policies related to services and network
     operations.  Performance objectives (such as those addressed by the
     Intserv and Diffserv frameworks) and security are examples of
     service aspects which may have policies associated with them.
     Policies may also apply to network operations, e.g., for managing
     policies for monitoring.

     It is highly desirable that such a policy management framework be
     as common as possible, so as to allow policies for any operational
     area to  be expressed in a uniform manner.  This has been the
     subject of activities in several IETF working groups.

     This memo defines a common vocabulary for describing concepts and
     components related to policy management.  It does not describe an
     architecture or framework.  Instead, it is intended to be used by
     various IETF working groups to align their terminology and concepts
     in architecture and framework documents which either address policy
     management or which specify components and services that are
     subject to policy management.

     This memo is a product of the Policy Terminology (POLTERM) BOF.








   Reichmeyer, et. al.          September 2000                    [Page 3]


   Internet Draft   draft-reichmeyer-polterm-terminology-00.txt March 2000

   2. Terms for Describing Approaches to Policy

   2.1. Policy

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

     Policy Representation in the Policy Framework WG Specific examples
     of policy representation can be found in the Policy Framework
     Architecture [ref]

   2.2. Policy Management

     Policy management is the area of network management that deals with
     the control of policies within a network, including installing and
     deleting policy rules at network devices and monitoring network
     performance related to the installed policy. Policy management is
     concerned with the overall behavior of the network, i.e. end-to-end
     or edge-to-edge, and controls policy based on the ability to
     provide consistent and predictable network services across the
     entire network, not just on a device-by-device basis.

   2.3. Policy Administration

     Policy administration is the function that creates, modifies and
     deletes policies, typically based on human input.

   2.4. Policy Management Area

     A Policy Management Area is an area of networking that deploys
     policy and policy management for the purpose of controlling various
     aspects of the network, network resources, and access to them by
     the applications and users of the network. Examples include
     Security, Diffserv, etc. Distinct Policy Management Areas may be
     represented by the interfaces presented by policy management
     systems, but this separation does not extend to the underlying data
     models and information that will be required to implement policies.





   Reichmeyer, et. al.          September 2000                    [Page 4]


   Internet Draft   draft-reichmeyer-polterm-terminology-00.txt March 2000

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

   2.6. Meta-policy

   2.6.1. Introduction

     The concept of a policy is expressible in different ways for
     different consumers of the policy. For example, a system
     administrator might want to express a policy that configures
     network elements in business terms. That same policy must therefore
     be translated into a form that enables devices supporting this
     business rules to be configured. This is conceptually the same
     policy, but there are two distinctly different representations of
     that policy that must be related to each other. This is because the
     goal of policy is to relate the management aspects (e.g., business
     rules) of the policy to actions executed in a device. At each level
     of abstraction, there is a universal set of all possible policies
     (e.g., different variations of queuing mechanisms).  However, a
     policy element might elect to support only a subset of the
     universal set.  By selecting such a subset, it in effect makes a
     policy decision that constrains other policy decisions.


   Reichmeyer, et. al.          September 2000                    [Page 5]


   Internet Draft   draft-reichmeyer-polterm-terminology-00.txt  March 2000

   2.6.2. Definition

     A meta-policy is a policy that defines how policies are made, or
     how to build other policies. Note, this is not to be confused with
     policy meta-data (see section 5).


   3. Terms describing Policy-based Network Management Models

   3.1. Introduction

     Three models for policy management are identified in the sections
     below.  These three models represent different ways of expressing
     the implementation and execution of policies. Primarily, the
     network services and resources that are being managed dictate
     network policies and the method used to access them by the users of
     the network.

   3.2. Outsourced Policy

     An outsourced policy model implements policy by having some
     components of the policy framework rely upon other components of
     that same framework to perform policy-related decisions. This model
     locates the policy decision-making function in a component separate
     from the device where the policy is executed.   An outsourced
     policy model is a client-server model. There is a well defined,
     real-time interaction between components in an outsourced policy
     model.

   3.3. Provisioned Policy

     A provisioned policy model implements policy by configuring devices
     that execute policy prior to the events that will prompt decisions.
     Configuration is pushed to the device, e.g., based on time of day
     or at initial booting of the device.  The focus of the provisioned
     policy model is on the distribution of configuration information.
     Events received use downloaded (pre-provisioned) mechanisms to
     implement  policy; thus, there is no real-time interaction between
     systems in this model. There is a well-defined interaction between
     components, but the interaction does not necessarily occur on a
     real-time basis.

   3.4. Interactive Policy

     An interactive policy model implements policy by installing policy
     expressions within appropriate components of the system. This
     includes complete and self-contained expression of policy data and
     rules that defines interaction between a process and its
     constituent components. The focus is not on distribution of policy
     rules and data, but rather on naming and being able to refer
     unambiguously and in a consistent, uniform manner to the


   Reichmeyer, et. al.          September 2000                    [Page 6]


   Internet Draft   draft-reichmeyer-polterm-terminology-00.txt  March 2000


     information required by the process responsible for implementing
     the given policy. Interaction between components is defined on a
     system-specific basis. For example, the network in the general case
     consists of a variety of different devices, each of which has
     different capabilities. This means that their specific
     configuration may vary device to device, but their overall handling
     of traffic (as a simple example) should be conceptually as uniform
     as possible. So in general there needs to be an interactive
     communication between the policy server making the decision and the
     set of devices that it controls that are implementing the decision.




   4. Policy Abstraction and Scoping

   4.1. Introduction

     Policy can be expressed using different levels of abstractions.
     Roles provide a way to scope policy, at the various levels of
     abstraction, to portions of the network where they apply. A policy
     is expressed as a set of related policies at different levels of
     abstraction. This is because the goal of policy is to relate the
     management aspects (e.g., business rules) of the policy to actions
     executed in a device. For example, high-level policies that
     describe how the network should treat different types of traffic
     may be expressed in a way that is independent of any one particular
     way of configuring a device. Yet, we still need to develop policies
     at a lower level that are used to configure specific devices that
     actually condition the traffic according to these business rules.
     This relation exists to enable different network vendors and
     different types of devices to be provisioned in a common way. So,
     we need to translate between the different representations of
     policies in a common and consistent way.  Three levels of
     abstraction have been identified.



   4.2.  Levels of abstraction

   4.2.1. Administrator-defined policy

     An administrator-defined policy is a policy that is expressed in
     human-oriented terms of rules which convey organizational or
     operational goals, independent of any of the details of how or
     where the policy will be implemented. For example, the Sales
     Organization runs a different set of applications compared to the
     Engineering Organization, and requires different conditioning of
     their traffic compared to that of the Engineering Organization.




   Reichmeyer, et. al.          September 2000                    [Page 7]


   Internet Draft    draft-reichmeyer-polterm-terminology-00.txt  March 2000

   4.2.2. Device-independent policy

     A device-independent policy is a policy that is expressed in terms
     of rules that describe conditions and actions to be taken by a
     device in a generic (i.e., implementation-independent) fashion. For
     example, multiple device-dependent policies could be derived from a
     single device-independent policy. The single device-independent
     policy could be described in terms of using various DiffServ Code
     Points to designate different conditioning for different service
     classes. This device-independent policy specifies different
     conditioning to be implemented for different traffic types
     independent of the type of device that is implementing the traffic.

   4.2.3. Device-dependent policy

     A device-dependent policy is a policy that is expressed in terms of
     rules that describe the conditions and actions to be taken by a
     specific device in terms that are particular to a given
     implementation. Continuing the example used in "device-independent
     policy," a set of device-dependent policies are defined that
     express how different devices are configured to express the
     conditioning defined in the single device-independent policy. Each
     device-dependent policy implements the same traffic conditioning
     instructions as specified by the device-independent policy, but in
     a device-specific way.

   4.3. Scoping with Roles

     Roles define groups of devices (or device interfaces) that want to
     share the same configuration of policy.



     For many policy rules, policy roles enable a more efficient
     implementation of policy. For example, roles can be used to
     identify a set of policies in a policy repository that are specific
     to what needs to be accomplished (e.g., find all edge frame relay
     policies and download them). However, for other types of policies,
     policy role mechanisms are insufficient. This is primarily because
     they by themselves are not sufficient to specify the mechanism that
     they are being used to control (e.g., the above example says
     nothing about configuring different queues in an interface) to
     scope them.


   5. Terms Concerning Modeling and Representation of Policy

   5.1. Information Model

     An information model is a representation of the entities in a
     managed environment and the way that they interact with each other.


   Reichmeyer, et. al.          September 2000                    [Page 8]


   Internet Draft    draft-reichmeyer-polterm-terminology-00.txt  March 2000

     It is independent of any specific repository, application,
     protocol, or platform. A set of data models can be derived from an
     information model.

   5.2. Data Model

     A data model represents a mapping of the contents of an information
     model into a form that is specific to a particular type of
     repository. By binding to a repository, protocol and schema are
     also bound. However, it should be noted that additional platform-
     and application-specific mappings may be required.





   5.3. Schema

     A schema is a collection of data models that are each bound to the
     same type of repository.

   5.4. Composition of policies

     Policies are composed of four primary components, or building
     blocks. These are: policy group, policy rule, policy condition, and
     policy action. They are briefly defined here. For more complete
     definition and description of the relationships, see [ref].

   5.4.1. Policy Group

     A policy group is a group of policies or policy rules.

   5.4.2. Policy Rule

     A policy rule is a set of conditions and a corresponding set of
     actions.

   5.4.3. Policy Condition

     A policy condition defines the criteria for when a policy rule is
     to be enforced, that is, when the policy action associated with the
     policy rule is to be taken.

   5.4.4. Policy Action

     A policy action defines what is to be done to enforce a policy rule
     when the conditions of the policy rule are met.






   Reichmeyer, et. al.          September 2000                    [Page 9]


   Internet Draft   draft-reichmeyer-polterm-terminology-00.txt  March 2000

   5.5. Policy Meta-data

     Policy meta-data is a set of data that describes the semantics of a
     specific policy. For example, meta-data could be used to describe
     additional semantics that should be associated with a given
     attribute in a data or information model. Note, this should not be
     confused with a meta-policy (see section 2).




   6. Terms for Describing Policy Functions

   6.1. Introduction

     Policy elements can be described in terms of the functions that
     they perform. This section defines the basic functions deployed in
     a policy management system. No assumptions are made regarding the
     physical elements of the system that implement these functions.



   6.2. Policy Storage and Retrieval

     Policies and policy rules must be stored and retrieved from
     storage, as part of the policy management process. This allows for
     consistent and predictable application of policy across a network.
     Storage and retrieval can be implemented with different types of
     storage technologies (e.g. directories and relational databases),
     which in turn define the type of protocol(s) that is (are) used to
     access the policy data. Details on the different technologies,
     protocols, and the impact of using one versus another, is beyond
     the scope of this draft.

   6.3. Policy Conversion

     Policy conversion transforms policy information from a
     representation used in one part of the policy system to another one
     used elsewhere in the system. For example, a proxy policy server
     might convert PIB data (received from a policy server) to CLI
     format used to talk to its clients.  Policy conversion is a
     syntactical transform between representations at the same level of
     abstraction.










   Reichmeyer, et. al.          September 2000                   [Page 10]


   Internet Draft    draft-reichmeyer-polterm-terminology-00.txt  March 2000

   6.4. Policy Discovery

     In order to insure a communication can proceed between policy
     domains, a policy decision may depend upon knowledge of the
     policies of all policy domains that will affect the communication.
     Each policy domain will have to 'discover' the policies of the
     other domains in order to make the correct policy decisions.

   6.5. Policy Resolution

     Often misnamed policy negotiation, though no real negotiation takes
     place. When presented with policies from multiple policy domains,
     through which a communication must pass, it is necessary to find a
     common policy supported by all the domains. If no such policy
     exists, then the communication cannot be completed.

   6.6. Policy Translation

     Policy translation transforms a policy from a level of abstraction
     used in one part of the policy system to another level of
     abstraction used elsewhere; e.g., a user name gets 'translated' to
     an IP address. This is a semantic transform from a policy element
     at one level of abstraction to another.

   6.7. Policy Control

     Policy control deals with the processing of policy and policy
     rules, the installation, deletion, and monitoring of policy in the
     network. Before a new policy can be installed in the network, it
     must be verified by the policy management system that it will not
     conflict with other existing policy in the network, and that it can
     be executed correctly.

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





   Reichmeyer, et. al.          September 2000                   [Page 11]


   Internet Draft    draft-reichmeyer-polterm-terminology-00.txt  March 2000

   6.7.2. Policy Conflict Resolution

     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 meta-data to determine which rule or rules
     should be applied.



   6.7.3. Policy Satisfiability

     Policy satisfiability refers to determining if a policy can execute
     successfully or not. For example, a policy might result in
     reserving bandwidth of 10Mb. However, if only 8 Mb of bandwidth are
     available, then even though the conditions of the policy are
     satisfied, it can not be successfully executed, because enough
     resources do not exist.

   6.7.4. Policy Feasibility

     Policy feasibility refers to determining if a given policy can
     execute safely. This not only means that the policy itself can
     execute correctly, but that the execution of that policy will not
     adversely affect other policies that are already deployed.



   6.8. Policy Decorreltation




   7. Terms for describing Functional Elements and Policy Topologies

   7.1. Introduction

     Policies are managed and implemented in functional elements, which
     correspond to real devices.  Functional elements perform one or
     more functions. Functional elements are not limited to routers and


   Reichmeyer, et. al.          September 2000                   [Page 12]


   Internet Draft    draft-reichmeyer-polterm-terminology-00.txt  March 2000

     switches. For example, host systems and firewalls can also be
     considered functional elements in a policy framework.

   7.2. Policy Administrator

     A policy administrator is a functional entity thatà  performs
     policy administration function.

   7.3. Policy Repository

     A policy repository is a specific type of data store that is used
     to store policies and policy data. A mapping is required from the
     repository-independent information model that describes a policy to
     a repository-specific implementation of that policy. In general, a
     set of mappings may be made -one for each type of repository. For
     example, an auxiliary class is a concept that is specific to
     directories. A mapping for a directory may use auxiliary classes,
     whereas a mapping to a relational database can not use auxiliary
     classes.

     Note that different vendor implementations of the same type of
     repository may still require an additional mapping from a common
     data model. For example, you might have a directory data model, and
     then x additional mappings to account for the differences in how
     vendors implement the access protocol and specific mechanisms, such
     as auxiliary classes.


   8. Terms Describing Interactions Between Policy Components

   8.1. Access Protocol(s)

   8.2. Policy Requests

   8.3. Policy Decisions

     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.

   8.4. Policy Evaluation

     Policy evaluation is the determination of whether or not the entity
     or set of entities that is being controlled by the policy is in a
     desired policy state.





   Reichmeyer, et. al.          September 2000                   [Page 13]


   Internet Draft    draft-reichmeyer-polterm-terminology-00.txt  March 2000

   8.5. Policy Enforcement

     Policy enforcement is the action of placing the entity or set of
     entities that is under policy control in a desired policy state
     using a set of management commands. For example, 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.

   8.6. Policy Monitoring

     Policy monitoring is an on-going active or passive examination of
     the entity or set of entities that are under policy control. Policy
     monitoring is done for one or more of the following reasons:

     1)         to ensure that clients are receiving the services that they
have
        contracted for

     2)         to monitor statistics as part of checking the health of the
        entity that is under policy control

     3)         to monitor statistics as part of checking whether policies
that
        are currently in use are being satisfied

     4)         to ensure that clients of a given set of policies are not
        abusing their privileges

   8.7. Policy Feedback

     Closed loop feedback is important to policy networks. This ensures
     that implementing a policy does not put the system that is under
     policy control into an unstable state. It can be in the form of
     acknowledgments to decisions, verification of accounting records,
     and many other forms.


   9. Terms describing specific policies

   9.1. Introduction

     In some cases, terminology is defined to describe sets of policies
     related to one or more areas to which policy management is applied.

   9.2. Terms related to Service Levels

     One important application of policy is in management of service
     level commitments by a service provider to a service user.  This
     may be in the context of a commercial relationship between a
     service provider and a service user which are two separate entities
     (e.g., an ISP and a subscriber) or which are two entities within


   Reichmeyer, et. al.          September 2000                   [Page 14]


   Internet Draft    draft-reichmeyer-polterm-terminology-00.txt  March 2000

     the same organization (e.g., an IT organization and a functional
     department).



   9.2.1. Service Level Agreement (SLA)

     A service level agreement (SLA) is a service contract between a
     service user and a service provider that specifies the service a
     user should receive for all or a portion of their traffic.  An SLA
     includes  considerations of a business or contractual nature.

     Note: This term is a generalization of the term as used in
     Diffserv.



   9.2.2. Service Level Specification (SLS)

     A Service Level Specification (SLS) is a set of parameters and
     their values which together define the service offered to a traffic
     stream by a domain.  An SLS is that part of an SLA that is
     implementable as one or more policies.

     Note: This term is a generalization of the term as used in
     Diffserv.  Also, the term Service Level Objective (SLO) is also
     used.

   9.3.  Terms related to security policies


   10. Security Considerations

     Security considerations are addressed in the appropriate
     architecture and framework documents.


   11. Author's Addresses

     Francis Reichmeyer

     IPHighway, Inc.

     400 Kelby Street

     Fort Lee, NJ 07024

     Phone: +1 201 665 8714

     Email: franr@iphighway.com



     Dan Grossman


   Reichmeyer, et. al.          September 2000                   [Page 15]


   Internet Draft    draft-reichmeyer-polterm-terminology-00.txt  March 2000

     Motorola Inc.

     20 Cabot Blvd.

     Mansfield, MA 02048

     Phone: +1 508 261 5312

     Email: dan@dma.isg.mot.com



     John Strassner

     Cisco Systems

     170 West Tasman Drive, Bldg 15

     San Jose, CA  95134

     Phone: +1 408 527 1069

     Email:  johns@cisco.com





     Matthew Condell

     BBN Technologies

     10 Moulton St.

     Cambridge, MA 02138

     Phone: +1 617 873 6203

     Email: mcondell@bbn.com


   12. References


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


   Reichmeyer, et. al.          September 2000                   [Page 16]


   Internet Draft    draft-reichmeyer-polterm-terminology-00.txt  March 2000

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

     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.












































   Reichmeyer, et. al.          September 2000                   [Page 17]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/