Subject: Re: [Entmib] IMPORTANT -- Proposed change to Entity Sensor MIB

From: Randy Presuhn <[email-masked]>
Date: Tue, 8 Oct 2002 07:27:31 -0700 (PDT)

Hi -

> Message-Id: <[email-masked]>
> To: [email-masked]
> From: Margaret Wasserman <[email-masked]>
> 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
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------
_______________________________________________
Entmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/entmib

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 08 Oct 2002 09:50:18 -0700

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.

> Randy Presuhn          BMC Software, Inc.  SJC-1.3141

Regards,
/david t. perkins

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 08 Oct 2002 09:50:18 -0700

HI,

Regards,
/david t. perkins

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Oct 2002 22:02:10 +0200

>>>>> David T Perkins writes:

David> I do agree with Randy, Juergen, and others that the MIB tools
David> should be updated, and note that this "problem" will occur much
David> more often when using the proposed SMI in SMIng.

You seem to assume that folks who produce compilers are not able to
learn from past mistakes. If that is true, we better give up.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Oct 2002 22:02:10 +0200

/js

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 08 Oct 2002 14:33:24 -0700

HI,

>learn from past mistakes. If that is true, we better give up.
I believe that the authors didn't know that they had a requirement,
and they did a design without taking that requirement into consideration.
Adding support for the requirement in probably all cases meant(means)
major design changes, which are disruptive.

We know better now the requirements, I hope.

Regards,
/david t. perkins

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 08 Oct 2002 14:33:24 -0700

HI,

Regards,
/david t. perkins