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.

4.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 imports each of the base data types that
   it uses from COPS-PR-SPPI (defined in this document), and may import
   as required from other PIB modules.  A PIB module may import, from
   the SMI, (subtree) OIDs for the purpose of defining new OIDs.  A PIB
   module may also import, from MIB modules, OID assignments as well as
   textual convention definitions providing that their underlying syntax
   is supported by the SPPI.  However, the following must not be
   included in an IMPORTS statement:

   -  named types defined by ASN.1 itself, specifically: INTEGER, OCTET
      STRING, OBJECT IDENTIFIER, SEQUENCE, SEQUENCE OF type,

   -  the BITS construct.

   For each ASN.1 macro that a PIB uses, it must import that macro's
   definition from the COPS-PR-SPPI.













4.2.  Reserved Keywords

   In addition to the reserved keywords listed in the SMI, the following
   must not be used as descriptors or module names:

      EXTENDS INSTALL-ERRORS Integer64 PIB-MIN-ACCESS PIB-ACCESS PIB-
      INDEX PIB-REFERENCES PIB-TAG SUBJECT-CATEGORIES UNIQUENESS
      Unsigned64

5.  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.

6.  Mapping of the MODULE-IDENTITY macro

6.1.  Mapping of the SUBJECT-CATEGORIES clause

   The SUBJECT-CATEGORIES clause, which must be present, identifies one
   or more categories of provisioning data for which this PIB module
   defines provisioning information.  For use with the COPS-PR protocol,
   the individual subject categories are mapped to COPS Client Types
   [COPS-PR].  IANA Considerations for SPPI SUBJECT-CATEGORIES follow
   the same requirements as specified in [COPS] IANA Considerations for
   COPS Client Types. The subject categories are identified either:

   -  via the keyword "all", indicating the PIB module defines
      provisioning information relevant for all subject categories (and
      thus, all COPS Client Types), or

   -  a list of named-number enumerations, where each number which must
      be greater than zero, identifies a subject category, and is mapped
      to the Client Type which is identified by that same number in the
      COPS protocol.  The namespace for these named numbers is global
      and therefore the labels should be assigned consistently across
      PIB modules.  At present time, no more than one named-number
      enumeration should be specified.

   Note that the list of categories specified in a PIB module's SUBJECT-
   CATEGORIES clause is not exclusive.  That is, some other
   specification might (e.g., at a future date) specify additional COPS
   Client Types to which the module is relevant.








   When a PIB module applies to multiple subject categories, that PIB
   module exists in multiple virtual information stores, one for each
   Client-Type. A PIB module with SUBJECT-CATEGORIES "all" uses the
   named- number specified in the SUBJECT-CATEGORIES of the PIB it is
   associated with, as the COPS Client-Type when it is sent over COPS.

7.  Mapping of the OBJECT-TYPE macro

   The SPPI requires that all attribute definitions be contained within
   a PRC, i.e., within a table definition.

7.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, 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.

   The differences from the SMI in the semantics of ObjectSyntax are now
   described.

7.1.1.  Counter32

   The Counter32 type is not supported by the SPPI.







7.1.2.  Gauge32

   The Gauge32 type is not supported by the SPPI.

7.1.3.  Opaque

   The Opaque type is provided solely for backward-compatibility, and
   shall not be used for newly-defined object types. The Opaque type
   supports the capability to pass arbitrary ASN.1 syntax. A value is
   encoded using the ASN.1 Basic Encoding Rules [ASN1] into a string of
   octets. This, in turn, is encoded as an OCTET STRING, in effect
   "double-wrapping" the original ASN.1 value. Note that a conforming
   implementation need only be able to accept and recognize opaquely-
   encoded data. It need not be able to unwrap the data and then
   interpret its contents. A requirement on "standard" PIB modules is
   that no object may have a SYNTAX clause value of Opaque.

7.1.4.  IpAddress

   The IpAddress type is provided solely for backward-compatibility, and
   shall not be used for newly-defined object types. Instead, It is
   recommended to use the InetAddressType/InetAddress pair TCs as
   defined in RFC2851 [INETADDR].

7.1.5.  Counter64

   The Counter64 type is not supported by the SPPI.

