Subject: RE: Straw process outline for dealing with structural and practic es problems

From: "Elwyn Davies" <[email-masked]>
Date: Fri, 18 Jul 2003 10:29:29 +0100

I agree with Brian's view that speed is of the essence.  Whilst there was
little convergence on the way forwards with the process, a significant
fraction of those present recognised that there were problems to solve and
so we need some sort of process to go forwards.  I'll take a look at
draft-hardie-alt-concensus-00 to see if we can merge the proposals, or make
some improved suggestions.  In the meantime maybe some members of the IESG
could give a view on whether this alternative has any resonance for them.

[With my problem statement editor hat on] I will review what was said in the
plenary last night and publish some ideas for mods to issue-02 over the
weekend.

Regards,
Elwyn

> -----Original Message-----
> From: avri [mailto:[email-masked]]
> Sent: 18 July 2003 10:05
> To: [email-masked]
> Subject: Re: Straw process outline for dealing with structural and
> practices problems
> 
> 
> I think it would need a consensus process for this group to pass
> this on to the IESG, though of course Elwyn could so, or the IESG
> which I believe is well represented on this list, could just 
> pick it up
> and combine it with whatever other processes ideas they were
> looking at.
> 
> In the meantime I think it a good idea for this group to keep talking
> about this and any other process suggestions and see if we can come
> up with something we can reach consensus on.  If the IESG reaches a
> decision point before we are done, so be it,  but we should not
> presuppose that they will and should keep working on in WG fashion.
> 
> a.
> 
> 
> On fredag, jul 18, 2003, at 10:15 Europe/Vienna, Brian E Carpenter 
> wrote:
> 
> > I think this is a possible approach, but given the lack of 
> convergence
> > last night on a model, I don't think the subset of us in 
> this WG have
> > any particular authority to decide. I suggest forwarding 
> this sketch of
> > a solution to the IESG, in the hope and expectation that they will
> > rapidly steer in this (or some other) direction.
> >
> > What we must avoid is a period of indecision about starting the
> > process. If we are going the way you suggest, we need the Nomcom 
> > working
> > on it by the end of next week.
> >
> >    Brian
> >
> >> Elwyn Davies wrote:
> >>
> >> A number of people involved in the problem WG have been thinking 
> >> about an alternative to using a WG to work through the
> >> structural and practices problems that we believe we have 
> identified 
> >> with the IETF, and come up with a proposal for revisions
> >> (if any) to the way the IETF operates.
> >>
> >> This proposal is offered as an alternative to the 
> proposals discussed 
> >> at tonight's plenary...
> >>
> >> In outline the plan requires:
> >>
> >>     o  Selection of a 'Synthesis and Answer Panel' (SAP) which will
> >>        moderate the process and own the final proposal for change 
> >> under
> >>        the general oversight of the IESG.
> >>
> >>     o  Generation of a list of issues that appear to require 
> >> attention,
> >>        initially in this document, but subject to additions by 
> >> agreement
> >>        of the SAP.
> >>
> >>     o  Solicitation of contributions from individuals or groups of 
> >> IETF
> >>        stakeholders which will address solutions to any part of the
> >>        problem space.
> >>
> >>     o  Synthesis and moderation of interactions between the various
> >>        contributions by the SAP in order to create a proposal which
> >>        appears to result in an organization which will, so 
> far as is
> >>        possible, no longer suffer from the issues identified, and a
> >>        minimally disruptive changeover process.
> >>
> >>     o  Acceptance of the proposal initially by as large a 
> part of the
> >>        IETF community as possible through open discussion by email 
> >> and at
> >>        plenary session(s), and finally by the existing IESG at the 
> >> time
> >>        of completion.
> >>
> >>     The plan will be subject to a tight timetable, 
> enforced by the SAP
> >>     with the backing of the I* and intended to deliver an accepted
> >>     proposal at the second IETF meeting after the inception of the 
> >> SAP.
> >>
> >> Constitution and Selection of the SAP
> >>
> >>     The SAP will comprise a number of members that is sufficiently 
> >> low so
> >>     that the group is able to take decisions rapidly and 
> effectively. 
> >> The
> >>     members of the SAP (SAPs) will be selected to represent the 
> >> interests
> >>     of as wide a range of the stakeholders in the IETF as 
> is possible.
> >>     To this end one group of the SAPs will be nominated by the 
> >> existing
> >>     management structures of the IETF (IESG, IAB and ISOC) 
> whilst the
> >>     remainder will be selected through an extension of the standard
> >>     nomcom process.
> >>
> >>     There will be eleven members of the SAP as follows:
> >>
> >>     o  Two members of the current IESG nominated by the IESG.
> >>
> >>     o  Two members of the current IAB nominated by the IAB.
> >>
> >>     o  One member of the current ISOC Board nominated by the ISOC 
> >> Board.
> >>
> >>     o  Six members selected by the same process as is used by the
> >>        to select the Nomcom with the variation that the 
> qualification
> >>        would be attendance at least 5 IETFs with the first 
> attendance
> >>        must be during 2000 or before.
> >>
> >>     The SAP would elect its chair from amongst its members 
> (as with 
> >> the
> >>     IAB).
> >>
> >>     Decisions would be by a voting process determined by 
> the SAP as 
> >> per
> >>     nomcom.
> >>
> >>     The SAP would also be able to encourage members of the 
> community 
> >> to
> >>     address problem areas that appeared to be 
> underrepresented in the
> >>     solutions presented.
> >>
> >>     The whole process should run to a tight timetable - 2 
> IETFs from
> >>     initiation to submission of completed proposal might be good!
> >>
> >> Regards,
> >> Elwyn Davies
> >>
> >> on behalf of Jeanette Hofmann and myself who fleshed out 
> this proposal
> >> from ideas by various members of the Problem WG editorial team.
> >
> 
>

