[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: Conventions for representing inheritance in MIBs
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de]
> Sent: Friday, June 16, 2000 8:34 AM
>
> 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.
>
[Dave] So the next question is, should there be common conventions for
mapping inheritance into a MIB? (Andrew's point that there are multiple ways
is well noted)
> 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.
>
[Dave] This looks close. I'm not sure how you extend hierarchically beyond a
base table and a single level of children (dependent's). Ie. Can I have a
dependent on a dependent of the base table? BTW, I didn't notice any
explicit reference to Inheritance anywhere in the whitepaper,
multiple/single or otherwise, so I'm not sure a mapping would be obvious. It
also seems that the index size will grow linearly with each subsequent
dependent-on-dependent table that is added (simple index alignment that
Andrew mentioned would avoid this).
> 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.
>
[Dave] I agree that SMIv2 has insufficient mechanisms to make mapping
Inheritance a machine readable process. Do you think these new textual
conventions (or some variation thereof) are ready for general release into
the IETF? What would be the procedure for moving these ideas from the IRTF
to IETF? And there is still the matter of specifying exactly how Inheritance
specifically is mapped to these SMIng 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/>
>
>
>