Re: [Entmib] entPhysicalUris object wrap-up

Andy Bierman <> Thu, 09 December 2004 03:43 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id WAA28405 for <>; Wed, 8 Dec 2004 22:43:28 -0500 (EST)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1CcFBH-00066P-Gb; Wed, 08 Dec 2004 22:41:27 -0500
Received: from ([] by with esmtp (Exim 4.32) id 1CcF5C-0005Ob-9R for; Wed, 08 Dec 2004 22:35:10 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id WAA28002 for <>; Wed, 8 Dec 2004 22:35:08 -0500 (EST)
Received: from ([] by with esmtp (Exim 4.33) id 1CcFC4-0002Ml-7j for; Wed, 08 Dec 2004 22:42:18 -0500
Received: from ( by with ESMTP; 08 Dec 2004 20:40:02 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id iB93YYm4026431; Wed, 8 Dec 2004 19:34:35 -0800 (PST)
Received: from ( []) by (MOS 3.4.5-GR) with ESMTP id BBT54397; Wed, 8 Dec 2004 19:34:34 -0800 (PST)
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 08 Dec 2004 19:34:33 -0800
To: "David T. Perkins" <>
From: Andy Bierman <>
Subject: Re: [Entmib] entPhysicalUris object wrap-up
In-Reply-To: < >
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
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:27 PM 12/8/2004, David T. Perkins wrote:
>Ok, you guys caught me not staying current on all messages.
>Now that I've read the I-D and read the messages from approx
>Nov 30 time frame, here are my comments:
>1) The text of the document and the text in the description
>   clause to not seem to be in alignment with reguards to
>   an empty value. Some people like to not create an instance
>   and others like the use of a zero length string. I prefer
>   a zero length string.
>2) The data type is OCTET STRING. I think it should be the
>   proper TC for a "printable US ASCII" (that is, printable
>   7-bit ASCII). URIs cannot contain spaces, and must contain
>   only a subset of characters from printable 7-bit ASCII. 
>3) In RFC 3413, textual convention SNMP-TARGET-MIB::SnmpTagList
>   provides a superset of what is needed for the syntax.
>   It provides support for UTF8 encodings, which are not needed
>   for URIs. It describes leading, trailing, and multiple
>   deliminators (you can't have them!).
>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.

>5) Yes, all MIB purests hate this and similar objects, since
>   they are really for "lazy management app writers". However,

No -- they are for lazy standards writers.

>   this object does provide benefit when it is difficult to
>   determine values of OIDs that are used for the value of
>   object entPhysicalVendorType. Tracking down OID values
>   used for identification can be a time consuming and
>   frustrating job.
>6) I don't remember why it is "read-write" and not read-only,
>   since entPhysicalVendorType is read-only. But maybe someone
>   can provide the reason. (I think if you want to change it,
>   then there should be a path not via SNMP. Because if you
>   can write it via SNMP, a management app must be translating
>   the value of entPhysicalVendorType.)
>So, I suggest that 
>1) the DESCRIPTION text be cleaned up and aligned with
>   the text in the document to say that the object is
>   a) an alternative way to identify the component
>      than the value of entPhysicalVendorType
>   b) potentially a list of alternative identifications
>2) the value of the SYNTAX be changed to DisplayString
>   (and the DESCRPTION clause restrict the values further).
>3) the descriptor be changed to something like
>   "entPhysicalAltIDlist" to better convey it's
>   semantics.
>4) Possibly change it to read-only. (But ignore this
>   if there is a good reason not to.)
>Note, I thought that maybe object entPhysicalAssetID could
>do double duty and hold the URI value, but it is too small.
>So, again, I feel that the WG made the best choices to
>create a new neutral object. 
>On Wed, 8 Dec 2004, Andy Bierman wrote:
>> At 01:27 PM 12/8/2004, David T. Perkins wrote:
>> >HI,
>> >
>> >I somehow missed the motivating reasons to go from a 
>> >an object that can provide a alternative identification
>> >to an object that supports only CLEI codes.
>> IMO, standard objects add value by providing common, well-defined 
>> semantics.  A list of undefined, unconstrained "alternate identifiers"
>> doesn't meet this criteria.  If the DESCRIPTION clause somehow 
>> constrained (and guided) implementations with a finite set of
>> alternatives, that would be fine.  Rationale for each alternative 
>> would need to be documented as well.  I strongly oppose doing
>> all this "alternative identifier" work as part of the 2737 update, 
>> because it isn't well-defined yet.
>> Andy
>I believe that Andy's objection can be resolved by a registry
>at IANA for URIs for this object.

yep -- that works for me ;-)

>/david t. perkins 


Entmib mailing list