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

[Jon Saperia <saperia@jdscons.com>]

Jeff,

I shall be brief. I too have made comments at WG meetings and via email. This 
is largely a repeat of them. I also respect and appreciate the work already 
done but believe it is a much bigger hammer than needed :-)

    1. I agree with your points about learning from our past and keeping that 
in mind as we evolve the SMI. We are in danger of adding significant 
cruft/complexity to something that novice engineers already find more 
complicated than necessary. Novice engineers are the ones that most often do a 
lot of this work. I observe that much of this cruft and complexity existed 
prior to the desire to merge SMI and SPPI.

    2. One of the points that I made several times before the WG formed, and 
since at WG meetings is that some of the changes (you listed some) seem to 
offer little practical value and will be disruptive. If I thought that adding 
semicolons at the end of each line or changing the capitolization rules would 
advance the state of management, I would be be all for them. I just have not 
been convinced that they will.

I will not be in London.

/jon

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

Thanks,
/jon
--

Jon Saperia		     saperia@jdscons.com
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/