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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf