Re: entity mib support for tcif

Another thing which may be of interest is : Top Level Assembly 
Number(Known as TAN)
for the products.
We have TAN Number and TAN Revision which might need to go into ENTITY 
MIB as well


Thanks
Subra


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