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