I would like to note that the use of this process was not agreed to by a
consensus of
the IESG.
Brian sent early versions of this proposal to the IESG, and it received
considerable pushback, some of it from me. I strongly encouraged
Brian to use a design team to draft a charter for a tightly focused working
group in the General Area instead. I agree with Brian that general
discussion of IETF process change tends to diverge and to move slowly,
but I believe that working groups like NomCom show that we can succeed
with focused charters in establishing new procedures or revising existing
ones. I believe the public chartering process of a focused working group
is a useful, necessary part of the openness of the IETF process, and that
the public discussion within that charter, once established, is critical
for process change of the scope envisioned.
It is not clear from the note below whether every volunteer to serve will
be a part of the PESCI team team, or whether the group will be selected
from among the volunteers by Brian. I ask him to clarify that point.
It is not clear from the note below whether the pesci-discuss list is the
discussion list for the PESCI design team or a conduit of community
input into its deliberations. I ask Brian to clarify that point.
Brian notes that after his design team reports to the IETF on the IETF's goals
and principles multiple things may happen, among them:
- decide whether to renew the PESCI design team (assumed below)
or use an alternative discussion forum
- consider various process change proposals from any source
- reach a team consensus on a consistent set of proposals
and a sequence for implementing them, with target dates. All
proposals must embed the principle of rough IETF consensus and
must provide an appeal mechanism.
- one of the proposals, likely the first, may be a proposal
for a new process for process change
- post the proposals as Internet-Drafts intended for publication
as BCPs
It is not clear who decides whether to renew the PESCI design team.
Its creation is a unilateral decision of Brian as Chair; is the decision
for renewal subject to public review?
Given the lack of a working group, who decides among alternatives
agreed to by consensus of this design team and those proposed
outside of this mechanism, should there be alternate proposals
that are proposed to the IETF?
Though Brian notes that there are multiple possible outcomes after
PESCI reports, this step appears to be a concrete proposal for how
to proceed:
forward proposals for approval as BCPs* and acceptance by
the ISOC Board. Until such time as the new process for process
change has been approved, the proposals will be submitted
directly to the General Area Director and the approval body
will be the IESG. However, the IESG members' principal chance
to comment on and influence the proposals is prior to their
forwarding for approval.
Brian has commented in the past on the difficulty of him being both
Chair and General Area Director, and this highlights the problem.
Brian is choosing to start the PESCI effort as IETF Chair(Roll 1); he will lead
it (Roll 2);
he will then forward its proposal to himself as General Area Director (Roll 3).
The IETF has had a serious queueing problem for a long time, as things have
evolved such that "important to the IETF" has meant "passes through the IESG".
That's deeply wrong (and very slow), and it needs to change. Getting us to a
point
where new queues are available for distinct tasks is a good idea, and "process
change
management" is clearly a distinct task from "manage working groups", which is
the IESG's basic job. But getting us to that new point by funneling the
interim
change process through a single individual (in however many multiple roles)
is equally wrong.
I ask Brian to adjust this plan so that PESCI's output is a charter for a
working group
that can achieve at least the first task "set up a new change management
process"
according to the existing system. I strongly support the need for change, and
I believe that to achieve the appropriate community involvement this is
required.
regards,
Ted Hardie
At 11:21 AM -0400 9/16/05, IETF Chair wrote:
There has been quite a bit of community discussion of IETF process
change in recent months. Obviously, process changes must obtain
rough consensus in the IETF and follow the procedures in place
(principally RFC 2026 today). However, past experience has shown
that general discussion of IETF process change on the main IETF
list, or in a normal working group, rapidly tends towards divergent
opinions with consensus being extremely hard and slow to establish.
On the other hand, we have experience that discussion of simply
formulated principles and of consistent process proposals can be
constructive and convergent.
This note describes a method of starting the next phase of IETF
IETF process change, possibly including updating the change process
itself.
As IETF Chair, I intend to lead a short term design team, to be
known as PESCI (Process Evolution Study Committee of the IETF).
I will request PESCI to
- review recent discussions on IETF process changes
- identify a concise set of goals and principles for process change
- publish these for comment and seek IETF debate and rough consensus
The target is to have a draft of goals and principles by IETF64.
The next steps will depend on the agreed goals and principles
after this debate. It is very likely that we will need
a process that will generate a consistent set of proposals
and a sequence for implementing them, with target dates. It is
also likely that the first proposal will be a new process for
process change. And it's a given that open discussion and
rough consensus, in accordance with IETF principles, will
be required.
A non-binding proposal for the next steps is appended to this
message.
Given the short time until the next IETF, the team will have to
start very soon and work quite intensively. If you would like to
volunteer for the PESCI team or nominate someone to serve on it,
please send me email immediately. I want to create the team within
a week.
Brian Carpenter
IETF Chair
N.B. The open discussion list will be pesci-discuss(_at_)ietf(_dot_)org,
but it hasn't yet been created at the time of sending this message.
-----
Possible next steps after the PESCI goals and principles are agreed:
- decide whether to renew the PESCI design team (assumed below)
or use an alternative discussion forum
- consider various process change proposals from any source
- reach a team consensus on a consistent set of proposals
and a sequence for implementing them, with target dates. All
proposals must embed the principle of rough IETF consensus and
must provide an appeal mechanism.
- one of the proposals, likely the first, may be a proposal
for a new process for process change
- post the proposals as Internet-Drafts intended for publication
as BCPs
- seek IETF-wide rough consensus on these drafts
- legal considerations, IASA financial considerations, and
considerations of practicality raised by current or past
Area Directors, WG Chairs and the like will be given special
consideration. If IETF consensus appears to be for a proposal
which is legally, financially or practically unacceptable,
PESCI will need to convince the community to change its mind.
To enable this, as relevant, the ADs, IAB members and IAOC
members including the IAD will be asked to provide personal
input specifically on the feasibility of implementing the
proposed process changes as they affect their specific roles.
- forward proposals for approval as BCPs* and acceptance by
the ISOC Board. Until such time as the new process for process
change has been approved, the proposals will be submitted
directly to the General Area Director and the approval body
will be the IESG. However, the IESG members' principal chance
to comment on and influence the proposals is prior to their
forwarding for approval.
*An alternative would be to use the mechanism described in
RFC 3933, if consensus was weak. In particular, this can be
used to experiment with the practicality of ideas.
Additional conditions for PESCI's work
- a subsidiary goal is to end up with a clearly defined
and interlocked set of process documents, rather than
a patchwork of updates to existing documents
- PESCI will provide an open mailing list where discussion
with the community will be encouraged. It will
issue regular (monthly?) progress reports and generally
operate as transparently as possible. Discussion in IETF
plenary sessions is also expected.
- nothing in this proposal prevents ongoing operational
improvements within the current process.
_______________________________________________
IETF-Announce mailing list
IETF-Announce(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf