One document matched: draft-ietf-policy-terminology-01.txt
Differences from draft-ietf-policy-terminology-00.txt
Policy Framework Working Group A. Westerinen
INTERNET-DRAFT J. Schnizlein
Category: Informational J. Strassner
Cisco Systems
Mark Scherling
xCert
Bob Quinn
Celox Networks
Jay Perry
CPlane
Shai Herzog
IP Highway
An-Ni Huynh
Lucent Technologies
Mark Carlson
Sun Microsystems
Steve Waldbusser
November 2000
Policy Terminology
<draft-ietf-policy-terminology-01.txt>
Friday, November 24, 2000, 12:03 AM
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: Nov 2000 + 6 months [Page 1]
Internet Draft Policy Terminology November 2000
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...........................................15
5. Acknowledgements................................................16
6. Security Considerations.........................................16
7. References......................................................16
8. Authors' Addresses..............................................18
9. Full Copyright Statement........................................20
Westerinen, et al. Expires: Nov 2000 + 6 months [Page 2]
Internet Draft Policy Terminology November 2000
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 in this draft.
These terms are directly related and specific to network policy.
This is a "living" document that is expected to grow over the next
several months, as the current terms are reviewed and additional
words suggested for inclusion.
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
will be listed, with its source.
Where definitions are contradictory, the recommendations of the draft
editors are presented. The draft editors will work with other ISD
authors to remove contradictions.
Westerinen, et al. Expires: Nov 2000 + 6 months [Page 3]
Internet Draft Policy Terminology November 2000
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) [DIAMETER]. Referencing the RADIUS RFC
[R2138], a network access server sends dial-user credentials to
a 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, number of sessions, calling number,
etc., and the attribute-values authorized.
Westerinen, et al. Expires: Nov 2000 + 6 months [Page 4]
Internet Draft Policy Terminology November 2000
$ 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.
$ 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
Westerinen, et al. Expires: Nov 2000 + 6 months [Page 5]
Internet Draft Policy Terminology November 2000
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, DSTERMS]
(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
See "policy domain."
$ DS
See "Differentiated Services."
$ filter
(T) A set of terms and/or criteria used for the purpose of
separating or categorizing. "Filters" are often manipulated and
used in network policy.
- Packet filters are defined in [FrameworkPIB, DiffServPIB].
They specify the criteria for matching a pattern (for example,
IP or 802 traffic criteria) to appear in packets belonging to
flows, e.g. microflows or behavior aggregates. Associated with
each filter is a permit/deny flag.
Westerinen, et al. Expires: Nov 2000 + 6 months [Page 6]
Internet Draft Policy Terminology November 2000
$ 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."
$ 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."
$ 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
Westerinen, et al. Expires: Nov 2000 + 6 months [Page 7]
Internet Draft Policy Terminology November 2000
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. [PCIM]
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 [for example, DiffPolicy]. 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 [PCIM], a rule's actions may be ordered.
$ policy condition
(P) An expression used to determine whether a policy rule's
actions should be performed. When the set of conditions
associated with a policy rule evaluates to TRUE, then the rule
should be enforced. A condition may be defined as the occurrence
of an event, or a computed expression typically consisting of
three elements: a variable, an operator and another variable or
constant. [QoSModel] Some of these elements may be implicit in
an implementation or protocol.
- In [PCIM], 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."
Westerinen, et al. Expires: Nov 2000 + 6 months [Page 8]
Internet Draft Policy Terminology November 2000
$ policy conversion
See "policy translation."
$ Policy Core Information Model (PCIM)
(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 contiguous portion of an Internet over which a 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. The
definition given in RFC 2474 for Differentiated Services is
very close to that of a security domain, defined in [SPSL]. In
[SPSL], it is stated: "A security domain is defined as a
connected set of network entities that are protected by policy
enforcement points (PEP) placed on every communication path
going through the perimeter of the domain. Every policy
enforcement point of the domain works to enforce the common set
of security policies associated with the domain."
$ 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."
Westerinen, et al. Expires: Nov 2000 + 6 months [Page 9]
Internet Draft Policy Terminology November 2000
$ 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. [FrameworkPIB] (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. [PolicyMIB]
$ 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. The need for "policy negotiation"
is described in the IPsec Policy Working Group charter [IPSP]:
"4) adopt or develop a policy exchange and negotiation
protocol. The protocol must be capable of: i) discovering
policy servers, ii) distributing and negotiating security
policies, and; iii) resolving policy conflicts in both
intra/inter domain environments."
$ 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 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. [QoSModel]
- In [PCIM], a more restrictive definition than the prior one
exists. PolicyRepository is a model abstraction representing
an administratively defined, logical container for reusable
policy conditions and policy actions.
Westerinen, et al. Expires: Nov 2000 + 6 months [Page 10]
Internet Draft Policy Terminology November 2000
$ policy request
(P) 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. [PCIM]
$ 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 [PCIM]. It
is a class representing a container, aggregating either policy
rules or other policy groups. It 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.
$ PolicyRepository
(T) An abstraction in the Policy Core Information Model [PCIM].
It is a class representing an administratively defined, logical
container for reusable policy conditions and policy actions.
(See also "policy repository.")
$ PRC
See "PRovisioning Class."
$ PRI
See "PRovisioning Instance."
Westerinen, et al. Expires: Nov 2000 + 6 months [Page 11]
Internet Draft Policy Terminology November 2000
$ 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.
[R2578, FrameworkPIB] (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. [FrameworkPIB] (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 capabilities that allow
a service provider to prioritize traffic, 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
Westerinen, et al. Expires: Nov 2000 + 6 months [Page 12]
Internet Draft Policy Terminology November 2000
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. [DCLASS]
$ 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 [PCIM] 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. [PolicyMIB, PCIM, FrameworkPIB, DiffServPIB]
Only the latter definition is directly related to network
policy.
$ 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
[PCIM], or may require that PRCs explicitly match the role
combination specified for the managed element [FrameworkPIB,
DiffServPIB]. 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.
Westerinen, et al. Expires: Nov 2000 + 6 months [Page 13]
Internet Draft Policy Terminology November 2000
$ RSVP
See "Resource reSerVation Protocol."
$ rule
See "policy rule."
$ 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 ISDs. (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. [SPSL]
$ service
(P) The behavior or functionality of a 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 "service" on a network element or 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.")
$ 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 customer's traffic by a network
provider. It is negotiated between a customer and the provider,
and (for DiffServ) defines a set of parameters (such as
Westerinen, et al. Expires: Nov 2000 + 6 months [Page 14]
Internet Draft Policy Terminology November 2000
specific Code Points and the Per-Hop-Behavior, profile
characteristics and treatment of the traffic for those Code
Points) and their values. An SLS is a combination of an
SLA (a negotiated agreement) and its SLOs (the individual
metrics and operational data to enforce). [DSTERMS] (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
related PRovisioning Classes as a PIB. [R2578, SPPI] (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
Westerinen, et al. Expires: Nov 2000 + 6 months [Page 15]
Internet Draft Policy Terminology November 2000
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.
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 and Jon Sapiera.
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
[DCLASS] Format of the RSVP DCLASS Object. Internet Draft, draft-
ietf-issll-dclass-01.txt, Y. Bernet. October 1999.
[DecSupp] Building Effective Decision Support Systems. R. Sprague,
and E. Carleson. Prentice Hall, 1982.
[DIAMETER] DIAMETER Framework Document. Internet Draft, draft-
calhoun-diameter-framework-08.txt, P. Calhoun, G. Zorn, P. Pan,
and H. Akhtar. June 2000.
[DiffPolicy] The DiffServ Policy MIB. Internet Draft, draft-ietf-
snmpconf-diffpolicy-02.txt, H. Hazewinkel and D. Partain. June
2000.
Westerinen, et al. Expires: Nov 2000 + 6 months [Page 16]
Internet Draft Policy Terminology November 2000
[DiffServPIB] Differentiated Services Quality of Service Policy
Information Base. Internet Draft, draft-ietf-diffserv-pib-
01.txt, M. Fine, K. McCloughrie, J. Seligson, K. Chan, S. Hahn,
A. Smith, and F. Reichmeyer. July 2000.
[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.4.
Distributed Management Task Force, Inc. August, 2000. The
components of the CIM v2.4 schema are available via links on the
following DMTF web page:
http://www.dmtf.org/spec/cim_schema_v24.html.
[DSTERMS] New Terminology for Diffserv. Internet Draft, draft-ietf-
diffserv-new-terms-03.txt, D. Grossman. November 1999.
[FrameworkPIB] Framework Policy Information Base. Internet Draft,
draft-ietf-rap-frameworkpib-02.txt, M. Fine, K. McCloughrie, J.
Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, and F.
Reichmeyer. September 2000.
[IPSP] IP Security Policy (ipsp) Working Group Charter. February
2000. http://www.ietf.org/html.charters/ipsp-charter.html.
[PCIM] Policy Core Information Model - Version 1 Specification.
Internet Draft, draft-ietf-policy-core-info-model-08.txt, B.
Moore, E. Ellison, J. Strassner, and A. Westerinen. October
2000.
[PolicyMIB] Policy Based Management MIB. Internet Draft, draft-ietf-
snmpconf-pm-03.txt, S. Waldbusser, J. Saperia and T. Hongal.
October 2000.
[QoSModel] Policy Framework QoS Information Model. Internet Draft,
draft-ietf-policy-qos-info-model-01.txt, Y. Snir, Y. Ramberg, J.
Strassner, and R. Cohen. April 2000.
[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.
Westerinen, et al. Expires: Nov 2000 + 6 months [Page 17]
Internet Draft Policy Terminology November 2000
[R2401] Security Architecture for the Internet Protocol. S. Kent,
and R. Atkinson. November 1998.
[R2409] The Internet Key Exchange (IKE). D. Harkins, and D. Carrel.
November 1998.
[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.
[SPPI] Structure of Policy Provisioning Information (SPPI).
Internet Draft, draft-ietf-rap-sppi-02.txt, K. McCloughrie, M.
Fine, J. Seligson, K. Chan, S. Chan, R. Sahita, A. Smith, and F.
Reichmeyer. September 2000.
[SPSL] Security Policy Specification Language. Internet Draft,
draft-ietf-ipsp-spsl-00.txt, M. Condell, C. Lynn, and J. Zao.
March 2000.
[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.
Westerinen, et al. Expires: Nov 2000 + 6 months [Page 18]
Internet Draft Policy Terminology November 2000
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
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
CPlane, Inc.
5150 El Camino Real - B-31
Los Altos, CA 94022
E-mail: jay@cplane.com
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
Westerinen, et al. Expires: Nov 2000 + 6 months [Page 19]
Internet Draft Policy Terminology November 2000
Mark Carlson
Sun Microsystems
2990 Center Green Court South
Boulder, CO 80301
Email: mark.carlson@sun.com
Steve Waldbusser
Email: waldbusser@nextbeacon.com
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: Nov 2000 + 6 months [Page 20] | PAFTECH AB 2003-2026 | 2026-04-24 01:30:31 |