Charters, "normal process" versus ISOC, etc. (was: Re: OPEN ISSUE: Quality Process WG Charter)

James Kempf kempf at docomolabs-usa.com
Mon May 19 09:05:38 CEST 2003


John,

I like this idea. We should kick it around a little to see if anybody
comes up with any potential unintended consequences, but I can't think
of any.
            jak

----- Original Message -----
From: "John C Klensin" <john-ietf at jck.com>
To: "Margaret Wasserman" <mrw at windriver.com>
Cc: <problem-statement at alvestrand.no>
Sent: Sunday, May 18, 2003 7:51 AM
Subject: Charters, "normal process" versus ISOC, etc. (was: Re: OPEN
ISSUE: Quality Process WG Charter)


>
>
> --On Friday, 16 May, 2003 11:54 -0400 Margaret Wasserman
> <mrw at windriver.com> wrote:
>
> >> I don't think this group should propose a charter for that
> >> group.
> >>
> >> And I'm not sure I even agree with the text in the process
> >> document about how that group should proceed.
> >
> > Would you like to propose an alternative?
>
> Margaret, I'd like to propose something as a strawman, partially
> based on further thought after my comments about process
> yesterday.  This is a radical suggestion and may not be a good
> idea, but I'd like to see if it resonates with others or at
> least stimulates some discussion and other suggestions.
>
> We seem to have three perspectives/ camps at the moment:
>
> (1) Use the normal process, including assigning these
> working groups to the IETF Chair (i.e., the "General
> Area").  That means having the Chair appointed by, and
> serving at the pleasure of, the IETF Chair, the IETF
> Chair making decisions about what WG decisions get
> processed by the IESG, etc.
>
> (2) Some people are deeply concerned about this, seeing
> the IESG as the problem and resistant to reform and the
> IESG generally, and perhaps the Chair in particular, as
> subject to inherent conflicts of interest in a reform
> process.   Many of them lean toward an ISOC-controlled
> process.
>
> (3) Some (perhaps very few) of us are more trustful of
> the IESG as a group, but are uncomfortable about the
> General Area, the notion of the IETF Chair wearing this
> hat in addition to all of the others, and the
> implications the first approach causes with the appeals
> process.  We also don't see an ISOC-based approach as
> really being feasible.
>
> So, again, at least as something to think about, I suggest a
> fourth option:  We ask the IESG to expeditiously create a new,
> but temporary, area for process review and reform, with, say, a
> one-year expiration period requiring community assent to keep it
> going any longer.  We ask the Nomcom to select an AD for that
> area, again asking them to expedite the action.  The IESG
> appoints one of its number (with the Chair/ General Area AD
> being the obvious choice since the workload would be the same as
> under option (1)) to fill in during the interim.
>
> What does this do for us?
>
> * Like the ISOC plan, it puts someone in as "responsible
> AD" for this work who is selected/ designated for the
> purpose and who is not part of the existing IESG.  The
> reduces suspicions about conflicts of interest.  And...
>
> * It also reduces concerns about available skill sets
> (since the Nomcom would be selecting someone
> specifically for this role) and time availability (since
> the chosen AD would have no other WG or external
> responsibilities).
>
> * It is very much part of the existing process model,
> doesn't raise special concerns about appeals, etc.
>
> * And I think we can assume that a person who was
> designated as responsible for this area would raise a
> public outcry --if necessary to the point of filing
> recall petitions-- if any of the blocking actions of
> which the IESG has been accused occurred wrt the outputs
> these relevant WGs.   Indeed, if I were to advise the
> Nomcom, I would suggest that willingness to go that far
> --and good sense about when or whether to do so-- would
> be an important criterion for a prospective candidate.
>
> And, to preempt any paranoid speculations, I don't want the job.
>
>        john
>
>
>



More information about the Problem-statement mailing list