idnits 2.17.1 draft-ietf-policy-terminology-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([R2828]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 645 has weird spacing: '... packet filt...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2000) is 8562 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 2748' is mentioned on line 190, but not defined == Missing Reference: 'R2216' is mentioned on line 651, but not defined == Unused Reference: 'DiffPolicy' is defined on line 778, but no explicit reference was found in the text == Unused Reference: 'R2401' is defined on line 834, but no explicit reference was found in the text == Unused Reference: 'R2409' is defined on line 837, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-08 == Outdated reference: A later version (-09) exists of draft-ietf-snmpconf-diffpolicy-02 == Outdated reference: A later version (-09) exists of draft-ietf-diffserv-pib-01 == Outdated reference: A later version (-08) exists of draft-ietf-diffserv-new-terms-03 == Outdated reference: A later version (-09) exists of draft-ietf-rap-frameworkpib-02 == Outdated reference: A later version (-15) exists of draft-ietf-snmpconf-pm-03 == Outdated reference: A later version (-05) exists of draft-ietf-policy-qos-info-model-01 == Outdated reference: A later version (-07) exists of draft-ietf-rap-sppi-02 == Outdated reference: A later version (-04) exists of draft-ietf-ipsp-spsl-00 Summary: 4 errors (**), 0 flaws (~~), 16 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Policy Framework Working Group A. Westerinen 2 INTERNET-DRAFT J. Schnizlein 3 Category: Informational J. Strassner 4 Cisco Systems 5 Mark Scherling 6 xCert 7 Bob Quinn 8 Celox Networks 9 Jay Perry 10 CPlane 11 Shai Herzog 12 IP Highway 13 An-Ni Huynh 14 Lucent Technologies 15 Mark Carlson 16 Sun Microsystems 17 Steve Waldbusser 18 November 2000 20 Policy Terminology 22 23 Friday, November 24, 2000, 12:03 AM 25 Status of this Memo 27 This document is an Internet-Draft and is in full conformance with 28 all provisions of Section 10 of RFC2026. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 Copyright Notice 48 Copyright (C) The Internet Society (2000). All Rights Reserved. 50 Abstract 52 This document is a glossary of policy-related terms. It provides 53 abbreviations, explanations, and recommendations for use of these 54 terms. The document takes the approach and format of RFC2828 55 [R2828], which defines an Internet Security Glossary. The intent is 56 to improve the comprehensibility and consistency of writing that 57 deals with network policy, particularly Internet Standards documents 58 (ISDs). 60 Table of Contents 62 1. Introduction.....................................................3 63 2. Explanation of Paragraph Markings................................4 64 3. Terms............................................................4 65 4. Intellectual Property...........................................15 66 5. Acknowledgements................................................16 67 6. Security Considerations.........................................16 68 7. References......................................................16 69 8. Authors' Addresses..............................................18 70 9. Full Copyright Statement........................................20 71 1. Introduction 73 This document provides abbreviations, definitions, and explanations 74 of terms related to network policy. All definitions are provided in 75 Section 3, with the terms listed in alphabetical order. 77 The intent is to improve the comprehensibility and consistency of 78 Internet Standards documents (ISDs) - i.e., RFCs, Internet-Drafts, 79 and other material produced as part of the Internet Standards 80 Process [R2026]. Benefits across the ISDs are well-stated in the 81 Introduction to RFC2828 [R2828]: 83 o "Clear, Concise, and Easily Understood Documentation" - Requires 84 that the set of terms and definitions be consistent, self- 85 supporting and uniform across all ISDs. 87 o Technical Excellence - Where all ISDs use terminology accurately, 88 precisely, and unambiguously. 90 o Prior Implementation and Testing - Requires that terms are used in 91 their plainest form, that private and "made-up" terms are avoided 92 in ISDs, and that new definitions are not created that conflict 93 with established ones. 95 o "Openness, Fairness, and Timeliness" - Where ISDs avoid terms that 96 are proprietary or otherwise favor a particular vendor, or that 97 create a bias toward a particular technology or mechanism. 99 Common and/or controversial policy terms are defined in this draft. 100 These terms are directly related and specific to network policy. 101 This is a "living" document that is expected to grow over the next 102 several months, as the current terms are reviewed and additional 103 words suggested for inclusion. 105 Wherever possible, this draft takes definitions from existing ISDs. 106 It should be noted that: 108 o Expired Internet-Drafts are not referenced, nor are their 109 terminology and definitions used in this document. 111 o Multiple definitions may exist across the ISDs. Each definition 112 will be listed, with its source. 114 Where definitions are contradictory, the recommendations of the draft 115 editors are presented. The draft editors will work with other ISD 116 authors to remove contradictions. 118 2. Explanation of Paragraph Markings 120 Section 3 marks terms and definitions as follows: 122 o Capitalization: Only terms that are proper nouns are capitalized. 124 o Paragraph Marking: Definitions and explanations are stated in 125 paragraphs that are marked as follows: 127 - "P" identifies basic policy-related terms. 129 - "T" identifies various techniques to create or convey policy- 130 related information in a network. For example, COPS and an 131 "Information Model" are two techniques for communicating and 132 describing policy-related data. 134 - "A" identifies specific Work Groups and general "areas of use" 135 of policy. For example, AAA and QoS are two "areas of use" 136 where policy concepts are extremely important to their 137 function and operation. 139 3. Terms 141 Note: In providing policy definitions, other "technology specific" 142 terms (for example, related to Differentiated Services) may be used 143 and referenced. These non-policy terms will not be defined in this 144 document, and the reader is requested to go to the referenced ISD for 145 additional detail. 147 $ AAA 148 See "Authentication, Authorization, Accounting." 150 $ abstraction levels 151 See "policy abstraction." 153 $ action 154 See "policy action." 156 $ Authentication, Authorization, Accounting (AAA) 157 (A) AAA efforts in the IETF have focused on the most widely 158 deployed use of authentication: Remote Authentication Dial In 159 User Service (RADIUS), and its expansion in Diameter (a "radius" 160 pun and not an acronym) [DIAMETER]. Referencing the RADIUS RFC 161 [R2138], a network access server sends dial-user credentials to 162 a AAA server, and receives authentication that the user is who 163 he/she claims along with a set of attribute-value pairs 164 authorizing various service features for that user. 165 Policy is implied in both the authentication, which can be 166 restricted by time of day, number of sessions, calling number, 167 etc., and the attribute-values authorized. 169 $ CIM 170 See "Common Information Model." 172 $ Common Information Model (CIM) 173 (T) An object-oriented information model published by the DMTF 174 (Distributed Management Task Force) [DMTF]. It consists of a 175 Specification detailing the abstract modeling constructs and 176 principles of the Information Model, and a textual language 177 definition to represent the Model. CIM's schemas are defined as 178 a set of files, written in the language of the Specification, 179 with graphical renderings using UML [UML]. Sets of classes and 180 associations represent CIM's Core and Common Models, defining an 181 information model for the "enterprise" - addressing general 182 concepts (in Core), and systems, devices, users, software 183 distribution, the physical environment, networks and policy (in 184 the Common Models). (See also "information model.") 186 $ Common Open Policy Service (COPS) 187 (T) A simple query and response TCP-based protocol that can be 188 used to exchange policy information between a Policy Decision 189 Point (PDP) and its clients (Policy Enforcement Points, PEPs). 190 [RFC 2748] (See also "Policy Decision Point" and "Policy 191 Enforcement Point.") 193 $ condition 194 See "policy condition." 196 $ configuration 197 (P) "Configuration" can be defined from two perspectives: 198 - The set of parameters in network elements and other systems 199 that determine their function and operation. Some parameters 200 are static, such as packet queue assignment and can be 201 predefined and downloaded to a network element. Others are 202 more dynamic, such as the actions taken by a network device 203 upon the occurrence of some event. The distinction between 204 static (predefined) "configuration" and the dynamic state of 205 network elements blurs as setting parameters becomes more 206 responsive, and signaling controls greater degrees of a 207 network device's behavior. 208 - A static setup of a network element, done before shipment to 209 a customer and which cannot be modified by the customer. 210 The first is the accepted usage in the Internet community. 212 $ COPS 213 See "Common Open Policy Service." 215 $ data model 216 (T) A mapping of the contents of an information model into a form 217 that is specific to a particular type of data store or 218 repository. A "data model" is basically the rendering of an 219 information model according to a specific set of mechanisms for 220 representing, organizing, storing and handling data. It has 221 three parts [DecSupp]: 222 - A collection of data structures such as lists, tables, 223 relations, etc. 224 - A collection of operations that can be applied to the 225 structures such as retrieval, update, summation, etc. 226 - A collection of integrity rules that define the legal states 227 (set of values) or changes of state (operations on values). 228 (See also "information model.") 230 $ DEN 231 See "Directory Enabled Networks." 233 $ Differentiated Services (DS) 234 (T) The IP header field, called the DS-field. In IPv4, it defines 235 the layout of the ToS (Type of Service) octet; in IPv6, it is 236 the Traffic Class octet. [R2474, DSTERMS] 237 (A) "Differentiated Services" is also an "area of use" for QoS 238 policies. It requires policy to define the correspondence 239 between codepoints in the packet's DS-field and individual per- 240 hop behaviors (to achieve a specified per-domain behavior). 241 (See also "Quality of Service.") 243 $ diffserv 244 See "Differentiated Services." 246 $ Directory Enabled Networks (DEN) 247 (T) A data model that is the LDAP mapping of CIM (the Common 248 Information Model). Its goals are to enable the deployment and 249 use of policy by starting with common service and user concepts 250 (defined in the information model), specifying their 251 mapping/storage in an LDAP-based repository, and using these 252 concepts in vendor/device-independent policy rules. [DMTF] (See 253 also "Common Information Model" and "data model.") 255 $ domain 256 See "policy domain." 258 $ DS 259 See "Differentiated Services." 261 $ filter 262 (T) A set of terms and/or criteria used for the purpose of 263 separating or categorizing. "Filters" are often manipulated and 264 used in network policy. 265 - Packet filters are defined in [FrameworkPIB, DiffServPIB]. 266 They specify the criteria for matching a pattern (for example, 267 IP or 802 traffic criteria) to appear in packets belonging to 268 flows, e.g. microflows or behavior aggregates. Associated with 269 each filter is a permit/deny flag. 271 $ goal 272 See "policy goal." 274 $ information model 275 (T) An abstraction and representation of the entities in a managed 276 environment, their properties, attributes and operations, and 277 the way that they relate to each other. It is independent of 278 any specific repository, application, protocol, or platform. 280 $ MIB 281 See "Policy Management Information Base." 283 $ MPLS 284 See "Multiprotocol Label Switching." 286 $ Multiprotocol Label Switching (MPLS) 287 (T) Integrates a label swapping and switching framework with 288 network layer routing [R2702]. The basic idea involves 289 assigning short fixed length labels to packets at the ingress 290 to an MPLS cloud. Throughout the interior of the MPLS domain, 291 the labels attached to packets are used to make forwarding 292 decisions (usually without recourse to the original packet 293 headers). 295 $ outsourced policy 296 (P) An execution model where a policy enforcement device issues a 297 query to delegate a decision for a specific policy event to 298 another component, external to it. For example, in RSVP, the 299 arrival of a new RSVP message to a PEP requires a fast policy 300 decision (not to delay the end-to-end setup). The PEP may use 301 COPS-RSVP to send a query to the PDP, asking for a policy 302 decision. [R2205, R2748] "Outsourced policy" is contrasted with 303 "provisioned policy", but they are not mutually exclusive and 304 operational systems may combine the two. 306 $ PCIM 307 See "Policy Core Information Model." 309 $ PDP 310 See "Policy Decision Point." 312 $ PEP 313 See "Policy Enforcement Point." 315 $ PIB 316 See "Policy Information Base." 318 $ policy 319 (P) "Policy" can be defined from two perspectives: 320 - A definite goal, course or method of action to guide and 321 determine present and future decisions. "Policies" are 322 implemented or executed within a particular context (such as 323 policies defined within a business unit). 324 - Policies as a set of rules to administer, manage, and control 325 access to network resources. [PCIM] 326 Note that these two views are not contradictory since 327 individual rules may be defined in support of business goals. 328 (See also "policy goal", "policy abstraction" and "policy 329 rule.") 331 $ policy abstraction 332 (P) Policy can be represented at different levels, ranging from 333 business goals to device-specific configuration parameters. 334 Translation between different levels of "abstraction" may 335 require information, other than policy, such as network and 336 host parameter configuration and capabilities. Various 337 documents and implementations may specify explicit levels of 338 abstraction [for example, DiffPolicy]. However, these do not 339 necessarily correspond to distinct processing entities or the 340 complete set of levels in all environments. (See also 341 "configuration" and "policy translation.") 343 $ policy action 344 (P) Definition of what is to be done to enforce a policy rule, 345 when the conditions of the rule are met. Policy actions may 346 result in the execution of one or more operations to affect 347 and/or configure network traffic and network resources. 348 - In [PCIM], a rule's actions may be ordered. 350 $ policy condition 351 (P) An expression used to determine whether a policy rule's 352 actions should be performed. When the set of conditions 353 associated with a policy rule evaluates to TRUE, then the rule 354 should be enforced. A condition may be defined as the occurrence 355 of an event, or a computed expression typically consisting of 356 three elements: a variable, an operator and another variable or 357 constant. [QoSModel] Some of these elements may be implicit in 358 an implementation or protocol. 359 - In [PCIM], a rule's conditions can be expressed as either an 360 ORed set of ANDed sets of statements (disjunctive normal 361 form), or an ANDed set of ORed sets of statements 362 (conjunctive normal form). Individual condition statements 363 can also be negated. 365 $ policy conflict 366 (P) Occurs when the actions of two rules (that are both satisfied 367 simultaneously) contradict each other. The entity implementing 368 the policy would not be able to determine which action to 369 perform. The implementers of policy systems must provide 370 conflict detection and avoidance or resolution mechanisms to 371 prevent this situation. "Policy conflict" is contrasted with 372 "policy error." 373 $ policy conversion 374 See "policy translation." 376 $ Policy Core Information Model (PCIM) 377 (T) An information model describing the basic concepts of policy 378 groups, rules, conditions, actions, repositories and their 379 relationships. This model is described as a "core" model since 380 it cannot be applied without domain-specific extensions (for 381 example, extensions for QoS or IPsec). PCIM is "core" with 382 respect to the area of policy. However, it is a "Common Model," 383 with respect to CIM - in that it extends the basic CIM concepts 384 for policy. (See also "Common Information Model") 386 $ policy decision 387 (P) Two perspectives of "policy decision" exist: 388 - A "process" perspective that deals with the evaluation of a 389 policy rule's conditions 390 - A "result" perspective that deals with the actions for 391 enforcement, when the conditions of a policy rule are TRUE 393 $ Policy Decision Point (PDP) 394 (P) A logical entity that makes policy decisions for itself or for 395 other network elements that request such decisions. [R2753] 396 (See also "policy decision.") 398 $ policy domain 399 (P) A contiguous portion of an Internet over which a consistent 400 set of [..] policies are administered in a coordinated fashion. 401 [R2474] This definition of a policy domain does not preclude 402 multiple sources of policy creation within an organization, but 403 does require that the resultant policies be coordinated. The 404 definition given in RFC 2474 for Differentiated Services is 405 very close to that of a security domain, defined in [SPSL]. In 406 [SPSL], it is stated: "A security domain is defined as a 407 connected set of network entities that are protected by policy 408 enforcement points (PEP) placed on every communication path 409 going through the perimeter of the domain. Every policy 410 enforcement point of the domain works to enforce the common set 411 of security policies associated with the domain." 413 $ policy enforcement 414 (P) The execution of a policy decision. 416 $ Policy Enforcement Point (PEP) 417 (P) A logical entity that enforces policy decisions. [R2753] (See 418 also "policy enforcement.") 420 $ policy error 421 (P) "Policy errors" occur when attempts to enforce policy actions 422 fail, whether due to temporary state or permanent mismatch 423 between the policy actions and the device enforcement 424 capabilities. This is contrasted with "policy conflict." 425 $ policy goal 426 (P) Goals are the business objectives or desired state intended to 427 be maintained by a policy system. As the highest level of 428 abstraction of policy, these goals are most directly described 429 in business rather than technical terms. For example, a goal 430 might state that a particular application operate on a network 431 as though it had its own dedicated network, despite using a 432 shared infrastructure. 'Policy goals' can include the objectives 433 of a service level agreement, as well as the assignment of 434 resources to applications or individuals. A policy system may be 435 created that automatically strives to achieve a goal through 436 feedback regarding whether the goal (such as a service level) is 437 being met. 439 $ Policy Information Base (PIB) 440 (T) Collections of related PRovisioning Classes (PRCs), defined as 441 a module. [FrameworkPIB] (See also "PRovisioning Class") 443 $ Policy Management Information Base (MIB) 444 (T) Collections of policy-related managed objects, defined as a 445 module and accessed via an SNMP framework. [PolicyMIB] 447 $ policy mapping 448 See "policy translation." 450 $ policy negotiation 451 (P) Exposing the desired or appropriate part of a policy to 452 another domain. This is necessary to support partial 453 interconnection between domains, which are operating with 454 different sets of policies. The need for "policy negotiation" 455 is described in the IPsec Policy Working Group charter [IPSP]: 456 "4) adopt or develop a policy exchange and negotiation 457 protocol. The protocol must be capable of: i) discovering 458 policy servers, ii) distributing and negotiating security 459 policies, and; iii) resolving policy conflicts in both 460 intra/inter domain environments." 462 $ policy repository 463 (P) "Policy repository" can be defined from three perspectives: 464 - A specific data store that holds policy rules, their 465 conditions and actions, and related policy data. A directory 466 would be an example of such a store. 467 - A logical container representing the administrative scope and 468 naming of policy rules, their conditions and actions, and 469 related policy data. A QoS policy domain would be an example 470 of such a container. [QoSModel] 471 - In [PCIM], a more restrictive definition than the prior one 472 exists. PolicyRepository is a model abstraction representing 473 an administratively defined, logical container for reusable 474 policy conditions and policy actions. 476 $ policy request 477 (P) Sent by a PEP to a PDP, it is more accurately qualified as a 478 "policy decision request." [R2753] (See also "policy 479 decision.") 481 $ policy rule 482 (P) A basic building block of a policy-based system. It is the 483 binding of a set of actions to a set of conditions - where the 484 conditions are evaluated to determine whether the actions are 485 performed. [PCIM] 487 $ policy server 488 (P) A marketing term whose definition is imprecise. Originally, 489 [R2753] referenced a "policy server." As the RFC evolved, this 490 term became more precise and known as the Policy Decision Point 491 (PDP). Today, the term is used in marketing and other 492 literature to refer specifically to a PDP, or for any entity 493 that uses/services policy. 495 $ policy translation 496 (P) The transformation of a policy from a representation and/or 497 level of abstraction, to another representation or level of 498 abstraction. For example, it may be necessary to convert PIB 499 data to a command line format. In this "conversion," the 500 translation to the new representation is likely to require a 501 change in the level of abstraction (becoming more or less 502 specific). Although these are logically distinct tasks, they 503 are (in most cases) blurred in the act of 504 translating/converting/mapping. Therefore, this is also known 505 as "policy conversion" or "policy mapping." 507 $ PolicyGroup 508 (T) An abstraction in the Policy Core Information Model [PCIM]. It 509 is a class representing a container, aggregating either policy 510 rules or other policy groups. It allows the grouping of rules 511 into a Policy, and the refinement of high-level Policies to 512 lower-level or different (i.e., converted or translated) peer 513 groups. 515 $ PolicyRepository 516 (T) An abstraction in the Policy Core Information Model [PCIM]. 517 It is a class representing an administratively defined, logical 518 container for reusable policy conditions and policy actions. 519 (See also "policy repository.") 521 $ PRC 522 See "PRovisioning Class." 524 $ PRI 525 See "PRovisioning Instance." 526 $ provisioned policy 527 (P) An execution model where network elements are pre-configured, 528 based on policy, prior to processing events. Configuration is 529 pushed to the network device, e.g., based on time of day or at 530 initial booting of the device. The focus of this model is on 531 the distribution of configuration information, and is 532 exemplified by Differentiated Services [R2475]. Based on 533 events received, devices use downloaded (pre-provisioned) 534 mechanisms to implement policy. "Provisioned policy" is 535 contrasted with "outsourced policy." 537 $ PRovisioning Class (PRC) 538 (T) An ordered set of attributes representing a type of policy 539 data. PRCs are defined in PIB modules (encoded using SPPI) and 540 registered in the Object Identifier tree. Instances of each PRC 541 are organized in tables, similar to conceptual tables in SMIv2. 542 [R2578, FrameworkPIB] (See also "Structure of Policy 543 Provisioning Information" and "Policy Information Base") 544 The acronym, PRC, has evolved from "policy rule class" to 545 "provisioning class." The reason for the change is that a 546 discrepancy existed between the use of the words, "policy rule" 547 in the PRC context versus other uses in PCIM and the industry. 548 In the latter, rules are If/Then statements - a binding of 549 conditions to actions. PRCs are not "rules" by this definition, 550 but the encoding of (network-wide) configuration information 551 for a device. 553 $ PRovisioning Instance (PRI) 554 (T) An instantiation of a PRovisioning Class. [FrameworkPIB] (See 555 also "PRovisioning Class") 557 $ QoS 558 See "Quality of Service." 560 $ Quality of Service (QoS) 561 (A) At a high level of abstraction, "Quality of Service" refers to 562 the ability to deliver network services according to the 563 parameters specified in a Service Level Agreement. "Quality" 564 is characterized by service availability, delay, jitter, 565 throughput and packet loss ratio. At a network resource level, 566 "Quality of Service" refers to a set of capabilities that allow 567 a service provider to prioritize traffic, control bandwidth, 568 and network latency. There are two different approaches to 569 "Quality of Service" on IP networks: Integrated Services 570 [R1633], and Differentiated Service [R2475]. Integrated 571 Services require policy control over the creation of signaled 572 reservations, which provide specific quantitative end-to-end 573 behavior for a (set of) flow(s). In contrast, Differentiated 574 Services require policy to define the correspondence between 575 codepoints in the packet's DS-field and individual per-hop 576 behaviors (to achieve a specified per-domain behavior). A 577 maximum of 64 per-hop behaviors limit the number of classes of 578 service traffic that can be marked at any point in a domain. 579 These classes of service signal the treatment of the packets 580 with respect to various QoS aspects, such as flow priority and 581 packet drop precedence. Policy controls the set of 582 configuration parameters for each class in Differentiated 583 Service, and the admission conditions for reservations in 584 Integrated Services. (See also "policy abstraction" and 585 "Service Level Agreement.") 587 $ Resource reSerVation Protocol (RSVP) 588 (T) A setup protocol designed for an Integrated Services Internet, 589 to reserve network resources for a path. [R2205] And, a 590 signaling mechanism for managing application traffic's QoS in a 591 Differentiated Service network. [DCLASS] 593 $ role 594 (P) "Role" is defined from three perspectives: 595 - A business position or function, to which people and logical 596 entities are assigned [X.500] 597 - The labeled endpoints of a UML (Unified Modeling Language) 598 association. Quoting from [UML], "When a class participates 599 in an association, it has a specific role that it plays in 600 that relationship; a role is just the face the class at the 601 near end of the association presents to the class at the 602 other end of the association." The Policy Core Information 603 Model [PCIM] uses UML to depict its class hierarchy. 604 Relationships/associations are significant in the model. 605 - An administratively specified characteristic of a managed 606 element (for example, an interface). It is a selector for 607 policy rules and PRovisioning Classes (PRCs), to determine 608 the applicability of the rule/PRC to a particular managed 609 element. [PolicyMIB, PCIM, FrameworkPIB, DiffServPIB] 610 Only the latter definition is directly related to network 611 policy. 613 $ role combination 614 (P) An unordered set of roles that characterize managed elements 615 and indicate the applicability of policy rules and PRovisioning 616 Classes (PRCs). A policy system uses the set of roles reported 617 by the managed element to determine the correct rules/PRCs to be 618 sent for enforcement. That determination may examine all 619 applicable policy rules identified by the role combination, its 620 sub-combinations and the individual roles in the combination 621 [PCIM], or may require that PRCs explicitly match the role 622 combination specified for the managed element [FrameworkPIB, 623 DiffServPIB]. The final set of rules/PRCs for enforcement are 624 defined by the policy system, as appropriate for the specified 625 role combination of the managed element. 627 $ RSVP 628 See "Resource reSerVation Protocol." 630 $ rule 631 See "policy rule." 633 $ schema 634 (T) Two different perspectives of schema are defined: 635 - A set of rules that determines what data can be stored in a 636 database or directory service [DirServs] 637 - A collection of data models that are each bound to the same 638 type of repository. 639 The latter is the preferred and recommended one for ISDs. (See 640 also "data model.") 642 $ Security Policy Specification Language (SPSL) 643 (T) A language designed to express security policies, security 644 domains, and the entities that manage those policies and 645 domains. It supports policies for packet filtering, IP 646 Security (IPsec), and IKE exchanges, but may be extended to 647 express other types of policies. [SPSL] 649 $ service 650 (P) The behavior or functionality of a network element or host 651 [DMTF, R2216]. Quoting from RFC 2216 [R2216], in order to 652 completely specify a "service", one must define the "functions 653 to be performed . . ., the information required . . . to 654 perform these functions, and the information made available by 655 the element to other elements of the system." Policy can be 656 used to configure a "service" on a network element or host, 657 invoke its functionality, and/or coordinate services in an 658 interdomain or end-to-end environment. 660 $ Service Level Agreement (SLA) 661 (P) The documented result of a negotiation between a 662 customer/consumer and a provider of a service, that specifies 663 the levels of availability, serviceability, performance, 664 operation or other attributes of the service. (See also 665 "Service Level Objective.") 667 $ Service Level Objective (SLO) 668 (P) Partitions an SLA into individual metrics and operational 669 information to enforce and/or monitor the SLA. "Service Level 670 Objectives" may be defined as part of an SLA, or in a separate 671 document. It is a set of parameters and their values. The 672 actions of enforcing and reporting monitored compliance can be 673 implemented as one or more policies. (See also "Service Level 674 Agreement.") 676 $ Service Level Specification (SLS) 677 (P) Specifies handling of customer's traffic by a network 678 provider. It is negotiated between a customer and the provider, 679 and (for DiffServ) defines a set of parameters (such as 680 specific Code Points and the Per-Hop-Behavior, profile 681 characteristics and treatment of the traffic for those Code 682 Points) and their values. An SLS is a combination of an 683 SLA (a negotiated agreement) and its SLOs (the individual 684 metrics and operational data to enforce). [DSTERMS] (See also 685 "Service Level Agreement" and "Service Level Objective.") 687 $ SLA 688 See "Service Level Agreement." 690 $ SLO 691 See "Service Level Objective." 693 $ SLS 694 See "Service Level Specification." 696 $ SMIv2 697 See "Structure of Management Information." 699 $ SPPI 700 See "Structure of Policy Provisioning Information." 702 $ SPSL 703 See "Security Policy Specification Language." 705 $ Structure of Policy Provisioning Information (SPPI) 706 (T) An adapted subset of SNMP's Structure of Management 707 Information (SMIv2) that is used to encode collections of 708 related PRovisioning Classes as a PIB. [R2578, SPPI] (See also 709 "Policy Information Base" and "PRovisioning Class") 711 $ Structure of Management Information, version 2 (SMIv2) 712 (T) An adapted subset of OSI's Abstract Syntax Notation One, ASN.1 713 (1988) used to encode collections of related objects as SNMP 714 Management Information Base (MIB) modules. [R2578] 716 $ subject 717 (P) An entity, or collection of entities, which originates a 718 request, and is verified as authorized/not authorized to 719 perform that request. 721 $ target 722 (P) An entity, or collection of entities, which is affected by a 723 policy. For example, the "targets" of a policy to reconfigure a 724 network device are the individual services that are updated and 725 configured. 727 4. Intellectual Property 729 The IETF takes no position regarding the validity or scope of any 730 intellectual property or other rights that might be claimed to 731 pertain to the implementation or use of the technology described in 732 this document or the extent to which any license under such rights 733 might or might not be available; neither does it represent that it 734 has made any effort to identify any such rights. Information on the 735 IETF's procedures with respect to rights in standards-track and 736 standards-related documentation can be found in BCP-11. 738 Copies of claims of rights made available for publication and any 739 assurances of licenses to be made available, or the result of an 740 attempt made to obtain a general license or permission for the use of 741 such proprietary rights by implementers or users of this 742 specification can be obtained from the IETF Secretariat. 744 The IETF invites any interested party to bring to its attention any 745 copyrights, patents or patent applications, or other proprietary 746 rights which may cover technology that may be required to practice 747 this standard. Please address the information to the IETF Executive 748 Director. 750 5. Acknowledgements 752 This document builds on the work of previous terminology drafts. The 753 authors of these drafts were Fran Reichmeyer, Dan Grossman, John 754 Strassner, Ed Ellesson and Matthew Condell. Also, definitions for 755 the general concepts of policy and policy rule include input from 756 Predrag Spasic. Very helpful comments and suggestions were received 757 from Juergen Schoenwaelder and Jon Sapiera. 759 6. Security Considerations 761 This document only defines policy-related terms. It does not describe 762 in detail the vulnerabilities of, threats to, or mechanisms that 763 protect specific policy implementations or policy-related Internet 764 protocols. 766 7. References 768 [DCLASS] Format of the RSVP DCLASS Object. Internet Draft, draft- 769 ietf-issll-dclass-01.txt, Y. Bernet. October 1999. 771 [DecSupp] Building Effective Decision Support Systems. R. Sprague, 772 and E. Carleson. Prentice Hall, 1982. 774 [DIAMETER] DIAMETER Framework Document. Internet Draft, draft- 775 calhoun-diameter-framework-08.txt, P. Calhoun, G. Zorn, P. Pan, 776 and H. Akhtar. June 2000. 778 [DiffPolicy] The DiffServ Policy MIB. Internet Draft, draft-ietf- 779 snmpconf-diffpolicy-02.txt, H. Hazewinkel and D. Partain. June 780 2000. 782 [DiffServPIB] Differentiated Services Quality of Service Policy 783 Information Base. Internet Draft, draft-ietf-diffserv-pib- 784 01.txt, M. Fine, K. McCloughrie, J. Seligson, K. Chan, S. Hahn, 785 A. Smith, and F. Reichmeyer. July 2000. 787 [DirServs] Understanding and Deploying LDAP Directory Services. T. 788 Howes, M. Smith, and G. Good. MacMillan Technical Publications, 789 1999. 791 [DMTF] Common Information Model (CIM) Schema, version 2.4. 792 Distributed Management Task Force, Inc. August, 2000. The 793 components of the CIM v2.4 schema are available via links on the 794 following DMTF web page: 795 http://www.dmtf.org/spec/cim_schema_v24.html. 797 [DSTERMS] New Terminology for Diffserv. Internet Draft, draft-ietf- 798 diffserv-new-terms-03.txt, D. Grossman. November 1999. 800 [FrameworkPIB] Framework Policy Information Base. Internet Draft, 801 draft-ietf-rap-frameworkpib-02.txt, M. Fine, K. McCloughrie, J. 802 Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, and F. 803 Reichmeyer. September 2000. 805 [IPSP] IP Security Policy (ipsp) Working Group Charter. February 806 2000. http://www.ietf.org/html.charters/ipsp-charter.html. 808 [PCIM] Policy Core Information Model - Version 1 Specification. 809 Internet Draft, draft-ietf-policy-core-info-model-08.txt, B. 810 Moore, E. Ellison, J. Strassner, and A. Westerinen. October 811 2000. 813 [PolicyMIB] Policy Based Management MIB. Internet Draft, draft-ietf- 814 snmpconf-pm-03.txt, S. Waldbusser, J. Saperia and T. Hongal. 815 October 2000. 817 [QoSModel] Policy Framework QoS Information Model. Internet Draft, 818 draft-ietf-policy-qos-info-model-01.txt, Y. Snir, Y. Ramberg, J. 819 Strassner, and R. Cohen. April 2000. 821 [R1633] Integrated Services in the Internet Architecture: An 822 Overview. R. Braden, D. Clark, and S. Shenker. June 1994. 824 [R2026] The Internet Standards Process -- Revision 3. S. Bradner. 825 October 1996. 827 [R2138] Remote Authentication Dial In User Service (RADIUS). C. 828 Rigney, A. Rubens, W. Simpson, and S. Willens. April 1997. 830 [R2205] Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 831 Specification. R. Braden, L. Zhang, S. Berson, S. Herzog, and S. 832 Jamin. September 1997. 834 [R2401] Security Architecture for the Internet Protocol. S. Kent, 835 and R. Atkinson. November 1998. 837 [R2409] The Internet Key Exchange (IKE). D. Harkins, and D. Carrel. 838 November 1998. 840 [R2474] Definition of the Differentiated Services Field (DS Field) 841 in the IPv4 and IPv6 Headers. K. Nichols, S. Blake, F. Baker, 842 and D. Black. December 1998. 844 [R2475] An Architecture for Differentiated Service. S. Blake, D. 845 Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. December 846 1998. 848 [R2578] Structure of Management Information Version 2 (SMIv2). K. 849 McGloughrie, D. Perkins, J. Schoenwaelder, J. Case, M. Rose, and 850 S. Waldbusser. April 1999. 852 [R2702] Requirements for Traffic Engineering Over MPLS. D. Awduche, 853 J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus. September 854 1999. 856 [R2748] The COPS (Common Open Policy Service) Protocol. D. Durham, 857 J. Boyle, R. Cohen, S. Herzog, R. Rajan, and A. Sastry. January 858 2000. 860 [R2753] A Framework for Policy-based Admission Control. R. 861 Yavatkar, D. Pendarakis, and R. Guerin. January 2000. 863 [R2828] Internet Security Glossary. R. Shirey. May 2000. 865 [SPPI] Structure of Policy Provisioning Information (SPPI). 866 Internet Draft, draft-ietf-rap-sppi-02.txt, K. McCloughrie, M. 867 Fine, J. Seligson, K. Chan, S. Chan, R. Sahita, A. Smith, and F. 868 Reichmeyer. September 2000. 870 [SPSL] Security Policy Specification Language. Internet Draft, 871 draft-ietf-ipsp-spsl-00.txt, M. Condell, C. Lynn, and J. Zao. 872 March 2000. 874 [UML] The Unified Modeling Language User Guide. G. Booch, J. 875 Rumbaugh, and I. Jacobson. Addison-Wesley, 1999. 877 [X.500] Data Communications Networks Directory, Recommendations 878 X.500-X.521, Volume VIII - Fascicle VIII.8. CCITT, IXth Plenary 879 Assembly, Melbourne. November 1988. 881 8. Authors' Addresses 883 Andrea Westerinen 884 Cisco Systems, Bldg 20 885 725 Alder Drive 886 Milpitas, CA 95035 887 E-mail: andreaw@cisco.com 889 John Schnizlein 890 Cisco Systems 891 9123 Loughran Road 892 Fort Washington, MD 20744 893 E-mail: john.schnizlein@cisco.com 895 John Strassner 896 Cisco Systems, Bldg 20 897 725 Alder Drive 898 Milpitas, CA 95035 899 E-mail: johns@cisco.com 901 Mark Scherling 902 Xcert International Inc. 903 Suite 300 904 505 Burrard Street 905 Vancouver, BC 906 V7X 1M3 907 E-mail: mscherling@xcert.com 909 Bob Quinn 910 Celox Networks 911 One Cabot Road 912 Hudson, MA 01749 913 E-mail: bquinn@celoxnetworks.com 915 Jay Perry 916 CPlane, Inc. 917 5150 El Camino Real - B-31 918 Los Altos, CA 94022 919 E-mail: jay@cplane.com 921 Shai Herzog 922 IPHighway 923 55 New York Avenue 924 Framingham, MA 01701 925 E-mail: herzog@iphighway.com 927 An-Ni Huynh 928 Lucent Technologies 929 2139 Route 35 930 Holmdel, NJ 07733 931 E-mail: ahuynh@lucent.com 932 Mark Carlson 933 Sun Microsystems 934 2990 Center Green Court South 935 Boulder, CO 80301 936 Email: mark.carlson@sun.com 938 Steve Waldbusser 939 Email: waldbusser@nextbeacon.com 941 9. Full Copyright Statement 943 Copyright (C) The Internet Society (2000). All Rights Reserved. 945 This document and translations of it may be copied and furnished to 946 others, and derivative works that comment on or otherwise explain it 947 or assist in its implementation may be prepared, copied, published 948 and distributed, in whole or in part, without restriction of any 949 kind, provided that the above copyright notice and this paragraph are 950 included on all such copies and derivative works. However, this 951 document itself may not be modified in any way, such as by removing 952 the copyright notice or references to the Internet Society or other 953 Internet organizations, except as needed for the purpose of 954 developing Internet standards in which case the procedures for 955 copyrights defined in the Internet Standards process must be 956 followed, or as required to translate it into languages other than 957 English. 959 The limited permissions granted above are perpetual and will not be 960 revoked by the Internet Society or its successors or assigns. 962 This document and the information contained herein is provided on an 963 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 964 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 965 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 966 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 967 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.