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

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/