Re: entity mib support for tcif

HI,

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.
 

On Sat, 6 Sep 2003, Margaret Wasserman wrote:
> Hi Mike,
> 
> At 10:44 AM 9/5/2003 -0700, C. M. Heard wrote:
> >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 }
> >
> >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?
> 
> >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.
> 
> Okay.
> 
> 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.
> 
> >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.
> 
> Okay, this makes sense.  If there are likely to be separate CLEI
> codes for separate FRUs, it would make sense to include this
> information in the Entity MIB.
> 
> >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?
> 
> >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 Kay
> (or others) have about how prolific CLEI codes are likely to be.
> 
> Thanks,
> Margaret
> 
Regards,
/david t. perkins