RE: [Entmib] entity mib support for tcif
Andy Bierman <abierman@cisco.com> Thu, 02 October 2003 17:26 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14699 for <entmib-archive@odin.ietf.org>; Thu, 2 Oct 2003 13:26:23 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57DF-0005Gx-VB for entmib-archive@odin.ietf.org; Thu, 02 Oct 2003 13:26:02 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92HQ1w6020253 for entmib-archive@odin.ietf.org; Thu, 2 Oct 2003 13:26:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57DF-0005GV-LZ; Thu, 02 Oct 2003 13:26:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57Cg-0005Ft-Px for entmib@optimus.ietf.org; Thu, 02 Oct 2003 13:25:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14643 for <entmib@ietf.org>; Thu, 2 Oct 2003 13:25:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A57Ce-0003n0-00 for entmib@ietf.org; Thu, 02 Oct 2003 13:25:24 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A57Cc-0003ml-00 for entmib@ietf.org; Thu, 02 Oct 2003 13:25:23 -0400
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.9/8.12.6) with ESMTP id h92HOeJs024776; Thu, 2 Oct 2003 10:24:40 -0700 (PDT)
Received: from ABIERMAN-W2K.cisco.com (sjc-vpn3-351.cisco.com [10.21.65.95]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMT27244; Thu, 2 Oct 2003 10:24:39 -0700 (PDT)
Message-Id: <4.3.2.7.2.20031002101643.027ea170@fedex.cisco.com>
X-Sender: abierman@fedex.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 02 Oct 2003 10:20:12 -0700
To: Kaj Tesink <kaj@research.telcordia.com>
From: Andy Bierman <abierman@cisco.com>
Subject: RE: [Entmib] entity mib support for tcif
Cc: entmib@ietf.org
In-Reply-To: <4.3.2.7.2.20031001171034.01610dd8@128.96.81.11>
References: <Pine.LNX.4.10.10309071508120.6520-100000@shell4.bayarea.ne t> <93401232EABAAB4EA430E13ECC701CCF2A0D3E@yorktown.pedestalnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: entmib-admin@ietf.org
Errors-To: entmib-admin@ietf.org
X-BeenThere: entmib@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/entmib>, <mailto:entmib-request@ietf.org?subject=unsubscribe>
List-Id: IETF Entity MIB WG <entmib.ietf.org>
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>
At 02:33 PM 10/1/2003, Kaj Tesink wrote: >folks, i consulted with some interested parties directly. >my impression is that we could do the following: > >1) to support the Manufacture Date we'll need a new object > entPhysicalMfgDate that augments the entPhysicalTable > >2) a) to support the CLEI we have the option of using > entPhysicalVendorType with the elegant method pointed out by Dave; > the only drawback is that this use theoretically may clash with > other uses people may have had in mind. > > b) alternatively, we can define a new entPhysicalVendorType2 > and still apply Dvae's method. > >3) from a documentation perspective we have the following options: > a) fold into the existing document; this may jeopardize the entmib > going to Draft > b) create a supplemental entmib > c) create a supplemental entmib that will be folded into the > main document once the specs reach the same standainzation status I prefer (3b). There are lots of MIB modules that import something from ENTITY-MIB (usually entPhysicalIndex) and none of these RFCs can advance to DS until the Entity MIB advances. I think it will take a long time to get the supplemental objects published, and then it will take at least a year to get another implementation report together. >all options work for me although on reflection >i have a slight pref for 2a) over 2b) based on distaste of object proliferation. > >any preferences out there? > > >kaj Andy >At 03:29 PM 9/7/2003 -0700, David T. Perkins wrote: >[snip] > > > >>And responding to Faye's question.... >>If a well know prefix is used, this does not create any additional >>work for vendors. That is, they already have to "create an OID registry" >>to support object entPhysicalVendorType. And for management platforms >>that want to use CLEI codes, a standard prefix (and encoding rules) >>allows them to "extract" a CLEI code from the value of >>entPhysicalVendorType, and all other management platforms to be >>blissfully unaware of CLEI codes. >> >>On Sun, 7 Sep 2003, Faye Ly wrote: >>> Just playing the devil's advocate! On the other hand, CLEI code is a >>> fixed string and although it is more elegant to maintain an OID registry >>> per vendor but this might grow for a NMS that manages multiple vendors. >>> A fixed string as an augmented table to the physical entity table is >>> more straightforward to support. >>> >>> -faye >>> >>> -----Original Message----- >>> From: C. M. Heard [mailto:heard@pobox.com] >>> Sent: Sunday, September 07, 2003 12:59 AM >>> To: entmib@ietf.org; Kaj Tesink; Giamboi, Anthony; Lam, Hing-Kam (Kam); >>> Faye Ly; Juergen Schoenwaelder; Margaret Wasserman; David T. Perkins; >>> Wijnen, Bert (Bert); atommib@research.telcordia.com >>> Subject: Re: [Entmib] entity mib support for tcif >>> >>> On Sat, 6 Sep 2003, David T. Perkins wrote: >>> > I believe that adding a CLEI code (common langauge equipment >>> > identifier code) is completely redundant with the object >>> > entPhysicalVendorType and should not be added. >>> > A CLEI code is a globally unique value that is purchased >>> > from Telcordia. It costs approximately $100 to get the >>> > document from Telcordia that defines CLEI codes, and >>> > it costs per assigned code. >>> > >>> > If a vendor wants to use CLEI codes, it is a simple matter >>> > to construct the OID value for entPhysicalVendorType from >>> > any CLEI code. >>> > >>> > The only proposal that I would support is to define a standard >>> > OID prefix, and encoding of the suffix of the OID. >>> > >>> > For example, assume and OID value is assigned with descriptor >>> > "entPhysicalVendorTypeCLIE", and the encoding is a sub-identifer >>> > of the decimal value of per character in the CLIE code. >>> >>> I think this is a VERY GOOD idea. >>> >>> In previous off-line discussions entPhysicalModelName was suggested >>> as one place where a CLEI code might live. While there is nothing >>> wrong with putting a CLEI code there (especially if it's on a bar >>> code on the label), there would be no guarantee that any particular >>> manufacturer did this, nor is there a sure-fire way for a management >>> application to tell if what's there is actually a CLEI code, if it >>> happens to be 10 octets long. But entPhysicalVendorType contains an >>> OID, which is self-describing. Very elegant. >>> >>> I wish there were as neat a solution for entPhysicalMfgDate :-( >>> >>> Mike >>> >>Regards, >>/david t. perkins > > >At 10:44 AM 9/5/2003 -0700, C. M. Heard wrote: >>>>>> On Fri, 5 Sep 2003, Juergen Schoenwaelder wrote: >JS> On Thu, Sep 04, 2003 at 07:29:23PM -0400, Kaj Tesink wrote: >JS> >JS> > new objects: >JS> > >JS> > entPhysicalCLIECode OBJECT-TYPE >This should say entPhysicalCLEICode >yup, sorry about the typo > >JS> > SYNTAX SnmpAdminString (SIZE (0..10)) >JS> > MAX-ACCESS read-write >JS> > STATUS current >JS> > DESCRIPTION >JS> > "The CLIE Code for the physical entity. If a CLIE Code >JS> > is unknown or non-existent, the entPhysicalCLIECode will >JS> > be set to a zero-length string instead." >JS> > ::= { entPhysicalEntry xx } >JS> > REFERENCE "TCIF-02-004, Guideline for data elements >JS> > included in the Management Information Base, >JS> > Telecommunications Industry Forum (TCIF), 09/11/2002. >JS> > ANSI T1.213-2001, Coded identification of equipment entities >JS> > of the North American telecommunications system for >JS> > information exchange, ANSI. >JS> > ANSI T1.213a-2001, Supplement to T1.213-2001, >JS> > Coded identification of equipment entities of the North >JS> > American telecommunications system for information exchange, >JS> > to correct the representation of the Basic Code in >JS> > Figure B.1, ANSI." >JS> >JS> Can someone translate that into something I can understand? >JS> >JS> Explaining entPhysicalCLIECode with "The CLIE Code for the physical >JS> entity." is not really helpful for those poor souls who have no clue >JS> what a CLIE code is (and the reference does not look like it is easy >JS> to find the answer somewhere on the web). > >Would it help to modify the definition like so: > >entPhysicalCLEICode OBJECT-TYPE >SYNTAX SnmpAdminString (SIZE (0..10)) >MAX-ACCESS read-write >STATUS current >DESCRIPTION >"The CLEI (Common Language Equipment Identifier) >Code for the physical entity. If the CLEI Code >is unknown, or if no CLEI code exists, then this >object will contain a zero-length string." >REFERENCE >[ ... as above ... ] >::= { entPhysicalEntry xx } >yup > >and perhaps to have something in the narrative section of the >defining document (whatever it turns out to be) that more completely >defines the nature and usage of a CLEI code? >>>>>> On Thu, 4 Sep 2003, Margaret Wasserman wrote: >MW> I am trying to understand your request... >I think I can answer some of these questions. Kaj, please step in >and correct me if I get anything wrong. >MW> Why has the TCIF defined objects that must occur in a MIB, >MW> without a defining a MIB that includes them? >The TCIF documents are requirements documents: they mandate what >information must be present but don't mandate a specific method for >getting it there. If the information isn't provided by a standard >MIB module then a proprietary MIB module can be used to satisfy the >requirement. This is a common approach in the telecom industry. >right on > >MW> Why do you think that it would make sense to add these objects >MW> to the Entity MIB? Are you expecting each sub-component in a >MW> system to have separate CLIE codes and manufacturing information? >MW> Or would there be one set for the entire box? >There is a separate CLEI code and manufacturing date for each Field >Replaceble Unit or FRU. A line card ("circuit pack" in >telecom-speak) would be an example of an FRU. > > >right. CLEIs are not necessarily box-related. >this is one reason why the entity mib seems a reasonable >place to put this info. > >MW> Why do you think that it would be better to include these >MW> objects in the Entity MIB than it would be to publish a >MW> separate MIB module that includes these objects? >I think there is some distaste for artifically fragmenting MIB >modules into "base" and "supplemental" parts just to get around the >problem that the presence of new objects inhibits advancement on the >standards track. This is especially the case when there would be >only a small number of object (two, in this case) in the >supplemental MIB module. A supplemental MIB module seems like >overkill in that case. > >yup, that was the logic > >That said, it is certainly feasible to define a supplemental MIB >module with one conceptual table whose row object AUGMENTS >entPhysicalEntry and contains just the two objects >entPhysicalCLEICode and entPhysicalMfgDate. It's even possible to >do this in a proprietary MIB module or in a MIB module sponsored by >a telecom industry consortium, although I think that there would >probably be greater regard for a MIB module that is on the IETF >standards track. > >we looked at these alternatives; esp. the CLEI is widely used >now, so enterprise-specific approaches are not the preferred path forward. >as mike points out above, the tcif is not into mib specifications; they look >at organizations like the ietf as the most appropriate place for that. >kaj > > >Hope that helps, >Mike > > > > > >============================================================= > >========================================================= >entity mib wg, >attached is a discussion on accommodating >some TCIF information elements in an appropriate >MIB module. >the entity mib would be a good candidate, but >we understand that the timing may be problematic >since it's going to draft right now. >we're talking about 6 data elements (see >TCIF-02-004, 09/11/2002). most can probably be mapped to existing >objects, but not all. >so it appears that we have several options: >a) extend the entity mib with the 'missing' objects (see attached strawman) >b) write a 'supplemental' mib module for the 'missing' objects >c) find another suitable mib module >while a) seems most desirable the current state of the entity mib may make >it problematic(?). (b) seems somewhat overkill. >(c) seems suboptimal. >the new objects would only be required for systems that support management >access to this information. >any comments? particulars attached, >pl copy Cc list above, >kaj, tony, >============================================================ > >TCIF Required MIB objects: >- CLEI Code >Suggested to use: new object >Reference: TCIF-02-004, 09/11/2002 >Reference: ANSI T1.213-2001 and T1.213a-2001, T1M1.3 >- Unique Serial Identification (USI) >Suggested to use: entPhysicalSerialNum >- Software Version >Suggested to use: entPhysicalSoftwareRev >- Manufacture Date >Suggested to use: new object >TCIF Optional MIB objects: >- Manufacturer Identification >Suggested to use: entPhysicalMfgName >- Manufacturer Product Identification >Suggested to use: entPhysicalModelName >============================================================= >new objects: >entPhysicalCLIECode OBJECT-TYPE >SYNTAX SnmpAdminString (SIZE (0..10)) >MAX-ACCESS read-write >STATUS current >DESCRIPTION >"The CLIE Code for the physical entity. If a CLIE Code >is unknown or non-existent, the entPhysicalCLIECode will >be set to a zero-length string instead." >::= { entPhysicalEntry xx } >REFERENCE "TCIF-02-004, Guideline for data elements >included in the Management Information Base, >Telecommunications Industry Forum (TCIF), 09/11/2002. >ANSI T1.213-2001, Coded identification of equipment entities >of the North American telecommunications system for >information exchange, ANSI. >ANSI T1.213a-2001, Supplement to T1.213-2001, >Coded identification of equipment entities of the North >American telecommunications system for information exchange, >to correct the representation of the Basic Code in >Figure B.1, ANSI." >entPhysicalMfgDate OBJECT-TYPE >SYNTAX DateAndTime >MAX-ACCESS read-only >STATUS current >DESCRIPTION >"The manufacturing date for the physical entity." >::= { entPhysicalEntry xx } > > > > > > > > >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > >Kaj Tesink >Telcordia Technologies. Inc. >331 Newman Springs Road >Red Bank, NJ 07701 >Email: kaj@research.telcordia.com >Tel: (732) 758-5254 >Fax: (732) 758-4177 > >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib
- [Entmib] entity mib support for tcif Kaj Tesink
- [Entmib] Re: entity mib support for tcif Kaj Tesink
- Re: [Entmib] entity mib support for tcif C. M. Heard
- [Entmib] entity mib support for tcif Kaj Tesink
- Re: [Entmib] entity mib support for tcif Margaret Wasserman
- Re: [Entmib] entity mib support for tcif Juergen Schoenwaelder
- Re: [Entmib] entity mib support for tcif Kaj Tesink
- Re: [Entmib] entity mib support for tcif Subrahmanya Hegde
- Re: [Entmib] entity mib support for tcif Margaret Wasserman
- RE: [Entmib] entity mib support for tcif Wijnen, Bert (Bert)
- RE: [Entmib] entity mib support for tcif C. M. Heard
- RE: [Entmib] entity mib support for tcif Andy Bierman
- RE: [Entmib] entity mib support for tcif Romascanu, Dan (Dan)
- Re: [Entmib] entity mib support for tcif David T. Perkins
- RE: [Entmib] entity mib support for tcif Romascanu, Dan (Dan)
- RE: [Entmib] entity mib support for tcif C. M. Heard
- Re: [Entmib] entity mib support for tcif C. M. Heard
- RE: [Entmib] entity mib support for tcif Faye Ly
- Re: [Entmib] entity mib support for tcif C. M. Heard
- RE: [Entmib] entity mib support for tcif Kaj Tesink
- RE: [Entmib] entity mib support for tcif David T. Perkins
- Re: [Entmib] entity mib support for tcif Juergen Schoenwaelder
- RE: [Entmib] entity mib support for tcif Romascanu, Dan (Dan)
- RE: [Entmib] entity mib support for tcif C. M. Heard
- RE: [Entmib] entity mib support for tcif Kaj Tesink
- RE: [Entmib] entity mib support for tcif David T. Perkins
- RE: [Entmib] entity mib support for tcif Kaj Tesink
- RE: [Entmib] entity mib support for tcif David T. Perkins
- RE: [Entmib] entity mib support for tcif Kaj Tesink
- RE: [Entmib] entity mib support for tcif Kaj Tesink
- Re: [Entmib] entity mib support for tcif Juergen Schoenwaelder
- RE: [Entmib] entity mib support for tcif Wijnen, Bert (Bert)
- RE: [Entmib] entity mib support for tcif Kaj Tesink
- Re: [Entmib] entity mib support for tcif Juergen Schoenwaelder
- Re: [Entmib] entity mib support for tcif David T. Perkins
- RE: [Entmib] entity mib support for tcif Andy Bierman
- Re: [Entmib] entity mib support for tcif Juergen Schoenwaelder