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: [email protected]
Tel: (732) 758-5254
Fax: (732) 758-4177

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