idnits 2.17.1 draft-ietf-policy-terminology-03.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 -- 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 (April 2001) is 8412 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 2748' is mentioned on line 191, but not defined Summary: 4 errors (**), 0 flaws (~~), 2 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 Shai Herzog 10 IP Highway 11 An-Ni Huynh 12 Lucent Technologies 13 Mark Carlson 14 Sun Microsystems 15 Jay Perry 16 Steve Waldbusser 17 April 2001 19 Terminology 21 22 Thursday, April 19, 2001, 3:53 PM 24 Status of this Memo 26 This document is an Internet-Draft and is in full conformance 27 with all provisions of Section 10 of RFC2026. 29 Internet-Drafts are working documents of the Internet 30 Engineering Task Force (IETF), its areas, and its working 31 groups. Note that other groups may also distribute working 32 documents as Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other 36 documents at any time. It is inappropriate to use Internet- 37 Drafts as reference material or to cite them other than as "work 38 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 53 provides abbreviations, explanations, and recommendations for 54 use of these terms. The document takes the approach and format 55 of RFC2828 [R2828], which defines an Internet Security Glossary. 56 The intent is to improve the comprehensibility and consistency 57 of writing that deals with network policy, particularly Internet 58 Standards documents (ISDs). 60 Table of Contents 62 1. Introduction.................................................3 63 2. Explanation of Paragraph Markings............................4 64 3. Terms........................................................4 65 4. Intellectual Property.......................................16 66 5. Acknowledgements............................................17 67 6. Security Considerations.....................................17 68 7. References..................................................17 69 8. Authors' Addresses..........................................18 70 9. Full Copyright Statement....................................20 71 1. Introduction 73 This document provides abbreviations, definitions, and 74 explanations of terms related to network policy. All definitions 75 are provided in Section 3, with the terms listed in alphabetical 76 order. 78 The intent is to improve the comprehensibility and consistency 79 of Internet Standards documents (ISDs) - i.e., RFCs, Internet- 80 Drafts, and other material produced as part of the Internet 81 Standards Process [R2026]. Benefits across the ISDs are well- 82 stated in the Introduction to RFC2828 [R2828]: 84 o "Clear, Concise, and Easily Understood Documentation" - 85 Requires that the set of terms and definitions be consistent, 86 self-supporting and uniform across all ISDs. 88 o Technical Excellence - Where all ISDs use terminology 89 accurately, precisely, and unambiguously. 91 o Prior Implementation and Testing - Requires that terms are 92 used in their plainest form, that private and "made-up" terms 93 are avoided in ISDs, and that new definitions are not created 94 that conflict with established ones. 96 o "Openness, Fairness, and Timeliness" - Where ISDs avoid terms 97 that are proprietary or otherwise favor a particular vendor, 98 or that create a bias toward a particular technology or 99 mechanism. 101 Common and/or controversial policy terms are defined. These 102 terms are directly related and specific to network policy. 104 Wherever possible, this draft takes definitions from existing 105 ISDs. It should be noted that: 107 o Expired Internet-Drafts are not referenced, nor are their 108 terminology and definitions used in this document. 110 o Multiple definitions may exist across the ISDs. Each 111 definition is listed, with its source. 113 2. Explanation of Paragraph Markings 115 Section 3 marks terms and definitions as follows: 117 o Capitalization: Only terms that are proper nouns are 118 capitalized. 120 o Paragraph Marking: Definitions and explanations are stated in 121 paragraphs that are marked as follows: 123 - "P" identifies basic policy-related terms. 125 - "T" identifies various techniques to create or convey 126 policy-related information in a network. For example, 127 COPS and an "Information Model" are two techniques for 128 communicating and describing policy-related data. 130 - "A" identifies specific Work Groups and general "areas of 131 use" of policy. For example, AAA and QoS are two "areas 132 of use" where policy concepts are extremely important to 133 their function and operation. 135 3. Terms 137 Note: In providing policy definitions, other "technology 138 specific" terms (for example, related to Differentiated 139 Services) may be used and referenced. These non-policy terms 140 will not be defined in this document, and the reader is 141 requested to go to the referenced ISD for additional detail. 143 $ AAA 144 See "Authentication, Authorization, Accounting." 146 $ abstraction levels 147 See "policy abstraction." 149 $ action 150 See "policy action." 152 $ Authentication, Authorization, Accounting (AAA) 153 (A) AAA efforts in the IETF have focused on the most widely 154 deployed use of authentication: Remote Authentication Dial 155 In User Service (RADIUS), and its expansion in Diameter (a 156 "radius" pun and not an acronym). Referencing the RADIUS 157 RFC [R2138], a network access server sends dial-user 158 credentials to an AAA server, and receives authentication 159 that the user is who he/she claims along with a set of 160 attribute-value pairs authorizing various service features 161 for that user. Policy is implied in both the 162 authentication, which can be restricted by time of day, 163 number of sessions, calling number, etc., and the 164 attribute-values authorized. AAA efforts in the IRTF are 165 wider, for control, authentication, authorization and 166 accounting of systems and environments based on policies 167 set by the administrators and users of the systems. 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 175 a Specification detailing the abstract modeling constructs 176 and principles of the Information Model, and a textual 177 language definition to represent the Model. CIM's schemas 178 are defined as a set of files, written in the language of 179 the Specification, with graphical renderings using UML 180 [UML]. Sets of classes and associations represent CIM's 181 Core and Common Models, defining an information model for 182 the "enterprise" - addressing general concepts (in Core), 183 and systems, devices, users, software distribution, the 184 physical environment, networks and policy (in the Common 185 Models). (See also "information model.") 187 $ Common Open Policy Service (COPS) 188 (T) A simple query and response TCP-based protocol that can 189 be used to exchange policy information between a Policy 190 Decision Point (PDP) and its clients (Policy Enforcement 191 Points, PEPs). [RFC 2748] (See also "Policy Decision Point" 192 and "Policy Enforcement Point.") 194 $ condition 195 See "policy condition." 197 $ configuration 198 (P) "Configuration" can be defined from two perspectives: 199 - The set of parameters in network elements and other 200 systems that determine their function and operation. 201 Some parameters are static, such as packet queue 202 assignment and can be predefined and downloaded to a 203 network element. Others are more dynamic, such as the 204 actions taken by a network device upon the occurrence of 205 some event. The distinction between static 206 (predefined) "configuration" and the dynamic state of 207 network elements blurs as setting parameters becomes 208 more responsive, and signaling controls greater degrees 209 of a network device's behavior. 210 - A static setup of a network element, done before 211 shipment to a customer and which cannot be modified by 212 the customer. 213 The first is the accepted usage in the Internet community. 215 $ COPS 216 See "Common Open Policy Service." 218 $ data model 219 (T) A mapping of the contents of an information model into a 220 form that is specific to a particular type of data store or 221 repository. A "data model" is basically the rendering of 222 an information model according to a specific set of 223 mechanisms for representing, organizing, storing and 224 handling data. It has three parts [DecSupp]: 225 - A collection of data structures such as lists, tables, 226 relations, etc. 227 - A collection of operations that can be applied to the 228 structures such as retrieval, update, summation, etc. 229 - A collection of integrity rules that define the legal 230 states (set of values) or changes of state (operations 231 on values). 232 (See also "information model.") 234 $ DEN 235 See "Directory Enabled Networks." 237 $ Differentiated Services (DS) 238 (T) The IP header field, called the DS-field. In IPv4, it 239 defines the layout of the ToS (Type of Service) octet; in 240 IPv6, it is the Traffic Class octet. [R2474] 241 (A) "Differentiated Services" is also an "area of use" for 242 QoS policies. It requires policy to define the 243 correspondence between codepoints in the packet's DS-field 244 and individual per-hop behaviors (to achieve a specified 245 per-domain behavior). (See also "Quality of Service.") 247 $ diffserv 248 See "Differentiated Services." 250 $ Directory Enabled Networks (DEN) 251 (T) A data model that is the LDAP mapping of CIM (the Common 252 Information Model). Its goals are to enable the deployment 253 and use of policy by starting with common service and user 254 concepts (defined in the information model), specifying 255 their mapping/storage in an LDAP-based repository, and 256 using these concepts in vendor/device-independent policy 257 rules. [DMTF] (See also "Common Information Model" and 258 "data model.") 260 $ domain 261 A collection of elements and services, administered in a 262 coordinated fashion. (See also "policy domain.") 264 $ DS 265 See "Differentiated Services." 266 $ filter 267 (T) A set of terms and/or criteria used for the purpose of 268 separating or categorizing. This is accomplished via 269 single- or multi-field matching of traffic header and/or 270 payload data. "Filters" are often manipulated and used in 271 network operation and policy. For example, packet filters 272 specify the criteria for matching a pattern (for example, 273 IP or 802 criteria) to distinguish separable classes of 274 traffic. 276 $ goal 277 See "policy goal." 279 $ information model 280 (T) An abstraction and representation of the entities in a 281 managed environment, their properties, attributes and 282 operations, and the way that they relate to each other. It 283 is independent of any specific repository, application, 284 protocol, or platform. 286 $ MIB 287 See "Policy Management Information Base." 289 $ MPLS 290 See "Multiprotocol Label Switching." (Also, MPLS may refer 291 to Multi-Protocol Lambda Switching in optical networks. But, 292 this is unrelated to policy and not discussed further in this 293 document.) 295 $ Multiprotocol Label Switching (MPLS) 296 (T) Integrates a label swapping and switching framework with 297 network layer routing [R2702]. The basic idea involves 298 assigning short fixed length labels to packets at the 299 ingress to an MPLS cloud. Throughout the interior of the 300 MPLS domain, the labels attached to packets are used to 301 make forwarding decisions (usually without recourse to the 302 original packet headers). 304 $ outsourced policy 305 (P) An execution model where a policy enforcement device 306 issues a query to delegate a decision for a specific policy 307 event to another component, external to it. For example, in 308 RSVP, the arrival of a new RSVP message to a PEP requires a 309 fast policy decision (not to delay the end-to-end setup). 310 The PEP may use COPS-RSVP to send a query to the PDP, 311 asking for a policy decision. [R2205, R2748] "Outsourced 312 policy" is contrasted with "provisioned policy", but they 313 are not mutually exclusive and operational systems may 314 combine the two. 316 $ PCIM 317 See "Policy Core Information Model." 318 $ PDP 319 See "Policy Decision Point." 321 $ PEP 322 See "Policy Enforcement Point." 324 $ PIB 325 See "Policy Information Base." 327 $ policy 328 (P) "Policy" can be defined from two perspectives: 329 - A definite goal, course or method of action to guide and 330 determine present and future decisions. "Policies" are 331 implemented or executed within a particular context 332 (such as policies defined within a business unit). 333 - Policies as a set of rules to administer, manage, and 334 control access to network resources. [R3060] 335 Note that these two views are not contradictory since 336 individual rules may be defined in support of business 337 goals. (See also "policy goal", "policy abstraction" and 338 "policy rule.") 340 $ policy abstraction 341 (P) Policy can be represented at different levels, ranging 342 from business goals to device-specific configuration 343 parameters. Translation between different levels of 344 "abstraction" may require information other than policy, 345 such as network and host parameter configuration and 346 capabilities. Various documents and implementations may 347 specify explicit levels of abstraction. However, these do 348 not necessarily correspond to distinct processing entities 349 or the complete set of levels in all environments. (See 350 also "configuration" and "policy translation.") 352 $ policy action 353 (P) Definition of what is to be done to enforce a policy rule, 354 when the conditions of the rule are met. Policy actions 355 may result in the execution of one or more operations to 356 affect and/or configure network traffic and network 357 resources. 358 - In [R3060], a rule's actions may be ordered. 360 $ policy condition 361 (P) A representation of the necessary state and/or 362 prerequisites that define whether a policy rule's actions 363 should be performed. This representation need not be 364 completely specified, but may be implicitly provided in an 365 implementation or protocol. When the policy condition(s) 366 associated with a policy rule evaluate to TRUE, then 367 (subject to other considerations such as rule priorities 368 and decision strategies) the rule should be enforced. 370 - In [R3060], a rule's conditions can be expressed as 371 either an ORed set of ANDed sets of statements 372 (disjunctive normal form), or an ANDed set of ORed sets 373 of statements (conjunctive normal form). Individual 374 condition statements can also be negated. 376 $ policy conflict 377 (P) Occurs when the actions of two rules (that are both 378 satisfied simultaneously) contradict each other. The entity 379 implementing the policy would not be able to determine 380 which action to perform. The implementers of policy systems 381 must provide conflict detection and avoidance or resolution 382 mechanisms to prevent this situation. "Policy conflict" is 383 contrasted with "policy error." 385 $ policy conversion 386 See "policy translation." 388 $ Policy Core Information Model (PCIM) [R3060] 389 (T) An information model describing the basic concepts of 390 policy groups, rules, conditions, actions, repositories and 391 their relationships. This model is described as a "core" 392 model since it cannot be applied without domain-specific 393 extensions (for example, extensions for QoS or IPsec). PCIM 394 is "core" with respect to the area of policy. However, it 395 is a "Common Model," with respect to CIM - in that it 396 extends the basic CIM concepts for policy. (See also 397 "Common Information Model.") 399 $ policy decision 400 (P) Two perspectives of "policy decision" exist: 401 - A "process" perspective that deals with the evaluation of 402 a policy rule's conditions 403 - A "result" perspective that deals with the actions for 404 enforcement, when the conditions of a policy rule are 405 TRUE 407 $ Policy Decision Point (PDP) 408 (P) A logical entity that makes policy decisions for itself 409 or for other network elements that request such decisions. 410 [R2753] (See also "policy decision.") 412 $ policy domain 413 (P) A collection of elements and services, and/or a portion 414 of an Internet over which a common and consistent set of 415 [..] policies are administered in a coordinated fashion. 416 [R2474] This definition of a policy domain does not 417 preclude multiple sources of policy creation within an 418 organization, but does require that the resultant policies 419 be coordinated. 421 - Policies defined in the context of one domain may need to 422 be communicated or negotiated outside of that domain. 423 (See also "policy negotiation.") 425 $ policy enforcement 426 (P) The execution of a policy decision. 428 $ Policy Enforcement Point (PEP) 429 (P) A logical entity that enforces policy decisions. [R2753] 430 (See also "policy enforcement.") 432 $ policy error 433 (P) "Policy errors" occur when attempts to enforce policy 434 actions fail, whether due to temporary state or permanent 435 mismatch between the policy actions and the device 436 enforcement capabilities. This is contrasted with "policy 437 conflict." 439 $ policy goal 440 (P) Goals are the business objectives or desired state 441 intended to be maintained by a policy system. As the 442 highest level of abstraction of policy, these goals are 443 most directly described in business rather than technical 444 terms. For example, a goal might state that a particular 445 application operate on a network as though it had its own 446 dedicated network, despite using a shared infrastructure. 447 'Policy goals' can include the objectives of a service 448 level agreement, as well as the assignment of resources to 449 applications or individuals. A policy system may be created 450 that automatically strives to achieve a goal through 451 feedback regarding whether the goal (such as a service 452 level) is being met. 454 $ Policy Information Base (PIB) 455 (T) Collections of related PRovisioning Classes (PRCs), 456 defined as a module. (See also "PRovisioning Class.") 458 $ Policy Management Information Base (MIB) 459 (T) Collections of policy-related managed objects, defined as 460 a module and accessed via an SNMP framework. 462 $ policy mapping 463 See "policy translation." 465 $ policy negotiation 466 (P) Exposing the desired or appropriate part of a policy to 467 another domain. This is necessary to support partial 468 interconnection between domains, which are operating with 469 different sets of policies. 471 $ policy repository 472 (P) "Policy repository" can be defined from three 473 perspectives: 474 - A specific data store that holds policy rules, their 475 conditions and actions, and related policy data. A 476 database or directory would be an example of such a 477 store. 478 - A logical container representing the administrative 479 scope and naming of policy rules, their conditions and 480 actions, and related policy data. A "QoS policy" domain 481 would be an example of such a container. 482 - In [R3060], a more restrictive definition than the prior 483 one exists. A PolicyRepository is a model abstraction 484 representing an administratively defined, logical 485 container for reusable policy elements. 487 $ policy request 488 (P) A message requesting a policy service. When sent by a 489 PEP to a PDP, it is more accurately qualified as a "policy 490 decision request." [R2753] (See also "policy decision.") 492 $ policy rule 493 (P) A basic building block of a policy-based system. It is 494 the binding of a set of actions to a set of conditions - 495 where the conditions are evaluated to determine whether the 496 actions are performed. [R3060] 498 $ policy server 499 (P) A marketing term whose definition is imprecise. 500 Originally, [R2753] referenced a "policy server." As the 501 RFC evolved, this term became more precise and known as the 502 Policy Decision Point (PDP). Today, the term is used in 503 marketing and other literature to refer specifically to a 504 PDP, or for any entity that uses/services policy. 506 $ policy translation 507 (P) The transformation of a policy from a representation 508 and/or level of abstraction, to another representation or 509 level of abstraction. For example, it may be necessary to 510 convert PIB data to a command line format. In this 511 "conversion," the translation to the new representation is 512 likely to require a change in the level of abstraction 513 (becoming more or less specific). Although these are 514 logically distinct tasks, they are (in most cases) blurred 515 in the act of translating/converting/mapping. Therefore, 516 this is also known as "policy conversion" or "policy 517 mapping." 519 $ PolicyGroup 520 (T) An abstraction in the Policy Core Information Model 521 [R3060]. It is a class representing a container, 522 aggregating either policy rules or other policy groups. It 523 allows the grouping of rules into a Policy, and the 524 refinement of high-level Policies to lower-level or 525 different (i.e., converted or translated) peer groups. 527 $ PRC 528 See "PRovisioning Class." 530 $ PRI 531 See "PRovisioning Instance." 533 $ provisioned policy 534 (P) An execution model where network elements are pre- 535 configured, based on policy, prior to processing events. 536 Configuration is pushed to the network device, e.g., based 537 on time of day or at initial booting of the device. The 538 focus of this model is on the distribution of configuration 539 information, and is exemplified by Differentiated Services 540 [R2475]. Based on events received, devices use downloaded 541 (pre-provisioned) mechanisms to implement policy. 542 "Provisioned policy" is contrasted with "outsourced 543 policy." 545 $ PRovisioning Class (PRC) 546 (T) An ordered set of attributes representing a type of policy 547 data. PRCs are defined in PIB modules (encoded using SPPI) 548 and registered in the Object Identifier tree. Instances of 549 each PRC are organized in tables, similar to conceptual 550 tables in SMIv2. (See also "Structure of Policy 551 Provisioning Information" and "Policy Information Base.") 552 The acronym, PRC, has evolved from "policy rule class" to 553 "provisioning class." The reason for the change is that a 554 discrepancy existed between the use of the words, "policy 555 rule" in the PRC context versus other uses in PCIM and the 556 industry. In the latter, rules are If/Then statements - a 557 binding of conditions to actions. PRCs are not "rules" by 558 this definition, but the encoding of (network-wide) 559 configuration information for a device. 561 $ PRovisioning Instance (PRI) 562 (T) An instantiation of a PRovisioning Class. (See also 563 "PRovisioning Class.") 565 $ QoS 566 See "Quality of Service." 568 $ Quality of Service (QoS) 569 (A) At a high level of abstraction, "Quality of Service" 570 refers to the ability to deliver network services according 571 to the parameters specified in a Service Level Agreement. 572 "Quality" is characterized by service availability, delay, 573 jitter, throughput and packet loss ratio. At a network 574 resource level, "Quality of Service" refers to a set of 575 capabilities that allow a service provider to prioritize 576 traffic, and control bandwidth and network latency. There 577 are two different approaches to "Quality of Service" on IP 578 networks: Integrated Services [R1633], and Differentiated 579 Service [R2475]. Integrated Services require policy control 580 over the creation of signaled reservations, which provide 581 specific quantitative end-to-end behavior for a (set of) 582 flow(s). In contrast, Differentiated Services require 583 policy to define the correspondence between codepoints in 584 the packet's DS-field and individual per-hop behaviors (to 585 achieve a specified per-domain behavior). A maximum of 64 586 per-hop behaviors limit the number of classes of service 587 traffic that can be marked at any point in a domain. These 588 classes of service signal the treatment of the packets with 589 respect to various QoS aspects, such as flow priority and 590 packet drop precedence. Policy controls the set of 591 configuration parameters for each class in Differentiated 592 Service, and the admission conditions for reservations in 593 Integrated Services. (See also "policy abstraction" and 594 "Service Level Agreement.") 596 $ Resource reSerVation Protocol (RSVP) 597 (T) A setup protocol designed for an Integrated Services 598 Internet, to reserve network resources for a path. [R2205] 599 And, a signaling mechanism for managing application 600 traffic's QoS in a Differentiated Service network. 602 $ role 603 (P) "Role" is defined from three perspectives: 604 - A business position or function, to which people and 605 logical entities are assigned [X.500] 606 - The labeled endpoints of a UML (Unified Modeling 607 Language) association. Quoting from [UML], "When a 608 class participates in an association, it has a specific 609 role that it plays in that relationship; a role is just 610 the face the class at the near end of the association 611 presents to the class at the other end of the 612 association." The Policy Core Information Model [R3060] 613 uses UML to depict its class hierarchy. 614 Relationships/associations are significant in the model. 615 - An administratively specified characteristic of a 616 managed element (for example, an interface). It is a 617 selector for policy rules and PRovisioning Classes 618 (PRCs), to determine the applicability of the rule/PRC to 619 a particular managed element. 620 Only the third definition (roles as selectors of policy) is 621 directly related to the management of network policy. 622 However, the first definition (roles as business positions 623 and functions) may be referenced in policy conditions and 624 actions. 626 $ role combination 627 (P) An unordered set of roles that characterize managed 628 elements and indicate the applicability of policy rules and 629 PRovisioning Classes (PRCs). A policy system uses the set 630 of roles reported by the managed element to determine the 631 correct rules/PRCs to be sent for enforcement. That 632 determination may examine all applicable policy rules 633 identified by the role combination, its sub-combinations 634 and the individual roles in the combination, or may require 635 that PRCs explicitly match the role combination specified 636 for the managed element. The final set of rules/PRCs for 637 enforcement are defined by the policy system, as 638 appropriate for the specified role combination of the 639 managed element. 641 $ RSVP 642 See "Resource reSerVation Protocol." 644 $ rule 645 See "policy rule." 647 $ rule based engine 648 (T) A rule based engine is able to evaluate policy 649 condition(s) and trigger appropriate policy actions. A 650 particular rule based engine may only be capable of acting 651 upon policy rules that are formatted in a specified way or 652 adhere to a specific language. 654 $ schema 655 (T) Two different perspectives of schema are defined: 656 - A set of rules that determines what data can be stored 657 in a database or directory service [DirServs] 658 - A collection of data models that are each bound to the 659 same type of repository. 660 The latter is the preferred and recommended one for 661 Internet Standards documents. (See also "data model.") 663 $ Security Policy Specification Language (SPSL) 664 (T) A language designed to express security policies, 665 security domains, and the entities that manage those 666 policies and domains. It supports policies for packet 667 filtering, IP Security (IPsec), and IKE exchanges, but may 668 be extended to express other types of policies. 670 $ service 671 (P) The behavior or functionality provided by a network, 672 network element or host [DMTF, R2216]. Quoting from RFC 673 2216 [R2216], in order to completely specify a "service", 674 one must define the "functions to be performed ..., the 675 information required ... to perform these functions, and 676 the information made available by the element to other 677 elements of the system." Policy can be used to configure a 678 "service" in a network or on a network element/host, invoke 679 its functionality, and/or coordinate services in an 680 interdomain or end-to-end environment. 682 $ Service Level Agreement (SLA) 683 (P) The documented result of a negotiation between a 684 customer/consumer and a provider of a service, that 685 specifies the levels of availability, serviceability, 686 performance, operation or other attributes of the service. 687 (See also "Service Level Objective.") [R2475] 689 $ Service Level Objective (SLO) 690 (P) Partitions an SLA into individual metrics and operational 691 information to enforce and/or monitor the SLA. "Service 692 Level Objectives" may be defined as part of an SLA, or in a 693 separate document. It is a set of parameters and their 694 values. The actions of enforcing and reporting monitored 695 compliance can be implemented as one or more policies. (See 696 also "Service Level Agreement.") 698 $ Service Level Specification (SLS) 699 (P) Specifies handling of a customer's traffic by a network 700 provider. It is negotiated between a customer and the 701 provider, and defines DiffServ parameters (such as specific 702 Code Points and Per-Hop-Behaviors, profile characteristics 703 and treatment of the traffic for those Code Points). 704 An SLS is a combination of an SLA (a negotiated agreement) 705 and its SLOs (the individual metrics and operational 706 data to enforce). (See also "Service Level Agreement" 707 and "Service Level Objective.") 709 $ SLA 710 See "Service Level Agreement." 712 $ SLO 713 See "Service Level Objective." 715 $ SLS 716 See "Service Level Specification." 718 $ SMIv2 719 See "Structure of Management Information." 721 $ SPPI 722 See "Structure of Policy Provisioning Information." 724 $ SPSL 725 See "Security Policy Specification Language." 727 $ Structure of Policy Provisioning Information (SPPI) 728 (T) An adapted subset of SNMP's Structure of Management 729 Information (SMIv2) that is used to encode collections of 730 related PRovisioning Classes as a PIB. (See also "Policy 731 Information Base" and "PRovisioning Class.") 733 $ Structure of Management Information, version 2 (SMIv2) 734 (T) An adapted subset of OSI's Abstract Syntax Notation One, 735 ASN.1 (1988) used to encode collections of related objects 736 as SNMP Management Information Base (MIB) modules. [R2578] 738 $ subject 739 (P) An entity, or collection of entities, which originates a 740 request, and is verified as authorized/not authorized to 741 perform that request. 743 $ target 744 (P) An entity, or collection of entities, which is affected 745 by a policy. For example, the "targets" of a policy to 746 reconfigure a network device are the individual services 747 that are updated and configured. 749 4. Intellectual Property 751 The IETF takes no position regarding the validity or scope of 752 any intellectual property or other rights that might be claimed 753 to pertain to the implementation or use of the technology 754 described in this document or the extent to which any license 755 under such rights might or might not be available; neither does 756 it represent that it has made any effort to identify any such 757 rights. Information on the IETF's procedures with respect to 758 rights in standards-track and standards-related documentation 759 can be found in BCP-11. 761 Copies of claims of rights made available for publication and 762 any assurances of licenses to be made available, or the result 763 of an attempt made to obtain a general license or permission for 764 the use of such proprietary rights by implementers or users of 765 this specification can be obtained from the IETF Secretariat. 767 The IETF invites any interested party to bring to its attention 768 any copyrights, patents or patent applications, or other 769 proprietary rights which may cover technology that may be 770 required to practice this standard. Please address the 771 information to the IETF Executive Director. 773 5. Acknowledgements 775 This document builds on the work of previous terminology drafts. 776 The authors of these drafts were Fran Reichmeyer, Dan Grossman, 777 John Strassner, Ed Ellesson and Matthew Condell. Also, 778 definitions for the general concepts of policy and policy rule 779 include input from Predrag Spasic. Very helpful comments and 780 suggestions were received from Juergen Schoenwaelder, Joe 781 Salowey and Jon Saperia. 783 6. Security Considerations 785 This document only defines policy-related terms. It does not 786 describe in detail the vulnerabilities of, threats to, or 787 mechanisms that protect specific policy implementations or 788 policy-related Internet protocols. 790 7. References 792 [DecSupp] Building Effective Decision Support Systems. R. 793 Sprague, and E. Carleson. Prentice Hall, 1982. 795 [DirServs] Understanding and Deploying LDAP Directory Services. 796 T. Howes, M. Smith, and G. Good. MacMillan Technical 797 Publications, 1999. 799 [DMTF] Common Information Model (CIM) Schema, version 2.x. 800 Distributed Management Task Force, Inc. The components of 801 the CIM v2.x schema are available via links on the following 802 DMTF web page: http://www.dmtf.org/spec/cim_schema_v24.html. 804 [R1633] Integrated Services in the Internet Architecture: An 805 Overview. R. Braden, D. Clark, and S. Shenker. June 1994. 807 [R2026] The Internet Standards Process -- Revision 3. S. 808 Bradner. October 1996. 810 [R2138] Remote Authentication Dial In User Service (RADIUS). C. 811 Rigney, A. Rubens, W. Simpson, and S. Willens. April 1997. 813 [R2205] Resource ReSerVation Protocol (RSVP) -- Version 1 814 Functional Specification. R. Braden, L. Zhang, S. Berson, 815 S. Herzog, and S. Jamin. September 1997. 817 [R2216] Network Element Service Specification Template. S. 818 Shenker, and J. Wroclawski. September 1997. 820 [R2474] Definition of the Differentiated Services Field (DS 821 Field) in the IPv4 and IPv6 Headers. K. Nichols, S. Blake, 822 F. Baker, and D. Black. December 1998. 824 [R2475] An Architecture for Differentiated Service. S. Blake, 825 D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. 826 December 1998. 828 [R2578] Structure of Management Information Version 2 (SMIv2). 829 K. McGloughrie, D. Perkins, J. Schoenwaelder, J. Case, M. 830 Rose, and S. Waldbusser. April 1999. 832 [R2702] Requirements for Traffic Engineering Over MPLS. D. 833 Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus. 834 September 1999. 836 [R2748] The COPS (Common Open Policy Service) Protocol. D. 837 Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, and A. 838 Sastry. January 2000. 840 [R2753] A Framework for Policy-based Admission Control. R. 841 Yavatkar, D. Pendarakis, and R. Guerin. January 2000. 843 [R2828] Internet Security Glossary. R. Shirey. May 2000. 845 [R3060] Policy Core Information Model -- Version 1 846 Specification. B. Moore, E. Ellesson, J. Strassner, and A. 847 Westerinen. February 2001. 849 [UML] The Unified Modeling Language User Guide. G. Booch, J. 850 Rumbaugh, and I. Jacobson. Addison-Wesley, 1999. 852 [X.500] Data Communications Networks Directory, Recommendations 853 X.500-X.521, Volume VIII - Fascicle VIII.8. CCITT, IXth 854 Plenary Assembly, Melbourne. November 1988. 856 8. Authors' Addresses 858 Andrea Westerinen 859 Cisco Systems, Bldg 20 860 725 Alder Drive 861 Milpitas, CA 95035 862 E-mail: andreaw@cisco.com 864 John Schnizlein 865 Cisco Systems 866 9123 Loughran Road 867 Fort Washington, MD 20744 868 E-mail: john.schnizlein@cisco.com 869 John Strassner 870 Cisco Systems, Bldg 20 871 725 Alder Drive 872 Milpitas, CA 95035 873 E-mail: johns@cisco.com 875 Mark Scherling 876 Xcert International Inc. 877 Suite 300 878 505 Burrard Street 879 Vancouver, BC 880 V7X 1M3 881 E-mail: mscherling@xcert.com 883 Bob Quinn 884 Celox Networks 885 One Cabot Road 886 Hudson, MA 01749 887 E-mail: bquinn@celoxnetworks.com 889 Jay Perry 890 E-mail: jay@jandg.net 892 Shai Herzog 893 IPHighway 894 55 New York Avenue 895 Framingham, MA 01701 896 E-mail: herzog@iphighway.com 898 An-Ni Huynh 899 Lucent Technologies 900 2139 Route 35 901 Holmdel, NJ 07733 902 E-mail: ahuynh@lucent.com 904 Mark Carlson 905 Sun Microsystems 906 3030 S. Technology Ct. Bldg B. 907 Broomfield, CO 80021 908 Email: mark.carlson@sun.com 910 Steve Waldbusser 911 Email: waldbusser@nextbeacon.com 912 9. Full Copyright Statement 914 Copyright (C) The Internet Society (2000). All Rights Reserved. 916 This document and translations of it may be copied and furnished 917 to others, and derivative works that comment on or otherwise 918 explain it or assist in its implementation may be prepared, 919 copied, published and distributed, in whole or in part, without 920 restriction of any kind, provided that the above copyright 921 notice and this paragraph are included on all such copies and 922 derivative works. However, this document itself may not be 923 modified in any way, such as by removing the copyright notice or 924 references to the Internet Society or other Internet 925 organizations, except as needed for the purpose of developing 926 Internet standards in which case the procedures for copyrights 927 defined in the Internet Standards process must be followed, or 928 as required to translate it into languages other than English. 930 The limited permissions granted above are perpetual and will not 931 be revoked by the Internet Society or its successors or assigns. 933 This document and the information contained herein is provided 934 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 935 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 936 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 937 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 938 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 939 PARTICULAR PURPOSE.