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

[Jeff Case <case@snmp.com>]

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