draft-ietf-rap-sppi-01.txt   draft-ietf-rap-sppi-02.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 14
Cisco Systems 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
No Affiliation No Affiliation
F. Reichmeyer F. Reichmeyer
IPHighway PFN
14 July 2000 20 September 2000
Structure of Policy Provisioning Information (SPPI) Structure of Policy Provisioning Information (SPPI)
draft-ietf-rap-sppi-01.txt draft-ietf-rap-sppi-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 2, line 5 skipping to change at page 2, line 5
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
Draft SPPI July 2000 Draft SPPI September 2000
1. Introduction 1. Introduction
RFC 2748 [COPS] defines the COPS protocol, and RFC 2749 [COPS-RSVP] RFC 2748 [COPS] defines the COPS protocol, and RFC 2749 [COPS-RSVP]
describes how the COPS protocol is used to provide for the outsourcing describes how the COPS protocol is used to provide for the outsourcing
of policy decisions for RSVP. Another usage of the COPS protocol, for of policy decisions for RSVP. Another usage of the COPS protocol, for
the provisioning of policy, is introduced in [COPS-PR]. In this the provisioning of policy, is introduced in [COPS-PR]. In this
provisioning model, the policy information is viewed as a collection of provisioning model, the policy information is viewed as a collection of
Policy Rule Classes and Policy Rule Instances residing in a virtual Provisioning Classes (PRCs) and Provisioning Instances (PRIs) residing
information store, termed the Policy Information Base (PIB). in a virtual information store, termed the Policy Information Base
Collections of related Policy Rule Classes are defined in a PIB module. (PIB). Collections of related Provisioning Classes are defined in a PIB
PIB modules are written using an adapted subset of SNMP's Structure of module. PIB modules are written using an adapted subset of SNMP's
Management Information (SMI) [SMI, TC, CONF]. It is the purpose of this Structure of Management Information (SMI) [SMI, TC, CONF]. It is the
document, the Structure of Policy Provisioning Information (SPPI), to purpose of this document, the Structure of Policy Provisioning
define that adapted subset. Information (SPPI), to define that adapted subset.
1.1. Change Log 1.1. Change Log
This log to be removed as and when this draft is published as an RFC. This log to be removed as and when this draft is published as an RFC.
1.1.1. Changes made in version published on 13 July 2000 1.1.1. Changes made in version published on 13 July 2000
- included definition of the TEXTUAL-CONVENTION macro in the SPPI's - included definition of the TEXTUAL-CONVENTION macro in the SPPI's
ASN.1 module so that TC's in PIBs can use data types not present in the ASN.1 module so that TC's in PIBs can use data types not present in the
SMI. SMI.
skipping to change at page 3, line 5 skipping to change at page 3, line 5
- renamed the MIN-ACCESS clause to be the PIB-MIN-ACCESS clause. - renamed the MIN-ACCESS clause to be the PIB-MIN-ACCESS clause.
- created a new PIB module to contain the TC's defined in the SPPI. - created a new PIB module to contain the TC's defined in the SPPI.
- defined new TC's: Prid, PolicyTagId, PolicyTagReference. - defined new TC's: Prid, PolicyTagId, PolicyTagReference.
- added Appendix with example usage of PIB-REFERENCE and PIB-TAG. - added Appendix with example usage of PIB-REFERENCE and PIB-TAG.
- added detail on carrying an INSTALL-ERROR in COPS-PR messages. - added detail on carrying an INSTALL-ERROR in COPS-PR messages.
Draft SPPI July 2000 Draft SPPI September 2000
1.1.2. Changes made in version published on 20 September 2000
- copied (unmodified) the definitions of the OBJECT-IDENTITY and OBJECT-
GROUP macros into this document.
- changed syntax of PolicyTagId and PolicyTagReference to Unsigned32.
- changed the PolicyXxx TC names to remove "Policy" and be more
consistent, i.e., PolicyTagId, PolicyReferenceId and PolicyTagReference
to TagId, ReferenceId and TagReferenceId.
- made the UNIQUENESS clause optional, but recommended wherever it
provides useful information.
- changed usage of the PIB-INDEX and INDEX clauses to be more
consistent: a PIB-INDEX clause is now always required, and always has
the same meaning. The INDEX clause is now optional, and is only used
for the algorithmic conversion to a MIB.
- changed default OID value for an added RowStatus column to be 127.
- removed the PIB-MODULES clause.
- changed the meaning of PRC to be Provisioning Class, and of PRI to be
Provisioning Instance.
- required the algorithmic conversion to a MIB to have a configurable
option with respect to how Integer64 and Unsigned64 are mapped to the
SMI.
- specified that a PIB module's SUBJECT-CATEGORIES clause is not
exclusive. That is, some other specification might (e.g., at a future
date) specify additional COPS Client Types to which the PIB module is
relevant.
- updated the Reserved Keywords.
- copied the definitions of IpAddress, Unsigned32, TimeTicks from the
SMI into COPS-PR-SPPI, and clarified that PIB modules must import each
base data type that it uses from COPS-PR-SPPI, and may import, from the
SMI, (subtree) OIDs for the purpose of defining new OIDs.
- various typos.
Draft SPPI September 2000
2. Use of the SMI 2. 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, which
use an adapted subset of the ASN.1 data definition language [ASN1]. The use an adapted subset of the ASN.1 data definition language [ASN1]. The
decision to base the definition of PIB modules on this format allows for decision to base the definition of PIB modules on this format allows for
the leveraging of the community's knowledge, experience and tools of the the leveraging of the community's knowledge, experience and tools of the
SMI and MIB modules. SMI and MIB modules.
2.1. Terminology Translation 2.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, both
tabular types with descriptors such as xxxTable and xxxEntry, as well as tabular types with descriptors such as xxxTable and xxxEntry, as well as
scalar and columnar object types. The SPPI does not use the term scalar and columnar object types. The SPPI does not use the term
"object" so as to avoid confusion with COPS protocol objects. Instead, "object" so as to avoid confusion with COPS protocol objects. Instead,
the SPPI uses the term Policy Rule Class (PRC) for the table and row the SPPI uses the term Provisioning Class (PRC) for the table and row
definitions (the xxxTable and xxxEntry objects, respectively), and definitions (the xxxTable and xxxEntry objects, respectively), and
Policy Rule Instance (PRI) for an instantiation of a row definition. Provisioning Instance (PRI) for an instantiation of a row definition.
For a columnar object of a table definition, the SPPI uses the term For a columnar object of a table definition, the SPPI uses the term
"attribute" of a Policy Rule Class. (The SPPI does not support the "attribute" of a Provisioning Class. (The SPPI does not support the
equivalent of the SMI's scalar objects.) equivalent of the SMI's scalar objects.)
2.2. Overview 2.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
skipping to change at page 4, line 5 skipping to change at page 5, line 5
the SPPI. the SPPI.
- 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-
Draft SPPI July 2000 Draft SPPI September 2000
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 acceptable
lower-bounds of implementation of the attributes of PRCs, and lower-bounds of implementation of the attributes of PRCs, and
thereby indirectly, acceptable lower-bounds of implementation of thereby indirectly, acceptable lower-bounds of implementation of
the PRCs themselves. The NOTIFICATION-GROUP macro is not used (at the PRCs themselves. The NOTIFICATION-GROUP macro is not used (at
this time) by the SPPI. Potential usage by the SPPI of the AGENT- this time) by the SPPI. Potential usage by the SPPI of the AGENT-
CAPABILITIES macro is for further study. CAPABILITIES macro is for further study.
3. Structure of this Specification 3. 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 definition.
This document specifies the SPPI via a modified ASN.1 definition (which This document specifies the SPPI also via a ASN.1 definition, which is a
imports those definitions which are unchanged from the SMI), together modified version of the SMI's definition, together with descriptive text
with descriptive text for only those elements in the SPPI's ASN.1 for only those elements in the SPPI's ASN.1 definition which have
definition which have differences from the SMI's. For elements in the differences from the SMI's. For elements in the ASN.1 definition which
ASN.1 definition which have no descriptive text in this specification, have no descriptive text in this specification, the reader is referred
the reader is referred to the SMI's descriptive text for that element. to the SMI's descriptive text for that element.
Draft SPPI July 2000 Draft SPPI September 2000
4. Definitions 4. Definitions
COPS-PR-SPPI DEFINITIONS ::= BEGIN COPS-PR-SPPI DEFINITIONS ::= BEGIN
IMPORTS ObjectName, SimpleSyntax, ExtUTCTime, Integer32, IMPORTS ObjectName, SimpleSyntax, ExtUTCTime
IpAddress, Unsigned32, TimeTicks
FROM SNMPv2-SMI; FROM SNMPv2-SMI;
-- definitions for PIB modules -- definitions for PIB modules
MODULE-IDENTITY MACRO ::= MODULE-IDENTITY MACRO ::=
BEGIN BEGIN
TYPE NOTATION ::= TYPE NOTATION ::=
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
PibModulesPart -- new
VALUE NOTATION ::= VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER) value(VALUE OBJECT IDENTIFIER)
SubjectPart ::= -- new SubjectPart ::= -- new
"SUBJECT-CATEGORY" "{" Categories "}" "SUBJECT-CATEGORIES" "{" Categories "}"
Categories ::= -- new Categories ::= -- new
CategoryIDs CategoryIDs
| "all" | "all"
CategoryIDs ::= -- new CategoryIDs ::= -- new
CategoryID CategoryID
| CategoryIDs "," CategoryID | CategoryIDs "," CategoryID
CategoryID ::= -- new CategoryID ::= -- new
identifier "(" number ")" 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)
"DESCRIPTION" Text "DESCRIPTION" Text
Draft SPPI July 2000 Draft SPPI September 2000
PibModulesPart ::= -- new -- a character string as defined in [SMI]
PIB-MODULES "{" PibModules "}" Text ::= value(IA5String)
PibModules ::= END
PibModule
| PibModules "," PibModule --
PibModule ::= -- module name of a PIB Module
value(OBJECT IDENTIFIER) OBJECT-IDENTITY MACRO ::=
BEGIN
TYPE NOTATION ::=
"STATUS" Status
"DESCRIPTION" Text
ReferPart
VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER)
Status ::=
"current"
| "deprecated"
| "obsolete"
ReferPart ::=
"REFERENCE" Text
| empty
-- a character string as defined in [SMI]
Text ::= value(IA5String) Text ::= value(IA5String)
END END
-- syntax of attributes -- syntax of attributes
-- the "base types" defined here are: -- the "base types" defined here are:
-- 3 built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER -- 3 built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER
-- 6 application-defined types: Integer32, IpAddress, Unsigned32, -- 6 application-defined types: Integer32, IpAddress, Unsigned32,
-- TimeTicks, Integer64 and Unsigned64 -- TimeTicks, 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
-- are not mentioned here... -- are not mentioned here...
Draft SPPI September 2000
application-wide application-wide
ApplicationSyntax ApplicationSyntax
} }
-- application-wide types -- application-wide types
ApplicationSyntax ::= ApplicationSyntax ::=
CHOICE { CHOICE {
ipAddress-value ipAddress-value
IpAddress, IpAddress,
timeticks-value timeticks-value
TimeTicks, TimeTicks,
unsigned-integer-value unsigned-integer-value
Unsigned32, Unsigned32,
large-integer-value -- new large-integer-value -- new
Integer64 Integer64,
Draft SPPI July 2000
large-unsigned-integer-value -- new large-unsigned-integer-value -- new
Unsigned64, Unsigned64
} }
-- the following 4 types are copied from the SMI
-- indistinguishable from INTEGER, but never needs more than -- indistinguishable from INTEGER, but never needs more than
-- 32-bits for a two's complement representation -- 32-bits for a two's complement representation
Integer32 ::= Integer32 ::=
INTEGER (-2147483648..2147483647) INTEGER (-2147483648..2147483647)
-- (this is a tagged type for historical reasons)
IpAddress ::=
[APPLICATION 0]
IMPLICIT OCTET STRING (SIZE (4))
-- an unsigned 32-bit quantity
Unsigned32 ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)
-- hundredths of seconds since an epoch
TimeTicks ::=
[APPLICATION 3]
Draft SPPI September 2000
IMPLICIT INTEGER (0..4294967295)
-- the following 2 types are not present in the SMI
Integer64 ::= Integer64 ::=
[APPLICATION 7] [APPLICATION 7]
IMPLICIT INTEGER (-9223372036854775808..9223372036854775807) IMPLICIT INTEGER (-9223372036854775808..9223372036854775807)
Unsigned64 Unsigned64
[APPLICATION 8] [APPLICATION 8]
IMPLICIT INTEGER (0..18446744073709551615) IMPLICIT INTEGER (0..18446744073709551615)
-- 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" AccessPart -- modified "PIB-ACCESS" AccessPart -- modified
PibReferencesPart -- new PibReferencesPart -- new
PibTagPart -- new PibTagPart -- new
"STATUS" Status "STATUS" Status
"DESCRIPTION" Text "DESCRIPTION" Text
ErrorsPart -- new ErrorsPart -- new
ReferPart ReferPart
IndexPart IndexPart -- modified
PibIndexPart -- new 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:
-- a base type (or its refinement), -- a base type (or its refinement),
-- a textual convention (or its refinement), or -- a textual convention (or its refinement), or
-- a BITS pseudo-type -- a BITS pseudo-type
Draft SPPI July 2000
type type
| "BITS" "{" NamedBits "}" | "BITS" "{" NamedBits "}"
NamedBits ::= NamedBit NamedBits ::= NamedBit
| NamedBits "," NamedBit | NamedBits "," NamedBit
Draft SPPI September 2000
NamedBit ::= identifier "(" number ")" -- number is nonnegative NamedBit ::= identifier "(" number ")" -- number is nonnegative
UnitsPart ::= UnitsPart ::=
"UNITS" Text "UNITS" Text
| empty | empty
AccessPart ::= -- new AccessPart ::= -- new
Access Access
| Access "," number -- number is positive | Access "," number -- number is positive
skipping to change at page 8, line 41 skipping to change at page 10, line 35
| "obsolete" | "obsolete"
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 ")" identifier "(" number ")" -- number is positive
ReferPart ::= ReferPart ::=
"REFERENCE" Text "REFERENCE" Text
| empty | empty
IndexPart ::= IndexPart ::=
"INDEX" "{" Index "}" -- modified "PIB-INDEX" "{" Index "}" -- new
| "AUGMENTS" "{" Entry "}" | "AUGMENTS" "{" Entry "}"
| "EXTENDS" "{" Entry "}" -- new | "EXTENDS" "{" Entry "}" -- new
| empty | empty
Draft SPPI July 2000
Index ::= Index ::=
-- the correspondent OBJECT-TYPE invocation -- the correspondent OBJECT-TYPE invocation
value(ObjectName) value(ObjectName)
Entry ::= Entry ::=
-- use the INDEX value of the -- use the INDEX value of the
-- correspondent OBJECT-TYPE invocation -- correspondent OBJECT-TYPE invocation
Draft SPPI September 2000
value(ObjectName) value(ObjectName)
PibIndexPart ::= -- new MibIndexPart ::=
"PIB-INDEX" "{" Index "}" "INDEX" "{" IndexTypePart "}"
| empty | empty
IndexTypePart ::=
IndexTypes
| IndexTypes "," ImpliedIndex
| ImpliedIndex
IndexTypes ::=
Index
| IndexTypes "," Index
ImpliedIndex ::=
"IMPLIED" Index
PibReferencesPart ::= PibReferencesPart ::=
-- for use with PolicyReferenceId TC -- for use with ReferenceId TC
"PIB-REFERENCES" "{" Entry "}" "PIB-REFERENCES" "{" Entry "}"
| empty | empty
PibTagPart ::= PibTagPart ::=
-- for use with "PolicyTagReference" 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 "}"
| "UNIQUENESS" "{" "}"
| empty
UniqueTypes ::= UniqueTypes ::=
UniqueType UniqueType
| UniqueTypes "," UniqueType | UniqueTypes "," UniqueType
| empty
UniqueType ::= UniqueType ::=
-- the correspondent OBJECT-TYPE invocation -- the correspondent OBJECT-TYPE invocation
value(ObjectName) value(ObjectName)
DefValPart ::= "DEFVAL" "{" Defvalue "}" DefValPart ::= "DEFVAL" "{" Defvalue "}"
| empty | empty
Defvalue ::= -- must be valid for the type specified in Defvalue ::= -- must be valid for the type specified in
-- SYNTAX clause of same OBJECT-TYPE macro -- SYNTAX clause of same OBJECT-TYPE macro
value(ObjectSyntax) value(ObjectSyntax)
Draft SPPI September 2000
| "{" BitsValue "}" | "{" BitsValue "}"
BitsValue ::= BitNames BitsValue ::= BitNames
| empty | empty
Draft SPPI July 2000
BitNames ::= BitName BitNames ::= BitName
| BitNames "," BitName | BitNames "," BitName
BitName ::= identifier BitName ::= identifier
-- a character string as defined in [SMI]
Text ::= value(IA5String)
END
-- definitions for conformance groups
OBJECT-GROUP MACRO ::=
BEGIN
TYPE NOTATION ::=
ObjectsPart
"STATUS" Status
"DESCRIPTION" Text
ReferPart
VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER)
ObjectsPart ::=
"OBJECTS" "{" Objects "}"
Objects ::=
Object
| Objects "," Object
Object ::=
value(ObjectName)
Status ::=
"current"
| "deprecated"
| "obsolete"
ReferPart ::=
"REFERENCE" Text
| empty
Draft SPPI September 2000
-- a character string as defined in [SMI]
Text ::= value(IA5String) Text ::= value(IA5String)
END END
-- definitions for compliance statements -- definitions for compliance statements
MODULE-COMPLIANCE MACRO ::= MODULE-COMPLIANCE MACRO ::=
BEGIN BEGIN
TYPE NOTATION ::= TYPE NOTATION ::=
"STATUS" Status "STATUS" Status
"DESCRIPTION" Text "DESCRIPTION" Text
skipping to change at page 11, line 4 skipping to change at page 13, line 47
| 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
identifier ModuleIdentifier identifier ModuleIdentifier
Draft SPPI July 2000
-- must not be empty unless contained -- must not be empty unless contained
-- in MIB Module -- in MIB Module
| empty | empty
ModuleIdentifier ::= ModuleIdentifier ::=
Draft SPPI September 2000
value(OBJECT IDENTIFIER) value(OBJECT IDENTIFIER)
| empty | empty
MandatoryPart ::= MandatoryPart ::=
"MANDATORY-GROUPS" "{" Groups "}" "MANDATORY-GROUPS" "{" Groups "}"
| empty | empty
Groups ::= Groups ::=
Group Group
| Groups "," Group | Groups "," Group
skipping to change at page 12, line 4 skipping to change at page 14, line 48
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),
-- a textual convention (or its refinement), or -- a textual convention (or its refinement), or
Draft SPPI July 2000
-- a BITS pseudo-type -- a BITS pseudo-type
type type
| "BITS" "{" NamedBits "}" | "BITS" "{" NamedBits "}"
Draft SPPI September 2000
NamedBits ::= NamedBit NamedBits ::= NamedBit
| NamedBits "," NamedBit | NamedBits "," NamedBit
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"
-- a character string as defined in [2] -- 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
skipping to change at page 13, line 5 skipping to change at page 15, line 48
DisplayPart ::= DisplayPart ::=
"DISPLAY-HINT" Text "DISPLAY-HINT" Text
| empty | empty
Status ::= Status ::=
"current" "current"
| "deprecated" | "deprecated"
| "obsolete" | "obsolete"
Draft SPPI July 2000
ReferPart ::= ReferPart ::=
"REFERENCE" Text "REFERENCE" Text
| empty | empty
-- a character string as defined in [2] Draft SPPI September 2000
-- a character string as defined in [SMI]
Text ::= value(IA5String) Text ::= value(IA5String)
Syntax ::= -- Must be one of the following: Syntax ::= -- Must be one of the following:
-- a base type (or its refinement), or -- a base type (or its refinement), or
-- 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
Draft SPPI July 2000 Draft SPPI September 2000
COPS-PR-SPPI-TC PIB-DEFINITIONS ::= BEGIN COPS-PR-SPPI-TC PIB-DEFINITIONS ::= BEGIN
IMPORTS Unsigned32, Integer32 FROM SNMPv2-SMI IMPORTS Unsigned32, MODULE-IDENTITY, TEXTUAL-CONVENTION
MODULE-IDENTITY, TEXTUAL-CONVENTION FROM COPS-PR-SPPI; FROM COPS-PR-SPPI;
copsPrSppiTc MODULE-IDENTITY copsPrSppiTc MODULE-IDENTITY
SUBJECT-CATEGORIES { all } SUBJECT-CATEGORIES { all }
LAST-UPDATED "200003101800Z" LAST-UPDATED "200009201800Z"
ORGANIZATION "IETF DIFFSERV WG" ORGANIZATION "IETF RAP WG"
CONTACT-INFO " CONTACT-INFO "Keith McCloghrie
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 264 8231 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 many/most PIB modules." which have general applicability to all PIB modules."
REVISION "200009201800Z"
DESCRIPTION
"Initial version, published in RFC xxxx."
::= { tbd } ::= { tbd }
PolicyInstanceId ::= 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 (or INDEX clause, if a PIB-INDEX named in a PIB-INDEX clause. The value of an attribute with this
clause is absent). The value of an attribute with this syntax is always greater than zero. PRIs of the same PRC need
syntax is always greater than zero. not have contiguous values for their instance-identifying
attribute."
PRIs of the same PRC need not have contiguous values for their
instance-identifying attribute."
SYNTAX Unsigned32 (1..4294967295) SYNTAX Unsigned32 (1..4294967295)
Draft SPPI July 2000 ReferenceId ::= TEXTUAL-CONVENTION
PolicyReferenceId ::= 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
Draft SPPI September 2000
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 (or INDEX clause, if a PIB-INDEX clause is PIB-INDEX clause , and its description must specify the
absent), and its description must specify the particular particular PRC to which the referenced PRI will belong.
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 referencing instance. The definition of an attribute with
this syntax can permit the attribute to have a value of zero to
The definition of an attribute with this syntax can permit the indicate that it is not currently pointing to an PRI."
attribute to have a value of zero to indicate that it is not
currently pointing to an 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
PolicyInstanceId value for the referenced instance." InstanceId value for the referenced instance. The definition
of an attribute with this syntax can permit the attribute to
have a value of 0.0 to indicate that it is not currently
pointing to a PRI."
SYNTAX OBJECT IDENTIFIER SYNTAX OBJECT IDENTIFIER
PolicyTagId ::= TEXTUAL-CONVENTION TagId ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Represents a tag value, such that all instances of a "Represents a tag value, such that all instances of a
particular PRC having the same tag value form a tag list. particular PRC having the same tag value form a tag list.
A tag list is identified by the tag value shared by all A tag list is identified by the tag value shared by all
instances in that tag list." instances in that tag list."
SYNTAX Integer32 SYNTAX Unsigned32 (1..4294967295)
PolicyTagReference ::= 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 PolicyTagId. The tag list consists of with the syntax of TagId. The tag list consists of
all instances which have the same value of the PolicyTagId all instances which have the same value of the TagId
Draft SPPI July 2000
attribute. Reference to the tag list is via the attribute attribute. Reference to the tag list is via the attribute
with the syntax of PolicyTagReference containing the tag with the syntax of TagReferenceId containing the tag
value which identifies the tag list." value which identifies the tag list."
SYNTAX Integer32 SYNTAX Unsigned32
END END
Draft SPPI July 2000 Draft SPPI September 2000
5. PIB Modules 5. 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 of
enterprise PIB modules are encouraged to choose names for their modules enterprise PIB modules are encouraged to choose names for their modules
that will have a low probability of colliding with standard or other that will have a low probability of colliding with standard or other
enterprise modules. enterprise modules.
The first line of a PIB module is: The first line of a PIB module is:
skipping to change at page 17, line 31 skipping to change at page 19, line 31
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.
5.1. Importing Definitions 5.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 may import from COPS-PR-SPPI (defined in In particular, a PIB module imports each of the base data types that it
this document), and from other PIB modules. A PIB module may also uses from COPS-PR-SPPI (defined in this document), and may import as
import OID assignments from MIB modules, as well as textual convention required from other PIB modules. A PIB module may import, from the SMI,
definitions providing that their underlying syntax is supported by the (subtree) OIDs for the purpose of defining new OIDs. A PIB module may
SPPI. However, the following must not be included in an IMPORTS also import, from MIB modules, OID assignments as well as textual
statement: convention definitions providing that their underlying syntax is
supported by the SPPI. However, the following must not be included in
an IMPORTS statement:
- named types defined by ASN.1 itself, specifically: INTEGER, OCTET - 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. - the BITS construct.
For each ASN.1 macro that a PIB uses, it must import that macro's For each ASN.1 macro that a PIB uses, it must import that macro's
definition from the appropriate module, as follows: definition from the COPS-PR-SPPI.
- MODULE-IDENTITY, OBJECT-TYPE, TEXTUAL-CONVENTION and MODULE-COMPLIANCE
from COPS-PR-SPPI
- OBJECT-IDENTITY from SNMPv2-SMI
- OBJECT-GROUP from SNMPv2-CONF
Draft SPPI July 2000
5.2. Reserved Keywords 5.2. Reserved Keywords
In addition to the reserved keywords listed in the SMI, the following In addition to the reserved keywords listed in the SMI, the following
must not be used as descriptors or module names: must not be used as descriptors or module names:
INSTALL-ERRORS Integer64 PIB-MIN-ACCESS PIB-ACCESS Draft SPPI September 2000
SUBJECT-CATEGORIES UNIQUENESS Unsigned64
EXTENDS INSTALL-ERRORS Integer64 PIB-MIN-ACCESS PIB-ACCESS
PIB-INDEX PIB-REFERENCES PIB-TAG SUBJECT-CATEGORIES UNIQUENESS
Unsigned64
6. Naming Hierarchy 6. 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 PRCs
in other portions of the OID tree. in other portions of the OID tree.
7. Mapping of the MODULE-IDENTITY macro 7. Mapping of the MODULE-IDENTITY macro
7.1. Mapping of the SUBJECT-CATEGORIES clause 7.1. Mapping of the SUBJECT-CATEGORIES clause
The SUBJECT-CATEGORIES clause, which must be present, identifies a The SUBJECT-CATEGORIES clause, which must be present, identifies one or
particular category of Policy data for which this PIB module defines more categories of provisioning data for which this PIB module defines
policy information. For use with the COPS-PR protocol, the individual provisioning information. For use with the COPS-PR protocol, the
subject categories are mapped to COPS Client Types [COPS-PR]. The individual subject categories are mapped to COPS Client Types [COPS-PR].
subject categories are identified either: The subject categories are identified either:
- via the keyword "all", indicating the PIB module defines policy - via the keyword "all", indicating the PIB module defines
information relevant for all subject categories (and thus, all COPS provisioning information relevant for all subject categories (and
Client Types), or thus, all COPS Client Types), or
- a list of named-number enumerations, where each number identifies a - a list of named-number enumerations, where each number which must
subject category, and is mapped to the Client Type which is be greater than zero, identifies a subject category, and is mapped
identified by that same number in the COPS protocol. At present to the Client Type which is identified by that same number in the
time, no more than one named-number enumeration should be COPS protocol. The namespace for these named numbers is global and
specified. therefore the labels should be assigned consistently across PIB
modules. At present time, no more than one named-number
enumeration should be specified.
Note that the list of categories specified in a PIB module's SUBJECT-
CATEGORIES clause is not exclusive. That is, some other specification
might (e.g., at a future date) specify additional COPS Client Types to
which the module is relevant.
When a PIB module applies to multiple subject categories, that PIB When a PIB module applies to multiple subject categories, that PIB
module exists in multiple virtual information stores, one for each module exists in multiple virtual information stores, one for each
Client-Type. Client-Type.
Draft SPPI July 2000 Draft SPPI September 2000
7.2. Mapping of the PIB-MODULES clause
The PIB-MODULES clause, which must be present if this PIB module
references any other PIB modules, identifies by module name each
referenced PIB module. For example, PIB modules referenced by an
IMPORTS or in a MODULE-CONFORMANCE should be identified in this clause.
This information is used by the algorithmic conversion of a PIB to a MIB
(see Appendix A).
8. Mapping of the OBJECT-TYPE macro 8. 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 a
PRC, i.e., within a table definition. PRC, i.e., within a table definition.
8.1. Mapping of the SYNTAX clause 8.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. The
skipping to change at page 20, line 5 skipping to change at page 21, line 44
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; base
types should contain a minimum of semantics. Semantics should, to the types should contain a minimum of semantics. Semantics should, to the
extent possible, be incorporated into a data type through the use of a extent possible, be incorporated into a data type through the use of a
textual convention. Thus, the IpAddress and TimeTicks data types should textual convention. Thus, the IpAddress and TimeTicks data types should
really be defined as textual conventions because they contain semantics. really be defined as textual conventions because they contain semantics.
However, they are defined here as base types so as to avoid confusion However, they are defined here as base types so as to avoid confusion
with the SMI which defines them as base types. with the SMI which defines them as base types.
Draft SPPI July 2000
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.
8.1.1. Counter32 8.1.1. Counter32
The Counter32 type is not supported by the SPPI. The Counter32 type is not supported by the SPPI.
Draft SPPI September 2000
8.1.2. Gauge32 8.1.2. Gauge32
The Gauge32 type is not supported by the SPPI. The Gauge32 type is not supported by the SPPI.
8.1.3. Opaque 8.1.3. Opaque
The Opaque type is not supported by the SPPI. The Opaque type is not supported by the SPPI.
8.1.4. Counter64 8.1.4. Counter64
skipping to change at page 20, line 37 skipping to change at page 22, line 30
The Integer64 type represents integer-valued information between -2^63 The Integer64 type represents integer-valued information between -2^63
and 2^63-1 inclusive (-9223372036854775808 to 9223372036854775807 and 2^63-1 inclusive (-9223372036854775808 to 9223372036854775807
decimal). While Integer64 may be sub-typed to be more constrained, if decimal). While Integer64 may be sub-typed to be more constrained, if
the constraint results in all possible values being contained in the the constraint results in all possible values being contained in the
range (-2147483648..2147483647), then the Integer32 type must be used range (-2147483648..2147483647), then the Integer32 type must be used
instead of Integer64. instead of Integer64.
8.1.6. Unsigned64 8.1.6. Unsigned64
The Integer64 type represents integer-valued information between -2^63 The Unsigned64 type represents integer-valued information between 0 and
and 2^63-1 inclusive (0 to 18446744073709551615 decimal). While 2^64-1 inclusive (0 to 18446744073709551615 decimal). While Unsigned64
Unsigned64 may be sub-typed to be more constrained, if the constraint may be sub-typed to be more constrained, if the constraint results in
results in all possible values being contained in the range all possible values being contained in the range (0..4294967295), then
(0..4294967295), then the Unsigned32 type must be used instead of the Unsigned32 type must be used instead of Unsigned64.
Unsigned64.
8.1.7. Policy Rule Classes 8.1.7. Provisioning Classes
The policy operations (on PIBs) supported by the SPPI apply exclusively The operations (on PIBs) supported by the SPPI apply exclusively to
to PRCs. Each PRC is modelled as a tabular structure, i.e., a table. PRCs. Each PRC is modelled as a tabular structure, i.e., a table. Each
Each instance of a particular PRC has the same set of attributes. The instance of a particular PRC has the same set of attributes. The set of
set of attributes which belong to every instance of a particular PRC is attributes which belong to every instance of a particular PRC is
modelled as a row in the table. This model is formalized by using the modelled as a row in the table. This model is formalized by using the
OBJECT-TYPE macro to define both: OBJECT-TYPE macro to define both:
Draft SPPI July 2000
- the PRC as a whole, called the table definition, and - the PRC as a whole, called the table definition, and
- the characteristics of every instance of a particular PRC, called - the characteristics of every instance of a particular PRC, called
the row definition. the row definition.
In the table definition, the SYNTAX clause has the form: In the table definition, the SYNTAX clause has the form:
Draft SPPI September 2000
SEQUENCE OF <EntryType> SEQUENCE OF <EntryType>
where <EntryType> refers to the SEQUENCE type of its attribute where <EntryType> refers to the SEQUENCE type of its attribute
definitions. In the row definition, the SYNTAX clause has the form: definitions. In the row definition, the SYNTAX clause has the form:
<EntryType> <EntryType>
where <EntryType> is a SEQUENCE type defined as follows: where <EntryType> is a SEQUENCE type defined as follows:
<EntryType> ::= SEQUENCE { <type1>, ... , <typeN> } <EntryType> ::= SEQUENCE { <type1>, ... , <typeN> }
skipping to change at page 21, line 44 skipping to change at page 23, line 37
8.2. Mapping of the MAX-ACCESS clause 8.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.
8.3. Mapping of the PIB-ACCESS clause 8.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, and
must not be present for any other OBJECT-TYPE definition. The PIB- must not be present for any other OBJECT-TYPE definition. The PIB-
ACCESS clause defines what kind of access is appropriate for the PRC. ACCESS clause defines what kind of access is appropriate for the PRC.
The PIB-ACCESS clause also optionally provides a number which is used in The PIB-ACCESS clause also optionally (default value is 127) provides a
the algorithmic conversion of a PIB to a MIB (see Appendix A). number which is used in the algorithmic conversion of a PIB to a MIB
(see Appendix A).
- 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 policy 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 must
notify the PDP of all its instances and attribute values of that notify the PDP of all its instances and attribute values of that
Draft SPPI July 2000
PRC. PRC.
- the value "install-notify" is used to indicate the uncommon type of - the value "install-notify" is used to indicate the uncommon type of
PRC which has both characteristics: "install" and "notify". PRC which has both characteristics: "install" and "notify".
Draft SPPI September 2000
8.4. Mapping of the INSTALL-ERRORS clause 8.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 PRC's
table definition, and must be absent otherwise, lists one or more table definition, and must be absent otherwise, lists one or more
potential reasons for rejecting an install or a removal of an instance potential reasons for rejecting an install or a removal of an instance
of the PRC. Each reason consists of a named-number enumeration, where of the PRC. Each reason consists of a named-number enumeration, where
the number represents a PRC-specific error-code to be used in a COPS the number represents a PRC-specific error-code to be used in a COPS
protocol message, as the Sub-Error Code, with the Error-Code set to protocol message, as the Sub-Error Code, with the Error-Code set to
priSpecificError (see [COPS-PR]). The semantics of each named-number priSpecificError (see [COPS-PR]). The semantics of each named-number
enumeration should be described in the PRC's DESCRIPTION clause. enumeration should be described in the PRC's DESCRIPTION clause.
The numbers listed in an INSTALL-ERRORS must be greater than zero and 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 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. still fail, but no PRC-specific error is available to be reported.
8.5. Mapping of the INDEX clause 8.5. Mapping of the PIB-INDEX clause
The INDEX clause, which must be present for a row definition (unless an The PIB-INDEX clause, which must be present for a row definition (unless
AUGMENTS or an EXTENDS clause is present instead), and must be absent an AUGMENTS or an EXTENDS clause is present instead), and must be absent
otherwise, defines identification information for instances of the PRC otherwise, defines identification information for instances of the PRC.
(unless a PIB-INDEX clause is also present, see below).
If a PIB-INDEX clause is absent for the same row definition, then a The PIB-INDEX clause includes exactly one descriptor. This descriptor
PRC's INDEX clause includes exactly one descriptor. This descriptor
specifies an attribute (typically, but not necessarily of the same PRC) specifies an attribute (typically, but not necessarily of the same PRC)
which is used to identify an instance of that PRC. The syntax of this which is used to identify an instance of that PRC. The syntax of this
attribute is required to be PolicyInstanceId (a textual convention with attribute is required to be InstanceId (a textual convention with an
an underlying syntax of Unsigned32), and it has no semantics other than underlying syntax of Unsigned32), and it has no semantics other than its
its use in identifying the PRC instance. The OBJECT IDENTIFIER which use in identifying the PRC instance. The OBJECT IDENTIFIER which
identifies an instance of a PRC is formed by appending one sub- identifies an instance of a PRC is formed by appending one sub-
identifier to the OID which identifies that PRC's row definition. The identifier to the OID which identifies that PRC's row definition. The
value of the additional sub-identifier is that instance's value of the value of the additional sub-identifier is that instance's value of the
attribute specified in the INDEX clause. attribute specified in the INDEX clause.
If a PIB-INDEX clause is present for the same row definition, then the Note that SPPI does not permit use of the IMPLIED keyword in a PIB-INDEX
INDEX clause can contain any number of attributes, and is used only by clause.
the algorithmic conversion of a PIB to a MIB (see Appendix A).
Note that SPPI does not permit use of the IMPLIED keyword.
Draft SPPI July 2000
8.6. Mapping of the PIB-INDEX clause 8.6. Mapping of the INDEX clause
The PIB-INDEX clause, which is optionally present if an INDEX clause is The INDEX clause is optionally present if a PIB-INDEX clause is present,
present, and must be absent otherwise, defines identification and must be absent otherwise. If present, the INDEX clause can contain
information for instances of the PRC. any number of attributes, and is used only by the algorithmic conversion
of a PIB to a MIB (see Appendix A).
If present, a PRC's PIB-INDEX clause includes exactly one descriptor. An IMPLIED keyword can be present in an INDEX clause if so desired.
This descriptor specifies an attribute (typically, but not necessarily
of the same PRC) which is used to identify an instance of that PRC. The
syntax of this attribute is required to be PolicyInstanceId (a textual
convention with an underlying syntax of Unsigned32), and it has no
semantics other than its use in identifying the PRC instance.
The OBJECT IDENTIFIER which identifies an instance of a PRC is formed by Draft SPPI September 2000
appending one sub-identifier to the OID which identifies that PRC's row
definition. The value of the additional sub-identifier is that
instance's value of the attribute specified in the PIB-INDEX clause.
8.7. Mapping of the AUGMENTS clause 8.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 INDEX clause and the EXTENDS definitions, is an alternative to the PIB-INDEX clause and the EXTENDS
clause. Every row definition has exactly one of: an INDEX clause, an clause. Every row definition has exactly one of: a PIB-INDEX clause, an
AUGMENTS clause, or an EXTENDS clause. AUGMENTS clause, or an EXTENDS clause.
A row definition which has an INDEX clause is called a base row 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 definition. A row definition which has an AUGMENTS clause is called a
row augmentation, where the AUGMENTS clause names the base row row augmentation, where the AUGMENTS clause names the base row
definition which is augmented by this row augmentation. (Thus, a row definition which is augmented by this row augmentation. (Thus, a row
augmentation cannot itself be augmented.) augmentation cannot itself be augmented.)
A PRC whose row definition is a row augmentation is called an augmenting A PRC whose row definition is a row augmentation is called an augmenting
PRC. Instances of an augmenting PRC are identified according to the PRC. Instances of an augmenting PRC are identified according to the
PIB-INDEX clause (or INDEX clause, if PIB-INDEX is absent) of the base PIB-INDEX clause of the base row definition named in the AUGMENTS
row definition named in the AUGMENTS clause. Further, instances of an clause. Further, instances of an augmenting PRC exist according to the
augmenting PRC exist according to the same semantics as instances of the same semantics as instances of the PRC which it augments. As such, when
PRC which it augments. As such, when an instance of a PRC is installed an instance of a PRC is installed or removed, an instance of every PRC
or removed, an instance of every PRC which augments it is also installed which augments it is also installed or removed (for more details, see
or removed (for more details, see [COPS-PR]). [COPS-PR]).
8.8. Mapping of the EXTENDS clause 8.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 definitions,
is an alternative to the INDEX clause and the AUGMENTS clause. Every is an alternative to the PIB-INDEX clause and the AUGMENTS clause.
row definition has exactly one of: an INDEX clause, an AUGMENTS clause, Every row definition has exactly one of: a PIB-INDEX clause, an AUGMENTS
clause, or an EXTENDS clause.
Draft SPPI July 2000
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 is
sparsely-augmented by this sparse row augmentation. The sparsely- 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 EXTENDS clause or the PIB-INDEX clause (or identified according to the PIB-INDEX clause of the row definition named
INDEX clause, if PIB-INDEX is absent) of the row definition named in the in the sparsely augmenting PRC's EXTENDS clause.
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. As
such, when an instance of a PRC is removed, an instance of any PRC which such, when an instance of a PRC is removed, an instance of any PRC which
sparsely augments it is also removed. sparsely augments it is also removed. However, an instance of a
sparsely augmenting PRC need not exist when the corresponding instance
8.8.1. Relation between INDEX, AUGMENTS and EXTENDS clauses Draft SPPI September 2000
of the PRC that it sparsely augments exists. Thus, an instance of a
sparsely augmenting PRC can be installed at the same time as or
subsequent to the installation of, and can be removed prior to the
removal of, the corresponding instance of the PRC that it sparsely
augments. So, instances of a sparsely augmenting PRC must be installed
explicitly, but are removed either implicitly (via removal of the
augmented PRI) or explicitly.
8.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:
- 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, then an EXTENDS clause this PRC and instances of an existing PRC, then an EXTENDS clause
should be used. should be used.
- Otherwise, an INDEX or PIB-INDEX clause should be used which names - Otherwise, a PIB-INDEX clause should be used which names its own
its own PolicyInstanceId attribute. InstanceId attribute.
8.9. Mapping of the UNIQUENESS clause 8.9. Mapping of the UNIQUENESS clause
The UNIQUENESS clause, which must be present for any row definition The UNIQUENESS clause, which is optionally present for any row
which has an INDEX clause, and must be absent otherwise, lists a set of definition which has a PIB-INDEX clause, and must be absent otherwise,
zero or more of the PRC's attributes, for which no two instances of the lists a set of zero or more of the PRC's attributes, for which no two
PRC can have the same set of values. The specified set of attributes instances of the PRC can have the same set of values. The specified set
provide a necessary and sufficient set of values by which to identify an of attributes provide a necessary and sufficient set of values by which
instance of this PRC. The attribute contained in the PIB-INDEX clause to identify an instance of this PRC. The attribute contained in the
(or INDEX clause, if a PIB-INDEX clause is absent) may not be present in PIB-INDEX clause may not be present in the UNIQUENESS clause. By
definition, an attribute may not appear more than once in a UNIQUENESS
clause. A UNIQUENESS clause containing zero attributes indicates that
it's possible for two instances of the PRC to have identical values for
all attributes except, of course, for the one named in the PIB-INDEX
clause.
Draft SPPI July 2000 Even though the UNIQUENESS clause is optional, its inclusion is
recommended wherever it provides useful information.
the UNIQUENESS clause. By definition, an attribute may not appear more Draft SPPI September 2000
than once in a UNIQUENESS clause. A UNIQUENESS clause containing zero
attributes indicates that it's possible for two instances of the PRC to
have identical values for all attributes except, of course, for the one
named in the PIB-INDEX clause (or INDEX clause, if a PIB-INDEX clause is
absent).
8.10. Mapping of the PIB-REFERENCES clause 8.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 which
has the SYNTAX of PolicyReferenceId, and must be absent otherwise, names has the SYNTAX of ReferenceId, and must be absent otherwise, names the
the PRC, an instance of which is referenced by the PolicyReferenceId PRC, an instance of which is referenced by the ReferenceId attribute.
attribute. For example usages of the PIB-REFERENCE clause, see Appendix For example usages of the PIB-REFERENCE clause, see Appendix B.
B.
8.11. Mapping of the PIB-TAG clause 8.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 the
SYNTAX PolicyTagReference, and must be absent otherwise, is used SYNTAX TagReferenceId, and must be absent otherwise, is used to indicate
indicate that this attribute references a "tag list" of instances of that this attribute references a "tag list" of instances of another PRC.
another PRC. Such a tag list (similar in concept to the usage of the Such a tag list (similar in concept to the usage of the same term in
same term in [APPL]) is formed by all instances of the other PRC which [APPL]) is formed by all instances of the other PRC which have the same
have the same (tag) value of a particular attribute of that other PRC. (tag) value of a particular attribute of that other PRC. The particular
The particular attribute of the other PRC, which must have the SYNTAX attribute of the other PRC, which must have the SYNTAX TagId, is named
PolicyTagId, is named in the PIB-TAG clause. For an example usage of in the PIB-TAG clause. For an example usage of the PIB-TAG clause, see
the PIB-TAG clause, see Appendix B. Appendix B.
Draft SPPI July 2000
9. Mapping of the OBJECT-IDENTITY macro 9. Mapping of the OBJECT-IDENTITY macro
The SMI's ASN.1 macro, OBJECT-IDENTITY [SMI], is used in PIB modules to The OBJECT-IDENTITY macro is used in PIB modules to define information
define information about an OBJECT IDENTIFIER assignment. about an OBJECT IDENTIFIER assignment.
10. Textual Conventions
When designing a PIB module, it is often useful to define new data types
similar to those defined in the SPPI. In comparison to a type defined
in the SPPI, each of these new types has a different name, a similar
syntax, and specific semantics. These newly defined types are termed
textual conventions, and are used for the convenience of humans reading
the PIB module.
Attributes defined using a textual convention are always encoded by
means of the rules that define their underlying type. The TEXTUAL-
CONVENTION (see below) is used in PIB modules to define the syntax and
semantics of a textual convention.
11. Mapping of the OBJECT-GROUP macro 10. 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 as
a collection of related PRCs and their attributes. The SPPI uses the a collection of related PRCs and their attributes. The OBJECT-GROUP
SMI's OBJECT-GROUP macro as the means to directly define the collection macro (directly) defines the collection of attributes which belong to a
of attributes which belong to a conformance group. Since each attribute conformance group. Since each attribute included in the collection
included in the collection belongs to a PRC, the collection of related belongs to a PRC, the collection of related PRCs which belong to a
PRCs which belong to a conformance group is also specified (indirectly) conformance group is also specified (indirectly) as the set of PRCs to
as the set of PRCs to which the included attributes belong. which the included attributes belong.
11.1. Mapping of the OBJECTS clause 10.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 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 in at least one conformance group. This avoids the common error of
Draft SPPI September 2000
adding a new attribute to a module and forgetting to add the new adding a new attribute to a module and forgetting to add the new
attribute to a group. attribute to a group.
Draft SPPI July 2000 11. Mapping of the MODULE-COMPLIANCE macro
12. 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.
12.1. Mapping of the MODULE clause 11.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 specified.
Each PIB module is named by its module name, and optionally, by its Each PIB module is named by its module name, and optionally, by its
associated OBJECT IDENTIFIER as well. The module name can be omitted associated OBJECT IDENTIFIER as well. The module name can be omitted
when the MODULE-COMPLIANCE invocation occurs inside a PIB module, to when the MODULE-COMPLIANCE invocation occurs inside a PIB module, to
refer to the encompassing PIB module. refer to the encompassing PIB module.
12.1.1. Mapping of the MANDATORY-GROUPS clause 11.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 or
more conformance groups within the correspondent PIB module which are more conformance groups within the correspondent PIB module which are
unconditionally mandatory for implementation. If an agent claims 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.
12.1.2. Mapping of the GROUP clause 11.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 name
each conformance group which is conditionally mandatory for compliance each conformance group which is conditionally mandatory for compliance
to the PIB module. The GROUP clause can also be used to name to the PIB module. The GROUP clause can also be used to name
unconditionally optional groups. A group named in a GROUP clause must unconditionally optional groups. A group named in a GROUP clause must
be absent from the correspondent MANDATORY-GROUPS clause. be absent from the correspondent MANDATORY-GROUPS clause.
Conditionally mandatory groups include those which are mandatory only if Conditionally mandatory groups include those which are mandatory only if
a particular protocol is implemented, or only if another group is a particular protocol is implemented, or only if another group is
implemented. A GROUP clause's DESCRIPTION specifies the conditions implemented. A GROUP clause's DESCRIPTION specifies the conditions
under which the group is conditionally mandatory. under which the group is conditionally mandatory.
Draft SPPI September 2000
A group which is named in neither a MANDATORY-GROUPS clause nor a GROUP A group which is named in neither a MANDATORY-GROUPS clause nor a GROUP
clause, is unconditionally optional for compliance to the PIB module. clause, is unconditionally optional for compliance to the PIB module.
Draft SPPI July 2000 11.1.3. Mapping of the OBJECT clause
12.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 in
a PIB module. a PIB module.
12.1.3.1. Mapping of the SYNTAX clause 11.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 for
this attribute in order to be compliant. this attribute in order to be compliant.
12.1.3.2. Mapping of the WRITE-SYNTAX clause 11.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.
12.1.3.3. Mapping of the PIB-MIN-ACCESS clause 11.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 define
the minimal level of access for the attribute named in the correspondent the minimal level of access for the attribute named in the correspondent
OBJECT clause. If this clause is absent, the minimal level of access is OBJECT clause. If this clause is absent, the minimal level of access is
the same as the maximal level specified in the PIB-ACCESS clause of the the same as the maximal level specified in the PIB-ACCESS clause of the
correspondent invocation of the OBJECT-TYPE macro. If present, this correspondent invocation of the OBJECT-TYPE macro. If present, this
clause must specify a subset of the access specified in the clause must specify a subset of the access specified in the
correspondent PIB-ACCESS clause, where: "install" is a subset of correspondent PIB-ACCESS clause, where: "install" is a subset of
"install-notify", "notify" is a subset of "install-notify", and "not- "install-notify", "notify" is a subset of "install-notify", and "not-
accessible" is a subset of all other values. accessible" is a subset of all other values.
An implementation is compliant if the level of access it provides is the 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 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. and the same or a subset of the maximal level in the PIB-ACCESS clause.
Draft SPPI July 2000 Draft SPPI September 2000
13. Mapping of the TEXTUAL-CONVENTION macro 12. Textual Conventions
When designing a PIB module, it is often useful to define new data types
similar to those defined in the SPPI. In comparison to a type defined
in the SPPI, each of these new types has a different name, a similar
syntax, and specific semantics. These newly defined types are termed
textual conventions, and are used for the convenience of humans reading
the PIB module.
Attributes defined using a textual convention are always encoded by
means of the rules that define their underlying type.
12.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 semantics
associated with a textual convention. It should be noted that the associated with a textual convention. It should be noted that the
expansion of the TEXTUAL-CONVENTION macro is something which 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 or
digits, with the initial character being an upper case letter. The name digits, with the initial character being an upper case letter. The name
must not conflict with any of the reserved words listed in section 3.7 must not conflict with any of the reserved words listed in section 5.2,
of [2], should not consist of all upper case letters, and shall not should not consist of all upper case letters, and shall not exceed 64
exceed 64 characters in length. (However, names longer than 32 characters in length. (However, names longer than 32 characters are not
characters are not recommended.) The hyphen is not allowed in the name recommended.) The hyphen is not allowed in the name of a textual
of a textual convention (except for use in information modules converted convention (except for use in information modules converted from SMIv1
from SMIv1 which allowed hyphens in ASN.1 type assignments). Further, which allowed hyphens in ASN.1 type assignments). Further, all names
all names used for the textual conventions defined in all "standard" PIB used for the textual conventions defined in all "standard" PIB modules
modules shall be unique. shall be unique.
13.1. Mapping of the SYNTAX clause 12.1.1. 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 structure
must be one of the following: a base type (see the SYNTAX clause of an must be one of the following: a base type (see the SYNTAX clause of an
OBJECT-TYPE macro), or the BITS construct. Note that this means that OBJECT-TYPE macro), or the BITS construct. Note that this means that
the SYNTAX clause of a Textual Convention can not refer to a previously the SYNTAX clause of a Textual Convention can not refer to a previously
defined Textual Convention. defined Textual Convention.
13.1.1. Sub-typing of Textual Conventions 12.1.1.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 the
same way as the SYNTAX clause of an OBJECT-TYPE macro. same way as the SYNTAX clause of an OBJECT-TYPE macro.
Draft SPPI July 2000 Draft SPPI September 2000
14. Extending a PIB Module 13. Extending a PIB Module
The SMI's rules for extending an information module are augmented with The SMI's rules for extending an information module are augmented with
the following rules: the following rules:
14.1. OBJECT-TYPE Definitions 13.1. OBJECT-TYPE Definitions
An invocation of the OBJECT-TYPE macro may also be revised in any of the An invocation of the OBJECT-TYPE macro may also be revised in any of the
following ways: following ways:
- An INSTALL-ERRORS clause may be added or an existing INSTALL-ERRORS - An INSTALL-ERRORS clause may be added or an existing INSTALL-ERRORS
clause have additional errors defined. clause have additional errors defined.
- Additional named-number enumerations may be added to a SUBJECT- - Additional named-number enumerations may be added to a SUBJECT-
CATEGORIES clause. CATEGORIES clause.
Draft SPPI July 2000 Draft SPPI September 2000
15. Appendix A: Mapping a PIB to a MIB 14. Appendix A: Mapping a PIB to a MIB
Since the SPPI is modelled on the SMI, a PIB can be easily and Since the SPPI is modelled on the SMI, a PIB can be easily and
algorithmically mapped into a MIB. This mapping is achieved by means of algorithmically mapped into a MIB. This mapping is achieved by means of
the following rules: the following rules:
- Modify the module's module name by appending "-MIB" to the name. - Modify the module's module name by appending "-MIB" to the name.
- Change the OID assigned to the MODULE-IDENTITY to be different
value.
- Replace the keyword PIB-DEFINITIONS with the keyword DEFINITIONS. - Replace the keyword PIB-DEFINITIONS with the keyword DEFINITIONS.
- Modify the module names of all external references to PIB modules - Modify the module names of all external references to PIB modules
(as identified in the PIB-MODULES clause) by appending "-MIB" to by appending "-MIB" to each such module name.
each such module name.
- Delete all of the following clauses: PIB-MODULES, PIB-ACCESS, PIB- - For each PRC definition, if an INDEX clause is absent, change the
INDEX, PIB-REFERENCES, PIB-TAG, UNIQUENESS, INSTALL-ERRORS, and "PIB-INDEX" keyword to "INDEX"; otherwise, delete the PIB-INDEX
SUBJECT-CATEGORIES. clause.
- Delete all of the following clauses: PIB-ACCESS, PIB-REFERENCES,
PIB-TAG, UNIQUENESS, INSTALL-ERRORS, and SUBJECT-CATEGORIES.
- Change all PIB-MIN-ACCESS clauses to MIN-ACCESS clauses, modifying - Change all PIB-MIN-ACCESS clauses to MIN-ACCESS clauses, modifying
"install" and "install-notify" to "read-create", and "notify" to "install" and "install-notify" to "read-create", and "notify" to
"read-only". "read-only".
- Add a MAX-ACCESS clause for each OBJECT-TYPE. For each table - Add a MAX-ACCESS clause for each OBJECT-TYPE. For each table
definition and row definition, the MAX-ACCESS is "not-accessible". definition and row definition, the MAX-ACCESS is "not-accessible".
For each attribute that is in the INDEX clause, the MAX-ACCESS is For each attribute that is in the INDEX clause, the MAX-ACCESS is
"not-accessible". For the remaining attributes, the MAX-ACCESS is "not-accessible". For the remaining attributes, the MAX-ACCESS is
"read-create". "read-create".
- Add a columnar attribute of type RowStatus with name status. The - Add a columnar attribute of type RowStatus with a descriptor and
optional number provided by the PIB-ACCESS clause is used as the appropriate DESCRIPTION. The descriptor can be formed by appending
OID for this columnar attribute. If no number is provided by the the nine characters "RowStatus" to the end of the PRC's descriptor
PIB-ACCESS clause, then the default number 1 is used. (truncated if necessary to avoid the resulting descriptor being too
long). The optional number provided by the PIB-ACCESS clause is
used as the OID for this columnar attribute. If no number is
provided by the PIB-ACCESS clause, then the default number 127 is
used.
- Modify any SYNTAX clause which has a base data type which is not - Modify any SYNTAX clause which has a base data type which is not
allowed in the SMI to be an OCTET STRING of the relevant size. allowed in the SMI, either to be a valid SMI data type or to omit
Specifically, both Integer64 and Unsigned64 are mapped to OCTET the OBJECT-TYPE or TEXTUAL-CONVENTION definition and all references
STRING (SIZE(8)).
(Note that the mapping of Integer64 and Unsigned64 to OCTET STRINGs is a Draft SPPI September 2000
compromise, which is considered superior to both
- omitting them from the conversion, and 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:
- mapping them to Counter64, which not only has problems representing - convert to an OCTET STRING of the relevant size.
negative numbers, but also has unwanted counter semantics.) Specifically, this option would map both Integer64 and
Unsigned64 to OCTET STRING (SIZE(8)), or
Draft SPPI July 2000 - omit them from the conversion, or
16. Appendix B: Example usage of PIB-REFERENCE and PIB-TAG clauses - map Integer64 and Unsigned64 to Counter64 (even though this
has problems representing negative numbers, and unwanted
counter semantics.)
Draft SPPI September 2000
15. Appendix B: Example usage of PIB-REFERENCE and PIB-TAG clauses
The following example demonstrates the use of the PIB-REFERENCE and PIB- The following example demonstrates the use of the PIB-REFERENCE and PIB-
TAG clauses. TAG clauses.
In this example, the PIB-REFERENCE clause is used by the In this example, the PIB-REFERENCE clause is used by the
qosIfDscpMapQueue attribute to indicate the PRC of which it references qosIfDscpMapQueue attribute to indicate the PRC of which it references
an instance, and similarly, by the qosIfDscpMapThresh attribute. 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 particular
"map", but there is no PRC defined for a map itself; rather, a map "map", but there is no PRC defined for a map itself; rather, a map
skipping to change at page 32, line 36 skipping to change at page 34, line 36
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
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An instance of the qosIfDscpAssign class." "An instance of the qosIfDscpAssign class."
INDEX { qosIfDscpAssignPrid } PIB-INDEX { qosIfDscpAssignPrid }
UNIQUENESS { qosIfDscpAssignName, qosIfDscpAssignRoles } UNIQUENESS { qosIfDscpAssignName, qosIfDscpAssignRoles }
::= { qosIfDscpAssignTable 1 } ::= { qosIfDscpAssignTable 1 }
QosIfDscpAssignEntry ::= SEQUENCE { QosIfDscpAssignEntry ::= SEQUENCE {
qosIfDscpAssignPrid PolicyInstanceId, qosIfDscpAssignPrid InstanceId,
qosIfDscpAssignName SnmpAdminString, qosIfDscpAssignName SnmpAdminString,
qosIfDscpAssignRoles RoleCombination, qosIfDscpAssignRoles RoleCombination,
qosIfDscpAssignDscpMap PolicyTagReference qosIfDscpAssignDscpMap TagReferenceId
} }
qosIfDscpAssignDscpMap OBJECT-TYPE qosIfDscpAssignDscpMap OBJECT-TYPE
SYNTAX PolicyTagReference SYNTAX TagReferenceId
PIB-TAG qosIfDscpMapMapId -- attribute defined below PIB-TAG qosIfDscpMapMapId -- attribute defined below
STATUS current STATUS current
DESCRIPTION DESCRIPTION
Draft SPPI July 2000 Draft SPPI September 2000
"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
-- --
skipping to change at page 33, line 31 skipping to change at page 35, line 31
"Assigns DSCP values to queues and thresholds for an arbitrary "Assigns DSCP values to queues and thresholds for an arbitrary
DSCP map. This map can then be assigned to various interface DSCP map. This map can then be assigned to various interface
and role combination pairs." and role combination pairs."
::= { qosIfParameters 10 } ::= { qosIfParameters 10 }
qosIfDscpMapEntry OBJECT-TYPE qosIfDscpMapEntry OBJECT-TYPE
SYNTAX QosIfDscpMapEntry SYNTAX QosIfDscpMapEntry
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An instance of the qosIfDscpMap class." "An instance of the qosIfDscpMap class."
INDEX { qosIfDscpMapPrid } PIB-INDEX { qosIfDscpMapPrid }
UNIQUENESS { qosIfDscpMapMapId, qosIfDscpMapDscp } UNIQUENESS { qosIfDscpMapMapId, qosIfDscpMapDscp }
::= { qosIfDscpMapTable 1 } ::= { qosIfDscpMapTable 1 }
QosIfDscpMapEntry ::= SEQUENCE { QosIfDscpMapEntry ::= SEQUENCE {
qosIfDscpMapPrid PolicyInstanceId, qosIfDscpMapPrid InstanceId,
qosIfDscpMapMapId INTEGER, qosIfDscpMapMapId TagId,
qosIfDscpMapDscp Dscp, qosIfDscpMapDscp Dscp,
qosIfDscpMapQueue PolicyReferenceId, qosIfDscpMapQueue ReferenceId,
qosIfDscpMapThresh PolicyReferenceId qosIfDscpMapThresh ReferenceId
} }
qosIfDscpMapMapId OBJECT-TYPE qosIfDscpMapMapId OBJECT-TYPE
SYNTAX PolicyTagId 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
Draft SPPI July 2000 Draft SPPI September 2000
SYNTAX PolicyReferenceId SYNTAX ReferenceId
PIB-REFERENCE qosIfQueueTable PIB-REFERENCE qosIfQueueTable
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 }
qosIfDscpMapThresh OBJECT-TYPE qosIfDscpMapThresh OBJECT-TYPE
SYNTAX PolicyReferenceId SYNTAX ReferenceId
PIB-REFERENCE qosIfThresholdTable PIB-REFERENCE qosIfThresholdTable
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 }
Draft SPPI July 2000 Draft SPPI September 2000
17. Security Considerations 16. Security Considerations
This document defines a language with which to define policy 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.
18. Authors' Addresses 17. Authors' Addresses
Keith McCloghrie 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
Michael Fine Michael Fine
Cisco Systems, Inc. Cisco Systems, Inc.
skipping to change at page 36, line 5 skipping to change at page 38, line 5
Phone: +1 978 288 8175 Phone: +1 978 288 8175
Email: khchan@nortelnetworks.com Email: khchan@nortelnetworks.com
Scott Hahn Scott Hahn
Intel Intel
2111 NE 25th Avenue 2111 NE 25th Avenue
Hillsboro, OR 97124 USA Hillsboro, OR 97124 USA
Phone: +1 503 264 8231 Phone: +1 503 264 8231
Email: scott.hahn@intel.com Email: scott.hahn@intel.com
Draft SPPI July 2000 Draft SPPI September 2000
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 264 8231 Phone: +1 503 712 1554
Email: ravi.sahita@intel.com Email: ravi.sahita@intel.com
Andrew Smith Andrew Smith
Fax: +1 415 345 1827 Fax: +1 415 345 1827
Email: ah_smith@pacbell.net Email: ah_smith@pacbell.net
Francis Reichmeyer Francis Reichmeyer
IPHighway Inc. PFN Inc.
Parker Plaza, 16th Floor University Park at MIT
400 Kelby St, Fort-Lee, NJ 07024 USA 26 Landsdowne Street
Phone: (201) 585-0800 Cambridge, MA 02139
Email: FranR@iphighway.com Phone: +1 617 494 9980
Email: franr@pfn.com
19. References 18. References
[COPS] [COPS]
Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and A. Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and A.
Sastry, "The COPS (Common Open Policy Service) Protocol" RFC 2748, Sastry, "The COPS (Common Open Policy Service) Protocol" RFC 2748,
January 2000. January 2000.
[COPS-RSVP] [COPS-RSVP]
Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and A. Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and A.
Sastry, " COPS usage for RSVP", RFC 2749, January 2000. Sastry, " COPS usage for RSVP", RFC 2749, January 2000.
[COPS-PR] [COPS-PR]
Reichmeyer, F., Herzog, S., Chan, K., Durham, D., Yavatkar, R. Reichmeyer, F., Herzog, S., Chan, K., Durham, D., Yavatkar, R.
Gai, S., McCloghrie, K. and A. Smith, "COPS Usage for Policy Gai, S., McCloghrie, K. and A. Smith, "COPS Usage for Policy
Provisioning" Internet Draft, draft-ietf-rap-cops-pr-03.txt, July Provisioning" Internet Draft, draft-ietf-rap-cops-pr-04.txt, August
2000. 2000.
[SMI] [SMI]
McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
and S. Waldbusser. "Structure of Management Information Version 2 and S. Waldbusser. "Structure of Management Information Version 2
(SMIv2)", RFC 2578, April 1999. (SMIv2)", RFC 2578, April 1999.
[TC] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., [TC] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
and S. Waldbusser. "Textual Conventions for SMIv2", RFC 2579, and S. Waldbusser. "Textual Conventions for SMIv2", RFC 2579,
April 1999. April 1999.
Draft SPPI July 2000 Draft SPPI September 2000
[CONF] [CONF]
McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
and S. Waldbusser. "Conformance Statements for SMIv2", RFC 2580, and S. Waldbusser. "Conformance Statements for SMIv2", RFC 2580,
April 1999. April 1999.
[APPL] [APPL]
Levi, D., Meyer, P., and B. Stewart, "SNMP Applications", RFC 2573, Levi, D., Meyer, P., and B. Stewart, "SNMP Applications", RFC 2573,
April 1999. April 1999.
[ASN1] [ASN1]
Information processing systems -- Open Systems Interconnection -- Information processing systems -- Open Systems Interconnection --
Specification of Abstract Syntax Notation One (ASN.1), Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization. International International Organization for Standardization. International
Standard 8824, December 1987. Standard 8824, December 1987.
Draft SPPI July 2000 Draft SPPI September 2000
20. Full Copyright Statement 19. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself 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 may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations, or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
skipping to change at page 39, line 5 skipping to change at page 41, line 5
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE." FITNESS FOR A PARTICULAR PURPOSE."
Draft SPPI July 2000 Draft SPPI September 2000
Table of Contents Table of Contents
1 Introduction .................................................... 2 1 Introduction .................................................... 2
1.1 Change Log .................................................... 2 1.1 Change Log .................................................... 2
1.1.1 Changes made in version published on 13 July 2000 ........... 2 1.1.1 Changes made in version published on 13 July 2000 ........... 2
2 Use of the SMI .................................................. 3 1.1.2 Changes made in version published on 20 September 2000 ...... 3
2.1 Terminology Translation ....................................... 3 2 Use of the SMI .................................................. 4
2.2 Overview ...................................................... 3 2.1 Terminology Translation ....................................... 4
3 Structure of this Specification ................................. 4 2.2 Overview ...................................................... 4
4 Definitions ..................................................... 5 3 Structure of this Specification ................................. 5
5 PIB Modules ..................................................... 17 4 Definitions ..................................................... 6
5.1 Importing Definitions ......................................... 17 5 PIB Modules ..................................................... 19
5.2 Reserved Keywords ............................................. 18 5.1 Importing Definitions ......................................... 19
6 Naming Hierarchy ................................................ 18 5.2 Reserved Keywords ............................................. 19
7 Mapping of the MODULE-IDENTITY macro ............................ 18 6 Naming Hierarchy ................................................ 20
7.1 Mapping of the SUBJECT-CATEGORIES clause ...................... 18 7 Mapping of the MODULE-IDENTITY macro ............................ 20
7.2 Mapping of the PIB-MODULES clause ............................. 19 7.1 Mapping of the SUBJECT-CATEGORIES clause ...................... 20
8 Mapping of the OBJECT-TYPE macro ................................ 19 8 Mapping of the OBJECT-TYPE macro ................................ 21
8.1 Mapping of the SYNTAX clause .................................. 19 8.1 Mapping of the SYNTAX clause .................................. 21
8.1.1 Counter32 ................................................... 20 8.1.1 Counter32 ................................................... 21
8.1.2 Gauge32 ..................................................... 20 8.1.2 Gauge32 ..................................................... 22
8.1.3 Opaque ...................................................... 20 8.1.3 Opaque ...................................................... 22
8.1.4 Counter64 ................................................... 20 8.1.4 Counter64 ................................................... 22
8.1.5 Integer64 ................................................... 20 8.1.5 Integer64 ................................................... 22
8.1.6 Unsigned64 .................................................. 20 8.1.6 Unsigned64 .................................................. 22
8.1.7 Policy Rule Classes ......................................... 20 8.1.7 Provisioning Classes ........................................ 22
8.2 Mapping of the MAX-ACCESS clause .............................. 21 8.2 Mapping of the MAX-ACCESS clause .............................. 23
8.3 Mapping of the PIB-ACCESS clause .............................. 21 8.3 Mapping of the PIB-ACCESS clause .............................. 23
8.4 Mapping of the INSTALL-ERRORS clause .......................... 22 8.4 Mapping of the INSTALL-ERRORS clause .......................... 24
8.5 Mapping of the INDEX clause ................................... 22 8.5 Mapping of the PIB-INDEX clause ............................... 24
8.6 Mapping of the PIB-INDEX clause ............................... 23 8.6 Mapping of the INDEX clause ................................... 24
8.7 Mapping of the AUGMENTS clause ................................ 23 8.7 Mapping of the AUGMENTS clause ................................ 25
8.8 Mapping of the EXTENDS clause ................................. 23 8.8 Mapping of the EXTENDS clause ................................. 25
8.8.1 Relation between INDEX, AUGMENTS and EXTENDS clauses ........ 24 8.8.1 Relation between PIB-INDEX, AUGMENTS and EXTENDS clauses
8.9 Mapping of the UNIQUENESS clause .............................. 24 .............................................................. 26
8.10 Mapping of the PIB-REFERENCES clause ......................... 25 8.9 Mapping of the UNIQUENESS clause .............................. 26
8.11 Mapping of the PIB-TAG clause ................................ 25 8.10 Mapping of the PIB-REFERENCES clause ......................... 27
9 Mapping of the OBJECT-IDENTITY macro ............................ 26 8.11 Mapping of the PIB-TAG clause ................................ 27
10 Textual Conventions ............................................ 26 9 Mapping of the OBJECT-IDENTITY macro ............................ 27
11 Mapping of the OBJECT-GROUP macro .............................. 26 10 Mapping of the OBJECT-GROUP macro .............................. 27
11.1 Mapping of the OBJECTS clause ................................ 26 10.1 Mapping of the OBJECTS clause ................................ 27
12 Mapping of the MODULE-COMPLIANCE macro ......................... 27 11 Mapping of the MODULE-COMPLIANCE macro ......................... 28
12.1 Mapping of the MODULE clause ................................. 27 11.1 Mapping of the MODULE clause ................................. 28
12.1.1 Mapping of the MANDATORY-GROUPS clause ..................... 27 11.1.1 Mapping of the MANDATORY-GROUPS clause ..................... 28
Draft SPPI July 2000 Draft SPPI September 2000
12.1.2 Mapping of the GROUP clause ................................ 27 11.1.2 Mapping of the GROUP clause ................................ 28
12.1.3 Mapping of the OBJECT clause ............................... 28 11.1.3 Mapping of the OBJECT clause ............................... 29
12.1.3.1 Mapping of the SYNTAX clause ............................. 28 11.1.3.1 Mapping of the SYNTAX clause ............................. 29
12.1.3.2 Mapping of the WRITE-SYNTAX clause ....................... 28 11.1.3.2 Mapping of the WRITE-SYNTAX clause ....................... 29
12.1.3.3 Mapping of the PIB-MIN-ACCESS clause ..................... 28 11.1.3.3 Mapping of the PIB-MIN-ACCESS clause ..................... 29
13 Mapping of the TEXTUAL-CONVENTION macro ........................ 29 12 Textual Conventions ............................................ 30
13.1 Mapping of the SYNTAX clause ................................. 29 12.1 Mapping of the TEXTUAL-CONVENTION macro ...................... 30
13.1.1 Sub-typing of Textual Conventions .......................... 29 12.1.1 Mapping of the SYNTAX clause ............................... 30
14 Extending a PIB Module ......................................... 30 12.1.1.1 Sub-typing of Textual Conventions ........................ 30
14.1 OBJECT-TYPE Definitions ...................................... 30 13 Extending a PIB Module ......................................... 31
15 Appendix A: Mapping a PIB to a MIB ............................. 31 13.1 OBJECT-TYPE Definitions ...................................... 31
16 Appendix B: Example usage of PIB-REFERENCE and PIB-TAG claus- 14 Appendix A: Mapping a PIB to a MIB ............................. 32
es ........................................................... 32 15 Appendix B: Example usage of PIB-REFERENCE and PIB-TAG claus-
17 Security Considerations ........................................ 35 es ........................................................... 34
18 Authors' Addresses ............................................. 35 16 Security Considerations ........................................ 37
19 References ..................................................... 36 17 Authors' Addresses ............................................. 37
20 Full Copyright Statement ....................................... 38 18 References ..................................................... 38
19 Full Copyright Statement ....................................... 40
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/