draft-ietf-rap-sppi-06.txt   draft-ietf-rap-sppi-07.txt 
skipping to change at page 1, line 17 skipping to change at page 1, line 17
K. Chan K. Chan
Nortel Networks Nortel Networks
S. Hahn S. Hahn
R. Sahita R. Sahita
Intel Intel
A. Smith A. Smith
Allegro Networks Allegro Networks
F. Reichmeyer F. Reichmeyer
PFN PFN
11 April 2001 08 May 2001
Structure of Policy Provisioning Information (SPPI) Structure of Policy Provisioning Information (SPPI)
draft-ietf-rap-sppi-06.txt draft-ietf-rap-sppi-07.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document 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.
SPPI April 2001 SPPI May 2001
Abstract Abstract
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 RFC 3084 [COPS-PR]. In the provisioning of policy, is introduced in RFC 3084 [COPS-PR]. In
this provisioning model, the policy information is viewed as a this provisioning model, the policy information is viewed as a
collection of Provisioning Classes (PRCs) and Provisioning Instances collection of Provisioning Classes (PRCs) and Provisioning Instances
(PRIs) residing in a virtual information store, termed the Policy (PRIs) residing in a virtual information store, termed the Policy
skipping to change at page 3, line 4 skipping to change at page 3, line 4
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 Provisioning 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
Provisioning 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 Provisioning 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.)
SPPI April 2001 SPPI May 2001
1.2. Overview 1.2. Overview
SNMP's SMI is divided into five parts: module definitions, object SNMP's SMI is divided into five parts: module definitions, object
definitions, notification definitions [SMI], textual convention definitions, notification definitions [SMI], textual convention
definitions [TC] and conformance definitions [CONF]. definitions [TC] and conformance definitions [CONF].
- The SMI's MODULE-IDENTITY macro is used to convey the semantics of - The SMI's MODULE-IDENTITY macro is used to convey the semantics of
a MIB module. The SPPI uses this macro to convey the semantics of a MIB module. The SPPI uses this macro to convey the semantics of
a PIB module. a PIB module.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
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 also via a ASN.1 definition, which is a This document specifies the SPPI also via a ASN.1 definition, which is a
modified version of the SMI's definition, together with descriptive text modified version of the SMI's definition, together with descriptive text
for only those elements in the SPPI's ASN.1 definition which have for only those elements in the SPPI's ASN.1 definition which have
differences from the SMI's. For elements in the ASN.1 definition which differences from the SMI's. For elements in the ASN.1 definition which
have no descriptive text in this specification, the reader is referred have no descriptive text in this specification, the reader is referred
to the SMI's descriptive text for that element. to the SMI's descriptive text for that element.
SPPI April 2001 SPPI May 2001
3. Definitions 3. Definitions
COPS-PR-SPPI DEFINITIONS ::= BEGIN COPS-PR-SPPI DEFINITIONS ::= BEGIN
IMPORTS ObjectName, SimpleSyntax, ExtUTCTime, mgmt IMPORTS ObjectName, SimpleSyntax, ExtUTCTime, mgmt
FROM SNMPv2-SMI; FROM SNMPv2-SMI;
-- the root for PIB definitions -- the root for PIB definitions
skipping to change at page 5, line 4 skipping to change at page 5, line 4
identifier "(" number ")" -- number is positive identifier "(" number ")" -- number is positive
RevisionPart ::= RevisionPart ::=
Revisions Revisions
| empty | empty
Revisions ::= Revisions ::=
Revision Revision
| Revisions Revision | Revisions Revision
Revision ::= Revision ::=
"REVISION" value(Update ExtUTCTime) "REVISION" value(Update ExtUTCTime)
SPPI April 2001 SPPI May 2001
"DESCRIPTION" Text "DESCRIPTION" Text
-- a character string as defined in [SMI] -- a character string as defined in [SMI]
Text ::= value(IA5String) Text ::= value(IA5String)
END END
-- --
OBJECT-IDENTITY MACRO ::= OBJECT-IDENTITY MACRO ::=
skipping to change at page 6, line 4 skipping to change at page 6, line 4
-- 3 built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER -- 3 built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER
-- 7 application-defined types: Integer32, IpAddress, Unsigned32, -- 7 application-defined types: Integer32, IpAddress, Unsigned32,
-- TimeTicks, Opaque, Integer64 and Unsigned64 -- TimeTicks, Opaque, Integer64 and Unsigned64
ObjectSyntax ::= ObjectSyntax ::=
CHOICE { CHOICE {
simple simple
SimpleSyntax, SimpleSyntax,
-- note that SEQUENCEs for table and row definitions -- note that SEQUENCEs for table and row definitions
SPPI April 2001 SPPI May 2001
-- are not mentioned here... -- are not mentioned here...
application-wide application-wide
ApplicationSyntax ApplicationSyntax
} }
-- application-wide types -- application-wide types
ApplicationSyntax ::= ApplicationSyntax ::=
skipping to change at page 7, line 5 skipping to change at page 7, line 5
-- (this is a tagged type for historical reasons) -- (this is a tagged type for historical reasons)
IpAddress ::= IpAddress ::=
[APPLICATION 0] [APPLICATION 0]
IMPLICIT OCTET STRING (SIZE (4)) IMPLICIT OCTET STRING (SIZE (4))
-- ******* THIS TYPE DEFINITION IS DEPRECATED ******* -- ******* THIS TYPE DEFINITION IS DEPRECATED *******
-- The IpAddress type represents a 32-bit internet -- The IpAddress type represents a 32-bit internet
-- IPv4 address. It is represented as an OctetString -- IPv4 address. It is represented as an OctetString
-- of length 4, in network byte-order. -- of length 4, in network byte-order.
SPPI April 2001 SPPI May 2001
-- Note that the IpAddress type is present for -- Note that the IpAddress type is present for
-- historical reasons. IPv4 and IPv6 addresses should -- historical reasons. IPv4 and IPv6 addresses should
-- be represented using the INET-ADDRESS-MIB -- be represented using the INET-ADDRESS-MIB
-- defined in [INETADDR]. -- defined in [INETADDR].
-- an unsigned 32-bit quantity -- an unsigned 32-bit quantity
Unsigned32 ::= Unsigned32 ::=
[APPLICATION 2] [APPLICATION 2]
IMPLICIT INTEGER (0..4294967295) IMPLICIT INTEGER (0..4294967295)
skipping to change at page 8, line 4 skipping to change at page 8, line 4
BEGIN BEGIN
TYPE NOTATION ::= TYPE NOTATION ::=
"SYNTAX" Syntax "SYNTAX" Syntax
UnitsPart UnitsPart
"PIB-ACCESS" Access -- modified "PIB-ACCESS" Access -- modified
PibReferencesPart -- new PibReferencesPart -- new
PibTagPart -- new PibTagPart -- new
"STATUS" Status "STATUS" Status
"DESCRIPTION" Text "DESCRIPTION" Text
ErrorsPart -- new ErrorsPart -- new
SPPI April 2001 SPPI May 2001
ReferPart ReferPart
IndexPart -- modified IndexPart -- modified
MibIndexPart -- modified MibIndexPart -- modified
UniquePart -- new UniquePart -- new
DefValPart DefValPart
VALUE NOTATION ::= VALUE NOTATION ::=
value(VALUE ObjectName) value(VALUE ObjectName)
skipping to change at page 9, line 4 skipping to change at page 9, line 4
ErrorsPart ::= -- new ErrorsPart ::= -- new
"INSTALL-ERRORS" "{" Errors "}" "INSTALL-ERRORS" "{" Errors "}"
| empty | empty
Errors ::= -- new Errors ::= -- new
Error Error
| Errors "," Error | Errors "," Error
Error ::= -- new Error ::= -- new
identifier "(" number ")" -- number is positive identifier "(" number ")" -- number is positive
SPPI April 2001 SPPI May 2001
ReferPart ::= ReferPart ::=
"REFERENCE" Text "REFERENCE" Text
| empty | empty
IndexPart ::= IndexPart ::=
"PIB-INDEX" "{" Index "}" -- new "PIB-INDEX" "{" Index "}" -- new
| "AUGMENTS" "{" Entry "}" | "AUGMENTS" "{" Entry "}"
| "EXTENDS" "{" Entry "}" -- new | "EXTENDS" "{" Entry "}" -- new
| empty | empty
skipping to change at page 10, line 4 skipping to change at page 10, line 4
PibTagPart ::= PibTagPart ::=
-- for use with TagReferenceId TC -- for use with TagReferenceId TC
"PIB-TAG" "{" Attr "}" "PIB-TAG" "{" Attr "}"
| empty | empty
Attr ::= -- specifies an attribute Attr ::= -- specifies an attribute
value(ObjectName) value(ObjectName)
UniquePart ::= -- new UniquePart ::= -- new
"UNIQUENESS" "{" UniqueTypes "}" "UNIQUENESS" "{" UniqueTypes "}"
SPPI April 2001 SPPI May 2001
| "UNIQUENESS" "{" "}" | "UNIQUENESS" "{" "}"
| empty | empty
UniqueTypes ::= UniqueTypes ::=
UniqueType UniqueType
| UniqueTypes "," UniqueType | UniqueTypes "," UniqueType
UniqueType ::= UniqueType ::=
-- the correspondent OBJECT-TYPE invocation -- the correspondent OBJECT-TYPE invocation
value(ObjectName) value(ObjectName)
skipping to change at page 11, line 4 skipping to change at page 11, line 4
ObjectsPart ObjectsPart
"STATUS" Status "STATUS" Status
"DESCRIPTION" Text "DESCRIPTION" Text
ReferPart ReferPart
VALUE NOTATION ::= VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER) value(VALUE OBJECT IDENTIFIER)
ObjectsPart ::= ObjectsPart ::=
"OBJECTS" "{" Objects "}" "OBJECTS" "{" Objects "}"
SPPI April 2001 SPPI May 2001
Objects ::= Objects ::=
Object Object
| Objects "," Object | Objects "," Object
Object ::= Object ::=
value(ObjectName) value(ObjectName)
Status ::= Status ::=
"current" "current"
| "deprecated" | "deprecated"
skipping to change at page 12, line 4 skipping to change at page 12, line 4
| "deprecated" | "deprecated"
| "obsolete" | "obsolete"
ReferPart ::= ReferPart ::=
"REFERENCE" Text "REFERENCE" Text
| empty | empty
ModulePart ::= ModulePart ::=
Modules Modules
Modules ::= Modules ::=
SPPI April 2001 SPPI May 2001
Module Module
| Modules Module | Modules Module
Module ::= Module ::=
-- name of module -- -- name of module --
"MODULE" ModuleName "MODULE" ModuleName
MandatoryPart MandatoryPart
CompliancePart CompliancePart
ModuleName ::= ModuleName ::=
skipping to change at page 13, line 4 skipping to change at page 13, line 4
Compliance ::= Compliance ::=
ComplianceGroup ComplianceGroup
| Object | Object
ComplianceGroup ::= ComplianceGroup ::=
"GROUP" value(OBJECT IDENTIFIER) "GROUP" value(OBJECT IDENTIFIER)
"DESCRIPTION" Text "DESCRIPTION" Text
Object ::= Object ::=
"OBJECT" value(ObjectName) "OBJECT" value(ObjectName)
SPPI April 2001 SPPI May 2001
InstallSyntaxPart -- modified InstallSyntaxPart -- modified
AccessPart AccessPart
"DESCRIPTION" Text "DESCRIPTION" Text
-- must be a refinement for object's SYNTAX clause -- must be a refinement for object's SYNTAX clause
InstallSyntaxPart ::= "SYNTAX" Syntax InstallSyntaxPart ::= "SYNTAX" Syntax
| empty | empty
Syntax ::= -- Must be one of the following: Syntax ::= -- Must be one of the following:
skipping to change at page 14, line 4 skipping to change at page 14, line 4
TEXTUAL-CONVENTION MACRO ::= TEXTUAL-CONVENTION MACRO ::=
BEGIN BEGIN
TYPE NOTATION ::= TYPE NOTATION ::=
DisplayPart DisplayPart
"STATUS" Status "STATUS" Status
"DESCRIPTION" Text "DESCRIPTION" Text
ReferPart ReferPart
"SYNTAX" Syntax "SYNTAX" Syntax
VALUE NOTATION ::= VALUE NOTATION ::=
SPPI April 2001 SPPI May 2001
value(VALUE Syntax) -- adapted ASN.1 value(VALUE Syntax) -- adapted ASN.1
DisplayPart ::= DisplayPart ::=
"DISPLAY-HINT" Text "DISPLAY-HINT" Text
| empty | empty
Status ::= Status ::=
"current" "current"
| "deprecated" | "deprecated"
skipping to change at page 15, line 4 skipping to change at page 15, line 4
| "BITS" "{" NamedBits "}" | "BITS" "{" NamedBits "}"
NamedBits ::= NamedBit NamedBits ::= NamedBit
| NamedBits "," NamedBit | NamedBits "," NamedBit
NamedBit ::= identifier "(" number ")" -- number is nonnegative NamedBit ::= identifier "(" number ")" -- number is nonnegative
END END
END END
SPPI April 2001 SPPI May 2001
COPS-PR-SPPI-TC PIB-DEFINITIONS ::= BEGIN COPS-PR-SPPI-TC PIB-DEFINITIONS ::= BEGIN
IMPORTS Unsigned32, MODULE-IDENTITY, TEXTUAL-CONVENTION, pib IMPORTS Unsigned32, MODULE-IDENTITY, TEXTUAL-CONVENTION, pib
FROM COPS-PR-SPPI; FROM COPS-PR-SPPI;
copsPrSppiTc MODULE-IDENTITY copsPrSppiTc MODULE-IDENTITY
SUBJECT-CATEGORIES { all } SUBJECT-CATEGORIES { all }
LAST-UPDATED "200009201800Z" LAST-UPDATED "200009201800Z"
ORGANIZATION "IETF RAP WG" ORGANIZATION "IETF RAP WG"
skipping to change at page 16, line 4 skipping to change at page 16, line 4
named in a PIB-INDEX clause. The value of an attribute with this named in a PIB-INDEX clause. The value of an attribute with this
syntax is always greater than zero. PRIs of the same PRC need syntax is always greater than zero. PRIs of the same PRC need
not have contiguous values for their instance-identifying not have contiguous values for their instance-identifying
attribute." attribute."
SYNTAX Unsigned32 (1..4294967295) SYNTAX Unsigned32 (1..4294967295)
ReferenceId ::= TEXTUAL-CONVENTION ReferenceId ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A textual convention for use by an attribute which is used as "A textual convention for use by an attribute which is used as
SPPI April 2001 SPPI May 2001
a pointer in order to reference an instance of a particular a pointer in order to reference an instance of a particular
PRC. An attribute with this syntax must not be used in a PRC. An attribute with this syntax must not be used in a
PIB-INDEX clause , and its description must specify the PIB-INDEX clause , and its description must specify the
particular PRC to which the referenced PRI will belong. particular PRC to which the referenced PRI will belong.
For an attribute of this type, the referenced PRI must exist. For an attribute of this type, the referenced PRI must exist.
Furthermore, it is an error to try to delete a PRI that is Furthermore, it is an error to try to delete a PRI that is
referenced by another instance without first deleting/modifying referenced by another instance without first deleting/modifying
the referencing instance. The definition of an attribute with the referencing instance. The definition of an attribute with
this syntax can permit the attribute to have a value of zero to this syntax can permit the attribute to have a value of zero to
skipping to change at page 17, line 4 skipping to change at page 17, line 4
DESCRIPTION DESCRIPTION
"Represents a reference to a tag list of instances of a "Represents a reference to a tag list of instances of a
particular PRC. The particular PRC must have an attribute particular PRC. The particular PRC must have an attribute
with the syntax of TagId. The tag list consists of with the syntax of TagId. The tag list consists of
all instances which have the same value of the TagId all instances which have the same value of the TagId
attribute. Reference to the tag list is via the attribute attribute. Reference to the tag list is via the attribute
with the syntax of TagReferenceId containing the tag with the syntax of TagReferenceId containing the tag
value which identifies the tag list." value which identifies the tag list."
SYNTAX Unsigned32 SYNTAX Unsigned32
END END
SPPI April 2001 SPPI May 2001
4. PIB Modules 4. PIB Modules
The names of all standard PIB modules must be unique (but different The names of all standard PIB modules must be unique (but different
versions of the same module should have the same name). Developers of versions of the same module should have the same name). Developers 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 18, line 5 skipping to change at page 18, line 5
- 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 COPS-PR-SPPI. definition from the COPS-PR-SPPI.
4.2. Reserved Keywords 4.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:
SPPI April 2001 SPPI May 2001
EXTENDS INSTALL-ERRORS Integer64 PIB-MIN-ACCESS PIB-ACCESS EXTENDS INSTALL-ERRORS Integer64 PIB-MIN-ACCESS PIB-ACCESS
PIB-INDEX PIB-REFERENCES PIB-TAG SUBJECT-CATEGORIES UNIQUENESS PIB-INDEX PIB-REFERENCES PIB-TAG SUBJECT-CATEGORIES UNIQUENESS
Unsigned64 Unsigned64
5. Naming Hierarchy 5. Naming Hierarchy
The SPPI uses the same OBJECT IDENTIFIER naming hierarchy as the SMI. The SPPI uses the same OBJECT IDENTIFIER naming hierarchy as the SMI.
That is, OIDs are typically assigned to PIB modules from the subtree That is, OIDs are typically assigned to PIB modules from the subtree
administered by the Internet Assigned Numbers Authority (IANA). administered by the Internet Assigned Numbers Authority (IANA).
skipping to change at page 19, line 4 skipping to change at page 19, line 4
modules. At present time, no more than one named-number modules. At present time, no more than one named-number
enumeration should be specified. enumeration should be specified.
Note that the list of categories specified in a PIB module's SUBJECT- Note that the list of categories specified in a PIB module's SUBJECT-
CATEGORIES clause is not exclusive. That is, some other specification CATEGORIES clause is not exclusive. That is, some other specification
might (e.g., at a future date) specify additional COPS Client Types to might (e.g., at a future date) specify additional COPS Client Types to
which the module is relevant. 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
SPPI April 2001 SPPI May 2001
Client-Type. A PIB module with SUBJECT-CATEGORIES "all" uses the named- Client-Type. A PIB module with SUBJECT-CATEGORIES "all" uses the named-
number specified in the SUBJECT-CATEGORIES of the PIB it is associated number specified in the SUBJECT-CATEGORIES of the PIB it is associated
with, as the COPS Client-Type when it is sent over COPS. with, as the COPS Client-Type when it is sent over COPS.
7. Mapping of the OBJECT-TYPE macro 7. Mapping of the OBJECT-TYPE macro
The SPPI requires that all attribute definitions be contained within a The SPPI requires that all attribute definitions be contained within a
PRC, i.e., within a table definition. PRC, i.e., within a table definition.
skipping to change at page 20, line 5 skipping to change at page 20, line 5
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. textual convention.
The differences from the SMI in the semantics of ObjectSyntax are now The differences from the SMI in the semantics of ObjectSyntax are now
described. described.
7.1.1. Counter32 7.1.1. Counter32
The Counter32 type is not supported by the SPPI. The Counter32 type is not supported by the SPPI.
SPPI April 2001 SPPI May 2001
7.1.2. Gauge32 7.1.2. Gauge32
The Gauge32 type is not supported by the SPPI. The Gauge32 type is not supported by the SPPI.
7.1.3. Opaque 7.1.3. Opaque
The Opaque type is provided solely for backward-compatibility, and shall The Opaque type is provided solely for backward-compatibility, and shall
not be used for newly-defined object types. The Opaque type supports the not be used for newly-defined object types. The Opaque type supports the
capability to pass arbitrary ASN.1 syntax. A value is encoded using the capability to pass arbitrary ASN.1 syntax. A value is encoded using the
skipping to change at page 21, line 5 skipping to change at page 21, line 5
instead of Integer64. instead of Integer64.
7.1.7. Unsigned64 7.1.7. Unsigned64
The Unsigned64 type represents integer-valued information between 0 and The Unsigned64 type represents integer-valued information between 0 and
2^64-1 inclusive (0 to 18446744073709551615 decimal). While Unsigned64 2^64-1 inclusive (0 to 18446744073709551615 decimal). While Unsigned64
may be sub-typed to be more constrained, if the constraint results in may be sub-typed to be more constrained, if the constraint results in
all possible values being contained in the range (0..4294967295), then all possible values being contained in the range (0..4294967295), then
the Unsigned32 type must be used instead of Unsigned64. the Unsigned32 type must be used instead of Unsigned64.
SPPI April 2001 SPPI May 2001
7.1.8. Provisioning Classes 7.1.8. Provisioning Classes
The operations (on PIBs) supported by the SPPI apply exclusively to The operations (on PIBs) supported by the SPPI apply exclusively to
PRCs. Each PRC is modelled as a tabular structure, i.e., a table. Each PRCs. Each PRC is modelled as a tabular structure, i.e., a table. Each
instance of a particular PRC has the same set of attributes. The set of instance of a particular PRC has the same set of attributes. The set of
attributes which belong to every instance of a particular PRC is attributes which belong to every instance of a particular PRC is
modelled as a row in the table. Note that a PRC must have no more than modelled as a row in the table. Note that a PRC must have no more than
127 attributes. The usage of subids (for PRC attributes) beyond 127 127 attributes. The usage of subids (for PRC attributes) beyond 127
(that is 128 and above) is reserved for Mapping PIBs to MIBs (see (that is 128 and above) is reserved for Mapping PIBs to MIBs (see
skipping to change at page 22, line 5 skipping to change at page 22, line 5
where there is one <type> for each attribute, and each <type> is of the where there is one <type> for each attribute, and each <type> is of the
form: form:
<descriptor> <syntax> <descriptor> <syntax>
where <descriptor> is the descriptor naming an attribute, and <syntax> where <descriptor> is the descriptor naming an attribute, and <syntax>
has the value of that attribute's SYNTAX clause, except that both sub- has the value of that attribute's SYNTAX clause, except that both sub-
typing information and the named values for enumerated integers or the typing information and the named values for enumerated integers or the
named bits for the BITS construct, are omitted from <syntax>. named bits for the BITS construct, are omitted from <syntax>.
SPPI April 2001 SPPI May 2001
7.2. Mapping of the MAX-ACCESS clause 7.2. Mapping of the MAX-ACCESS clause
The MAX-ACCESS clause is not supported by the SPPI. The MAX-ACCESS clause is not supported by the SPPI.
7.3. Mapping of the PIB-ACCESS clause 7.3. Mapping of the PIB-ACCESS clause
The PIB-ACCESS clause must be present for a PRC's table definition, and The PIB-ACCESS clause must be present for a PRC's table definition, 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.
skipping to change at page 23, line 5 skipping to change at page 23, line 5
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 Error Sub-code, with the Error-Code set to protocol message, as the Error Sub-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.
SPPI April 2001 SPPI May 2001
7.5. Mapping of the PIB-INDEX clause 7.5. Mapping of the PIB-INDEX clause
The PIB-INDEX clause, which must be present for a row definition (unless The PIB-INDEX clause, which must be present for a row definition (unless
an 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.
The PIB-INDEX clause includes exactly one descriptor. This descriptor The PIB-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
skipping to change at page 24, line 4 skipping to change at page 24, line 4
A row definition which has a PIB-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 of the base row definition named in the AUGMENTS PIB-INDEX clause of the base row definition named in the AUGMENTS
SPPI April 2001 SPPI May 2001
clause. Further, instances of an augmenting PRC exist according to the clause. Further, instances of an augmenting PRC exist according to the
same semantics as instances of the PRC which it augments. As such, when same semantics as instances of the PRC which it augments. As such, when
an instance of a PRC is installed or removed, an instance of every PRC an instance of a PRC is installed or removed, an instance of every PRC
which augments it is also installed or removed. (for more details, see which augments it is also installed or removed. (for more details, see
[COPS-PR]). [COPS-PR]).
7.8. Mapping of the EXTENDS clause 7.8. Mapping of the EXTENDS clause
The EXTENDS clause, which must not be present except in row definitions, The EXTENDS clause, which must not be present except in row definitions,
skipping to change at page 25, line 5 skipping to change at page 25, line 5
explicitly, but are removed either implicitly (via removal of the explicitly, but are removed either implicitly (via removal of the
augmented PRI) or explicitly. When a sparsely augmented PRC is augmented PRI) or explicitly. When a sparsely augmented PRC is
installed, both instances, the instance of the sparsely augmented PRC installed, both instances, the instance of the sparsely augmented PRC
and the instance of the sparsely augmenting PRC must be sent in one COPS and the instance of the sparsely augmenting PRC must be sent in one COPS
message.x message.x
7.8.1. Relation between PIB-INDEX, AUGMENTS and EXTENDS clauses 7.8.1. Relation between PIB-INDEX, AUGMENTS and EXTENDS clauses
When defining instance identification information for a PRC: When defining instance identification information for a PRC:
SPPI April 2001 SPPI May 2001
- If there is a one-to-one correspondence between instances of this - If there is a one-to-one correspondence between instances of this
PRC and instances of an existing PRC, then the AUGMENTS clause PRC and instances of an existing PRC, then the AUGMENTS clause
should be used. should be used.
- Otherwise, if there is a sparse relationship between instances of - Otherwise, if there is a sparse relationship between instances of
this PRC and instances of an existing PRC (that is, there is a one this PRC and instances of an existing PRC (that is, there is a one
to zero or one correspondence between instances of a sparsely to zero or one correspondence between instances of a sparsely
augmented PRC and the instances of the PRC that sparsely augments augmented PRC and the instances of the PRC that sparsely augments
it.), then an EXTENDS clause should be used. it.), then an EXTENDS clause should be used.
skipping to change at page 26, line 5 skipping to change at page 26, line 5
Even though the UNIQUENESS clause is optional, its inclusion is Even though the UNIQUENESS clause is optional, its inclusion is
recommended wherever it provides useful information. recommended wherever it provides useful information.
7.10. Mapping of the PIB-REFERENCES clause 7.10. Mapping of the PIB-REFERENCES clause
The PIB-REFERENCES clause, which must be present for any attribute which The PIB-REFERENCES clause, which must be present for any attribute which
has the SYNTAX of ReferenceId, and must be absent otherwise, names the has the SYNTAX of ReferenceId, and must be absent otherwise, names the
PRC, an instance of which is referenced by the ReferenceId attribute. PRC, an instance of which is referenced by the ReferenceId attribute.
For example usages of the PIB-REFERENCES clause, see Appendix B. For example usages of the PIB-REFERENCES clause, see Appendix B.
SPPI April 2001 SPPI May 2001
7.11. Mapping of the PIB-TAG clause 7.11. Mapping of the PIB-TAG clause
The PIB-TAG clause, which must be present for an attribute which has the The PIB-TAG clause, which must be present for an attribute which has the
SYNTAX TagReferenceId, and must be absent otherwise, is used to indicate SYNTAX TagReferenceId, and must be absent otherwise, is used to indicate
that this attribute references a "tag list" of instances of another PRC. that this attribute references a "tag list" of instances of another PRC.
Such a tag list (similar in concept to the usage of the same term in Such a tag list (similar in concept to the usage of the same term in
[APPL]) is formed by all instances of the other PRC which have the same [APPL]) is formed by all instances of the other PRC which have the same
(tag) value of a particular attribute of that other PRC. The particular (tag) value of a particular attribute of that other PRC. The particular
attribute of the other PRC, which must have the SYNTAX TagId, is named attribute of the other PRC, which must have the SYNTAX TagId, is named
skipping to change at page 27, line 5 skipping to change at page 27, line 5
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
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.
SPPI April 2001 SPPI May 2001
10. Mapping of the MODULE-COMPLIANCE macro 10. Mapping of the MODULE-COMPLIANCE macro
The MODULE-COMPLIANCE macro is used to convey a minimum set of The MODULE-COMPLIANCE macro is used to convey a minimum set of
requirements with respect to implementation of one or more PIB modules. requirements with respect to implementation of one or more PIB modules.
A requirement on all "standard" PIB modules is that a corresponding A requirement on all "standard" PIB modules is that a corresponding
MODULE-COMPLIANCE specification is also defined, either in the same MODULE-COMPLIANCE specification is also defined, either in the same
module or in a companion module. module or in a companion module.
skipping to change at page 28, line 5 skipping to change at page 28, line 5
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.
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.
SPPI April 2001 SPPI May 2001
10.1.3. Mapping of the OBJECT clause 10.1.3. Mapping of the OBJECT clause
The OBJECT clause, which need not be present, is repeatedly used to The OBJECT clause, which need not be present, is repeatedly used to
specify each attribute for which compliance has a refined requirement specify each attribute for which compliance has a refined requirement
with respect to the PIB module definition. The attribute must be with respect to the PIB module definition. The attribute must be
present in one of the conformance groups named in the correspondent present in one of the conformance groups named in the correspondent
MANDATORY-GROUPS clause or GROUP clauses. MANDATORY-GROUPS clause or GROUP clauses.
By definition, each attribute specified in an OBJECT clause follows a By definition, each attribute specified in an OBJECT clause follows a
skipping to change at page 29, line 5 skipping to change at page 29, line 5
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.
SPPI April 2001 SPPI May 2001
11. Textual Conventions 11. Textual Conventions
When designing a PIB module, it is often useful to define new data types When designing a PIB module, it is often useful to define new data types
similar to those defined in the SPPI. In comparison to a type defined 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 in the SPPI, each of these new types has a different name, a similar
syntax, and specific semantics. These newly defined types are termed syntax, and specific semantics. These newly defined types are termed
textual conventions, and are used for the convenience of humans reading textual conventions, and are used for the convenience of humans reading
the PIB module. the PIB module.
skipping to change at page 29, line 37 skipping to change at page 29, line 37
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 5.2, must not conflict with any of the reserved words listed in section 5.2,
should not consist of all upper case letters, and shall not exceed 64 should not consist of all upper case letters, and shall not exceed 64
characters in length. (However, names longer than 32 characters are not characters in length. (However, names longer than 32 characters are not
recommended.) The hyphen is not allowed in the name of a textual recommended.) The hyphen is not allowed in the name of a textual
convention (except for use in information modules converted from SMIv1 convention (except for use in information modules converted from SMIv1
which allowed hyphens in ASN.1 type assignments). Further, all names which allowed hyphens in ASN.1 type assignments). Further, all names
used for the textual conventions defined in all "standard" PIB modules used for the textual conventions defined in all "standard" PIB modules
shall be unique. shall be unique.
11.1.1. Mapping of the SYNTAX clause 11.1.1. Mapping of the DISPLAY-HINT clause
The DISPLAY-HINT clause, which need not be present, gives a hint as to
how the value of an instance of an object with the syntax defined using
this textual convention might be displayed. The DISPLAY-HINT clause must
not be present if the Textual Convention is defined with a syntax of:
OBJECT IDENTIFIER, or any enumerated syntax (BITS or INTEGER). The
determination of whether it makes sense for other syntax types is
dependent on the specific definition of the Textual Convention.
The rules for the format specification of the hint are the same as
specified in Section 3.1 of [TC].
SPPI May 2001
11.1.2. Mapping of the SYNTAX clause
The SYNTAX clause, which must be present, defines abstract data The SYNTAX clause, which must be present, defines abstract data
structure corresponding to the textual convention. The data structure structure corresponding to the textual convention. The data 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.
11.1.1.1. Sub-typing of Textual Conventions 11.1.2.1. Sub-typing of Textual Conventions
The SYNTAX clause of a TEXTUAL CONVENTION macro may be sub-typed in the The SYNTAX clause of a TEXTUAL CONVENTION macro may be sub-typed in the
same way as the SYNTAX clause of an OBJECT-TYPE macro. same way as the SYNTAX clause of an OBJECT-TYPE macro.
SPPI April 2001
12. Extending a PIB Module 12. Extending a PIB Module
PIBs may be revised as implementation experience is gained. However, PIBs may be revised as implementation experience is gained. However,
changes with potential to cause disruption to interoperability between changes with potential to cause disruption to interoperability between
the previous PIB and the revised PIB are not allowed. the previous PIB and the revised PIB are not allowed.
12.1. PIB Modules 12.1. PIB Modules
For any change, the invocation of the MODULE-IDENTITY macro must be For any change, the invocation of the MODULE-IDENTITY macro must be
updated to include information about the revision: specifically, updated to include information about the revision: specifically,
skipping to change at page 30, line 37 skipping to change at page 31, line 5
since their descriptors may still be referenced by other PIB modules, since their descriptors may still be referenced by other PIB modules,
and the OBJECT IDENTIFIERs used to name them must never be re-assigned. and the OBJECT IDENTIFIERs used to name them must never be re-assigned.
The EXTENDS/AUGMENTS clause should be used to extend previous The EXTENDS/AUGMENTS clause should be used to extend previous
definitions depending on the information to be represented. definitions depending on the information to be represented.
Changes to an existing PIB can be made in several ways: Changes to an existing PIB can be made in several ways:
- Additional PRCs can be added to a PIB or an existing one - Additional PRCs can be added to a PIB or an existing one
deprecated. deprecated.
SPPI May 2001
- Attributes can be added to, or deprecated from, an existing PRC. - Attributes can be added to, or deprecated from, an existing PRC.
Note that an ASN.1 value of the correct type or an ASN.1 NULL value Note that an ASN.1 value of the correct type or an ASN.1 NULL value
must be sent even for deprecated attributes to mantain must be sent even for deprecated attributes to mantain
interoperability. New attributes must be added in sequence after interoperability. New attributes must be added in sequence after
the existing ones. the existing ones.
- An existing PRC can be extended or augmented with a new PRC defined - An existing PRC can be extended or augmented with a new PRC defined
in another (perhaps enterprise specific) PIB. in another (perhaps enterprise specific) PIB.
Additional named-number enumerations may be added to a SUBJECT- Additional named-number enumerations may be added to a SUBJECT-
CATEGORIES clause. CATEGORIES clause.
SPPI April 2001
12.2. Object Assignments 12.2. Object Assignments
If any non-editorial change is made to any clause of a object If any non-editorial change is made to any clause of a object
assignment, then the OBJECT IDENTIFIER value associated with that object assignment, then the OBJECT IDENTIFIER value associated with that object
assignment must also be changed, along with its associated descriptor. assignment must also be changed, along with its associated descriptor.
Note that the max subid for PRC attributes is 127 (See Section 7.1.8) Note that the max subid for PRC attributes is 127 (See Section 7.1.8)
12.3. Object Definitions 12.3. Object Definitions
An object definition may be revised in any of the following ways: An object definition may be revised in any of the following ways:
skipping to change at page 31, line 41 skipping to change at page 32, line 5
or "obsolete". Similarly, a STATUS clause value of "deprecated" or "obsolete". Similarly, a STATUS clause value of "deprecated"
may be revised as "obsolete". When making such a change, the may be revised as "obsolete". When making such a change, the
DESCRIPTION clause should be updated to explain the rationale. DESCRIPTION clause should be updated to explain the rationale.
- Clarifications and additional information may be included in the - Clarifications and additional information may be included in the
DESCRIPTION clause. DESCRIPTION clause.
- 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.
SPPI May 2001
- A REFERENCE clause may be added or updated. - A REFERENCE clause may be added or updated.
- A DEFVAL clause may be added or updated. - A DEFVAL clause may be added or updated.
- A PRC may be augmented by adding new objects at the end of the row, - A PRC may be augmented by adding new objects at the end of the row,
and making the corresponding update to the SEQUENCE definition. and making the corresponding update to the SEQUENCE definition.
- Entirely new objects may be defined, named with previously - Entirely new objects may be defined, named with previously
unassigned OBJECT IDENTIFIER values. unassigned OBJECT IDENTIFIER values.
SPPI April 2001
Otherwise, if the semantics of any previously defined object are changed Otherwise, if the semantics of any previously defined object are changed
(i.e., if a non-editorial change is made to any clause other than those (i.e., if a non-editorial change is made to any clause other than those
specifically allowed above), then the OBJECT IDENTIFIER value associated specifically allowed above), then the OBJECT IDENTIFIER value associated
with that object must also be changed. with that object must also be changed.
Note that changing the descriptor associated with an existing object is Note that changing the descriptor associated with an existing object is
considered a semantic change, as these strings may be used in an IMPORTS considered a semantic change, as these strings may be used in an IMPORTS
statement. statement.
SPPI April 2001 SPPI May 2001
13. Appendix A: Mapping a PIB to a MIB 13. Appendix A: Mapping a PIB to a MIB
Since the SPPI is modelled on the SMI, a PIB can be potentially Since the SPPI is modelled on the SMI, a PIB can be potentially
algorithmically mapped into a MIB. This mapping is achieved by means of 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 - Change the OID assigned to the MODULE-IDENTITY to be different
skipping to change at page 34, line 4 skipping to change at page 34, line 4
the nine characters "RowStatus" to the end of the PRC's descriptor the nine characters "RowStatus" to the end of the PRC's descriptor
(truncated if necessary to avoid the resulting descriptor being too (truncated if necessary to avoid the resulting descriptor being too
long). A Subid beyond 127 (i.e., 128 and above) can be used as the long). A Subid beyond 127 (i.e., 128 and above) can be used as the
OID for this columnar attribute. OID for this columnar attribute.
- 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, either to be a valid SMI data type or to omit allowed in the SMI, either to be a valid SMI data type or to omit
the OBJECT-TYPE or TEXTUAL-CONVENTION definition and all references the OBJECT-TYPE or TEXTUAL-CONVENTION definition and all references
to it. Since it is not clear (at this time) which is the best SMI 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 data type to use, the conversion SHOULD provide a configurable
SPPI April 2001 SPPI May 2001
option allowing a choice from at least the following: option allowing a choice from at least the following:
- convert to an OCTET STRING of the relevant size. - convert to an OCTET STRING of the relevant size.
Specifically, this option would map both Integer64 and Specifically, this option would map both Integer64 and
Unsigned64 to OCTET STRING (SIZE(8)), or Unsigned64 to OCTET STRING (SIZE(8)), or
- omit them from the conversion, or - omit them from the conversion, or
- map Integer64 and Unsigned64 to Counter64 (even though this - map Integer64 and Unsigned64 to Counter64 (even though this
has problems representing negative numbers, and unwanted has problems representing negative numbers, and unwanted
counter semantics.) counter semantics.)
SPPI April 2001 SPPI May 2001
14. Appendix B: Example usage of PIB-REFERENCES and PIB-TAG clauses 14. Appendix B: Example usage of PIB-REFERENCES and PIB-TAG clauses
The following example demonstrates the use of the PIB-REFERENCES and The following example demonstrates the use of the PIB-REFERENCES and
PIB-TAG clauses. PIB-TAG clauses.
In this example, the PIB-REFERENCES clause is used by the In this example, the PIB-REFERENCES clause is used by the
qosIfDscpMapQueue attribute to indicate the PRC of which it references qosIfDscpMapQueue attribute to indicate the PRC of which it references
an instance, and similarly, by the qosIfDscpMapThresh attribute. an instance, and similarly, by the qosIfDscpMapThresh attribute.
skipping to change at page 36, line 4 skipping to change at page 36, line 4
qosIfDscpAssignName SnmpAdminString, qosIfDscpAssignName SnmpAdminString,
qosIfDscpAssignRoles RoleCombination, qosIfDscpAssignRoles RoleCombination,
qosIfDscpAssignDscpMap TagReferenceId qosIfDscpAssignDscpMap TagReferenceId
} }
qosIfDscpAssignDscpMap OBJECT-TYPE qosIfDscpAssignDscpMap OBJECT-TYPE
SYNTAX TagReferenceId SYNTAX TagReferenceId
PIB-TAG { qosIfDscpMapMapId } -- attribute defined below PIB-TAG { qosIfDscpMapMapId } -- attribute defined below
STATUS current STATUS current
DESCRIPTION DESCRIPTION
SPPI April 2001 SPPI May 2001
"The DSCP map which is applied to interfaces of type "The DSCP map which is applied to interfaces of type
qosIfDscpAssignName which have a role combination of qosIfDscpAssignName which have a role combination of
qosIfDscpAssignRoles." qosIfDscpAssignRoles."
::= { qosIfDscpAssignEntry 3 } ::= { qosIfDscpAssignEntry 3 }
-- --
-- DSCP to Queue and Threshold Mapping Table -- DSCP to Queue and Threshold Mapping Table
-- --
skipping to change at page 37, line 4 skipping to change at page 37, line 4
qosIfDscpMapMapId OBJECT-TYPE qosIfDscpMapMapId OBJECT-TYPE
SYNTAX TagId SYNTAX TagId
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An integer that identifies the DSCP map to which this PRI "An integer that identifies the DSCP map to which this PRI
belongs." belongs."
::= { qosIfDscpMapEntry 2 } ::= { qosIfDscpMapEntry 2 }
qosIfDscpMapQueue OBJECT-TYPE qosIfDscpMapQueue OBJECT-TYPE
SPPI April 2001 SPPI May 2001
SYNTAX ReferenceId SYNTAX ReferenceId
PIB-REFERENCES { qosIfQueueEntry } PIB-REFERENCES { qosIfQueueEntry }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This attribute maps the DSCP specified by qosIfDscpMapDscp to "This attribute maps the DSCP specified by qosIfDscpMapDscp to
the queue identified by qosIfQueuePrid in qosIfQueueTable. the queue identified by qosIfQueuePrid in qosIfQueueTable.
For a given DSCP map, all the queues must belong to a single For a given DSCP map, all the queues must belong to a single
queue set." queue set."
::= { qosIfDscpMapEntry 4 } ::= { qosIfDscpMapEntry 4 }
skipping to change at page 38, line 4 skipping to change at page 38, line 4
SYNTAX ReferenceId SYNTAX ReferenceId
PIB-REFERENCES { qosIfThresholdEntry } PIB-REFERENCES { qosIfThresholdEntry }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This attribute maps the DSCP specified by qosIfDscpMapDscp to "This attribute maps the DSCP specified by qosIfDscpMapDscp to
the threshold identified by qosIfThresholdId in the threshold identified by qosIfThresholdId in
qosIfThresholdTable. The threshold set to which this qosIfThresholdTable. The threshold set to which this
threshold belongs must be assigned to the queue specified by threshold belongs must be assigned to the queue specified by
qosIfDscpMapQueue." qosIfDscpMapQueue."
::= { qosIfDscpMapEntry 5 } ::= { qosIfDscpMapEntry 5 }
SPPI April 2001 SPPI May 2001
15. Security Considerations 15. Security Considerations
This document defines a language with which to define provisioning This document defines a language with which to define provisioning
information. The language itself has no security impact on the information. The language itself has no security impact on the
Internet. Internet.
16. IANA Considerations 16. IANA Considerations
The root of the subtree administered by the Internet Assigned Numbers The root of the subtree administered by the Internet Assigned Numbers
skipping to change at page 39, line 5 skipping to change at page 39, line 5
also need to be registered and MUST use Object Identifiers below this also need to be registered and MUST use Object Identifiers below this
oid. A standards track PIB can only be assigned an OID by IANA if the oid. A standards track PIB can only be assigned an OID by IANA if the
PIB is approved by the IESG as a "standards track" document. PIB is approved by the IESG as a "standards track" document.
Experimental and enterprise PIBs MUST be defined under the Experimental and enterprise PIBs MUST be defined under the
"experimental" and "enterprises" Object Identifiers respectively. "experimental" and "enterprises" Object Identifiers respectively.
The PIB module "copsPrSppiTc" is defined in this document as a standard The PIB module "copsPrSppiTc" is defined in this document as a standard
module and hence, needs a subid assignment under the "pib" oid from module and hence, needs a subid assignment under the "pib" oid from
IANA. IANA.
SPPI April 2001 SPPI May 2001
SPPI SUBJECT-CATEGORIES are mapped to COPS Client Types. IANA SPPI SUBJECT-CATEGORIES are mapped to COPS Client Types. IANA
Considerations for SUBJECT-CATEGORIES follow the same requirements as Considerations for SUBJECT-CATEGORIES follow the same requirements as
specified in [COPS] IANA Considerations for COPS Client Types. Thus, a specified in [COPS] IANA Considerations for COPS Client Types. Thus, a
new PIB can define a new COPS Client Type in the "standards", new PIB can define a new COPS Client Type in the "standards",
"experimental" or "enterprise" space, and when approved that would mean "experimental" or "enterprise" space, and when approved that would mean
that a new COPS Client Type gets assigned. IANA must update the registry that a new COPS Client Type gets assigned. IANA must update the registry
for COPS CLient Types (where applicable as described in [COPS] IANA for COPS CLient Types (where applicable as described in [COPS] IANA
Considerations) as a result. Considerations) as a result.
skipping to change at page 40, line 4 skipping to change at page 40, line 4
Billerica, MA 01821 USA Billerica, MA 01821 USA
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
SPPI April 2001 SPPI May 2001
Ravi Sahita Ravi Sahita
Intel Intel
2111 NE 25th Avenue 2111 NE 25th Avenue
Hillsboro, OR 97124 USA Hillsboro, OR 97124 USA
Phone: +1 503 712 1554 Phone: +1 503 712 1554
Email: ravi.sahita@intel.com Email: ravi.sahita@intel.com
Andrew Smith Andrew Smith
Allegro Networks Allegro Networks
skipping to change at page 41, line 5 skipping to change at page 41, line 5
[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" RFC 3084, March 2001. Provisioning" RFC 3084, March 2001.
[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, STD 58, April 1999. (SMIv2)", RFC 2578, STD 58, April 1999.
SPPI April 2001 SPPI May 2001
[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, STD and S. Waldbusser. "Textual Conventions for SMIv2", RFC 2579, STD
58, April 1999. 58, April 1999.
[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,
STD 58, April 1999. STD 58, April 1999.
skipping to change at page 42, line 4 skipping to change at page 42, line 4
[IANA] [IANA]
http://www.isi.edu/in-notes/iana/assignments/smi-numbers http://www.isi.edu/in-notes/iana/assignments/smi-numbers
[IANA-CONSIDERATIONS] [IANA-CONSIDERATIONS]
Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC-2119] [RFC-2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997 Levels", BCP 14, RFC 2119, March 1997
SPPI April 2001 SPPI May 2001
19. Full Copyright Statement 19. Full Copyright Statement
Copyright (C) The Internet Society (2000). 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
skipping to change at page 43, line 4 skipping to change at page 43, line 4
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."
SPPI April 2001 SPPI May 2001
Table of Contents Table of Contents
1 Use of the SMI .................................................. 2 1 Use of the SMI .................................................. 2
1.1 Terminology Translation ....................................... 2 1.1 Terminology Translation ....................................... 2
1.2 Overview ...................................................... 3 1.2 Overview ...................................................... 3
2 Structure of this Specification ................................. 3 2 Structure of this Specification ................................. 3
3 Definitions ..................................................... 4 3 Definitions ..................................................... 4
4 PIB Modules ..................................................... 17 4 PIB Modules ..................................................... 17
4.1 Importing Definitions ......................................... 17 4.1 Importing Definitions ......................................... 17
skipping to change at page 44, line 4 skipping to change at page 44, line 4
7.11 Mapping of the PIB-TAG clause ................................ 26 7.11 Mapping of the PIB-TAG clause ................................ 26
8 Mapping of the OBJECT-IDENTITY macro ............................ 26 8 Mapping of the OBJECT-IDENTITY macro ............................ 26
9 Mapping of the OBJECT-GROUP macro ............................... 26 9 Mapping of the OBJECT-GROUP macro ............................... 26
9.1 Mapping of the OBJECTS clause ................................. 26 9.1 Mapping of the OBJECTS clause ................................. 26
10 Mapping of the MODULE-COMPLIANCE macro ......................... 27 10 Mapping of the MODULE-COMPLIANCE macro ......................... 27
10.1 Mapping of the MODULE clause ................................. 27 10.1 Mapping of the MODULE clause ................................. 27
10.1.1 Mapping of the MANDATORY-GROUPS clause ..................... 27 10.1.1 Mapping of the MANDATORY-GROUPS clause ..................... 27
10.1.2 Mapping of the GROUP clause ................................ 27 10.1.2 Mapping of the GROUP clause ................................ 27
10.1.3 Mapping of the OBJECT clause ............................... 28 10.1.3 Mapping of the OBJECT clause ............................... 28
10.1.3.1 Mapping of the SYNTAX clause ............................. 28 10.1.3.1 Mapping of the SYNTAX clause ............................. 28
SPPI April 2001 SPPI May 2001
10.1.3.2 Mapping of the WRITE-SYNTAX clause ....................... 28 10.1.3.2 Mapping of the WRITE-SYNTAX clause ....................... 28
10.1.3.3 Mapping of the PIB-MIN-ACCESS clause ..................... 28 10.1.3.3 Mapping of the PIB-MIN-ACCESS clause ..................... 28
11 Textual Conventions ............................................ 29 11 Textual Conventions ............................................ 29
11.1 Mapping of the TEXTUAL-CONVENTION macro ...................... 29 11.1 Mapping of the TEXTUAL-CONVENTION macro ...................... 29
11.1.1 Mapping of the SYNTAX clause ............................... 29 11.1.1 Mapping of the DISPLAY-HINT clause ......................... 29
11.1.1.1 Sub-typing of Textual Conventions ........................ 29 11.1.2 Mapping of the SYNTAX clause ............................... 30
11.1.2.1 Sub-typing of Textual Conventions ........................ 30
12 Extending a PIB Module ......................................... 30 12 Extending a PIB Module ......................................... 30
12.1 PIB Modules .................................................. 30 12.1 PIB Modules .................................................. 30
12.2 Object Assignments ........................................... 31 12.2 Object Assignments ........................................... 31
12.3 Object Definitions ........................................... 31 12.3 Object Definitions ........................................... 31
13 Appendix A: Mapping a PIB to a MIB ............................. 33 13 Appendix A: Mapping a PIB to a MIB ............................. 33
14 Appendix B: Example usage of PIB-REFERENCES and PIB-TAG 14 Appendix B: Example usage of PIB-REFERENCES and PIB-TAG
clauses ...................................................... 35 clauses ...................................................... 35
15 Security Considerations ........................................ 38 15 Security Considerations ........................................ 38
16 IANA Considerations ............................................ 38 16 IANA Considerations ............................................ 38
17 Authors' Addresses ............................................. 39 17 Authors' Addresses ............................................. 39
 End of changes. 

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