draft-ietf-rap-sppi-04.txt   draft-ietf-rap-sppi-05.txt 
skipping to change at page 1, line 16 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
22 January 2001 20 February 2001
Structure of Policy Provisioning Information (SPPI) Structure of Policy Provisioning Information (SPPI)
draft-ietf-rap-sppi-04.txt draft-ietf-rap-sppi-05.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 January 2001 Draft SPPI February 2001
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
Provisioning Classes (PRCs) and Provisioning Instances (PRIs) residing Provisioning Classes (PRCs) and Provisioning Instances (PRIs) residing
in a virtual information store, termed the Policy Information Base in a virtual information store, termed the Policy Information Base
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-REFERENCES and PIB-TAG. - added Appendix with example usage of PIB-REFERENCES 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 January 2001 Draft SPPI February 2001
1.1.2. Changes made in version published on 20 September 2000 1.1.2. Changes made in version published on 20 September 2000
- copied (unmodified) the definitions of the OBJECT-IDENTITY and OBJECT- - copied (unmodified) the definitions of the OBJECT-IDENTITY and OBJECT-
GROUP macros into this document. GROUP macros into this document.
- changed syntax of PolicyTagId and PolicyTagReference to Unsigned32. - changed syntax of PolicyTagId and PolicyTagReference to Unsigned32.
- changed the PolicyXxx TC names to remove "Policy" and be more - changed the PolicyXxx TC names to remove "Policy" and be more
consistent, i.e., PolicyTagId, PolicyReferenceId and PolicyTagReference consistent, i.e., PolicyTagId, PolicyReferenceId and PolicyTagReference
skipping to change at page 4, line 5 skipping to change at page 4, line 5
- updated the Reserved Keywords. - updated the Reserved Keywords.
- copied the definitions of IpAddress, Unsigned32, TimeTicks from the - copied the definitions of IpAddress, Unsigned32, TimeTicks from the
SMI into COPS-PR-SPPI, and clarified that PIB modules must import each 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 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. SMI, (subtree) OIDs for the purpose of defining new OIDs.
- various typos. - various typos.
Draft SPPI January 2001 Draft SPPI February 2001
1.1.3. Changes made in version published on 13 November 2000 1.1.3. Changes made in version published on 13 November 2000
- clarified definition of PIB-REFERENCES. - clarified definition of PIB-REFERENCES.
- added "report-only" as a value of PIB-ACCESS. - added "report-only" as a value of PIB-ACCESS.
1.1.4. Changes made in version published 22 January 2000 1.1.4. Changes made in version published 22 January 2001
- Converted PIB-REFERENCE to PIB-REFERENCES - Converted PIB-REFERENCE to PIB-REFERENCES
- Changed [APPLICATION 7] and [APPLICATION 8] references to [APPLICATION - Changed [APPLICATION 7] and [APPLICATION 8] references to [APPLICATION
10] and [APPLICATION 11]. 10] and [APPLICATION 11].
Draft SPPI January 2001 1.1.5. Changes made in version published 20 February 2001
- Deprecated IpAddress and added reference to INET-ADDRESS-MIB.
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
skipping to change at page 5, line 34 skipping to change at page 5, line 5
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.)
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].
Draft SPPI February 2001
- The SMI's MODULE-IDENTITY macro is used to convey the semantics of - The SMI's MODULE-IDENTITY macro is used to convey the semantics of
a MIB module. The SPPI uses this macro to convey the semantics of a MIB module. The SPPI uses this macro to convey the semantics of
a PIB module. a PIB module.
- The SMI's OBJECT-TYPE macro is used to convey the syntax and - The SMI's OBJECT-TYPE macro is used to convey the syntax and
semantics of managed objects. The SPPI uses this macro to convey semantics of managed objects. The SPPI uses this macro to convey
the syntax and semantics of PRCs and their attributes. the syntax and semantics of PRCs and their attributes.
- The SMI's notification definitions are not used (at this time) by - The SMI's notification definitions are not used (at this time) by
the SPPI. (Note that the use of the keyword 'notify' in the SPPI the SPPI. (Note that the use of the keyword 'notify' in the SPPI
is not related to the SMI's notifications). is not related to the SMI's notifications).
- The SMI's TEXTUAL CONVENTION macro allows new data types to be - The SMI's TEXTUAL CONVENTION macro allows new data types to be
defined. The SPPI uses this macro to define new data types having defined. The SPPI uses this macro to define new data types having
particular syntax and semantics which is common to several particular syntax and semantics which is common to several
attributes of one of more PRCs. attributes of one of more PRCs.
Draft SPPI January 2001
- The SMI's conformance definitions define several macros: the - The SMI's conformance definitions define several macros: the
OBJECT-GROUP macro, the NOTIFICATION-GROUP macro, the MODULE- OBJECT-GROUP macro, the NOTIFICATION-GROUP macro, the MODULE-
COMPLIANCE macro and the AGENT-CAPABILITIES macro. The SPPI uses COMPLIANCE macro and the AGENT-CAPABILITIES macro. The SPPI uses
the OBJECT-GROUP and MODULE-COMPLIANCE macros to specify acceptable the OBJECT-GROUP and MODULE-COMPLIANCE macros to specify 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.
skipping to change at page 7, line 5 skipping to change at page 6, 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.
Draft SPPI January 2001 Draft SPPI February 2001
4. Definitions 4. Definitions
COPS-PR-SPPI DEFINITIONS ::= BEGIN COPS-PR-SPPI DEFINITIONS ::= BEGIN
IMPORTS ObjectName, SimpleSyntax, ExtUTCTime IMPORTS ObjectName, SimpleSyntax, ExtUTCTime
FROM SNMPv2-SMI; FROM SNMPv2-SMI;
-- definitions for PIB modules -- definitions for PIB modules
skipping to change at page 8, line 5 skipping to change at page 7, line 5
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 January 2001 Draft SPPI February 2001
-- a character string as defined in [SMI] -- a character string as defined in [SMI]
Text ::= value(IA5String) Text ::= value(IA5String)
END END
-- --
OBJECT-IDENTITY MACRO ::= OBJECT-IDENTITY MACRO ::=
BEGIN BEGIN
TYPE NOTATION ::= TYPE NOTATION ::=
skipping to change at page 9, line 5 skipping to change at page 8, line 5
-- 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 January 2001 Draft SPPI February 2001
application-wide application-wide
ApplicationSyntax ApplicationSyntax
} }
-- application-wide types -- application-wide types
ApplicationSyntax ::= ApplicationSyntax ::=
CHOICE { CHOICE {
ipAddress-value ipAddress-value
skipping to change at page 9, line 42 skipping to change at page 8, line 42
-- 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) -- (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 *******
-- The IpAddress type represents a 32-bit internet
-- IPv4 address. It is represented as an OctetString
-- of length 4, in network byte-order.
-- Note that the IpAddress type is present for
-- historical reasons. IPv4 and IPv6 addresses should
-- be represented using the INET-ADDRESS-MIB
-- defined in [INETADDR].
Draft SPPI February 2001
-- an unsigned 32-bit quantity -- an unsigned 32-bit quantity
Unsigned32 ::= Unsigned32 ::=
[APPLICATION 2] [APPLICATION 2]
IMPLICIT INTEGER (0..4294967295) IMPLICIT INTEGER (0..4294967295)
-- hundredths of seconds since an epoch -- hundredths of seconds since an epoch
TimeTicks ::= TimeTicks ::=
[APPLICATION 3] [APPLICATION 3]
Draft SPPI January 2001
IMPLICIT INTEGER (0..4294967295) IMPLICIT INTEGER (0..4294967295)
-- the following 2 types are not present in the SMI -- the following 2 types are not present in the SMI
Integer64 ::= Integer64 ::=
[APPLICATION 10] [APPLICATION 10]
IMPLICIT INTEGER (-9223372036854775808..9223372036854775807) IMPLICIT INTEGER (-9223372036854775808..9223372036854775807)
Unsigned64 Unsigned64
[APPLICATION 11] [APPLICATION 11]
skipping to change at page 10, line 43 skipping to change at page 10, line 4
ReferPart ReferPart
IndexPart -- modified IndexPart -- modified
MibIndexPart -- modified MibIndexPart -- modified
UniquePart -- new UniquePart -- new
DefValPart DefValPart
VALUE NOTATION ::= VALUE NOTATION ::=
value(VALUE ObjectName) value(VALUE ObjectName)
Syntax ::= -- Must be one of the following: Syntax ::= -- Must be one of the following:
Draft SPPI February 2001
-- 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
type type
| "BITS" "{" NamedBits "}" | "BITS" "{" NamedBits "}"
NamedBits ::= NamedBit NamedBits ::= NamedBit
| NamedBits "," NamedBit | NamedBits "," NamedBit
Draft SPPI January 2001
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 11, line 43 skipping to change at page 11, line 4
Error Error
| Errors "," Error | Errors "," Error
Error ::= -- new Error ::= -- new
identifier "(" number ")" -- number is positive identifier "(" number ")" -- number is positive
ReferPart ::= ReferPart ::=
"REFERENCE" Text "REFERENCE" Text
| empty | empty
IndexPart ::= IndexPart ::=
Draft SPPI February 2001
"PIB-INDEX" "{" Index "}" -- new "PIB-INDEX" "{" Index "}" -- new
| "AUGMENTS" "{" Entry "}" | "AUGMENTS" "{" Entry "}"
| "EXTENDS" "{" Entry "}" -- new | "EXTENDS" "{" Entry "}" -- new
| empty | empty
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
Draft SPPI January 2001
-- correspondent OBJECT-TYPE invocation -- correspondent OBJECT-TYPE invocation
value(ObjectName) value(ObjectName)
MibIndexPart ::= MibIndexPart ::=
"INDEX" "{" IndexTypePart "}" "INDEX" "{" IndexTypePart "}"
| empty | empty
IndexTypePart ::= IndexTypePart ::=
IndexTypes IndexTypes
| IndexTypes "," ImpliedIndex | IndexTypes "," ImpliedIndex
| ImpliedIndex | ImpliedIndex
IndexTypes ::= IndexTypes ::=
skipping to change at page 12, line 42 skipping to change at page 12, line 4
Attr ::= -- specifies an attribute Attr ::= -- specifies an attribute
value(ObjectName) value(ObjectName)
UniquePart ::= -- new UniquePart ::= -- new
"UNIQUENESS" "{" UniqueTypes "}" "UNIQUENESS" "{" UniqueTypes "}"
| "UNIQUENESS" "{" "}" | "UNIQUENESS" "{" "}"
| empty | empty
UniqueTypes ::= UniqueTypes ::=
UniqueType UniqueType
| UniqueTypes "," UniqueType | UniqueTypes "," UniqueType
Draft SPPI February 2001
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
Draft SPPI January 2001
value(ObjectSyntax) value(ObjectSyntax)
| "{" BitsValue "}" | "{" BitsValue "}"
BitsValue ::= BitNames BitsValue ::= BitNames
| empty | empty
BitNames ::= BitName BitNames ::= BitName
| BitNames "," BitName | BitNames "," BitName
BitName ::= identifier BitName ::= identifier
skipping to change at page 13, line 43 skipping to change at page 13, line 5
value(VALUE OBJECT IDENTIFIER) value(VALUE OBJECT IDENTIFIER)
ObjectsPart ::= ObjectsPart ::=
"OBJECTS" "{" Objects "}" "OBJECTS" "{" Objects "}"
Objects ::= Objects ::=
Object Object
| Objects "," Object | Objects "," Object
Object ::= Object ::=
value(ObjectName) value(ObjectName)
Draft SPPI February 2001
Status ::= Status ::=
"current" "current"
| "deprecated" | "deprecated"
| "obsolete" | "obsolete"
ReferPart ::= ReferPart ::=
"REFERENCE" Text "REFERENCE" Text
| empty | empty
Draft SPPI January 2001
-- a character string as defined in [SMI] -- 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
skipping to change at page 14, line 42 skipping to change at page 14, line 4
ModulePart ::= ModulePart ::=
Modules Modules
Modules ::= Modules ::=
Module Module
| Modules Module | Modules Module
Module ::= Module ::=
-- name of module -- -- name of module --
"MODULE" ModuleName "MODULE" ModuleName
MandatoryPart MandatoryPart
Draft SPPI February 2001
CompliancePart CompliancePart
ModuleName ::= ModuleName ::=
-- identifier must start with uppercase letter -- identifier must start with uppercase letter
identifier ModuleIdentifier identifier ModuleIdentifier
-- must not be empty unless contained -- must not be empty unless contained
-- in MIB Module -- in MIB Module
| empty | empty
ModuleIdentifier ::= ModuleIdentifier ::=
Draft SPPI January 2001
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 15, line 43 skipping to change at page 15, line 4
"DESCRIPTION" Text "DESCRIPTION" Text
Object ::= Object ::=
"OBJECT" value(ObjectName) "OBJECT" value(ObjectName)
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
Draft SPPI February 2001
| 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
-- a BITS pseudo-type -- a BITS pseudo-type
type type
| "BITS" "{" NamedBits "}" | "BITS" "{" NamedBits "}"
Draft SPPI January 2001
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"
skipping to change at page 16, line 43 skipping to change at page 16, line 5
ReferPart ReferPart
"SYNTAX" Syntax "SYNTAX" Syntax
VALUE NOTATION ::= VALUE NOTATION ::=
value(VALUE Syntax) -- adapted ASN.1 value(VALUE Syntax) -- adapted ASN.1
DisplayPart ::= DisplayPart ::=
"DISPLAY-HINT" Text "DISPLAY-HINT" Text
| empty | empty
Draft SPPI February 2001
Status ::= Status ::=
"current" "current"
| "deprecated" | "deprecated"
| "obsolete" | "obsolete"
ReferPart ::= ReferPart ::=
"REFERENCE" Text "REFERENCE" Text
| empty | empty
Draft SPPI January 2001
-- a character string as defined in [SMI] -- 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 January 2001 Draft SPPI February 2001
COPS-PR-SPPI-TC PIB-DEFINITIONS ::= BEGIN COPS-PR-SPPI-TC PIB-DEFINITIONS ::= BEGIN
IMPORTS Unsigned32, MODULE-IDENTITY, TEXTUAL-CONVENTION IMPORTS Unsigned32, 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 "200009201800Z" LAST-UPDATED "200009201800Z"
ORGANIZATION "IETF RAP WG" ORGANIZATION "IETF RAP WG"
skipping to change at page 19, line 5 skipping to change at page 18, line 5
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
Draft SPPI January 2001 Draft SPPI February 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 20, line 5 skipping to change at page 19, line 5
"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
Draft SPPI January 2001 Draft SPPI February 2001
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 21, line 5 skipping to change at page 20, 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.
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:
Draft SPPI January 2001 Draft SPPI February 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
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).
skipping to change at page 22, line 5 skipping to change at page 21, line 5
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
Client-Type. Client-Type.
Draft SPPI January 2001 Draft SPPI February 2001
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 23, line 5 skipping to change at page 22, line 5
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.
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 January 2001 Draft SPPI February 2001
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 24, line 5 skipping to change at page 23, line 5
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:
- 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 January 2001 Draft SPPI February 2001
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:
skipping to change at page 25, line 5 skipping to change at page 24, line 5
- the value "install" is used to indicate a PRC which a PDP can - the value "install" is used to indicate a PRC which a PDP can
install in the PEP as provisioning information. install in the PEP as provisioning information.
- the value "notify" is used to indicate a PRC for which the PEP must - the value "notify" is used to indicate a PRC for which the PEP 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
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 January 2001 Draft SPPI February 2001
the value "report-only" is used to indicate a PRC which has neither the the value "report-only" is used to indicate a PRC which has neither the
"install" characteristic nor the "notify" characteristic. However, "install" characteristic nor the "notify" characteristic. However,
instances of such a PRC may be included in synchronous/asynchronous instances of such a PRC may be included in synchronous/asynchronous
reports generated by the PEP. (Note: PRCs having the "install" and/or reports generated by the PEP. (Note: PRCs having the "install" and/or
"notify" characteristics may also be included in reports generated by "notify" characteristics may also be included in reports generated by
the PEP.) the PEP.)
8.4. Mapping of the INSTALL-ERRORS clause 8.4. Mapping of the INSTALL-ERRORS clause
skipping to change at page 26, line 5 skipping to change at page 25, line 5
underlying syntax of Unsigned32), and it has no semantics other than its underlying syntax of Unsigned32), and it has no semantics other than 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.
Note that SPPI does not permit use of the IMPLIED keyword in a PIB-INDEX Note that SPPI does not permit use of the IMPLIED keyword in a PIB-INDEX
clause. clause.
Draft SPPI January 2001 Draft SPPI February 2001
8.6. Mapping of the INDEX clause 8.6. Mapping of the INDEX clause
The INDEX clause is optionally present if a PIB-INDEX clause is present, The INDEX clause is optionally present if a PIB-INDEX clause is present,
and must be absent otherwise. If present, the INDEX clause can contain and must be absent otherwise. If present, the INDEX clause can contain
any number of attributes, and is used only by the algorithmic conversion any number of attributes, and is used only by the algorithmic conversion
of a PIB to a MIB (see Appendix A). of a PIB to a MIB (see Appendix A).
An IMPLIED keyword can be present in an INDEX clause if so desired. An IMPLIED keyword can be present in an INDEX clause if so desired.
skipping to change at page 27, line 5 skipping to change at page 26, line 5
is an alternative to the PIB-INDEX clause and the AUGMENTS clause. is an alternative to the PIB-INDEX clause and the AUGMENTS clause.
Every row definition has exactly one of: a PIB-INDEX clause, an AUGMENTS Every row definition has exactly one of: a PIB-INDEX clause, an AUGMENTS
clause, or an EXTENDS clause. clause, or an EXTENDS clause.
A row definition which has an EXTENDS clause is called a sparse row A row definition which has an EXTENDS clause is called a sparse row
augmentation, where the EXTENDS clause names the row definition which is augmentation, where the EXTENDS clause names the row definition which 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.
Draft SPPI January 2001 Draft SPPI February 2001
A PRC whose row definition is a sparse row augmentation is called a A PRC whose row definition is a sparse row augmentation is called a
sparsely augmenting PRC. Instances of a sparsely augmenting PRC are sparsely augmenting PRC. Instances of a sparsely augmenting PRC are
identified according to the PIB-INDEX clause of the row definition named identified according to the PIB-INDEX clause of the row definition named
in the sparsely augmenting PRC's EXTENDS clause. in the sparsely augmenting PRC's EXTENDS clause.
An instance of a sparsely augmenting PRC can not exist unless a An instance of a sparsely augmenting PRC can not exist unless a
corresponding instance of the PRC which it sparsely augments exists. As corresponding instance of the PRC which it sparsely augments exists. 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. However, an instance of a sparsely augments it is also removed. However, an instance of a
skipping to change at page 28, line 5 skipping to change at page 27, line 5
The UNIQUENESS clause, which is optionally present for any row The UNIQUENESS clause, which is optionally present for any row
definition which has a PIB-INDEX clause, and must be absent otherwise, definition which has a PIB-INDEX clause, and must be absent otherwise,
lists a set of zero or more of the PRC's attributes, for which no two lists a set of zero or more of the PRC's attributes, for which no two
instances of the PRC can have the same set of values. The specified set instances of the PRC can have the same set of values. The specified set
of attributes provide a necessary and sufficient set of values by which of attributes provide a necessary and sufficient set of values by which
to identify an instance of this PRC. The attribute contained in the to identify an instance of this PRC. The attribute contained in the
PIB-INDEX clause may not be present in the UNIQUENESS clause. By PIB-INDEX clause may not be present in the UNIQUENESS clause. By
definition, an attribute may not appear more than once in a UNIQUENESS definition, an attribute may not appear more than once in a UNIQUENESS
clause. A UNIQUENESS clause containing zero attributes indicates that clause. A UNIQUENESS clause containing zero attributes indicates that
Draft SPPI January 2001 Draft SPPI February 2001
it's possible for two instances of the PRC to have identical values for 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 all attributes except, of course, for the one named in the PIB-INDEX
clause. clause.
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.
8.10. Mapping of the PIB-REFERENCES clause 8.10. Mapping of the PIB-REFERENCES clause
skipping to change at page 29, line 5 skipping to change at page 28, line 5
(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
in the PIB-TAG clause. For an example usage of the PIB-TAG clause, see in the PIB-TAG clause. For an example usage of the PIB-TAG clause, see
Appendix B. Appendix B.
9. Mapping of the OBJECT-IDENTITY macro 9. Mapping of the OBJECT-IDENTITY macro
The OBJECT-IDENTITY macro is used in PIB modules to define information The OBJECT-IDENTITY macro is used in PIB modules to define information
about an OBJECT IDENTIFIER assignment. about an OBJECT IDENTIFIER assignment.
Draft SPPI January 2001 Draft SPPI February 2001
10. 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 OBJECT-GROUP a collection of related PRCs and their attributes. The OBJECT-GROUP
macro (directly) defines the collection of attributes which belong to a macro (directly) defines the collection of attributes which belong to a
conformance group. Since each attribute included in the collection conformance group. Since each attribute included in the collection
belongs to a PRC, the collection of related PRCs which belong to a belongs to a PRC, the collection of related PRCs which belong to a
conformance group is also specified (indirectly) as the set of PRCs to conformance group is also specified (indirectly) as the set of PRCs to
which the included attributes belong. which the included attributes belong.
skipping to change at page 30, line 5 skipping to change at page 29, line 5
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.
11.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
Draft SPPI January 2001 Draft SPPI February 2001
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.
11.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
skipping to change at page 31, line 5 skipping to change at page 30, line 5
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.
11.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.
Draft SPPI January 2001 Draft SPPI February 2001
11.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.
11.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
skipping to change at page 32, line 5 skipping to change at page 31, line 5
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 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
Draft SPPI January 2001 Draft SPPI February 2001
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.
12.1.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
skipping to change at page 33, line 5 skipping to change at page 32, line 5
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 January 2001 Draft SPPI February 2001
14. 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 - Change the OID assigned to the MODULE-IDENTITY to be different
skipping to change at page 34, line 5 skipping to change at page 33, line 5
(truncated if necessary to avoid the resulting descriptor being too (truncated if necessary to avoid the resulting descriptor being too
long). The optional number provided by the PIB-ACCESS clause is long). The optional number provided by the PIB-ACCESS clause is
used as the OID for this columnar attribute. If no number 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 provided by the PIB-ACCESS clause, then the default number 127 is
used. 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, 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
Draft SPPI January 2001 Draft SPPI February 2001
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
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.)
Draft SPPI January 2001 Draft SPPI February 2001
15. Appendix B: Example usage of PIB-REFERENCES and PIB-TAG clauses 15. 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 5 skipping to change at page 35, line 5
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
Draft SPPI January 2001 Draft SPPI February 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 5 skipping to change at page 36, line 5
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
Draft SPPI January 2001 Draft SPPI February 2001
SYNTAX ReferenceId SYNTAX ReferenceId
PIB-REFERENCES qosIfQueueTable PIB-REFERENCES 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 }
skipping to change at page 38, line 5 skipping to change at page 37, line 5
PIB-REFERENCES qosIfThresholdTable PIB-REFERENCES 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 January 2001 Draft SPPI February 2001
16. Security Considerations 16. 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.
17. Authors' Addresses 17. Authors' Addresses
Keith McCloghrie Keith McCloghrie
skipping to change at page 39, 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 January 2001 Draft SPPI February 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 40, line 5 skipping to change at page 39, line 5
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-04.txt, August 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.
Draft SPPI January 2001 Draft SPPI February 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, and S. Waldbusser. "Textual Conventions for SMIv2", RFC 2579,
April 1999. 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,
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 January 2001 [INETADDR]
M. Daniele, B. Haberman, S. Routhier and J. Schoenwaelder "Textual
Conventions for Internet Network Addresses", RFC 2851, June 2000.
Draft SPPI February 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 42, 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 January 2001 Draft SPPI February 2001
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
1.1.2 Changes made in version published on 20 September 2000 ...... 3 1.1.2 Changes made in version published on 20 September 2000 ...... 3
1.1.3 Changes made in version published on 13 November 2000 ....... 4 1.1.3 Changes made in version published on 13 November 2000 ....... 4
1.1.4 Changes made in version published 22 January 2000 ........... 4 1.1.4 Changes made in version published 22 January 2001 ........... 4
2 Use of the SMI .................................................. 5 1.1.5 Changes made in version published 20 February 2001 .......... 4
2.1 Terminology Translation ....................................... 5 2 Use of the SMI .................................................. 4
2.2 Overview ...................................................... 5 2.1 Terminology Translation ....................................... 4
3 Structure of this Specification ................................. 6 2.2 Overview ...................................................... 4
4 Definitions ..................................................... 7 3 Structure of this Specification ................................. 5
5 PIB Modules ..................................................... 20 4 Definitions ..................................................... 6
5.1 Importing Definitions ......................................... 20 5 PIB Modules ..................................................... 19
5.2 Reserved Keywords ............................................. 20 5.1 Importing Definitions ......................................... 19
6 Naming Hierarchy ................................................ 21 5.2 Reserved Keywords ............................................. 19
7 Mapping of the MODULE-IDENTITY macro ............................ 21 6 Naming Hierarchy ................................................ 20
7.1 Mapping of the SUBJECT-CATEGORIES clause ...................... 21 7 Mapping of the MODULE-IDENTITY macro ............................ 20
8 Mapping of the OBJECT-TYPE macro ................................ 22 7.1 Mapping of the SUBJECT-CATEGORIES clause ...................... 20
8.1 Mapping of the SYNTAX clause .................................. 22 8 Mapping of the OBJECT-TYPE macro ................................ 21
8.1.1 Counter32 ................................................... 22 8.1 Mapping of the SYNTAX clause .................................. 21
8.1.2 Gauge32 ..................................................... 23 8.1.1 Counter32 ................................................... 21
8.1.3 Opaque ...................................................... 23 8.1.2 Gauge32 ..................................................... 22
8.1.4 Counter64 ................................................... 23 8.1.3 Opaque ...................................................... 22
8.1.5 Integer64 ................................................... 23 8.1.4 Counter64 ................................................... 22
8.1.6 Unsigned64 .................................................. 23 8.1.5 Integer64 ................................................... 22
8.1.7 Provisioning Classes ........................................ 23 8.1.6 Unsigned64 .................................................. 22
8.2 Mapping of the MAX-ACCESS clause .............................. 24 8.1.7 Provisioning Classes ........................................ 22
8.3 Mapping of the PIB-ACCESS clause .............................. 24 8.2 Mapping of the MAX-ACCESS clause .............................. 23
8.4 Mapping of the INSTALL-ERRORS clause .......................... 25 8.3 Mapping of the PIB-ACCESS clause .............................. 23
8.5 Mapping of the PIB-INDEX clause ............................... 25 8.4 Mapping of the INSTALL-ERRORS clause .......................... 24
8.6 Mapping of the INDEX clause ................................... 26 8.5 Mapping of the PIB-INDEX clause ............................... 24
8.7 Mapping of the AUGMENTS clause ................................ 26 8.6 Mapping of the INDEX clause ................................... 25
8.8 Mapping of the EXTENDS clause ................................. 26 8.7 Mapping of the AUGMENTS clause ................................ 25
8.8 Mapping of the EXTENDS clause ................................. 25
8.8.1 Relation between PIB-INDEX, AUGMENTS and EXTENDS clauses 8.8.1 Relation between PIB-INDEX, AUGMENTS and EXTENDS clauses
.............................................................. 27 .............................................................. 26
8.9 Mapping of the UNIQUENESS clause .............................. 27 8.9 Mapping of the UNIQUENESS clause .............................. 26
8.10 Mapping of the PIB-REFERENCES clause ......................... 28 8.10 Mapping of the PIB-REFERENCES clause ......................... 27
8.11 Mapping of the PIB-TAG clause ................................ 28 8.11 Mapping of the PIB-TAG clause ................................ 27
9 Mapping of the OBJECT-IDENTITY macro ............................ 28 9 Mapping of the OBJECT-IDENTITY macro ............................ 27
10 Mapping of the OBJECT-GROUP macro .............................. 29 10 Mapping of the OBJECT-GROUP macro .............................. 28
10.1 Mapping of the OBJECTS clause ................................ 29 10.1 Mapping of the OBJECTS clause ................................ 28
11 Mapping of the MODULE-COMPLIANCE macro ......................... 29
Draft SPPI January 2001 Draft SPPI February 2001
11.1 Mapping of the MODULE clause ................................. 29 11 Mapping of the MODULE-COMPLIANCE macro ......................... 28
11.1.1 Mapping of the MANDATORY-GROUPS clause ..................... 29 11.1 Mapping of the MODULE clause ................................. 28
11.1.2 Mapping of the GROUP clause ................................ 30 11.1.1 Mapping of the MANDATORY-GROUPS clause ..................... 28
11.1.3 Mapping of the OBJECT clause ............................... 30 11.1.2 Mapping of the GROUP clause ................................ 29
11.1.3.1 Mapping of the SYNTAX clause ............................. 30 11.1.3 Mapping of the OBJECT clause ............................... 29
11.1.3.2 Mapping of the WRITE-SYNTAX clause ....................... 31 11.1.3.1 Mapping of the SYNTAX clause ............................. 29
11.1.3.3 Mapping of the PIB-MIN-ACCESS clause ..................... 31 11.1.3.2 Mapping of the WRITE-SYNTAX clause ....................... 30
12 Textual Conventions ............................................ 31 11.1.3.3 Mapping of the PIB-MIN-ACCESS clause ..................... 30
12.1 Mapping of the TEXTUAL-CONVENTION macro ...................... 31 12 Textual Conventions ............................................ 30
12.1.1 Mapping of the SYNTAX clause ............................... 32 12.1 Mapping of the TEXTUAL-CONVENTION macro ...................... 30
12.1.1.1 Sub-typing of Textual Conventions ........................ 32 12.1.1 Mapping of the SYNTAX clause ............................... 31
13 Extending a PIB Module ......................................... 32 12.1.1.1 Sub-typing of Textual Conventions ........................ 31
13.1 OBJECT-TYPE Definitions ...................................... 32 13 Extending a PIB Module ......................................... 31
14 Appendix A: Mapping a PIB to a MIB ............................. 33 13.1 OBJECT-TYPE Definitions ...................................... 31
14 Appendix A: Mapping a PIB to a MIB ............................. 32
15 Appendix B: Example usage of PIB-REFERENCES and PIB-TAG 15 Appendix B: Example usage of PIB-REFERENCES and PIB-TAG
clauses ...................................................... 35 clauses ...................................................... 34
16 Security Considerations ........................................ 38 16 Security Considerations ........................................ 37
17 Authors' Addresses ............................................. 38 17 Authors' Addresses ............................................. 37
18 References ..................................................... 39 18 References ..................................................... 38
19 Full Copyright Statement ....................................... 41 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/