Re: Latest posted agenda for SMIng meeting at the 49th IETF...

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

At 03:03 PM 1/4/2001 -0800, Wes Hardaker wrote:
<stuff cut out>
>David> Some of the existing MIB tools are tightly dependent on a
>David> particular SNMP protocol stack, and obviously will not be able
>David> to generate/interpret hierarchical table definitions (unless,
>David> you add a row entry value for every contained class, forcing
>David> every contained class to look like a separate table oid-wise,
>David> but indexed the same).
>
>Right.  Do we require the new language to supply only minimal changes
>to a given current code base?  Or can we rethink not only how we
>represent data textually but binarily (I love making up words) as
>well?  Must the textual data *always* be mapped into the *exact same
>structures* that exist today?  Must SMIng -> SMIv2 mappings *always*
>be possible?

On the above, I believe that you must be able to map back to
a valid SMIv2 MIB module. Such a translation may have to be
done via hand or with help of additional information. Consider
the RMON MIB modules. Many tables in them follow the same design
pattern. It would be very desirable to define a base RMON
control class that would be subclassed for each specific
control table. If you created SMIng modules with this approach
then when you tried to reverse map them to SMIv2, you couldn't,
since original "descriptors" in the SMIv2 RMON module would be
lost. Also, there are many MIB modules where there is semantic
information in ASN.1 comments. This would end up in different
place (or be lost) if the SMIng module designer(s) were not very
careful.

(Backwards (and forwards) compatibility are key factors in
making forward progress. This is a paradox - but is so true.)

Regards,
/david t. perkins