7.1.6.  Integer64

   The Integer64 type represents integer-valued information between
   -2^63 and 2^63-1 inclusive (-9223372036854775808 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.

7.1.7.  Unsigned64

   The Unsigned64 type represents integer-valued information between 0
   and 2^64-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.








7.1.8.  Provisioning Classes

   The 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. Note that a PRC must have no
   more than 127 attributes. The usage of subids (for PRC attributes)
   beyond 127 (that is 128 and above) is reserved for Mapping PIBs to
   MIBs (see Appendix A).  PRCs that require more than 127 attributes
   must use the AUGMENTS clause to augment the PRC containing the
   initial 127 attributes to add additional attributes. Definition of
   Provisioning Classes 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.

   In the table definition, the SYNTAX clause has the form:

      SEQUENCE OF <EntryType>

   where <EntryType> refers to the SEQUENCE type of its attribute
   definitions.  In the row definition, the SYNTAX clause has the form:

      <EntryType>

   where <EntryType> is a SEQUENCE type defined as follows:

      <EntryType> ::= SEQUENCE { <type1>, ... , <typeN> }

   where there is one <type> for each attribute, and each <type> is of
   the form:

      <descriptor> <syntax>

   where <descriptor> is the descriptor naming an attribute, and
   <syntax> 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
   <syntax>.

7.2.  Mapping of the MAX-ACCESS clause

   The MAX-ACCESS clause is not supported by the SPPI.






7.3.  Mapping of the PIB-ACCESS clause

   The PIB-ACCESS clause must be present for a PRC's table definition,
   and must not be present for any other OBJECT-TYPE definition.  The
   PIB-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 provisioning 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".

   -  the value "report-only" is used to indicate a PRC which has
      neither the "install" characteristic nor the "notify"
      characteristic.  However, instances of such a PRC may be included
      in synchronous/asynchronous reports generated by the PEP.  (Note:
      PRCs having the "install" and/or "notify" characteristics may also
      be included in reports generated by the PEP.)

7.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, as the Error Sub-code, with the
   Error-Code set to priSpecificError (see [COPS-PR]).  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 greater than zero and
   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.

7.5.  Mapping of the PIB-INDEX clause

   The PIB-INDEX clause, which must be present for a row definition
   (unless an AUGMENTS or an EXTENDS clause is present instead), and
   must be absent otherwise, defines identification information for
   instances of the PRC.






   The PIB-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 InstanceId (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's
   row definition.  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 in a PIB-
   INDEX clause.

7.6.  Mapping of the INDEX clause

   The INDEX clause is optionally present if a PIB-INDEX clause is
   present, and must be absent otherwise.  If present, the INDEX clause
   can contain any number of attributes, and is used only by the
   algorithmic conversion of a PIB to a MIB (see Appendix A).

   An IMPLIED keyword can be present in an INDEX clause if so desired.

7.7.  Mapping of the AUGMENTS clause

   The AUGMENTS clause, which must not be present except in row
   definitions, is an alternative to the PIB-INDEX clause and the
   EXTENDS clause.  Every row definition has exactly one of: a PIB-INDEX
   clause, an AUGMENTS clause, or an EXTENDS clause.

   A row definition which has a PIB-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.)

   A PRC whose row definition is a row augmentation is called an
   augmenting PRC.  Instances of an augmenting PRC are identified
   according to the PIB-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]).









