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

[Andy Bierman <abierman@cisco.com>]

At 04:23 PM 9/17/2002 +0200, Frank Strauss wrote:
>Hi!
>
>Durham, David writes:
>
>DD> I have prepared this message to the mailing list to initiate a
>DD> last call on the wg consensus for items raised during the IETF and
>DD> interim meetings. This last call is also for the edification of
>DD> those on the list who have not read/commented on the meeting
>DD> minutes.
>
>DD> There are several items that achieved clear consensus in the wg
>DD> meetings.  This mail is to confirm that the mailing list is not of
>DD> a different opinion.
>
>I did not attend the recent WG meetings. However, I expressed my doubts
>several times to the WG chair, to Andy and others. I definetely don't want
>to stop the WG from making progress, but however, I'd like to express
>my reservations again, since I did not yet receive any feedback on them...
>
>Let me first express my general vision and expectations on the SMING
>WG which are derived from the WG charter, from discussions with WG
>members and from my personal thinking...
>
>Currently,
> we have 100+ Standard MIBs (which was a lot of hard work).
> we have many MIB agent implementations (which was a lot of hard work). 
> we have many MIB manager implementations (which was a lot of hard work).
>
>What's the goal of SMING? - Sure, we want to come up a with a new
>language that makes it
> easier to express the model behind a device or service, so that it's
> easier to generate better code skeletons for new agent development, and
> easier to generate better code stubs for new manager development.
>
>Up to this point, I think we agree.
>
>Now, what I think the SMING should try to achieve is a future
>situation that allows us to use not only totally new SMING MIBs to
>develop new (parts of) agents and managers, but also to use updated
>and annotated MIBs of those 100+ Standard MIBs (which will remain the
>most important ones for many years) to easier develop new agents
>talking to all (old and new) existing managers, easier develop new
>managers talking to all (old and new) existing agents.
>
>I believe that this kind of a compatible transition is a very important
>goal.  And it requires to stick with what I called `semantics of what
>is transported on the wire' in recent messages.

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


>Based on this thinking my opinions on the consensus issues posted by
>David D. are as follows...
>
>DD> 1. That the sming supports N-levels of nesting. This includes the
>DD> nesting of complex data structures, unions, and multidimensional
>DD> constructs such as arrays. [See the 53rd IETF SMIng meeting
>DD> minutes for more details]
>
>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.

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


>DD> 2. That the sming take advantage of the hierarchical oid namespace
>DD> to achieve consensus item number 1. That is, the naming scheme
>DD> should map directly to the n-levels of nesting as is in Andy
>DD> Bierman's smi-ds proposal.  [See the 53rd IETF SMIng meeting
>DD> minutes for more details]
>
>Due to my above reasonings I disagree that the naming scheme should
>be changed. BTW, I did not see a proof that this is necessary, although
>I agree that it looks more intuitive to reflect the structure in the
>naming. However, the consequences of such a change would cause too severe
>incompatibilities.

The WG has repeatedly agreed to change the naming scheme, if N > 2.
SMIv2 only allows for N < 2, and the naming scheme does not change
at all if N < 2.  Old MIBs can be represented in SMIv3, and they
can be updated in SMIv3, without changing the code design for
implementations of those MIBs. The WG also decided that old MIBs
should not be updated in a way that would change the nest level.


>DD> 3. The smiv2 definitions be convertible to sming (meaning that
>DD> sming is backwards compatible with smiv2). It is not a requirement
>DD> that new sming definitions map back to the smiv2. [See the June
>DD> 2002 SMIng Interim meeting minutes for more details]
>
>I agree.
>
>DD> 4. The existing smi look-and-feel will be preserved where
>DD> possible. There are exceptions for new constructs in the sming
>DD> language. Also, where the existing smi syntax is broken it should
>DD> be fixed. [See the 53rd IETF SMIng meeting minutes and June
>DD> Interim meeting minutes for more details]
>
>Although I would prefer to kick this crappy, ASN.1-based,
>exception-overloaded thing overboard and end up with a clean language
>design to ease readability, understandability, and implementability, I
>understand that many people would like to stick with the SMIv2 look
>and feel.
>
>DD> 5. Backward compatibility of the new sming with the SPPI is not a
>DD> requirement. [See the 54th IETF SMIng meeting minutes for more
>DD> details]
>
>I agree. However, I still suggest to reflect this in the charter so
>that everybody is aware of this significant change in the WG's goals.
>
>
>I also agree (or don't care) on issue #6, that the resulting language
>might be called SMIv3.
>
>
>DD> Note that the last call period for these items ends in two weeks,
>DD> on September 18th.
>
>Though in still time, I'm sorry for this late input. 
>
>Please note, that I understand that like with almost any IETF work,
>this WG's further directions are based on rough consensus; and rough
>consensus does not necessarily mean full consensus. However, I did not
>want to remain silent about my reserverations and I thank Bert for
>encouraging me to restate them.

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



> -frank

Andy