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

[Jeff Case <case@snmp.com>]

>Hi!

hi frank ... thanks for your note

Jeff> 1.  there are too many requirements

frank>I think, this statement itself is way too general. Please look at each
frank>single requirement in Section 4.1 of the current I-D that you don't
frank>feel comfortable with and *argue* about why it should be moved to 4.2
frank>or 4.3.

1.  please note that the sheer quantity of requirements makes focus impossible

    this working group, like all ietf working groups, needs focus

    i would hope that this is a basic point on which we can agree

    i would further hope we can also agree that if someone were to say
    they "are focused on 45 things simultaneously" that it would sound
    silly on the face of it

    my point is exactly what i said:  there are too many requirements in
    the requirements document

    i believe it is in the best interest of the working group to winnow
    the list further before progressing to the next phase

    i am definitely not interested in attempting to *argue* (your term and
    emphasis) about any and expecially not all of them

    perhaps it would be more fruitful to see if we agree on the basics

    only then is it reasonable to attempt a rational discussion of one
    or more of the individual items

Jeff>     [...] revisit the basic premise:
Jeff>     that a totally new definition language is needed to align
Jeff>     the SPPI and PIBs with the SMI and MIBs ... the market for
Jeff>     SPPI and PIBs peaked in calendar year 2000 and is already on
Jeff>     the wane

Jeff>     XML is the new silver bullet hoping to replace SMI and MIBs
Jeff>     ... SPPI and PIBs have already joined the long list of
Jeff>     would-be replacements for SNMP that didn't make it in the
Jeff>     market ... example: how many products are under development
Jeff>     at a router vendor, say cisco, that implement COPS/PR &PIBs?
Jeff>     snmp and mibs? [...]

frank>So, are you talking about the requirements document or the SMING WG
frank>charter?

see draft-ietf-sming-reqs-03 including the abstract, 1.0 introduction,
2,. motivation, 3., background, and how it colors 4., requirements

similar text is found in the charter





Jeff>     too many requirements ... they need to be reduced, prioritized

frank>That has already been done.

the diet is not finished until all the pounds are off

if we try to address all 45 "requirements" then we do not have the
requisite focus ... you are in favor of focus, are you not?




Jeff> 2.  the document is out of sync with the real requirements of the market

Jeff>     the stated requirements are irrelevant to much of the real market
Jeff>     and they have tuned out this process in droves

frank>Again, be precise, please. Which stated requirements are you talking
frank>about?

your response trimmed out one of my for examples which was precise

are you questioning my point #2, the example i chose to illustrate
the point, both or something else?  do you agree that our work needs to
reflect the real requirements of the market?




Jeff>     i find parts of the nmrg work to be of high quality, however, i
Jeff>     find that many parts of the proposal to far from appropriate [...]

frank>So, are you talking about the requirements document or the currently
frank>proposed specs which are far from being complete?

this sentence says what i meant for it to say ... the nmrg work, or the
proposed specs as you call them

i think of the requirements document as being ietf work

i perceive them to be tightly linked to one another, developed to be
in harmony with one another, with the nmrg proposed specs evolving to
attempt to track the requirements document




Jeff>     we also need to coordinate the work in revising the smi with
Jeff>     the work to enhance the protocol, i.e., the EOS working
Jeff>     group

frank>I agree, that this should be taken more closely into account with the
frank>SNMP mapping specific requirements.

this is progress



Jeff> 3.  the document does not reflect some of the input provided to the
Jeff>     working group

Jeff>     for example, at multiple meetings of the working group, including
Jeff>     having made the investment to participate in the seattle interim
Jeff>     meeting, i strongly argued that the new sming grammar need to be
Jeff>     roughly, i.e., imperfectly, but pretty darn closely, translatable
Jeff>     to SMIv2 format, as opposed to mapped to the protocol as described
Jeff>     in 4.1.15, which i continue to strongly believe is wrong-headed

frank>I wonder why you recognized 4.1.15 but not 4.1.16: Translation to
frank>other data definition languages, e.g. SMIv2, *is* a requirement.

draft-ietf-sming-req-03 still states that the cannonic mapping is to the
protocol, not the SMIv2, correct?

frank>I disagree that translation to another data definition language is
frank>more important than mapping to the protocols. The reason is simple:
frank>Data definitions that can be translated but not used in a protocol are
frank>quite useless in contrast to those that can be used but not
frank>translated.

note that if you map to the data definition language which is already
compatible with the protocol, it is impossible to have a data definition
that can be translated but not used in a protocol ... your logic needs
to be revisited



Jeff> i would be happy to provide additional details with anyone
Jeff> interested in engaging in further civilized discussion of these
Jeff> points

frank>Of course, the working group is interested. If you want to know the
frank>name of a person who's interested, take mine for example. But please
frank>post your input to the mailing list, so that everyone is aware of the
frank>discussion, right in the sense of your own statement:

    Jeff> whether you agree or disagree, please do not remain a member of
    Jeff> the great silent majority -- we need you to re-engage with the
    Jeff> process

fair enough, i have done so


frank>In Summary:
frank>
frank>- Please differentiate to which document you refer, the WG charter,
frank>  the requirements document, or the current specification proposal.

done

frank>- Please come up with *precise* concerns (requirements in Section 4.1
frank>  that you don't like) and *argue* about them.  Statements like ``too
frank>  many requirements'' or ``i strongly disagree with the position taken
frank>  by the document'' don't help a lot.

no thank you ... see above ... i respectfully decline to "*argue*" with you

regards,
jdc