7.8.  Mapping of the EXTENDS clause

   The EXTENDS clause, which must not be present except in row
   definitions, is an alternative to the PIB-INDEX clause and the
   AUGMENTS clause.  Every row definition has exactly one of: a PIB-
   INDEX clause, an AUGMENTS clause, or an EXTENDS clause.

   A row definition which has an EXTENDS clause is called a sparse row
   augmentation, where the EXTENDS clause names the row definition which
   is sparsely-augmented by this sparse row augmentation.  The sparsely-
   augmented row can be a base row definition, or another sparse row
   augmentation.

   A PRC whose row definition is a sparse row augmentation is called a
   sparsely augmenting PRC.  Instances of a sparsely augmenting PRC are
   identified according to the PIB-INDEX clause of the row definition
   named in the sparsely augmenting PRC's EXTENDS clause.

   An instance of a sparsely augmenting PRC can not exist unless a
   corresponding instance of the PRC which it sparsely augments exists.
   As such, when an instance of a PRC is removed, an instance of any PRC
   which sparsely augments it is also removed.  However, an instance of
   a sparsely augmenting PRC need not exist when the corresponding
   instance of the PRC that it sparsely augments exists.  Thus, an
   instance of a sparsely augmenting PRC can be installed at the same
   time as or subsequent to the installation of, and can be removed
   prior to the removal of, the corresponding instance of the PRC that
   it sparsely augments.  So, instances of a sparsely augmenting PRC
   must be installed explicitly, but are removed either implicitly (via
   removal of the augmented PRI) or explicitly. When a sparsely
   augmented PRC is installed, both instances, the instance of the
   sparsely augmented PRC and the instance of the sparsely augmenting
   PRC must be sent in one COPS message.

7.8.1.  Relation between PIB-INDEX, AUGMENTS and EXTENDS 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 (that is, there is a one
      to zero or one correspondence between instances of a sparsely
      augmented PRC and the instances of the PRC that sparsely augments
      it.), then an EXTENDS clause should be used.






   -  Otherwise, a PIB-INDEX clause should be used which names its own
      InstanceId attribute.

7.9.  Mapping of the UNIQUENESS clause

   The UNIQUENESS clause, which is optionally present for any row
   definition, 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 specified set of attributes provide a necessary and sufficient
   set of values by which to identify an instance of this PRC.  The
   attribute contained in the PIB-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 PIB-INDEX clause.

   If a PRC and its sparsely augmenting PRC both have UNIQUENESS
   clauses, then the UNIQUENESS constraint for instances of each PRC
   MUST be applied according to the UNIQUENESS clause in the
   corresponding PRC definition.  Note that a sparsely augmenting PRC
   thus can override the UNIQUENESS clause of the PRC it sparsely
   augments.

   Even though the UNIQUENESS clause is optional, its inclusion is
   recommended wherever it provides useful information.

7.10.  Mapping of the PIB-REFERENCES clause

   The PIB-REFERENCES clause, which must be present for any attribute
   which has the SYNTAX of ReferenceId, and must be absent otherwise,
   names the PRC, an instance of which is referenced by the ReferenceId
   attribute.  For example usages of the PIB-REFERENCES clause, see
   Appendix B.

7.11.  Mapping of the PIB-TAG clause

   The PIB-TAG clause, which must be present for an attribute which has
   the SYNTAX TagReferenceId, and must be absent otherwise, is used to
   indicate that this attribute references a "tag list" of instances of
   another PRC.  Such a tag list (similar in concept to the usage of the
   same term in [APPL]) is formed by all instances of the other PRC
   which have the same (tag) value of a particular attribute of that
   other PRC.  The particular attribute of the other PRC, which must
   have the SYNTAX TagId, is named in the PIB-TAG clause.  For an
   example usage of the PIB-TAG clause, see Appendix B.







8.  Mapping of the OBJECT-IDENTITY macro

   The OBJECT-IDENTITY macro is used in PIB modules to define
   information about an OBJECT IDENTIFIER assignment.

9.  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 OBJECT-
   GROUP macro (directly) defines 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.

9.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.

10.  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.

10.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.








10.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.

10.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.

10.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.

10.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.







10.1.3.2.  Mapping of the WRITE-SYNTAX clause

   The WRITE-SYNTAX clause is not supported by the SPPI.

10.1.3.3.  Mapping of the PIB-MIN-ACCESS clause

   The PIB-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
   PIB-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 PIB-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 PIB-ACCESS
   clause.

11.  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.

11.1.  Mapping of the TEXTUAL-CONVENTION macro

   The TEXTUAL-CONVENTION macro is used to convey the syntax and
   semantics associated with a textual convention.  It should be noted
   that the expansion of the TEXTUAL-CONVENTION macro is something which
   conceptually happens during implementation and not during run-time.

   The name of a textual convention must consist of one or more letters
   or digits, with the initial character being an upper case letter.
   The name must not conflict with any of the reserved words listed in
   section 5.2, should not consist of all upper case letters, and shall
   not exceed 64 characters in length.  (However, names longer than 32
   characters are not recommended.)  The hyphen is not allowed in the
   name of a textual convention (except for use in information modules






   converted from SMIv1 which allowed hyphens in ASN.1 type
   assignments).  Further, all names used for the textual conventions
   defined in all "standard" PIB modules shall be unique.

