RE: entity mib support for tcif

HI,

In addition to the redundancy of objects, I have big issue
with including in a standards track MIB module, support for
a proprietary network management platform, and one where
there is significant costs for device vendors.

Here is a FAQ on CLEIs from telcordia:
http://www.telcordia.com/resources/commonlang/productshowroom/showroom/equip_id/carriers/faq.html

I could not find the costs for each assignment of a CLEI, and
it appears from the Telcordia WEB site that the cost is variable -
that is you need to "talk with a friendly sales representative".

Before we take any further steps on this, I believe that an
official representative from Telcordia needs to provide full
disclosure of the the costs of using CLEI codes. And the openness
and accessibility of the CLEI assignments.

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