idnits 2.17.1 draft-ietf-rap-sppi-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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. 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 (10 March 2000) is 8813 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'APPLICATION 7' is mentioned on line 225, but not defined == Missing Reference: 'APPLICATION 8' is mentioned on line 229, but not defined -- Looks like a reference, but probably isn't: '2' on line 445 -- No information found for draft-ietf-rap-cops-pr - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'COPS-PR' -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. McCloghrie 2 Internet Draft M. Fine 3 Cisco Systems 4 J. Seligson 5 K. Chan 6 Nortel Networks 7 S. Chan 8 Intel 9 A. Smith 10 Extreme Networks 11 F. Reichmeyer 12 IPHighway 14 10 March 2000 16 Structure of Policy Provisioning Information (SPPI) 18 draft-ietf-rap-sppi-00.txt 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance with all 23 provisions of Section 10 of RFC2026. Internet-Drafts are working 24 documents of the Internet Engineering Task Force (IETF), its areas, and 25 its working groups. Note that other groups may also distribute working 26 documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference material 31 or to cite them other than as ``work in progress.'' 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Copyright Notice 41 Copyright (C) The Internet Society (2000). All Rights Reserved. 43 Draft SPPI March 2000 45 1. Introduction 47 RFC 2748 [COPS] defines the COPS protocol, and RFC 2749 [COPS-RSVP] 48 describes how the COPS protocol is used to provide for the outsourcing 49 of policy decisions for RSVP. Another usage of the COPS protocol, for 50 the provisioning of policy, is introduced in [COPS-PR]. In this 51 provisioning model, the policy information is viewed as a collection of 52 Policy Rule Classes and Policy Rule Instances residing in a virtual 53 information store, termed the Policy Information Base (PIB). 54 Collections of related Policy Rule Classes are defined in a PIB module. 55 PIB modules are written using an adapted subset of SNMP's Structure of 56 Management Information (SMI) [SMI, TC, CONF]. It is the purpose of this 57 document, the Structure of Policy Provisioning Information (SPPI), to 58 define that adapted subset. 60 2. Use of the SMI 62 The SPPI and PIB modules are based on SNMP's SMI and MIB modules, which 63 use an adapted subset of the ASN.1 data definition language [ASN1]. The 64 decision to base the definition of PIB modules on this format allows for 65 the leveraging of the community's knowledge, experience and tools of the 66 SMI and MIB modules. 68 2.1. Terminology Translation 70 The SMI uses the term "managed objects" to refer to object types, both 71 tabular types with descriptors such as xxxTable and xxxEntry, as well as 72 scalar and columnar object types. The SPPI does not use the term 73 "object" so as to avoid confusion with COPS protocol objects. Instead, 74 the SPPI uses the term Policy Rule Class (PRC) for the table and row 75 definitions (the xxxTable and xxxEntry objects, respectively), and 76 Policy Rule Instance (PRI) for an instantiation of a row definition. 77 For a columnar object of a table definition, the SPPI uses the term 78 "attribute" of a Policy Rule Class. (The SPPI does not support the 79 equivalent of the SMI's scalar objects.) 81 2.2. Overview 83 SNMP's SMI is divided into five parts: module definitions, object 84 definitions, notification definitions [SMI], textual convention 85 definitions [TC] and conformance definitions [CONF]. 87 - The SMI's MODULE-IDENTITY macro is used to convey the semantics of 88 a MIB module. The SPPI uses this macro to convey the semantics of 89 a PIB module. 91 Draft SPPI March 2000 93 - The SMI's OBJECT-TYPE macro is used to convey the syntax and 94 semantics of managed objects. The SPPI uses this macro to convey 95 the syntax and semantics of PRCs and their attributes. 97 - The SMI's notification definitions are not used (at this time) by 98 the SPPI. 100 - The SMI's TEXTUAL CONVENTION macro allows new data types to be 101 defined. The SPPI uses this macro to define new data types having 102 particular syntax and semantics which is common to several 103 attributes of one of more PRCs. 105 - The SMI's conformance definitions define several macros: the 106 OBJECT-GROUP macro, the NOTIFICATION-GROUP macro, the MODULE- 107 COMPLIANCE macro and the AGENT-CAPABILITIES macro. The SPPI uses 108 the OBJECT-GROUP and MODULE-COMPLIANCE macros to specify acceptable 109 lower-bounds of implementation of the attributes of PRCs, and 110 thereby indirectly, acceptable lower-bounds of implementation of 111 the PRCs themselves. The NOTIFICATION-GROUP macro is not used (at 112 this time) by the SPPI. Potential usage by the SPPI of the AGENT- 113 CAPABILITIES macro is for further study. 115 3. Structure of this Specification 117 The SMI is specified in terms of an ASN.1 definition together with 118 descriptive text for each element introduced in that ASN.1 definition. 119 This document specifies the SPPI via a modified ASN.1 definition (which 120 imports those definitions which are unchanged from the SMI), together 121 with descriptive text for only those elements in the SPPI's ASN.1 122 definition which have differences from the SMI's. For elements in the 123 ASN.1 definition which have no descriptive text in this specification, 124 the reader is referred to the SMI's descriptive text for that element. 126 Draft SPPI March 2000 128 4. Definitions 130 COPS-PR-SPPI DEFINITIONS ::= BEGIN 132 IMPORTS ObjectName, SimpleSyntax, ExtUTCTime, Integer32, 133 IpAddress, Unsigned32, TimeTicks 134 FROM SNMPv2-SMI 135 TEXTUAL-CONVENTION FROM SNMPv2-TC; 137 -- definitions for PIB modules 139 MODULE-IDENTITY MACRO ::= 140 BEGIN 141 TYPE NOTATION ::= 142 ClientPart -- new 143 "LAST-UPDATED" value(Update ExtUTCTime) 144 "ORGANIZATION" Text 145 "CONTACT-INFO" Text 146 "DESCRIPTION" Text 147 RevisionPart 149 VALUE NOTATION ::= 150 value(VALUE OBJECT IDENTIFIER) 152 ClientPart ::= -- new 153 "CLIENT-TYPE" "{" ClientTypes "}" 154 ClientTypes ::= -- new 155 ClientTypeIDs 156 | "all" 157 ClientTypeIDs ::= -- new 158 ClientTypeID 159 | ClientTypeIDs "," ClientTypeID 160 ClientTypeID ::= -- new 161 identifier "(" number ")" 163 RevisionPart ::= 164 Revisions 165 | empty 166 Revisions ::= 167 Revision 168 | Revisions Revision 169 Revision ::= 170 "REVISION" value(Update ExtUTCTime) 171 "DESCRIPTION" Text 173 Draft SPPI March 2000 175 Text ::= value(IA5String) 176 END 178 -- syntax of attributes 180 -- the "base types" defined here are: 181 -- 3 built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER 182 -- 6 application-defined types: Integer32, IpAddress, Unsigned32, 183 -- TimeTicks, Integer64 and Unsigned64 185 ObjectSyntax ::= 186 CHOICE { 187 simple 188 SimpleSyntax, 190 -- note that SEQUENCEs for table and row definitions 191 -- are not mentioned here... 193 application-wide 194 ApplicationSyntax 195 } 197 -- application-wide types 199 ApplicationSyntax ::= 200 CHOICE { 201 ipAddress-value 202 IpAddress, 204 timeticks-value 205 TimeTicks, 207 unsigned-integer-value 208 Unsigned32, 210 large-integer-value -- new 211 Integer64 213 large-unsigned-integer-value -- new 214 Unsigned64, 215 } 217 -- indistinguishable from INTEGER, but never needs more than 218 -- 32-bits for a two's complement representation 219 Integer32 ::= 220 Draft SPPI March 2000 222 INTEGER (-2147483648..2147483647) 224 Integer64 ::= 225 [APPLICATION 7] 226 IMPLICIT INTEGER (-9223372036854775807..9223372036854775807) 228 Unsigned64 229 [APPLICATION 8] 230 IMPLICIT INTEGER (0..18446744073709551615) 232 -- definition for Policy Rule Classes and their attributes 233 -- (differences from the SMI are noted in the ASN.1 comments) 235 OBJECT-TYPE MACRO ::= 236 BEGIN 237 TYPE NOTATION ::= 238 "SYNTAX" Syntax 239 UnitsPart 240 "POLICY-ACCESS" Access -- modified 241 "STATUS" Status 242 "DESCRIPTION" Text 243 ErrorsPart -- new 244 ReferPart 245 IndexPart 246 UniquePart -- new 247 DefValPart 249 VALUE NOTATION ::= 250 value(VALUE ObjectName) 252 Syntax ::= -- Must be one of the following: 253 -- a base type (or its refinement), 254 -- a textual convention (or its refinement), or 255 -- a BITS pseudo-type 256 type 257 | "BITS" "{" NamedBits "}" 259 NamedBits ::= NamedBit 260 | NamedBits "," NamedBit 262 NamedBit ::= identifier "(" number ")" -- number is nonnegative 264 UnitsPart ::= 265 "UNITS" Text 267 Draft SPPI March 2000 269 | empty 271 Access ::= -- modified 272 "install" 273 | "notify" 274 | "install-notify" 276 Status ::= 277 "current" 278 | "deprecated" 279 | "obsolete" 281 ErrorsPart ::= -- new 282 "INSTALL-ERRORS" "{" Errors "}" 283 | empty 285 Errors ::= -- new 286 Error 287 | Errors "," Error 288 Error ::= -- new 289 identifier "(" number ")" 291 ReferPart ::= 292 "REFERENCE" Text 293 | empty 295 IndexPart ::= 296 "INDEX" "{" Index "}" -- modified 297 | "AUGMENTS" "{" Entry "}" 298 | empty 299 Index ::= 300 -- the correspondent OBJECT-TYPE invocation 301 value(ObjectName) 302 Entry ::= 303 -- use the INDEX value of the 304 -- correspondent OBJECT-TYPE invocation 305 value(ObjectName) 307 UniquePart ::= -- new 308 "UNIQUENESS" "{" UniqueTypes "}" 309 UniqueTypes ::= 310 UniqueType 311 | UniqueTypes "," UniqueType 312 | empty 313 UniqueType ::= 315 Draft SPPI March 2000 317 -- the correspondent OBJECT-TYPE invocation 318 value(ObjectName) 320 DefValPart ::= "DEFVAL" "{" Defvalue "}" 321 | empty 323 Defvalue ::= -- must be valid for the type specified in 324 -- SYNTAX clause of same OBJECT-TYPE macro 325 value(ObjectSyntax) 326 | "{" BitsValue "}" 328 BitsValue ::= BitNames 329 | empty 331 BitNames ::= BitName 332 | BitNames "," BitName 334 BitName ::= identifier 336 -- a character string as defined in section 3.1.1 337 Text ::= value(IA5String) 338 END 339 Draft SPPI March 2000 341 -- definitions for compliance statements 343 MODULE-COMPLIANCE MACRO ::= 344 BEGIN 345 TYPE NOTATION ::= 346 "STATUS" Status 347 "DESCRIPTION" Text 348 ReferPart 349 ModulePart 351 VALUE NOTATION ::= 352 value(VALUE OBJECT IDENTIFIER) 354 Status ::= 355 "current" 356 | "deprecated" 357 | "obsolete" 359 ReferPart ::= 360 "REFERENCE" Text 361 | empty 363 ModulePart ::= 364 Modules 365 Modules ::= 366 Module 367 | Modules Module 368 Module ::= 369 -- name of module -- 370 "MODULE" ModuleName 371 MandatoryPart 372 CompliancePart 374 ModuleName ::= 375 -- identifier must start with uppercase letter 376 identifier ModuleIdentifier 377 -- must not be empty unless contained 378 -- in MIB Module 379 | empty 380 ModuleIdentifier ::= 381 value(OBJECT IDENTIFIER) 382 | empty 384 MandatoryPart ::= 385 "MANDATORY-GROUPS" "{" Groups "}" 387 Draft SPPI March 2000 389 | empty 391 Groups ::= 392 Group 393 | Groups "," Group 394 Group ::= 395 value(OBJECT IDENTIFIER) 397 CompliancePart ::= 398 Compliances 399 | empty 401 Compliances ::= 402 Compliance 403 | Compliances Compliance 404 Compliance ::= 405 ComplianceGroup 406 | Object 408 ComplianceGroup ::= 409 "GROUP" value(OBJECT IDENTIFIER) 410 "DESCRIPTION" Text 412 Object ::= 413 "OBJECT" value(ObjectName) 414 InstallSyntaxPart -- modified 415 AccessPart 416 "DESCRIPTION" Text 418 -- must be a refinement for object's SYNTAX clause 419 InstallSyntaxPart ::= "SYNTAX" Syntax 420 | empty 422 Syntax ::= -- Must be one of the following: 423 -- a base type (or its refinement), 424 -- a textual convention (or its refinement), or 425 -- a BITS pseudo-type 426 type 427 | "BITS" "{" NamedBits "}" 429 NamedBits ::= NamedBit 430 | NamedBits "," NamedBit 432 NamedBit ::= identifier "(" number ")" -- number is nonnegative 434 Draft SPPI March 2000 436 AccessPart ::= 437 "MIN-ACCESS" Access 438 | empty 439 Access ::= -- modified 440 "not-accessible" 441 | "install" 442 | "notify" 443 | "install-notify" 445 -- a character string as defined in [2] 446 Text ::= value(IA5String) 447 END 449 PolicyInstanceId ::= TEXTUAL-CONVENTION 450 STATUS current 451 DESCRIPTION 452 "The textual convention for use by an attribute which is used 453 as the instance-identifying index of a PRC, i.e., an attribute 454 named in an INDEX clause. The value of an attribute with this 455 syntax is always greater than zero. 457 PRIs of the same PRC need not have contiguous values for their 458 instance-identifying attribute." 459 SYNTAX Unsigned32 (1..4294967295) 461 PolicyReferenceId ::= TEXTUAL-CONVENTION 462 STATUS current 463 DESCRIPTION 464 "A textual convention for use by an attribute which is used as 465 a pointer in order to reference an instance of a particular 466 PRC. An attribute with this syntax must not be used in an 467 INDEX clause, and its description must specify the particular 468 PRC to which the referenced PRI will belong. 470 For an attribute of this type, the referenced PRI must exist. 471 Furthermore, it is an error to try to delete a PRI that is 472 referenced by another instance without first deleting/modifying 473 the referencing instance. 475 The definition of an attribute with this syntax can permit the 476 attribute to have a value of zero to indicate that it is not 477 currently pointing to an PRI." 478 SYNTAX Unsigned32 480 END 481 Draft SPPI March 2000 483 5. PIB Modules 485 The names of all standard PIB modules must be unique (but different 486 versions of the same module should have the same name). Developers of 487 enterprise PIB modules are encouraged to choose names for their modules 488 that will have a low probability of colliding with standard or other 489 enterprise modules. 491 The first line of a PIB module is: 493 PIB-MODULE-NAME PIB-DEFINITIONS ::= BEGIN 495 where PIB-MODULE-NAME is the module name. 497 Like the SMI, additional ASN.1 macros must not be defined in PIB 498 modules. 500 5.1. Importing Definitions 502 Like the SMI, a PIB module which needs to reference an external 503 definition, must use the IMPORTS statement to identify both the 504 descriptor and the module in which the descriptor is defined, where a 505 module is identified by its ASN.1 module name. 507 In particular, a PIB module may import from COPS-PR-SPPI (defined in 508 this document), and from other PIB modules. A PIB module may also 509 import OID assignments from MIB modules, as well as textual convention 510 definitions providing that their underlying syntax is supported by the 511 SPPI. 513 For each ASN.1 macro that a PIB uses, it must import that macro's 514 definition from the appropriate module, as follows: 516 - MODULE-IDENTITY, OBJECT-TYPE and MODULE-COMPLIANCE from COPS-PR-SPPI 518 - OBJECT-IDENTITY from SNMPv2-SMI 520 - TEXTUAL-CONVENTION from SNMPv2-TC 522 - OBJECT-GROUP from SNMPv2-CONF 523 Draft SPPI March 2000 525 5.2. Reserved Keywords 527 In addition to the reserved keywords listed in the SMI, the following 528 must not be used as descriptors or module names: 530 CLIENT-TYPE INSTALL-ERRORS Integer64 POLICY-ACCESS UNIQUENESS 531 Unsigned64 533 6. Naming Hierarchy 535 The SPPI uses the same OBJECT IDENTIFIER naming hierarchy as the SMI. 536 That is, OIDs are typically assigned to PIB modules from the subtree 537 administered by the Internet Assigned Numbers Authority (IANA). 538 However, like the SMI, the SPPI does not prohibit the definition of PRCs 539 in other portions of the OID tree. 541 7. Mapping of the MODULE-IDENTITY macro 543 7.1. Mapping of the CLIENT-TYPE clause 545 The CLIENT-TYPE clause, which must be present, identifies COPS Client 546 Types [COPS-PR] for which this PIB module defines policy information. 547 The Client Types are identified either: 549 - via the keyword "all", indicating the PIB module defines policy 550 information for all COPS-PR Client-Types, or 552 - a list of named-number enumerations, where each number specifies a 553 Client Type used in the COPS protocol. At present time, no more 554 than one named-number enumeration should be specified. 556 When a PIB module applies to multiple Client-Types, that PIB module 557 exists in multiple virtual information stores, one for each Client-Type. 559 Draft SPPI March 2000 561 8. Mapping of the OBJECT-TYPE macro 563 The SPPI requires that all attribute definitions be contained within a 564 PRC, i.e., within a table definition. 566 8.1. Mapping of the SYNTAX clause 568 The SYNTAX clause, which must be present within the definition of an 569 attribute, defines the abstract data structure of that attribute. The 570 data structure must be one of the following: a base type, the BITS 571 construct, or a textual convention. 573 The SYNTAX clause must also be present for the table and row definitions 574 of a PRC, and in this case must be a SEQUENCE OF or SEQUENCE (see 575 section 8.1.7 below). 577 The base types are an extended subset of the SMI's base types: 579 - built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER, 581 - application-defined types: Integer32, IpAddress, Unsigned32, 582 TimeTicks, Integer64 and Unsigned64. 584 A textual convention is a newly-defined type defined as a sub-type of a 585 base type [TC]. The value of an attribute whose syntax is defined using 586 a textual convention is encoded "on-the-wire" according to the textual 587 convention's underlying base type. 589 Note that the set of base types has been chosen so as to provide 590 sufficient variety of on-the-wire encodings for attribute values; base 591 types should contain a minimum of semantics. Semantics should, to the 592 extent possible, be incorporated into a data type through the use of a 593 textual convention. Thus, the IpAddress and TimeTicks data types should 594 really be defined as textual conventions because they contain semantics. 595 However, they are defined here as base types so as to avoid confusion 596 with the SMI which defines them as base types. 598 The differences from the SMI in the semantics of ObjectSyntax are now 599 described. 601 8.1.1. Counter32 603 The Counter32 type is not supported by the SPPI. 605 Draft SPPI March 2000 607 8.1.2. Gauge32 609 The Gauge32 type is not supported by the SPPI. 611 8.1.3. Opaque 613 The Opaque type is not supported by the SPPI. 615 8.1.4. Counter64 617 The Counter64 type is not supported by the SPPI. 619 8.1.5. Integer64 621 The Integer64 type represents integer-valued information between -2^63 622 and 2^63-1 inclusive (-9223372036854775807 to 9223372036854775807 623 decimal). While Integer64 may be sub-typed to be more constrained, if 624 the constraint results in all possible values being contained in the 625 range (-2147483648..2147483647), then the Integer32 type must be used 626 instead of Integer64. 628 8.1.6. Unsigned64 630 The Integer64 type represents integer-valued information between -2^63 631 and 2^63-1 inclusive (0 to 18446744073709551615 decimal). While 632 Unsigned64 may be sub-typed to be more constrained, if the constraint 633 results in all possible values being contained in the range 634 (0..4294967295), then the Unsigned32 type must be used instead of 635 Unsigned64. 637 8.1.7. Policy Rule Classes 639 The policy operations (on PIBs) supported by the SPPI apply exclusively 640 to PRCs. Each PRC is modelled as a tabular structure, i.e., a table. 641 Each instance of a particular PRC has the same set of attributes. The 642 set of attributes which belong to every instance of a particular PRC is 643 modelled as a row in the table. This model is formalized by using the 644 OBJECT-TYPE macro to define both: 646 - the PRC as a whole, called the table definition, and 648 - the characteristics of every instance of a particular PRC, called 649 the row definition. 651 Draft SPPI March 2000 653 In the table definition, the SYNTAX clause has the form: 655 SEQUENCE OF 657 where refers to the SEQUENCE type of its attribute 658 definitions. In the row definition, the SYNTAX clause has the form: 660 662 where is a SEQUENCE type defined as follows: 664 ::= SEQUENCE { , ... , } 666 where there is one for each attribute, and each is of the 667 form: 669 671 where is the descriptor naming an attribute, and 672 has the value of that attribute's SYNTAX clause, except that both sub- 673 typing information and the named values for enumerated integers or the 674 named bits for the BITS construct, are omitted from . 676 8.2. Mapping of the MAX-ACCESS clause 678 The MAX-ACCESS clause is not supported by the SPPI. 680 8.3. Mapping of the POLICY-ACCESS clause 682 The POLICY-ACCESS clause must be present for a PRC's table definition, 683 and must not be present for any other OBJECT-TYPE definition. The 684 POLICY-ACCESS clause defines what kind of access is appropriate for the 685 PRC. 687 - the value "install" is used to indicate a PRC which a PDP can 688 install in the PEP as policy information. 690 - the value "notify" is used to indicate a PRC for which the PEP must 691 notify the PDP of all its instances and attribute values of that 692 PRC. 694 - the value "install-notify" is used to indicate the uncommon type of 695 PRC which has both characteristics: "install" and "notify". 697 Draft SPPI March 2000 699 8.4. Mapping of the INSTALL-ERRORS clause 701 The INSTALL-ERRORS clause, which may optionally be present for a PRC's 702 table definition, and must be absent otherwise, lists one or more 703 potential reasons for rejecting an install or a removal of an instance 704 of the PRC. Each reason consists of a named-number enumeration, where 705 the number represents a PRC-specific error-code to be used in a COPS 706 protocol message. The semantics of each named-number enumeration should 707 be described in the PRC's DESCRIPTION clause. 709 The numbers listed in an INSTALL-ERRORS must be less than 65536. If 710 this clause is not present, an install/remove can still fail, but no 711 PRC-specific error is available to be reported. 713 8.5. Mapping of the INDEX clause 715 The INDEX clause, which must be present for a row definition (unless an 716 AUGMENTS clause is present instead), and must be absent otherwise, 717 defines identification information for instances of the PRC. 719 A PRC's INDEX clause includes exactly one descriptor. This descriptor 720 specifies an attribute (typically, but not necessarily of the same PRC) 721 which is used to identify an instance of that PRC. The syntax of this 722 attribute is required to be PolicyInstanceId (a textual convention with 723 an underlying syntax of Unsigned32), and it has no semantics other than 724 its use in identifying the PRC instance. 726 The OBJECT IDENTIFIER which identifies an instance of a PRC is formed by 727 appending one sub-identifier to the OID which identifies that PRC. The 728 value of the additional sub-identifier is that instance's value of the 729 attribute specified in the INDEX clause. 731 Note that SPPI does not permit use of the IMPLIED keyword. 733 8.6. Mapping of the AUGMENTS clause 735 The AUGMENTS clause, which must not be present except in row 736 definitions, is an alternative to the INDEX clause. Every row 737 definition has either an INDEX clause or an AUGMENTS clause. 739 A row definition which has an INDEX clause is called a base row 740 definition. A row definition which has an AUGMENTS clause is called a 741 row augmentation, where the AUGMENTS clause names the base row 742 definition which is augmented by this row augmentation. (Thus, a row 743 augmentation cannot itself be augmented.) 744 Draft SPPI March 2000 746 A PRC whose row definition is a row augmentation is called an augmenting 747 PRC. Instances of an augmenting PRC are identified according to the 748 INDEX clause of the base row definition named in the AUGMENTS clause. 749 Further, instances of an augmenting PRC exist according to the same 750 semantics as instances of the PRC which it augments. As such, when an 751 instance of a PRC is installed or removed, an instance of every PRC 752 which augments it is also installed or removed (for more details, see 753 [COPS-PR]). 755 8.6.1. Relation between INDEX and AUGMENTS clauses 757 When defining instance identification information for a PRC: 759 - If there is a one-to-one correspondence between instances of this 760 PRC and instances of an existing PRC, then the AUGMENTS clause 761 should be used. 763 - Otherwise, if there is a sparse relationship between instances of 764 this PRC and instances of an existing PRC, then an INDEX clause 765 should be used which names the same attribute as the existing PRC. 767 8.7. Mapping of the UNIQUENESS clause 769 The UNIQUENESS clause, which must be present for any row definition 770 which has an INDEX clause, and must be absent otherwise, lists a set of 771 zero or more of the PRC's attributes, for which no two instances of the 772 PRC can have the same set of values. The attribute contained in the 773 INDEX clause may not be present in the UNIQUENESS clause. By 774 definition, an attribute may not appear more than once in a UNIQUENESS 775 clause. A UNIQUENESS clause containing zero attributes indicates that 776 it's possible for two instances of the PRC to have identical values for 777 all attributes except, of course, for the one named in the INDEX clause. 779 Draft SPPI March 2000 781 9. Mapping of the OBJECT-IDENTITY macro 783 The SMI's ASN.1 macro, OBJECT-IDENTITY [SMI], is used in PIB modules to 784 define information about an OBJECT IDENTIFIER assignment. 786 10. Textual Conventions 788 When designing a PIB module, it is often useful to define new data types 789 similar to those defined in the SPPI. In comparison to a type defined 790 in the SPPI, each of these new types has a different name, a similar 791 syntax, and specific semantics. These newly defined types are termed 792 textual conventions, and are used for the convenience of humans reading 793 the PIB module. 795 Attributes defined using a textual convention are always encoded by 796 means of the rules that define their underlying type. The SMI's ASN.1 797 macro, TEXTUAL-CONVENTION [TC], is used in PIB modules to define the 798 syntax and semantics of a textual convention. Note however, that the 799 underlying syntax of all textual conventions defined in (or imported 800 into) a PIB module must comply with the syntax allowed by the SPPI. 802 11. Mapping of the OBJECT-GROUP macro 804 For conformance purposes, it is useful to define a conformance group as 805 a collection of related PRCs and their attributes. The SPPI uses the 806 SMI's OBJECT-GROUP macro as the means to directly define the collection 807 of attributes which belong to a conformance group. Since each attribute 808 included in the collection belongs to a PRC, the collection of related 809 PRCs which belong to a conformance group is also specified (indirectly) 810 as the set of PRCs to which the included attributes belong. 812 11.1. Mapping of the OBJECTS clause 814 The OBJECTS clause, which must be present, is used to specify each 815 attribute contained in the conformance group. Each of the specified 816 attributes must be defined in the same PIB module as the OBJECT-GROUP 817 macro appears. 819 It is required that every attribute defined in a PIB module be contained 820 in at least one conformance group. This avoids the common error of 821 adding a new attribute to a module and forgetting to add the new 822 attribute to a group. 824 Draft SPPI March 2000 826 12. Mapping of the MODULE-COMPLIANCE macro 828 The MODULE-COMPLIANCE macro is used to convey a minimum set of 829 requirements with respect to implementation of one or more PIB modules. 831 A requirement on all "standard" PIB modules is that a corresponding 832 MODULE-COMPLIANCE specification is also defined, either in the same 833 module or in a companion module. 835 12.1. Mapping of the MODULE clause 837 The MODULE clause, which must be present, is repeatedly used to name 838 each PIB module for which compliance requirements are being specified. 839 Each PIB module is named by its module name, and optionally, by its 840 associated OBJECT IDENTIFIER as well. The module name can be omitted 841 when the MODULE-COMPLIANCE invocation occurs inside a PIB module, to 842 refer to the encompassing PIB module. 844 12.1.1. Mapping of the MANDATORY-GROUPS clause 846 The MANDATORY-GROUPS clause, which need not be present, names the one or 847 more conformance groups within the correspondent PIB module which are 848 unconditionally mandatory for implementation. If an agent claims 849 compliance to the PIB module, then it must implement each and every 850 attribute (and therefore the PRCs to which they belong) within each 851 conformance group listed. 853 12.1.2. Mapping of the GROUP clause 855 The GROUP clause, which need not be present, is repeatedly used to name 856 each conformance group which is conditionally mandatory for compliance 857 to the PIB module. The GROUP clause can also be used to name 858 unconditionally optional groups. A group named in a GROUP clause must 859 be absent from the correspondent MANDATORY-GROUPS clause. 861 Conditionally mandatory groups include those which are mandatory only if 862 a particular protocol is implemented, or only if another group is 863 implemented. A GROUP clause's DESCRIPTION specifies the conditions 864 under which the group is conditionally mandatory. 866 A group which is named in neither a MANDATORY-GROUPS clause nor a GROUP 867 clause, is unconditionally optional for compliance to the PIB module. 869 Draft SPPI March 2000 871 12.1.3. Mapping of the OBJECT clause 873 The OBJECT clause, which need not be present, is repeatedly used to 874 specify each attribute for which compliance has a refined requirement 875 with respect to the PIB module definition. The attribute must be 876 present in one of the conformance groups named in the correspondent 877 MANDATORY-GROUPS clause or GROUP clauses. 879 By definition, each attribute specified in an OBJECT clause follows a 880 MODULE clause which names the PIB module in which that attribute is 881 defined. Therefore, the use of an IMPORTS statement, to specify from 882 where such attributes are imported, is redundant and is not required in 883 a PIB module. 885 12.1.3.1. Mapping of the SYNTAX clause 887 The SYNTAX clause, which need not be present, is used to provide a 888 refined SYNTAX for the attribute named in the correspondent OBJECT 889 clause. The refined syntax is the minimum level of support needed for 890 this attribute in order to be compliant. 892 12.1.3.2. Mapping of the WRITE-SYNTAX clause 894 The WRITE-SYNTAX clause is not supported by the SPPI. 896 12.1.3.3. Mapping of the MIN-ACCESS clause 898 The MIN-ACCESS clause, which need not be present, is used to define the 899 minimal level of access for the attribute named in the correspondent 900 OBJECT clause. If this clause is absent, the minimal level of access is 901 the same as the maximal level specified in the POLICY-ACCESS clause of 902 the correspondent invocation of the OBJECT-TYPE macro. If present, this 903 clause must specify a subset of the access specified in the 904 correspondent POLICY-ACCESS clause, where: "install" is a subset of 905 "install-notify", "notify" is a subset of "install-notify", and "not- 906 accessible" is a subset of all other values. 908 An implementation is compliant if the level of access it provides is the 909 same or a superset of the minimal level in the MODULE-COMPLIANCE macro 910 and the same or a subset of the maximal level in the POLICY-ACCESS 911 clause. 913 Draft SPPI March 2000 915 13. Extending a PIB Module 917 The SMI's rules for extending an information module are augmented with 918 the following rules: 920 13.1. OBJECT-TYPE Definitions 922 An invocation of the OBJECT-TYPE macro may also be revised in any of the 923 following ways: 925 - An INSTALL-ERRORS clause may be added or an existing INSTALL-ERRORS 926 clause have additional errors defined. 928 - Additional named-number enumerations may be added to a CLIENT-TYPE 929 clause. 931 Draft SPPI March 2000 933 14. Appendix A: Mapping a PIB to a MIB 935 Since the SPPI is modelled on the SMI, a PIB can be easily and 936 algorithmically mapped into a MIB for the purpose of monitoring by SNMP. 937 This mapping is achieved by means of the following rules: 939 - Replace the keyword POLICY-DEFINITIONS with the keyword 940 DEFINITIONS. 942 - Delete all POLICY-ACCESS clauses. 944 - Delete all UNIQUENESS clauses. 946 - Delete all INSTALL-ERRORS clauses. 948 - Delete the CLIENT-TYPE clause. 950 - Add a MAX-ACCESS clause for each OBJECT-TYPE. For each table 951 definition and row definition, the MAX-ACCESS is "not-accessible". 952 For each attribute that is an index, the MAX-ACCESS is "not- 953 accessible". For the remaining attributes, the MAX-ACCESS is 954 "read-only" if the POLICY-ACCESS for the class is "install" or 955 "install-notify", and it is "read-create" if the POLICY-ACCESS for 956 the class is "notify". 958 - Add a columnar attribute of type RowStatus with name status and 959 with the next available OID if the POLICY-ACCESS is "notify". 961 - Modify any SYNTAX clause which has a base data type which is not 962 allowed in the SMI to be an OCTET STRING of the relevant size. 963 Specifically, both Integer64 and Unsigned64 are mapped to OCTET 964 STRING (SIZE(8)). 966 Draft SPPI March 2000 968 15. Security Considerations 970 This document defines a language with which to define policy 971 information. The language itself has no security impact on the 972 Internet. 974 16. Authors' Addresses 976 Keith McCloghrie 977 Cisco Systems, Inc. 978 170 West Tasman Drive 979 San Jose, CA 95134-1706 USA 980 Phone: +1 408 526 5260 981 Email: kzm@cisco.com 983 Michael Fine 984 Cisco Systems, Inc. 985 170 West Tasman Drive 986 San Jose, CA 95134-1706 USA 987 Phone: +1 408 527 8218 988 Email: mfine@cisco.com 990 John Seligson 991 Nortel Networks, Inc. 992 4401 Great America Parkway 993 Santa Clara, CA 95054 USA 994 Phone: +1 408 495 2992 995 Email: jseligso@nortelnetworks.com 997 Kwok Ho Chan 998 Nortel Networks, Inc. 999 600 Technology Park Drive 1000 Billerica, MA 01821 USA 1001 Phone: +1 978 288 8175 1002 Email: khchan@nortelnetworks.com 1004 Scott Hahn 1005 Intel 1006 2111 NE 25th Avenue 1007 Hillsboro, OR 97124 USA 1008 Phone: +1 503 264 8231 1009 Email: scott.hahn@intel.com 1011 Draft SPPI March 2000 1013 Andrew Smith 1014 Extreme Networks 1015 10460 Bandley Drive 1016 Cupertino CA 95014 USA 1017 Phone: +1 408 342 0999 1018 Email: andrew@extremenetworks.com 1020 Francis Reichmeyer 1021 IPHighway Inc. 1022 Parker Plaza, 16th Floor 1023 400 Kelby St, Fort-Lee, NJ 07024 USA 1024 Phone: (201) 585-0800 1025 Email: FranR@iphighway.com 1027 17. References 1029 [COPS] 1030 Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and A. 1031 Sastry, "The COPS (Common Open Policy Service) Protocol" RFC 2748, 1032 January 2000. 1034 [COPS-RSVP] 1035 Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and A. 1036 Sastry, " COPS usage for RSVP", RFC 2749, January 2000. 1038 [COPS-PR] 1039 Reichmeyer, F., Herzog, S., Chan, K., Durham, D., Yavatkar, R. 1040 Gai, S., McCloghrie, K. and A. Smith, "COPS Usage for Policy 1041 Provisioning" Internet Draft, draft-ietf-rap-cops-pr-02.txt, March 1042 2000. 1044 [SMI] 1045 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1046 and S. Waldbusser. "Structure of Management Information Version 2 1047 (SMIv2)", RFC 2578, April 1999. 1049 [TC] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1050 and S. Waldbusser. "Textual Conventions for SMIv2", RFC 2579, 1051 April 1999. 1053 [CONF] 1054 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1055 and S. Waldbusser. "Conformance Statements for SMIv2", RFC 2580, 1056 April 1999. 1058 Draft SPPI March 2000 1060 [ASN1] 1061 Information processing systems -- Open Systems Interconnection -- 1062 Specification of Abstract Syntax Notation One (ASN.1), 1063 International Organization for Standardization. International 1064 Standard 8824, December 1987. 1066 Draft SPPI March 2000 1068 18. Full Copyright Statement 1070 Copyright (C) The Internet Society (1999). All Rights Reserved. 1072 This document and translations of it may be copied and furnished to 1073 others, and derivative works that comment on or otherwise explain it or 1074 assist in its implementation may be prepared, copied, published and 1075 distributed, in whole or in part, without restriction of any kind, 1076 provided that the above copyright notice and this paragraph are included 1077 on all such copies and derivative works. However, this document itself 1078 may not be modified in any way, such as by removing the copyright notice 1079 or references to the Internet Society or other Internet organizations, 1080 except as needed for the purpose of developing Internet standards in 1081 which case the procedures for copyrights defined in the Internet 1082 Standards process must be followed, or as required to translate it into 1083 languages other than English. 1085 The limited permissions granted above are perpetual and will not be 1086 revoked by the Internet Society or its successors or assigns. 1088 This document and the information contained herein is provided on an "AS 1089 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1090 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1091 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1092 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1093 FITNESS FOR A PARTICULAR PURPOSE." 1094 Draft SPPI March 2000 1096 Table of Contents 1098 1 Introduction .................................................... 2 1099 2 Use of the SMI .................................................. 2 1100 2.1 Terminology Translation ....................................... 2 1101 2.2 Overview ...................................................... 2 1102 3 Structure of this Specification ................................. 3 1103 4 Definitions ..................................................... 4 1104 5 PIB Modules ..................................................... 12 1105 5.1 Importing Definitions ......................................... 12 1106 5.2 Reserved Keywords ............................................. 13 1107 6 Naming Hierarchy ................................................ 13 1108 7 Mapping of the MODULE-IDENTITY macro ............................ 13 1109 7.1 Mapping of the CLIENT-TYPE clause ............................. 13 1110 8 Mapping of the OBJECT-TYPE macro ................................ 14 1111 8.1 Mapping of the SYNTAX clause .................................. 14 1112 8.1.1 Counter32 ................................................... 14 1113 8.1.2 Gauge32 ..................................................... 15 1114 8.1.3 Opaque ...................................................... 15 1115 8.1.4 Counter64 ................................................... 15 1116 8.1.5 Integer64 ................................................... 15 1117 8.1.6 Unsigned64 .................................................. 15 1118 8.1.7 Policy Rule Classes ......................................... 15 1119 8.2 Mapping of the MAX-ACCESS clause .............................. 16 1120 8.3 Mapping of the POLICY-ACCESS clause ........................... 16 1121 8.4 Mapping of the INSTALL-ERRORS clause .......................... 17 1122 8.5 Mapping of the INDEX clause ................................... 17 1123 8.6 Mapping of the AUGMENTS clause ................................ 17 1124 8.6.1 Relation between INDEX and AUGMENTS clauses ................. 18 1125 8.7 Mapping of the UNIQUENESS clause .............................. 18 1126 9 Mapping of the OBJECT-IDENTITY macro ............................ 19 1127 10 Textual Conventions ............................................ 19 1128 11 Mapping of the OBJECT-GROUP macro .............................. 19 1129 11.1 Mapping of the OBJECTS clause ................................ 19 1130 12 Mapping of the MODULE-COMPLIANCE macro ......................... 20 1131 12.1 Mapping of the MODULE clause ................................. 20 1132 12.1.1 Mapping of the MANDATORY-GROUPS clause ..................... 20 1133 12.1.2 Mapping of the GROUP clause ................................ 20 1134 12.1.3 Mapping of the OBJECT clause ............................... 21 1135 12.1.3.1 Mapping of the SYNTAX clause ............................. 21 1136 12.1.3.2 Mapping of the WRITE-SYNTAX clause ....................... 21 1137 12.1.3.3 Mapping of the MIN-ACCESS clause ......................... 21 1138 13 Extending a PIB Module ......................................... 22 1139 13.1 OBJECT-TYPE Definitions ...................................... 22 1140 Draft SPPI March 2000 1142 14 Appendix A: Mapping a PIB to a MIB ............................. 23 1143 15 Security Considerations ........................................ 24 1144 16 Authors' Addresses ............................................. 24 1145 17 References ..................................................... 25 1146 18 Full Copyright Statement ....................................... 27