Re: comments on draft-ietf-sming-reqs-03.txt

["Joel M. Halpern" <joel@longsys.com>]

Jeff, I think that there is a more basic question that underlies the 
issues, include your strong request for better SMIv2 compatibility.
To whit:
    what are we trying to accomplish?
Sometimes we say ~bring smi and sppi together.~
Sometimes we say ~bring forward the state of the art in nm protocol 
engineering.~
and sometimes we just say ~make things better in a not too disruptive fashion.~

While these goals are related, they are different.  For example, if you 
focus on the first goal, then a consequence is that you want to make it as 
simple and clean a mapping to smi and sppi as possible.  If you focus on 
the second goal, then you want to focus on what makes the resulting whole 
work better, and minor changes that would be painful by themselvesw are 
acceptable because the make the whole thing hang together.

I believe that this inconsistency is why we simultaneously have a very long 
list of requirements and a number of people who feel that the requirements 
miss the point one way or another.  I have not spoken up about specific 
requirements because I can not tell what goal is being sought and therefore 
which goals make sense.

Yours,
Joel M. Halpern

At 01:19 AM 8/3/01 -0400, Jeff Case wrote:


>i have 3 basic comments with respect to draft-ietf-sming-reqs-03.txt
>now in working group last call
>
>i preface them by saying that i appreciate the time and work of the
>coauthors in preparing the document ... i just do not fully appreciate
>the result and believe we can and must address the following:
>
>
>1.  there are too many requirements
>
>     the list of requirements needs to be shortened dramatically before
>     it is translated into working group work items
>
>     one way to shorten the list is to revisit the basic premise:  that
>     a totally new definition language is needed to align the SPPI and PIBs
>     with the SMI and MIBs ... the market for SPPI and PIBs peaked in calendar
>     year 2000 and is already on the wane
>
>     XML is the new silver bullet hoping to replace SMI and MIBs ... SPPI
>     and PIBs have already joined the long list of would-be replacements
>     for SNMP that didn't make it in the market ... example:  how many
>     products are under development at a router vendor, say cisco, that
>     implement COPS/PR &PIBs?  snmp and mibs?
>
>     it isn't clear what role XML will play, but the role of SPPI and PIBs
>     is clear:  minimal in the short term and none in the long term
>
>     we should avoid repeating history ... in 1988 we were told to put 
> together
>     a data definition language that would be protocol independent, i.e.,
>     one that would support both snmp and cmip, and as a result, the smi
>     and mib definitions of today evolved from that requirement
>
>     there is cruft in the smi today from that requirement that was put
>     in there for the protocol independence and compatibility with cmip
>         examples:  the dual definitions in tables of the FooEntry sequence
>                    the extra .1 in every tabular object's oid name
>
>     we need to be careful not to put in a bunch of new cruft in to the
>     sming in order to support compatibility with a technology that was
>     on the decline before the economy turned down and has died in its
>     infancy as a result of the tight economy
>
>     yes, the development of PIBs is flourishing in the IETF, but not in
>     the market ... let us be careful to not get too detatched from those
>     who pay the bills ... that happened with the party-based snmpv2 and
>     it wasn't pretty -- we should not do that again
>
>     too many requirements ... they need to be reduced, prioritized
>
>     to end this point on a positive comment:  i agree with the motivation
>     surrounding requirement 4.1.17 and it is worth addressing
>
>
>2.  the document is out of sync with the real requirements of the market
>
>     the market is not "ietf participants"
>
>     the stated requirements are irrelevant to much of the real market
>     and they have tuned out this process in droves
>
>     how many different individuals and companies contribued to this
>     process and what percentage of the users of SMIv2 does that represent?
>
>     the document references and uses the NMRG proposal as a baseline
>     to help understand the requirements
>
>     if we want the droves that have tuned out to tune back in, and we do
>     want them to tune back in, then we need to do work that they find
>     relevant ... which is true of more than one of the work efforts in
>     the O&M area where participation is so thin
>
>     i find parts of the nmrg work to be of high quality, however, i
>     find that many parts of the proposal to far from appropriate
>
>     for example, i feel strongly that changes such as
>         changing "DESCRIPTION" to "description"
>         changing NOTIFICATION to event
>         adding a semicolon at the end of every line
>         etc ad nauseum
>     will NOT provide any kind of advancement in the state-of-the-art
>
>     these sorts of changes are gratuitous and counter-productive
>
>     the portion of the marketplace with which i am intimately familiar
>     is not willing to make changes that are all buck and no bang
>
>     there are some good changes, but they are hidden behind a complete
>     change to the look and feel which obviate them
>
>     we also need to coordinate the work in revising the smi with the work
>     to enhance the protocol, i.e., the EOS working group
>
>     at present, these two work efforts are intentionally decoupled, to the
>     detriment of both -- they need to be coordinated, as work on the
>     smi and the protocol has always been coupled in the past
>
>
>3.  the document does not reflect some of the input provided to the
>     working group
>
>     when you read the above, you may have asked yourself, "why is he saying
>     this now, i.e., why did he wait until last call?"
>
>     well, this isn't the first time i have spoken on these topics
>
>     for example, at multiple meetings of the working group, including
>     having made the investment to participate in the seattle interim
>     meeting, i strongly argued that the new sming grammar need to be
>     roughly, i.e., imperfectly, but pretty darn closely, translatable
>     to SMIv2 format, as opposed to mapped to the protocol as described
>     in 4.1.15, which i continue to strongly believe is wrong-headed
>
>     [yes, i am aware of what it says elsewhere in general in 4.3.1 in
>     particular]
>
>     i strongly disagree with the position taken by the document, have said
>     so before, and will continue to say so until convinced otherwise
>
>     the current position on this point dooms the current work effort to
>     irrelevance in the marketplace and relegates it to a worthless
>     academic exercise that will be another embarassment to the ietf
>
>
>SUMMARY:
>
>the requirements document needs to
>         a) be put on a strict, serious, diet to reduce the number of
>                 requirements, and
>         b) to get back to basics and the realities of needs of the market
>
>i would be happy to provide additional details with anyone interested in
>engaging in further civilized discussion of these points
>
>whether you agree or disagree, please do not remain a member of the great
>silent majority -- we need you to re-engage with the process
>
>i hope to see and chat with many of you in london next week
>
>best regards,
>jdc