Re: entity mib support for tcif

On Sat, 6 Sep 2003, Margaret Wasserman wrote:
> At 10:44 AM 9/5/2003 -0700, C. M. Heard wrote:
> >Would it help to modify the definition like so:
> >
[ ... snipped ... ]
> >
> >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?
> 
> I think that the narrative text is key.  The term "CLEI code" sounds
> vaguely familiar, but I still don't know what one looks like.  What
> is a CLEI code used for?  Does it identify the manufacturer, the
> version of the unit, the purpose of the unit,...?
> 
> BTW, is a CLEI code really an un-formatted 10 character string?

No, it does have some internal structure;  there is a brief
explanation of the purpose of these codes and an illustrative
example here:

http://www.telcordia.com/products_services/oss/neps/nepsnews/common.html

A FAQ can be found here:

http://www.telcordia.com/resources/commonlang/productshowroom/showroom/equip_id/carriers/faq.html

or here:

http://www.commonlanguage.com/resources/commonlang/productshowroom/showroom/equip_id/carriers/faq.html

To quote a couple of Q/A pairs from the FAQ:

   Q:  What is a CLEI code and how is it used?
   A:   A CLEI code is an intelligent, 10-character code that can
   identify telecommunications equipment with great precision.  CLEI
   codes are accepted by telecommunications providers as a de facto
   industry standard. T heir primary uses include inventory
   management and provisioning.

   Q:  Do CLEI codes conform to ANSI standards?
   A:  Yes, CLEI codes conform to ANSI standard T1.213, "Coded
   Identification of Equipment Entities of the North American
   Telecommunications System for Information Exchange."  The CLEI
   code set has also been recognized by the TCIF Bar Code and
   Standard Code Committee as one of two accepted ways to identify
   communications equipment.

> Any thoughts on how influential the TCIF is and/or how widely their
> requirements will be adhered to?  This is the first I've heard of
> them -- which doesn't mean anything one way or the other, except
> that I'm not sure how seriously we should take their requirements.

I am not all that familiar with the TCIF itself, but my
understanding is that most of the major telecom carriers in North
America do require CLEI codes for the equipment that they purchase.

> >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.
> 
> I share this distaste, but I also understand that desire to advance
> things on the standards track...  For something like the Entity
> MIB, there will probably always be "just one more" piece of
> information that some group wants to associate with physical or
> logical entities and/or "just one more" type of physical entity
> that folks are including in their boxes...  Where should we draw
> the line?

All good points.

> >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.
> 
> Well, let's see what other folks on the Entity MIB mailing list
> think...  I'd also be interested any thoughts that you or [Kaj]
> (or others) have about how prolific CLEI codes are likely to be.

Indeed, it would be good for the WG members to weigh in on
whether entPhysicalCLEICode and entPhysicalMfgDate should be
added to the ENTITY-MIB.

Regarding how prolific CLEI codes are likely to be:  it is my
understanding that they are practically universal for products that
are deployed by telecom providers, at least in North America.  I
don't think that they are widely used in other industry segments,
however.  So the proposed entPhysicalCLEICode is somewhat
industry-specific.  The entPhysicalMfgDate is probably more somewhat
more generic, in that it is useful even in environments that don't
require or use CLEI codes.

Mike