Re: [Entmib] entPhysicalUris object wrap-up

Andy Bierman <abierman@cisco.com> Thu, 09 December 2004 15:28 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01009 for <entmib-archive@lists.ietf.org>; Thu, 9 Dec 2004 10:28:59 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcQCT-00039e-BX; Thu, 09 Dec 2004 10:27:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcQAP-0002kk-JF for entmib@megatron.ietf.org; Thu, 09 Dec 2004 10:25:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00376 for <entmib@ietf.org>; Thu, 9 Dec 2004 10:25:16 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcQHO-0007Qn-Pp for entmib@ietf.org; Thu, 09 Dec 2004 10:32:32 -0500
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 09 Dec 2004 08:30:17 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB9FOZm4016865; Thu, 9 Dec 2004 07:24:35 -0800 (PST)
Received: from abierman-xp.cisco.com (sjc-vpn4-642.cisco.com [10.21.82.130]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BBT84388; Thu, 9 Dec 2004 07:24:41 -0800 (PST)
Message-Id: <4.3.2.7.2.20041209071848.0262c6c8@fedex.cisco.com>
X-Sender: abierman@fedex.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 09 Dec 2004 07:24:41 -0800
To: j.schoenwaelder@iu-bremen.de
From: Andy Bierman <abierman@cisco.com>
Subject: Re: [Entmib] entPhysicalUris object wrap-up
In-Reply-To: <20041209141310.GB3095@james>
References: <p0620073ebdde00b935ad@[192.168.2.2]> <4.3.2.7.2.20041208160349.025f4d60@fedex.cisco.com> <4.3.2.7.2.20041208192619.0260fd50@fedex.cisco.com> <p0620073ebdde00b935ad@[192.168.2.2]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: Margaret Wasserman <margaret@thingmagic.com>, entmib@ietf.org
X-BeenThere: entmib@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Entity MIB WG <entmib.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/entmib>, <mailto:entmib-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:entmib@ietf.org>
List-Help: <mailto:entmib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/entmib>, <mailto:entmib-request@ietf.org?subject=subscribe>
Sender: entmib-bounces@ietf.org
Errors-To: entmib-bounces@ietf.org

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 

_______________________________________________
Entmib mailing list
Entmib@ietf.org
https://www1.ietf.org/mailman/listinfo/entmib