Network Working Group K. McCloghrie Internet Draft M. Fine Cisco Systems J. Seligson K. Chan Nortel Networks S. Chan Intel A. Smith Extreme Networks F. Reichmeyer IPHighway 10 March 2000 Structure of Policy Provisioning Information (SPPI) draft-ietf-rap-sppi-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Expires September 2000 [Page 1] Draft SPPI March 2000 1. Introduction RFC 2748 [COPS] defines the COPS protocol, and RFC 2749 [COPS-RSVP] describes how the COPS protocol is used to provide for the outsourcing of policy decisions for RSVP. Another usage of the COPS protocol, for the provisioning of policy, is introduced in [COPS-PR]. In this provisioning model, the policy information is viewed as a collection of Policy Rule Classes and Policy Rule Instances residing in a virtual information store, termed the Policy Information Base (PIB). Collections of related Policy Rule Classes are defined in a PIB module. PIB modules are written using an adapted subset of SNMP's Structure of Management Information (SMI) [SMI, TC, CONF]. It is the purpose of this document, the Structure of Policy Provisioning Information (SPPI), to define that adapted subset. 2. Use of the SMI The SPPI and PIB modules are based on SNMP's SMI and MIB modules, which use an adapted subset of the ASN.1 data definition language [ASN1]. The decision to base the definition of PIB modules on this format allows for the leveraging of the community's knowledge, experience and tools of the SMI and MIB modules. 2.1. Terminology Translation The SMI uses the term "managed objects" to refer to object types, both tabular types with descriptors such as xxxTable and xxxEntry, as well as scalar and columnar object types. The SPPI does not use the term "object" so as to avoid confusion with COPS protocol objects. Instead, the SPPI uses the term Policy Rule Class (PRC) for the table and row definitions (the xxxTable and xxxEntry objects, respectively), and Policy Rule Instance (PRI) for an instantiation of a row definition. For a columnar object of a table definition, the SPPI uses the term "attribute" of a Policy Rule Class. (The SPPI does not support the equivalent of the SMI's scalar objects.) 2.2. Overview SNMP's SMI is divided into five parts: module definitions, object definitions, notification definitions [SMI], textual convention definitions [TC] and conformance definitions [CONF]. - The SMI's MODULE-IDENTITY macro is used to convey the semantics of a MIB module. The SPPI uses this macro to convey the semantics of a PIB module. Expires September 2000 [Page 2] Draft SPPI March 2000 - The SMI's OBJECT-TYPE macro is used to convey the syntax and semantics of managed objects. The SPPI uses this macro to convey the syntax and semantics of PRCs and their attributes. - The SMI's notification definitions are not used (at this time) by the SPPI. - The SMI's TEXTUAL CONVENTION macro allows new data types to be defined. The SPPI uses this macro to define new data types having particular syntax and semantics which is common to several attributes of one of more PRCs. - The SMI's conformance definitions define several macros: the OBJECT-GROUP macro, the NOTIFICATION-GROUP macro, the MODULE- COMPLIANCE macro and the AGENT-CAPABILITIES macro. The SPPI uses the OBJECT-GROUP and MODULE-COMPLIANCE macros to specify acceptable lower-bounds of implementation of the attributes of PRCs, and thereby indirectly, acceptable lower-bounds of implementation of the PRCs themselves. The NOTIFICATION-GROUP macro is not used (at this time) by the SPPI. Potential usage by the SPPI of the AGENT- CAPABILITIES macro is for further study. 3. Structure of this Specification The SMI is specified in terms of an ASN.1 definition together with descriptive text for each element introduced in that ASN.1 definition. This document specifies the SPPI via a modified ASN.1 definition (which imports those definitions which are unchanged from the SMI), together with descriptive text for only those elements in the SPPI's ASN.1 definition which have differences from the SMI's. For elements in the ASN.1 definition which have no descriptive text in this specification, the reader is referred to the SMI's descriptive text for that element. Expires September 2000 [Page 3] Draft SPPI March 2000 4. Definitions COPS-PR-SPPI DEFINITIONS ::= BEGIN IMPORTS ObjectName, SimpleSyntax, ExtUTCTime, Integer32, IpAddress, Unsigned32, TimeTicks FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; -- definitions for PIB modules MODULE-IDENTITY MACRO ::= BEGIN TYPE NOTATION ::= ClientPart -- new "LAST-UPDATED" value(Update ExtUTCTime) "ORGANIZATION" Text "CONTACT-INFO" Text "DESCRIPTION" Text RevisionPart VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER) ClientPart ::= -- new "CLIENT-TYPE" "{" ClientTypes "}" ClientTypes ::= -- new ClientTypeIDs | "all" ClientTypeIDs ::= -- new ClientTypeID | ClientTypeIDs "," ClientTypeID ClientTypeID ::= -- new identifier "(" number ")" RevisionPart ::= Revisions | empty Revisions ::= Revision | Revisions Revision Revision ::= "REVISION" value(Update ExtUTCTime) "DESCRIPTION" Text Expires September 2000 [Page 4] Draft SPPI March 2000 Text ::= value(IA5String) END -- syntax of attributes -- the "base types" defined here are: -- 3 built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER -- 6 application-defined types: Integer32, IpAddress, Unsigned32, -- TimeTicks, Integer64 and Unsigned64 ObjectSyntax ::= CHOICE { simple SimpleSyntax, -- note that SEQUENCEs for table and row definitions -- are not mentioned here... application-wide ApplicationSyntax } -- application-wide types ApplicationSyntax ::= CHOICE { ipAddress-value IpAddress, timeticks-value TimeTicks, unsigned-integer-value Unsigned32, large-integer-value -- new Integer64 large-unsigned-integer-value -- new Unsigned64, } -- indistinguishable from INTEGER, but never needs more than -- 32-bits for a two's complement representation Integer32 ::= Expires September 2000 [Page 5] Draft SPPI March 2000 INTEGER (-2147483648..2147483647) Integer64 ::= [APPLICATION 7] IMPLICIT INTEGER (-9223372036854775807..9223372036854775807) Unsigned64 [APPLICATION 8] IMPLICIT INTEGER (0..18446744073709551615) -- definition for Policy Rule Classes and their attributes -- (differences from the SMI are noted in the ASN.1 comments) OBJECT-TYPE MACRO ::= BEGIN TYPE NOTATION ::= "SYNTAX" Syntax UnitsPart "POLICY-ACCESS" Access -- modified "STATUS" Status "DESCRIPTION" Text ErrorsPart -- new ReferPart IndexPart UniquePart -- new DefValPart VALUE NOTATION ::= value(VALUE ObjectName) Syntax ::= -- Must be one of the following: -- a base type (or its refinement), -- a textual convention (or its refinement), or -- a BITS pseudo-type type | "BITS" "{" NamedBits "}" NamedBits ::= NamedBit | NamedBits "," NamedBit NamedBit ::= identifier "(" number ")" -- number is nonnegative UnitsPart ::= "UNITS" Text Expires September 2000 [Page 6] Draft SPPI March 2000 | empty Access ::= -- modified "install" | "notify" | "install-notify" Status ::= "current" | "deprecated" | "obsolete" ErrorsPart ::= -- new "INSTALL-ERRORS" "{" Errors "}" | empty Errors ::= -- new Error | Errors "," Error Error ::= -- new identifier "(" number ")" ReferPart ::= "REFERENCE" Text | empty IndexPart ::= "INDEX" "{" Index "}" -- modified | "AUGMENTS" "{" Entry "}" | empty Index ::= -- the correspondent OBJECT-TYPE invocation value(ObjectName) Entry ::= -- use the INDEX value of the -- correspondent OBJECT-TYPE invocation value(ObjectName) UniquePart ::= -- new "UNIQUENESS" "{" UniqueTypes "}" UniqueTypes ::= UniqueType | UniqueTypes "," UniqueType | empty UniqueType ::= Expires September 2000 [Page 7] Draft SPPI March 2000 -- the correspondent OBJECT-TYPE invocation value(ObjectName) DefValPart ::= "DEFVAL" "{" Defvalue "}" | empty Defvalue ::= -- must be valid for the type specified in -- SYNTAX clause of same OBJECT-TYPE macro value(ObjectSyntax) | "{" BitsValue "}" BitsValue ::= BitNames | empty BitNames ::= BitName | BitNames "," BitName BitName ::= identifier -- a character string as defined in section 3.1.1 Text ::= value(IA5String) END Expires September 2000 [Page 8] Draft SPPI March 2000 -- definitions for compliance statements MODULE-COMPLIANCE MACRO ::= BEGIN TYPE NOTATION ::= "STATUS" Status "DESCRIPTION" Text ReferPart ModulePart VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER) Status ::= "current" | "deprecated" | "obsolete" ReferPart ::= "REFERENCE" Text | empty ModulePart ::= Modules Modules ::= Module | Modules Module Module ::= -- name of module -- "MODULE" ModuleName MandatoryPart CompliancePart ModuleName ::= -- identifier must start with uppercase letter identifier ModuleIdentifier -- must not be empty unless contained -- in MIB Module | empty ModuleIdentifier ::= value(OBJECT IDENTIFIER) | empty MandatoryPart ::= "MANDATORY-GROUPS" "{" Groups "}" Expires September 2000 [Page 9] Draft SPPI March 2000 | empty Groups ::= Group | Groups "," Group Group ::= value(OBJECT IDENTIFIER) CompliancePart ::= Compliances | empty Compliances ::= Compliance | Compliances Compliance Compliance ::= ComplianceGroup | Object ComplianceGroup ::= "GROUP" value(OBJECT IDENTIFIER) "DESCRIPTION" Text Object ::= "OBJECT" value(ObjectName) InstallSyntaxPart -- modified AccessPart "DESCRIPTION" Text -- must be a refinement for object's SYNTAX clause InstallSyntaxPart ::= "SYNTAX" Syntax | empty Syntax ::= -- Must be one of the following: -- a base type (or its refinement), -- a textual convention (or its refinement), or -- a BITS pseudo-type type | "BITS" "{" NamedBits "}" NamedBits ::= NamedBit | NamedBits "," NamedBit NamedBit ::= identifier "(" number ")" -- number is nonnegative Expires September 2000 [Page 10] Draft SPPI March 2000 AccessPart ::= "MIN-ACCESS" Access | empty Access ::= -- modified "not-accessible" | "install" | "notify" | "install-notify" -- a character string as defined in [2] Text ::= value(IA5String) END PolicyInstanceId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The textual convention for use by an attribute which is used as the instance-identifying index of a PRC, i.e., an attribute named in an INDEX clause. The value of an attribute with this syntax is always greater than zero. PRIs of the same PRC need not have contiguous values for their instance-identifying attribute." SYNTAX Unsigned32 (1..4294967295) PolicyReferenceId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A textual convention for use by an attribute which is used as a pointer in order to reference an instance of a particular PRC. An attribute with this syntax must not be used in an INDEX clause, and its description must specify the particular PRC to which the referenced PRI will belong. For an attribute of this type, the referenced PRI must exist. Furthermore, it is an error to try to delete a PRI that is referenced by another instance without first deleting/modifying the referencing instance. The definition of an attribute with this syntax can permit the attribute to have a value of zero to indicate that it is not currently pointing to an PRI." SYNTAX Unsigned32 END Expires September 2000 [Page 11] Draft SPPI March 2000 5. PIB Modules The names of all standard PIB modules must be unique (but different versions of the same module should have the same name). Developers of enterprise PIB modules are encouraged to choose names for their modules that will have a low probability of colliding with standard or other enterprise modules. The first line of a PIB module is: PIB-MODULE-NAME PIB-DEFINITIONS ::= BEGIN where PIB-MODULE-NAME is the module name. Like the SMI, additional ASN.1 macros must not be defined in PIB modules. 5.1. Importing Definitions Like the SMI, a PIB module which needs to reference an external definition, must use the IMPORTS statement to identify both the descriptor and the module in which the descriptor is defined, where a module is identified by its ASN.1 module name. In particular, a PIB module may import from COPS-PR-SPPI (defined in this document), and from other PIB modules. A PIB module may also import OID assignments from MIB modules, as well as textual convention definitions providing that their underlying syntax is supported by the SPPI. For each ASN.1 macro that a PIB uses, it must import that macro's definition from the appropriate module, as follows: - MODULE-IDENTITY, OBJECT-TYPE and MODULE-COMPLIANCE from COPS-PR-SPPI - OBJECT-IDENTITY from SNMPv2-SMI - TEXTUAL-CONVENTION from SNMPv2-TC - OBJECT-GROUP from SNMPv2-CONF Expires September 2000 [Page 12] Draft SPPI March 2000 5.2. Reserved Keywords In addition to the reserved keywords listed in the SMI, the following must not be used as descriptors or module names: CLIENT-TYPE INSTALL-ERRORS Integer64 POLICY-ACCESS UNIQUENESS Unsigned64 6. Naming Hierarchy The SPPI uses the same OBJECT IDENTIFIER naming hierarchy as the SMI. That is, OIDs are typically assigned to PIB modules from the subtree administered by the Internet Assigned Numbers Authority (IANA). However, like the SMI, the SPPI does not prohibit the definition of PRCs in other portions of the OID tree. 7. Mapping of the MODULE-IDENTITY macro 7.1. Mapping of the CLIENT-TYPE clause The CLIENT-TYPE clause, which must be present, identifies COPS Client Types [COPS-PR] for which this PIB module defines policy information. The Client Types are identified either: - via the keyword "all", indicating the PIB module defines policy information for all COPS-PR Client-Types, or - a list of named-number enumerations, where each number specifies a Client Type used in the COPS protocol. At present time, no more than one named-number enumeration should be specified. When a PIB module applies to multiple Client-Types, that PIB module exists in multiple virtual information stores, one for each Client-Type. Expires September 2000 [Page 13] Draft SPPI March 2000 8. Mapping of the OBJECT-TYPE macro The SPPI requires that all attribute definitions be contained within a PRC, i.e., within a table definition. 8.1. Mapping of the SYNTAX clause The SYNTAX clause, which must be present within the definition of an attribute, defines the abstract data structure of that attribute. The data structure must be one of the following: a base type, the BITS construct, or a textual convention. The SYNTAX clause must also be present for the table and row definitions of a PRC, and in this case must be a SEQUENCE OF or SEQUENCE (see section 8.1.7 below). The base types are an extended subset of the SMI's base types: - built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER, - application-defined types: Integer32, IpAddress, Unsigned32, TimeTicks, Integer64 and Unsigned64. A textual convention is a newly-defined type defined as a sub-type of a base type [TC]. The value of an attribute whose syntax is defined using a textual convention is encoded "on-the-wire" according to the textual convention's underlying base type. Note that the set of base types has been chosen so as to provide sufficient variety of on-the-wire encodings for attribute values; base types should contain a minimum of semantics. Semantics should, to the extent possible, be incorporated into a data type through the use of a textual convention. Thus, the IpAddress and TimeTicks data types should really be defined as textual conventions because they contain semantics. However, they are defined here as base types so as to avoid confusion with the SMI which defines them as base types. The differences from the SMI in the semantics of ObjectSyntax are now described. 8.1.1. Counter32 The Counter32 type is not supported by the SPPI. Expires September 2000 [Page 14] Draft SPPI March 2000 8.1.2. Gauge32 The Gauge32 type is not supported by the SPPI. 8.1.3. Opaque The Opaque type is not supported by the SPPI. 8.1.4. Counter64 The Counter64 type is not supported by the SPPI. 8.1.5. Integer64 The Integer64 type represents integer-valued information between -2^63 and 2^63-1 inclusive (-9223372036854775807 to 9223372036854775807 decimal). While Integer64 may be sub-typed to be more constrained, if the constraint results in all possible values being contained in the range (-2147483648..2147483647), then the Integer32 type must be used instead of Integer64. 8.1.6. Unsigned64 The Integer64 type represents integer-valued information between -2^63 and 2^63-1 inclusive (0 to 18446744073709551615 decimal). While Unsigned64 may be sub-typed to be more constrained, if the constraint results in all possible values being contained in the range (0..4294967295), then the Unsigned32 type must be used instead of Unsigned64. 8.1.7. Policy Rule Classes The policy operations (on PIBs) supported by the SPPI apply exclusively to PRCs. Each PRC is modelled as a tabular structure, i.e., a table. Each instance of a particular PRC has the same set of attributes. The set of attributes which belong to every instance of a particular PRC is modelled as a row in the table. This model is formalized by using the OBJECT-TYPE macro to define both: - the PRC as a whole, called the table definition, and - the characteristics of every instance of a particular PRC, called the row definition. Expires September 2000 [Page 15] Draft SPPI March 2000 In the table definition, the SYNTAX clause has the form: SEQUENCE OF where refers to the SEQUENCE type of its attribute definitions. In the row definition, the SYNTAX clause has the form: where is a SEQUENCE type defined as follows: ::= SEQUENCE { , ... , } where there is one for each attribute, and each is of the form: where is the descriptor naming an attribute, and has the value of that attribute's SYNTAX clause, except that both sub- typing information and the named values for enumerated integers or the named bits for the BITS construct, are omitted from . 8.2. Mapping of the MAX-ACCESS clause The MAX-ACCESS clause is not supported by the SPPI. 8.3. Mapping of the POLICY-ACCESS clause The POLICY-ACCESS clause must be present for a PRC's table definition, and must not be present for any other OBJECT-TYPE definition. The POLICY-ACCESS clause defines what kind of access is appropriate for the PRC. - the value "install" is used to indicate a PRC which a PDP can install in the PEP as policy information. - the value "notify" is used to indicate a PRC for which the PEP must notify the PDP of all its instances and attribute values of that PRC. - the value "install-notify" is used to indicate the uncommon type of PRC which has both characteristics: "install" and "notify". Expires September 2000 [Page 16] Draft SPPI March 2000 8.4. Mapping of the INSTALL-ERRORS clause The INSTALL-ERRORS clause, which may optionally be present for a PRC's table definition, and must be absent otherwise, lists one or more potential reasons for rejecting an install or a removal of an instance of the PRC. Each reason consists of a named-number enumeration, where the number represents a PRC-specific error-code to be used in a COPS protocol message. The semantics of each named-number enumeration should be described in the PRC's DESCRIPTION clause. The numbers listed in an INSTALL-ERRORS must be less than 65536. If this clause is not present, an install/remove can still fail, but no PRC-specific error is available to be reported. 8.5. Mapping of the INDEX clause The INDEX clause, which must be present for a row definition (unless an AUGMENTS clause is present instead), and must be absent otherwise, defines identification information for instances of the PRC. A PRC's INDEX clause includes exactly one descriptor. This descriptor specifies an attribute (typically, but not necessarily of the same PRC) which is used to identify an instance of that PRC. The syntax of this attribute is required to be PolicyInstanceId (a textual convention with an underlying syntax of Unsigned32), and it has no semantics other than its use in identifying the PRC instance. The OBJECT IDENTIFIER which identifies an instance of a PRC is formed by appending one sub-identifier to the OID which identifies that PRC. The value of the additional sub-identifier is that instance's value of the attribute specified in the INDEX clause. Note that SPPI does not permit use of the IMPLIED keyword. 8.6. Mapping of the AUGMENTS clause The AUGMENTS clause, which must not be present except in row definitions, is an alternative to the INDEX clause. Every row definition has either an INDEX clause or an AUGMENTS clause. A row definition which has an INDEX clause is called a base row definition. A row definition which has an AUGMENTS clause is called a row augmentation, where the AUGMENTS clause names the base row definition which is augmented by this row augmentation. (Thus, a row augmentation cannot itself be augmented.) Expires September 2000 [Page 17] Draft SPPI March 2000 A PRC whose row definition is a row augmentation is called an augmenting PRC. Instances of an augmenting PRC are identified according to the INDEX clause of the base row definition named in the AUGMENTS clause. Further, instances of an augmenting PRC exist according to the same semantics as instances of the PRC which it augments. As such, when an instance of a PRC is installed or removed, an instance of every PRC which augments it is also installed or removed (for more details, see [COPS-PR]). 8.6.1. Relation between INDEX and AUGMENTS clauses When defining instance identification information for a PRC: - If there is a one-to-one correspondence between instances of this PRC and instances of an existing PRC, then the AUGMENTS clause should be used. - Otherwise, if there is a sparse relationship between instances of this PRC and instances of an existing PRC, then an INDEX clause should be used which names the same attribute as the existing PRC. 8.7. Mapping of the UNIQUENESS clause The UNIQUENESS clause, which must be present for any row definition which has an INDEX clause, and must be absent otherwise, lists a set of zero or more of the PRC's attributes, for which no two instances of the PRC can have the same set of values. The attribute contained in the INDEX clause may not be present in the UNIQUENESS clause. By definition, an attribute may not appear more than once in a UNIQUENESS clause. A UNIQUENESS clause containing zero attributes indicates that it's possible for two instances of the PRC to have identical values for all attributes except, of course, for the one named in the INDEX clause. Expires September 2000 [Page 18] Draft SPPI March 2000 9. Mapping of the OBJECT-IDENTITY macro The SMI's ASN.1 macro, OBJECT-IDENTITY [SMI], is used in PIB modules to define information about an OBJECT IDENTIFIER assignment. 10. Textual Conventions When designing a PIB module, it is often useful to define new data types similar to those defined in the SPPI. In comparison to a type defined in the SPPI, each of these new types has a different name, a similar syntax, and specific semantics. These newly defined types are termed textual conventions, and are used for the convenience of humans reading the PIB module. Attributes defined using a textual convention are always encoded by means of the rules that define their underlying type. The SMI's ASN.1 macro, TEXTUAL-CONVENTION [TC], is used in PIB modules to define the syntax and semantics of a textual convention. Note however, that the underlying syntax of all textual conventions defined in (or imported into) a PIB module must comply with the syntax allowed by the SPPI. 11. Mapping of the OBJECT-GROUP macro For conformance purposes, it is useful to define a conformance group as a collection of related PRCs and their attributes. The SPPI uses the SMI's OBJECT-GROUP macro as the means to directly define the collection of attributes which belong to a conformance group. Since each attribute included in the collection belongs to a PRC, the collection of related PRCs which belong to a conformance group is also specified (indirectly) as the set of PRCs to which the included attributes belong. 11.1. Mapping of the OBJECTS clause The OBJECTS clause, which must be present, is used to specify each attribute contained in the conformance group. Each of the specified attributes must be defined in the same PIB module as the OBJECT-GROUP macro appears. It is required that every attribute defined in a PIB module be contained in at least one conformance group. This avoids the common error of adding a new attribute to a module and forgetting to add the new attribute to a group. Expires September 2000 [Page 19] Draft SPPI March 2000 12. Mapping of the MODULE-COMPLIANCE macro The MODULE-COMPLIANCE macro is used to convey a minimum set of requirements with respect to implementation of one or more PIB modules. A requirement on all "standard" PIB modules is that a corresponding MODULE-COMPLIANCE specification is also defined, either in the same module or in a companion module. 12.1. Mapping of the MODULE clause The MODULE clause, which must be present, is repeatedly used to name each PIB module for which compliance requirements are being specified. Each PIB module is named by its module name, and optionally, by its associated OBJECT IDENTIFIER as well. The module name can be omitted when the MODULE-COMPLIANCE invocation occurs inside a PIB module, to refer to the encompassing PIB module. 12.1.1. Mapping of the MANDATORY-GROUPS clause The MANDATORY-GROUPS clause, which need not be present, names the one or more conformance groups within the correspondent PIB module which are unconditionally mandatory for implementation. If an agent claims compliance to the PIB module, then it must implement each and every attribute (and therefore the PRCs to which they belong) within each conformance group listed. 12.1.2. Mapping of the GROUP clause The GROUP clause, which need not be present, is repeatedly used to name each conformance group which is conditionally mandatory for compliance to the PIB module. The GROUP clause can also be used to name unconditionally optional groups. A group named in a GROUP clause must be absent from the correspondent MANDATORY-GROUPS clause. Conditionally mandatory groups include those which are mandatory only if a particular protocol is implemented, or only if another group is implemented. A GROUP clause's DESCRIPTION specifies the conditions under which the group is conditionally mandatory. A group which is named in neither a MANDATORY-GROUPS clause nor a GROUP clause, is unconditionally optional for compliance to the PIB module. Expires September 2000 [Page 20] Draft SPPI March 2000 12.1.3. Mapping of the OBJECT clause The OBJECT clause, which need not be present, is repeatedly used to specify each attribute for which compliance has a refined requirement with respect to the PIB module definition. The attribute must be present in one of the conformance groups named in the correspondent MANDATORY-GROUPS clause or GROUP clauses. By definition, each attribute specified in an OBJECT clause follows a MODULE clause which names the PIB module in which that attribute is defined. Therefore, the use of an IMPORTS statement, to specify from where such attributes are imported, is redundant and is not required in a PIB module. 12.1.3.1. Mapping of the SYNTAX clause The SYNTAX clause, which need not be present, is used to provide a refined SYNTAX for the attribute named in the correspondent OBJECT clause. The refined syntax is the minimum level of support needed for this attribute in order to be compliant. 12.1.3.2. Mapping of the WRITE-SYNTAX clause The WRITE-SYNTAX clause is not supported by the SPPI. 12.1.3.3. Mapping of the MIN-ACCESS clause The MIN-ACCESS clause, which need not be present, is used to define the minimal level of access for the attribute named in the correspondent OBJECT clause. If this clause is absent, the minimal level of access is the same as the maximal level specified in the POLICY-ACCESS clause of the correspondent invocation of the OBJECT-TYPE macro. If present, this clause must specify a subset of the access specified in the correspondent POLICY-ACCESS clause, where: "install" is a subset of "install-notify", "notify" is a subset of "install-notify", and "not- accessible" is a subset of all other values. An implementation is compliant if the level of access it provides is the same or a superset of the minimal level in the MODULE-COMPLIANCE macro and the same or a subset of the maximal level in the POLICY-ACCESS clause. Expires September 2000 [Page 21] Draft SPPI March 2000 13. Extending a PIB Module The SMI's rules for extending an information module are augmented with the following rules: 13.1. OBJECT-TYPE Definitions An invocation of the OBJECT-TYPE macro may also be revised in any of the following ways: - An INSTALL-ERRORS clause may be added or an existing INSTALL-ERRORS clause have additional errors defined. - Additional named-number enumerations may be added to a CLIENT-TYPE clause. Expires September 2000 [Page 22] Draft SPPI March 2000 14. Appendix A: Mapping a PIB to a MIB Since the SPPI is modelled on the SMI, a PIB can be easily and algorithmically mapped into a MIB for the purpose of monitoring by SNMP. This mapping is achieved by means of the following rules: - Replace the keyword POLICY-DEFINITIONS with the keyword DEFINITIONS. - Delete all POLICY-ACCESS clauses. - Delete all UNIQUENESS clauses. - Delete all INSTALL-ERRORS clauses. - Delete the CLIENT-TYPE clause. - Add a MAX-ACCESS clause for each OBJECT-TYPE. For each table definition and row definition, the MAX-ACCESS is "not-accessible". For each attribute that is an index, the MAX-ACCESS is "not- accessible". For the remaining attributes, the MAX-ACCESS is "read-only" if the POLICY-ACCESS for the class is "install" or "install-notify", and it is "read-create" if the POLICY-ACCESS for the class is "notify". - Add a columnar attribute of type RowStatus with name status and with the next available OID if the POLICY-ACCESS is "notify". - Modify any SYNTAX clause which has a base data type which is not allowed in the SMI to be an OCTET STRING of the relevant size. Specifically, both Integer64 and Unsigned64 are mapped to OCTET STRING (SIZE(8)). Expires September 2000 [Page 23] Draft SPPI March 2000 15. Security Considerations This document defines a language with which to define policy information. The language itself has no security impact on the Internet. 16. Authors' Addresses Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 526 5260 Email: kzm@cisco.com Michael Fine Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 527 8218 Email: mfine@cisco.com John Seligson Nortel Networks, Inc. 4401 Great America Parkway Santa Clara, CA 95054 USA Phone: +1 408 495 2992 Email: jseligso@nortelnetworks.com Kwok Ho Chan Nortel Networks, Inc. 600 Technology Park Drive Billerica, MA 01821 USA Phone: +1 978 288 8175 Email: khchan@nortelnetworks.com Scott Hahn Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA Phone: +1 503 264 8231 Email: scott.hahn@intel.com Expires September 2000 [Page 24] Draft SPPI March 2000 Andrew Smith Extreme Networks 10460 Bandley Drive Cupertino CA 95014 USA Phone: +1 408 342 0999 Email: andrew@extremenetworks.com Francis Reichmeyer IPHighway Inc. Parker Plaza, 16th Floor 400 Kelby St, Fort-Lee, NJ 07024 USA Phone: (201) 585-0800 Email: FranR@iphighway.com 17. References [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol" RFC 2748, January 2000. [COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and A. Sastry, " COPS usage for RSVP", RFC 2749, January 2000. [COPS-PR] Reichmeyer, F., Herzog, S., Chan, K., Durham, D., Yavatkar, R. Gai, S., McCloghrie, K. and A. Smith, "COPS Usage for Policy Provisioning" Internet Draft, draft-ietf-rap-cops-pr-02.txt, March 2000. [SMI] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser. "Structure of Management Information Version 2 (SMIv2)", RFC 2578, April 1999. [TC] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser. "Textual Conventions for SMIv2", RFC 2579, April 1999. [CONF] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser. "Conformance Statements for SMIv2", RFC 2580, April 1999. Expires September 2000 [Page 25] Draft SPPI March 2000 [ASN1] Information processing systems -- Open Systems Interconnection -- Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, December 1987. Expires September 2000 [Page 26] Draft SPPI March 2000 18. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Expires September 2000 [Page 27] Draft SPPI March 2000 Table of Contents 1 Introduction .................................................... 2 2 Use of the SMI .................................................. 2 2.1 Terminology Translation ....................................... 2 2.2 Overview ...................................................... 2 3 Structure of this Specification ................................. 3 4 Definitions ..................................................... 4 5 PIB Modules ..................................................... 12 5.1 Importing Definitions ......................................... 12 5.2 Reserved Keywords ............................................. 13 6 Naming Hierarchy ................................................ 13 7 Mapping of the MODULE-IDENTITY macro ............................ 13 7.1 Mapping of the CLIENT-TYPE clause ............................. 13 8 Mapping of the OBJECT-TYPE macro ................................ 14 8.1 Mapping of the SYNTAX clause .................................. 14 8.1.1 Counter32 ................................................... 14 8.1.2 Gauge32 ..................................................... 15 8.1.3 Opaque ...................................................... 15 8.1.4 Counter64 ................................................... 15 8.1.5 Integer64 ................................................... 15 8.1.6 Unsigned64 .................................................. 15 8.1.7 Policy Rule Classes ......................................... 15 8.2 Mapping of the MAX-ACCESS clause .............................. 16 8.3 Mapping of the POLICY-ACCESS clause ........................... 16 8.4 Mapping of the INSTALL-ERRORS clause .......................... 17 8.5 Mapping of the INDEX clause ................................... 17 8.6 Mapping of the AUGMENTS clause ................................ 17 8.6.1 Relation between INDEX and AUGMENTS clauses ................. 18 8.7 Mapping of the UNIQUENESS clause .............................. 18 9 Mapping of the OBJECT-IDENTITY macro ............................ 19 10 Textual Conventions ............................................ 19 11 Mapping of the OBJECT-GROUP macro .............................. 19 11.1 Mapping of the OBJECTS clause ................................ 19 12 Mapping of the MODULE-COMPLIANCE macro ......................... 20 12.1 Mapping of the MODULE clause ................................. 20 12.1.1 Mapping of the MANDATORY-GROUPS clause ..................... 20 12.1.2 Mapping of the GROUP clause ................................ 20 12.1.3 Mapping of the OBJECT clause ............................... 21 12.1.3.1 Mapping of the SYNTAX clause ............................. 21 12.1.3.2 Mapping of the WRITE-SYNTAX clause ....................... 21 12.1.3.3 Mapping of the MIN-ACCESS clause ......................... 21 13 Extending a PIB Module ......................................... 22 13.1 OBJECT-TYPE Definitions ...................................... 22 Expires September 2000 [Page 28] Draft SPPI March 2000 14 Appendix A: Mapping a PIB to a MIB ............................. 23 15 Security Considerations ........................................ 24 16 Authors' Addresses ............................................. 24 17 References ..................................................... 25 18 Full Copyright Statement ....................................... 27 Expires September 2000 [Page 29]