Hi.
I've been trying to follow this discussion from a safe distance,
but, given the amount of traffic, I want to add three general
observations to the mix, possibly summarizing some earlier
comments including my own:
(1) Drawing analogies from IEEE, or IEEE 802, procedures
to the IETF and extrapolating what will work is a tricky
business, if only because of different ground rules for
participation and approval of projects and different
assumptions about standing committees / project areas in
the two groups.
(2) As the discussion goes on, if appears to me that, in
practice, an SG is little more than a normal WG with an
unusual set of charter-time constraints. While unusual,
those constraints are well within the boundaries of what
the IESG is permitted to do today. Indeed, I believe
that groups have been chartered under constraints and
with responsibilities not appreciably different from
those that would apply to an SG. From that perspective,
our real problem is that, in the last few years, IESG
members have not felt that they have sufficient
community support (or pressure) to quickly and
efficiently shut down WGs that are drifting or otherwise
not performing. An SG model could provide a less
painful shutdown point by permitting simply not
extending the SG or not granting a WG charter, rather
than having to shut down something that has a few
advocates or some investment, even if it is not making
progress. But, as others have pointed out, that same
opportunity exists in principle when WG benchmarks are
not met. Whether an SG model is effective in
eliminating pre-project efforts that would go nowhere
would seem to depend on precisely the same factors that
make the possibility of WG shutdown effective: support
by the community for identifying and shutting down
disfunctional efforts and willingness by the ADs for
doing so.
(3) I am concerned about anything that creates new
opportunities for making the process of getting work
into, through, and out of the IETF even longer and more
complicated. The worst risk associated with introducing
SGs is that, just as we have evolved from "A BOF, or
sometimes two, are optional steps to help get a WG
organized and focused" to "BOFs are almost always
required", we might evolve into the expectation of
spending one or more IETF meetings in SGs, as well as an
additional meeting or two in BOFs, before generating a
typical WG charter. In the notation of Lakshminath's
recent chart, we have moved from "Idea --> WG" being
the normal case, to "Idea --> BoF-1 --> BoF-2 --> WG"
being the normal case, to some risk of making "Idea -->
BoF-1 --> BoF-2 --> SG --> WG" normal. Under some
circumstances, that would be a year well spent. Under
others, it is just another year wasted in exploration,
extended problem description, and procedures when the
goal should be to do technical work and get useful
results out (and to cut unfocused ideas and ideas with
insufficient support out of the system with as little
wasted time and energy as possible).
Nonetheless, it seems clear from the list discussions that there
are a number of people in the community who think this is worth
trying. Precisely because it doesn't seem to create any
substantively new options or framework and because its use is
optional, it seems to me that it is worth trying, if only in the
hope of refocusing the energy that seems to be going into
discussing its details back onto technical work. I would
suggest that the "experiment" model was designed with the
intention of permitting experiments to be flexible and that it
would be preferable to either
* give the IESG discretion to set and evolve the details
or
* to establish an ad hoc experiment specification,
modification, and evaluation group to fix and modify
details and generally guide the experiment and advise
the IESG and the community about successes and failures
on an ongoing basis.
Very detailed design --whether of technology or procedures -- on
the IETF list has almost never worked for us in the past, yet it
seems that is exactly what people are trying to do with this
proposal.
Just my opinion, of course.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf