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

["Durham, David" <david.durham@intel.com>]

> -----Original Message-----
> From: Wes Hardaker [mailto:wes@hardakers.net]
> Sent: Thursday, January 04, 2001 4:20 PM
>
> >>>>> On Thu, 04 Jan 2001 15:49:54 -0800, "David T. Perkins" 
> <dperkins@dsperkins.com> said:
> 
> >> 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?
> 
> David> On the above, I believe that you must be able to map back to a
> David> valid SMIv2 MIB module.
> 
> I don't mean that you can't do it at all.  I mean to ask is it a
> requirement that all *new* modules written in the new language be
> backwards-mappable.
> 
> EG, SMIv2 can be translated into SMIv1 minus counter64s.  Is a similar
> requirement presumed for SMIng?
> 
> There are two cases:
> 
> 1) Can you use the new language to write a specification that is
>    backwards compatible.
> 
> 2) Can the new language make use of features that will not be
>    backwards compatible when *new* definitions are being written.
> 
> I'm talking about case #2.  Case #1 is a necessity that I think we all
> agree upon.
> 
> [ rmon example deleted ]
> David> If you created SMIng modules with this approach then when you
> David> tried to reverse map them to SMIv2, you couldn't
> 
> You wouldn't do what I'm talking about for old mibs.  *Only* for new
> ones.  You would *force* column enumeration with the old ones to
> ensure backwards compatibility.  I think I'm getting repeatedly
> misunderstood about this point.
> 
[Dave] So, it sounds like in any case sming would still require the explicit
table mapping for backward compatibility reasons. 

I still have some questions regarding reversioning if the alternative
approach was used for new mibs however. What if one inserts a new class
between two others in the inheritance hierarchy? That is, what if ClassA <-
ClassC later becomes ClassA <- ClassB <- ClassC? Or what if someone inserts
new attributes in the middle of an existing class? How would such things
affect the mapping?

The idea of using the oids more intelligently, and mapping them closer to
the class structure sounds intriguing. Certainly it would simplify the
mapping process. Would you be willing to write up a formal proposal on how
the non-tabular approach would work so the WG can better assess the pros &
cons (and determine what changes would be required for implementations)?