Thanks Jari, Eric. Some notes inline ...
On 10/8/2007 12:03 AM, Jari Arkko wrote:
<snip>
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.
I am not sure what kind of "abuse" you are worried about Eric. Please
clarify.
This would be helpful. Bernard, Laksminath, any ideas?
I don't think we should make it algorithmic and instead should leave the
steering, direction and judgment aspects of an IESG job intact. That
said, my expectation is that the sponsoring AD is responsible for
considering the general guidance the draft offers and making a decision
on whether to form an SG, suggest a(nother) BoF session, form a WG, or
say that the work is not appropriate at the IETF at the time, etc.
The motivating text is:
"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. "
The guiding text is:
"Study Groups MAY be formed
by the IESG when there is evidence of clear interest in a topic on
the part of IETF participants and end-users, but other criteria
relating to Working Group formation (including creation of a
satisfactory Charter) have not yet been met."
We could make the guiding text more precise (perhaps include some
specific criteria), if that is what the community wants.
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?
We could clarify, but the intent is to follow the WG process for formation.
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?
I disagree with Eric here. I believe that we are not a meeting based
organization and should be making more of these important decisions via
email where we have more time to consider the proposals carefully. My
observation based on some of the BoFs I have been involved with recently
is that far too much time is wasted between two BoF sessions. With
little or no discussion between sessions, a good portion of the meeting
time is used to get on the same page (again).
That aside, if the sponsoring AD believes that the in-person events are
important, they may suggest a BoF as a first step to bringing new work
to the IETF. An SG may come after that.
regards,
Lakshminath
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
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf