[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: [802.1] P802.1b/D0
Mike,
Can I take your proposal for comments and forward it to the IEEE folks? I think that we do have rough consensus that the migration procedure recommended in Section 12.3 of the IEEE document is to be discouraged.
This would not be a formal liaison, or even a formal comment as the IEEE document is at its first version. I would certainly mention that the issue was discussed among the MIB experts.
Other folks, strong objections?
Dan
> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: Monday, December 23, 2002 11: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
>
>
>