Eric, Thanks for your comments. A couple of responses inline: > 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". First, this proposal does in no way change the situation that the ADs have to say NO a lot of the time, and be able to justify that answer. Just as a data point from one AD, I have given that answer to many BOF requests and WG formation requests, and I don't feel saying no to something in between is going to be a problem :-) assuming the group indeed is not ready. But the issues with scheduling, lack of attention for important topics, and low quality of new work proposals are real concerns. I have a slightly different take on this than what you had above, however. INT is probably the most troublesome area with respect to scheduling, and I generally do not have any free slots during an IETF meeting. However, I don't think this implies we shouldn't consider new work. Its not as if the Internet was ready and nothing new was ever needed. We have a number of serious issues and new demands to meet. But we need to actively manage the set of things we work on. Some of the tools we need to consider include actually stopping WGs that have completed their task, rechartering, management restructuring (e.g., merging groups), questioning whether a non-delivering WG needs to continue to exist and consume slots, and yes, even new work. > 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. This would be helpful. Bernard, Laksminath, any ideas? > Arguably, SG formation should be subject to an IETF LC in the > same way that WG formation is. > Hm. I believed this was already the case. SGs are subject to exactly the same process as WGs, and I was assuming that like, WG formation, SG formation would include discussion in the IESG, consultation with the IAB, and IETF Last Call. Perhaps this needs clarification. Authors? > 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. > Saying NO is still going to be needed. > 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. > Good point. Bernard, Laksminath -- any ideas here? > 3. The experiment be structured to do the minimal amount of harm > if it fails. > In IESG review of this proposal, one of the things we talked about was whether there is a way to limit this experiment so that we can indeed test the idea but avoid impacting everyone. One of the suggestions was to set a limit on the number of SGs during the experiment to some low value, such as three. I would be in favor of this limitation. Jari _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf