Re: a proposal

[Andy Bierman <abierman@cisco.com>]

Hi Jeff,

All I can tell from this draft is that you think SMIv3
should be the same as SMIv2, except with Integer64 
and Unsigned64 data types added.  That's fine, I guess.

I think the WG is past the point of selecting potential features,
and ready to see specific ideas for solutions. I agree that some
of the objectives can be debated without proposals (like multiple
naming schemes vs 1 naming scheme) but most features like
structures, unions, tuples, etc. would benefit from solution proposals.

thanks,
Andy




>SMI-NG Working Group (and internet-drafts publisher):
>
>I would like this draft to be considered by the SMIng WG and discussed
>at the next IETF meeting.
>
>This document describes SMIng extensions to the SMI, based on changes and
>enhancements to SMIv2.  It is creatively called "SMIng based on SMIv2."
>
>In the interest of being clear, I want to say up-front that I do not believe
>this proposed document incorporates all of the desirable changes as we move
>from SMIv2 to SMIng.
>
>I have not yet incorporated several desirable changes because we all have our
>favorites.  Mine happen to include things like aggregate objects, tuples,
>tables with multiple INDEX clauses, and unions.  Your list may be (and
>probably is) different.  In any case, there is not (yet) consensus about
>which requirements have favorable cost-benefit ratios.
>
>I elected to not include my favorites yet and have them co-mingled with and
>thereby clouding the basic proposal that we proceed by modifying the existing
>SMI rather than starting over again from scratch.
>
>I realize that the resulting document is a near-copy of SMIv2, but this is
>not a gimmick.
>
>The reason why I submitted the entire document for republication as
>an Internet Draft is that I wanted to be squeaky clean with respect to
>the process requirements of the Working Group as stated by our Working
>Group Chair, Dave Durham, in his note of October 9, 2001.  The document
>is long, but will be familiar to the members of the Working Group because
>the changes incorporated to date are minor.  The process calls for a
>complete proposal, i.e., a complete document, and the only way to achieve
>that is to submit this lengthy near-copy of our existing SMIv2.  I apologize
>in advance for the seemingly brute-force approach.
>
>Four principles drove the preparation of this document:
>
>    1.  The grammar definition and resulting syntax of MIB documents is 
>        in the same style of the existing successful grammar and syntax,
>        thereby remaining familiar to many producers and consumers of MIB
>        documents
>
>    2.  The document incorporates mandatory maintenance, e.g., new data
>        types for signed and unsigned integers.
>
>    3.  While other features will certainly be added in the future, it's not
>        clear today which ones will achieve consensus.  Therefore, the document
>        outlines the basic approach while addressing those requirements that
>        appear to have overwhelming consensus, e.g., independence from ASN.1
>        specifications.
>
>    4.  The document provides a base for additional enhancements should
>        there be a consensus that we should build on the existing
>        SMI.
>
>It is my hope that with this basic approach, we can talk about which of the
>requirements should make the cut with regard to cost/benefit and be added
>to SMIv2.  
>
>best regards,
>jdc
>----