Policy Framework Working Group A. Westerinen
INTERNET-DRAFT J. Schnizlein
Category: Informational J. Strassner
Cisco Systems
Mark Scherling
xCert
Bob Quinn
Celox Networks
Shai Herzog
IP Highway
An-Ni Huynh
Lucent Technologies
Mark Carlson
Sun Microsystems
Jay Perry
Steve Waldbusser
April 2001
Terminology
<draft-ietf-policy-terminology-03.txt>
Thursday, April 19, 2001, 3:53 PM
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
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.
Westerinen, et al. Expires: Apr 2001 + 6 months [Page 1]
Internet Draft Policy Terminology April 2001
Abstract
This document is a glossary of policy-related terms. It
provides abbreviations, explanations, and recommendations for
use of these terms. The document takes the approach and format
of RFC2828 [R2828], which defines an Internet Security Glossary.
The intent is to improve the comprehensibility and consistency
of writing that deals with network policy, particularly Internet
Standards documents (ISDs).
Table of Contents
1. Introduction.................................................3
2. Explanation of Paragraph Markings............................4
3. Terms........................................................4
4. Intellectual Property.......................................16
5. Acknowledgements............................................17
6. Security Considerations.....................................17
7. References..................................................17
8. Authors' Addresses..........................................18
9. Full Copyright Statement....................................20
Westerinen, et al. Expires: Apr 2001 + 6 months [Page 2]
Internet Draft Policy Terminology April 2001
1. Introduction
This document provides abbreviations, definitions, and
explanations of terms related to network policy. All definitions
are provided in Section 3, with the terms listed in alphabetical
order.
The intent is to improve the comprehensibility and consistency
of Internet Standards documents (ISDs) - i.e., RFCs, Internet-
Drafts, and other material produced as part of the Internet
Standards Process [R2026]. Benefits across the ISDs are well-
stated in the Introduction to RFC2828 [R2828]:
o "Clear, Concise, and Easily Understood Documentation" -
Requires that the set of terms and definitions be consistent,
self-supporting and uniform across all ISDs.
o Technical Excellence - Where all ISDs use terminology
accurately, precisely, and unambiguously.
o Prior Implementation and Testing - Requires that terms are
used in their plainest form, that private and "made-up" terms
are avoided in ISDs, and that new definitions are not created
that conflict with established ones.
o "Openness, Fairness, and Timeliness" - Where ISDs avoid terms
that are proprietary or otherwise favor a particular vendor,
or that create a bias toward a particular technology or
mechanism.
Common and/or controversial policy terms are defined. These
terms are directly related and specific to network policy.
Wherever possible, this draft takes definitions from existing
ISDs. It should be noted that:
o Expired Internet-Drafts are not referenced, nor are their
terminology and definitions used in this document.
o Multiple definitions may exist across the ISDs. Each
definition is listed, with its source.
Westerinen, et al. Expires: Apr 2001 + 6 months [Page 3]
Internet Draft Policy Terminology April 2001
2. Explanation of Paragraph Markings
Section 3 marks terms and definitions as follows:
o Capitalization: Only terms that are proper nouns are
capitalized.
o Paragraph Marking: Definitions and explanations are stated in
paragraphs that are marked as follows:
- "P" identifies basic policy-related terms.
- "T" identifies various techniques to create or convey
policy-related information in a network. For example,
COPS and an "Information Model" are two techniques for
communicating and describing policy-related data.
- "A" identifies specific Work Groups and general "areas of
use" of policy. For example, AAA and QoS are two "areas
of use" where policy concepts are extremely important to
their function and operation.
3. Terms
Note: In providing policy definitions, other "technology
specific" terms (for example, related to Differentiated
Services) may be used and referenced. These non-policy terms
will not be defined in this document, and the reader is
requested to go to the referenced ISD for additional detail.
$ AAA
See "Authentication, Authorization, Accounting."
$ abstraction levels
See "policy abstraction."
$ action
See "policy action."
$ Authentication, Authorization, Accounting (AAA)
(A) AAA efforts in the IETF have focused on the most widely
deployed use of authentication: Remote Authentication Dial
In User Service (RADIUS), and its expansion in Diameter (a
"radius" pun and not an acronym). Referencing the RADIUS
RFC [R2138], a network access server sends dial-user
credentials to an AAA server, and receives authentication
that the user is who he/she claims along with a set of
attribute-value pairs authorizing various service features
for that user. Policy is implied in both the
authentication, which can be restricted by time of day,
Westerinen, et al. Expires: Apr 2001 + 6 months [Page 4]
Internet Draft Policy Terminology April 2001
number of sessions, calling number, etc., and the
attribute-values authorized. AAA efforts in the IRTF are
wider, for control, authentication, authorization and
accounting of systems and environments based on policies
set by the administrators and users of the systems.
$ CIM
See "Common Information Model."
$ Common Information Model (CIM)
(T) An object-oriented information model published by the DMTF
(Distributed Management Task Force) [DMTF]. It consists of
a Specification detailing the abstract modeling constructs
and principles of the Information Model, and a textual
language definition to represent the Model. CIM's schemas
are defined as a set of files, written in the language of
the Specification, with graphical renderings using UML
[UML]. Sets of classes and associations represent CIM's
Core and Common Models, defining an information model for
the "enterprise" - addressing general concepts (in Core),
and systems, devices, users, software distribution, the
physical environment, networks and policy (in the Common
Models). (See also "information model.")
$ Common Open Policy Service (COPS)
(T) A simple query and response TCP-based protocol that can
be used to exchange policy information between a Policy
Decision Point (PDP) and its clients (Policy Enforcement
Points, PEPs). [RFC 2748] (See also "Policy Decision Point"
and "Policy Enforcement Point.")
$ condition
See "policy condition."
$ configuration
(P) "Configuration" can be defined from two perspectives:
- The set of parameters in network elements and other
systems that determine their function and operation.
Some parameters are static, such as packet queue
assignment and can be predefined and downloaded to a
network element. Others are more dynamic, such as the
actions taken by a network device upon the occurrence of
some event. The distinction between static
(predefined) "configuration" and the dynamic state of
network elements blurs as setting parameters becomes
more responsive, and signaling controls greater degrees
of a network device's behavior.
- A static setup of a network element, done before
shipment to a customer and which cannot be modified by
the customer.
The first is the accepted usage in the Internet community.
Westerinen, et al. Expires: Apr 2001 + 6 months [Page 5]
Internet Draft Policy Terminology April 2001
$ COPS
See "Common Open Policy Service."
$ data model
(T) A mapping of the contents of an information model into a
form that is specific to a particular type of data store or
repository. A "data model" is basically the rendering of
an information model according to a specific set of
mechanisms for representing, organizing, storing and
handling data. It has three parts [DecSupp]:
- A collection of data structures such as lists, tables,
relations, etc.
- A collection of operations that can be applied to the
structures such as retrieval, update, summation, etc.
- A collection of integrity rules that define the legal
states (set of values) or changes of state (operations
on values).
(See also "information model.")
$ DEN
See "Directory Enabled Networks."
$ Differentiated Services (DS)
(T) The IP header field, called the DS-field. In IPv4, it
defines the layout of the ToS (Type of Service) octet; in
IPv6, it is the Traffic Class octet. [R2474]
(A) "Differentiated Services" is also an "area of use" for
QoS policies. It requires policy to define the
correspondence between codepoints in the packet's DS-field
and individual per-hop behaviors (to achieve a specified
per-domain behavior). (See also "Quality of Service.")
$ diffserv
See "Differentiated Services."
$ Directory Enabled Networks (DEN)
(T) A data model that is the LDAP mapping of CIM (the Common
Information Model). Its goals are to enable the deployment
and use of policy by starting with common service and user
concepts (defined in the information model), specifying
their mapping/storage in an LDAP-based repository, and
using these concepts in vendor/device-independent policy
rules. [DMTF] (See also "Common Information Model" and
"data model.")
$ domain
A collection of elements and services, administered in a
coordinated fashion. (See also "policy domain.")
$ DS
See "Differentiated Services."
Westerinen, et al. Expires: Apr 2001 + 6 months [Page 6]
Internet Draft Policy Terminology April 2001
$ filter
(T) A set of terms and/or criteria used for the purpose of
separating or categorizing. This is accomplished via
single- or multi-field matching of traffic header and/or
payload data. "Filters" are often manipulated and used in
network operation and policy. For example, packet filters
specify the criteria for matching a pattern (for example,
IP or 802 criteria) to distinguish separable classes of
traffic.
$ goal
See "policy goal."
$ information model
(T) An abstraction and representation of the entities in a
managed environment, their properties, attributes and
operations, and the way that they relate to each other. It
is independent of any specific repository, application,
protocol, or platform.
$ MIB
See "Policy Management Information Base."
$ MPLS
See "Multiprotocol Label Switching." (Also, MPLS may refer
to Multi-Protocol Lambda Switching in optical networks. But,
this is unrelated to policy and not discussed further in this
document.)
$ Multiprotocol Label Switching (MPLS)
(T) Integrates a label swapping and switching framework with
network layer routing [R2702]. The basic idea involves
assigning short fixed length labels to packets at the
ingress to an MPLS cloud. Throughout the interior of the
MPLS domain, the labels attached to packets are used to
make forwarding decisions (usually without recourse to the
original packet headers).
$ outsourced policy
(P) An execution model where a policy enforcement device
issues a query to delegate a decision for a specific policy
event to another component, external to it. For example, in
RSVP, the arrival of a new RSVP message to a PEP requires a
fast policy decision (not to delay the end-to-end setup).
The PEP may use COPS-RSVP to send a query to the PDP,
asking for a policy decision. [R2205, R2748] "Outsourced
policy" is contrasted with "provisioned policy", but they
are not mutually exclusive and operational systems may
combine the two.
$ PCIM
See "Policy Core Information Model."
Westerinen, et al. Expires: Apr 2001 + 6 months [Page 7]
Internet Draft Policy Terminology April 2001
$ PDP
See "Policy Decision Point."
$ PEP
See "Policy Enforcement Point."
$ PIB
See "Policy Information Base."
$ policy
(P) "Policy" can be defined from two perspectives:
- A definite goal, course or method of action to guide and
determine present and future decisions. "Policies" are
implemented or executed within a particular context
(such as policies defined within a business unit).
- Policies as a set of rules to administer, manage, and
control access to network resources. [R3060]
Note that these two views are not contradictory since
individual rules may be defined in support of business
goals. (See also "policy goal", "policy abstraction" and
"policy rule.")
$ policy abstraction
(P) Policy can be represented at different levels, ranging
from business goals to device-specific configuration
parameters. Translation between different levels of
"abstraction" may require information other than policy,
such as network and host parameter configuration and
capabilities. Various documents and implementations may
specify explicit levels of abstraction. However, these do
not necessarily correspond to distinct processing entities
or the complete set of levels in all environments. (See
also "configuration" and "policy translation.")
$ policy action
(P) Definition of what is to be done to enforce a policy rule,
when the conditions of the rule are met. Policy actions
may result in the execution of one or more operations to
affect and/or configure network traffic and network
resources.
- In [R3060], a rule's actions may be ordered.
$ policy condition
(P) A representation of the necessary state and/or
prerequisites that define whether a policy rule's actions
should be performed. This representation need not be
completely specified, but may be implicitly provided in an
implementation or protocol. When the policy condition(s)
associated with a policy rule evaluate to TRUE, then
(subject to other considerations such as rule priorities
and decision strategies) the rule should be enforced.
Westerinen, et al. Expires: Apr 2001 + 6 months [Page 8]
Internet Draft Policy Terminology April 2001
- In [R3060], a rule's conditions can be expressed as
either an ORed set of ANDed sets of statements
(disjunctive normal form), or an ANDed set of ORed sets
of statements (conjunctive normal form). Individual
condition statements can also be negated.
$ policy conflict
(P) Occurs when the actions of two rules (that are both
satisfied simultaneously) contradict each other. The entity
implementing the policy would not be able to determine
which action to perform. The implementers of policy systems
must provide conflict detection and avoidance or resolution
mechanisms to prevent this situation. "Policy conflict" is
contrasted with "policy error."
$ policy conversion
See "policy translation."
$ Policy Core Information Model (PCIM) [R3060]
(T) An information model describing the basic concepts of
policy groups, rules, conditions, actions, repositories and
their relationships. This model is described as a "core"
model since it cannot be applied without domain-specific
extensions (for example, extensions for QoS or IPsec). PCIM
is "core" with respect to the area of policy. However, it
is a "Common Model," with respect to CIM - in that it
extends the basic CIM concepts for policy. (See also
"Common Information Model.")
$ policy decision
(P) Two perspectives of "policy decision" exist:
- A "process" perspective that deals with the evaluation of
a policy rule's conditions
- A "result" perspective that deals with the actions for
enforcement, when the conditions of a policy rule are
TRUE
$ Policy Decision Point (PDP)
(P) A logical entity that makes policy decisions for itself
or for other network elements that request such decisions.
[R2753] (See also "policy decision.")
$ policy domain
(P) A collection of elements and services, and/or a portion
of an Internet over which a common and consistent set of
[..] policies are administered in a coordinated fashion.
[R2474] This definition of a policy domain does not
preclude multiple sources of policy creation within an
organization, but does require that the resultant policies
be coordinated.
Westerinen, et al. Expires: Apr 2001 + 6 months [Page 9]
Internet Draft Policy Terminology April 2001
- Policies defined in the context of one domain may need to
be communicated or negotiated outside of that domain.
(See also "policy negotiation.")
$ policy enforcement
(P) The execution of a policy decision.
$ Policy Enforcement Point (PEP)
(P) A logical entity that enforces policy decisions. [R2753]
(See also "policy enforcement.")
$ policy error
(P) "Policy errors" occur when attempts to enforce policy
actions fail, whether due to temporary state or permanent
mismatch between the policy actions and the device
enforcement capabilities. This is contrasted with "policy
conflict."
$ policy goal
(P) Goals are the business objectives or desired state
intended to be maintained by a policy system. As the
highest level of abstraction of policy, these goals are
most directly described in business rather than technical
terms. For example, a goal might state that a particular
application operate on a network as though it had its own
dedicated network, despite using a shared infrastructure.
'Policy goals' can include the objectives of a service
level agreement, as well as the assignment of resources to
applications or individuals. A policy system may be created
that automatically strives to achieve a goal through
feedback regarding whether the goal (such as a service
level) is being met.
$ Policy Information Base (PIB)
(T) Collections of related PRovisioning Classes (PRCs),
defined as a module. (See also "PRovisioning Class.")
$ Policy Management Information Base (MIB)
(T) Collections of policy-related managed objects, defined as
a module and accessed via an SNMP framework.
$ policy mapping
See "policy translation."
$ policy negotiation
(P) Exposing the desired or appropriate part of a policy to
another domain. This is necessary to support partial
interconnection between domains, which are operating with
different sets of policies.
Westerinen, et al. Expires: Apr 2001 + 6 months [Page 10]
Internet Draft Policy Terminology April 2001
$ policy repository
(P) "Policy repository" can be defined from three
perspectives:
- A specific data store that holds policy rules, their
conditions and actions, and related policy data. A
database or directory would be an example of such a
store.
- A logical container representing the administrative
scope and naming of policy rules, their conditions and
actions, and related policy data. A "QoS policy" domain
would be an example of such a container.
- In [R3060], a more restrictive definition than the prior
one exists. A PolicyRepository is a model abstraction
representing an administratively defined, logical
container for reusable policy elements.
$ policy request
(P) A message requesting a policy service. When sent by a
PEP to a PDP, it is more accurately qualified as a "policy
decision request." [R2753] (See also "policy decision.")
$ policy rule
(P) A basic building block of a policy-based system. It is
the binding of a set of actions to a set of conditions -
where the conditions are evaluated to determine whether the
actions are performed. [R3060]
$ policy server
(P) A marketing term whose definition is imprecise.
Originally, [R2753] referenced a "policy server." As the
RFC evolved, this term became more precise and known as the
Policy Decision Point (PDP). Today, the term is used in
marketing and other literature to refer specifically to a
PDP, or for any entity that uses/services policy.
$ policy translation
(P) The transformation of a policy from a representation
and/or level of abstraction, to another representation or
level of abstraction. For example, it may be necessary to
convert PIB data to a command line format. In this
"conversion," the translation to the new representation is
likely to require a change in the level of abstraction
(becoming more or less specific). Although these are
logically distinct tasks, they are (in most cases) blurred
in the act of translating/converting/mapping. Therefore,
this is also known as "policy conversion" or "policy
mapping."
$ PolicyGroup
(T) An abstraction in the Policy Core Information Model
[R3060]. It is a class representing a container,
aggregating either policy rules or other policy groups. It
Westerinen, et al. Expires: Apr 2001 + 6 months [Page 11]
Internet Draft Policy Terminology April 2001
allows the grouping of rules into a Policy, and the
refinement of high-level Policies to lower-level or
different (i.e., converted or translated) peer groups.
$ PRC
See "PRovisioning Class."
$ PRI
See "PRovisioning Instance."
$ provisioned policy
(P) An execution model where network elements are pre-
configured, based on policy, prior to processing events.
Configuration is pushed to the network device, e.g., based
on time of day or at initial booting of the device. The
focus of this model is on the distribution of configuration
information, and is exemplified by Differentiated Services
[R2475]. Based on events received, devices use downloaded
(pre-provisioned) mechanisms to implement policy.
"Provisioned policy" is contrasted with "outsourced
policy."
$ PRovisioning Class (PRC)
(T) An ordered set of attributes representing a type of policy
data. PRCs are defined in PIB modules (encoded using SPPI)
and registered in the Object Identifier tree. Instances of
each PRC are organized in tables, similar to conceptual
tables in SMIv2. (See also "Structure of Policy
Provisioning Information" and "Policy Information Base.")
The acronym, PRC, has evolved from "policy rule class" to
"provisioning class." The reason for the change is that a
discrepancy existed between the use of the words, "policy
rule" in the PRC context versus other uses in PCIM and the
industry. In the latter, rules are If/Then statements - a
binding of conditions to actions. PRCs are not "rules" by
this definition, but the encoding of (network-wide)
configuration information for a device.
$ PRovisioning Instance (PRI)
(T) An instantiation of a PRovisioning Class. (See also
"PRovisioning Class.")
$ QoS
See "Quality of Service."
$ Quality of Service (QoS)
(A) At a high level of abstraction, "Quality of Service"
refers to the ability to deliver network services according
to the parameters specified in a Service Level Agreement.
"Quality" is characterized by service availability, delay,
jitter, throughput and packet loss ratio. At a network
resource level, "Quality of Service" refers to a set of
Westerinen, et al. Expires: Apr 2001 + 6 months [Page 12]
Internet Draft Policy Terminology April 2001
capabilities that allow a service provider to prioritize
traffic, and control bandwidth and network latency. There
are two different approaches to "Quality of Service" on IP
networks: Integrated Services [R1633], and Differentiated
Service [R2475]. Integrated Services require policy control
over the creation of signaled reservations, which provide
specific quantitative end-to-end behavior for a (set of)
flow(s). In contrast, Differentiated Services require
policy to define the correspondence between codepoints in
the packet's DS-field and individual per-hop behaviors (to
achieve a specified per-domain behavior). A maximum of 64
per-hop behaviors limit the number of classes of service
traffic that can be marked at any point in a domain. These
classes of service signal the treatment of the packets with
respect to various QoS aspects, such as flow priority and
packet drop precedence. Policy controls the set of
configuration parameters for each class in Differentiated
Service, and the admission conditions for reservations in
Integrated Services. (See also "policy abstraction" and
"Service Level Agreement.")
$ Resource reSerVation Protocol (RSVP)
(T) A setup protocol designed for an Integrated Services
Internet, to reserve network resources for a path. [R2205]
And, a signaling mechanism for managing application
traffic's QoS in a Differentiated Service network.
$ role
(P) "Role" is defined from three perspectives:
- A business position or function, to which people and
logical entities are assigned [X.500]
- The labeled endpoints of a UML (Unified Modeling
Language) association. Quoting from [UML], "When a
class participates in an association, it has a specific
role that it plays in that relationship; a role is just
the face the class at the near end of the association
presents to the class at the other end of the
association." The Policy Core Information Model [R3060]
uses UML to depict its class hierarchy.
Relationships/associations are significant in the model.
- An administratively specified characteristic of a
managed element (for example, an interface). It is a
selector for policy rules and PRovisioning Classes
(PRCs), to determine the applicability of the rule/PRC to
a particular managed element.
Only the third definition (roles as selectors of policy) is
directly related to the management of network policy.
However, the first definition (roles as business positions
and functions) may be referenced in policy conditions and
actions.
Westerinen, et al. Expires: Apr 2001 + 6 months [Page 13]
Internet Draft Policy Terminology April 2001
$ role combination
(P) An unordered set of roles that characterize managed
elements and indicate the applicability of policy rules and
PRovisioning Classes (PRCs). A policy system uses the set
of roles reported by the managed element to determine the
correct rules/PRCs to be sent for enforcement. That
determination may examine all applicable policy rules
identified by the role combination, its sub-combinations
and the individual roles in the combination, or may require
that PRCs explicitly match the role combination specified
for the managed element. The final set of rules/PRCs for
enforcement are defined by the policy system, as
appropriate for the specified role combination of the
managed element.
$ RSVP
See "Resource reSerVation Protocol."
$ rule
See "policy rule."
$ rule based engine
(T) A rule based engine is able to evaluate policy
condition(s) and trigger appropriate policy actions. A
particular rule based engine may only be capable of acting
upon policy rules that are formatted in a specified way or
adhere to a specific language.
$ schema
(T) Two different perspectives of schema are defined:
- A set of rules that determines what data can be stored
in a database or directory service [DirServs]
- A collection of data models that are each bound to the
same type of repository.
The latter is the preferred and recommended one for
Internet Standards documents. (See also "data model.")
$ Security Policy Specification Language (SPSL)
(T) A language designed to express security policies,
security domains, and the entities that manage those
policies and domains. It supports policies for packet
filtering, IP Security (IPsec), and IKE exchanges, but may
be extended to express other types of policies.
$ service
(P) The behavior or functionality provided by a network,
network element or host [DMTF, R2216]. Quoting from RFC
2216 [R2216], in order to completely specify a "service",
one must define the "functions to be performed ..., the
information required ... to perform these functions, and
the information made available by the element to other
elements of the system." Policy can be used to configure a
Westerinen, et al. Expires: Apr 2001 + 6 months [Page 14]
Internet Draft Policy Terminology April 2001
"service" in a network or on a network element/host, invoke
its functionality, and/or coordinate services in an
interdomain or end-to-end environment.
$ Service Level Agreement (SLA)
(P) The documented result of a negotiation between a
customer/consumer and a provider of a service, that
specifies the levels of availability, serviceability,
performance, operation or other attributes of the service.
(See also "Service Level Objective.") [R2475]
$ Service Level Objective (SLO)
(P) Partitions an SLA into individual metrics and operational
information to enforce and/or monitor the SLA. "Service
Level Objectives" may be defined as part of an SLA, or in a
separate document. It is a set of parameters and their
values. The actions of enforcing and reporting monitored
compliance can be implemented as one or more policies. (See
also "Service Level Agreement.")
$ Service Level Specification (SLS)
(P) Specifies handling of a customer's traffic by a network
provider. It is negotiated between a customer and the
provider, and defines DiffServ parameters (such as specific
Code Points and Per-Hop-Behaviors, profile characteristics
and treatment of the traffic for those Code Points).
An SLS is a combination of an SLA (a negotiated agreement)
and its SLOs (the individual metrics and operational
data to enforce). (See also "Service Level Agreement"
and "Service Level Objective.")
$ SLA
See "Service Level Agreement."
$ SLO
See "Service Level Objective."
$ SLS
See "Service Level Specification."
$ SMIv2
See "Structure of Management Information."
$ SPPI
See "Structure of Policy Provisioning Information."
$ SPSL
See "Security Policy Specification Language."
$ Structure of Policy Provisioning Information (SPPI)
(T) An adapted subset of SNMP's Structure of Management
Information (SMIv2) that is used to encode collections of
Westerinen, et al. Expires: Apr 2001 + 6 months [Page 15]
Internet Draft Policy Terminology April 2001
related PRovisioning Classes as a PIB. (See also "Policy
Information Base" and "PRovisioning Class.")
$ Structure of Management Information, version 2 (SMIv2)
(T) An adapted subset of OSI's Abstract Syntax Notation One,
ASN.1 (1988) used to encode collections of related objects
as SNMP Management Information Base (MIB) modules. [R2578]
$ subject
(P) An entity, or collection of entities, which originates a
request, and is verified as authorized/not authorized to
perform that request.
$ target
(P) An entity, or collection of entities, which is affected
by a policy. For example, the "targets" of a policy to
reconfigure a network device are the individual services
that are updated and configured.
4. Intellectual Property
The IETF takes no position regarding the validity or scope of
any intellectual property or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; neither does
it represent that it has made any effort to identify any such
rights. Information on the IETF's procedures with respect to
rights in standards-track and standards-related documentation
can be found in BCP-11.
Copies of claims of rights made available for publication and
any assurances of licenses to be made available, or the result
of an attempt made to obtain a general license or permission for
the use of such proprietary rights by implementers or users of
this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights which may cover technology that may be
required to practice this standard. Please address the
information to the IETF Executive Director.
Westerinen, et al. Expires: Apr 2001 + 6 months [Page 16]
Internet Draft Policy Terminology April 2001
5. Acknowledgements
This document builds on the work of previous terminology drafts.
The authors of these drafts were Fran Reichmeyer, Dan Grossman,
John Strassner, Ed Ellesson and Matthew Condell. Also,
definitions for the general concepts of policy and policy rule
include input from Predrag Spasic. Very helpful comments and
suggestions were received from Juergen Schoenwaelder, Joe
Salowey and Jon Saperia.
6. Security Considerations
This document only defines policy-related terms. It does not
describe in detail the vulnerabilities of, threats to, or
mechanisms that protect specific policy implementations or
policy-related Internet protocols.
7. References
[DecSupp] Building Effective Decision Support Systems. R.
Sprague, and E. Carleson. Prentice Hall, 1982.
[DirServs] Understanding and Deploying LDAP Directory Services.
T. Howes, M. Smith, and G. Good. MacMillan Technical
Publications, 1999.
[DMTF] Common Information Model (CIM) Schema, version 2.x.
Distributed Management Task Force, Inc. The components of
the CIM v2.x schema are available via links on the following
DMTF web page: http://www.dmtf.org/spec/cim_schema_v24.html.
[R1633] Integrated Services in the Internet Architecture: An
Overview. R. Braden, D. Clark, and S. Shenker. June 1994.
[R2026] The Internet Standards Process -- Revision 3. S.
Bradner. October 1996.
[R2138] Remote Authentication Dial In User Service (RADIUS). C.
Rigney, A. Rubens, W. Simpson, and S. Willens. April 1997.
[R2205] Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification. R. Braden, L. Zhang, S. Berson,
S. Herzog, and S. Jamin. September 1997.
[R2216] Network Element Service Specification Template. S.
Shenker, and J. Wroclawski. September 1997.
Westerinen, et al. Expires: Apr 2001 + 6 months [Page 17]
Internet Draft Policy Terminology April 2001
[R2474] Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers. K. Nichols, S. Blake,
F. Baker, and D. Black. December 1998.
[R2475] An Architecture for Differentiated Service. S. Blake,
D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss.
December 1998.
[R2578] Structure of Management Information Version 2 (SMIv2).
K. McGloughrie, D. Perkins, J. Schoenwaelder, J. Case, M.
Rose, and S. Waldbusser. April 1999.
[R2702] Requirements for Traffic Engineering Over MPLS. D.
Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus.
September 1999.
[R2748] The COPS (Common Open Policy Service) Protocol. D.
Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, and A.
Sastry. January 2000.
[R2753] A Framework for Policy-based Admission Control. R.
Yavatkar, D. Pendarakis, and R. Guerin. January 2000.
[R2828] Internet Security Glossary. R. Shirey. May 2000.
[R3060] Policy Core Information Model -- Version 1
Specification. B. Moore, E. Ellesson, J. Strassner, and A.
Westerinen. February 2001.
[UML] The Unified Modeling Language User Guide. G. Booch, J.
Rumbaugh, and I. Jacobson. Addison-Wesley, 1999.
[X.500] Data Communications Networks Directory, Recommendations
X.500-X.521, Volume VIII - Fascicle VIII.8. CCITT, IXth
Plenary Assembly, Melbourne. November 1988.
8. Authors' Addresses
Andrea Westerinen
Cisco Systems, Bldg 20
725 Alder Drive
Milpitas, CA 95035
E-mail: andreaw@cisco.com
John Schnizlein
Cisco Systems
9123 Loughran Road
Fort Washington, MD 20744
E-mail: john.schnizlein@cisco.com
Westerinen, et al. Expires: Apr 2001 + 6 months [Page 18]
Internet Draft Policy Terminology April 2001
John Strassner
Cisco Systems, Bldg 20
725 Alder Drive
Milpitas, CA 95035
E-mail: johns@cisco.com
Mark Scherling
Xcert International Inc.
Suite 300
505 Burrard Street
Vancouver, BC
V7X 1M3
E-mail: mscherling@xcert.com
Bob Quinn
Celox Networks
One Cabot Road
Hudson, MA 01749
E-mail: bquinn@celoxnetworks.com
Jay Perry
E-mail: jay@jandg.net
Shai Herzog
IPHighway
55 New York Avenue
Framingham, MA 01701
E-mail: herzog@iphighway.com
An-Ni Huynh
Lucent Technologies
2139 Route 35
Holmdel, NJ 07733
E-mail: ahuynh@lucent.com
Mark Carlson
Sun Microsystems
3030 S. Technology Ct. Bldg B.
Broomfield, CO 80021
Email: mark.carlson@sun.com
Steve Waldbusser
Email: waldbusser@nextbeacon.com
Westerinen, et al. Expires: Apr 2001 + 6 months [Page 19]
Internet Draft Policy Terminology April 2001
9. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright
notice and this paragraph are included on all such copies and
derivative works. However, this document itself may not be
modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided
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.
Westerinen, et al. Expires: Apr 2001 + 6 months [Page 20]
