Re: [Entmib] entPhysicalUris object wrap-up

Andy Bierman <> Thu, 09 December 2004 17:55 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id MAA15591 for <>; Thu, 9 Dec 2004 12:55:49 -0500 (EST)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1CcSLt-0001Eu-MQ; Thu, 09 Dec 2004 12:45:17 -0500
Received: from ([] by with esmtp (Exim 4.32) id 1CcSA7-0006HK-4H for; Thu, 09 Dec 2004 12:33:07 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id MAA12825 for <>; Thu, 9 Dec 2004 12:33:04 -0500 (EST)
Received: from ([] by with esmtp (Exim 4.33) id 1CcSH7-00023j-7a for; Thu, 09 Dec 2004 12:40:22 -0500
Received: from ( by with ESMTP; 09 Dec 2004 09:35:26 -0800
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id iB9HWRm4017668; Thu, 9 Dec 2004 09:32:27 -0800 (PST)
Received: from ( []) by (MOS 3.4.5-GR) with ESMTP id BBT96881; Thu, 9 Dec 2004 09:32:28 -0800 (PST)
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 09 Dec 2004 09:32:27 -0800
To: Kaj Tesink <>
From: Andy Bierman <>
Subject: Re: [Entmib] entPhysicalUris object wrap-up
In-Reply-To: <>
References: <p0620073ebdde00b935ad@[]> <> <> <p0620073ebdde00b935ad@[]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
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 08:57 AM 12/9/2004, Kaj Tesink wrote:
>At 08:23 AM 12/9/2004, Margaret Wasserman wrote:
>>Hi All,
>>>At 06:27 PM 12/8/2004, David T. Perkins wrote:
>>>>4) This issue has been discussed many times. As was pointed out
>>>>   by Kaj in an earlier message, the approach choosen was the
>>>>   best solution and was acceptable to all on the WG mailing
>>>>   list. I don't believe that it is fair to undo what was
>>>>   hammered out over a long period of time where:
>>>>   a) it was demonstrated that use of an
>>>>      "alternative identification" scheme was needed
>>>>      and provided value at little cost.
>>>>   b) the scheme was neutral
>>>>   c) the scheme provided support for multiple competing
>>>>      alternative identifications (limited only by the size
>>>>      of the object)
>>>>   d) the cost to support a "non implementation" was next
>>>>      to nothing
>>>I missed all this on the mailing list.
>>>I'll let the WG Chair decide, and I'll wait
>>>on any edits.
>>Kaj's document was never a WG document and, IMO, the Entity MIB WG did not make any official decisions about these objects before we decided to add them to the Entity MIB.  I know that a few people used the Entity MIB mailing list to discuss Kaj's personal submission, and I thought that was fine.  But, I didn't track the discussion closely enough to have a mental record of it, and no official consensus calls were made about it.
>>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.   How are applications supposed to know that this contains?  Would it be possible to compare these strings?  Use them as URLs?  Or do anything with them besides just display them on a screen?
>>I am not actually religious about this, though.  So, if that's what the WG thinks is the best way to represent this object, so be it.
>fair enough, so let me recall again how we got here:
>1. the original proposal was for some simple (i thought :-)
>   object additions to be added to the entmib itself.
>2. support for the objects was demonstrated over time,
>   but there were 2 issues:
>     a) status of the entmib (trying for Draft)
>     b) the CLEI object representation
>3. (2a) was solved by coming up with a separate
>     supplemental MIB, a procedural move.
>4. the supplemental MIB had to be a personal
>     submission due to the procedural issue of wg charter.
>5. later, the need for a supplemental MIB was removed
>     since entmib stays at Proposed. thus,
>     removing the procedural issues, and
>     we are back to the original objects.
>6. (2b) went thru an interesting discussion on concerns
>     on how best to represent T1.213 format. this
>     resulted eventually IMHO in an elegant proposal
>     by Juergen and Dave using the URI representation.
>     note that the object's nature is Identification; one
>     advantage also pointed out by Juergen is that the URI
>     approach allows identification not only of CLEIs
>     but of other things as well, avoiding the need to
>     rework the entmib in the future on this aspect.
>7. to support (6) we needed a URN request for CLEI name space.
>     this request has been posted using appropriate format
>     and 3406 process.
>8. irrespective of (6) and (7), the use and application of
>     CLEIs themselves are perfectly clear; see T1.213 for
>     details, and years of use.
>so, based on (1)-(8) i think Dave's observations above
>are reasonable.
>(i'd not suse in Dave's item (c) the word 'competing';
>rather it accommodates identifiers for different applications,
>but i assume that that was meant).
>the string in the Uri object, at least for the CLEI
>application is well formatted and defined. IANA registries
>  and
>are there to help sort things out, no?

The documentation I was provided for this object (especially the 
OBJECT-TYPE macro) did not convey any of this info, rationale, 
or references.  If it did, I wouldn't have objected to the
vagueness of the object.

I still don't understand why we need a list of URIs per entity.
This adds complexity.  It there a compelling need for multiple
URIs per entity?



Entmib mailing list