11.1.1.  Mapping of the DISPLAY-HINT clause

   The DISPLAY-HINT clause, which need not be present, gives a hint as
   to how the value of an instance of an object with the syntax defined
   using this textual convention might be displayed. The DISPLAY-HINT
   clause must not be present if the Textual Convention is defined with
   a syntax of:  OBJECT IDENTIFIER, or any enumerated syntax (BITS or
   INTEGER).  The determination of whether it makes sense for other
   syntax types is dependent on the specific definition of the Textual
   Convention.

   The rules for the format specification of the hint are the same as
   specified in Section 3.1 of [TC].

11.1.2.  Mapping of the SYNTAX clause

   The SYNTAX clause, which must be present, defines abstract data
   structure corresponding to the textual convention.  The data
   structure must be one of the following: a base type (see the SYNTAX
   clause of an OBJECT-TYPE macro), or the BITS construct.  Note that
   this means that the SYNTAX clause of a Textual Convention can not
   refer to a previously defined Textual Convention.

11.1.2.1.  Sub-typing of Textual Conventions

   The SYNTAX clause of a TEXTUAL CONVENTION macro may be sub-typed in
   the same way as the SYNTAX clause of an OBJECT-TYPE macro.

12.  Extending a PIB Module

   PIBs may be revised as implementation experience is gained. However,
   changes with potential to cause disruption to interoperability
   between the previous PIB and the revised PIB are not allowed.

12.1.  PIB Modules

   For any change, the invocation of the MODULE-IDENTITY macro must be
   updated to include information about the revision: specifically,
   updating the LAST-UPDATED clause, adding a pair of REVISION and
   DESCRIPTION clauses, and making any necessary changes to existing
   clauses, including the ORGANIZATION and CONTACT-INFO clauses.








   Note that any definition contained in an existing PIB is available to
   be IMPORT-ed by any other PIB, and is referenced in an IMPORTS clause
   via the PIB module name.  Thus, a PIB module name should not be
   changed.  Definitions should not be moved from one PIB to another.

   Also note that obsolete definitions must not be removed from PIB
   modules since their descriptors may still be referenced by other PIB
   modules, and the OBJECT IDENTIFIERs used to name them must never be
   re-assigned.  The EXTENDS/AUGMENTS clause should be used to extend
   previous definitions depending on the information to be represented.

   Changes to an existing PIB can be made in several ways:

   -  Additional PRCs can be added to a PIB or an existing one
      deprecated.

   -  Attributes can be added to, or deprecated from, an existing PRC.
      Note that an ASN.1 value of the correct type or an ASN.1 NULL
      value must be sent even for deprecated attributes to maintain
      interoperability. New attributes must be added in sequence after
      the existing ones.

   -  An existing PRC can be extended or augmented with a new PRC
      defined in another (perhaps enterprise specific) PIB.

   Additional named-number enumerations may be added to a SUBJECT-
   CATEGORIES clause.

12.2.  Object Assignments

   If any non-editorial change is made to any clause of a object
   assignment, then the OBJECT IDENTIFIER value associated with that
   object assignment must also be changed, along with its associated
   descriptor.  Note that the max subid for PRC attributes is 127 (See
   Section 7.1.8)

