Re: entPhysicalUris object wrap-up

At 06:27 PM 12/8/2004, David T. Perkins wrote:
>HI,
>
>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 ;-)


>Regards,
>/david t. perkins 

thanks,
Andy