ietf
[Top] [All Lists]

Re: Comments on draft-aboba-sg-experiment-02

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