Re: [Entmib] entPhysicalUris object wrap-up

Juergen Schoenwaelder <> Thu, 09 December 2004 14:20 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id JAA24039 for <>; Thu, 9 Dec 2004 09:20:14 -0500 (EST)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1CcP7k-0000mC-LJ; Thu, 09 Dec 2004 09:18:28 -0500
Received: from ([] by with esmtp (Exim 4.32) id 1CcP3A-0008Bg-Ce for; Thu, 09 Dec 2004 09:13:44 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id JAA23581 for <>; Thu, 9 Dec 2004 09:13:43 -0500 (EST)
Received: from ([]) by with esmtp (Exim 4.33) id 1CcPA9-0005rX-Fa for; Thu, 09 Dec 2004 09:20:58 -0500
Received: from localhost ( []) by (Postfix) with ESMTP id 51D40374B; Thu, 9 Dec 2004 15:13:11 +0100 (CET)
Received: from ([]) by localhost (demetrius []) (amavisd-new, port 10024) with ESMTP id 28165-08; Thu, 9 Dec 2004 15:13:10 +0100 (CET)
Received: from james ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTP id 592923745; Thu, 9 Dec 2004 15:13:10 +0100 (CET)
Received: from schoenw by james with local (Exim 4.34) id 1CcP2c-0000rD-78; Thu, 09 Dec 2004 15:13:10 +0100
Date: Thu, 9 Dec 2004 15:13:10 +0100
From: Juergen Schoenwaelder <>
To: Margaret Wasserman <>
Subject: Re: [Entmib] entPhysicalUris object wrap-up
Message-ID: <20041209141310.GB3095@james>
Mail-Followup-To: Margaret Wasserman <>, Andy Bierman <>,
References: <> <> <p0620073ebdde00b935ad@[]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p0620073ebdde00b935ad@[]>
User-Agent: Mutt/1.5.6+20040907i
X-Virus-Scanned: by amavisd-new 20030616p5 at
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc:, Andy Bierman <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Entity MIB WG <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

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.]


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

Entmib mailing list