Re: SMIng consensus issues restated, call for consensus ends Septembe r 18, 2002

[Frank Strauss <strauss@ibr.cs.tu-bs.de>]

Hi!

Andy> I don't know why we have to keep going over this point.
Andy> With SMIv3, it will be possible to create data definitions
Andy> which are 100% equivalent to the existing SMIv2 definitions.
Andy> There will be no on-the-wire changes at all for these conversions.

If 100% compatibilty with SMIv2 would be the goal, then it would be
best to stick with SMIv2. In other words: We have goals that bring
benefits. And the benefits of a new naming would break compatibility.

>> I agree that more complex data structures to express data models would
>> be a win. However, I prefer to see that they are doable before making
>> them a requirement. Anyway, in general I agree to issue #1.

Andy> I think the SMI-DS document has already shown that an N-level
Andy> data definition can be constructed. It has also shown that
Andy> when N=2, the same instance naming as SMIv2 is used.

See above. I believe, sticking with N<2 is not your goal. 
Please correct me, if I'm wrong.

Andy> The WG has repeatedly agreed to change the naming scheme, if N > 2.
Andy> SMIv2 only allows for N < 2, and the naming scheme does not change
Andy> at all if N < 2.  Old MIBs can be represented in SMIv3, and they
Andy> can be updated in SMIv3, without changing the code design for
Andy> implementations of those MIBs. 

Yes, and I would like to have the possiblity to simplify the code
design for implementations for those many MIBs when they are revised
over time.

Andy> The WG also decided that old MIBs should not be updated in a way
Andy> that would change the nest level.

I agree that the nest level in naming of old MIBs should not
change. In fact it MUST not change.

Andy> I think the WG has worked hard to come up with a design that allows
Andy> SMIv2-style code to continue, but also allows for the introduction
Andy> of new MIBs that take advantage of new features, like nested arrays.

I would prefer a slightly different goal: Making new features like
nested containment available not only to new MIBs but also to
revisions of existing MIBs.

 -frank