---

From: "Elwyn Davies" <[email-masked]>
Date: Mon, 28 Jul 2003 10:21:51 +0100

Hi.

Perhaps we should have reversed the order of the text of the proposals:
I agree that we need to start producing ideas for solutions NOW, and that
was part of the straw process although it was said late on.  The exact
mechanics of the selection/compromise/synthesis process are moot until it
has something to work on.

So let this be a call to arms!

Whether you think the problem statement, as it is, is right or not, if you
(singular or a group) have ideas for a fix or a way forwards for some part
of the problem as you perceive it, get it written down and put it in front
of the community as soon as possible.

We can work on an acceptance process in parallel.

Regards,
Elwyn

> From: Dave Crocker [mailto:[email-masked]]
> Sent: 27 July 2003 18:12
> Folks,
> JCK> And that brings me back to my Thursday evening comment.  I
> JCK> think it is time to _do_ something, not design structures for
> JCK> talking about what to do.    I think we should go through the
> 
> John and others have raised a number of concerns about a number of
> proposals, notably the one coming from a subset of the 
> problem-statement
> editors' team. I was/am part of that team, but did not 
> contribute to the
> proposal, except for a quick, late-stage review.
> 
> I think we need to pursue some very separate lines of discussion, to
> give this whole topic proper consideration.  What follows separates
> discussion of the timing of change, the source of proposals 
> for change,
> and the authority for making decisions about change.
> 
> 
> 1.  TIMING OF CHANGE
> 
> I keep pointing out how long it has been since Yokohama, because this
> much passage of time, with no change, suggests that the 
> actual operation
> of the IETF is proving to be more interested in discussing 
> process than
> in improving our work... by making changes that will have real and
> useful effect. (No, I don't believe anyone actually intends this to be
> true, but so far, our actions show the truth of that fact.)
> 
> I also point it out because it means that we are suffering the same
> problem with timeliness in our change effort as we do in our protocol
> development: loss of market window. In other words, loss of 
> opportunity
> and relevance.
> 
> In this case, the "market window" has to do with the attitudes of
> participants. When folks feel a deep sense of frustration and the
> frustration does not get resolved anytime soon, folks will typically
> give up. This fact plays heavily on the interpretations and 
> validity we
> can assert, about "feedback" we are getting during our continuing
> process. (For the statistically inclined, think of this as biasing the
> sample.)
> 
> So, the calls from a number of folks to start making changes, rather
> than to continue talking about the process of change, seems 
> is entirely
> appropriate. The fact that it is coming from a number of independent
> participants -- and I continue to be amused when John K. and 
> I agree on
> a topic's recommendation phase, not just its analysis phase -- should
> carry some weight.
> 
> 
> 2.  SOURCE OF CHANGE PROPOSALS
> 
> At this point, quite a few people/groups are suggesting that 
> the source
> of useful proposals for change need to come from... The IETF populace
> and not from specially "authorized" representatives.
> 
> There is an key, implicit message here, folks.  Ultimately, this is
> "our" organization and we call for the specifics of change, 
> not just the
> concept of change.  Yokohama made clear that change is needed, but it
> did not specify the details.  The details are in the specifics of
> careful proposals.  They must come from us.
> 
> The fact that this perspective seems to be coming from a 
> number of very
> independent sources suggests that it is not all that controversial. At
> the least, I haven't seen a serious alternative to it 
> proposed recently.
> 
> The bottom line from this is that we need concrete, detailed proposals
> for concrete, specific changes, backed by their rationale.  Some are
> starting to emerge.
> 
> What is essential is that anyone having an idea that is not 
> yet written
> down and available for review needs to do that work.
> 
> Anyone.
> 
> As in, not just our "leaders" and not just some designated committee.
> 
> Anyone and Everyone.
> 
> 
> 3.  AUTHORITY TO ADOPT SPECIFIC CHANGES
> 
> So, given a panoply of concrete, detailed, serious proposals, how does
> the IETF choose ones to implement?  Here lies the divergence of views.
> (And frankly, I was getting tired of agreeing with John so much.)
> 
> Some suggest the IESG.  Some suggest a blue-ribbon committee.  Some
> suggest the IETF Plenary.
> 
> I now believe all those ideas are fundamentally flawed, 
> though I remain
> somewhat biased towards the last of these, though it too is flawed.
> 
> The universal flaw is that all of them ignore the real need for real,
> broad, community support. Whatever is chosen, the community has to
> embrace it. This being a community of rather independent 
> personalities,
> embracing does not occur because someone dictates it.
> 
> The IESG has no history deciding what process changes are best for the
> IETF. Further, its members have no special expertise in such 
> design and
> selection. Choosing some decision mechanism other than the 
> IESG does not
> imply that we are in melt-down or that the IESG is incompetent. It
> suggests that that is a body with different skills and 
> perspective than
> is appropriate for this category of decision-making.
> 
> A select, "blue-ribbon" committee is always an appealing idea, and
> always suspect.  It, too, has no track record of success for the
> decision it is making.   Unfortunately, there is no existing
> IETF-related body that does have that track record or that even
> obviously has the necessary skills about organizational design and
> change.
> 
> The Elwyn-et-al proposal invokes an multi-source sampling 
> mechanism for
> populating the committee. I've come to cherish the benefit of ANY
> diverse sampling technique, for populating a decision-making 
> group that
> is intended to represent a larger community, as long as it has any
> reasonable basis. In particular, there needs to be some assurance that
> the folks being chosen are likely to be clueful. Its key strength is
> that it ensures a real diversity of views (and agendas.) 
> Hence, it works
> on independent contributions. This forces a negotiation and compromise
> process.
> 
> The problem with using an IETF Plenary session as the decision-making
> body is that it may well be too highly biased (limited) a 
> sample of the
> population.
> 
> Ultimately, however, I believe that the real decision-making 
> needs to be
> done by garnering strong support from the community. I won't go as far
> as invoking the usual "rough consensus" criterion, because we now have
> quite a bit of experience showing how difficult that can be to acquire
> or gauge, for "social" decisions.
> 
> And let's be clear that that is the realm we are in. This is human and
> group stuff, not technical. So, few if any of us have any 
> real skills in
> this. Worse, finding folks who *do* have those skills does 
> not solve the
> problem. In fact, there is no way to guarantee that any proposal will
> work as intended or even that it will work well. That is the 
> sad fact of
> life about this type of organizational change, especially for a group
> this diverse and diffuse.
> 
> To me, that means the only thing we can do is to make sure that the
> decision is as broadly-shared as we can make it. This begins by
> developing a constituency of support for a candidate proposal.
> 
> The nice things about such a direction of effort is that it 
> lessens the
> import of choosing the best group to make the "final" decision.
> 
> d/
> --
>  Dave Crocker <mailto:[email-masked]>
>  Brandenburg InternetWorking <http://www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
> 
>