Subject: [Entmib] entity mib support for tcif

From: Kaj Tesink <[email-masked]>
Date: Thu, 04 Sep 2003 19:29:23 -0400

i was told that this request hadnt made it to the entire intended audience,
so here goes again. sorry for the duplicate for those who did receive
the first time.

kaj

=========================================================

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 }

========================================================================

 >Subject: RE: Object Identifiers for MIB information
 >Date: Wed, 6 Aug 2003 12:58:48 -0700
 >X-MS-Has-Attach:
 >X-MS-TNEF-Correlator:
 >Thread-Topic: Object Identifiers for MIB information
 >Thread-Index: AcNcQaap13s3mWdMQsuSf53LJiptygAEzb+Q
 >From: "Faye Ly" <[email-masked]>
 >To: "C. M. Heard" <[email-masked]>,
 >         "Giamboi, Anthony" <[email-masked]>
 >Cc: "Lam, Hing-Kam (Kam)" <[email-masked]>,
 >         "Lee, Shyhyann" <[email-masked]>,
 >         "Fox, Robert H." <[email-masked]>,
 >         "Kaj Tesink" <[email-masked]>,
 >         "Wijnen, Bert (Bert)" <[email-masked]>
 >X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper)
 >
 >It sounds like ENTITY-MIB is only missing the Manufacture date and
 >CLEI? Why don't we bring them up to the ENTITY-MIB WG?
 >
 >-faye
 >
 >-----Original Message-----
 >From: C. M. Heard [mailto:[email-masked]]
 >Sent: Wednesday, August 06, 2003 10:39 AM
 >To: Giamboi, Anthony
 >Cc: Faye Ly; 'Lam, Hing-Kam (Kam)'; Lee, Shyhyann; Fox, Robert H.; 'Kaj
 >Tesink'; 'Wijnen, Bert (Bert)'
 >Subject: RE: Object Identifiers for MIB information
 >
 >On Wed, 6 Aug 2003, Giamboi, Anthony wrote:
 > > I asked the initial question.
 > >
 > > The issue is:
 > >
 > > The Telecommunications Industry Forum (TCIF) has issued a document
 > > (TCIF.02.004 Guideline for Data Elements Included in the Management
 > > Information Base (MIB)). This document states that there are 4 data
 > > elements that must be included in a MIB and they are:
 > >
 > > CLEI code
 > > Unique Serial Number
 > > Software version that is running
 > > Date of Manufacture
 > >
 > > In order for a manufacturer to load this information in the MIB we
 > > wanted to know if there was a standard way to identify these data
 > > elements within the MIB. If there is, great, if there isn't, maybe
 > > there should be? We are looking for your guidance on this issue.
 >
 >As of today, a vendor can represent these items either by proprietary
 >MIB objects or by a combination of standard objects in the ENTITY-MIB
 >and some proprietary objects. The details will be vendor- and
 >equipment-specific.
 >
 >If the TCIF is happy with that -- i.e., if their requirement is just to
 >have the information represented in some way, not necessarily the same
 >way for each vendor/device -- then there is no need to worry about
 >standardizing another MIB module. If they want a vendor- and
 >device-independent way of getting this information, then more work is
 >needed.
 >
 >For what it's worth, here's the stuff that the ENTITY-MIB already has:
 >
 >entPhysicalHardwareRev
 >entPhysicalFirmwareRev
 >entPhysicalSoftwareRev
 >entPhysicalSerialNum
 >entPhysicalMfgName
 >entPhysicalModelName
 >
 >As noted previously, entPhysicalModelName could be used for CLEI code,
 >but other things could appear there.  As far as I know, there is no
 >object for Date of Manufacture, that would have to be in a proprietary
 >MIB extension.
 >
 >I hope this helps more than it confuses :-)
 >
 >Mike

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies. Inc.
331 Newman Springs Road
Red Bank, NJ 07701
Email: [email-masked]
Tel: (732) 758-5254
Fax: (732) 758-4177

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies. Inc.
331 Newman Springs Road
Red Bank, NJ 07701
Email: [email-masked]
Tel: (732) 758-5254
Fax: (732) 758-4177

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

