Re: IMPORTANT -- Proposed change to Entity Sensor MIB

HI,

On the following, there are several levels of support needed in
tools to support identical object descriptors in different MIB
modules.
First, some tools cannot cope with compiling a collection of MIB
modules that have identical object descriptors. This is really
broken, and such tools should carry a mark of shame on them.

Secondly, there are many types of outputs from MIB compilers. One
type of output is C code and data structs used in building an
agent or management application. Typically, the default identifiers
for variables and function names for the C code are simple
transforms of the object descriptors with out regards to the
MIB module where the objects types are defined. This works
adequately when there is no duplication of object descriptors,
and also when the generated C variables are not used in the
same scope. However, there is no guarantee that no clash will
occur. Thus, the "higher quality" MIB compiler will allow its
transform of object descriptors to C variables and functions
to be modified as a configuration parameter in its running.

As to the request, I suggest that the pragmatic path be followed
and the descriptors changed in the sensor MIB module before it
is published.  
I do agree with Randy, Juergen, and others that the MIB
tools should be updated, and note that this "problem" will
occur much more often when using the proposed SMI in SMIng.

At 07:27 AM 10/8/2002 -0700, Randy Presuhn wrote:
>Hi -
>
>> Message-Id: <[email protected]>
>> To: [email protected]
>> From: Margaret Wasserman <[email protected]>
>> Subject: [Entmib] IMPORTANT -- Proposed change to Entity Sensor MIB
>> Date: Tue, 08 Oct 2002 10:01:03 -0400
>...
>> This change was proposed because of our current object name
>> overlap with Cisco's proprietary sensor MIB, which causes
>> problems for anyone who tries to implement both MIBs on the
>> same device and/or manage a device that includes both MIBs.
>
>Only if they're using broken tools.  I think we should not
>indulge in gyrations like this simply so folks can continue
>using broken tools.
>
>> Using the same object names (even though the module name
>> is different) causes a problem for various tools that assume
>> that object names will all be globally unique.
>> 
>
>Making this change would do no good.  It would support the
>continued use of broken tools, which is arguable bad.
>
>> Bert is checking with the IESG to determine whether the
>> proposed object name changes would require the MIB to be
>> re-cycled through the IESG, or whether they could be done
>> as part of the RFC editing process.
>> 
>> Before we make any changes, though, we'd like to know if the
>> group does or doesn't support making this change.  Choices
>> are:
>> 
>>       - Leave the MIB as-is.
>>       - Change the names only if it will not require
>>               re-submission to the IESG.
>>       - Change the names, even if re-submission to the
>>               IESG would be required.
>> 
>> Thoughts?
>...
>
>My choice would be to
>Leave it as it is.
>
> Randy Presuhn          BMC Software, Inc.  SJC-1.3141



Regards,
/david t. perkins