draft-ietf-policy-terminology-03.txt   draft-ietf-policy-terminology-04.txt 
Policy Framework Working Group A. Westerinen Policy Framework Working Group A. Westerinen
INTERNET-DRAFT J. Schnizlein INTERNET-DRAFT J. Schnizlein
Category: Informational J. Strassner Category: Informational Cisco Systems
Cisco Systems John Strassner
IntelliDEN
Mark Scherling Mark Scherling
xCert xCert
Bob Quinn Bob Quinn
Celox Networks Celox Networks
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
Jay Perry Jay Perry
Steve Waldbusser Steve Waldbusser
Terminology Terminology for Policy-Based Management
<draft-ietf-policy-terminology-03.txt> <draft-ietf-policy-terminology-04.txt>
Thursday, April 19, 2001, 3:53 PM Friday, July 20, 2001, 9:06 AM
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
skipping to change at page 2, line 20 skipping to change at page 2, line 20
of RFC2828 [R2828], which defines an Internet Security Glossary. of RFC2828 [R2828], which defines an Internet Security Glossary.
The intent is to improve the comprehensibility and consistency The intent is to improve the comprehensibility and consistency
of writing that deals with network policy, particularly Internet of writing that deals with network policy, particularly Internet
Standards documents (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.......................................16 4. Intellectual Property.......................................17
5. Acknowledgements............................................17 5. Acknowledgements............................................17
6. Security Considerations.....................................17 6. Security Considerations.....................................17
7. References..................................................17 7. References..................................................18
8. Authors' Addresses..........................................18 8. Authors' Addresses..........................................19
9. Full Copyright Statement....................................20 9. Full Copyright Statement....................................21
1. Introduction 1. Introduction
This document provides abbreviations, definitions, and This document provides abbreviations, definitions, and
explanations of terms related to network policy. All definitions explanations of terms related to network policy. All definitions
are provided in Section 3, with the terms listed in alphabetical are provided in Section 3, with the terms listed in alphabetical
order. order.
The intent is to improve the comprehensibility and consistency The intent is to improve the comprehensibility and consistency
of Internet Standards documents (ISDs) - i.e., RFCs, Internet- of Internet Standards documents (ISDs)--i.e., RFCs, Internet-
Drafts, and other material produced as part of the Internet Drafts, and other material produced as part of the Internet
Standards Process [R2026]. Benefits across the ISDs are well- Standards Process [R2026]. Benefits across the ISDs are well-
stated in the Introduction to RFC2828 [R2828]: stated in the Introduction to RFC2828 [R2828]:
o "Clear, Concise, and Easily Understood Documentation" - o "Clear, Concise, and Easily Understood Documentation" -
Requires that the set of terms and definitions be consistent, Requires that the set of terms and definitions be consistent,
self-supporting and uniform across all ISDs. self-supporting and uniform across all ISDs.
o Technical Excellence - Where all ISDs use terminology o Technical Excellence - Where all ISDs use terminology
accurately, precisely, and unambiguously. accurately, precisely, and unambiguously.
skipping to change at page 4, line 20 skipping to change at page 4, line 20
capitalized. 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 - "T" identifies various techniques to create or convey
policy-related information in a network. For example, policy-related information in a network. For example,
COPS and an "Information Model" are two techniques for COPS and an "Information Model" are two techniques for
communicating and describing policy-related data. communicating and describing policy-related data. SNMP
and MIBs are another.
- "A" identifies specific Work Groups and general "areas of - "A" identifies specific Work Groups and general "areas of
use" of policy. For example, AAA and QoS are two "areas use" of policy. For example, AAA and QoS are two "areas
of use" where policy concepts are extremely important to of use" where policy concepts are extremely important to
their function and operation. their function and operation.
3. Terms 3. Terms
Note: In providing policy definitions, other "technology Note: In providing policy definitions, other "technology
specific" terms (for example, related to Differentiated specific" terms (for example, related to Differentiated
skipping to change at page 4, line 45 skipping to change at page 4, line 46
$ 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 deals with control, authentication, authorization and
deployed use of authentication: Remote Authentication Dial
In User Service (RADIUS), and its expansion in Diameter (a
"radius" pun and not an acronym). Referencing the RADIUS
RFC [R2138], a network access server sends dial-user
credentials to an AAA server, and receives authentication
that the user is who he/she claims along with a set of
attribute-value pairs authorizing various service features
for that user. Policy is implied in both the
authentication, which can be restricted by time of day,
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 accounting of systems and environments based on policies
set by the administrators and users of the systems. set by the administrators and users of the systems. The use
of policy may be implicit - as defined by RADIUS [R2138].
In RADIUS, a network access server sends dial-user
credentials to an AAA server, and receives authentication
that the user is who he/she claims, along with a set of
attribute-value pairs authorizing various service features.
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.
$ 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 (Distributed Management Task Force) [DMTF]. It consists of
a Specification detailing the abstract modeling constructs a Specification detailing the abstract modeling constructs
and principles of the Information Model, and a textual and principles of the Information Model, and a textual
language definition to represent the Model. CIM's schemas language definition to represent the Model. CIM's schemas
are defined as a set of files, written in the language of are defined as a set of files, written in the language of
the Specification, with graphical renderings using UML the Specification, with graphical renderings using UML
[UML]. Sets of classes and associations represent CIM's [UML]. Sets of classes and associations represent CIM's
Core and Common Models, defining an information model for Core and Common Models, defining an information model for
the "enterprise" - addressing general concepts (in Core), the "enterprise" - addressing general concepts (in Core),
and systems, devices, users, software distribution, the and systems, devices, users, software distribution, the
physical environment, networks and policy (in the Common physical environment, networks and policy (in the Common
Models). (See also "information model.") 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 (T) A simple query and response TCP-based protocol that can be
be used to exchange policy information between a Policy used to exchange policy information between a Policy
Decision Point (PDP) and its clients (Policy Enforcement Decision Point (PDP) and its clients (Policy Enforcement
Points, PEPs). [RFC 2748] (See also "Policy Decision Point" Points, PEPs). [R2748] The COPS protocol is used to provide
and "Policy Enforcement Point.") for the outsourcing of policy decisions for RSVP. [R2749]
Another usage is for the provisioning of policy. [R3084]
(See also "Policy Decision 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 - The set of parameters in network elements and other
systems that determine their function and operation. systems that determine their function and operation.
Some parameters are static, such as packet queue Some parameters are static, such as packet queue
assignment and can be predefined and downloaded to a assignment and can be predefined and downloaded to a
skipping to change at page 6, line 31 skipping to change at page 6, line 31
on values). 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 (T) The IP header field, called the DS-field. In IPv4, it
defines the layout of the ToS (Type of Service) octet; in defines the layout of the ToS (Type of Service) octet; in
IPv6, it is the Traffic Class octet. [R2474] IPv6, it is the Traffic Class octet. [R2474]
(A) "Differentiated Services" is also an "area of use" for (A) "Differentiated Services" is also an "area of use" for QoS
QoS policies. It requires policy to define the policies. It requires policy to define the correspondence
correspondence between codepoints in the packet's DS-field between codepoints in the packet's DS-field and individual
and individual per-hop behaviors (to achieve a specified per-hop behaviors (to achieve a specified per-domain
per-domain behavior). (See also "Quality of Service.") behavior). In addition, policy can be used to specify the
routing of packets based on various classification
criteria. (See also "Quality of Service" and "filter.")
$ 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 Information Model). Its goals are to enable the deployment
and use of policy by starting with common service and user and use of policy by starting with common service and user
concepts (defined in the information model), specifying concepts (defined in the information model), specifying
their mapping/storage in an LDAP-based repository, and their mapping/storage in an LDAP-based repository, and
using these concepts in vendor/device-independent policy using these concepts in vendor/device-independent policy
rules. [DMTF] (See also "Common Information Model" and rules. [DMTF] (See also "Common Information Model" and
"data model.") "data model.")
$ domain $ domain
A collection of elements and services, administered in a (P) A collection of elements and services, administered in a
coordinated fashion. (See also "policy domain.") 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. This is accomplished via separating or categorizing. This is accomplished via
single- or multi-field matching of traffic header and/or single- or multi-field matching of traffic header and/or
payload data. "Filters" are often manipulated and used in payload data. "Filters" are often manipulated and used in
network operation and policy. For example, packet filters network operation and policy. For example, packet filters
specify the criteria for matching a pattern (for example, specify the criteria for matching a pattern (for example,
IP or 802 criteria) to distinguish separable classes of IP or 802 criteria) to distinguish separable classes of
traffic. traffic.
skipping to change at page 7, line 21 skipping to change at page 7, line 24
IP or 802 criteria) to distinguish separable classes of IP or 802 criteria) to distinguish separable classes of
traffic. traffic.
$ goal $ goal
See "policy goal." See "policy goal."
$ information model $ information model
(T) An abstraction and representation of the entities in a (T) An abstraction and representation of the entities in a
managed environment, their properties, attributes and managed environment, their properties, attributes and
operations, and the way that they relate to each other. It operations, and the way that they relate to each other. It
is independent of any specific repository, application, is independent of any specific repository, software usage,
protocol, or platform. protocol, or platform.
$ Management Information Base (MIB)
(T) A collection of information that can be accessed via
the Simple Network Management Protocol. Management
information is defined in MIB modules using the rules
contained in SNMP's Structure of Management Information
(SMI) specifications. [R2570] Management information is
an abstract concept, and definitions can be created for
high level policy specifications, low level policy, as
well as technology and vendor specific configurations,
status and statistics. (See also "Simple Network
Management Protocol" and "Structure of Management
Information.")
$ MIB $ MIB
See "Policy Management Information Base." See "Management Information Base."
$ MPLS $ MPLS
See "Multiprotocol Label Switching." (Also, MPLS may refer See "Multiprotocol Label Switching." (Also, MPLS may refer
to Multi-Protocol Lambda Switching in optical networks. But, to Multi-Protocol Lambda Switching in optical networks. But,
this is unrelated to policy and not discussed further in this this is unrelated to policy and not discussed further in this
document.) 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
skipping to change at page 9, line 4 skipping to change at page 9, line 24
$ policy condition $ policy condition
(P) A representation of the necessary state and/or (P) A representation of the necessary state and/or
prerequisites that define whether a policy rule's actions prerequisites that define whether a policy rule's actions
should be performed. This representation need not be should be performed. This representation need not be
completely specified, but may be implicitly provided in an completely specified, but may be implicitly provided in an
implementation or protocol. When the policy condition(s) implementation or protocol. When the policy condition(s)
associated with a policy rule evaluate to TRUE, then associated with a policy rule evaluate to TRUE, then
(subject to other considerations such as rule priorities (subject to other considerations such as rule priorities
and decision strategies) the rule should be enforced. and decision strategies) the rule should be enforced.
(T) In [R3060], a rule's conditions can be expressed as either
- In [R3060], a rule's conditions can be expressed as an ORed set of ANDed sets of statements (disjunctive normal
either an ORed set of ANDed sets of statements form), or an ANDed set of ORed sets of statements
(disjunctive normal form), or an ANDed set of ORed sets (conjunctive normal form). Individual condition statements
of statements (conjunctive normal form). Individual can also be negated.
condition statements can also be negated.
$ policy conflict $ policy conflict
(P) Occurs when the actions of two rules (that are both (P) Occurs when the actions of two rules (that are both
satisfied simultaneously) contradict each other. The entity satisfied simultaneously) contradict each other. The entity
implementing the policy would not be able to determine implementing the policy would not be able to determine
which action to perform. The implementers of policy systems which action to perform. The implementers of policy systems
must provide conflict detection and avoidance or resolution must provide conflict detection and avoidance or resolution
mechanisms to prevent this situation. "Policy conflict" is mechanisms to prevent this situation. "Policy conflict" is
contrasted with "policy error." contrasted with "policy error."
skipping to change at page 9, line 50 skipping to change at page 10, line 20
TRUE TRUE
$ Policy Decision Point (PDP) $ Policy Decision Point (PDP)
(P) A logical entity that makes policy decisions for itself (P) A logical entity that makes policy decisions for itself
or for other network elements that request such decisions. or for other network elements that request such decisions.
[R2753] (See also "policy decision.") [R2753] (See also "policy decision.")
$ policy domain $ policy domain
(P) A collection of elements and services, and/or a portion (P) A collection of elements and services, and/or a portion
of an Internet over which a common and consistent set of of an Internet over which a common and consistent set of
[..] policies are administered in a coordinated fashion. policies are administered in a coordinated fashion. [R2474]
[R2474] This definition of a policy domain does not This definition of a policy domain does not preclude
preclude multiple sources of policy creation within an multiple sources of policy creation within an organization,
organization, but does require that the resultant policies but does require that the resultant policies be
be coordinated. coordinated.
- Policies defined in the context of one domain may need to - Policies defined in the context of one domain may need to
be communicated or negotiated outside of that domain. be communicated or negotiated outside of that domain.
(See also "policy negotiation.") (See also "policy negotiation.")
$ 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] (P) A logical entity that enforces policy decisions. [R2753]
(See also "policy enforcement.") (See also "policy enforcement.")
skipping to change at page 10, line 42 skipping to change at page 11, line 11
level agreement, as well as the assignment of resources to level agreement, as well as the assignment of resources to
applications or individuals. A policy system may be created applications or individuals. A policy system may be created
that automatically strives to achieve a goal through that automatically strives to achieve a goal through
feedback regarding whether the goal (such as a service feedback regarding whether the goal (such as a service
level) is being met. level) is being met.
$ Policy Information Base (PIB) $ Policy Information Base (PIB)
(T) Collections of related PRovisioning Classes (PRCs), (T) Collections of related PRovisioning Classes (PRCs),
defined as a module. (See also "PRovisioning Class.") defined as a module. (See also "PRovisioning Class.")
$ Policy Management Information Base (MIB)
(T) Collections of policy-related managed objects, defined as
a module and accessed via an SNMP framework.
$ policy mapping $ 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. different sets of policies.
$ policy repository $ policy repository
skipping to change at page 11, line 22 skipping to change at page 11, line 37
- A logical container representing the administrative - A logical container representing the administrative
scope and naming of policy rules, their conditions and scope and naming of policy rules, their conditions and
actions, and related policy data. A "QoS policy" domain actions, and related policy data. A "QoS policy" domain
would be an example of such a container. would be an example of such a container.
- In [R3060], a more restrictive definition than the prior - In [R3060], a more restrictive definition than the prior
one exists. A PolicyRepository is a model abstraction one exists. A PolicyRepository is a model abstraction
representing an administratively defined, logical representing an administratively defined, logical
container for reusable policy elements. container for reusable policy elements.
$ policy request $ policy request
(P) A message requesting a policy service. When sent by a (P) A message requesting a policy-related service. This may
PEP to a PDP, it is more accurately qualified as a "policy refer to a request to retrieve a specific set of policy
decision request." [R2753] (See also "policy decision.") rules, to determine the actions to enforce, or other policy
requests. When sent by a PEP to a PDP, it is more
accurately qualified as a "policy decision request."
[R2753] (See also "policy decision.")
$ policy rule $ policy rule
(P) A basic building block of a policy-based system. It is (P) A basic building block of a policy-based system. It is
the binding of a set of actions to a set of conditions - the binding of a set of actions to a set of conditions -
-
where the conditions are evaluated to determine whether the where the conditions are evaluated to determine whether the
actions are performed. [R3060] actions are performed. [R3060]
$ policy server $ policy server
(P) A marketing term whose definition is imprecise. (P) A marketing term whose definition is imprecise.
Originally, [R2753] referenced a "policy server." As the Originally, [R2753] referenced a "policy server." As the
RFC evolved, this term became more precise and known as the RFC evolved, this term became more precise and known as the
Policy Decision Point (PDP). Today, the term is used in Policy Decision Point (PDP). Today, the term is used in
marketing and other literature to refer specifically to a marketing and other literature to refer specifically to a
PDP, or for any entity that uses/services policy. PDP, or for any entity that uses/services policy.
skipping to change at page 13, line 5 skipping to change at page 13, line 25
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" (A) At a high level of abstraction, "Quality of Service"
refers to the ability to deliver network services according refers to the ability to deliver network services according
to the parameters specified in a Service Level Agreement. to the parameters specified in a Service Level Agreement.
"Quality" is characterized by service availability, delay, "Quality" is characterized by service availability, delay,
jitter, throughput and packet loss ratio. At a network jitter, throughput and packet loss ratio. At a network
resource level, "Quality of Service" refers to a set of resource level, "Quality of Service" refers to a set of
capabilities that allow a service provider to prioritize capabilities that allow a service provider to prioritize
traffic, and control bandwidth and network latency. There traffic, control bandwidth, and network latency. There are
are two different approaches to "Quality of Service" on IP two different approaches to "Quality of Service" on IP
networks: Integrated Services [R1633], and Differentiated networks: Integrated Services [R1633], and Differentiated
Service [R2475]. Integrated Services require policy control Service [R2475]. Integrated Services require policy control
over the creation of signaled reservations, which provide over the creation of signaled reservations, which provide
specific quantitative end-to-end behavior for a (set of) specific quantitative end-to-end behavior for a (set of)
flow(s). In contrast, Differentiated Services require flow(s). In contrast, Differentiated Services require
policy to define the correspondence between codepoints in policy to define the correspondence between codepoints in
the packet's DS-field and individual per-hop behaviors (to the packet's DS-field and individual per-hop behaviors (to
achieve a specified per-domain behavior). A maximum of 64 achieve a specified per-domain behavior). A maximum of 64
per-hop behaviors limit the number of classes of service per-hop behaviors limit the number of classes of service
traffic that can be marked at any point in a domain. These traffic that can be marked at any point in a domain. These
classes of service signal the treatment of the packets with classes of service signal the treatment of the packets with
respect to various QoS aspects, such as flow priority and respect to various QoS aspects, such as flow priority and
packet drop precedence. Policy controls the set of packet drop precedence. In addition, policy can be used to
configuration parameters for each class in Differentiated specify the routing of packets based on various
Service, and the admission conditions for reservations in classification criteria. Policy controls the set of
Integrated Services. (See also "policy abstraction" and configuration parameters and routing for each class in
"Service Level Agreement.") Differentiated Service, and the admission conditions for
reservations in Integrated Services. (See also "policy
abstraction" and "Service Level Agreement.")
$ Resource reSerVation Protocol (RSVP) $ Resource reSerVation Protocol (RSVP)
(T) A setup protocol designed for an Integrated Services (T) A setup protocol designed for an Integrated Services
Internet, to reserve network resources for a path. [R2205] Internet, to reserve network resources for a path. [R2205]
And, a signaling mechanism for managing application And, a signaling mechanism for managing application
traffic's QoS in a Differentiated Service network. 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 - A business position or function, to which people and
skipping to change at page 13, line 48 skipping to change at page 14, line 22
role that it plays in that relationship; a role is just role that it plays in that relationship; a role is just
the face the class at the near end of the association the face the class at the near end of the association
presents to the class at the other end of the presents to the class at the other end of the
association." The Policy Core Information Model [R3060] association." The Policy Core Information Model [R3060]
uses UML to depict its class hierarchy. 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 - An administratively specified characteristic of a
managed element (for example, an interface). It is a managed element (for example, an interface). It is a
selector for policy rules and PRovisioning Classes selector for policy rules and PRovisioning Classes
(PRCs), to determine the applicability of the rule/PRC to (PRCs), to determine the applicability of the rule/PRC to
a particular managed element. a particular managed element. [R3060]
Only the third definition (roles as selectors of policy) is Only the third definition (roles as selectors of policy) is
directly related to the management of network policy. directly related to the management of network policy.
However, the first definition (roles as business positions However, the first definition (roles as business positions
and functions) may be referenced in policy conditions and and functions) may be referenced in policy conditions and
actions. actions.
$ role combination $ role combination
(P) An unordered set of roles that characterize managed (P) A lexicographically ordered set of roles that characterize
elements and indicate the applicability of policy rules and managed elements and indicate the applicability of policy
PRovisioning Classes (PRCs). A policy system uses the set rules and PRovisioning Classes (PRCs). A policy system
of roles reported by the managed element to determine the uses the set of roles reported by the managed element to
correct rules/PRCs to be sent for enforcement. That determine the correct rules/PRCs to be sent for
determination may examine all applicable policy rules enforcement. That determination may examine all applicable
identified by the role combination, its sub-combinations policy rules identified by the role combination, its sub-
and the individual roles in the combination, or may require combinations and the individual roles in the combination.
that PRCs explicitly match the role combination specified [R3060] In the case of PRCs, a PRC must explicitly match
for the managed element. The final set of rules/PRCs for the role combination of the managed element in order to be
applicable and/or enforced. (The comparison is typically
case-sensitive.) The final set of rules/PRCs for
enforcement are defined by the policy system, as enforcement are defined by the policy system, as
appropriate for the specified role combination of the appropriate for the specified role combination of the
managed element. managed element.
$ RSVP $ RSVP
See "Resource reSerVation Protocol." See "Resource reSerVation Protocol."
$ rule $ rule
See "policy rule." See "policy rule."
skipping to change at page 14, line 42 skipping to change at page 15, line 16
$ 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 - A set of rules that determines what data can be stored
in a database or directory service [DirServs] in a database or directory service [DirServs]
- A collection of data models that are each bound to the - A collection of data models that are each bound to the
same type of repository. same type of repository.
The latter is the preferred and recommended one for The latter is the preferred and recommended one for
Internet Standards documents. (See also "data model.") Internet Standards documents. (See also "data model.")
$ Security Policy Specification Language (SPSL)
(T) A language designed to express security policies,
security domains, and the entities that manage those
policies and domains. It supports policies for packet
filtering, IP Security (IPsec), and IKE exchanges, but may
be extended to express other types of policies.
$ service $ service
(P) The behavior or functionality provided by a network, (P) The behavior or functionality provided by a network,
network element or host [DMTF, R2216]. Quoting from RFC network element or host [DMTF, R2216]. Quoting from RFC
2216 [R2216], in order to completely specify a "service", 2216 [R2216], in order to completely specify a "service",
one must define the "functions to be performed ..., the one must define the "functions to be performed ..., the
information required ... to perform these functions, and information required ... to perform these functions, and
the information made available by the element to other the information made available by the element to other
elements of the system." Policy can be used to configure a elements of the system." Policy can be used to configure a
"service" in a network or on a network element/host, invoke "service" in a network or on a network element/host, invoke
its functionality, and/or coordinate services in an its functionality, and/or coordinate services in an
skipping to change at page 15, line 18 skipping to change at page 15, line 38
$ 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 customer/consumer and a provider of a service, that
specifies the levels of availability, serviceability, specifies the levels of availability, serviceability,
performance, operation or other attributes of the service. performance, operation or other attributes of the service.
(See also "Service Level Objective.") [R2475] (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 information to enforce and/or monitor the SLA. "Service
Level Objectives" may be defined as part of an SLA, or in a Level Objectives" may be defined as part of an SLA, an SLS,
separate document. It is a set of parameters and their or in a separate document. It is a set of parameters and
values. The actions of enforcing and reporting monitored their values. The actions of enforcing and reporting
compliance can be implemented as one or more policies. (See monitored compliance can be implemented as one or more
also "Service Level Agreement.") policies. (See also "Service Level Agreement.")
$ Service Level Specification (SLS) $ Service Level Specification (SLS)
(P) Specifies handling of a 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. It is negotiated between a customer and the
provider, and defines DiffServ parameters (such as specific provider, and (for example) in a DiffServ environment,
Code Points and Per-Hop-Behaviors, profile characteristics defines parameters such as specific Code Points and the
and treatment of the traffic for those Code Points). Per-Hop-Behavior, profile characteristics and treatment of
An SLS is a combination of an SLA (a negotiated agreement) the traffic for those Code Points. An SLS is a specific SLA
and its SLOs (the individual metrics and operational (a negotiated agreement) and its SLOs (the individual
data to enforce). (See also "Service Level Agreement" metrics and operational data to enforce) to guarantee
and "Service Level Objective.") quality of service for network traffic. (See also "Service
Level Agreement" and "Service Level Objective.")
$ Simple Network Management Protocol (SNMP)
(T) SNMP is a framework (including a protocol) for managing
systems in a network environment. [R2570] It can be used
for policy-based configuration and control using a specific
MIB Module designed to execute policies on managed elements
via scripts. The elements (instances) in a network device
are evaluated using a policy filter, to determine where
policy will be applied.
$ 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."
$ SMIv2 $ SMIv2
See "Structure of Management Information." See "Structure of Management Information."
$ SNMP
See "Simple Network Management Protocol."
$ SPPI $ SPPI
See "Structure of Policy Provisioning Information." See "Structure of Policy Provisioning Information."
$ SPSL
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. (See also "Policy related PRovisioning Classes as a PIB. (See also "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, (T) An adapted subset of OSI's Abstract Syntax Notation One,
ASN.1 (1988) used to encode collections of related objects ASN.1 (1988) used to encode collections of related objects
as SNMP Management Information Base (MIB) modules. [R2578] as SNMP Management Information Base (MIB) modules. [R2578]
skipping to change at page 17, line 13 skipping to change at page 17, line 37
information to the IETF Executive Director. information to the IETF Executive Director.
5. Acknowledgements 5. Acknowledgements
This document builds on the work of previous terminology drafts. This document builds on the work of previous terminology drafts.
The authors of these drafts were Fran Reichmeyer, Dan Grossman, The authors of these drafts were Fran Reichmeyer, Dan Grossman,
John Strassner, Ed Ellesson and Matthew Condell. Also, John Strassner, Ed Ellesson and Matthew Condell. Also,
definitions for the general concepts of policy and policy rule definitions for the general concepts of policy and policy rule
include input from Predrag Spasic. Very helpful comments and include input from Predrag Spasic. Very helpful comments and
suggestions were received from Juergen Schoenwaelder, Joe suggestions were received from Juergen Schoenwaelder, Joe
Salowey and Jon Saperia. Salowey, Jon Saperia, Ravi Sahita, Bob Moore, Guus Sliepen,
T.H. Jonatan and Dave Perkins.
6. Security Considerations 6. Security Considerations
This document only defines policy-related terms. It does not This document only defines policy-related terms. It does not
describe in detail the vulnerabilities of, threats to, or describe in detail the vulnerabilities of, threats to, or
mechanisms that protect specific policy implementations or mechanisms that protect specific policy implementations or
policy-related Internet protocols. policy-related Internet protocols.
7. References 7. References
[DecSupp] Building Effective Decision Support Systems. R. [DecSupp] Building Effective Decision Support Systems. R.
Sprague, and E. Carleson. Prentice Hall, 1982. Sprague, and E. Carleson. Prentice Hall, 1982.
[DirServs] Understanding and Deploying LDAP Directory Services. [DirServs] Understanding and Deploying LDAP Directory Services.
T. Howes, M. Smith, and G. Good. MacMillan Technical T. Howes, M. Smith, and G. Good. MacMillan Technical
Publications, 1999. Publications, 1999.
[DMTF] Common Information Model (CIM) Schema, version 2.x. [DMTF] Common Information Model (CIM) Schema, version 2.x.
Distributed Management Task Force, Inc. The components of Distributed Management Task Force, Inc. The components of
the CIM v2.x schema are available via links on the following the CIM v2.x schema are available via links on the following
DMTF web page: http://www.dmtf.org/spec/cim_schema_v24.html. DMTF web page:
http://www.dmtf.org/standards/standard_cim.php.
[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. [R2026] The Internet Standards Process -- Revision 3. S.
Bradner. 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.
skipping to change at page 18, line 13 skipping to change at page 18, line 44
Shenker, and J. Wroclawski. September 1997. Shenker, and J. Wroclawski. September 1997.
[R2474] Definition of the Differentiated Services Field (DS [R2474] Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers. K. Nichols, S. Blake, Field) in the IPv4 and IPv6 Headers. K. Nichols, S. Blake,
F. Baker, and D. Black. December 1998. F. Baker, and D. Black. December 1998.
[R2475] An Architecture for Differentiated Service. S. Blake, [R2475] An Architecture for Differentiated Service. S. Blake,
D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss.
December 1998. December 1998.
[R2570] Introduction to Version 3 of the Internet-standard
Network Management Framework. J. Case, R. Mundy, D. Partain,
and B. Stewart. April 1999.
[R2578] Structure of Management Information Version 2 (SMIv2). [R2578] Structure of Management Information Version 2 (SMIv2).
K. McGloughrie, D. Perkins, J. Schoenwaelder, J. Case, M. K. McGloughrie, D. Perkins, J. Schoenwaelder, J. Case, M.
Rose, and S. Waldbusser. April 1999. Rose, and S. Waldbusser. April 1999.
[R2702] Requirements for Traffic Engineering Over MPLS. D. [R2702] Requirements for Traffic Engineering Over MPLS. D.
Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus.
September 1999. September 1999.
[R2748] The COPS (Common Open Policy Service) Protocol. D. [R2748] The COPS (Common Open Policy Service) Protocol. D.
Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, and A. Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, and A.
Sastry. January 2000. Sastry. January 2000.
[R2749] COPS Usage for RSVP. J. Boyle, R. Cohen, D. Durham, S.
Herzog, R. Rajan, and A. 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.
[R3060] Policy Core Information Model -- Version 1 [R3060] Policy Core Information Model -- Version 1
Specification. B. Moore, E. Ellesson, J. Strassner, and A. Specification. B. Moore, E. Ellesson, J. Strassner, and A.
Westerinen. February 2001. Westerinen. February 2001.
[R3084] COPS Usage for Policy Provisioning (COPS-PR). K. Chan,
J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F.
Reichmeyer, R. Yavatkar, and A. Smith. March 2001.
[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 X.500-X.521, Volume VIII - Fascicle VIII.8. CCITT, IXth
Plenary 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
Cisco Systems Cisco Systems
9123 Loughran Road 9123 Loughran Road
Fort Washington, MD 20744 Fort Washington, MD 20744
E-mail: john.schnizlein@cisco.com E-mail: john.schnizlein@cisco.com
John Strassner
Cisco Systems, Bldg 20
725 Alder Drive
Milpitas, CA 95035
E-mail: johns@cisco.com
John Strassner
IntelliDEN, Inc.
90 South Cascade Avenue
Colorado Springs, CO 80903
Phone: +1-719-785-0648
E-mail: john.strassner@intelliden.com
Mark Scherling Mark Scherling
Xcert International Inc. Xcert International Inc.
Suite 300 Suite 300
505 Burrard Street 505 Burrard Street
Vancouver, BC Vancouver, BC
V7X 1M3 V7X 1M3
E-mail: mscherling@xcert.com E-mail: mscherling@xcert.com
Bob Quinn Bob Quinn
Celox Networks Celox Networks
 End of changes. 40 change blocks. 
105 lines changed or deleted 139 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/