RE: [Entmib] Re: Entity mib support for tcif

["David T. Perkins" <[e-mail]>]

HI,

Here is what I would do....
* I would just add the objects to the existing entity physical table,
    that is table entPhysicalTable. If this is not acceptable, then I
    would reluctantly create a table that augmented the entity
    physical table (not create a sparse augments).
* Here is the augmented table definition (which I would rather not
    have to create)

entPhysicalSupplTable OBJECT-TYPE
    SYNTAX  SEQUENCE OF EntPhysicalSupplEntry
    MAX-ACCESS  not-accessible
    STATUS  current
    DESCRIPTION
      "The table for supplementary objects to table entPhysicalTable."
    ::= { entityPhysical 2 } -- note, this comes after entPhysicalTable

entPhysicalSupplEntry OBJECT-TYPE
    SYNTAX  EntPhysicalSupplEntry
    MAX-ACCESS  not-accessible
    STATUS  current
    DESCRIPTION
      "An entry in the entPhysicalSupplTable.  There is a one-to-one
      relationship with entries in table entPhysicalTable."
    AUGMENTS { entPhysicalEntry }
        ::= { entPhysicalSupplTable 1 }

EntPhysicalSupplEntry ::= SEQUENCE {
    entPhysicalSupplManfactDate DateAndTimeOrZero,
    entPhysicalSupplAltTypes Utf8String 
    }


entPhysicalSupplManfactDate  OBJECT-TYPE
    SYNTAX      DateAndTimeOrZero
    MAX-ACCESS  read-only  -- maybe this should be w/r like serial number
    STATUS      current
    DESCRIPTION
      "The manufacturing date for the physical entity, or 'zero'
      if the date is unknown or not appropriate."
    ::= { entSupplPhysicalEntry 1 }

entPhysicalSupplAltTypes OBJECT-TYPE
    SYNTAX      Utf8String
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
          "A zero length string if the value is unknown or not
          appropriate; or one, or more pairs of tag and value
          which provide alternative identification of the entity
          in addition to the value of object entPhysicalVendorType.
          This object was added so that one or more industry
          sectors could add sector specific identification codes.
          It is expected that typically, at most a single sector
          identification code will be present. However, managers
          must cope with a list of tag-value pairs.
          The format of the value (when not a zero length string) is:
            <pair>[;<pair>]...
          where the format of <pair> is
            <id>:<value>
          where the values for <id> are short strings managed by IANA,
          and <value> follows the rules for an <id> definition,
          and may include any character other than ';'. The first
          defined <id> is 'CLEI', and when so, the values for
          <value> are 1 to 10 characters long as defined by 
          TCIF-02-004, Guideline for data elements
          included in the Management Information Base,
          Telecommunications Industry Forum (TCIF), 09/11/2002.

          An example value is 'CLEI:ABCDEFGHIJ'"
    ::= { entSupplPhysicalEntry 2 }




