RE: Conventions for representing inheritance in MIBs

[Andrew Smith <andrew@extremenetworks.com>]

Dave,

We faced this problem with the Diffserv MIB: the -03 version uses several
different mechanisms to tackle this:
1. define a child table that uses the same index variables as the parent;
this may or may not have entries that are creatable/deletable independent of
the parent.
2. define a child that is pointed to by a RowPointer in the parent (or
vice-versa) but with independent index variables.

I don't believe there is a single mechanism that can meet the differing
needs for inheritance: the generic/flexible mechanism of (2) above is too
inefficient to use in general and a closer coupling between parent and child
has better properties w.r.t. searching and creating. AUGMENTs is more
limiting I think - there the child and parent entries are very tightly
coupled (I think the rules are that neither can exist without the other).

My 2c.

Andrew

> -----Original Message-----
> From:	Durham, David [SMTP:david.durham@intel.com]
> Sent:	Wednesday, June 14, 2000 6:35 PM
> To:	'mibs@ops.ietf.org'
> Cc:	'Wijnen, Bert (Bert)'
> Subject:	Conventions for representing inheritance in MIBs
> 
> Hello,
> 
> I'm sure this question has been asked before, but I am curious if anyone
> has
> thought about how Inheritance can be consistently represented in MIBs and
> if
> there are conventions for representing inheritance within the SMI. By
> inheritance I mean a hierarchical specialization of a common parent
> similar
> to the existing functionality provided by AUGMENTS (extending one
> object-type sequence with another). Only AUGMENTS appears to be too
> limited
> to describe the full semantics needed by inheritance.
> 
> Inheritance example:
> 
>                      Base
>                        ^
>                        |
>                    ____|____
>                    |       |
>                    |       |
>                Child1     Child2
>                   ^
>                   |
>               ____|____
>               |       |
>               |       |
>            Child3   Child4
> 
> So, when instantiating Child3, I also want to instantiate its parent,
> Child1, and their common Base, but none of the others. Similarly, when
> instantiating Child1, I should get it and the Base, but nothing else.
> Possibly all related instances should be indexed accordingly or otherwise
> associated.
> 
> The advantage of inheritance is that it provides a mechanism for
> independent
> specializations. Thus, common attributes can be defined in a base object
> with well understood semantics, which can then be extended in a variety of
> ways (via new object-types).
> 
> I realize that the concept can certainly be mapped into a MIB, but are
> there
> any common conventions for doing so? Perhaps textual conventions that
> could
> be defined so that compilers would automatically know the necessary
> semantics?
> 
> Thanks for any input,
> -Dave
> 
> 
>