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

[Wes Hardaker <wes@hardakers.net>]

>>>>> 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.

-- 
"Ninjas aren't dangerous.  They're more afraid of you than you are of them."