RE: entity mib support for tcif

folks, i consulted with some interested parties directly.
my impression is that we could do the following:

1) to support the Manufacture Date we'll need a new object
    entPhysicalMfgDate that augments the entPhysicalTable

2) a) to support the CLEI we have the option of using
    entPhysicalVendorType with the elegant method pointed out by Dave;
    the only drawback is that this use theoretically may clash with
    other uses people may have had in mind.

    b) alternatively, we can define a new entPhysicalVendorType2
    and still apply Dvae's method.

3) from a documentation perspective we have the following options:
    a) fold into the existing document; this may jeopardize the entmib
        going to Draft
    b) create a supplemental entmib
    c) create a supplemental entmib that will be folded into the
       main document once the specs reach the same standainzation status

all options work for me although on reflection
i have a slight pref for 2a) over 2b) based on distaste of object 
proliferation.

any preferences out there?


kaj




At 03:29 PM 9/7/2003 -0700, David T. Perkins wrote:
[snip]



>And responding to Faye's question....
>If a well know prefix is used, this does not create any additional
>work for vendors. That is, they already have to "create an OID registry"
>to support object entPhysicalVendorType. And for management platforms
>that want to use CLEI codes, a standard prefix (and encoding rules)
>allows them to "extract" a CLEI code from the value of
>entPhysicalVendorType, and all other management platforms to be
>blissfully unaware of CLEI codes.
>
>On Sun, 7 Sep 2003, Faye Ly wrote:
> > 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 protected]]
> > Sent: Sunday, September 07, 2003 12:59 AM
> > To: [email protected]; Kaj Tesink; Giamboi, Anthony; Lam, Hing-Kam (Kam);
> > Faye Ly; Juergen Schoenwaelder; Margaret Wasserman; David T. Perkins;
> > Wijnen, Bert (Bert); [email protected]
> > 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
> >
>Regards,
>/david t. perkins


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





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

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








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

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

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