Re: entPhysicalUris object wrap-up

On Thu, Dec 09, 2004 at 08:23:55AM -0500, Margaret Wasserman wrote:
 
> Personally, I agree with Andy that it is a bit lame to have an 
> undiscriminated, unformatted, loosely specified string in the middle 
> of this MIB.

This is I think a total mis-understanding of the MIB object. You may
not like this object, but saying it is an undiscriminated, unformatted,
loosely specified string really missed the point.

> How are applications supposed to know that this contains?  

The object contains URIs separated by white space. Meaning is attached
to URIs and applications have to understand the URIs (such as CLEI code
URNs). If they do not understand the URI semantics, the URIs can still
be displayed as a service to the operator who has to write down the
hardware identification into an email message or speak it into a phone.

> Would it be possible to compare these strings?

This boils down to comparisons of URIs. In the case of CLEI code URNs,
I would not see any problem.

> Use them as URLs?  Or do anything with them besides just display 
> them on a screen?

See above. And yes, displaying a hardware identification number 
such as a CLEI code on screen can be useful. Note that most of the
SnmpAdminString objects in the EntPhysicalEntry mainly serve the 
purpose of being displayed to the operator. (Unless I am missing
some magic hidden algorithm burried deeply inside of the MIB.)

Note: I do not claim that we have to add this object. There might 
be reasons not do so and there are of course reasons why we ended 
up with what we have on the table. What I dislike, however, are 
general and unsubstantiated statements.

As far as I understand things, Andy dislikes the fact that the object 
allows arbitrary URIs and thus naming schemes. So we may have to 
reconsider the discussion that lead us to use URIs in the first place, 
namely to side-step the fact that these codes are not "openly" 
available. If that is now not a problem anymore, we can reconsider 
the URI notation we came up with to side-step the issue and have
something that is less fancy. [But in any case, this is all about
syntax and does not really change what a management application can
or cannot do with a CLEI code.]

/js

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