[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed IETF Working Group: sming
Bert,
Thanks for the clarification. I think that all the procedure discussion
actually helped, because it clarified a few things:
* How non-BOFed new Working Groups are being created and discussed.
This looks like not being very well understood - the proof being that it
took about three days for you - our respected ADs - to figure out and
explain to the constituency how it works.
* There IS a list to discuss SMIng. (why was it not mentioned from the
beginning?)
* new-work list is for liaison purposes.
I am still not 100% happy with the lack of a standard place to discuss BOFs.
This would be useful IMO - especially because the ADs seem to have large
powers in deciding what to approve and what to send to the basket. However,
I prefer now to close the thread - at least from my point of view - and use
the bandwidth for the technical issues.
Regards,
Dan
> -----Original Message-----
> From: Wijnen, Bert (Bert) [SMTP:bwijnen@lucent.com]
> Sent: Thu October 26 2000 10:53
> To: Cucchiara, Joan; Dan Romascanu; Jon Saperia
> Cc: mibs@ops.ietf.org; rap@ops.ietf.org; nim@ops.ietf.org; Steve Coya;
> Randy Bush
> Subject: RE: Proposed IETF Working Group: sming
>
> All,
>
> Sorry for the cross-posting. PLEASE do ONLY reply to the REPLY-TO
> mailing list and not to the mibs, rap or nim lists.
>
> We have a mailing list for the sming discussion: sming@ops.ietf.org
> To subscribe, send email to majordomo@psg.com
> and in the body: subscribe sming
>
> When I started to initially respond to the email on this topic, I was
> mistaken
> and mentioned new-work as a mailing list where this could be discussed.
> The new-work however is a read-only list for communication between
> (among others) ietf, itu, w3c, etc. The idea is that these organisations
> also inform each other of new work that is being planned, so that we
> can try to avoid duplication. When I started to see comments, I mistakenly
> thought that people were reacting to new-work posting, but it turns out
> they were reacting to the posting at IETF-Announce. Normally people
> can then send comments to iesg and/or responsible ADs (and that is
> true in this case also).
>
> W.r.t to some of the issues that were brought up, here are my answers.
>
> Q1. Why do we not hold a BOF first.
> A1. An AD can always initiate new work without having a BOF.
> In this particular case, we have had many requests in the past that
> SMI needed more work. For example, we have approved RFC2856
> as a short term tactical solution under the condition that long term
> solution would be worked on. We also have seen strong support for
> this type of work in various SNMP WG meetings when new work
> was discussed. At the NIM BOF at the last IETF, it was clear that
> many people where sceptical about complete new Network
> Information Model work, and that it needed much better definition
> on what exactly we want/need to do. However, at that same BOF,
> many people expressed that it would make sense to work on
> SMI (SMIng work from NMRG, SPPI, SMIv2 were all mentioned
> as input and concerns in this area). So that is why we are
> initiating/proposing this new work (without having a BOF first).
>
> Q2. Can we change the WG name, because it looks too familiar to SMICng
> A2. In principle, yes we can change the name. I am not so sure it really
> is an issue... but we're open to suggestions. The one suggestion
> we've
> seen sofar is SMIv3.
>
> Q3. when the charter says 'The objective is to replace both the SMIv2 and
> the SPPI with a single merged language for defining information for
> the
> monitoring, configuration, and provisioning of network devices' what
> does
> replace mean? Is the intended work targeting the standards track,
> and SPPI and SMIv2 will one day become historical?
> (I actually do not know what is the resolution about the status of
> SPPI )
> A3. One of the concerns I have as AD (and I guess many more people) is
> that I do not like the idea of having too many languages to do more
> or
> less the same thing. So "merging SMI and SPPI" seems a good thing.
> SPPI is currently in WG Last Call in RAP WG, and I expect it on my
> desk for consideration as PS soon.
> Potentially, at some point in the future, we may decide to make
> SMIv2 and SPPI historical in favor of this new work. Such a decision
> will be taken via the normal IETF process (i.e. WG deliberations
> and/or IETF Last Call). We currently have SMIv1 and SMIv2 at
> (full) Internet Standard. SMIv1 cannot be used for stds track MIBs
> any more, so at some point, I guess we want to make it historic.
>
> Q4 The third paragraph talks about a 'transport independent information
> model'. How does this relate to NIM? NIM started to discuss about
> such
> a
> model, and seems to have got stuck in a dispute about the language.
> It
> looks
> like smicng has taken a shortcut and decided that it has the answer
> to
> the
> nim dilemma and found the appropriate language that nim could not
> agree
> upon.
> A4. Yep, the better wording is "language" or "data model" I think. So
> we'll
> change
> the wording a bit. And you are right, I think I came away from the
> NIM
> BOF
> that people do support the idea to work on the language. See also my
> comments above.
>
> Q5. These questions are intended to clarify the relationship between the
> different pieces of work in the area. I think such a work is really
> needed -
> do we have the will and bandwidth to execute it?
> A5. I hope the above clarifies.
> I think I have heard enough supporting statements that I trust we
> can do the work and succeed. Besides, the SNMPv3 WG will
> need to focus on just "advancing SNMPv3 to full std" and no longer
> talk about all sorts of new work. If more work is needed (like this
> proposed WG), then we need to find other places to do such new
> SNMP related work.
>
> Q6. Should the SMIng work from NMRG be the starting point?
> Is the C-like language something we want/need?
> A6. I have followed that work very closely. It is not only theoretical
> work,
> but it has also been implemented. Then, at the last NMRG meeting,
> I saw good stuff, also with good input/contributions from SPPI
> authors.
> So... I think it makes a lot of sense to take that at least as a
> starting
> point for the discussions in the WG.
> Of course the WG can discuss the merits of this as normal. But for
> now, I think we should not just throw away the NMRG work and
> try to understand why they made the choices that are on the table.
>
> It is also my understanding from the last NMRG meeting, that we should
> expect revisions of the SMIng documents rsn. So let's see what we
> find in there. Those should be used as the basis.
>
> Hope this helps,
> Bert
>
> > ----------
> > From: Dan Romascanu[SMTP:dromasca@avaya.com]
> > Sent: Tuesday, October 24, 2000 6:15 PM
> > To: 'Steve Coya'; Cucchiara, Joan
> > Cc: 'Jon Saperia'; 'Wijnen, Bert (Bert)'; mibs@ops.ietf.org
> > Subject: RE: Proposed IETF Working Group: sming
> >
> > Steve,
> >
> > You seem to be saying that new-work is a list primarily set for
> > informational purposes. Jon, Joan, and myself are asking where a
> PROPOSED
> > WG, that did not hold a BOF of itself, and did not establish an e-mail
> > list,
> > should be announced to and discussed by the IETF community. Bert seems
> to
> > think that 'new-work' might be the place, while your take seems to be
> > slightly different.
> >
> > Regards,
> >
> > Dan
> >
> > > -----Original Message-----
> > > From: Steve Coya [SMTP:scoya@ietf.org]
> > > Sent: Tue October 24 2000 18:02
> > > To: Cucchiara, Joan
> > > Cc: 'Jon Saperia'; Dan Romascanu; 'Wijnen, Bert (Bert)';
> > > mibs@ops.ietf.org
> > > Subject: RE: Proposed IETF Working Group: sming
> > >
> > >
> > > Folks,
> > >
> > > For quite some time (since January 1998 if not before), the IESG has
> > > posted WG Review messages to the IETF-Announcement list and to the
> > > new-work list. This is done with a single message (i.e new-work does
> NOT
> > > get advance notice).
> > >
> > > The new-work list contains addresses for leaders of other standards
> > > organizations. This is one of the mechanisms used by the IESG to
> insure
> > > that we are not about to embark upon a work effort already being done
> > > elsewherwe.
> > >
> > > Note that these are PROPOSED WG actions, and that the IESG has NOT
> made
> > > any decision on them.
> > >
> >