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

[Andy Bierman <abierman@cisco.com>]

At 10:21 PM 9/17/2002 +0200, Frank Strauss wrote:
>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.

That's not what the meeting minutes or my email says.  This particular
goal is for SMIv2 objects converted to SMIv3, there is no change in
semantics, no wire-encoding changes, and no instance naming changes.

There is a separate goal to add new capabilities to the SMI.


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

For existing MIBs and any new MIBs that wish to keep N < 2,
that can be done with SMIv3. For MIB designers that wish to
use new capabilities, such as N > 2, that can also be done.


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

You can choose to revise MIBs in the same manner as before
(note this is a design choice made by MIB writers, not a
choice forced by the SMI).


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

This is not worthwhile if it means that all MIBs are harder to write
because of it.  The notion of unfolding all nested layers into 2 layers
with manual mapping definitions is not a workable solution.  It doesn't
even work for many constructs, such as an ARRAY in an ARRAY.


> -frank 

Andy