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", RFC2748, January
2000.
[COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S.,
Rajan, R. and A. Sastry, " COPS usage for
RSVP", RFC2749, 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",
RFC3084, 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, RFC2578, April 1999.
[TC] McCloghrie, K., Perkins, D., Schoenwaelder, J.,
Case, J., Rose, M. and S. Waldbusser, "Textual
Conventions for SMIv2", STD 58, RFC2579, 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", RFC2573, 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", RFC2851, 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, RFC2434, October 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC2119,
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 RFCEditor function is currently provided by the
Internet Society.