RE: entity mib support for tcif

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:[email protected]] 
>>> Sent: Sunday, September 07, 2003 12:59 AM
>>> To: [email protected]; Kaj Tesink; Giamboi, Anthony; Lam, Hing-Kam (Kam);
>>> Faye Ly; Juergen Schoenwaelder; Margaret Wasserman; David T. Perkins;
>>> Wijnen, Bert (Bert); [email protected]
>>> 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: [email protected]
>Tel: (732) 758-5254
>Fax: (732) 758-4177
>
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/