[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: [802.1] P802.1b/D0
Hi,
I could be wrong, but I was of the impression that you could not use the same registered descriptors, such as sampleMIB, and assign them new OIDs.
From RFC2578, section 3.6 (from Mike's mail below)
"the descriptor can not be changed nor associated with any other registration."
And I would think that would be true for migrating a mib from experimental to mib-2; wouldn't the registered descriptors AND the OIDs in the migrated mib need to be changed?
Or is this another instance of a restriction being relaxed to become a Consistency Language Rule to be overridden when convenient? ;-)
dbh
> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: Monday, December 23, 2002 4:30 PM
> To: MIB Doctors (E-mail)
> Subject: 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
>
>
>