Re: Conventions for representing inheritance in MIBs

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Durham, David writes:

David> I'm sure this question has been asked before, but I am curious
David> if anyone has thought about how Inheritance can be consistently
David> represented in MIBs and if there are conventions for
David> representing inheritance within the SMI. By inheritance I mean
David> a hierarchical specialization of a common parent similar to the
David> existing functionality provided by AUGMENTS (extending one
David> object-type sequence with another). Only AUGMENTS appears to be
David> too limited to describe the full semantics needed by
David> inheritance.

[...]

David> I realize that the concept can certainly be mapped into a MIB,
David> but are there any common conventions for doing so? Perhaps
David> textual conventions that could be defined so that compilers
David> would automatically know the necessary semantics?

It is of course possible to map inheritance into a MIB. There are
however no common conventions for doing it - at least nothing I am
aware of.

The SMIng proposal adds additional keywords to represent existance
relationships between tables. For example, a "sparse" between Child1
and Base in your example defines that an entry in the Child1 table
needs to have a similar indexed entry in the Base table. The
difference to an auments existance relationship is that not every row
in the Base table must appear in the Child table. See Dave Perkins
white paper on existance relationsships for more details, available
from <URL:http://www.snmpinfo.com/>. A revised version is in the
appendix of his RMON book.

To continue the example: If you would attach a RowStatus in an SMIng
to Child1, it would automatically have the effect to also create an
entry in the Base table if you instantiate a row in the Child1 table.
In short: SMIng makes inheritance mappings easier and machine readable
so that you can build tools which do the right thing. In SMIv2, you
simply lack information about the types of relationships between
tables and it is hard to express them via well know TCs or other
mechanisms.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>