[Pesci-discuss] Section 6 comments

> My most burning question is whether section 6 of the PESCI document is 
> a realistic and acceptable way forward to get the process of getting 
> important changes done running

As requested.

>    What the PESCI design team propose should be done next:
>
>    We believe that an early proposal is needed for a new process for
>    developing changes to the IETF processes especially in the area of
>    developing standards documentation and other specifications.
>
>    This proposed new process
>    o  would be used by all individuals, design teams, and working groups
>       who wish to propose changes or additions to IETF processes,
>    o  should involve consultation with the IESG, the IAB, the IAOC, the
>       Working Group chairs, and IETF participants generally, but
>    o  must avoid requiring the IESG to develop the new processes or
>       micromanage this process of development and approval.
>    The new proposals, both for the change process and any resulting
>    changed processes, should be implemented as a matter of urgency and
>    should be handled expeditiously by the existing approvals and
>    publishing process.

This says very little in terms of concrete things, except that
the process needs an "early proposal", is used by everyone,
involves consultation with existing bodies,  is "urgent"
and "requires no micromanagement".

> 6.1.  Change Process Proposal
>
>    We propose that the design team model is the most effective way of
>    engineering process changes.  Within the context of the existing IETF
>    process, this could be arranged by constituting a set of design teams
>    with appropriate oversight and the charter of carrying out process
>    change.  The design teams would operate within these charters: the
>    overseers would invite design team members to participate, but
>    alternative teams could offer solutions if they feel they have better
>    solutions.
>
>    The teams should function with an open discussion list, in the same
>    way that the PESCI committee has done.  The result of the committee
>    should be tested against the IETF consensus in the normal fashion; we
>    believe that if there is clear IETF consensus that the proposal makes
>    sense, the IESG (and the ISOC Board of Trustees) will respect that
>    consensus and approve of it.

This is mostly OK. I just wonder where the efficiency compared
to a WG approach comes from (we all agree it hasn't worked well).
Even in a WG, its somewhat private groups that develop documents.
The difference between the above and the WG process appears
to be mainly that instead of a WG and IETF approval steps, we will have
just one, IETF approval step. I'm reasonably certain that we,
the IETF, still have sufficient possibility to affect the outcome,
which I think has been some people's concern. But I'm not sure
you will avoid some of the earlier problems that the WG processes
have had. We could still be in for a lengthy discussion at IETF
level. But maybe that's fine.

I definately want to keep my ability to comment on and
affect proposals. Maybe it helps that the discussion
will be in plenary/ietflist instead of some obscure and
ever-changing wg/mailinglist... most of the what we need
is a statement from the troops who actually do IETF
stuff, not from the few process fanatics or parts of
existing management... sometimes it feels that the
discussion (as well as mike time in plenaries) is
more or hijacked by a select few.

> 6.2.  Immediate Tasks for the Change Process
>
>    Assuming that the model suggested in Section 6.1 is adopted, the
>    following process change task appears to be the most urgent one, and
>    a team should start on this as soon as possible.
>
>    The most important single management role in the IETF at the moment
>    is that of the IESG, including the role of IETF Chair.  This should
>    therefore also receive the most scrutiny.  It's unreasonable to ask
>    people to grade their own performance, or to attempt to perform a
>    role at full speed while having to review how it could be done
>    otherwise.  Therefore, a review of the roles the IESG has should be
>    rooted outside the IESG - while asking current and former IESG
>    members for information and advice at every opportunity.
>
>    This should include:
>    o  Creating a list of the tasks that currently gate on the IESG
>    o  Identifying any additional related tasks that might be appropriate
>       to improve efficiency and effectiveness
>    o  Making proposals for discarding or restructuring the existing
>       tasks in combination with the new tasks
>    o  Making a proposal for grouping those tasks into separate task
>       groups that can be assigned to different bodies at need.
>    o  Developing a proposal for how the standards development work of
>       the IETF should be partitioned to provide optimum efficiency while
>       allowing the IETF to take on all appropriate work.
>    o  Developing a suggestion for an initial set of bodies for handling
>       those tasks in the new work partitioning scheme, including, if
>       appropriate, a restructuring of the IESG.
>    o  Describing the process by which the set of bodies gets modified.
>    o  Describing how members of the proposed bodies get selected,
>       replaced, and (if needed) r

I'm actually not at all certain that IESG restructuring
is priority 1. I think there's a good chance that
some of the non-basic AD tasks should be moved
to other bodies, including, for instance, process
changes. I would rather do a small change wrt IESG
role along with a few other changes elsewhere.

Anyway, I agree very much that IESG changes should
be performed by someone else than the IESG. It
puzzles me though, that the IESG would be selecting
the people to work on IESG role changes. Not sure
how to fix that, unless we have nomcom pick process
change masters, or have the IAB supervise pesci
instead.

The text isn't clear enough that all of the above bullet items
are intended to be about IESG's role. (Or are they?)

Item 5 appears to not belong under IESG restructuring, imho.
(I like item 5, but it seems that its more of an area etc issue.)

I'm a bit surprised that Section 5 worked hard on what items
should get a restructuring and then in Section 6 you decide
that just one of those does. I think we can afford upto a few
design teams at a time to look at other issues, too. I think
excellent bang-for-the-buck ratio could be reached from
rfc editor model changes. WG process is the other major
consumption of time at the moment, so improving that
would also be a priority (just that I don't know how). Trend
for openess should also continue.

So my suggestion would be to say that along with a
smaller scope of an iesg role change, 1-2-... other design teams
be created as well initially to look at the other problems, in
parallel.

--Jari

_______________________________________________
Pesci-discuss mailing list
Pesci-discuss@ietf.org
https://www1.ietf.org/mailman/listinfo/pesci-discuss