Re: Questions re current sonetng, atm1ng and atm2TC drafts

[Gary Hanson <[e-mail]>]

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

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.

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