RE: Reforming the BOF Process (was Declining the ifare bof for Chicago)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



See in-line.

Dan


 
 

> -----Original Message-----
> From: John C Klensin [mailto:john-ietf@xxxxxxx] 
> Sent: Sunday, June 17, 2007 9:13 PM
> To: Bernard Aboba; ietf@xxxxxxxx
> Subject: Re: Reforming the BOF Process (was Declining the 
> ifare bof for Chicago)
> 
> 
> 
> --On Tuesday, 12 June, 2007 09:52 -0700 Bernard Aboba 
> <bernard_aboba@xxxxxxxxxxx> wrote:
> 
> >...
> > For example, by restricting the function of an initial BOF to  a 
> >determination of interest and a decision to form/not form a  study 
> >group,  the opportunities for unfairness and bias can be  reduced.  
> >Once the study group had produced a charter and  
> documentation of the 
> >formation criteria, the review of these  documents could 
> proceed with 
> >more information than is  typically available as the result of a 
> >(potentially delayed)  2nd BOF. Also, the review could 
> utilize existing 
> >procedures  for ensuring transparency and accountability, such as an 
> >open  review process and documentation of DISCUSS comments.
> 
> Bernard,
> 
> Some specific observations on shifting more toward an IEEE model...
> 
> (1) Unless things have changed since I was last paying 
> careful attention, the process you describe is used to adding 
> a new project to an existing technical committee.  The 
> process for creating a new technical committee is somewhat 
> more elaborate.
> The IETF has no layer between the steering group (IESG, TSC 
> (?)) and the WGs who actually do the technical work.  We also 
> usually try to charter WGs on a short-term, project basis 
> rather than assigning new projects to existing WGs.  Because 
> of those differences, we need to be careful about analogies 
> unless we are willing to rethink process models in much more 
> fundamental ways than tweaking the BOF process.

Actually I believe that the IEEE have study groups both at the level of
technical committees (Working Groups) which end if successful with new
projects within existing Working Groups as well as at the level of the
whole IEEE which may end with new Working Groups being formed. Now a
IEEE Working Group vary very much in size and scope, but there are a few
like IEEE 802.1 (bridging, security QoS) and IEEE 802.11 (wireless LAN)
which are comparable in size, scope and number of projects with an IETF
area rather than with an IETF WG. 

> 
> (2) I don't have statistics, but my impression is that most 
> technical standards work in the IEEE these days (not just in 
> 802, but more broadly) starts with a proposal to standardize a
> specific industry technology.   Those proposals are debated and
> refined, but the assumption is that little fundamental 
> engineering or design work is done in the standardization 
> process. 

This also differs from case to case. In some IEEE projects work may
start with a given technology on the table, in some other there may be
more than one, or just an idea or several ideas about how to solve the
problem, and much debate happens until an initial proposal is baselined.
I do not believe that overall the distribution of cases is significantly
different to what happens in the IETF. 
 

> We behave as if the IETF is still doing engineering 
> design work.  Maybe it is time to drop that as an inefficient 
> and ineffective fantasy, but, again, considering that 
> involves much broader issues than reforming the BOF process.
> 
> (3) Many of us are concerned about the length of time it 
> takes to move a well-thought-out idea that has significant 
> support forward from initial proposal to a functioning 
> standards development effort.  Perhaps we should be 
> concentrating as much on that question as on the one of how 
> we cut bad, or inadequately supported, ideas off as cleanly 
> as possible.

I believe that the lack of some agreed criteria of approval for new work
is a problem. Maybe this is what you mean by 'how we cut bad'. 

> Adding a study group creation process and a study group 
> process to the existing opportunities for delay would not 
> contribute to speeding things up.  Indeed, it would do much 
> the contrary.
> 
> (4) I, and others, have said this before, but my belief is 
> that the single most effective change that could be made to 
> the BOF process would be for the IESG to stop taking its 
> ability to project the future so seriously.  As you and 
> others have commented, the track record on that isn't good 
> anyway.  Suppose, instead, we were to permit WGs to be set up 
> on a provisional basis, with intense review after some 
> reasonable period of time and cancellation if they were not 
> performing adequately and producing results the community 
> seemed to care about.  This would combine some of the 
> advantages of IEEE-like study groups with a streamlined 
> process that focused on the one true measure of whether a WG 
> could produce useful work: starting it up and seeing if it 
> produced useful work.  

What would be the differences between 'study groups' and 'WGs set up on
provisional basis'? 

> 
> Since decisions as to whether to charter a WG are somewhat 
> subjective and the IESG has broad discretion, this is a 
> change the IESG could institute --experimentally or 
> permanently-- on its own initiative without our spending 
> energy on changing the
> processes.   Its success would, however, depend on a change of
> attitude in the community: today, so much effort goes into 
> the charter process because it has become almost impossible, 
> in practice, to kill off a non-performing WG or to put a tight
> leach on one that is wandering in the weeds.   ADs who try to do
> so do not win popularity contests, to put it mildly.   If the
> IESG saw clear and broad community support for chartering WGs 
> that were questionable but plausible and then tuning charters 
> or killing non-performing WGs if things didn't work out as 
> originally conceived, I believe we could get a great deal of 
> the nonsense, arbitrariness, and delays out of the early 
> parts of the process.  
> 
> But I don't think that support is there, at least yet.  
> Without it, changes in forms or procedures probably do not 
> produce better results and, if delay is considered an 
> important cost, might produce worse ones.
> 
> regards,
>     john
> 
> 
> 
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ietf
> 

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]