_______________________________________________
Entmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/entmib

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 5 Sep 2003 10:44:30 -0700 (PDT)

>>>>> 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

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 }

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.

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.

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.

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.

Hope that helps,

Mike

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 04 Sep 2003 19:45:08 -0400

Hi Kaj,

I am trying to understand your request...

Why has the TCIF defined objects that must occur in a MIB,
without a defining a MIB that includes them?

Why do you think that it would make sense to add these objects
to the Entity MIB?  Are you expecting each sub-component in a
system to have separate CLIE codes and manufacturing information?
Or would there be one set for the entire box?

Why do you think that it would be better to include these
objects in the Entity MIB than it would be to publish a
separate MIB module that includes these objects?

Thanks,
Margaret

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Sep 2003 10:34:56 +0200

>              to correct the representation of the Basic Code in

Can someone translate that into something I can understand?

Explaining entPhysicalCLIECode with "The CLIE Code for the physical
entity." is not really helpful for those poor souls who have no clue
what a CLIE code is (and the reference does not look like it is easy
to find the answer somewhere on the web).

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Kaj Tesink <[email-masked]>
Date: Fri, 05 Sep 2003 18:06:56 -0400

>This should say entPhysicalCLEICode

yup, sorry about the typo

>          ::= { entPhysicalEntry xx }

yup

>requirement.  This is a common approach in the telecom industry.

right on

>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.

>supplemental MIB module.  A supplemental MIB module seems like

yup, that was the logic

>probably be greater regard for a MIB module that is on the IETF

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

Kaj Tesink

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Sep 2003 10:34:56 +0200

/js

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 5 Sep 2003 10:44:30 -0700 (PDT)

Hope that helps,

Mike

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 04 Sep 2003 19:45:08 -0400

Hi Kaj,

Thanks,
Margaret

---

From: Subrahmanya Hegde <[email-masked]>
Date: Fri, 05 Sep 2003 11:04:15 -0700

Another thing which may be of interest is : Top Level Assembly 
Number(Known as TAN)
for the products.
We have TAN Number and TAN Revision which might need to go into ENTITY 
MIB as well

Thanks
Subra

---

From: Subrahmanya Hegde <[email-masked]>
Date: Fri, 05 Sep 2003 11:04:15 -0700

Thanks
Subra

---

From: Kaj Tesink <[email-masked]>
Date: Fri, 05 Sep 2003 18:06:56 -0400

yup

right on

yup, that was the logic

kaj

Kaj Tesink

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 06 Sep 2003 11:39:00 -0400

Hi Mike,

>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?

>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.

>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.

>supplemental MIB module.  A supplemental MIB module seems like

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?

>probably be greater regard for a MIB module that is on the IETF

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

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 06 Sep 2003 11:39:00 -0400

Hi Mike,

Okay.

Thanks,
Margaret

---

From: "David T. Perkins" <[email-masked]>
Date: Sat, 6 Sep 2003 17:48:23 -0700 (PDT)

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.

> (or others) have about how prolific CLEI codes are likely to be.
Regards,
/david t. perkins

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 7 Sep 2003 00:59:25 -0700 (PDT)

> 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

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 7 Sep 2003 00:59:25 -0700 (PDT)

Mike

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 6 Sep 2003 12:37:32 -0700 (PDT)

> >Would it help to modify the definition like so:
[ ... snipped ... ]
> 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.

> 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.

> that folks are including in their boxes...  Where should we draw

All good points.

> think...  I'd also be interested any thoughts that you or [Kaj]

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

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 6 Sep 2003 12:37:32 -0700 (PDT)

[ ... snipped ... ]

A FAQ can be found here:

or here:

All good points.

Mike

---

From: "David T. Perkins" <[email-masked]>
Date: Sat, 6 Sep 2003 17:48:23 -0700 (PDT)

HI,

Regards,
/david t. perkins