Re: Entity MIB v3

On Tue, Nov 30, 2004 at 11:37:31AM -0500, David B Harrington wrote:
 
> It could be useful to identify something like a mfg code or OEM part
> number, to make it easier to identify problem components for things
> like product recalls. Enterasys uses a proprietary MIB object for this
> type of information (amongst other info). In some cases, other SDOs
> define standards for the semantics. The information is not necessarily
> something that we are likely to reach standardization on. This
> information is likely to be available via the CLI or an HTML-based
> interface, and it might be useful to define an SNMP-equivalent, but a
> URI is not a normal SNMP construct.

I read this as an argument in favor of the entPhysicalUris addition.
 
> I agree there is the possibility of namespace conflict, and the
> usefulness of this object to a vendor-neutral application is
> questionable. 

Please someone explain to me the namespace conflict you are seeing.
 
> I don't object to removing this object from this module. For those who
> wish to use a CLIE URI, I suggest they write an RFC with the CLIE
> codes and include a mib module with the URI object to augment the
> entity mib table. Hopefully, they will also include an object to
> identify the namespace.

Now you seem to argue against the entPhysicalUris addition. (I fail
to see why you need an object to identify a namespace since the
namespace should be clear from the URI. But then I admit that I fail
to understand the point raised above, so I am obviously missing some
pieces here.)

So, Dave, what do you want to tell us?

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany