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

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

---

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

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

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,

Kaj Tesink

---

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

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

> 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

---

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

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 7 Sep 2003 12:05:36 +0300

If this proposal is adopted, it looks like we need a DateAndTimeOrNul TC, for these systems that do not support manufacture date for some reason. 

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 7 Sep 2003 12:10:36 +0300

FWIW - I have encountered the requirement to support CLEI codes. They seem to be quite wide spread in assets management applications in the Telecom market. My opinion is that the best place for these would be in a separate MIB module, with one conceptual table whose row object AUGMENTS entPhysicalEntry.

Regards,

Dan

> think...  I'd also be interested any thoughts that you or Kay
> Thanks,
> Margaret
> _______________________________________________
> Entmib mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/entmib
>

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 7 Sep 2003 20:25:37 +0200

Or..., the DESCRIPTION clause could say that all zeroes for
the DateAndTime would mean 
"manufacture date unknown or nor supported"

Just thinking aloud here.

By the way, I believe that most of us are on entmib or atommib 
lists, so I have trimmed all the people names (except whom I responded to).
I have bcc:-ed you all this time, so you can spoeak up if my
assumtion is incorrect.

But even 2 mailing lists... can we move this to one list for now?

Thanks,
Bert 

> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: zondag 7 september 2003 11:06
> To: Kaj Tesink; [email-masked]
> Cc: C. M. Heard; Giamboi, Anthony; Lam, Hing-Kam (Kam); Wijnen, Bert
> (Bert); [email-masked]; Faye Ly
> Subject: RE: [Entmib] entity mib support for tcif
> 
> 
> 
> If this proposal is adopted, it looks like we need a 
> DateAndTimeOrNul TC, for these systems that do not support 
> manufacture date for some reason. 
> 
> Dan
> 
> >