Re: [Entmib] entPhysicalUris object wrap-up
Andy Bierman <abierman@cisco.com> Thu, 09 December 2004 03:43 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 WAA28405 for <entmib-archive@lists.ietf.org>; Wed, 8 Dec 2004 22:43:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcFBH-00066P-Gb; Wed, 08 Dec 2004 22:41:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcF5C-0005Ob-9R for entmib@megatron.ietf.org; Wed, 08 Dec 2004 22:35:10 -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 WAA28002 for <entmib@ietf.org>; Wed, 8 Dec 2004 22:35:08 -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 1CcFC4-0002Ml-7j for entmib@ietf.org; Wed, 08 Dec 2004 22:42:18 -0500
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 08 Dec 2004 20:40:02 +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 iB93YYm4026431; Wed, 8 Dec 2004 19:34: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 BBT54397; Wed, 8 Dec 2004 19:34:34 -0800 (PST)
Message-Id: <4.3.2.7.2.20041208192619.0260fd50@fedex.cisco.com>
X-Sender: abierman@fedex.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 08 Dec 2004 19:34:33 -0800
To: "David T. Perkins" <dperkins@dsperkins.com>
From: Andy Bierman <abierman@cisco.com>
Subject: Re: [Entmib] entPhysicalUris object wrap-up
In-Reply-To: <Pine.LNX.4.10.10412081743530.576-100000@shell4.bayarea.net >
References: <4.3.2.7.2.20041208160349.025f4d60@fedex.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
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: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 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib
- [Entmib] entPhysicalUris object wrap-up Andy Bierman
- Re: [Entmib] entPhysicalUris object wrap-up Margaret Wasserman
- RE: [Entmib] entPhysicalUris object wrap-up Wijnen, Bert (Bert)
- Re: [Entmib] entPhysicalUris object wrap-up Juergen Schoenwaelder
- Re: [Entmib] entPhysicalUris object wrap-up David T. Perkins
- Re: [Entmib] entPhysicalUris object wrap-up Andy Bierman
- Re: [Entmib] entPhysicalUris object wrap-up David T. Perkins
- Re: [Entmib] entPhysicalUris object wrap-up Andy Bierman
- Re: [Entmib] entPhysicalUris object wrap-up Margaret Wasserman
- Re: [Entmib] entPhysicalUris object wrap-up Juergen Schoenwaelder
- Re: [Entmib] entPhysicalUris object wrap-up Kaj Tesink
- Re: [Entmib] entPhysicalUris object wrap-up Andy Bierman
- Re: [Entmib] entPhysicalUris object wrap-up Kaj Tesink
- RE: [Entmib] entPhysicalUris object wrap-up Kaj Tesink
- Re: [Entmib] entPhysicalUris object wrap-up Andy Bierman
- Re: [Entmib] entPhysicalUris object wrap-up Kaj Tesink
- Re: [Entmib] entPhysicalUris object wrap-up Kaj Tesink