Re: entPhysicalUris object wrap-up

At 06:13 AM 12/9/2004, Juergen Schoenwaelder wrote:
>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.]

I dislike MIB objects that are too general to add value
to a standard.  A URI is very generic.  What kind of 
resource is being identified here? Anything at all the
vendor wants to put there.  I think vendor MIBs are more
appropriate for this usage.  I am happy enough with an
IANA registry for the URNs that SHOULD be used.


>/js

Andy



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