Re: [Entmib] entPhysicalUris object wrap-up

Andy Bierman <> Thu, 09 December 2004 15:28 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id KAA01009 for <>; Thu, 9 Dec 2004 10:28:59 -0500 (EST)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1CcQCT-00039e-BX; Thu, 09 Dec 2004 10:27:25 -0500
Received: from ([] by with esmtp (Exim 4.32) id 1CcQAP-0002kk-JF for; Thu, 09 Dec 2004 10:25:17 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id KAA00376 for <>; Thu, 9 Dec 2004 10:25:16 -0500 (EST)
Received: from ([] by with esmtp (Exim 4.33) id 1CcQHO-0007Qn-Pp for; Thu, 09 Dec 2004 10:32:32 -0500
Received: from ( by with ESMTP; 09 Dec 2004 08:30:17 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id iB9FOZm4016865; Thu, 9 Dec 2004 07:24:35 -0800 (PST)
Received: from ( []) by (MOS 3.4.5-GR) with ESMTP id BBT84388; Thu, 9 Dec 2004 07:24:41 -0800 (PST)
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 09 Dec 2004 07:24:41 -0800
From: Andy Bierman <>
Subject: Re: [Entmib] entPhysicalUris object wrap-up
In-Reply-To: <20041209141310.GB3095@james>
References: <p0620073ebdde00b935ad@[]> <> <> <p0620073ebdde00b935ad@[]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: Margaret Wasserman <>,
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Entity MIB WG <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

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.



>Juergen Schoenwaelder               International University Bremen
><>     P.O. Box 750 561, 28725 Bremen, Germany 

Entmib mailing list