Re: [Entmib] entPhysicalUris object wrap-up

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
5) Yes, all MIB purests hate this and similar objects, since
   they are really for "lazy management app writers". However,
   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.

Regards,
/david t. perkins

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