draft-ietf-rap-sppi-07.txt   rfc3159.txt 
Network Working Group K. McCloghrie Network Working Group K. McCloghrie
Internet Draft M. Fine Request for Comments: 3159 M. Fine
Cisco Systems Category: Standards Track Cisco Systems
J. Seligson J. Seligson
K. Chan K. Chan
Nortel Networks Nortel Networks
S. Hahn S. Hahn
R. Sahita R. Sahita
Intel Intel
A. Smith A. Smith
Allegro Networks Allegro Networks
F. Reichmeyer F. Reichmeyer
PFN PFN
August 2001
08 May 2001
Structure of Policy Provisioning Information (SPPI) Structure of Policy Provisioning Information (SPPI)
draft-ietf-rap-sppi-07.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document specifies an Internet standards track protocol for the
provisions of Section 10 of RFC2026. Internet-Drafts are working Internet community, and requests discussion and suggestions for
documents of the Internet Engineering Task Force (IETF), its areas, and improvements. Please refer to the current edition of the "Internet
its working groups. Note that other groups may also distribute working Official Protocol Standards" (STD 1) for the standardization state
documents as Internet-Drafts. and status of this protocol. Distribution of this memo is unlimited.
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 Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
SPPI May 2001
Abstract Abstract
RFC 2748 [COPS] defines the COPS protocol, and RFC 2749 [COPS-RSVP] This document, the Structure of Policy Provisioning Information
describes how the COPS protocol is used to provide for the outsourcing (SPPI), defines the adapted subset of SNMP's Structure of Management
of policy decisions for RSVP. Another usage of the COPS protocol, for Information (SMI) used to write Policy Information Base (PIB)
the provisioning of policy, is introduced in RFC 3084 [COPS-PR]. In modules.
this provisioning model, the policy information is viewed as a
collection of Provisioning Classes (PRCs) and Provisioning Instances RFC 2748 defines the COPS protocol, and RFC 2749 describes how the
(PRIs) residing in a virtual information store, termed the Policy COPS protocol is used to provide for the outsourcing of policy
Information Base (PIB). Collections of related Provisioning Classes are decisions for RSVP. Another usage of the COPS protocol, for the
defined in a PIB module. PIB modules are written using an adapted provisioning of policy, is introduced in RFC 3084. In this
subset of SNMP's Structure of Management Information (SMI) [SMI, TC, provisioning model, the policy information is viewed as a collection
CONF]. It is the purpose of this document, the Structure of Policy of Provisioning Classes (PRCs) and Provisioning Instances (PRIs)
Provisioning Information (SPPI), to define that adapted subset. residing in a virtual information store, termed the Policy
Information Base (PIB). Collections of related Provisioning Classes
are defined in a PIB module.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119]. document are to be interpreted as described in [RFC2119].
Table of Contents
1 Use of the SMI ................................................. 3
1.1 Terminology Translation ...................................... 3
1.2 Overview ..................................................... 3
2 Structure of this Specification ................................ 4
3 Definitions .................................................... 5
4 PIB Modules .................................................... 17
4.1 Importing Definitions ........................................ 17
4.2 Reserved Keywords ............................................ 18
5 Naming Hierarchy ............................................... 18
6 Mapping of the MODULE-IDENTITY macro ........................... 18
6.1 Mapping of the SUBJECT-CATEGORIES clause ..................... 18
7 Mapping of the OBJECT-TYPE macro ............................... 19
7.1 Mapping of the SYNTAX clause ................................. 19
7.1.1 Counter32 .................................................. 19
7.1.2 Gauge32 .................................................... 20
7.1.3 Opaque ..................................................... 20
7.1.4 IpAddress .................................................. 20
7.1.5 Counter64 .................................................. 20
7.1.6 Integer64 .................................................. 20
7.1.7 Unsigned64 ................................................. 20
7.1.8 Provisioning Classes ....................................... 21
7.2 Mapping of the MAX-ACCESS clause ............................. 21
7.3 Mapping of the PIB-ACCESS clause ............................. 22
7.4 Mapping of the INSTALL-ERRORS clause ......................... 22
7.5 Mapping of the PIB-INDEX clause .............................. 22
7.6 Mapping of the INDEX clause .................................. 23
7.7 Mapping of the AUGMENTS clause ............................... 23
7.8 Mapping of the EXTENDS clause ................................ 24
7.8.1 Relation between PIB-INDEX, AUGMENTS and EXTENDS clauses .. 24
7.9 Mapping of the UNIQUENESS clause ............................. 25
7.10 Mapping of the PIB-REFERENCES clause ........................ 25
7.11 Mapping of the PIB-TAG clause ............................... 25
8 Mapping of the OBJECT-IDENTITY macro ........................... 26
9 Mapping of the OBJECT-GROUP macro .............................. 26
9.1 Mapping of the OBJECTS clause ................................ 26
10 Mapping of the MODULE-COMPLIANCE macro ........................ 26
10.1 Mapping of the MODULE clause ................................ 26
10.1.1 Mapping of the MANDATORY-GROUPS clause .................... 27
10.1.2 Mapping of the GROUP clause ............................... 27
10.1.3 Mapping of the OBJECT clause .............................. 27
10.1.3.1 Mapping of the SYNTAX clause ............................ 27
10.1.3.2 Mapping of the WRITE-SYNTAX clause ...................... 28
10.1.3.3 Mapping of the PIB-MIN-ACCESS clause .................... 28
11 Textual Conventions ........................................... 28
11.1 Mapping of the TEXTUAL-CONVENTION macro ..................... 28
11.1.1 Mapping of the DISPLAY-HINT clause ........................ 29
11.1.2 Mapping of the SYNTAX clause .............................. 29
11.1.2.1 Sub-typing of Textual Conventions ....................... 29
12 Extending a PIB Module ........................................ 29
12.1 PIB Modules ................................................. 29
12.2 Object Assignments .......................................... 30
12.3 Object Definitions .......................................... 30
Appendix A: Mapping a PIB to a MIB ............................... 32
Appendix B: Example usage of PIB-REFERENCES and PIB-TAG clauses .. 33
Security Considerations .......................................... 35
IANA Considerations .............................................. 35
Authors' Addresses ............................................... 37
References ....................................................... 38
Full Copyright Statement ......................................... 40
1. Use of the SMI 1. Use of the SMI
The SPPI and PIB modules are based on SNMP's SMI and MIB modules, which The SPPI and PIB modules are based on SNMP's SMI and MIB modules,
use an adapted subset of the ASN.1 data definition language [ASN1]. The which use an adapted subset of the ASN.1 data definition language
decision to base the definition of PIB modules on this format allows for [ASN1]. The decision to base the definition of PIB modules on this
the leveraging of the community's knowledge, experience and tools of the format allows for the leveraging of the community's knowledge,
SMI and MIB modules. experience and tools of the SMI and MIB modules.
1.1. Terminology Translation 1.1. Terminology Translation
The SMI uses the term "managed objects" to refer to object types, both The SMI uses the term "managed objects" to refer to object types,
tabular types with descriptors such as xxxTable and xxxEntry, as well as both tabular types with descriptors such as xxxTable and xxxEntry, as
scalar and columnar object types. The SPPI does not use the term well as scalar and columnar object types. The SPPI does not use the
"object" so as to avoid confusion with COPS protocol objects. Instead, term "object" so as to avoid confusion with COPS protocol objects.
the SPPI uses the term Provisioning Class (PRC) for the table and row Instead, the SPPI uses the term Provisioning Class (PRC) for the
definitions (the xxxTable and xxxEntry objects, respectively), and table and row definitions (the xxxTable and xxxEntry objects,
Provisioning Instance (PRI) for an instantiation of a row definition. respectively), and Provisioning Instance (PRI) for an instantiation
For a columnar object of a table definition, the SPPI uses the term of a row definition. For a columnar object of a table definition,
"attribute" of a Provisioning Class. (The SPPI does not support the the SPPI uses the term "attribute" of a Provisioning Class. (The
equivalent of the SMI's scalar objects.) SPPI does not support the equivalent of the SMI's scalar objects.)
SPPI May 2001
1.2. Overview 1.2. Overview
SNMP's SMI is divided into five parts: module definitions, object SNMP's SMI is divided into five parts: module definitions, object
definitions, notification definitions [SMI], textual convention definitions, notification definitions [SMI], textual convention
definitions [TC] and conformance definitions [CONF]. definitions [TC] and conformance definitions [CONF].
- The SMI's MODULE-IDENTITY macro is used to convey the semantics of - 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 MIB module. The SPPI uses this macro to convey the semantics of
a PIB module. a PIB module.
- The SMI's OBJECT-TYPE macro is used to convey the syntax and - The SMI's OBJECT-TYPE macro is used to convey the syntax and
semantics of managed objects. The SPPI uses this macro to convey semantics of managed objects. The SPPI uses this macro to convey
the syntax and semantics of PRCs and their attributes. the syntax and semantics of PRCs and their attributes.
- The SMI's notification definitions are not used (at this time) by - The SMI's notification definitions are not used (at this time) by
the SPPI. (Note that the use of the keyword 'notify' in the SPPI the SPPI. (Note that the use of the keyword 'notify' in the SPPI
is not related to the SMI's notifications). is not related to the SMI's notifications).
- The SMI's TEXTUAL CONVENTION macro allows new data types to be - The SMI's TEXTUAL CONVENTION macro allows new data types to be
defined. The SPPI uses this macro to define new data types having defined. The SPPI uses this macro to define new data types having
particular syntax and semantics which is common to several particular syntax and semantics which is common to several
attributes of one of more PRCs. attributes of one of more PRCs.
- The SMI's conformance definitions define several macros: the - The SMI's conformance definitions define several macros: the
OBJECT-GROUP macro, the NOTIFICATION-GROUP macro, the MODULE- OBJECT-GROUP macro, the NOTIFICATION-GROUP macro, the MODULE-
COMPLIANCE macro and the AGENT-CAPABILITIES macro. The SPPI uses COMPLIANCE macro and the AGENT-CAPABILITIES macro. The SPPI uses
the OBJECT-GROUP and MODULE-COMPLIANCE macros to specify acceptable the OBJECT-GROUP and MODULE-COMPLIANCE macros to specify
lower-bounds of implementation of the attributes of PRCs, and acceptable lower-bounds of implementation of the attributes of
thereby indirectly, acceptable lower-bounds of implementation of PRCs, and thereby indirectly, acceptable lower-bounds of
the PRCs themselves. The NOTIFICATION-GROUP macro is not used (at implementation of the PRCs themselves. The NOTIFICATION-GROUP
this time) by the SPPI. Potential usage by the SPPI of the AGENT- macro is not used (at this time) by the SPPI. Potential usage by
CAPABILITIES macro is for further study. the SPPI of the AGENT- CAPABILITIES macro is for further study.
2. Structure of this Specification 2. Structure of this Specification
The SMI is specified in terms of an ASN.1 definition together with The SMI is specified in terms of an ASN.1 definition together with
descriptive text for each element introduced in that ASN.1 definition. descriptive text for each element introduced in that ASN.1
This document specifies the SPPI also via a ASN.1 definition, which is a definition. This document specifies the SPPI also via a ASN.1
modified version of the SMI's definition, together with descriptive text definition, which is a modified version of the SMI's definition,
for only those elements in the SPPI's ASN.1 definition which have together with descriptive text for only those elements in the SPPI's
differences from the SMI's. For elements in the ASN.1 definition which ASN.1 definition which have differences from the SMI's. For elements
have no descriptive text in this specification, the reader is referred in the ASN.1 definition which have no descriptive text in this
to the SMI's descriptive text for that element. specification, the reader is referred to the SMI's descriptive text
for that element.
SPPI May 2001
3. Definitions 3. Definitions
COPS-PR-SPPI DEFINITIONS ::= BEGIN COPS-PR-SPPI DEFINITIONS ::= BEGIN
IMPORTS ObjectName, SimpleSyntax, ExtUTCTime, mgmt IMPORTS ObjectName, SimpleSyntax, ExtUTCTime, mgmt
FROM SNMPv2-SMI; FROM SNMPv2-SMI;
-- the root for PIB definitions -- the root for PIB definitions
skipping to change at page 4, line 33 skipping to change at page 5, line 31
SubjectPart -- new SubjectPart -- new
"LAST-UPDATED" value(Update ExtUTCTime) "LAST-UPDATED" value(Update ExtUTCTime)
"ORGANIZATION" Text "ORGANIZATION" Text
"CONTACT-INFO" Text "CONTACT-INFO" Text
"DESCRIPTION" Text "DESCRIPTION" Text
RevisionPart RevisionPart
VALUE NOTATION ::= VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER) value(VALUE OBJECT IDENTIFIER)
SubjectPart ::= -- new SubjectPart ::= -- new
"SUBJECT-CATEGORIES" "{" Categories "}" "SUBJECT-CATEGORIES" "{" Categories "}"
-- see IANA Considerations section
Categories ::= -- new Categories ::= -- new
CategoryIDs CategoryIDs
| "all" | "all"
CategoryIDs ::= -- new CategoryIDs ::= -- new
CategoryID CategoryID
| CategoryIDs "," CategoryID | CategoryIDs "," CategoryID
CategoryID ::= -- new CategoryID ::= -- new
identifier "(" number ")" -- number is positive identifier "(" number ")" -- number is positive
RevisionPart ::= RevisionPart ::=
Revisions Revisions
| empty | empty
Revisions ::= Revisions ::=
Revision Revision
| Revisions Revision | Revisions Revision
Revision ::= Revision ::=
"REVISION" value(Update ExtUTCTime) "REVISION" value(Update ExtUTCTime)
SPPI May 2001
"DESCRIPTION" Text "DESCRIPTION" Text
-- a character string as defined in [SMI] -- a character string as defined in [SMI]
Text ::= value(IA5String) Text ::= value(IA5String)
END END
-- --
OBJECT-IDENTITY MACRO ::= OBJECT-IDENTITY MACRO ::=
BEGIN BEGIN
skipping to change at page 6, line 4 skipping to change at page 6, line 47
-- 3 built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER -- 3 built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER
-- 7 application-defined types: Integer32, IpAddress, Unsigned32, -- 7 application-defined types: Integer32, IpAddress, Unsigned32,
-- TimeTicks, Opaque, Integer64 and Unsigned64 -- TimeTicks, Opaque, Integer64 and Unsigned64
ObjectSyntax ::= ObjectSyntax ::=
CHOICE { CHOICE {
simple simple
SimpleSyntax, SimpleSyntax,
-- note that SEQUENCEs for table and row definitions -- note that SEQUENCEs for table and row definitions
SPPI May 2001
-- are not mentioned here... -- are not mentioned here...
application-wide application-wide
ApplicationSyntax ApplicationSyntax
} }
-- application-wide types -- application-wide types
ApplicationSyntax ::= ApplicationSyntax ::=
CHOICE { CHOICE {
skipping to change at page 7, line 4 skipping to change at page 7, line 43
INTEGER (-2147483648..2147483647) INTEGER (-2147483648..2147483647)
-- (this is a tagged type for historical reasons) -- (this is a tagged type for historical reasons)
IpAddress ::= IpAddress ::=
[APPLICATION 0] [APPLICATION 0]
IMPLICIT OCTET STRING (SIZE (4)) IMPLICIT OCTET STRING (SIZE (4))
-- ******* THIS TYPE DEFINITION IS DEPRECATED ******* -- ******* THIS TYPE DEFINITION IS DEPRECATED *******
-- The IpAddress type represents a 32-bit internet -- The IpAddress type represents a 32-bit internet
-- IPv4 address. It is represented as an OctetString -- IPv4 address. It is represented as an OctetString
-- of length 4, in network byte-order. -- of length 4, in network byte-order.
SPPI May 2001
-- Note that the IpAddress type is present for -- Note that the IpAddress type is present for
-- historical reasons. IPv4 and IPv6 addresses should -- historical reasons. IPv4 and IPv6 addresses should
-- be represented using the INET-ADDRESS-MIB -- be represented using the INET-ADDRESS-MIB
-- defined in [INETADDR]. -- defined in [INETADDR].
-- an unsigned 32-bit quantity -- an unsigned 32-bit quantity
Unsigned32 ::= Unsigned32 ::=
[APPLICATION 2] [APPLICATION 2]
IMPLICIT INTEGER (0..4294967295) IMPLICIT INTEGER (0..4294967295)
skipping to change at page 7, line 33 skipping to change at page 8, line 21
Opaque ::= Opaque ::=
[APPLICATION 4] [APPLICATION 4]
IMPLICIT OCTET STRING IMPLICIT OCTET STRING
-- the following 2 types are not present in the SMI -- the following 2 types are not present in the SMI
Integer64 ::= Integer64 ::=
[APPLICATION 10] [APPLICATION 10]
IMPLICIT INTEGER (-9223372036854775808..9223372036854775807) IMPLICIT INTEGER (-9223372036854775808..9223372036854775807)
Unsigned64 Unsigned64 ::=
[APPLICATION 11] [APPLICATION 11]
IMPLICIT INTEGER (0..18446744073709551615) IMPLICIT INTEGER (0..18446744073709551615)
-- definition for Provisioning Classes and their attributes -- definition for Provisioning Classes and their attributes
-- (differences from the SMI are noted in the ASN.1 comments) -- (differences from the SMI are noted in the ASN.1 comments)
OBJECT-TYPE MACRO ::= OBJECT-TYPE MACRO ::=
BEGIN BEGIN
TYPE NOTATION ::= TYPE NOTATION ::=
"SYNTAX" Syntax "SYNTAX" Syntax
UnitsPart UnitsPart
"PIB-ACCESS" Access -- modified "PIB-ACCESS" Access -- modified
PibReferencesPart -- new PibReferencesPart -- new
PibTagPart -- new PibTagPart -- new
"STATUS" Status "STATUS" Status
"DESCRIPTION" Text "DESCRIPTION" Text
ErrorsPart -- new ErrorsPart -- new
SPPI May 2001
ReferPart ReferPart
IndexPart -- modified IndexPart -- modified
MibIndexPart -- modified MibIndexPart -- modified
UniquePart -- new UniquePart -- new
DefValPart DefValPart
VALUE NOTATION ::= VALUE NOTATION ::=
value(VALUE ObjectName) value(VALUE ObjectName)
Syntax ::= -- Must be one of the following: Syntax ::= -- Must be one of the following:
skipping to change at page 9, line 4 skipping to change at page 9, line 37
ErrorsPart ::= -- new ErrorsPart ::= -- new
"INSTALL-ERRORS" "{" Errors "}" "INSTALL-ERRORS" "{" Errors "}"
| empty | empty
Errors ::= -- new Errors ::= -- new
Error Error
| Errors "," Error | Errors "," Error
Error ::= -- new Error ::= -- new
identifier "(" number ")" -- number is positive identifier "(" number ")" -- number is positive
SPPI May 2001
ReferPart ::= ReferPart ::=
"REFERENCE" Text "REFERENCE" Text
| empty | empty
IndexPart ::= IndexPart ::=
"PIB-INDEX" "{" Index "}" -- new "PIB-INDEX" "{" Index "}" -- new
| "AUGMENTS" "{" Entry "}" | "AUGMENTS" "{" Entry "}"
| "EXTENDS" "{" Entry "}" -- new | "EXTENDS" "{" Entry "}" -- new
| empty | empty
skipping to change at page 10, line 4 skipping to change at page 10, line 34
PibTagPart ::= PibTagPart ::=
-- for use with TagReferenceId TC -- for use with TagReferenceId TC
"PIB-TAG" "{" Attr "}" "PIB-TAG" "{" Attr "}"
| empty | empty
Attr ::= -- specifies an attribute Attr ::= -- specifies an attribute
value(ObjectName) value(ObjectName)
UniquePart ::= -- new UniquePart ::= -- new
"UNIQUENESS" "{" UniqueTypes "}" "UNIQUENESS" "{" UniqueTypes "}"
SPPI May 2001
| "UNIQUENESS" "{" "}" | "UNIQUENESS" "{" "}"
| empty | empty
UniqueTypes ::= UniqueTypes ::=
UniqueType UniqueType
| UniqueTypes "," UniqueType | UniqueTypes "," UniqueType
UniqueType ::= UniqueType ::=
-- the correspondent OBJECT-TYPE invocation -- the correspondent OBJECT-TYPE invocation
value(ObjectName) value(ObjectName)
DefValPart ::= "DEFVAL" "{" Defvalue "}" DefValPart ::= "DEFVAL" "{" Defvalue "}"
skipping to change at page 11, line 4 skipping to change at page 11, line 30
ObjectsPart ObjectsPart
"STATUS" Status "STATUS" Status
"DESCRIPTION" Text "DESCRIPTION" Text
ReferPart ReferPart
VALUE NOTATION ::= VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER) value(VALUE OBJECT IDENTIFIER)
ObjectsPart ::= ObjectsPart ::=
"OBJECTS" "{" Objects "}" "OBJECTS" "{" Objects "}"
SPPI May 2001
Objects ::= Objects ::=
Object Object
| Objects "," Object | Objects "," Object
Object ::= Object ::=
value(ObjectName) value(ObjectName)
Status ::= Status ::=
"current" "current"
| "deprecated" | "deprecated"
| "obsolete" | "obsolete"
skipping to change at page 12, line 4 skipping to change at page 12, line 27
| "deprecated" | "deprecated"
| "obsolete" | "obsolete"
ReferPart ::= ReferPart ::=
"REFERENCE" Text "REFERENCE" Text
| empty | empty
ModulePart ::= ModulePart ::=
Modules Modules
Modules ::= Modules ::=
SPPI May 2001
Module Module
| Modules Module | Modules Module
Module ::= Module ::=
-- name of module -- -- name of module --
"MODULE" ModuleName "MODULE" ModuleName
MandatoryPart MandatoryPart
CompliancePart CompliancePart
ModuleName ::= ModuleName ::=
-- identifier must start with uppercase letter -- identifier must start with uppercase letter
skipping to change at page 13, line 4 skipping to change at page 13, line 25
Compliance ::= Compliance ::=
ComplianceGroup ComplianceGroup
| Object | Object
ComplianceGroup ::= ComplianceGroup ::=
"GROUP" value(OBJECT IDENTIFIER) "GROUP" value(OBJECT IDENTIFIER)
"DESCRIPTION" Text "DESCRIPTION" Text
Object ::= Object ::=
"OBJECT" value(ObjectName) "OBJECT" value(ObjectName)
SPPI May 2001
InstallSyntaxPart -- modified InstallSyntaxPart -- modified
AccessPart AccessPart
"DESCRIPTION" Text "DESCRIPTION" Text
-- must be a refinement for object's SYNTAX clause -- must be a refinement for object's SYNTAX clause
InstallSyntaxPart ::= "SYNTAX" Syntax InstallSyntaxPart ::= "SYNTAX" Syntax
| empty | empty
Syntax ::= -- Must be one of the following: Syntax ::= -- Must be one of the following:
-- a base type (or its refinement), -- a base type (or its refinement),
skipping to change at page 13, line 34 skipping to change at page 14, line 4
NamedBit ::= identifier "(" number ")" -- number is nonnegative NamedBit ::= identifier "(" number ")" -- number is nonnegative
AccessPart ::= AccessPart ::=
"PIB-MIN-ACCESS" Access -- modified "PIB-MIN-ACCESS" Access -- modified
| empty | empty
Access ::= -- modified Access ::= -- modified
"not-accessible" "not-accessible"
| "install" | "install"
| "notify" | "notify"
| "install-notify" | "install-notify"
| "report-only"
-- a character string as defined in [SMI] -- a character string as defined in [SMI]
Text ::= value(IA5String) Text ::= value(IA5String)
END END
-- definition of textual conventions -- definition of textual conventions
TEXTUAL-CONVENTION MACRO ::= TEXTUAL-CONVENTION MACRO ::=
BEGIN BEGIN
TYPE NOTATION ::= TYPE NOTATION ::=
DisplayPart DisplayPart
"STATUS" Status "STATUS" Status
"DESCRIPTION" Text "DESCRIPTION" Text
ReferPart ReferPart
"SYNTAX" Syntax "SYNTAX" Syntax
VALUE NOTATION ::= VALUE NOTATION ::=
SPPI May 2001
value(VALUE Syntax) -- adapted ASN.1 value(VALUE Syntax) -- adapted ASN.1
DisplayPart ::= DisplayPart ::=
"DISPLAY-HINT" Text "DISPLAY-HINT" Text
| empty | empty
Status ::= Status ::=
"current" "current"
| "deprecated" | "deprecated"
| "obsolete" | "obsolete"
skipping to change at page 14, line 36 skipping to change at page 15, line 4
-- a BITS pseudo-type -- a BITS pseudo-type
type type
| "BITS" "{" NamedBits "}" | "BITS" "{" NamedBits "}"
NamedBits ::= NamedBit NamedBits ::= NamedBit
| NamedBits "," NamedBit | NamedBits "," NamedBit
NamedBit ::= identifier "(" number ")" -- number is nonnegative NamedBit ::= identifier "(" number ")" -- number is nonnegative
END END
END END
SPPI May 2001
COPS-PR-SPPI-TC PIB-DEFINITIONS ::= BEGIN COPS-PR-SPPI-TC PIB-DEFINITIONS ::= BEGIN
IMPORTS Unsigned32, MODULE-IDENTITY, TEXTUAL-CONVENTION, pib IMPORTS Unsigned32, MODULE-IDENTITY, TEXTUAL-CONVENTION, pib
FROM COPS-PR-SPPI; FROM COPS-PR-SPPI;
copsPrSppiTc MODULE-IDENTITY copsPrSppiTc MODULE-IDENTITY
SUBJECT-CATEGORIES { all } SUBJECT-CATEGORIES { all }
LAST-UPDATED "200009201800Z" LAST-UPDATED "200108160000Z"
ORGANIZATION "IETF RAP WG" ORGANIZATION "IETF RAP WG"
CONTACT-INFO "Keith McCloghrie CONTACT-INFO "Keith McCloghrie
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive, 170 West Tasman Drive,
San Jose, CA 95134-1706 USA San Jose, CA 95134-1706 USA
Phone: +1 408 526 5260 Phone: +1 408 526 5260
Email: kzm@cisco.com Email: kzm@cisco.com
Ravi Sahita Ravi Sahita
Intel Intel
2111 NE 25th Avenue 2111 NE 25th Avenue
Hillsboro, OR 97124 USA Hillsboro, OR 97124 USA
Phone: +1 503 712 1554 Phone: +1 503 712 1554
Email: ravi.sahita@intel.com " Email: ravi.sahita@intel.com "
DESCRIPTION DESCRIPTION
"The PIB module containing a set of Textual Conventions "The PIB module containing a set of Textual Conventions
which have general applicability to all PIB modules." which have general applicability to all PIB modules."
REVISION "200009201800Z" REVISION "200108160000Z"
DESCRIPTION DESCRIPTION
"Initial version, published in RFC xxxx." "Initial version, published in RFC 3159."
::= { pib xxx } -- to be assigned by IANA ::= { pib 1 }
InstanceId ::= TEXTUAL-CONVENTION InstanceId ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The textual convention for use by an attribute which is used "The textual convention for use by an attribute which is used
as the instance-identifying index of a PRC, i.e., an attribute as the instance-identifying index of a PRC, i.e., an attribute
named in a PIB-INDEX clause. The value of an attribute with this named in a PIB-INDEX clause. The value of an attribute with
syntax is always greater than zero. PRIs of the same PRC need this syntax is always greater than zero. PRIs of the same PRC
not have contiguous values for their instance-identifying need not have contiguous values for their instance-identifying
attribute." attribute."
SYNTAX Unsigned32 (1..4294967295) SYNTAX Unsigned32 (1..4294967295)
ReferenceId ::= TEXTUAL-CONVENTION ReferenceId ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A textual convention for use by an attribute which is used as "A textual convention for use by an attribute which is used as
SPPI May 2001
a pointer in order to reference an instance of a particular a pointer in order to reference an instance of a particular
PRC. An attribute with this syntax must not be used in a PRC. An attribute with this syntax must not be used in a
PIB-INDEX clause , and its description must specify the PIB-INDEX clause , and its description must specify the
particular PRC to which the referenced PRI will belong. particular PRC to which the referenced PRI will belong.
For an attribute of this type, the referenced PRI must exist. For an attribute of this type, the referenced PRI must exist.
Furthermore, it is an error to try to delete a PRI that is Furthermore, it is an error to try to delete a PRI that is
referenced by another instance without first deleting/modifying referenced by another instance without first deleting/modifying
the referencing instance. The definition of an attribute with the referencing instance. The definition of an attribute with
this syntax can permit the attribute to have a value of zero to this syntax can permit the attribute to have a value of zero to
indicate that it is not currently pointing to an PRI." indicate that it is not currently pointing to a PRI."
SYNTAX Unsigned32 SYNTAX Unsigned32
Prid ::= TEXTUAL-CONVENTION Prid ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Represents a pointer to a PRI, i.e,. to an instance of a "Represents a pointer to a PRI, i.e,. to an instance of a
PRC. The value is the OID name of the PRC's row definition, PRC. The value is the OID name of the PRC's row definition,
appended with one sub-identifier containing the value of the appended with one sub-identifier containing the value of the
InstanceId value for the referenced instance. The definition InstanceId value for the referenced instance. The definition
of an attribute with this syntax can permit the attribute to of an attribute with this syntax can permit the attribute to
skipping to change at page 16, line 48 skipping to change at page 16, line 45
TagReferenceId ::= TEXTUAL-CONVENTION TagReferenceId ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Represents a reference to a tag list of instances of a "Represents a reference to a tag list of instances of a
particular PRC. The particular PRC must have an attribute particular PRC. The particular PRC must have an attribute
with the syntax of TagId. The tag list consists of with the syntax of TagId. The tag list consists of
all instances which have the same value of the TagId all instances which have the same value of the TagId
attribute. Reference to the tag list is via the attribute attribute. Reference to the tag list is via the attribute
with the syntax of TagReferenceId containing the tag with the syntax of TagReferenceId containing the tag
value which identifies the tag list." value which identifies the tag list.
The definition of an attribute with this syntax can permit
the attribute to have a value of 0 to indicate that it is
not currently referencing a tag list."
SYNTAX Unsigned32 SYNTAX Unsigned32
END END
SPPI May 2001
4. PIB Modules 4. PIB Modules
The names of all standard PIB modules must be unique (but different The names of all standard PIB modules must be unique (but different
versions of the same module should have the same name). Developers of versions of the same module should have the same name). Developers
enterprise PIB modules are encouraged to choose names for their modules of enterprise PIB modules are encouraged to choose names for their
that will have a low probability of colliding with standard or other modules that will have a low probability of colliding with standard
enterprise modules. or other enterprise modules.
The first line of a PIB module is: The first line of a PIB module is:
PIB-MODULE-NAME PIB-DEFINITIONS ::= BEGIN PIB-MODULE-NAME PIB-DEFINITIONS ::= BEGIN
where PIB-MODULE-NAME is the module name. where PIB-MODULE-NAME is the module name.
Like the SMI, additional ASN.1 macros must not be defined in PIB Like the SMI, additional ASN.1 macros must not be defined in PIB
modules. modules.
4.1. Importing Definitions 4.1. Importing Definitions
Like the SMI, a PIB module which needs to reference an external Like the SMI, a PIB module which needs to reference an external
definition, must use the IMPORTS statement to identify both the definition, must use the IMPORTS statement to identify both the
descriptor and the module in which the descriptor is defined, where a descriptor and the module in which the descriptor is defined, where a
module is identified by its ASN.1 module name. module is identified by its ASN.1 module name.
In particular, a PIB module imports each of the base data types that it In particular, a PIB module imports each of the base data types that
uses from COPS-PR-SPPI (defined in this document), and may import as it uses from COPS-PR-SPPI (defined in this document), and may import
required from other PIB modules. A PIB module may import, from the SMI, as required from other PIB modules. A PIB module may import, from
(subtree) OIDs for the purpose of defining new OIDs. A PIB module may the SMI, (subtree) OIDs for the purpose of defining new OIDs. A PIB
also import, from MIB modules, OID assignments as well as textual module may also import, from MIB modules, OID assignments as well as
convention definitions providing that their underlying syntax is textual convention definitions providing that their underlying syntax
supported by the SPPI. However, the following must not be included in is supported by the SPPI. However, the following must not be
an IMPORTS statement: included in an IMPORTS statement:
- named types defined by ASN.1 itself, specifically: INTEGER, OCTET - named types defined by ASN.1 itself, specifically: INTEGER, OCTET
STRING, OBJECT IDENTIFIER, SEQUENCE, SEQUENCE OF type, 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 - the BITS construct.
definition from the COPS-PR-SPPI.
4.2. Reserved Keywords For each ASN.1 macro that a PIB uses, it must import that macro's
definition from the COPS-PR-SPPI.
In addition to the reserved keywords listed in the SMI, the following 4.2. Reserved Keywords
must not be used as descriptors or module names:
SPPI May 2001 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 EXTENDS INSTALL-ERRORS Integer64 PIB-MIN-ACCESS PIB-ACCESS PIB-
PIB-INDEX PIB-REFERENCES PIB-TAG SUBJECT-CATEGORIES UNIQUENESS INDEX PIB-REFERENCES PIB-TAG SUBJECT-CATEGORIES UNIQUENESS
Unsigned64 Unsigned64
5. Naming Hierarchy 5. Naming Hierarchy
The SPPI uses the same OBJECT IDENTIFIER naming hierarchy as the SMI. The SPPI uses the same OBJECT IDENTIFIER naming hierarchy as the SMI.
That is, OIDs are typically assigned to PIB modules from the subtree That is, OIDs are typically assigned to PIB modules from the subtree
administered by the Internet Assigned Numbers Authority (IANA). administered by the Internet Assigned Numbers Authority (IANA).
However, like the SMI, the SPPI does not prohibit the definition of PRCs However, like the SMI, the SPPI does not prohibit the definition of
in other portions of the OID tree. PRCs in other portions of the OID tree.
6. Mapping of the MODULE-IDENTITY macro 6. Mapping of the MODULE-IDENTITY macro
6.1. Mapping of the SUBJECT-CATEGORIES clause 6.1. Mapping of the SUBJECT-CATEGORIES clause
The SUBJECT-CATEGORIES clause, which must be present, identifies one or The SUBJECT-CATEGORIES clause, which must be present, identifies one
more categories of provisioning data for which this PIB module defines or more categories of provisioning data for which this PIB module
provisioning information. For use with the COPS-PR protocol, the defines provisioning information. For use with the COPS-PR protocol,
individual subject categories are mapped to COPS Client Types [COPS-PR]. the individual subject categories are mapped to COPS Client Types
IANA Considerations for SPPI SUBJECT-CATEGORIES follow the same [COPS-PR]. IANA Considerations for SPPI SUBJECT-CATEGORIES follow
requirements as specified in [COPS] IANA Considerations for COPS Client the same requirements as specified in [COPS] IANA Considerations for
Types. The subject categories are identified either: 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 - via the keyword "all", indicating the PIB module defines
be greater than zero, identifies a subject category, and is mapped provisioning information relevant for all subject categories (and
to the Client Type which is identified by that same number in the thus, all COPS Client Types), or
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- - a list of named-number enumerations, where each number which must
CATEGORIES clause is not exclusive. That is, some other specification be greater than zero, identifies a subject category, and is mapped
might (e.g., at a future date) specify additional COPS Client Types to to the Client Type which is identified by that same number in the
which the module is relevant. 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.
When a PIB module applies to multiple subject categories, that PIB Note that the list of categories specified in a PIB module's SUBJECT-
module exists in multiple virtual information stores, one for each CATEGORIES clause is not exclusive. That is, some other
SPPI May 2001 specification might (e.g., at a future date) specify additional COPS
Client Types to which the module is relevant.
Client-Type. A PIB module with SUBJECT-CATEGORIES "all" uses the named- When a PIB module applies to multiple subject categories, that PIB
number specified in the SUBJECT-CATEGORIES of the PIB it is associated module exists in multiple virtual information stores, one for each
with, as the COPS Client-Type when it is sent over COPS. 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 7. Mapping of the OBJECT-TYPE macro
The SPPI requires that all attribute definitions be contained within a The SPPI requires that all attribute definitions be contained within
PRC, i.e., within a table definition. a PRC, i.e., within a table definition.
7.1. Mapping of the SYNTAX clause 7.1. Mapping of the SYNTAX clause
The SYNTAX clause, which must be present within the definition of an The SYNTAX clause, which must be present within the definition of an
attribute, defines the abstract data structure of that attribute. The attribute, defines the abstract data structure of that attribute.
data structure must be one of the following: a base type, the BITS The data structure must be one of the following: a base type, the
construct, or a textual convention. BITS construct, or a textual convention.
The SYNTAX clause must also be present for the table and row definitions The SYNTAX clause must also be present for the table and row
of a PRC, and in this case must be a SEQUENCE OF or SEQUENCE (see definitions of a PRC, and in this case must be a SEQUENCE OF or
section 8.1.7 below). SEQUENCE (see section 8.1.7 below).
The base types are an extended subset of the SMI's base types: The base types are an extended subset of the SMI's base types:
- built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER, - built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER,
- application-defined types: Integer32, Unsigned32, TimeTicks, - application-defined types: Integer32, Unsigned32, TimeTicks,
Integer64 and Unsigned64. Integer64 and Unsigned64.
A textual convention is a newly-defined type defined as a sub-type of a A textual convention is a newly-defined type defined as a sub-type of
base type [TC]. The value of an attribute whose syntax is defined using a base type [TC]. The value of an attribute whose syntax is defined
a textual convention is encoded "on-the-wire" according to the textual using a textual convention is encoded "on-the-wire" according to the
convention's underlying base type. textual convention's underlying base type.
Note that the set of base types has been chosen so as to provide 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 sufficient variety of on-the-wire encodings for attribute values;
types should contain a minimum of semantics. Semantics should, to the base types should contain a minimum of semantics. Semantics should,
extent possible, be incorporated into a data type through the use of a to the extent possible, be incorporated into a data type through the
textual convention. use of a textual convention.
The differences from the SMI in the semantics of ObjectSyntax are now The differences from the SMI in the semantics of ObjectSyntax are now
described. described.
7.1.1. Counter32 7.1.1. Counter32
The Counter32 type is not supported by the SPPI. The Counter32 type is not supported by the SPPI.
SPPI May 2001
7.1.2. Gauge32 7.1.2. Gauge32
The Gauge32 type is not supported by the SPPI. The Gauge32 type is not supported by the SPPI.
7.1.3. Opaque 7.1.3. Opaque
The Opaque type is provided solely for backward-compatibility, and shall The Opaque type is provided solely for backward-compatibility, and
not be used for newly-defined object types. The Opaque type supports the shall not be used for newly-defined object types. The Opaque type
capability to pass arbitrary ASN.1 syntax. A value is encoded using the supports the capability to pass arbitrary ASN.1 syntax. A value is
ASN.1 Basic Encoding Rules [ASN1] into a string of octets. This, in encoded using the ASN.1 Basic Encoding Rules [ASN1] into a string of
turn, is encoded as an OCTET STRING, in effect "double-wrapping" the octets. This, in turn, is encoded as an OCTET STRING, in effect
original ASN.1 value. Note that a conforming implementation need only be "double-wrapping" the original ASN.1 value. Note that a conforming
able to accept and recognize opaquely-encoded data. It need not be able implementation need only be able to accept and recognize opaquely-
to unwrap the data and then interpret its contents. A requirement on encoded data. It need not be able to unwrap the data and then
"standard" PIB modules is that no object may have a SYNTAX clause value interpret its contents. A requirement on "standard" PIB modules is
of Opaque. that no object may have a SYNTAX clause value of Opaque.
7.1.4. IpAddress 7.1.4. IpAddress
The IpAddress type is provided solely for backward-compatibility, and The IpAddress type is provided solely for backward-compatibility, and
shall not be used for newly-defined object types. Instead, It is shall not be used for newly-defined object types. Instead, It is
recommended to use the InetAddressType/InetAddress pair TCs as defined recommended to use the InetAddressType/InetAddress pair TCs as
in RFC2851 [INETADDR]. defined in RFC2851 [INETADDR].
7.1.5. Counter64 7.1.5. Counter64
The Counter64 type is not supported by the SPPI. The Counter64 type is not supported by the SPPI.
7.1.6. Integer64 7.1.6. Integer64
The Integer64 type represents integer-valued information between -2^63 The Integer64 type represents integer-valued information between
and 2^63-1 inclusive (-9223372036854775808 to 9223372036854775807 -2^63 and 2^63-1 inclusive (-9223372036854775808 to
decimal). While Integer64 may be sub-typed to be more constrained, if 9223372036854775807 decimal). While Integer64 may be sub-typed to be
the constraint results in all possible values being contained in the more constrained, if the constraint results in all possible values
range (-2147483648..2147483647), then the Integer32 type must be used being contained in the range (-2147483648..2147483647), then the
instead of Integer64. Integer32 type must be used instead of Integer64.
7.1.7. Unsigned64 7.1.7. Unsigned64
The Unsigned64 type represents integer-valued information between 0 and The Unsigned64 type represents integer-valued information between 0
2^64-1 inclusive (0 to 18446744073709551615 decimal). While Unsigned64 and 2^64-1 inclusive (0 to 18446744073709551615 decimal). While
may be sub-typed to be more constrained, if the constraint results in Unsigned64 may be sub-typed to be more constrained, if the constraint
all possible values being contained in the range (0..4294967295), then results in all possible values being contained in the range
the Unsigned32 type must be used instead of Unsigned64. (0..4294967295), then the Unsigned32 type must be used instead of
Unsigned64.
SPPI May 2001
7.1.8. Provisioning Classes 7.1.8. Provisioning Classes
The operations (on PIBs) supported by the SPPI apply exclusively to 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 PRCs. Each PRC is modelled as a tabular structure, i.e., a table.
instance of a particular PRC has the same set of attributes. The set of Each instance of a particular PRC has the same set of attributes.
attributes which belong to every instance of a particular PRC is The set of attributes which belong to every instance of a particular
modelled as a row in the table. Note that a PRC must have no more than PRC is modelled as a row in the table. Note that a PRC must have no
127 attributes. The usage of subids (for PRC attributes) beyond 127 more than 127 attributes. The usage of subids (for PRC attributes)
(that is 128 and above) is reserved for Mapping PIBs to MIBs (see beyond 127 (that is 128 and above) is reserved for Mapping PIBs to
Appendix A). PRCs that require more than 127 attributes must use the MIBs (see Appendix A). PRCs that require more than 127 attributes
AUGMENTS clause to augment the PRC containing the initial 127 attributes must use the AUGMENTS clause to augment the PRC containing the
to add additional attributes. Definition of Provisioning Classes is initial 127 attributes to add additional attributes. Definition of
formalized by using the OBJECT-TYPE macro to define both: 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 PRC as a whole, called the table definition, and
the row definition.
In the table definition, the SYNTAX clause has the form: - the characteristics of every instance of a particular PRC, called
the row definition.
SEQUENCE OF <EntryType> In the table definition, the SYNTAX clause has the form:
where <EntryType> refers to the SEQUENCE type of its attribute SEQUENCE OF <EntryType>
definitions. In the row definition, the SYNTAX clause has the form:
<EntryType> where <EntryType> refers to the SEQUENCE type of its attribute
definitions. In the row definition, the SYNTAX clause has the form:
where <EntryType> is a SEQUENCE type defined as follows: <EntryType>
<EntryType> ::= SEQUENCE { <type1>, ... , <typeN> } where <EntryType> is a SEQUENCE type defined as follows:
where there is one <type> for each attribute, and each <type> is of the <EntryType> ::= SEQUENCE { <type1>, ... , <typeN> }
form:
<descriptor> <syntax> where there is one <type> for each attribute, and each <type> is of
the form:
where <descriptor> is the descriptor naming an attribute, and <syntax> <descriptor> <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>.
SPPI May 2001 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 7.2. Mapping of the MAX-ACCESS clause
The MAX-ACCESS clause is not supported by the SPPI. The MAX-ACCESS clause is not supported by the SPPI.
7.3. Mapping of the PIB-ACCESS clause 7.3. Mapping of the PIB-ACCESS clause
The PIB-ACCESS clause must be present for a PRC's table definition, and The PIB-ACCESS clause must be present for a PRC's table definition,
must not be present for any other OBJECT-TYPE definition. The PIB- and must not be present for any other OBJECT-TYPE definition. The
ACCESS clause defines what kind of access is appropriate for the PRC. 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 - the value "install" is used to indicate a PRC which a PDP can
install in the PEP as provisioning information. install in the PEP as provisioning information.
- the value "notify" is used to indicate a PRC for which the PEP must - the value "notify" is used to indicate a PRC for which the PEP
notify the PDP of all its instances and attribute values of that must notify the PDP of all its instances and attribute values of
PRC. that PRC.
- the value "install-notify" is used to indicate the uncommon type of - the value "install-notify" is used to indicate the uncommon type
PRC which has both characteristics: "install" and "notify". of PRC which has both characteristics: "install" and "notify".
the value "report-only" is used to indicate a PRC which has neither the - the value "report-only" is used to indicate a PRC which has
"install" characteristic nor the "notify" characteristic. However, neither the "install" characteristic nor the "notify"
instances of such a PRC may be included in synchronous/asynchronous characteristic. However, instances of such a PRC may be included
reports generated by the PEP. (Note: PRCs having the "install" and/or in synchronous/asynchronous reports generated by the PEP. (Note:
"notify" characteristics may also be included in reports generated by PRCs having the "install" and/or "notify" characteristics may also
the PEP.) be included in reports generated by the PEP.)
7.4. Mapping of the INSTALL-ERRORS clause 7.4. Mapping of the INSTALL-ERRORS clause
The INSTALL-ERRORS clause, which may optionally be present for a PRC's The INSTALL-ERRORS clause, which may optionally be present for a
table definition, and must be absent otherwise, lists one or more PRC's table definition, and must be absent otherwise, lists one or
potential reasons for rejecting an install or a removal of an instance more potential reasons for rejecting an install or a removal of an
of the PRC. Each reason consists of a named-number enumeration, where instance of the PRC. Each reason consists of a named-number
the number represents a PRC-specific error-code to be used in a COPS enumeration, where the number represents a PRC-specific error-code to
protocol message, as the Error Sub-code, with the Error-Code set to be used in a COPS protocol message, as the Error Sub-code, with the
priSpecificError (see [COPS-PR]). The semantics of each named-number Error-Code set to priSpecificError (see [COPS-PR]). The semantics of
enumeration should be described in the PRC's DESCRIPTION clause. 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.
SPPI May 2001 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 7.5. Mapping of the PIB-INDEX clause
The PIB-INDEX clause, which must be present for a row definition (unless The PIB-INDEX clause, which must be present for a row definition
an AUGMENTS or an EXTENDS clause is present instead), and must be absent (unless an AUGMENTS or an EXTENDS clause is present instead), and
otherwise, defines identification information for instances of the PRC. must be absent otherwise, defines identification information for
instances of the PRC.
The PIB-INDEX clause includes exactly one descriptor. This descriptor The PIB-INDEX clause includes exactly one descriptor. This
specifies an attribute (typically, but not necessarily of the same PRC) descriptor specifies an attribute (typically, but not necessarily of
which is used to identify an instance of that PRC. The syntax of this the same PRC) which is used to identify an instance of that PRC. The
attribute is REQUIRED to be InstanceId (a textual convention with an syntax of this attribute is REQUIRED to be InstanceId (a textual
underlying syntax of Unsigned32), and it has no semantics other than its convention with an underlying syntax of Unsigned32), and it has no
use in identifying the PRC instance. The OBJECT IDENTIFIER which semantics other than its use in identifying the PRC instance. The
identifies an instance of a PRC is formed by appending one sub- OBJECT IDENTIFIER which identifies an instance of a PRC is formed by
identifier to the OID which identifies that PRC's row definition. The appending one sub- identifier to the OID which identifies that PRC's
value of the additional sub-identifier is that instance's value of the row definition. The value of the additional sub-identifier is that
attribute specified in the INDEX clause. 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 Note that SPPI does not permit use of the IMPLIED keyword in a PIB-
clause. INDEX clause.
7.6. Mapping of the INDEX clause 7.6. Mapping of the INDEX clause
The INDEX clause is optionally present if a PIB-INDEX clause is present, The INDEX clause is optionally present if a PIB-INDEX clause is
and must be absent otherwise. If present, the INDEX clause can contain present, and must be absent otherwise. If present, the INDEX clause
any number of attributes, and is used only by the algorithmic conversion can contain any number of attributes, and is used only by the
of a PIB to a MIB (see Appendix A). algorithmic conversion of a PIB to a MIB (see Appendix A).
An IMPLIED keyword can be present in an INDEX clause if so desired. An IMPLIED keyword can be present in an INDEX clause if so desired.
7.7. Mapping of the AUGMENTS clause 7.7. Mapping of the AUGMENTS clause
The AUGMENTS clause, which must not be present except in row The AUGMENTS clause, which must not be present except in row
definitions, is an alternative to the PIB-INDEX clause and the EXTENDS definitions, is an alternative to the PIB-INDEX clause and the
clause. Every row definition has exactly one of: a PIB-INDEX clause, an EXTENDS clause. Every row definition has exactly one of: a PIB-INDEX
AUGMENTS clause, or an EXTENDS clause. 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 A row definition which has a PIB-INDEX clause is called a base row
PRC. Instances of an augmenting PRC are identified according to the definition. A row definition which has an AUGMENTS clause is called
PIB-INDEX clause of the base row definition named in the AUGMENTS a row augmentation, where the AUGMENTS clause names the base row
SPPI May 2001 definition which is augmented by this row augmentation. (Thus, a row
augmentation cannot itself be augmented.)
clause. Further, instances of an augmenting PRC exist according to the A PRC whose row definition is a row augmentation is called an
same semantics as instances of the PRC which it augments. As such, when augmenting PRC. Instances of an augmenting PRC are identified
an instance of a PRC is installed or removed, an instance of every PRC according to the PIB-INDEX clause of the base row definition named in
which augments it is also installed or removed. (for more details, see the AUGMENTS clause. Further, instances of an augmenting PRC exist
[COPS-PR]). 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 7.8. Mapping of the EXTENDS clause
The EXTENDS clause, which must not be present except in row definitions, The EXTENDS clause, which must not be present except in row
is an alternative to the PIB-INDEX clause and the AUGMENTS clause. definitions, is an alternative to the PIB-INDEX clause and the
Every row definition has exactly one of: a PIB-INDEX clause, an AUGMENTS AUGMENTS clause. Every row definition has exactly one of: a PIB-
clause, or an EXTENDS clause. INDEX clause, an AUGMENTS clause, or an EXTENDS clause.
A row definition which has an EXTENDS clause is called a sparse row A row definition which has an EXTENDS clause is called a sparse row
augmentation, where the EXTENDS clause names the row definition which is augmentation, where the EXTENDS clause names the row definition which
sparsely-augmented by this sparse row augmentation. The sparsely- is sparsely-augmented by this sparse row augmentation. The sparsely-
augmented row can be a base row definition, or another sparse row augmented row can be a base row definition, or another sparse row
augmentation. augmentation.
A PRC whose row definition is a sparse row augmentation is called a A PRC whose row definition is a sparse row augmentation is called a
sparsely augmenting PRC. Instances of a sparsely augmenting PRC are sparsely augmenting PRC. Instances of a sparsely augmenting PRC are
identified according to the PIB-INDEX clause of the row definition named identified according to the PIB-INDEX clause of the row definition
in the sparsely augmenting PRC's EXTENDS clause. named in the sparsely augmenting PRC's EXTENDS clause.
An instance of a sparsely augmenting PRC can not exist unless a An instance of a sparsely augmenting PRC can not exist unless a
corresponding instance of the PRC which it sparsely augments exists. As corresponding instance of the PRC which it sparsely augments exists.
such, when an instance of a PRC is removed, an instance of any PRC which As such, when an instance of a PRC is removed, an instance of any PRC
sparsely augments it is also removed. However, an instance of a which sparsely augments it is also removed. However, an instance of
sparsely augmenting PRC need not exist when the corresponding instance a sparsely augmenting PRC need not exist when the corresponding
of the PRC that it sparsely augments exists. Thus, an instance of a instance of the PRC that it sparsely augments exists. Thus, an
sparsely augmenting PRC can be installed at the same time as or instance of a sparsely augmenting PRC can be installed at the same
subsequent to the installation of, and can be removed prior to the time as or subsequent to the installation of, and can be removed
removal of, the corresponding instance of the PRC that it sparsely prior to the removal of, the corresponding instance of the PRC that
augments. So, instances of a sparsely augmenting PRC must be installed it sparsely augments. So, instances of a sparsely augmenting PRC
explicitly, but are removed either implicitly (via removal of the must be installed explicitly, but are removed either implicitly (via
augmented PRI) or explicitly. When a sparsely augmented PRC is removal of the augmented PRI) or explicitly. When a sparsely
installed, both instances, the instance of the sparsely augmented PRC augmented PRC is installed, both instances, the instance of the
and the instance of the sparsely augmenting PRC must be sent in one COPS sparsely augmented PRC and the instance of the sparsely augmenting
message.x PRC must be sent in one COPS message.
7.8.1. Relation between PIB-INDEX, AUGMENTS and EXTENDS clauses 7.8.1. Relation between PIB-INDEX, AUGMENTS and EXTENDS clauses
When defining instance identification information for a PRC: When defining instance identification information for a PRC:
SPPI May 2001
- If there is a one-to-one correspondence between instances of this - If there is a one-to-one correspondence between instances of this
PRC and instances of an existing PRC, then the AUGMENTS clause PRC and instances of an existing PRC, then the AUGMENTS clause
should be used. should be used.
- Otherwise, if there is a sparse relationship between instances of - Otherwise, if there is a sparse relationship between instances of
this PRC and instances of an existing PRC (that is, there is a one this PRC and instances of an existing PRC (that is, there is a one
to zero or one correspondence between instances of a sparsely to zero or one correspondence between instances of a sparsely
augmented PRC and the instances of the PRC that sparsely augments augmented PRC and the instances of the PRC that sparsely augments
it.), then an EXTENDS clause should be used. it.), then an EXTENDS clause should be used.
- Otherwise, a PIB-INDEX clause should be used which names its own - Otherwise, a PIB-INDEX clause should be used which names its own
InstanceId attribute. InstanceId attribute.
7.9. Mapping of the UNIQUENESS clause 7.9. Mapping of the UNIQUENESS clause
The UNIQUENESS clause, which is optionally present for any row The UNIQUENESS clause, which is optionally present for any row
definition, lists a set of zero or more of the PRC's attributes, for 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 which no two instances of the PRC can have the same set of values.
specified set of attributes provide a necessary and sufficient set of The specified set of attributes provide a necessary and sufficient
values by which to identify an instance of this PRC. The attribute set of values by which to identify an instance of this PRC. The
contained in the PIB-INDEX clause may not be present in the UNIQUENESS attribute contained in the PIB-INDEX clause may not be present in the
clause. By definition, an attribute may not appear more than once in a UNIQUENESS clause. By definition, an attribute may not appear more
UNIQUENESS clause. A UNIQUENESS clause containing zero attributes than once in a UNIQUENESS clause. A UNIQUENESS clause containing
indicates that it's possible for two instances of the PRC to have zero attributes indicates that it's possible for two instances of the
identical values for all attributes except, of course, for the one named PRC to have identical values for all attributes except, of course,
in the PIB-INDEX clause. for the one named in the PIB-INDEX clause.
If a PRC and its sparsely augmenting PRC both have UNIQUENESS clauses, If a PRC and its sparsely augmenting PRC both have UNIQUENESS
then the UNIQUENESS constraint for instances of each PRC MUST be applied clauses, then the UNIQUENESS constraint for instances of each PRC
according to the UNIQUENESS clause in the corresponding PRC definition. MUST be applied according to the UNIQUENESS clause in the
Note that a sparsely augmenting PRC thus can override the UNIQUENESS corresponding PRC definition. Note that a sparsely augmenting PRC
clause of the PRC it sparsely augments. thus can override the UNIQUENESS clause of the PRC it sparsely
augments.
Even though the UNIQUENESS clause is optional, its inclusion is Even though the UNIQUENESS clause is optional, its inclusion is
recommended wherever it provides useful information. recommended wherever it provides useful information.
7.10. Mapping of the PIB-REFERENCES clause 7.10. Mapping of the PIB-REFERENCES clause
The PIB-REFERENCES clause, which must be present for any attribute which The PIB-REFERENCES clause, which must be present for any attribute
has the SYNTAX of ReferenceId, and must be absent otherwise, names the which has the SYNTAX of ReferenceId, and must be absent otherwise,
PRC, an instance of which is referenced by the ReferenceId attribute. names the PRC, an instance of which is referenced by the ReferenceId
For example usages of the PIB-REFERENCES clause, see Appendix B. attribute. For example usages of the PIB-REFERENCES clause, see
Appendix B.
SPPI May 2001
7.11. Mapping of the PIB-TAG clause 7.11. Mapping of the PIB-TAG clause
The PIB-TAG clause, which must be present for an attribute which has the The PIB-TAG clause, which must be present for an attribute which has
SYNTAX TagReferenceId, and must be absent otherwise, is used to indicate the SYNTAX TagReferenceId, and must be absent otherwise, is used to
that this attribute references a "tag list" of instances of another PRC. indicate that this attribute references a "tag list" of instances of
Such a tag list (similar in concept to the usage of the same term in another PRC. Such a tag list (similar in concept to the usage of the
[APPL]) is formed by all instances of the other PRC which have the same same term in [APPL]) is formed by all instances of the other PRC
(tag) value of a particular attribute of that other PRC. The particular which have the same (tag) value of a particular attribute of that
attribute of the other PRC, which must have the SYNTAX TagId, is named other PRC. The particular attribute of the other PRC, which must
in the PIB-TAG clause. For an example usage of the PIB-TAG clause, see have the SYNTAX TagId, is named in the PIB-TAG clause. For an
Appendix B. example usage of the PIB-TAG clause, see Appendix B.
8. Mapping of the OBJECT-IDENTITY macro 8. Mapping of the OBJECT-IDENTITY macro
The OBJECT-IDENTITY macro is used in PIB modules to define information The OBJECT-IDENTITY macro is used in PIB modules to define
about an OBJECT IDENTIFIER assignment. information about an OBJECT IDENTIFIER assignment.
9. Mapping of the OBJECT-GROUP macro 9. Mapping of the OBJECT-GROUP macro
For conformance purposes, it is useful to define a conformance group as For conformance purposes, it is useful to define a conformance group
a collection of related PRCs and their attributes. The OBJECT-GROUP as a collection of related PRCs and their attributes. The OBJECT-
macro (directly) defines the collection of attributes which belong to a GROUP macro (directly) defines the collection of attributes which
conformance group. Since each attribute included in the collection belong to a conformance group. Since each attribute included in the
belongs to a PRC, the collection of related PRCs which belong to a collection belongs to a PRC, the collection of related PRCs which
conformance group is also specified (indirectly) as the set of PRCs to belong to a conformance group is also specified (indirectly) as the
which the included attributes belong. set of PRCs to which the included attributes belong.
9.1. Mapping of the OBJECTS clause 9.1. Mapping of the OBJECTS clause
The OBJECTS clause, which must be present, is used to specify each The OBJECTS clause, which must be present, is used to specify each
attribute contained in the conformance group. Each of the specified attribute contained in the conformance group. Each of the specified
attributes must be defined in the same PIB module as the OBJECT-GROUP attributes must be defined in the same PIB module as the OBJECT-GROUP
macro appears. 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.
SPPI May 2001 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 10. Mapping of the MODULE-COMPLIANCE macro
The MODULE-COMPLIANCE macro is used to convey a minimum set of The MODULE-COMPLIANCE macro is used to convey a minimum set of
requirements with respect to implementation of one or more PIB modules. requirements with respect to implementation of one or more PIB
modules.
A requirement on all "standard" PIB modules is that a corresponding A requirement on all "standard" PIB modules is that a corresponding
MODULE-COMPLIANCE specification is also defined, either in the same MODULE-COMPLIANCE specification is also defined, either in the same
module or in a companion module. module or in a companion module.
10.1. Mapping of the MODULE clause 10.1. Mapping of the MODULE clause
The MODULE clause, which must be present, is repeatedly used to name 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 for which compliance requirements are being
Each PIB module is named by its module name, and optionally, by its specified. Each PIB module is named by its module name, and
associated OBJECT IDENTIFIER as well. The module name can be omitted optionally, by its associated OBJECT IDENTIFIER as well. The module
when the MODULE-COMPLIANCE invocation occurs inside a PIB module, to name can be omitted when the MODULE-COMPLIANCE invocation occurs
refer to the encompassing PIB module. inside a PIB module, to refer to the encompassing PIB module.
10.1.1. Mapping of the MANDATORY-GROUPS clause 10.1.1. Mapping of the MANDATORY-GROUPS clause
The MANDATORY-GROUPS clause, which need not be present, names the one or The MANDATORY-GROUPS clause, which need not be present, names the one
more conformance groups within the correspondent PIB module which are or more conformance groups within the correspondent PIB module which
unconditionally mandatory for implementation. If an agent claims are unconditionally mandatory for implementation. If an agent claims
compliance to the PIB module, then it must implement each and every compliance to the PIB module, then it must implement each and every
attribute (and therefore the PRCs to which they belong) within each attribute (and therefore the PRCs to which they belong) within each
conformance group listed. conformance group listed.
10.1.2. Mapping of the GROUP clause 10.1.2. Mapping of the GROUP clause
The GROUP clause, which need not be present, is repeatedly used to name The GROUP clause, which need not be present, is repeatedly used to
each conformance group which is conditionally mandatory for compliance name each conformance group which is conditionally mandatory for
to the PIB module. The GROUP clause can also be used to name compliance to the PIB module. The GROUP clause can also be used to
unconditionally optional groups. A group named in a GROUP clause must name unconditionally optional groups. A group named in a GROUP
be absent from the correspondent MANDATORY-GROUPS clause. 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 Conditionally mandatory groups include those which are mandatory only
clause, is unconditionally optional for compliance to the PIB module. 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.
SPPI May 2001 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 10.1.3. Mapping of the OBJECT clause
The OBJECT clause, which need not be present, is repeatedly used to The OBJECT clause, which need not be present, is repeatedly used to
specify each attribute for which compliance has a refined requirement specify each attribute for which compliance has a refined requirement
with respect to the PIB module definition. The attribute must be with respect to the PIB module definition. The attribute must be
present in one of the conformance groups named in the correspondent present in one of the conformance groups named in the correspondent
MANDATORY-GROUPS clause or GROUP clauses. MANDATORY-GROUPS clause or GROUP clauses.
By definition, each attribute specified in an OBJECT clause follows a By definition, each attribute specified in an OBJECT clause follows a
MODULE clause which names the PIB module in which that attribute is MODULE clause which names the PIB module in which that attribute is
defined. Therefore, the use of an IMPORTS statement, to specify from defined. Therefore, the use of an IMPORTS statement, to specify from
where such attributes are imported, is redundant and is not required in where such attributes are imported, is redundant and is not required
a PIB module. in a PIB module.
10.1.3.1. Mapping of the SYNTAX clause 10.1.3.1. Mapping of the SYNTAX clause
The SYNTAX clause, which need not be present, is used to provide a The SYNTAX clause, which need not be present, is used to provide a
refined SYNTAX for the attribute named in the correspondent OBJECT refined SYNTAX for the attribute named in the correspondent OBJECT
clause. The refined syntax is the minimum level of support needed for clause. The refined syntax is the minimum level of support needed
this attribute in order to be compliant. for this attribute in order to be compliant.
10.1.3.2. Mapping of the WRITE-SYNTAX clause 10.1.3.2. Mapping of the WRITE-SYNTAX clause
The WRITE-SYNTAX clause is not supported by the SPPI. The WRITE-SYNTAX clause is not supported by the SPPI.
10.1.3.3. Mapping of the PIB-MIN-ACCESS clause 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 PIB-MIN-ACCESS clause, which need not be present, is used to
the minimal level of access for the attribute named in the correspondent define the minimal level of access for the attribute named in the
OBJECT clause. If this clause is absent, the minimal level of access is correspondent OBJECT clause. If this clause is absent, the minimal
the same as the maximal level specified in the PIB-ACCESS clause of the level of access is the same as the maximal level specified in the
correspondent invocation of the OBJECT-TYPE macro. If present, this PIB-ACCESS clause of the correspondent invocation of the OBJECT-TYPE
clause must specify a subset of the access specified in the macro. If present, this clause must specify a subset of the access
correspondent PIB-ACCESS clause, where: "install" is a subset of specified in the correspondent PIB-ACCESS clause, where: "install" is
"install-notify", "notify" is a subset of "install-notify", and "not- a subset of "install-notify", "notify" is a subset of "install-
accessible" is a subset of all other values. 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.
SPPI May 2001 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 11. Textual Conventions
When designing a PIB module, it is often useful to define new data types When designing a PIB module, it is often useful to define new data
similar to those defined in the SPPI. In comparison to a type defined types similar to those defined in the SPPI. In comparison to a type
in the SPPI, each of these new types has a different name, a similar defined in the SPPI, each of these new types has a different name, a
syntax, and specific semantics. These newly defined types are termed similar syntax, and specific semantics. These newly defined types
textual conventions, and are used for the convenience of humans reading are termed textual conventions, and are used for the convenience of
the PIB module. humans reading the PIB module.
Attributes defined using a textual convention are always encoded by Attributes defined using a textual convention are always encoded by
means of the rules that define their underlying type. means of the rules that define their underlying type.
11.1. Mapping of the TEXTUAL-CONVENTION macro 11.1. Mapping of the TEXTUAL-CONVENTION macro
The TEXTUAL-CONVENTION macro is used to convey the syntax and semantics The TEXTUAL-CONVENTION macro is used to convey the syntax and
associated with a textual convention. It should be noted that the semantics associated with a textual convention. It should be noted
expansion of the TEXTUAL-CONVENTION macro is something which that the expansion of the TEXTUAL-CONVENTION macro is something which
conceptually happens during implementation and not during run-time. conceptually happens during implementation and not during run-time.
The name of a textual convention must consist of one or more letters or The name of a textual convention must consist of one or more letters
digits, with the initial character being an upper case letter. The name or digits, with the initial character being an upper case letter.
must not conflict with any of the reserved words listed in section 5.2, The name must not conflict with any of the reserved words listed in
should not consist of all upper case letters, and shall not exceed 64 section 5.2, should not consist of all upper case letters, and shall
characters in length. (However, names longer than 32 characters are not not exceed 64 characters in length. (However, names longer than 32
recommended.) The hyphen is not allowed in the name of a textual characters are not recommended.) The hyphen is not allowed in the
convention (except for use in information modules converted from SMIv1 name of a textual convention (except for use in information modules
which allowed hyphens in ASN.1 type assignments). Further, all names converted from SMIv1 which allowed hyphens in ASN.1 type
used for the textual conventions defined in all "standard" PIB modules assignments). Further, all names used for the textual conventions
shall be unique. defined in all "standard" PIB modules shall be unique.
11.1.1. Mapping of the DISPLAY-HINT clause 11.1.1. Mapping of the DISPLAY-HINT clause
The DISPLAY-HINT clause, which need not be present, gives a hint as to The DISPLAY-HINT clause, which need not be present, gives a hint as
how the value of an instance of an object with the syntax defined using to how the value of an instance of an object with the syntax defined
this textual convention might be displayed. The DISPLAY-HINT clause must using this textual convention might be displayed. The DISPLAY-HINT
not be present if the Textual Convention is defined with a syntax of: clause must not be present if the Textual Convention is defined with
OBJECT IDENTIFIER, or any enumerated syntax (BITS or INTEGER). The a syntax of: OBJECT IDENTIFIER, or any enumerated syntax (BITS or
determination of whether it makes sense for other syntax types is INTEGER). The determination of whether it makes sense for other
dependent on the specific definition of the Textual Convention. 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].
SPPI May 2001 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 11.1.2. Mapping of the SYNTAX clause
The SYNTAX clause, which must be present, defines abstract data The SYNTAX clause, which must be present, defines abstract data
structure corresponding to the textual convention. The data structure structure corresponding to the textual convention. The data
must be one of the following: a base type (see the SYNTAX clause of an structure must be one of the following: a base type (see the SYNTAX
OBJECT-TYPE macro), or the BITS construct. Note that this means that clause of an OBJECT-TYPE macro), or the BITS construct. Note that
the SYNTAX clause of a Textual Convention can not refer to a previously this means that the SYNTAX clause of a Textual Convention can not
defined Textual Convention. refer to a previously defined Textual Convention.
11.1.2.1. Sub-typing of Textual Conventions 11.1.2.1. Sub-typing of Textual Conventions
The SYNTAX clause of a TEXTUAL CONVENTION macro may be sub-typed in the The SYNTAX clause of a TEXTUAL CONVENTION macro may be sub-typed in
same way as the SYNTAX clause of an OBJECT-TYPE macro. the same way as the SYNTAX clause of an OBJECT-TYPE macro.
12. Extending a PIB Module 12. Extending a PIB Module
PIBs may be revised as implementation experience is gained. However, PIBs may be revised as implementation experience is gained. However,
changes with potential to cause disruption to interoperability between changes with potential to cause disruption to interoperability
the previous PIB and the revised PIB are not allowed. between the previous PIB and the revised PIB are not allowed.
12.1. PIB Modules 12.1. PIB Modules
For any change, the invocation of the MODULE-IDENTITY macro must be For any change, the invocation of the MODULE-IDENTITY macro must be
updated to include information about the revision: specifically, updated to include information about the revision: specifically,
updating the LAST-UPDATED clause, adding a pair of REVISION and updating the LAST-UPDATED clause, adding a pair of REVISION and
DESCRIPTION clauses, and making any necessary changes to existing DESCRIPTION clauses, and making any necessary changes to existing
clauses, including the ORGANIZATION and CONTACT-INFO clauses. 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 Note that any definition contained in an existing PIB is available to
since their descriptors may still be referenced by other PIB modules, be IMPORT-ed by any other PIB, and is referenced in an IMPORTS clause
and the OBJECT IDENTIFIERs used to name them must never be re-assigned. via the PIB module name. Thus, a PIB module name should not be
The EXTENDS/AUGMENTS clause should be used to extend previous changed. Definitions should not be moved from one PIB to another.
definitions depending on the information to be represented.
Changes to an existing PIB can be made in several ways: 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.
- Additional PRCs can be added to a PIB or an existing one Changes to an existing PIB can be made in several ways:
deprecated.
SPPI May 2001 - Additional PRCs can be added to a PIB or an existing one
deprecated.
- Attributes can be added to, or deprecated from, an existing PRC. - 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 Note that an ASN.1 value of the correct type or an ASN.1 NULL
must be sent even for deprecated attributes to mantain value must be sent even for deprecated attributes to maintain
interoperability. New attributes must be added in sequence after interoperability. New attributes must be added in sequence after
the existing ones. the existing ones.
- An existing PRC can be extended or augmented with a new PRC defined - An existing PRC can be extended or augmented with a new PRC
in another (perhaps enterprise specific) PIB. defined in another (perhaps enterprise specific) PIB.
Additional named-number enumerations may be added to a SUBJECT- Additional named-number enumerations may be added to a SUBJECT-
CATEGORIES clause. CATEGORIES clause.
12.2. Object Assignments 12.2. Object Assignments
If any non-editorial change is made to any clause of a object If any non-editorial change is made to any clause of a object
assignment, then the OBJECT IDENTIFIER value associated with that object assignment, then the OBJECT IDENTIFIER value associated with that
assignment must also be changed, along with its associated descriptor. object assignment must also be changed, along with its associated
Note that the max subid for PRC attributes is 127 (See Section 7.1.8) descriptor. Note that the max subid for PRC attributes is 127 (See
Section 7.1.8)
12.3. Object Definitions 12.3. Object Definitions
An object definition may be revised in any of the following ways: 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 - A SYNTAX clause containing an enumerated INTEGER may have new
DESCRIPTION clause. enumerations added or existing labels changed. Similarly, named
bits may be added or existing labels changed for the BITS
construct.
- An INSTALL-ERRORS clause may be added or an existing INSTALL-ERRORS - The value of a SYNTAX clause may be replaced by a textual
clause have additional errors defined. 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.
SPPI May 2001 - A UNITS clause may be added.
- A REFERENCE clause may be added or updated. - 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.
- A DEFVAL clause may be added or updated. - Clarifications and additional information may be included in the
DESCRIPTION clause.
- A PRC may be augmented by adding new objects at the end of the row, - An INSTALL-ERRORS clause may be added or an existing INSTALL-
and making the corresponding update to the SEQUENCE definition. ERRORS clause have additional errors defined.
- Entirely new objects may be defined, named with previously - A REFERENCE clause may be added or updated.
unassigned OBJECT IDENTIFIER values.
Otherwise, if the semantics of any previously defined object are changed - A DEFVAL clause may be added or updated.
(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 - A PRC may be augmented by adding new objects at the end of the
considered a semantic change, as these strings may be used in an IMPORTS row, and making the corresponding update to the SEQUENCE
statement. definition.
SPPI May 2001 - Entirely new objects may be defined, named with previously
unassigned OBJECT IDENTIFIER values.
13. Appendix A: Mapping a PIB to a MIB 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.
Since the SPPI is modelled on the SMI, a PIB can be potentially Appendix A: Mapping a PIB to a MIB
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. 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:
- Change the OID assigned to the MODULE-IDENTITY to be different - Modify the module's module name by appending "-MIB" to the name.
value.
- Replace the keyword PIB-DEFINITIONS with the keyword DEFINITIONS. - Change the OID assigned to the MODULE-IDENTITY to be different
value.
- Modify the module names of all external references to PIB modules - Replace the keyword PIB-DEFINITIONS with the keyword DEFINITIONS.
by appending "-MIB" to each such module name.
- For each PRC definition, if an INDEX clause is absent, change the - Modify the module names of all external references to PIB modules
"PIB-INDEX" keyword to "INDEX"; otherwise, delete the PIB-INDEX by appending "-MIB" to each such module name.
clause.
- Delete all of the following clauses: PIB-ACCESS, PIB-REFERENCES, - For each PRC definition, if an INDEX clause is absent, change the
PIB-TAG, UNIQUENESS, INSTALL-ERRORS, and SUBJECT-CATEGORIES. "PIB-INDEX" keyword to "INDEX"; otherwise, delete the PIB-INDEX
clause.
- Change all PIB-MIN-ACCESS clauses to MIN-ACCESS clauses, modifying - Delete all of the following clauses: PIB-ACCESS, PIB-REFERENCES,
"install" and "install-notify" to "read-create", and "notify" to PIB-TAG, UNIQUENESS, INSTALL-ERRORS, and SUBJECT-CATEGORIES.
"read-only".
- Add a MAX-ACCESS clause for each OBJECT-TYPE. For each table - Change all PIB-MIN-ACCESS clauses to MIN-ACCESS clauses, modifying
definition and row definition, the MAX-ACCESS is "not-accessible". "install" and "install-notify" to "read-create", and "notify" to
For each attribute that is in the INDEX clause, the MAX-ACCESS is "read-only".
"not-accessible". For the remaining attributes, the MAX-ACCESS is
"read-create".
- Add a columnar attribute of type RowStatus with a descriptor and - Add a MAX-ACCESS clause for each OBJECT-TYPE. For each table
appropriate DESCRIPTION. The descriptor can be formed by appending definition and row definition, the MAX-ACCESS is "not-accessible".
the nine characters "RowStatus" to the end of the PRC's descriptor For each attribute that is in the INDEX clause, the MAX-ACCESS is
(truncated if necessary to avoid the resulting descriptor being too "not-accessible". For the remaining attributes, the MAX-ACCESS is
long). A Subid beyond 127 (i.e., 128 and above) can be used as the "read-create".
OID for this columnar attribute.
- Modify any SYNTAX clause which has a base data type which is not - Add a columnar attribute of type RowStatus with a descriptor and
allowed in the SMI, either to be a valid SMI data type or to omit appropriate DESCRIPTION. The descriptor can be formed by
the OBJECT-TYPE or TEXTUAL-CONVENTION definition and all references appending the nine characters "RowStatus" to the end of the PRC's
to it. Since it is not clear (at this time) which is the best SMI descriptor (truncated if necessary to avoid the resulting
data type to use, the conversion SHOULD provide a configurable descriptor being too long). A Subid beyond 127 (i.e., 128 and
SPPI May 2001 above) can be used as the OID for this columnar attribute.
option allowing a choice from at least the following: - 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. - convert to an OCTET STRING of the relevant size. Specifically,
Specifically, this option would map both Integer64 and this option would map both Integer64 and Unsigned64 to OCTET
Unsigned64 to OCTET STRING (SIZE(8)), or STRING (SIZE(8)), or
- omit them from the conversion, or - omit them from the conversion, or
- map Integer64 and Unsigned64 to Counter64 (even though this - map Integer64 and Unsigned64 to Counter64 (even though this has
has problems representing negative numbers, and unwanted problems representing negative numbers, and unwanted counter
counter semantics.) semantics.)
SPPI May 2001
14. Appendix B: Example usage of PIB-REFERENCES and PIB-TAG clauses Appendix B: Example usage of PIB-REFERENCES and PIB-TAG clauses
The following example demonstrates the use of the PIB-REFERENCES and The following example demonstrates the use of the PIB-REFERENCES and
PIB-TAG clauses. PIB-TAG clauses.
In this example, the PIB-REFERENCES clause is used by the In this example, the PIB-REFERENCES clause is used by the
qosIfDscpMapQueue attribute to indicate the PRC of which it references qosIfDscpMapQueue attribute to indicate the PRC of which it
an instance, and similarly, by the qosIfDscpMapThresh attribute. references an instance, and similarly, by the qosIfDscpMapThresh
attribute.
The qosIfDscpMapTable PRC has an instance for each DSCP of a particular The qosIfDscpMapTable PRC has an instance for each DSCP of a
"map", but there is no PRC defined for a map itself; rather, a map particular "map", but there is no PRC defined for a map itself;
consists of all instances of qosIfDscpMapTable which have the same value rather, a map consists of all instances of qosIfDscpMapTable which
of qosIfDscpMapMapId. That is, a tag list is formed by all instances of have the same value of qosIfDscpMapMapId. That is, a tag list is
qosIfDscpMapTable which have the same value of qosIfDscpMapMapId. This formed by all instances of qosIfDscpMapTable which have the same
tag list is referenced by the attribute qosIfDscpAssignDscpMap, and its value of qosIfDscpMapMapId. This tag list is referenced by the
use of the PIB-TAG clause indicates this. attribute qosIfDscpAssignDscpMap, and its use of the PIB-TAG clause
indicates this.
qosIfDscpAssignTable OBJECT-TYPE qosIfDscpAssignTable OBJECT-TYPE
SYNTAX SEQUENCE OF QosIfDscpAssignEntry SYNTAX SEQUENCE OF QosIfDscpAssignEntry
PIB-ACCESS install PIB-ACCESS install
STATUS current STATUS current
DESCRIPTION " " DESCRIPTION " "
::= { qosIfParameters 9 } ::= { qosIfParameters 9 }
qosIfDscpAssignEntry OBJECT-TYPE qosIfDscpAssignEntry OBJECT-TYPE
SYNTAX QosIfDscpAssignEntry SYNTAX QosIfDscpAssignEntry
skipping to change at page 36, line 4 skipping to change at page 34, line 13
qosIfDscpAssignName SnmpAdminString, qosIfDscpAssignName SnmpAdminString,
qosIfDscpAssignRoles RoleCombination, qosIfDscpAssignRoles RoleCombination,
qosIfDscpAssignDscpMap TagReferenceId qosIfDscpAssignDscpMap TagReferenceId
} }
qosIfDscpAssignDscpMap OBJECT-TYPE qosIfDscpAssignDscpMap OBJECT-TYPE
SYNTAX TagReferenceId SYNTAX TagReferenceId
PIB-TAG { qosIfDscpMapMapId } -- attribute defined below PIB-TAG { qosIfDscpMapMapId } -- attribute defined below
STATUS current STATUS current
DESCRIPTION DESCRIPTION
SPPI May 2001
"The DSCP map which is applied to interfaces of type "The DSCP map which is applied to interfaces of type
qosIfDscpAssignName which have a role combination of qosIfDscpAssignName which have a role combination of
qosIfDscpAssignRoles." qosIfDscpAssignRoles."
::= { qosIfDscpAssignEntry 3 } ::= { qosIfDscpAssignEntry 3 }
-- --
-- DSCP to Queue and Threshold Mapping Table -- DSCP to Queue and Threshold Mapping Table
-- --
qosIfDscpMapTable OBJECT-TYPE qosIfDscpMapTable OBJECT-TYPE
skipping to change at page 37, line 4 skipping to change at page 35, line 10
qosIfDscpMapMapId OBJECT-TYPE qosIfDscpMapMapId OBJECT-TYPE
SYNTAX TagId SYNTAX TagId
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An integer that identifies the DSCP map to which this PRI "An integer that identifies the DSCP map to which this PRI
belongs." belongs."
::= { qosIfDscpMapEntry 2 } ::= { qosIfDscpMapEntry 2 }
qosIfDscpMapQueue OBJECT-TYPE qosIfDscpMapQueue OBJECT-TYPE
SPPI May 2001
SYNTAX ReferenceId SYNTAX ReferenceId
PIB-REFERENCES { qosIfQueueEntry } PIB-REFERENCES { qosIfQueueEntry }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This attribute maps the DSCP specified by qosIfDscpMapDscp to "This attribute maps the DSCP specified by qosIfDscpMapDscp to
the queue identified by qosIfQueuePrid in qosIfQueueTable. the queue identified by qosIfQueuePrid in qosIfQueueTable.
For a given DSCP map, all the queues must belong to a single For a given DSCP map, all the queues must belong to a single
queue set." queue set."
::= { qosIfDscpMapEntry 4 } ::= { qosIfDscpMapEntry 4 }
skipping to change at page 38, line 4 skipping to change at page 35, line 31
SYNTAX ReferenceId SYNTAX ReferenceId
PIB-REFERENCES { qosIfThresholdEntry } PIB-REFERENCES { qosIfThresholdEntry }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This attribute maps the DSCP specified by qosIfDscpMapDscp to "This attribute maps the DSCP specified by qosIfDscpMapDscp to
the threshold identified by qosIfThresholdId in the threshold identified by qosIfThresholdId in
qosIfThresholdTable. The threshold set to which this qosIfThresholdTable. The threshold set to which this
threshold belongs must be assigned to the queue specified by threshold belongs must be assigned to the queue specified by
qosIfDscpMapQueue." qosIfDscpMapQueue."
::= { qosIfDscpMapEntry 5 } ::= { qosIfDscpMapEntry 5 }
SPPI May 2001
15. Security Considerations Security Considerations
This document defines a language with which to define provisioning This document defines a language with which to define provisioning
information. The language itself has no security impact on the information. The language itself has no security impact on the
Internet. Internet.
16. IANA Considerations IANA Considerations
The root of the subtree administered by the Internet Assigned Numbers The root of the subtree administered by the Internet Assigned Numbers
Authority (IANA) for the Internet is: Authority (IANA) for the Internet is:
internet OBJECT IDENTIFIER ::= { iso 3 6 1 } internet OBJECT IDENTIFIER ::= { iso 3 6 1 }
That is, the Internet subtree of OBJECT IDENTIFIERs starts with the That is, the Internet subtree of OBJECT IDENTIFIERs starts with the
prefix: prefix:
1.3.6.1. 1.3.6.1.
Several branches underneath this subtree are used for network Several branches underneath this subtree are used for network
management: management:
mgmt OBJECT IDENTIFIER ::= { internet 2 } mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 } experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 } private OBJECT IDENTIFIER ::= { internet 4 }
enterprises OBJECT IDENTIFIER ::= { private 1 } enterprises OBJECT IDENTIFIER ::= { private 1 }
The mgmt(2) subtree is used to identify "standard" objects. The mgmt(2) subtree is used to identify "standard" objects.
This document defines This document defines
pib OBJECT IDENTIFIER ::= { mgmt 2 } pib OBJECT IDENTIFIER ::= { mgmt 2 }
as the root for PIBs defined to be carried over [COPS-PR]. This Object as the root for PIBs defined to be carried over [COPS-PR]. This
Identifier is a high level assignment that needs to be registered with Object Identifier is a high level assignment that needs to be
[IANA]. Root Object Identifiers for future "standards track" PIBs will registered with [IANA]. Root Object Identifiers for future "standards
also need to be registered and MUST use Object Identifiers below this track" PIBs will also need to be registered and MUST use Object
oid. A standards track PIB can only be assigned an OID by IANA if the Identifiers below this oid. A standards track PIB can only be
PIB is approved by the IESG as a "standards track" document. assigned an OID by IANA if the PIB is approved by the IESG as a
Experimental and enterprise PIBs MUST be defined under the "standards track" document. Experimental and enterprise PIBs MUST be
"experimental" and "enterprises" Object Identifiers respectively. defined under the "experimental" and "enterprises" Object Identifiers
respectively.
The PIB module "copsPrSppiTc" is defined in this document as a standard The PIB module "copsPrSppiTc" is defined in this document as a
module and hence, needs a subid assignment under the "pib" oid from standard module and hence, needs a subid assignment under the "pib"
IANA. oid from IANA.
SPPI May 2001 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.
SPPI SUBJECT-CATEGORIES are mapped to COPS Client Types. IANA Authors' Addresses
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.
17. Authors' Addresses Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706 USA
Keith McCloghrie Phone: +1 408 526 5260
Cisco Systems, Inc. Email: kzm@cisco.com
170 West Tasman Drive
San Jose, CA 95134-1706 USA
Phone: +1 408 526 5260
Email: kzm@cisco.com
Michael Fine Michael Fine
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134-1706 USA San Jose, CA 95134-1706 USA
Phone: +1 408 527 8218
Email: mfine@cisco.com
John Seligson Phone: +1 408 527 8218
Nortel Networks, Inc. EMail: mfine@cisco.com
4401 Great America Parkway
Santa Clara, CA 95054 USA
Phone: +1 408 495 2992
Email: jseligso@nortelnetworks.com
Kwok Ho Chan John Seligson
Nortel Networks, Inc. Nortel Networks, Inc.
600 Technology Park Drive 4401 Great America Parkway
Billerica, MA 01821 USA Santa Clara, CA 95054 USA
Phone: +1 978 288 8175
Email: khchan@nortelnetworks.com
Scott Hahn Phone: +1 408 495 2992
Intel EMail: jseligso@nortelnetworks.com
2111 NE 25th Avenue
Hillsboro, OR 97124 USA
Phone: +1 503 264 8231
Email: scott.hahn@intel.com
SPPI May 2001
Ravi Sahita Kwok Ho Chan
Intel Nortel Networks, Inc.
2111 NE 25th Avenue 600 Technology Park Drive
Hillsboro, OR 97124 USA Billerica, MA 01821 USA
Phone: +1 503 712 1554
Email: ravi.sahita@intel.com
Andrew Smith Phone: +1 978 288 8175
Allegro Networks EMail: khchan@nortelnetworks.com
6399 San Ignacio Ave.
San Jose
CA 95119
FAX: 415 345 1827
Email: andrew@allegronetworks.com
Francis Reichmeyer Scott Hahn
PFN Inc. Intel
University Park at MIT 2111 NE 25th Avenue
26 Landsdowne Street Hillsboro, OR 97124 USA
Cambridge, MA 02139
Phone: +1 617 494 9980
Email: franr@pfn.com
18. References Phone: +1 503 264 8231
EMail: scott.hahn@intel.com
Ravi Sahita
Intel
2111 NE 25th Avenue
Hillsboro, OR 97124 USA
[COPS] Phone: +1 503 712 1554
Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and A. EMail: ravi.sahita@intel.com
Sastry, "The COPS (Common Open Policy Service) Protocol" RFC 2748,
January 2000.
[COPS-RSVP] Andrew Smith
Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and A. Allegro Networks
Sastry, " COPS usage for RSVP", RFC 2749, January 2000. 6399 San Ignacio Ave.
San Jose, CA 95119 USA
[COPS-PR] Fax: +1 415 345 1827
Reichmeyer, F., Herzog, S., Chan, K., Durham, D., Yavatkar, R. EMail: andrew@allegronetworks.com
Gai, S., McCloghrie, K. and A. Smith, "COPS Usage for Policy
Provisioning" RFC 3084, March 2001.
[SMI] Francis Reichmeyer
McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., PFN Inc.
and S. Waldbusser. "Structure of Management Information Version 2 University Park at MIT
(SMIv2)", RFC 2578, STD 58, April 1999. 26 Landsdowne Street
Cambridge, MA 02139 USA
SPPI May 2001 Phone: +1 617 494 9980
EMail: franr@pfn.com
[TC] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., References
and S. Waldbusser. "Textual Conventions for SMIv2", RFC 2579, STD
58, April 1999.
[CONF] [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S.,
McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., Rajan, R. and A. Sastry, "The COPS (Common Open
and S. Waldbusser. "Conformance Statements for SMIv2", RFC 2580, Policy Service) Protocol", RFC 2748, January
STD 58, April 1999. 2000.
[APPL] [COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S.,
Levi, D., Meyer, P., and B. Stewart, "SNMP Applications", RFC 2573, Rajan, R. and A. Sastry, " COPS usage for
April 1999. RSVP", RFC 2749, January 2000.
[ASN1] [COPS-PR] Reichmeyer, F., Herzog, S., Chan, K., Durham,
Information processing systems -- Open Systems Interconnection -- D., Yavatkar, R., Gai, S., McCloghrie, K. and
Specification of Abstract Syntax Notation One (ASN.1), A. Smith, "COPS Usage for Policy Provisioning",
International Organization for Standardization. International RFC 3084, March 2001.
Standard 8824, December 1987.
[INETADDR] [SMI] McCloghrie, K., Perkins, D., Schoenwaelder, J.,
M. Daniele, B. Haberman, S. Routhier and J. Schoenwaelder "Textual Case, J., Rose, M. and S. Waldbusser,
Conventions for Internet Network Addresses", RFC 2851, June 2000. "Structure of Management Information Version 2
(SMIv2)", STD 58, RFC 2578, April 1999.
[IANA] [TC] McCloghrie, K., Perkins, D., Schoenwaelder, J.,
http://www.isi.edu/in-notes/iana/assignments/smi-numbers Case, J., Rose, M. and S. Waldbusser, "Textual
Conventions for SMIv2", STD 58, RFC 2579, April
1999.
[IANA-CONSIDERATIONS] [CONF] McCloghrie, K., Perkins, D., Schoenwaelder, J.,
Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Case, J., Rose, M. and S. Waldbusser,
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. "Conformance Statements for SMIv2", STD 58, RFC
2580, April 1999.
[RFC-2119] [APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP
Bradner, S., "Key words for use in RFCs to Indicate Requirement Applications", RFC 2573, April 1999.
Levels", BCP 14, RFC 2119, March 1997
SPPI May 2001
19. Full Copyright Statement [ASN1] Information processing systems -- Open Systems
Interconnection -- Specification of Abstract
Syntax Notation One (ASN.1), International
Organization for Standardization.
International Standard 8824, December 1987.
Copyright (C) The Internet Society (2000). All Rights Reserved. [INETADDR] Daniele, M., Haberman, B., Routhier, S. and J.
Schoenwaelder "Textual Conventions for Internet
Network Addresses", RFC 2851, June 2000.
This document and translations of it may be copied and furnished to [IANA] http://www.isi.edu/in-notes/iana/assignments/smi-numbers
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 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
revoked by the Internet Society or its successors or assigns. Writing an IANA Considerations Section in
RFCs", BCP 26, RFC 2434, October 1998.
This document and the information contained herein is provided on an "AS [RFC2119] Bradner, S., "Key words for use in RFCs to
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK Indicate Requirement Levels", BCP 14, RFC 2119,
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT March 1997.
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."
SPPI May 2001
Table of Contents Full Copyright Statement
1 Use of the SMI .................................................. 2 Copyright (C) The Internet Society (2001). All Rights Reserved.
1.1 Terminology Translation ....................................... 2
1.2 Overview ...................................................... 3
2 Structure of this Specification ................................. 3
3 Definitions ..................................................... 4
4 PIB Modules ..................................................... 17
4.1 Importing Definitions ......................................... 17
4.2 Reserved Keywords ............................................. 17
5 Naming Hierarchy ................................................ 18
6 Mapping of the MODULE-IDENTITY macro ............................ 18
6.1 Mapping of the SUBJECT-CATEGORIES clause ...................... 18
7 Mapping of the OBJECT-TYPE macro ................................ 19
7.1 Mapping of the SYNTAX clause .................................. 19
7.1.1 Counter32 ................................................... 19
7.1.2 Gauge32 ..................................................... 20
7.1.3 Opaque ...................................................... 20
7.1.4 IpAddress ................................................... 20
7.1.5 Counter64 ................................................... 20
7.1.6 Integer64 ................................................... 20
7.1.7 Unsigned64 .................................................. 20
7.1.8 Provisioning Classes ........................................ 21
7.2 Mapping of the MAX-ACCESS clause .............................. 22
7.3 Mapping of the PIB-ACCESS clause .............................. 22
7.4 Mapping of the INSTALL-ERRORS clause .......................... 22
7.5 Mapping of the PIB-INDEX clause ............................... 23
7.6 Mapping of the INDEX clause ................................... 23
7.7 Mapping of the AUGMENTS clause ................................ 23
7.8 Mapping of the EXTENDS clause ................................. 24
7.8.1 Relation between PIB-INDEX, AUGMENTS and EXTENDS clauses
.............................................................. 24
7.9 Mapping of the UNIQUENESS clause .............................. 25
7.10 Mapping of the PIB-REFERENCES clause ......................... 25
7.11 Mapping of the PIB-TAG clause ................................ 26
8 Mapping of the OBJECT-IDENTITY macro ............................ 26
9 Mapping of the OBJECT-GROUP macro ............................... 26
9.1 Mapping of the OBJECTS clause ................................. 26
10 Mapping of the MODULE-COMPLIANCE macro ......................... 27
10.1 Mapping of the MODULE clause ................................. 27
10.1.1 Mapping of the MANDATORY-GROUPS clause ..................... 27
10.1.2 Mapping of the GROUP clause ................................ 27
10.1.3 Mapping of the OBJECT clause ............................... 28
10.1.3.1 Mapping of the SYNTAX clause ............................. 28
SPPI May 2001
10.1.3.2 Mapping of the WRITE-SYNTAX clause ....................... 28 This document and translations of it may be copied and furnished to
10.1.3.3 Mapping of the PIB-MIN-ACCESS clause ..................... 28 others, and derivative works that comment on or otherwise explain it
11 Textual Conventions ............................................ 29 or assist in its implementation may be prepared, copied, published
11.1 Mapping of the TEXTUAL-CONVENTION macro ...................... 29 and distributed, in whole or in part, without restriction of any
11.1.1 Mapping of the DISPLAY-HINT clause ......................... 29 kind, provided that the above copyright notice and this paragraph are
11.1.2 Mapping of the SYNTAX clause ............................... 30 included on all such copies and derivative works. However, this
11.1.2.1 Sub-typing of Textual Conventions ........................ 30 document itself may not be modified in any way, such as by removing
12 Extending a PIB Module ......................................... 30 the copyright notice or references to the Internet Society or other
12.1 PIB Modules .................................................. 30 Internet organizations, except as needed for the purpose of
12.2 Object Assignments ........................................... 31 developing Internet standards in which case the procedures for
12.3 Object Definitions ........................................... 31 copyrights defined in the Internet Standards process must be
13 Appendix A: Mapping a PIB to a MIB ............................. 33 followed, or as required to translate it into languages other than
14 Appendix B: Example usage of PIB-REFERENCES and PIB-TAG English.
clauses ...................................................... 35
15 Security Considerations ........................................ 38 The limited permissions granted above are perpetual and will not be
16 IANA Considerations ............................................ 38 revoked by the Internet Society or its successors or assigns.
17 Authors' Addresses ............................................. 39
18 References ..................................................... 40 This document and the information contained herein is provided on an
19 Full Copyright Statement ....................................... 42 "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.
 End of changes. 228 change blocks. 
883 lines changed or deleted 815 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/