12.3.  Object Definitions

   An object definition may be revised in any of the following ways:

   -  A SYNTAX clause containing an enumerated INTEGER may have new
      enumerations added or existing labels changed.  Similarly, named
      bits may be added or existing labels changed for the BITS
      construct.









   -  The value of a SYNTAX clause may be replaced by a textual
      convention, providing the textual convention is defined to use the
      same primitive ASN.1 type, has the same set of values, and has
      identical semantics.

   -  A UNITS clause may be added.

   -  A STATUS clause value of "current" may be revised as "deprecated"
      or "obsolete".  Similarly, a STATUS clause value of "deprecated"
      may be revised as "obsolete".  When making such a change, the
      DESCRIPTION clause should be updated to explain the rationale.

   -  Clarifications and additional information may be included in the
      DESCRIPTION clause.

   -  An INSTALL-ERRORS clause may be added or an existing INSTALL-
      ERRORS clause have additional errors defined.

   -  A REFERENCE clause may be added or updated.

   -  A DEFVAL clause may be added or updated.

   -  A PRC may be augmented by adding new objects at the end of the
      row, and making the corresponding update to the SEQUENCE
      definition.

   -  Entirely new objects may be defined, named with previously
      unassigned OBJECT IDENTIFIER values.

   Otherwise, if the semantics of any previously defined object are
   changed (i.e., if a non-editorial change is made to any clause other
   than those specifically allowed above), then the OBJECT IDENTIFIER
   value associated with that object must also be changed.  Note that
   changing the descriptor associated with an existing object is
   considered a semantic change, as these strings may be used in an
   IMPORTS statement.

















Appendix A: Mapping a PIB to a MIB

   Since the SPPI is modelled on the SMI, a PIB can be potentially
   algorithmically mapped into a MIB.  This mapping is achieved by means
   of the following rules:

   -  Modify the module's module name by appending "-MIB" to the name.

   -  Change the OID assigned to the MODULE-IDENTITY to be different
      value.

   -  Replace the keyword PIB-DEFINITIONS with the keyword DEFINITIONS.

   -  Modify the module names of all external references to PIB modules
      by appending "-MIB" to each such module name.

   -  For each PRC definition, if an INDEX clause is absent, change the
      "PIB-INDEX" keyword to "INDEX"; otherwise, delete the PIB-INDEX
      clause.

   -  Delete all of the following clauses: PIB-ACCESS, PIB-REFERENCES,
      PIB-TAG, UNIQUENESS, INSTALL-ERRORS, and SUBJECT-CATEGORIES.

   -  Change all PIB-MIN-ACCESS clauses to MIN-ACCESS clauses, modifying
      "install" and "install-notify" to "read-create", and "notify" to
      "read-only".

   -  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 in the INDEX clause, the MAX-ACCESS is
      "not-accessible".  For the remaining attributes, the MAX-ACCESS is
      "read-create".

   -  Add a columnar attribute of type RowStatus with a descriptor and
      appropriate DESCRIPTION.  The descriptor can be formed by
      appending the nine characters "RowStatus" to the end of the PRC's
      descriptor (truncated if necessary to avoid the resulting
      descriptor being too long).  A Subid beyond 127 (i.e., 128 and
      above) can be used as the OID for this columnar attribute.

   -  Modify any SYNTAX clause which has a base data type which is not
      allowed in the SMI, either to be a valid SMI data type or to omit
      the OBJECT-TYPE or TEXTUAL-CONVENTION definition and all
      references to it.  Since it is not clear (at this time) which is
      the best SMI data type to use, the conversion SHOULD provide a
      configurable option allowing a choice from at least the following:







      -  convert to an OCTET STRING of the relevant size.  Specifically,
         this option would map both Integer64 and Unsigned64 to OCTET
         STRING (SIZE(8)), or

      -  omit them from the conversion, or

      -  map Integer64 and Unsigned64 to Counter64 (even though this has
         problems representing negative numbers, and unwanted counter
         semantics.)

Appendix B: Example usage of PIB-REFERENCES and PIB-TAG clauses

   The following example demonstrates the use of the PIB-REFERENCES and
   PIB-TAG clauses.

   In this example, the PIB-REFERENCES clause is used by the
   qosIfDscpMapQueue attribute to indicate the PRC of which it
   references an instance, and similarly, by the qosIfDscpMapThresh
   attribute.

   The qosIfDscpMapTable PRC has an instance for each DSCP of a
   particular "map", but there is no PRC defined for a map itself;
   rather, a map consists of all instances of qosIfDscpMapTable which
   have the same value of qosIfDscpMapMapId.  That is, a tag list is
   formed by all instances of qosIfDscpMapTable which have the same
   value of qosIfDscpMapMapId.  This tag list is referenced by the
   attribute qosIfDscpAssignDscpMap, and its use of the PIB-TAG clause
   indicates this.

