draft-ietf-policy-terminology-02.txt   draft-ietf-policy-terminology-03.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 J. Strassner
Cisco Systems Cisco Systems
Mark Scherling Mark Scherling
xCert xCert
Bob Quinn Bob Quinn
Celox Networks Celox Networks
Jay Perry
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
Jay Perry
Steve Waldbusser Steve Waldbusser
Terminology Terminology
<draft-ietf-policy-terminology-02.txt> <draft-ietf-policy-terminology-03.txt>
Thursday, March 01, 2001, 10:46 PM Thursday, April 19, 2001, 3:53 PM
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 17 skipping to change at page 2, line 17
This document is a glossary of policy-related terms. It This document is a glossary of policy-related terms. It
provides abbreviations, explanations, and recommendations for provides abbreviations, explanations, and recommendations for
use of these terms. The document takes the approach and format use of these terms. The document takes the approach and format
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.......................................16
5. Acknowledgements..........................................17 5. Acknowledgements............................................17
6. Security Considerations...................................17 6. Security Considerations.....................................17
7. References................................................17 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 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
skipping to change at page 8, line 47 skipping to change at page 8, line 47
$ 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 when the conditions of the rule are met. Policy actions
may result in the execution of one or more operations to may result in the execution of one or more operations to
affect and/or configure network traffic and network affect and/or configure network traffic and network
resources. resources.
- In [R3060], a rule's actions may be ordered. - 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) A representation of the necessary state and/or
actions should be performed. When the set of conditions prerequisites that define whether a policy rule's actions
associated with a policy rule evaluates to TRUE, then the should be performed. This representation need not be
rule should be enforced. A condition may be defined as the completely specified, but may be implicitly provided in an
occurrence of an event, or a computed expression typically implementation or protocol. When the policy condition(s)
consisting of three elements: a variable, an operator and associated with a policy rule evaluate to TRUE, then
another variable or constant. Some of these elements may be (subject to other considerations such as rule priorities
implicit in an implementation or protocol. and decision strategies) the rule should be enforced.
- In [R3060], a rule's conditions can be expressed as - In [R3060], a rule's conditions can be expressed as
either an ORed set of ANDed sets of statements either an ORed set of ANDed sets of statements
(disjunctive normal form), or an ANDed set of ORed sets (disjunctive normal form), or an ANDed set of ORed sets
of statements (conjunctive normal form). Individual of statements (conjunctive normal form). Individual
condition statements 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
skipping to change at page 12, line 46 skipping to change at page 12, line 46
rule" in the PRC context versus other uses in PCIM and the rule" in the PRC context versus other uses in PCIM and the
industry. In the latter, rules are If/Then statements - a industry. In the latter, rules are If/Then statements - a
binding of conditions to actions. PRCs are not "rules" by binding of conditions to actions. PRCs are not "rules" by
this definition, but the encoding of (network-wide) this definition, but the encoding of (network-wide)
configuration information for a device. configuration information for a device.
$ PRovisioning Instance (PRI) $ PRovisioning Instance (PRI)
(T) An instantiation of a PRovisioning Class. (See also (T) An instantiation of a PRovisioning Class. (See 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" (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, control bandwidth, and network latency. There are traffic, and control bandwidth and network latency. There
two different approaches to "Quality of Service" on IP are 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
skipping to change at page 13, line 53 skipping to change at page 13, line 49
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.
Only the latter definition is directly related to network Only the third definition (roles as selectors of policy) is
policy. directly related to the management of network policy.
However, the first definition (roles as business positions
and functions) may be referenced in policy conditions and
actions.
$ role combination $ role combination
(P) An unordered set of roles that characterize managed (P) An unordered set of roles that characterize managed
elements and indicate the applicability of policy rules and elements and indicate the applicability of policy rules and
PRovisioning Classes (PRCs). A policy system uses the set PRovisioning Classes (PRCs). A policy system uses the set
of roles reported by the managed element to determine the of roles reported by the managed element to determine the
correct rules/PRCs to be sent for enforcement. That correct rules/PRCs to be sent for enforcement. That
determination may examine all applicable policy rules determination may examine all applicable policy rules
identified by the role combination, its sub-combinations identified by the role combination, its sub-combinations
and the individual roles in the combination, or may require and the individual roles in the combination, or may require
skipping to change at page 14, line 39 skipping to change at page 14, line 39
particular rule based engine may only be capable of acting particular rule based engine may only be capable of acting
upon policy rules that are formatted in a specified way or upon policy rules that are formatted in a specified way or
adhere to a specific language. 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 - 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 ISDs. The latter is the preferred and recommended one for
(See also "data model.") Internet Standards documents. (See also "data model.")
$ Security Policy Specification Language (SPSL) $ Security Policy Specification Language (SPSL)
(T) A language designed to express security policies, (T) A language designed to express security policies,
security domains, and the entities that manage those security domains, and the entities that manage those
policies and domains. It supports policies for packet policies and domains. It supports policies for packet
filtering, IP Security (IPsec), and IKE exchanges, but may filtering, IP Security (IPsec), and IKE exchanges, but may
be extended to express other types of policies. 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,
element or host [DMTF, R2216]. Quoting from RFC 2216 network element or host [DMTF, R2216]. Quoting from RFC
[R2216], in order to completely specify a "service", one 2216 [R2216], in order to completely specify a "service",
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" on a network element or host, invoke its "service" in a network or on a network element/host, invoke
functionality, and/or coordinate services in an interdomain its functionality, and/or coordinate services in an
or end-to-end environment. 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 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, or in a
separate document. It is a set of parameters and their separate document. It is a set of parameters and their
values. The actions of enforcing and reporting monitored values. The actions of enforcing and reporting monitored
compliance can be implemented as one or more policies. (See compliance can be implemented as one or more policies. (See
also "Service Level 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 a 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 defines DiffServ parameters (such as specific
Code Points and the Per-Hop-Behavior, profile Code Points and Per-Hop-Behaviors, profile characteristics
characteristics and treatment of the traffic for those Code and treatment of the traffic for those Code Points).
Points). An SLS is a combination of an SLA (a negotiated An SLS is a combination of an SLA (a negotiated agreement)
agreement) and its SLOs (the individual metrics and and its SLOs (the individual metrics and operational
operational data to enforce). (See also "Service Level data to enforce). (See also "Service Level Agreement"
Agreement" and "Service Level Objective.") 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 17, line 34 skipping to change at page 17, line 34
[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/cims.html. DMTF web page: http://www.dmtf.org/spec/cim_schema_v24.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. [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.
[R2205] Resource ReSerVation Protocol (RSVP) - Version 1 [R2205] Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification. R. Braden, L. Zhang, S. Berson, Functional Specification. R. Braden, L. Zhang, S. Berson,
S. Herzog, and S. Jamin. September 1997. S. Herzog, and S. Jamin. September 1997.
[R2401] Security Architecture for the Internet Protocol. S. [R2216] Network Element Service Specification Template. S.
Kent, and R. Atkinson. November 1998. Shenker, and J. Wroclawski. September 1997.
[R2409] The Internet Key Exchange (IKE). D. Harkins, and D.
Carrel. November 1998.
[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.
[R2578] Structure of Management Information Version 2 (SMIv2). [R2578] Structure of Management Information Version 2 (SMIv2).
skipping to change at page 18, line 30 skipping to change at page 18, line 30
[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.
[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.
[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.
skipping to change at page 19, line 25 skipping to change at page 19, line 25
V7X 1M3 V7X 1M3
E-mail: mscherling@xcert.com E-mail: mscherling@xcert.com
Bob Quinn Bob Quinn
Celox Networks Celox Networks
One Cabot Road One Cabot Road
Hudson, MA 01749 Hudson, MA 01749
E-mail: bquinn@celoxnetworks.com E-mail: bquinn@celoxnetworks.com
Jay Perry Jay Perry
CPlane, Inc. E-mail: jay@jandg.net
5150 El Camino Real - B-31
Los Altos, CA 94022
E-mail: jay@cplane.com
Shai Herzog Shai Herzog
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
 End of changes. 20 change blocks. 
58 lines changed or deleted 50 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/