[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FW: [802.1] P802.1b/D0
On Mon, 23 Dec 2002, Randy Presuhn wrote:
> > From: "David T. Perkins" <dperkins@dsperkins.com>
[ ... ]
> > Is it
> > 1) several different OID values being associated with the same
> > object type (notification type, etc)
>
> yes
>
> ...
> > If it is the first, then there is a big problem. ...
>
> I don't see how it's any different from the same OBJECT-TYPE
> being registered under experimental and later being re-registered
> somewhere else. The experimental registration doesn't just go away.
I agree that there is no problem (as far as the SMI is concerned) with
taking a given set of definitions (object types, notification types,
conformance statements, and capabilities) that are registered under the
experimental subtree and creating a new set of objects that are defined
exactly the same way (same descriptors, etc.) except for being registered
under mib-2. However, I would NOT say that a given experimental object
is "the same object" as its mib-2 counterpart. I would say that they are
two different objects. That seems to be what Randy's comment below is
saying: "different addresses refer to identical houses (which are
nonetheless not the same house)."
On Mon, 23 Dec 2002, Harrington, David wrote:
> -----Original Message-----
> From: Randy Presuhn [mailto:rpresuhn@bmc.com]
[ ... ]
> > I do think the analogy in the "migration" material in 12.3
> > (d) isn't quite right. One doesn't really create "a second
> > Object Identifiervalue to identify the same object".
> > Rather, one creates a second object whose definition is
> > identical to the first, rather like addresses in suburbs
> > where different addresses refer to identical houses (which
> > are nonetheless not the same house.)
>
> Your discussion verges on the philosophical. I am more interested in
> providing IEEE mib developers some (pointers to) concrete guidance of
> mib development best practices.
I don't think Randy's point is just a philosophical point. I think
the point is that the SMI provides NO WAY to register one definition
with more than one OBJECT IDENTIFIER value, and so the "migration"
material in 12.3 (d) is simply wrong with respect to OBJECT IDENTIFIER
values associated with OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE,
OBJECT-GROUP, OBJECT-IDENTITY, NOTIFICATION-GROUP, MODULE-COMPLIANCE,
or AGENT-CAPABILITIES invocations. One must instead create new
definitions, perhaps with identical text to the old definitions, and
register those new definitions under different OID values.
Since IEEE comments require a specific problem description and a
proposed remedy, let me take a stab at that.
------------------------------------------------------------------------
Problem description:
The first sentence of the "migration" material in 12.3 (d), viz.,
If migration is considered desirable, there is no requirement
to remove the old Object Identifier values; it is possible
to add a second Object Identifier value to identify the same
object.
contradicts the following rule from RFC 2578, Section 3.6, that
applies to SNMP MIBs:
(1) registration: the definition of a particular item is registered as
a particular OBJECT IDENTIFIER value, and associated with a
particular descriptor. After such a registration, the semantics
thereby associated with the value are not allowed to change, the
OBJECT IDENTIFIER can not be used for any other registration, and
the descriptor can not be changed nor associated with any other
registration. The following macros result in a registration:
OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-GROUP,
OBJECT-IDENTITY, NOTIFICATION-GROUP, MODULE-COMPLIANCE,
AGENT-CAPABILITIES.
The difficulty is that it is not legal for a given object definition
to be associated with more than one object identifier value. The
accepted procedure is to create a new object definition with the
essentially the same text, but residing in a different information
module and assigned a different OBJECT IDENTIFIER value. For example,
when an experimental IETF MIB module registered under the experimental
subtree is to be put on the standards track, a new MIB module with
the same definitions would be registered under the mib-2 tree (see
RFC 2578, Section 4). For example, the following experimental module
SAMPLE-EXPERIMENTAL-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
experimental
FROM SNMPv2-SMI
OBJECT-GROUP
FROM SNMPv2-CONF;
sampleMib MODULE-IDENTITY
LAST-UPDATED "200212231930Z" -- December 23, 2002
ORGANIZATION "[ ... ]"
CONTACT-INFO "[ ... ]"
DESCRIPTION "A sample experimental MIB module"
REVISION "200212231930Z" -- December 23, 2002
DESCRIPTION "Initial experimental version"
::= { experimental YYY } -- replace YYY with IANA-assigned number
sampleObjects OBJECT IDENTIFIER ::= { sampleMib 1 }
sampleGroups OBJECT IDENTIFIER ::= { sampleMib 2 }
sampleTestPatternMode OBJECT-TYPE
SYNTAX INTEGER {
none(1),
squareWave(2),
prbs31(3),
mixedFrequency(4)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A sample object"
::= { sampleObjects 1 }
sampleGroup OBJECT-GROUP
OBJECTS {
sampleTestPatternMode
}
STATUS current
DESCRIPTION
"A sample object group"
::= { sampleGroups 1 }
END
would be turned into something like this
SAMPLE-STANDARD-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
mib-2
FROM SNMPv2-SMI
OBJECT-GROUP
FROM SNMPv2-CONF;
sampleMib MODULE-IDENTITY
LAST-UPDATED "200212232030Z" -- December 23, 2002
ORGANIZATION "[ ... ]"
CONTACT-INFO "[ ... ]"
DESCRIPTION "A sample standards-track MIB module"
REVISION "200212232030Z" -- December 23, 2002
DESCRIPTION "Initial standards-track version"
::= { mib-2 XXX } -- replace XXX with IANA-assigned number
sampleObjects OBJECT IDENTIFIER ::= { sampleMib 1 }
sampleGroups OBJECT IDENTIFIER ::= { sampleMib 2 }
sampleTestPatternMode OBJECT-TYPE
SYNTAX INTEGER {
none(1),
squareWave(2),
prbs31(3),
mixedFrequency(4)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A sample object"
::= { sampleObjects 1 }
sampleGroup OBJECT-GROUP
OBJECTS {
sampleTestPatternMode
}
STATUS current
DESCRIPTION
"A sample object group"
::= { sampleGroups 1 }
END
with the latter being published as a new MIB module.
Note that the definitions registered under the experimental
subtree are not deleted; the SMI does not permit that (see
RFC 2578 Section 10). The STATUS of those definitions
would, however, most likely be changed to obsolete.
Note also that this migration is not without cost. In particular,
any existing implementations of the experimental MIB module would
have to be updated to support the new standards-track MIB module,
because SNMP requests refer to object using their assigned OBJECT
IDENTIFIER values. It is probably not a good idea (and may not
even be practial) to attempt to migrate a MIB module that has
been widely deployed.
Proposed remedy:
Replace the material in 12.3 (d) by the following text:
If migration is considered desirable, there is no requirement
to remove the old Object Identifier values; indeed, for objects
defined in SNMP MIB modules it is not permissible to do so, nor
may such objects be associated with more than Object Identifier
value. Instead, new definitions must be created and registered
under the desired Object Identifier tree.
------------------------------------------------------------------------
Additional wordsmithing/comments welcome; but I think that whatever
text is proposed for 12.3 (d) ought not to minimize the cost.
In particular ...
On Mon, 23 Dec 2002, David T. Perkins wrote:
> New definitions to "tidy up" most likely have higher costs
> than what ever benefit they provide.
I most certainly agree with that. Especially if the old definitions
have seen significant deployment in the field. I've seen some
discussion along these lines in the IPCDN mail archive, and I hope
that they keep this in mind.
//cmh