qosIfDscpAssignTable OBJECT-TYPE
    SYNTAX         SEQUENCE OF QosIfDscpAssignEntry
    PIB-ACCESS     install
    STATUS         current
    DESCRIPTION " "
    ::= { qosIfParameters 9 }

qosIfDscpAssignEntry OBJECT-TYPE
    SYNTAX         QosIfDscpAssignEntry
    STATUS         current
    DESCRIPTION
        "An instance of the qosIfDscpAssign class."
    PIB-INDEX      { qosIfDscpAssignPrid }
    UNIQUENESS     { qosIfDscpAssignName, qosIfDscpAssignRoles }
    ::= { qosIfDscpAssignTable 1 }

QosIfDscpAssignEntry ::= SEQUENCE {
        qosIfDscpAssignPrid       InstanceId,
        qosIfDscpAssignName       SnmpAdminString,





        qosIfDscpAssignRoles      RoleCombination,
        qosIfDscpAssignDscpMap    TagReferenceId
}

qosIfDscpAssignDscpMap OBJECT-TYPE
    SYNTAX         TagReferenceId
    PIB-TAG        { qosIfDscpMapMapId }  -- attribute defined below
    STATUS         current
    DESCRIPTION
        "The DSCP map which is applied to interfaces of type
        qosIfDscpAssignName which have a role combination of
        qosIfDscpAssignRoles."
    ::= { qosIfDscpAssignEntry 3 }

--
-- DSCP to Queue and Threshold Mapping Table
--

qosIfDscpMapTable OBJECT-TYPE
    SYNTAX         SEQUENCE OF QosIfDscpMapEntry
    PIB-ACCESS     install
    STATUS         current
    DESCRIPTION
        "Assigns DSCP values to queues and thresholds for an arbitrary
        DSCP map.  This map can then be assigned to various interface
        and role combination pairs."
    ::= { qosIfParameters 10 }

qosIfDscpMapEntry OBJECT-TYPE
    SYNTAX         QosIfDscpMapEntry
    STATUS         current
    DESCRIPTION
        "An instance of the qosIfDscpMap class."
    PIB-INDEX      { qosIfDscpMapPrid }
    UNIQUENESS     { qosIfDscpMapMapId, qosIfDscpMapDscp }
    ::= { qosIfDscpMapTable 1 }

QosIfDscpMapEntry ::= SEQUENCE {
        qosIfDscpMapPrid       InstanceId,
        qosIfDscpMapMapId      TagId,
        qosIfDscpMapDscp       Dscp,
        qosIfDscpMapQueue      ReferenceId,
        qosIfDscpMapThresh     ReferenceId
}

qosIfDscpMapMapId OBJECT-TYPE
    SYNTAX         TagId
    STATUS         current





    DESCRIPTION
        "An integer that identifies the DSCP map to which this PRI
        belongs."
    ::= { qosIfDscpMapEntry 2 }

qosIfDscpMapQueue OBJECT-TYPE
    SYNTAX         ReferenceId
    PIB-REFERENCES { qosIfQueueEntry }
    STATUS         current
    DESCRIPTION
        "This attribute maps the DSCP specified by qosIfDscpMapDscp to
        the queue identified by qosIfQueuePrid in qosIfQueueTable.
        For a given DSCP map, all the queues must belong to a single
        queue set."
    ::= { qosIfDscpMapEntry 4 }

qosIfDscpMapThresh OBJECT-TYPE
    SYNTAX         ReferenceId
    PIB-REFERENCES { qosIfThresholdEntry }
    STATUS         current
    DESCRIPTION
        "This attribute maps the DSCP specified by qosIfDscpMapDscp to
        the threshold identified by qosIfThresholdId in
        qosIfThresholdTable.  The threshold set to which this
        threshold belongs must be assigned to the queue specified by
        qosIfDscpMapQueue."
    ::= { qosIfDscpMapEntry 5 }

Security Considerations

   This document defines a language with which to define provisioning
   information.  The language itself has no security impact on the
   Internet.

