Re: Questions re current sonetng, atm1ng and atm2TC drafts

[Kaj Tesink <[e-mail]>]

At 08:45 AM 3/25/98 -0800, Gary Hanson wrote:
>
>Kaj and Peter,
>
>It is not completely clear to me that it is a problem to have
>one MIB register objects at a level below that of objects
>registered in other MIBs.  For example, just because ATM-MIB
>registers { mib-2 37 }, it is not illegal for ATM-TC-MIB to
>register { mib-2 37 3 }, nor just because ATM-MIB registers
>{ mib-2 37 1 } is it illegal for ATM-TC-MIB to register
>{ mib-2 37 1 1 }.

thats what i thought; it shouldnt
>
>This type of registration of objects at points in the OID
>hierarchy space below that of objects registered by other
>MIBs is done all the time by the non-SMI-defining MIBs.
>
>This leads me to believe that the fault lies with the MIB
>compiler Peter is using.  It seems to me that there are only
>three reasonable options available to fix the problems that
>Peter is apparently experiencing with his MIB compiler.
>
>1.  Abandon the approach of creating an ATM-TC-MIB, and of
>    migrating the OBJECT-IDENTITY object registrations from
>    the ATM-MIB to the ATM-TC-MIB.
>
>2.  Register the atmTCMIB MODULE-IDENTITY as a different
>    value under mib-2 (as is done by the PerfHist-TC-MIB in
>    <draft-ietf-atommib-perfhistTC-01.txt), and deprecate
>    the existing objects under atmTrafficDescriptorTypes in
>    favor of new objects under atmObjectIdentifies.
>
>3.  Ask the vendor of Peter's MIB compiler to relax its
>    checking of object re-registrations, specifically so
>    that the registration of an object N levels deep does
>    not also imply the simultaneous registration of unnamed
>    objects at levels N-1 or higher.
>
>I don't like option 1, since I think it is a good step
>forward to migrate the common TEXTUAL-CONVENTIONs and
>OBJECT-IDENTITYs to a MIB dedicated to such definitions.
>
>I also don't like option 2, or more precisely the second
>part of option 2, since the atmTrafficDescriptorTypes are
>already commonly used, and are not deserving of deprecation
>merely because of our interest in moving them to a new home.
>
>That leaves me to think option 3 is technically the best
>option, even if it makes things temporarily more difficult
>for those of us who are presently dependent on MIB compilers
>with overly strict object registration checking.

i will check the drafts on their correctness 
but i think i agree with this too.

>
>Regards,
>Gary
>
>
>On Tue, 24 Mar 1998, Kaj Tesink wrote:
>
>> At 12:04 PM 3/23/98 +0800, Peter Jones wrote:
>> >Hi Kaj,
>> >
>> >Kaj Tesink wrote:
>> >> 
>> >> hi peter,
>> >> 
>> >> thanks for your mail; good points; i'll forward some of it to the quality review
>> >> process folks so that we can fix any problems.
>> >> 
>> >> [...]
>> >> 
>> >> - on your observation that the various atm mibs seem to IMPORT from
>> >>   each other: i thought that was fixed a long time ago. i know
>> >>   i made some changes because of that. well, obviously we need to check this
>> >>   and fix as result of the quality review process.
>> >> 
>> >
>> >Regarding the importing, atm2TC does not directly import from atm1ng, it
>> >cheats.
>> >
>> >For instance:
>> >1)	The MODULE-IDENTITY clause from atm2TC really is { atmMIB 3 } which
>> >	is in atm1ng. The specification using { mib-2 37 3 } ducks around 
>> >	the problem that the  mib-2 37 is defined in atm1ng. Our MIB 

>> >	compiler complains that atm1ng is redefining an OID already 
>> >	specified in atm2TC.
>> >               atmTCMIB MODULE-IDENTITY
>> >                    ::= { mib-2 37 3 } -- atmMIB 3
>> 
>> i'll look into it; i thought we got it fixed but will check
>> 
>> >
>> >2)	A similar problems exists for the traffic descriptor types, 
>> >	with the {atmMIBObjects 1} branch being moved from atm1ng 
>> >	to atm2TC. The same techniques is used to get around the 
>> >	issue, by specifying 
>> >	atmTrafficDescriptorTypes OBJECT IDENTIFIER ::= {mib-2 37 1 1}.
>> >	This causes us the same problem when compiling atm1ng where our
>> >	compiler says that atmMIBObjects (i.e. mib-2 37 1) has already 
>> >	been defined in atm2TC. 
>> 
>> hadnt seen this one before
>> 
>> >
>> >That's the essence of what I am complaining about. Hooking the OIDs
>> >defined
>> >in atm2TC onto the subtree defining in atm1ng is not good.
>> 
>> will check
> 

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/                                                                      _/
_/  Kaj Tesink                                                          _/
_/  Bellcore                                                            _/
_/  Business Internet Professional Services  vmail [phone]       _/
_/  331 Newman Springs Rd.                   email [e-mail]  _/
_/  Red Bank, NJ 07701                     faxmail [phone]       _/
_/                                                                      _/
_/  * NOTE AREA CODE CHANGE (908) --> (732) EFFECTIVE JUNE 1, 1997 *    _/
_/                                                                      _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/