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]