Comments on draft-aboba-sg-experiment-02

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

 



$Id: draft-aboba-sg-experiment-02-rev.txt,v 1.2 2007/10/08 01:38:07 ekr Exp $

I don't find the motivation for this work particularly compelling:

   In some situations, while interest on the part of IETF participants
   and end-users may be evident, and the relevance to the Internet
   community may be demonstrated, the answer to other questions (such as
   an understanding of existing work, achievability of goals, or overlap
   with existing working groups or standards bodies) may not be as
   clear.  In the past, the likely outcome in this circumstance has been
   to postpone Working Group formation or even additional Birds of a
   Feather (BOF) sessions until satisfactory answers are forthcoming.
   However, in practice this may leave the status of the potential
   Working Group officially undetermined for months or even years.
   While the Area Directors should provide potential Working Group
   participants timely updates on the status of the potential Working
   Group and insight into IESG or IAB concerns, currently there is no
   mechanism to track progress toward working group creation, and as a
   result, participants may not have a clear understanding of the status
   or the next steps.  Also, the lack of formal recognition may
   negatively affect the motivation of the participants, and may leave
   those who have no followed the effort closely with an impression that
   no work is going on.

I think there's a more meta-issue here: do we think it would be good
for the IETF to have more WGs? If the answer is "yes, then it makes
sense to foster new work in various ways. If the answer is "no" then
it makes sense to treat getting an effort ready for WG formation as a
proxy for the level of readiness of that effort. My general feeling is
that the answer is "no." In some areas, such as RAI, every slot is
filled and there are sometimes double bookings.  Even in other areas,
conflicts are a serious problem and documents that everyone agrees are
important languish for lack of attention.  So, I'm not sure why a
change that's designed to make WG formation easier is a good
thing--nor that experimenting with such a change is.

A related issue is that this puts pressure on ADs to approve SGs for
efforts that they would ordinarily simply refuse WGs for. I.e.,
"OK, so you won't give us a WG, how about a SG". Currently this
document simply has it at the IESG's discretion:

   If at any point during the Working Group formation process, including
   after a first or second BoF session, interest within the IETF and
   end-user community has been demonstrated, but one or more Working
   Group formation criteria outlined in [RFC2418] Section 2.1 has not
   yet been met, the IESG MAY propose that a Study Group be formed.

This seems ripe for abuse of the kind I outlined above. IMO this
document would benefit from a clearer statement of the conditions
under which it was appropriate to form an SG, thus reducing pressure
on ADs. Arguably, SG formation should be subject to an IETF LC in the
same way that WG formation is. 

Finally, it's unclear the extent to which SGs are intended to
transition directly to WGs without going through another BOF
phase. I have two concerns here:

1. It will be hard for the IESG to deny "successful" SGs the right
   to form a WG.
2. BOFs are a defined in-person event at which everyone knows that
   WG formation is being considered. This provides an opportunity
   for public high bandwidth discussion of that topic. I don't
   think an LC on the IETF list is an adequate substitute.

Both of these issues are exacerbated by the tendency of running WGs
(and I would expect SGs) to become insular. Since the point of a
BOF is to encourage widespread input and more or less by definition
an SG has failed at this stage, it seems unwise to allow SGs to
become WGs without a real public vetting stage.

In response to these objections, one might argue that this is only
experiment, intended to evaluate the workability of a proposed change.
That is of course true, but because we can only run a relatively
small number of such experiments, it seems to me that one ought
to ensure that:

1. The experiment is in service of a goal which we all pretty
   much agree is good (since it's much harder to evaluate that
   than whether the goal was achieved.)
2. The experiment be designed to test the best available variant
   of an idea.
3. The experiment be structured to do the minimal amount of harm 
   if it fails.

It's not clear to me that this proposed experiment meets these
desiderata.

-Ekr

_______________________________________________

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]