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

From: Margaret Wasserman <[email-masked]>
Date: Tue, 08 Oct 2002 10:01:03 -0400

Hi All,

Bob Burget has proposed a change to the Entity Sensor MIB,
specifically:

To change 'entSensor' to 'entPhySensor' in all relevant
descriptors.

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.

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.

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?

Margaret

_______________________________________________
Entmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/entmib

---

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

>>>>> Margaret Wasserman writes:

Margaret> Using the same object names (even though the module name is
Margaret> different) causes a problem for various tools that assume
Margaret> that object names will all be globally unique.

Tools that rely on globally unique names are broken. Unless there is
evidence that the majority of people use broken tools, I think we
should not start to change names just because we have clashes with
some proprietary MIBs.

If a company decides that standards support is not important enough to
get the tools they use fixed, then that is a business decisions which
is interesting itself in its interpretation.

/js

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

---

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

/js

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 08 Oct 2002 13:06:32 -0400

>should not start to change names just because we have clashes with

The Wind River code generator (AKA the former Epilogue Envoy
product) is broken in this way.  If you use it to generate
code for two MIBs will the same object descriptors, it will
generate conflicting function names.

Some of the tools that I have heard are "broken" include:

         SNMP Research's Emanate code generator
         HP OpenView

..but, I can't verify this from my own experience.

Also, using non-globally-unique names will make it harder to
access this MIB from any of the MIB browser products I've used,
if the conflicting Cisco-proprietary MIB is also loaded.

I'm still not sure, though, how big of a problem this is or
isn't.  How many of the target devices for this MIB will
implement both this MIB and the Cisco-proprietary version?

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 08 Oct 2002 13:06:32 -0400

Margaret