[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FW: Conventions for representing inheritance in MIBs
>>>>> Durham, David writes:
>> 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> [Dave] This looks close. I'm not sure how you extend
Dave> hierarchically beyond a base table and a single level of
Dave> children (dependent's). Ie. Can I have a dependent on a
Dave> dependent of the base table?
I have to think about it.
Dave> BTW, I didn't notice any explicit reference to Inheritance
Dave> anywhere in the whitepaper, multiple/single or otherwise, so I'm
Dave> not sure a mapping would be obvious. It also seems that the
Dave> index size will grow linearly with each subsequent
Dave> dependent-on-dependent table that is added (simple index
Dave> alignment that Andrew mentioned would avoid this).
The index does not get more complex in a sparse relationship. A sparse
is basically the same as an augments except that you have 1:0..1
relationship instead of a strict 1:1 relationship. The expand
relationship (1:0..n) adds to the index - but this is necessary to
unique identify instances. (But note that expands is not needed to
represent a specialization relationship.)
>> 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> [Dave] I agree that SMIv2 has insufficient mechanisms to make
Dave> mapping Inheritance a machine readable process. Do you think
Dave> these new textual conventions (or some variation thereof) are
Dave> ready for general release into the IETF?
SMIng is not a new textual convention. It is a proposal for a more
powerful SMI which is backwards compatible to SMIv2 and adds a few new
features to address well know short-comings of the SMIv2.
Dave> What would be the procedure for moving these ideas from the IRTF
Dave> to IETF?
Nothing special I think. Someone needs to establish a WG and things
will move from there.
Dave> And there is still the matter of specifying exactly how
Dave> Inheritance specifically is mapped to these SMIng mechanisms.
I think mappings like these do not belong into the SMIng language
definition. I think they belong into a separate document (probably
BCP) which for example documents algorithms to map some OO models into
a MIB.
BTW, we have also done some research recently to extract conceptual
models (UML diagrams) out of existing MIB definitions. The reverse
engineering algorithm we have developed uses quite a few heuristics to
do its job. So we learn about how to do mappings in the other
directions and SMIng would indeed help to reduce some of the
heuristics we currently need. A paper describing our reverse
engineering algorithm will be forthcoming. You can already get a
prototype implementation as part of the libsmi package (which outputs
the conceptual model in a format which is understood by the dia
editor.)
/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/>