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