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

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

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.

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.

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.

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.


 -frank