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

[Frank Strauss <strauss@ibr.cs.tu-bs.de>]

Hi!


Jeff> 1.  please note that the sheer quantity of requirements makes
Jeff>     focus impossible
Jeff>     this working group, like all ietf working groups, needs focus
Jeff>     i would hope that this is a basic point on which we can agree

Yes. -- The focus is defined in the WG charter.

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

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

I think, you mix up the focus with the list of requirements. In my
opinion, the purpose of a requirements document is to detail the
general goals to some degree. That's why I think there cannot be too
many requirements, as long as we don't lose the focus and don't miss
the important stuff. If there would be four important requirements,
it's still good to add 40 other less important but yet reasonable
ones. And it would be stupid to remove them, just in order to shorten
the list.

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

I'm sorry for my mistake to choose the wrong term, due to my native
tongue. See also my recent email on this list.


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?

Jeff> see draft-ietf-sming-reqs-03 including the abstract, 1.0 introduction,
Jeff> 2,. motivation, 3., background, and how it colors 4., requirements
Jeff> similar text is found in the charter

The requirements draft reflects the goals of the SMING WG
(charter). This is why I think, you should direct your input to the
SMING WG in general and to the IESG.


Jeff> the diet is not finished until all the pounds are off
Jeff> if we try to address all 45 "requirements" then we do not have the
Jeff> requisite focus ... you are in favor of focus, are you not?

Since we took the burden to work on the requirements document, I'm
in favor of being precise and not just more or less repeat the charter.


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

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

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

This is not true. You did not refer to any concrete requirement that
you would like to see removed or degraded to Section 4.2 or 4.3. Hence,
there is nothing to this regard, that I've trimmed out. I would still
appreciate concrete input.


Jeff> are you questioning my point #2, the example i chose to illustrate
Jeff> the point, both or something else?  

In your point #2, the only example you gave was related to the current
specification proposal, hence out of focus for the requirements
discussion. 

What I'm questioning is as simple as input like ``I think requirement
4.1.x should be moved to 4.3, because ...'' instead of ``There are too
many requirements'' or ``The stated requirements are irrelevant to
much of the real market''.


Jeff> do you agree that our work needs to reflect the real
Jeff> requirements of the market?

I would add other reasonable principles but I agree to this one.


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

Yes.

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

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

You are right as long as we assume that there is no evolution.
A simple example: When SMIv2 was developed the *primary* goal was to
make use of the enhancements and not to map it back to SMIv1 to make
most of the enhancements useless. However, it was a requirement to
make SMIv2 mappable to SMIv1 wherever possible. The same is true for
the SMING requirements.


 -frank