At 07:01 PM 4/14/2004 -0400, Kaj Tesink wrote:
>At 03:34 PM 4/9/2004 -0700, Faye Ly wrote:
>>Hi,
>> 
>>Yes, we have a need for this MIB.  Any chance of getting this done?
>
>
>i think the following issues have been raised:
>1. document title is too vague
>2. opaque object is cumbersome to implement
>3. acceptance as work item
>
>
>1. document title is too vague:
>current proposed title is:
>Definitions of Supplemental Entity Managed Objects
>
>the current contents of the MIB module is only two objects
>- manufacturing date
>- additional info (an opaque object with one currently identified
>  application)
>
>i proposed this title to be
>a) in line with similar documentation techniques in the past
>b) to be compatible with possible extensions in the future
>
>given the two current objects, and that one of them is opaque,
>it is hard to be very specific. Dan suggested something like:
>'Entity MIB Extensions for manufacturing date and physical module identification'
>
>or perhaps:
>
>Extensions to entPhysicalTable of the Entity MIB
>(more precise but still not very illuminating)
>
>I suggest we go with Dan's proposal.
>
>
>2. opaque object is cumbersome to implement.
>the suggested construct was based on neat suggestions by Dave
>and was meant to accommodate several concerns and also
>allow flexibility. but several comments pointed out that
>this may be too cumbersome to implement. i attach the 
>original proposal which was an object dedicated to CLEI.
>note that my original question was posed in the context of
>extending the Entity MIB directly instead of creating a separate
>document. 
>any strong feelings against going back to the original? Dave?
>
>
>3. acceptance as work item
>since the original proposal i've seen several supporting comments 
>but i leave this to the WG chair and AD to gauge
>
>kaj
>
>
>
>
>
>---snip from initial posting-------------------------------------------------
>
>
>=============================================================
>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 }
>
>
>> 
>>-faye  
>>-----Original Message----- 
>>From: [e-mail] [mailto:[e-mail]] On Behalf Of Kaj Tesink 
>>Sent: Friday, April 02, 2004 8:38 AM 
>>To: Sharon Chisholm; [e-mail] 
>>Subject: [Entmib] Re: Entity mib support for tcif
>>
>>hi Sharon,
>>At 12:56 PM 4/1/2004 -0500, Sharon Chisholm wrote:
>>
>>>hi
>>>Where are we in this discussion? Have we decided whether the working group 
>>>wants to take this on?
>>
>>i think that question is still pending; 
>>we asked for input and expressions of interest well before the 
>>last ietf meeting but there has not been much traffic on this 
>>since that request. so let me repeat the request for input on this spec:
>>
>>http://www.ietf.org/internet-drafts/draft-tesink-entity-supplmib-00.txt
>>
>>
>>
>>
>>
>>>This is a requirement I've heard bounced around a few times so I think this 
>>>is worth trying to address, but like Dan I have a few concerns with some 
>>>aspects of the proposed solution. As he has mentioned, the title is not 
>>>sufficiently descriptive. In addition, I think the data types might be too 
>>>opaque to be useful. 
>>
>>as per my comments based on Dan's note, there were 
>>some good reasons for the high level title, but 
>>i'd be open to other suggestions.
>>as for the opaque object, the history is that 
>>the initial proposal based on an octet string 
>>syntax invoked a discussion about flexibility 
>>and some other aspects, and resulted in a proposal 
>>by Dave for the current opaque construct, although 
>>some other comments expressed reservations (i believe 
>>by Juergen and Dan). 
>>i'm willing to go with whatever the rough consensus 
>>dictates. 
>>kaj
>>
>>
>>
>>
>>
>>>Sharon 
>>>-----Original Message----- 
>>>From: Kaj Tesink [mailto:[e-mail]] 
>>>Sent: Wednesday, February 11, 2004 10:25 AM 
>>>To: [e-mail] 
>>>Subject: RE: [Entmib] Re: Entity mib support for tcif
>>>
>>>
>>>Hi Dan,
>>>At 10:03 PM 2/10/2004 +0200, Romascanu, Dan (Dan) wrote: 
>>>>Kaj, 
>>>> 
>>>>I was among the ones who supported doing this work. I did not change my 
>>>>mind. 
>>>> 
>>>>Two comments: 
>>>>1. I would like the title of the document to be more explicit about 
>>>>what 
>>>>is really provided by this MIB. 'Supplemental' is really too generic a 
>>>>title - what about something like 'Entity MIB Extensions for manufacturing 
>>>>and physical modules identification'?
>>>
>>>
>>>I see what you're trying to do. While this would more accurately reflect the 
>>>content, there is the issue of future compatibility. The problem with 
>>>adding 
>>>new objects to MIBs over time is that 
>>>a) either you add to the original spec; but this means there's a problem 
>>>    with advancing the spec over time 
>>>b) or you define supplemental specs; the problem here is that you dont want 
>>>    all sorts of miblets around; you want to minimize the number So, similar 
>>>as what we did for ATM, and attempted for DS1s, the tactic was to use this 
>>>generic title, so that additional functions could still be added for a 
>>>while. I agree its not perfect. I also thought that in previous 
>>>discussions 
>>>there were some thoughts about some additional functions(?).
>>>
>>>>2. Some of the concerns expressed in the meeting (not by me) were 
>>>>related 
>>>>to the availability and the proprietary nature of the CLEI codes. Can you 
>>>>comment on these? Are the documents mentioned in the REFERENCE clause of 
>>>>the cleiCode object freely available?
>>>You're right, some of that did come up before. 
>>>My understanding is the following: 
>>>- the references point to documents by different standards groups, 
>>>   and i think are available for a small fee at www.atis.org 
>>>- CLEI codes are defined in those standards; 
>>>   Telcordia is the registrar to obtain an actual code 
>>>In previous discussion it was pointed out that 
>>>while CLEIs are in wide use, there is no obligation to 
>>>use them; I've tried to reflect that in the draft 
>>>in two ways: (a) use an opaque object instead of a dedicated object as 
>>>proposed by Dave, and (b) language for the case that the whole thing (no 
>>>CLEI nor any other application of the object) is not supported.
>>>Kaj
>>>
>>>
>>>
>>>
>>>
>>>
>>>>Thanks and Regards, 
>>>> 
>>>>Dan 
>>>> 
>>>> 
>>>> 
>>>> > -----Original Message----- 
>>>> > From: [e-mail] [mailto:[e-mail]]On Behalf 
>>>> > Of Kaj Tesink 
>>>> > Sent: 10 February, 2004 6:48 PM 
>>>> > To: [e-mail] 
>>>> > Subject: Fwd: [Entmib] Re: Entity mib support for tcif 
>>>> > 
>>>> > 
>>>> > all, 
>>>> > 
>>>> > the draft i sent to the list last week is now available at 
>>>> > http://www.ietf.org/internet-drafts/draft-tesink-entity-supplm 
>>>> > ib-00.txt 
>>>> > 
>>>> > pl note that the file name was changed (my error). 
>>>> > in order to move this forward the WG would need 
>>>> > to accept this as a formal work item. 
>>>> > 
>>>> > so we'd appreciate comments on 
>>>> > a) whether there is support/objection to do this work 
>>>> > b) any technical comments 
>>>> > while the minneapolis meeting already indicated some tentative 
>>>> > support, restating this or any new/additional views would be helpful 
>>>> > 
>>>> > kaj 
>>>> > 
>>>> > 
>>>> > 
>>>> > 
>>>> > >X-Sender: kaj@128.96.81.11 
>>>> > >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 
>>>> > >Date: Thu, 05 Feb 2004 15:06:54 -0500 
>>>> > >To: [e-mail] 
>>>> > >From: Kaj Tesink <[e-mail]> 
>>>> > > 
>>>> > > 
>>>> > >all, 
>>>> > > 
>>>> > >attached is the supplemental entity miblet 
>>>> > >discussed a while ago, supporting 
>>>> > >- manufacturing date 
>>>> > >- additional entity info 
>>>> > >the latter uses the method proposed by dave 
>>>> > >to convey information such as CLEIs. 
>>>> > >i do recall that there were some different 
>>>> > >views on whether to use an opaque encoding 
>>>> > >method versus using a dedicated object, but 
>>>> > >please read it over and provide any comments. 
>>>> > > 
>>>> > >kaj 
>>>> >
>>>
>>>
>>>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>>>Kaj Tesink 
>>>Telcordia Technologies. Inc. 
>>>331 Newman Springs Road 
>>>Red Bank, NJ 07701 
>>>Email: [e-mail] 
>>>Tel: [phone] 
>>>Fax: [phone]
>>>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>>>
>>>
>>>_______________________________________________ 
>>>Entmib mailing list 
>>>[e-mail] 
>>>https://www1.ietf.org/mailman/listinfo/entmib
>>>_______________________________________________ 
>>>Entmib mailing list 
>>>[e-mail] 
>>>https://www1.ietf.org/mailman/listinfo/entmib
>>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>>Kaj Tesink 
>>Telcordia Technologies. Inc. 
>>331 Newman Springs Road 
>>Red Bank, NJ 07701 
>>Email: [e-mail] 
>>Tel: [phone] 
>>Fax: [phone]
>>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ 
>>_______________________________________________ Entmib mailing list [e-mail] https://www1.ietf.org/mailman/listinfo/entmib 
>
>
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>
>Kaj Tesink
>Telcordia Technologies. Inc.

Regards,
/david t. perkins