idnits 2.17.1 draft-ietf-policy-terminology-00.txt: -(624): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 616 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 (July 2000) is 8686 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 2748' is mentioned on line 193, but not defined == Missing Reference: 'RFC 2401' is mentioned on line 283, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) == Missing Reference: 'RFC 2409' is mentioned on line 283, but not defined ** Obsolete undefined reference: RFC 2409 (Obsoleted by RFC 4306) == Missing Reference: 'R2216' is mentioned on line 622, but not defined == Unused Reference: 'R2138' is defined on line 784, but no explicit reference was found in the text == Unused Reference: 'R2401' is defined on line 791, but no explicit reference was found in the text == Unused Reference: 'R2409' is defined on line 794, 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 (-08) exists of draft-ietf-diffserv-new-terms-02 == Outdated reference: A later version (-08) exists of draft-ietf-policy-core-info-model-07 == Outdated reference: A later version (-05) exists of draft-ietf-policy-qos-info-model-01 == Outdated reference: A later version (-15) exists of draft-ietf-snmpconf-pm-01 == Outdated reference: A later version (-07) exists of draft-ietf-rap-sppi-00 == Outdated reference: A later version (-04) exists of draft-ietf-ipsp-spsl-00 Summary: 6 errors (**), 0 flaws (~~), 17 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 Bank One 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 July 2000 19 Policy Terminology 21 22 Friday, July 14, 2000, 12:10 AM 24 Status of this Memo 26 This document is an Internet-Draft and is in full conformance with 27 all provisions of Section 10 of RFC2026. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Copyright Notice 47 Copyright (C) The Internet Society (2000). All Rights Reserved. 49 Abstract 51 This document is a glossary of policy-related terms. It provides 52 abbreviations, explanations, and recommendations for use of these 53 terms. The document takes the approach and format of RFC2828 54 [R2828], which defines an Internet Security Glossary. The intent is 55 to improve the comprehensibility and consistency of writing that 56 deals with network policy, particularly Internet Standards documents 57 (ISDs). 59 Table of Contents 61 1. Introduction....................................................3 62 2. Explanation of Paragraph Markings...............................4 63 3. Terms...........................................................4 64 4. Intellectual Property..........................................15 65 5. Acknowledgements...............................................15 66 6. Security Considerations........................................16 67 7. References.....................................................16 68 8. Authors' Addresses.............................................18 69 9. Full Copyright Statement.......................................19 70 1. Introduction 72 This document provides abbreviations, definitions, and explanations 73 of terms related to network policy. All definitions are provided in 74 Section 3, with the terms listed in alphabetical order. 76 The intent is to improve the comprehensibility and consistency of 77 Internet Standards documents (ISDs)--i.e., RFCs, Internet-Drafts, and 78 other material produced as part of the Internet Standards Process 79 [R2026]. Benefits across the ISDs are well-stated in the Introduction 80 to RFC2828 [R2828]: 82 o "Clear, Concise, and Easily Understood Documentation" - Requires 83 that the set of terms and definitions be consistent, self- 84 supporting and uniform across all ISDs. 86 o Technical Excellence - Where all ISDs use terminology accurately, 87 precisely, and unambiguously. 89 o Prior Implementation and Testing - Requires that terms are used in 90 their plainest form, that private and "made-up" terms are avoided 91 in ISDs, and that new definitions are not created that conflict 92 with established ones. 94 o "Openness, Fairness, and Timeliness" - Where ISDs avoid terms that 95 are proprietary or otherwise favor a particular vendor, or that 96 create a bias toward a particular technology or mechanism. 98 Common and/or controversial policy terms are defined in this draft. 99 These terms are directly related and specific to network policy. 100 This is a "living" document that is expected to grow over the next 101 several months, as the current terms are reviewed and additional 102 words suggested for inclusion. 104 Wherever possible, this draft takes definitions from existing ISDs. 105 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 definition 111 will be listed, with its source. 113 Where definitions are contradictory, the recommendations of the draft 114 editors are presented. The draft editors will work with other ISD 115 authors to remove contradictions. 117 2. Explanation of Paragraph Markings 119 Section 3 marks terms and definitions as follows: 121 o Capitalization: Only terms that are proper nouns are capitalized. 123 o Paragraph Marking: Definitions and explanations are stated in 124 paragraphs that are marked as follows: 126 - "P" identifies basic policy-related terms. 128 - "M" identifies various mechanisms to create or convey policy- 129 related information in a network. For example, COPS and an 130 "Information Model" are two mechanisms for communicating and 131 describing policy-related data. 133 - "A" identifies specific Work Groups and general "areas of use" 134 of policy. For example, AAA and QoS are two "areas of use" 135 where policy concepts are extremely important to their 136 function and operation. 138 3. Terms 140 Note: In providing policy definitions, other "technology specific" 141 terms (for example, related to Differentiated Services) may be used 142 and referenced. These non-policy terms will not be defined in this 143 document, and the reader is requested to go to the referenced ISD 144 for additional detail. 146 $ AAA 147 See "Authentication, Authorization, Accounting." 149 $ abstraction levels 150 See "policy abstraction." 152 $ action 153 See "policy action." 155 $ Authentication, Authorization, Accounting (AAA) 156 (A) AAA efforts in the IETF have focused on the most widely 157 deployed use of authentication: Remote Authentication Dial In 158 User Service (RADIUS). Referencing the RADIUS RFC (R2138), a 159 network access server sends dial-user credentials to a AAA 160 server, and receives authentication that the user is who he/she 161 claims along with a set of attribute-value pairs authorizing 162 various service features for that user. Policy is implied in 163 both the authentication, which can be restricted by time of day, 164 number of sessions, calling number, etc., and the attribute- 165 values authorized. The AAA Working Group is also completing its 166 requirements for a general-purpose AAA protocol expanding beyond 167 RADIUS. The only protocol proposed thus far is Diameter 168 ("radius" pun - not an acronym) [DIAMETER]. And, the 169 Authentication Authorization Accounting ARCHitecture Research 170 Group (AAAARCH) was formed as a new area of research within the 171 IRTF, with the goal of coordination "with the Policy Framework 172 WG and others." 174 $ CIM 175 See "Common Information Model." 177 $ Common Information Model (CIM) 178 (M) An object-oriented information model published by the DMTF 179 (Distributed Management Task Force) [DMTF]. It consists of a 180 Specification detailing the abstract modeling constructs and 181 principles of the Information Model, and a language definition 182 to represent the Model. CIM includes a set of files, written in 183 the language specified in the Specification. These are known as 184 the Core and Common Models, and define an information model for 185 the "enterprise" - addressing systems, devices, users, software 186 distribution, the physical environment, networks and policy. 187 (See also "information model.") 189 $ Common Open Policy System (COPS) 190 (M) A simple query and response TCP-based protocol that can be 191 used to exchange policy information between a Policy Decision 192 Point (PDP) and its clients (Policy Enforcement Points, PEPs). 193 [RFC 2748] (See also "Policy Decision Point" and "Policy 194 Enforcement Point.") 196 $ condition 197 See "policy condition." 199 $ configuration 200 (P) The set of parameters in network elements and other systems 201 that determine their function and operation. Some parameters 202 are static, such as packet queue assignment and can be 203 predefined and downloaded to a network element. Others are 204 more dynamic, such as the actions taken by a network device 205 upon the occurrence of some event. The distinction between 206 static (predefined) "configuration" and the dynamic state of 207 network elements blurs as setting parameters becomes more 208 responsive, and signaling controls greater degrees of a 209 network device's behavior. 211 $ COPS 212 See "Common Open Policy System." 214 $ data model 215 (M) A mapping of the contents of an information model into a form 216 that is specific to a particular type of data store or 217 repository. A "data model" is basically the rendering of an 218 information model according to a specific set of mechanisms for 219 representing, organizing, storing and handling data. It has 220 three parts [DecSupp]: 221 - A collection of data structures such as lists, tables, 222 relations, etc. 223 - A collection of operations that can be applied to the 224 structures such as retrieval, update, summation, etc. 225 - A collection of integrity rules that define the legal states 226 (set of values) or changes of state (operations on values). 227 (See also "information model.") 229 $ DEN 230 See "Directory Enabled Networks." 232 $ Differentiated Services (DS) 233 (M) The IP header field, called the DS-field. In IPv4, it defines 234 the layout of the ToS (Type of Service) octet; in IPv6, it is 235 the Traffic Class octet. [R2474, DSTERMS] 236 (A) "Differentiated Services" is also an "area of use" for QoS 237 policies. It requires policy to define the correspondence 238 between codepoints in the packet's DS-field and individual per- 239 hop behaviors (to achieve a specified per-domain behavior). 240 (See also "Quality of Service.") 242 $ diffserv 243 See "Differentiated Services." 245 $ Directory Enabled Networks (DEN) 246 (M) A data model that is the LDAP mapping of CIM (the Common 247 Information Model). Its goals are to enable the deployment and 248 use of policy by starting with common service and user concepts 249 (defined in the information model), specifying their 250 mapping/storage in an LDAP-based repository, and using these 251 concepts in vendor/device-independent policy rules. [DMTF] (See 252 also "Common Information Model" and "data model.") 254 $ domain 255 See "policy domain." 257 $ DS 258 See "Differentiated Services." 260 $ filter 261 (M) A set of terms and/or criteria used for the purpose of 262 separating or categorizing. "Filters" are often manipulated and 263 used in network policy. 264 - Packet filters are defined in [PIB]. They specify the 265 criteria for matching a pattern (for example, IP or 802 266 traffic criteria) to appear in packets belonging to flows, 267 e.g. microflows or behavior aggregates. Associated with 268 each filter is a permit/deny flag. 270 $ goal 271 See "policy goal." 273 $ information model 274 (M) An abstraction and representation of the entities in a managed 275 environment, their properties, attributes and operations, and 276 the way that they relate to each other. It is independent of 277 any specific repository, application, protocol, or platform. 279 $ Internet Protocol Security Policy (IPSP) 280 (A) An IETF Working Group chartered to define a standard data 281 model, specification language and exchange protocol for 282 supporting IP Security Policies that are compatible with the 283 existing IPsec architecture [RFC 2401] and IKE [RFC 2409], 284 complementing the standards work achieved by the IPsec Working 285 Group. 287 $ IPSP 288 See "Internet Protocol Security Policy." 290 $ MPLS 291 See "Multiprotocol Label Switching." 293 $ Multiprotocol Label Switching (MPLS) 294 (M) Integrates a label swapping framework with network layer 295 routing [R2702]. The basic idea involves assigning short fixed 296 length labels to packets at the ingress to an MPLS cloud. 297 Throughout the interior of the MPLS domain, the labels attached 298 to packets are used to make forwarding decisions (usually 299 without recourse to the original packet headers). 301 $ outsourced policy 302 (P) An execution model where a policy enforcement device issues a 303 query to delegate a decision for a specific policy event to 304 another component, external to it. For example, in RSVP, the 305 arrival of a new RSVP message to a PEP requires a fast policy 306 decision (not to delay the end-to-end setup). The PEP may use 307 COPS-RSVP to send a query to the PDP, asking for a policy 308 decision. [R2205, R2748] "Outsourced policy" is contrasted with 309 "provisioned policy", but they are not mutually exclusive and 310 operational systems may combine the two. 312 $ PDP 313 See "Policy Decision Point." 315 $ PEP 316 See "Policy Enforcement Point." 318 $ PIB 319 See "Policy Information Base." 320 $ policy 321 (P) "Policy" can be defined from two perspectives: 322 - A definite goal, course or method of action to guide and 323 determine present and future decisions. "Policies" are 324 implemented or executed within a particular context (such 325 as policies defined within a business unit). 326 - Policies as a set of rules to administer, manage, and 327 control access to network resources. [PCIM] 328 Note that these two views are not contradictory since 329 individual rules may be defined in support of business goals. 330 (See also "policy goal", "policy abstraction" and "policy 331 rule.") 333 $ policy abstraction 334 (P) Policy can be represented at different levels, ranging from 335 business goals to device-specific configuration parameters. 336 Translation between different levels of "abstraction" may 337 require information, other than policy, such as network and 338 host parameter configuration and capabilities. (See also 339 "configuration" and "policy translation.") 341 $ policy action 342 (P) Definition of what is to be done to enforce a policy rule, 343 when the conditions of the rule are met. Policy actions may 344 result in the execution of one or more operations to affect 345 and/or configure network traffic and network resources. 346 - In [PCIM], a rule's actions may be ordered. 348 $ policy condition 349 (P) An expression used to determine whether a policy rule's 350 actions should be performed. When the set of conditions 351 associated with a policy rule evaluates to TRUE, then the rule 352 should be enforced. A condition may be defined as the occurrence 353 of an event, or a computed expression typically consisting of 354 three elements: a variable, an operator and another variable or 355 constant. [QoSModel] Some of these elements may be implicit in 356 an implementation or protocol. 357 - In [PCIM], a rule's conditions can be expressed as either an 358 ORed set of ANDed sets of statements (disjunctive normal 359 form), or an ANDed set of ORed sets of statements 360 (conjunctive normal form). Individual condition statements 361 can also be negated. 363 $ policy conflict 364 (P) Occurs when the actions of two rules (that are both satisfied 365 simultaneously) contradict each other. The entity implementing 366 the policy would not be able to determine which action to 367 perform. The implementers of policy systems must provide 368 conflict detection and avoidance or resolution mechanisms to 369 prevent this situation. "Policy conflict" is contrasted with 370 "policy error." 371 $ policy conversion 372 See "policy translation." 374 $ policy decision 375 (P) Two perspectives of "policy decision" exist: 376 - A "process" perspective that deals with the evaluation of a 377 policy rule's conditions 378 - A "result" perspective that deals with the actions for 379 enforcement, when the conditions of a policy rule are TRUE 381 $ Policy Decision Point (PDP) 382 (P) A logical entity that makes policy decisions for itself or for 383 other network elements that request such decisions. [R2753] 384 (See also "policy decision.") 386 $ policy domain 387 (P) A contiguous portion of an Internet over which a consistent 388 set of [..] policies are administered in a coordinated fashion. 389 [R2474] This definition of a policy domain does not preclude 390 multiple sources of policy creation within an organization, but 391 does require that the resultant policies be coordinated. The 392 definition given in RFC 2474 for Differentiated Services is 393 very close to that of a security domain, defined in [SPSL]. In 394 [SPSL], it is stated: "A security domain is defined as a 395 connected set of network entities that are protected by policy 396 enforcement points (PEP) placed on every communication path 397 going through the perimeter of the domain. Every policy 398 enforcement point of the domain works to enforce the common set 399 of security policies associated with the domain." 401 $ policy enforcement 402 (P) The execution of a policy decision. 404 $ Policy Enforcement Point (PEP) 405 (P) A logical entity that enforces policy decisions. [R2753] (See 406 also "policy enforcement.") 408 $ policy error 409 (P) "Policy errors" occur when attempts to enforce policy actions 410 fail, whether due to temporary state or permanent mismatch 411 between the policy actions and the device enforcement 412 capabilities. This is contrasted with "policy conflict." 414 $ policy goal 415 (P) Goals are the business objectives or conditions/states 416 intended to be maintained by a policy system. At the highest 417 level of abstraction of policy, "goals" are most directly 418 related to business rather than technical terms. For example, a 419 "goal" might be that a particular application receives network 420 behavior equivalent to having its own dedicated network, 421 despite using a shared infrastructure. (See also "policy 422 abstraction.") 423 $ Policy Information Base (PIB) 424 (M) Collections of related policy rule classes (PRCs), defined as 425 a module. [PIB] 427 $ policy negotiation 428 (P) Exposing the desired or appropriate part of a policy to 429 another domain. This is necessary to support partial 430 interconnection between domains, which are operating with 431 different sets of policies. The need for "policy negotiation" 432 is described in the IPsec Policy Working Group charter [IPSP]: 433 "4) adopt or develop a policy exchange and negotiation 434 protocol. The protocol must be capable of: i) discovering 435 policy servers, ii) distributing and negotiating security 436 policies, and; iii) resolving policy conflicts in both 437 intra/inter domain environments." 439 $ policy repository 440 (P) "Policy repository" can be defined from three perspectives: 441 - A specific data store that holds policy rules, their 442 conditions and actions, and related policy data. A 443 directory would be an example of such a store. 444 - A logical container representing the administrative scope and 445 naming of policy rules, their conditions and actions, and 446 related policy data. A QoS policy domain would be an example 447 of such a container. [QoSModel] 448 - In [PCIM], a more restrictive definition than the prior one 449 exists. PolicyRepository is a model abstraction representing 450 an administratively defined, logical container for reusable 451 policy conditions and policy actions. 453 $ policy request 454 (P) Sent by a PEP to a PDP, it is more accurately qualified as a 455 "policy decision request." [R2753] (See also "policy 456 decision.") 458 $ Policy Retrieval Point (PRP) 459 (P) A client of a policy repository. [AAA] 460 - Outside of [AAA], this term is not used, since policy 461 retrieval is a necessary function of a policy-based 462 system. For example, a PDP includes both policy retrieval 463 and decision making functionality. 465 $ policy rule 466 (P) A basic building block of a policy-based system. It is the 467 binding of a set of actions to a set of conditions - where the 468 conditions are evaluated to determine whether the actions are 469 performed. [PCIM] 471 $ Policy Rule Class (PRC) 472 (M) An ordered set of scalar attributes, defined in a PIB. "Policy 473 Rule Classes" are arranged in a hierarchical structure similar 474 to tables in SNMP's SMIv2. [R2578, PIB] 475 $ policy server 476 (P) A marketing term whose definition is imprecise. Originally, 477 [R2753] referenced a "policy server." As the RFC evolved, this 478 term became more precise and known as the Policy Decision Point 479 (PDP). Today, the term is used in marketing and other 480 literature to refer specifically to a PDP, or for any entity 481 that uses/services policy. 483 $ policy translation 484 (P) The transformation of a policy from a representation and/or 485 level of abstraction, to another representation or level of 486 abstraction. For example, it may be necessary to convert PIB 487 data to a command line format. This is also known as "policy 488 conversion." 490 $ PolicyGroup 491 (M) An abstraction in the Policy Core Information Model [PCIM]. It 492 is a class representing a container, aggregating either policy 493 rules or other policy groups. It allows the grouping of rules 494 into a Policy, and the refinement of high-level Policies to 495 lower-level or different (i.e., converted or translated) peer 496 groups. 498 $ PolicyRepository 499 (M) An abstraction in the Policy Core Information Model [PCIM]. 500 It is a class representing an administratively defined, logical 501 container for reusable policy conditions and policy actions. 502 (See also "policy repository.") 504 $ PRC 505 See "Policy Rule Class." 507 $ provisioned policy 508 (P) An execution model where network elements are pre-configured, 509 based on policy, prior to processing events. Configuration is 510 pushed to the network device, e.g., based on time of day or at 511 initial booting of the device. The focus of this model is on 512 the distribution of configuration information, and is 513 exemplified by Differentiated Services [R2475]. Based on 514 events received, devices use downloaded (pre-provisioned) 515 mechanisms to implement policy. "Provisioned policy" is 516 contrasted with "outsourced policy." 518 $ PRP 519 See "Policy Retrieval Point." 521 $ QoS 522 See "Quality of Service." 523 $ Quality of Service (QoS) 524 (A) At a high level of abstraction, "Quality of Service" refers 525 to the ability to deliver network services according to the 526 parameters specified in a Service Level Agreement. "Quality" 527 is characterized by service availability, delay, jitter, 528 throughput and packet loss ratio. At a network resource level, 529 "Quality of Service" refers to a set of capabilities that allow 530 a service provider to prioritize traffic, control bandwidth, 531 and network latency. There are two different approaches to 532 "Quality of Service" on IP networks: Integrated Services 533 [R1633], and Differentiated Service [R2475]. Integrated 534 Services require policy control over the creation of signaled 535 reservations, which provide specific quantitative end-to-end 536 behavior for a (set of) flow(s). In contrast, Differentiated 537 Services require policy to define the correspondence between 538 codepoints in the packet's DS-field and individual per-hop 539 behaviors (to achieve a specified per-domain behavior). A 540 maximum of 64 per-hop behaviors limit the number of classes of 541 service traffic that can be marked at any point in a domain. 542 These classes of service signal the treatment of the packets 543 with respect to various QoS aspects, such as flow priority and 544 packet drop precedence. Policy controls the set of 545 configuration parameters for each class in Differentiated 546 Service, and the admission conditions for reservations in 547 Integrated Services. (See also "policy abstraction" and 548 "Service Level Agreement.") 550 $ Resource reSerVation Protocol (RSVP) 551 (M) A setup protocol designed for an Integrated Services Internet, 552 to reserve network resources for a path. [R2205] And, a 553 signaling mechanism for managing application traffic's QoS in a 554 Differentiated Service network. [DCLASS] 556 $ role 557 (P) "Role" is defined from four perspectives: 558 - A business position or function, to which people and logical 559 entities are assigned [X.500] 560 - The labeled endpoints of a UML (Unified Modeling Language) 561 association. Quoting from [UML], "When a class participates 562 in an association, it has a specific role that it plays in 563 that relationship; a role is just the face the class at the 564 near end of the association presents to the class at the 565 other end of the association." The Policy Core Information 566 Model [PCIM] uses UML to depict its class hierarchy. 567 Relationships/associations are significant in the model. 568 - An abstract characteristic assigned to a network element that 569 expresses a notion, such as a political, financial, legal, 570 geographical, or architectural attribute, typically not 571 directly derivable from information stored on the system 572 [SNMPCONF] 573 - A string characterizing a particular function of a network 574 element or interface, that can be used to identify particular 575 behavior associated with that element. It is a selector for 576 policy rules, to determine the applicability of the rule to a 577 particular network element. "Roles" abstract the capabilities 578 and/or use of network devices and resources. [PCIM, PIB] 579 Only the latter two definitions are directly related to network 580 policy. The last is the preferred and recommended definition. 581 The use of the term in [SNMPCONF] contradicts the established 582 usage in references [PCIM] and [PIB]. 584 $ role combination 585 (P) An unordered set of roles. Two interpretations of "role 586 combination" currently exist: 587 - The set of roles in a "role combination" must be identical to 588 the set of the roles of the network element or interface 589 [PIB] 590 - The selection process for a "role-combination" chooses 591 policies associated with the combination itself, policies 592 associated with each of its sub-combinations, and policies 593 associated with each of the individual roles in the 594 combination [PCIM] 595 These two interpretations are contradictory and require 596 alignment to prevent confusion across the ISDs. 598 $ RSVP 599 See "Resource reSerVation Protocol." 601 $ rule 602 See "policy rule." 604 $ schema 605 (M) Two different perspectives of schema are defined: 606 - A set of rules that determines what data can be stored in a 607 database or directory service [DirServs] 608 - A collection of data models that are each bound to the same 609 type of repository. 610 The latter is the preferred and recommended one for ISDs. (See 611 also "data model.") 613 $ Security Policy Specification Language (SPSL) 614 (M) A language designed to express security policies, security 615 domains, and the entities that manage those policies and 616 domains. It supports policies for packet filtering, IP 617 Security (IPsec), and IKE exchanges, but may be extended to 618 express other types of policies. [SPSL] 620 $ service 621 (P) The behavior or functionality of a network element or host 622 [DMTF, R2216]. Quoting from RFC 2216 [R2216], in order to 623 completely specify a "service", one must define the "functions 624 to be performed �, the information required � to perform these 625 functions, and the information made available by the element to 626 other elements of the system." Policy can be used to configure 627 a "service" on a network element or host, invoke its 628 functionality, and/or coordinate services in an interdomain or 629 end-to-end environment. 631 $ Service Level Agreement (SLA) 632 (P) The documented result of a negotiation between a 633 customer/consumer and a provider of a service, that specifies 634 the levels of availability, serviceability, performance, 635 operation or other attributes of the service. (See also 636 "Service Level Objective.") 638 $ Service Level Objective (SLO) 639 (P) Partitions an SLA into individual metrics and operational 640 information to enforce and/or monitor the SLA. "Service Level 641 Objectives" may be defined as part of an SLA, or in a separate 642 document. It is a set of parameters and their values. The 643 actions of enforcing and reporting monitored compliance can be 644 implemented as one or more policies. (See also "Service Level 645 Agreement.") 647 $ Service Level Specification (SLS) 648 (P) Specifies handling of customer's traffic by a network 649 provider. It is negotiated between a customer and the provider, 650 and defines DiffServ parameters (such as specific Code Points 651 and the Per-Hop-Behavior, profile characteristics and treatment 652 of the traffic for those Code Points). An SLS is a combination 653 of an SLA (a negotiated agreement) and its SLOs (the individual 654 metrics and operational data to enforce). [DSTERMS] (See also 655 "Service Level Agreement" and "Service Level Objective.") 657 $ SLA 658 See "Service Level Agreement." 660 $ SLO 661 See "Service Level Objective." 663 $ SLS 664 See "Service Level Specification." 666 $ SMIv2 667 See "Structure of Management Information." 669 $ SPPI 670 See "Structure of Policy Provisioning Information." 672 $ SPSL 673 See "Security Policy Specification Language." 675 $ Structure of Policy Provisioning Information (SPPI) 676 (M) An adapted subset of SNMP's Structure of Management 677 Information (SMIv2) that is used to encode collections of 678 related Policy Rule Classes as a PIB. [R2578, SPPI] 679 $ Structure of Management Information, version 2 (SMIv2) 680 (M) An adapted subset of OSI's Abstract Syntax Notation One, 681 ASN.1 (1988) used to encode collections of related objects as 682 SNMP Management Information Base (MIB) modules. [R2578] 684 $ subject 685 (P) An entity, or collection of entities, which originates a 686 request, and is verified as authorized/not authorized to 687 perform that request. 689 $ target 690 (P) An entity, or collection of entities, which is affected by a 691 policy. For example, the "targets" of a policy to reconfigure a 692 network device are the individual services that are updated and 693 configured. 695 4. Intellectual Property 697 The IETF takes no position regarding the validity or scope of any 698 intellectual property or other rights that might be claimed to 699 pertain to the implementation or use of the technology described in 700 this document or the extent to which any license under such rights 701 might or might not be available; neither does it represent that it 702 has made any effort to identify any such rights. Information on the 703 IETF's procedures with respect to rights in standards-track and 704 standards-related documentation can be found in BCP-11. 706 Copies of claims of rights made available for publication and any 707 assurances of licenses to be made available, or the result of an 708 attempt made to obtain a general license or permission for the use of 709 such proprietary rights by implementers or users of this 710 specification can be obtained from the IETF Secretariat. 712 The IETF invites any interested party to bring to its attention any 713 copyrights, patents or patent applications, or other proprietary 714 rights which may cover technology that may be required to practice 715 this standard. Please address the information to the IETF Executive 716 Director. 718 5. Acknowledgements 720 This document builds on the work of previous terminology drafts. The 721 authors of these drafts were Fran Reichmeyer, Dan Grossman, John 722 Strassner, Ed Ellesson and Matthew Condell. Also, definitions for 723 the general concepts of policy and policy rule include input from 724 Predrag Spasic. 726 6. Security Considerations 728 This document only defines policy-related terms. It does not describe 729 in detail the vulnerabilities of, threats to, or mechanisms that 730 protect specific policy implementations or policy-related Internet 731 protocols. 733 7. References 735 [AAA] AAA Authorization Framework. Internet Draft, draft-ietf-aaa- 736 authz-arch-00.txt, J. Vollbrecht, P. Calhoun, S. Farrell, L. 737 Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, and D. 738 Spence. October 1999. 740 [DCLASS] Format of the RSVP DCLASS Object. Internet Draft, draft- 741 ietf-issll-dclass-01.txt, Y. Bernet. October 1999. 743 [DecSupp] Building Effective Decision Support Systems. R. Sprague, 744 and E. Carleson. Prentice Hall, 1982. 746 [DIAMETER] DIAMETER Framework Document. Internet Draft, draft- 747 calhoun-diameter-framework-08.txt, P. Calhoun, G. Zorn, P. Pan, 748 and H. Akhtar. June 2000. 750 [DirServs] Understanding and Deploying LDAP Directory Services. T. 751 Howes, M. Smith, and G. Good. MacMillan Technical Publications, 752 1999. 754 [DMTF] Common Information Model (CIM) Schema, version 2.4. 755 Distributed Management Task Force, Inc. July, 2000. The 756 components of the CIM v2.4 schema are available via links on the 757 following DMTF web page: 758 http://www.dmtf.org/spec/cim_schema_v24.html. 760 [DSTERMS] New Terminology for Diffserv. Internet Draft, draft-ietf- 761 diffserv-new-terms-02.txt>, D. Grossman. November 1999. 763 [IPSP] IP Security Policy (ipsp) Working Group Charter. February 764 2000. http://www.ietf.org/html.charters/ipsp-charter.html. 766 [PCIM] Policy Core Information Model - Version 1 Specification. 767 Internet Draft, draft-ietf-policy-core-info-model-07.txt, B. 768 Moore, E. Ellison, J. Strassner, and A. Westerinen. July 2000. 770 [PIB] Quality of Service Policy Information Base. Internet Draft, 771 draft-mfine-cops-pib-02.txt, M. Fine, K. McCloughrie, J. 772 Seligson, K. Chan, S. Hahn, and A. Smith. October 1999. 774 [QoSModel] Policy Framework QoS Information Model. Internet Draft, 775 draft-ietf-policy-qos-info-model-01.txt, Y. Snir, Y. Ramberg, J. 776 Strassner, and R. Cohen. April 2000. 778 [R1633] Integrated Services in the Internet Architecture: An 779 Overview. R. Braden, D. Clark, and S. Shenker. June 1994. 781 [R2026] The Internet Standards Process -- Revision 3. S. Bradner. 782 October 1996. 784 [R2138] Remote Authentication Dial In User Service (RADIUS). C. 785 Rigney, A. Rubens, W. Simpson, and S. Willens. April 1997. 787 [R2205] Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 788 Specification. R. Braden, L. Zhang, S. Berson, S. Herzog, and S. 789 Jamin. September 1997. 791 [R2401] Security Architecture for the Internet Protocol. S. Kent, 792 and R. Atkinson. November 1998. 794 [R2409] The Internet Key Exchange (IKE). D. Harkins, and D. Carrel. 795 November 1998. 797 [R2474] Definition of the Differentiated Services Field (DS Field) 798 in the IPv4 and IPv6 Headers. K. Nichols, S. Blake, F. Baker, 799 and D. Black. December 1998. 801 [R2475] An Architecture for Differentiated Service. S. Blake, D. 802 Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. December 803 1998. 805 [R2578] Structure of Management Information Version 2 (SMIv2). K. 806 McGloughrie, D. Perkins, J. Schoenwaelder, J. Case, M. Rose, and 807 S. Waldbusser. April 1999. 809 [R2702] Requirements for Traffic Engineering Over MPLS. D. Awduche, 810 J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus. September 811 1999. 813 [R2748] The COPS (Common Open Policy Service) Protocol. D. Durham, 814 J. Boyle, R. Cohen, S. Herzog, R. Rajan, and A. Sastry. January 815 2000. 817 [R2753] A Framework for Policy-based Admission Control. R. 818 Yavatkar, D. Pendarakis, and R. Guerin. January 2000. 820 [R2828] Internet Security Glossary. R. Shirey. May 2000. 822 [SNMPCONF] Policy Based Management MIB. Internet Draft, draft-ietf- 823 snmpconf-pm-01.txt, S. Waldbusser, J. Saperia and T. Hongal. May 824 2000. 826 [SPPI] Structure of Policy Provisioning Information (SPPI). 827 Internet Draft, draft-ietf-rap-sppi-00.txt, K. McCloughrie, M. 829 Fine, J. Seligson, K. Chan, S. Chan, A. Smith, and F. Reichmeyer. 830 March 2000. 832 [SPSL] Security Policy Specification Language. Internet Draft, 833 draft-ietf-ipsp-spsl-00.txt, M. Condell, C. Lynn, and J. Zao. 834 March 2000. 836 [UML] The Unified Modeling Language User Guide. G. Booch, J. 837 Rumbaugh, and I. Jacobson. Addison-Wesley, 1999. 839 [X.500] Data Communications Networks Directory, Recommendations 840 X.500-X.521, Volume VIII - Fascicle VIII.8. CCITT, IXth Plenary 841 Assembly, Melbourne. November 1988. 843 8. Authors' Addresses 845 Andrea Westerinen 846 Cisco Systems, Bldg 15 847 170 West Tasman Drive 848 San Jose, CA 95134 849 E-mail: andreaw@cisco.com 851 John Schnizlein 852 Cisco Systems 853 9123 Loughran Road 854 Fort Washington, MD 20744 855 E-mail: john.schnizlein@cisco.com 857 John Strassner 858 Cisco Systems, Bldg 15 859 170 West Tasman Drive 860 San Jose, CA 95134 861 E-mail: johns@cisco.com 863 Mark Scherling 864 Bank One International 865 62 Beaufort Drive 866 Kanata, Ontario, Canada 867 K2L 2G3 868 E-mail: marks@m3p.ca 870 Bob Quinn 871 Celox Networks 872 One Cabot Road 873 Hudson, MA 01749 874 E-mail: bquinn@celoxnetworks.com 876 Jay Perry 877 CPlane, Inc. 878 5150 El Camino Real - B-31 879 Los Altos, CA 94022 880 E-mail: jay@cplane.com 881 Shai Herzog 882 IPHighway 883 55 New York Avenue 884 Framingham, MA 01701 885 E-mail: herzog@iphighway.com 887 An-Ni Huynh 888 Lucent Technologies 889 2139 Route 35 890 Holmdel, NJ 07733 891 E-mail: ahuynh@lucent.com 893 Mark Carlson 894 Sun Microsystems 895 2990 Center Green Court South 896 Boulder, CO 80301 897 Email: mark.carlson@sun.com 899 9. Full Copyright Statement 901 Copyright (C) The Internet Society (2000). All Rights Reserved. 903 This document and translations of it may be copied and furnished to 904 others, and derivative works that comment on or otherwise explain it 905 or assist in its implementation may be prepared, copied, published 906 and distributed, in whole or in part, without restriction of any 907 kind, provided that the above copyright notice and this paragraph 908 are included on all such copies and derivative works. However, this 909 document itself may not be modified in any way, such as by removing 910 the copyright notice or references to the Internet Society or other 911 Internet organizations, except as needed for the purpose of 912 developing Internet standards in which case the procedures for 913 copyrights defined in the Internet Standards process must be 914 followed, or as required to translate it into languages other than 915 English. 917 The limited permissions granted above are perpetual and will not be 918 revoked by the Internet Society or its successors or assigns. 920 This document and the information contained herein is provided on an 921 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 922 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 923 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 924 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 925 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.