entity mib support for tcif

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.

mail exploder test

[ bcc'd to list owner and wg chair ]

just checking ... some recent messages regarding "entity mib support
for tcif" that were sent to this list don't seem to have made it out
to the subscribers.  sorry for the clutter if this is a false alarm.

//cmh

Re: entity mib support for tcif

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

At 07:29 PM 9/4/2003 -0400, Kaj Tesink wrote:
>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
>
>
>=========================================================
>

Re: entity mib support for tcif

On Thu, Sep 04, 2003 at 07:29:23PM -0400, Kaj Tesink wrote:

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

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

Re: entity mib support for tcif

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

Re: entity mib support for tcif

entity mib support for tcif

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" <faye <at> pedestalnetworks.com>
 >To: "C. M. Heard" <heard <at> pobox.com>,
 >         "Giamboi, Anthony" <agiamboi <at> telcordia.com>
 >Cc: "Lam, Hing-Kam (Kam)" <hklam <at> lucent.com>,
 >         "Lee, Shyhyann" <sylee <at> telcordia.com>,
 >         "Fox, Robert H." <rfox <at> telcordia.com>,
 >         "Kaj Tesink" <kaj <at> research.telcordia.com>,
 >         "Wijnen, Bert (Bert)" <bwijnen <at> lucent.com>
 >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:heard <at> pobox.com]
 >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: kaj <at> research.telcordia.com
Tel: (732) 758-5254
Fax: (732) 758-4177

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

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

Kaj Tesink
Telcordia Technologies. Inc.
331 Newman Springs Road
Red Bank, NJ 07701
Email: kaj <at> research.telcordia.com
Tel: (732) 758-5254
Fax: (732) 758-4177

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

Re: entity mib support for tcif

Re: entity mib support for tcif

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

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

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

Kaj Tesink
Telcordia Technologies. Inc.
331 Newman Springs Road
Red Bank, NJ 07701
Email: kaj <at> research.telcordia.com
Tel: (732) 758-5254
Fax: (732) 758-4177

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

Re: entity mib support for tcif

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