Keith,
Since I started participating in O&M, I have repeatedly heard two distinct themes. One theme is build on what you have. The other is build something new that can replace what you have. With regard to SMIng, I have certainly heard strong opinions on this same theme. I don't profess to have a strong opinion as to which I would personally choose. I am personally more interested in the results. However, it is difficult to get results when these themes repeatedly collide.
Closing the process in an open standards body does not solve anything. I have concluded that the approach you aspouse fairs no better than the approach I am suggesting when there are strong opinions on both sides. Inviting alternative proposals or additions/changes to the main proposal is a healthy way of determining the strength of convictions.
Your main concern with respect to the NIM BOF was that when the effort is too broad, the work is unachievable. This was the reason why I specifically suggested that the charter should bound the scope to address specific needs, but allow for alternative proposals that meet those needs as well.
The fundamental question is: What is the approach the polarizes the various opinions the least? Note that every message on a theme like this one has a tendency to polarize further.
regards,
-Walter
> -----Original Message-----
> From: Keith McCloghrie [mailto:kzm@cisco.com]
> Sent: Friday, October 27, 2000 3:47 PM
> To: wweiss@ellacoya.com
> Cc: bwijnen@lucent.com; sming@ops.ietf.org
> Subject: Re: [nmrg] RE: Proposed IETF Working Group: sming
>
>
> Walter,
>
> Soliciting a set of proposals to try to solve all the problems that
> can be identified was the approach that was advocated at the NIM BOF.
> The response at the BOF was much scepticism, and comments that the
> scope of such an effort was much too broad to have a realistic chance
> of success, i.e., while I think there was a consensus on a
> desire to do
> something, there was no consensus to adopt the proposed approach. In
> contrast, several people spoke at the BOF in favour of pursuing the
> SMIng work and starting a WG to to standardize it (and I don't recall
> anyone speaking against). Indeed, the work and implementation done in
> the IRTF shows that the proposed charter is achievable, in contrast to
> the scepticism on the NIM approach.
>
> WGs in the IETF have a much higher success rate when they start from
> an existing solution and "tweak" it, as compared to having to choose
> between several competing proposals put forward by
> (competing) proponents.
> In fact, it is very hard to get consensus for a choice between several
> proposals. What normally happens is that after spending a year having
> each side claiming the benefits of their different approaches, the WG
> reaches an impasse, and either the effort comes to an end or multiple
> WGs get created, one for each different proposal. The IMPP WG in the
> Apps Area is just the latest example of this.
>
> Regarding your suggestion of determining requirements, I do think that
> listing a set of desirable features would be a good stepping stone for
> the WG in determining what "tweaks" to SMIng should be considered.
>
> Keith.
>
> > Bert,
> >
> > > -----Original Message-----
> > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> > > Sent: Friday, October 27, 2000 9:46 AM
> > > To: 'sming@ops.ietf.org'
> > > Cc: Dan Romascanu
> > > Subject: RE: [nmrg] RE: Proposed IETF Working Group: sming
> > >
> > >
> > > Here, inline are my responses/comments
> > >
> > > > ----------
> > > > From: Dan Romascanu[SMTP:dromasca@avaya.com]
> > > > Sent: Friday, October 27, 2000 1:04 PM
> > > > To: 'sming@ops.ietf.org'; Dave Sidor
> > > > Cc: David Perkins; Andrea Westerinen; mibs; nim
> > > > Subject: RE: [nmrg] RE: Proposed IETF Working
> Group: sming
> > > >
> > > >
> > > > Bert,
> > > >
> > > > I think that Dave Sidor's message is a good example about
> > > some of the not
> > > > so
> > > > clear issues concerning this new work proposal. Note
> that I am now
> > > > addressing the content, and not the procedure issues.
> > > >
> > > Yes, I got that. And I am trying to get a clear statement
> > > that the IESG can
> > > make.
> > > As you can see, we are all (including, or may be
> > > specifically, ADs) learning
> > > as
> > > we go.
> > >
> > > > 1. You are mentioning that the proposal intents to 'move
> > > SMI forward to
> > > > address some of the issues that have been raised in the
> last so many
> > > > years'.
> > > > In this case the first step should be to specify which
> > > problems we propose
> > > > to solve. Maybe the first item in the deliverables list
> should be
> > > > 'Requirements for SMIv3 document'.
> > > That sounds plausible, but we do know quite a few reqmnts already.
> > > For sure, I want to get SMI and SPPI back on the same track.
> > > Now.. I would assume that the first WG meeting, or this
> mailing list
> > > right now, allows for discussing this topic. Maybe
> someone can already
> > > prepare an I-D to try and list the most important ones.
> > >
> > You seem to be advocating an evaluation of the NMRG output based on
> > undocumented opinions of the problem set we are facing. By
> ignoring the
> > potential set of problems, it is easy to argue for a
> specific solution and
> > to avoid comparing this proposal with alternatives, because
> the criteria for
> > a comparison are undefined.
> >
> > > > 2. The text of the proposal still seems to indicate that it
> > > takes upon
> > > > itself to provide an answer to the problem of the
> common information
> > > > model.
> > > > Dave Sidor read it this way, so did I. I happen to be
> > > convinced that such
> > > > a
> > > > model is needed, and deserves a separate framework, and
> > > SMIv3 is not the
> > > > answer.
> > > I did get this from your message. I think I tried to
> answer that in my
> > > clarifications.
> > > And when we do approve the WG, then I will certainly try to
> > > get the wording
> > > improved/fixed. Specific text that you think would make
> it clearer can
> > > always
> > > be suggested on this list or directly to me.
> > >
> > > > 3. I understand so well that we focus on SNMP and COPS, but
> > > it is too
> > > > early
> > > > for having decided about the solution. I think that I agree
> > > with your
> > > > assessment in a previous mail, that the floor should be
> > > open for different
> > > > proposals. This would include the good work done in the
> > > ITRF, but should
> > > > not
> > > > exclude other proposal that may come from different
> > > sources. The future
> > > > Charter should have clear text about this.
> > > >
> > > The IETF process is open, and at any point people can raise
> > > any issues or
> > > concerns they have. And when we start this work, I can also
> > > see that we
> > > spend
> > > some face to face time to discuss other possible solutions.
> > > We can also have
> > > some email discussions on this. But for now... I do want to
> > > strongly suggest
> > > that we first take a serious look at the IRTF docs that I
> > > hope will show up
> > > rsn.
> > > And the charter tries to convey that "strong suggestion". If
> > > the WG decides
> > > later on that the "strong suggestion" should be ignored, then
> > > of course the
> > > WG chairs and ADs will evaluate the issues raised to see
> if we need to
> > > reconsider.
> >
> > Given my comments above, I would suggest that it is
> reasonable to use the
> > NMRG specs as input for developing requirements. However to
> suggest that the
> > NMRG specs is the outcome slams the door pretty hard on potential
> > alternatives.
>
>