IANA Considerations

   The root of the subtree administered by the Internet Assigned Numbers
   Authority (IANA) for the Internet is:

      internet       OBJECT IDENTIFIER ::= { iso 3 6 1 }

   That is, the Internet subtree of OBJECT IDENTIFIERs starts with the
   prefix:

      1.3.6.1.

   Several branches underneath this subtree are used for network
   management:





      mgmt           OBJECT IDENTIFIER ::= { internet 2 }
      experimental   OBJECT IDENTIFIER ::= { internet 3 }
      private        OBJECT IDENTIFIER ::= { internet 4 }
      enterprises    OBJECT IDENTIFIER ::= { private 1 }

   The mgmt(2) subtree is used to identify "standard" objects.

   This document defines

      pib           OBJECT IDENTIFIER ::= { mgmt 2 }

   as the root for PIBs defined to be carried over [COPS-PR].  This
   Object Identifier is a high level assignment that needs to be
   registered with [IANA]. Root Object Identifiers for future "standards
   track" PIBs will also need to be registered and MUST use Object
   Identifiers below this oid. A standards track PIB can only be
   assigned an OID by IANA if the PIB is approved by the IESG as a
   "standards track" document.  Experimental and enterprise PIBs MUST be
   defined under the "experimental" and "enterprises" Object Identifiers
   respectively.

   The PIB module "copsPrSppiTc" is defined in this document as a
   standard module and hence, needs a subid assignment under the "pib"
   oid from IANA.

   SPPI SUBJECT-CATEGORIES are mapped to COPS Client Types.  IANA
   Considerations for SUBJECT-CATEGORIES follow the same requirements as
   specified in [COPS] IANA Considerations for COPS Client Types. Thus,
   a new PIB can define a new COPS Client Type in the "standards",
   "experimental" or "enterprise" space, and when approved that would
   mean that a new COPS Client Type gets assigned. IANA must update the
   registry for COPS Client Types (where applicable as described in
   [COPS] IANA Considerations) as a result.




















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








   Ravi Sahita
   Intel
   2111 NE 25th Avenue
   Hillsboro, OR 97124 USA

   Phone: +1 503 712 1554
   EMail: ravi.sahita@intel.com


   Andrew Smith
   Allegro Networks
   6399 San Ignacio Ave.
   San Jose, CA 95119 USA

   Fax:   +1 415 345 1827
   EMail: andrew@allegronetworks.com


   Francis Reichmeyer
   PFN Inc.
   University Park at MIT
   26 Landsdowne Street
   Cambridge, MA 02139 USA

   Phone: +1 617 494 9980
   EMail: franr@pfn.com

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",
                         RFC 3084, March 2001.

   [SMI]                 McCloghrie, K., Perkins, D., Schoenwaelder, J.,
                         Case, J., Rose, M. and S. Waldbusser,
                         "Structure of Management Information Version 2
                         (SMIv2)", STD 58, RFC 2578, April 1999.






   [TC]                  McCloghrie, K., Perkins, D., Schoenwaelder, J.,
                         Case, J., Rose, M. and S. Waldbusser, "Textual
                         Conventions for SMIv2", STD 58, RFC 2579, April
                         1999.

   [CONF]                McCloghrie, K., Perkins, D., Schoenwaelder, J.,
                         Case, J., Rose, M. and S. Waldbusser,
                         "Conformance Statements for SMIv2", STD 58, RFC
                         2580, April 1999.

   [APPL]                Levi, D., Meyer, P. and B. Stewart, "SNMP
                         Applications", RFC 2573, April 1999.

   [ASN1]                Information processing systems -- Open Systems
                         Interconnection -- Specification of Abstract
                         Syntax Notation One (ASN.1), International
                         Organization for Standardization.
                         International Standard 8824, December 1987.

   [INETADDR]            Daniele, M., Haberman, B., Routhier, S. and J.
                         Schoenwaelder "Textual Conventions for Internet
                         Network Addresses", RFC 2851, June 2000.

   [IANA]   http://www.isi.edu/in-notes/iana/assignments/smi-numbers

   [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
                         Writing an IANA Considerations Section in
                         RFCs", BCP 26, RFC 2434, October 1998.

   [RFC2119]             Bradner, S., "Key words for use in RFCs to
                         Indicate Requirement Levels", BCP 14, RFC 2119,
                         March 1997.





















Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















