Re: IETF Process Evolution

[Brian E Carpenter <[e-mail]>]

Ted,

Ted Hardie wrote:
> I would like to note that the use of this process was not agreed to by a consensus of
> the IESG. 

Indeed not. To be frank I feel that the IETF Chair has to be independent
of the IESG in certain matters, even though the ADs are deeply dependent
on the way the process is defined.

> 
> 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.

I very nearly sent my note with the whole "possible next steps" text
deleted, but was advised that would leave things too open. If the consensus
after the first stage is to set up several tightly focussed WGs, that will
be just fine by me. But we aren't there yet.

> 
> 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.

I don't think that's possible. I already have about ten names and that
is too many for a focussed effort, so I will have to select.

> 
> 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.

pesci-discuss will be open to the community -- hopefully it will be up and
running today or tomorrow. (My preference is to have a dedicated list,
simply so that *this* list can remain as the general-purpose list.) We'll
have a private list for the team, like any design team.

> 
> 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?

I don't want to appear flippant, but it seems that every decision in the
IETF is subject to public review. (Actually, that is probably a candidate
for the list of PESCI principles.) So let me say that if PESCI proposes
that it should be renewed after the initial phase, that would need to
be part of the consensus that we have to form. My intention here is to
bootstrap a process, not to dictate the future of the IETF.
> 
> 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?

That's why I want to focus on simple statements of goals and
principles - it will be much easier to argue for or against specific
proposals against a background of agreed principles. If you're saying
that a design team doesn't have priority over an independent proposal,
I can only agree - ultimately proposals have to be discussed on their
merits.
> 
> 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. 

That's a fact of life: that *is* the current process.


>> However, the IESG members' principal chance
>>   to comment on and influence the proposals is prior to their
>>   forwarding for approval.

And that is an intention - it would clearly be highly unfortunate
for the IESG to find objections of principle at a late stage in
the consensus-building process.
> 
> 
> 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).

I have no problem with filling both role 1 and 2. I think it comes with the
territory. It may well be that role 3 raises potential issues - that is
why I think an early proposal should be for a change to the change process.

> 
> 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.   

There I'm afraid that pragmatism wins. Whether it's right or wrong, it's
the process we have today.
> 
> 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.

Well, I believe that community involvement is required to (as it was required for
BCP 101). But I don't assume that a WG is the best way to get that involvement for
the first steps - as noted above, it may well be best for later steps once they are
based on clear principles.

Briefly, on your other message about

> WG Name:  New Queues (NQ)

Well yes, I will be very happy if we can focus enough to get a set of concrete
proposals like that a few months from now. That would be ideal.

     Brian

> 
> 			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 [e-mail],
>>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
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/ietf-announce
> 
> 


_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf