Subject: [Entmib] entity mib support for tcif

From: Kaj Tesink <[email-masked]>
Date: Wed, 03 Sep 2003 14:09:03 -0400

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

---

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

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

Regards,

Dan

---

From: "Faye Ly" <[email-masked]>
Date: Sun, 7 Sep 2003 11:03:16 -0700

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-masked]] 
Sent: Sunday, September 07, 2003 12:59 AM
To: [email-masked]; Kaj Tesink; Giamboi, Anthony; Lam, Hing-Kam (Kam);
Faye Ly; Juergen Schoenwaelder; Margaret Wasserman; David T. Perkins;
Wijnen, Bert (Bert); [email-masked]
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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 8 Sep 2003 20:36:10 +0300

How would we deal with the compliance issues? I guess that this would mean having a compliance group that includes this object only - right? What about the case where there are several physical entities in the same enclosure, with some of them supporting this capability, other not? 

Thanks,

Dan

> From: Kaj Tesink [mailto:[email-masked]]
> Sent: 08 September, 2003 5:13 PM
> To: [email-masked]
> At 01:24 PM 9/7/2003 -0700, C. M. Heard wrote:
> > >>>>> On Sun, 7 Sep 2003, Romascanu, Dan (Dan) wrote:
> >Dan> If this proposal is adopted, it looks like we need a
> >Dan> DateAndTimeOrNul TC, for these systems that do not support
> >Dan> manufacture date for some reason.
> >Dan>
> >Dan> Dan
> >Dan>
> >Dan> >
> >Dan> > entPhysicalMfgDate   OBJECT-TYPE
> >Dan> >       SYNTAX      DateAndTime
> >Dan> >       MAX-ACCESS  read-only
> >Dan> >       STATUS      current
> >Dan> >       DESCRIPTION
> >Dan> >               "The manufacturing date for the 
> physical entity."
> >Dan> >       ::= { entPhysicalEntry xx }
> >
> >Using a special value (e.g., a zero-length OCTER STRING) to represent
> >"no date" is one way.  Another is just not to instantiate the object.
> >Since a manager would have to deal with that anyway (existing
> >implementations don't support this object), maybe that's the
> >simplest approach.
> 
> thats was my thinking too & the reason why i didnt write that
> case in the DESCRIPTION
> 
> kaj
> 
> 
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 8 Sep 2003 20:36:10 +0300

Thanks,

Dan