IETF Process Evolution: PESCI team members
I've picked the following PESCI team members from the various volunteers and nominees: Harald Alvestrand Scott Brim Elwyn Davies Adrian Farrel Michael Richardson Thanks to everybody who was willing to serve at short notice. As a reminder, PESCI's immediate tasks are: - 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 and the cutoff date for our first draft is October 17. As noted previously, the open mailing list is [EMAIL PROTECTED] (see https://www1.ietf.org/mailman/listinfo/pesci-discuss) You can write privately to the team at [EMAIL PROTECTED] If you've lost track of the background to PESCI, see http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01567.html ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: IETF Process Evolution
One thing I was thinking about when reading the call for volunteers for PESCI: I'd like to see thoughtful people on this group. Thoughtful people are likely to see that participatig in the group will be a painful experience. They are likely to not volunteer for the job. I'd like people to think about who they WANT to have doing this job (and who they do NOT want to have there?), and tell Brian about that. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Process Evolution
That list has about 25 people on it so far - almost critical mass, but I do suspect that more than 25 people have interest in this topic. Maybe next week would be a good time to switch over. Brian Spencer Dawkins wrote: Dear Brian, Should this thread move to pesci-discuss? Thanks, Spencer The open mailing list is up. Post to: [EMAIL PROTECTED] Subscribe via: https://www1.ietf.org/mailman/listinfo/pesci-discuss Archive at: http://www.ietf.org/mail-archive/web/pesci-discuss/current/index.html It's set up for members-only posting so that spam will get trapped. Non-member non-spam messages will wait until they are released by a moderator. Apart from that, there is no moderation, so please stay on topic and observe netiquette. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Process Evolution
The open mailing list is up. Post to: [EMAIL PROTECTED] Subscribe via: https://www1.ietf.org/mailman/listinfo/pesci-discuss Archive at: http://www.ietf.org/mail-archive/web/pesci-discuss/current/index.html It's set up for members-only posting so that spam will get trapped. Non-member non-spam messages will wait until they are released by a moderator. Apart from that, there is no moderation, so please stay on topic and observe netiquette. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Process Evolution
Dear Brian, Should this thread move to pesci-discuss? Thanks, Spencer The open mailing list is up. Post to: [EMAIL PROTECTED] Subscribe via: https://www1.ietf.org/mailman/listinfo/pesci-discuss Archive at: http://www.ietf.org/mail-archive/web/pesci-discuss/current/index.html It's set up for members-only posting so that spam will get trapped. Non-member non-spam messages will wait until they are released by a moderator. Apart from that, there is no moderation, so please stay on topic and observe netiquette. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Process Evolution
As I've said on the other occasions I've had to see versions of Brian's proposal, My completely personal opinion: . it's reasonable for Brian to appoint a committee of whomever he wants, by whatever process he wants, to do whatever he wants . the outcome of that committee *MUST* fit in with our existing process: the IETF cannot be constrained to accept the output of that committee unless it has gone through full IETF review and existing process which I think is largely in agreement with what Ted and John have said, and isn't disagreeing with the text of Brian's statement. From here, the devil is in the implementation details, IMO: . how Brian will identify folks with (both) sufficient involvement and time to devote to produce a draft by IETF64; . how to have the public review of/input to any proposal(s) that has sufficient community engagement without ratholing (i.e., simply deferring all the aforementioned unsuccessful points of WGs) The first point is an oblique suggestion that we have patience in IETF64; the second is a suggestion of requirements. Leslie. John C Klensin wrote: Ted, I finding myself agreeing with you in many ways, but probably for different reasons. I'm trying to better formulate the differences instead of (or at least before) posting something incoherent, but, in the meantime... --On Friday, 16 September, 2005 16:45 -0700 Ted Hardie [EMAIL PROTECTED] wrote: At 2:28 PM -0700 9/16/05, Dave Crocker wrote: And since all other public development efforts for process change have frankly fallen flat, as Brian has cited, what is your basis for believing that a working group charter will somehow make yet-another public process more effective at developing a specification for change? Possibly I'm wrong in this, but I believe that the public process works when the community cares about the outcome. The IASA work is done, and I believe it is a success because enough people cared about the outcome to make it one. I think there are two conditions. The first is caring and the second is a very narrow and specific focus, with serious thought and debate going into that focus. There were good things about the AdminRest-IASA process and bad things about it, but there was a clearly-defined problem to be solved and a process that produced a solution. Dave believes, I think, that, as it worked out, it was the wrong problem to be solving at the time and I'm at least sympathetic to that view, but that doesn't change the properties of fairly well-defined problem, fairly well-defined solution space, mechanisms that were fairly open at critical times (although, IMO, not nearly open enough at others). In that regard, I see the difference between, e.g., IPR and Poisson as being the difference between creating a WG with a very specific focus and problem to be solved and creating a more or less standing WG and telling them to look at Process issues, figure out what needs to be done, and do it. As we could all predict from our experience with technical/engineering WGs with narrow and well-understood scope versus those that are expected to figure out what the problem is before trying to solve it, IPR was productive while Poisson spent a lot of time in the weeds. In that context, part of what concerns me about the PESCI idea is that the is no clear problem definition. If there were a clear and concise problem definition on which there was obvious community consensus, I wouldn't worry much about the committee -- the problem definition would provide a good platform from which to evaluate success. If it were a spontaneously-occurring design team in which a few colleagues got together to sort out a problem and generate a proposal that would be treated as an individual submission with not more authority than any other such submission, I wouldn't worry about it: as Dave points out, some of our best work comes out of such teams. But this one appears to represent neither of those cases. But this is neither of those cases. Instead, either the problem area is open-ended or there are ideas that will steer it that Brian has not made public (I assume from his note that it is the first). The group isn't going to be spontaneous, it is going to be hand-picked by the IETF Chair and presided over by him and that will give it and its product a certain level of authority. There is also actually a difference between sufficient people who care to do the work and a sufficient number of experienced and relevant people in the community who care and are involved enough to be sure the work is right. That, to me, is the area of greatest difference between process WGs and engineering/ specification ones: with the latter, most of the people who get in there and do serious work are directly involved with the quality of the outcome (whether they do well or not is a separate matter). Process WGs
Re: IETF Process Evolution
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
Re: IETF Process Evolution
On Fri, 16 Sep 2005, IETF Chair wrote: This note describes a method of starting the next phase of IETF IETF process change, possibly including updating the change process itself. FWIW, I think this approach makes sense. In all process WGs (or BOFs) I have participated (ipr, newtrk, icar, mpowr, ...), it either took a horribly long time to achieve a result (and the result was typically just clarifications, not rocket science), or the results didn't materialize before the energy was lost. The only semi-concluded effort, ipr, was set out with very specific goals (don't make major changes, just clarify the current procedures. AND FOR THE LOVE OF GOD, don't touch RAND) so it yielded some results after quite a bit of time, but as said, it doesn't seem even close to comparable to this effort (clarifications vs major changes). However, I'm slightly concerned (as has been heard from others) as to the scope of the process work design team. I fear the task the DT would take upon itself would be too big (or the [perceived] expectations of the community too big) so that getting results would be very challenging if not impossible. For example, the bullet point below seems to imply, by the way, it would be nice if you could re-design the IETF process documents in a consistent manner. PESCI should concentrate on the high order bits, not these kind of clean-up activities. 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 -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Process Evolution
Thanks to John for his long and considered note. Two short responses inline before I have to sign off for the weekend: At 12:36 AM -0400 9/17/05, John C Klensin wrote: Ted, I finding myself agreeing with you in many ways, but probably for different reasons. I'm trying to better formulate the differences instead of (or at least before) posting something incoherent, but, in the meantime... --On Friday, 16 September, 2005 16:45 -0700 Ted Hardie [EMAIL PROTECTED] wrote: At 2:28 PM -0700 9/16/05, Dave Crocker wrote: And since all other public development efforts for process change have frankly fallen flat, as Brian has cited, what is your basis for believing that a working group charter will somehow make yet-another public process more effective at developing a specification for change? Possibly I'm wrong in this, but I believe that the public process works when the community cares about the outcome. The IASA work is done, and I believe it is a success because enough people cared about the outcome to make it one. I think there are two conditions. The first is caring and the second is a very narrow and specific focus, with serious thought and debate going into that focus. There were good things about the AdminRest-IASA process and bad things about it, but there was a clearly-defined problem to be solved and a process that produced a solution. Dave believes, I think, that, as it worked out, it was the wrong problem to be solving at the time and I'm at least sympathetic to that view, but that doesn't change the properties of fairly well-defined problem, fairly well-defined solution space, mechanisms that were fairly open at critical times (although, IMO, not nearly open enough at others). I agree with the properties of fairly well-defined problem, fairly well-defined solution space, but I see I missed making one of the crucial points about IASA. It did not use a working group process, but that did not eliminate the inherent problems in getting a large group of people onto the same page about change--it moved them into plenary, onto the IETF mailing list, and into the hands of the IAB and IESG to judge consensus. That it worked is a testament to efforts on the part of Leslie, Harald, the doc authors, and the community, but it was far from easy.There were also serious concerns throughout about the openness of the process, and I believe that only the personnel and contractual nature of some aspects of the negotiation justified the process in the eyes of some long-time IETFers. I don't think the same justifications for a non-WG process exist here, and until PESCI produces its output, we won't know if there are other justification. I appreciate Brian's effort to not rule out any specific onward process from PESCI, but I remain pretty concerned that the presumption seems to be it skips the usual mechanisms for public participation. My own experience is that the ad hoc replacements aren't easy, and they stress already overloaded aspects of the existing system. In that regard, I see the difference between, e.g., IPR and Poisson as being the difference between creating a WG with a very specific focus and problem to be solved and creating a more or less standing WG and telling them to look at Process issues, figure out what needs to be done, and do it. As we could all predict from our experience with technical/engineering WGs with narrow and well-understood scope versus those that are expected to figure out what the problem is before trying to solve it, IPR was productive while Poisson spent a lot of time in the weeds. In that context, part of what concerns me about the PESCI idea is that the is no clear problem definition. If there were a clear and concise problem definition on which there was obvious community consensus, I wouldn't worry much about the committee -- the problem definition would provide a good platform from which to evaluate success. If it were a spontaneously-occurring design team in which a few colleagues got together to sort out a problem and generate a proposal that would be treated as an individual submission with not more authority than any other such submission, I wouldn't worry about it: as Dave points out, some of our best work comes out of such teams. But this one appears to represent neither of those cases. But this is neither of those cases. Instead, either the problem area is open-ended or there are ideas that will steer it that Brian has not made public (I assume from his note that it is the first). The group isn't going to be spontaneous, it is going to be hand-picked by the IETF Chair and presided over by him and that will give it and its product a certain level of authority. There is also actually a difference between sufficient people who care to do the work and a sufficient number of experienced and relevant people in the community who care and are involved enough to be sure the work is right. That, to me, is the area of greatest
Re: IETF Process Evolution
I understand the concerns you express. What surprises me with the IETF is the lack of methodology (at least for a French brain). This seems to fit the model since it works: it then should be preserved, at least in part. This may also be one of the systemic root of the problem. Brian introduces the possibility of a one shot test in that area, a way to gain collective experience. So, I would suggest a phased approach. John says a clear and concise problem definition on which there was obvious community consensus would be great. To propose one cannot be carried by the whole community: it would be confused, eventually lead by usual people, already addressing the whole problem, new ideas we need would pile and could not be documented enough to gain momentum. On another end, I agree that defining the problem is half defining the solution. I would suggest the PECSI be missioned to come up with several possible basic problem definitions, consensually approved by their supporters (to make sure they are complete) through a Last Call. Then a community debate could be over a PECSI II Charter. That PECSI II would produce a revised IETF model to be commonly discussed. Then a PECSI III could produce a detailed road map to implement it. Such a road map would probably consistently describe the common document Brian calls for (a PECSI IV could write and maintain) and of all the updates to be carried by the appropriate areas and WGs? If that process was positive, it could then be tried in other IETF deliveries processes. If not, at every stage the common debate can decide to terminate it or to adapt it. But I feel that even aborted, each stage would already produce interesting and structured enough results. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Process Evolution
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
Re: IETF Process Evolution
From: Ted Hardie [EMAIL PROTECTED] 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. Hi, Ted, There are a lot of very helpful comments later in your note to Brian, which I snipped, but I wanted to respond to this paragraph. While it seems plausible that we could use the same mechanism for protocol design and for process evolution, my understanding of the Problem working group's efforts and the subsequent newtrk/icar/proto/mpowr (and yes, there were others) efforts is that this approach simply does not work. I used to believe that it could, and was honestly surprised when it didn't. I was wrong. It happens. I wrote my observations on why working groups don't work for process change in an early draft of what became RFC 3933. I agreed to remove the observations in order to publish the draft (the question was, do you want to publish the draft or argue about the observations?), but I still think Sections 1, 2 and 3 of http://bgp.potaroo.net/ietf/all-ids/draft-klensin-process-july14-01.txt were accurate when they were written, and I do not know why these observations would have been invalidated in the past two years. Whenever I refer to this version of the draft, I need to add this disclaimer: The reason this approach fails isn't anyone's fault - it's systemic. I continue to have the highest respect for the ADs who supported these efforts to improve things, and for the BOF chairs, WG chairs, and editors who tried to make improvements happen. But we've already been here. At the very least, I expect coming up with a tight charter to derail any discussion of evolution until IETF 65. That's what happened in newtrk and icar, when IETF participants went from discussing proposals to discussing a charter. Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Process Evolution
At 1:39 PM -0500 9/16/05, Spencer Dawkins wrote: While it seems plausible that we could use the same mechanism for protocol design and for process evolution, my understanding of the Problem working group's efforts and the subsequent newtrk/icar/proto/mpowr (and yes, there were others) efforts is that this approach simply does not work. Spencer, simply does not work is good rhetoric, but it doesn't fit all the facts. Groups like NomCom and IPR have taken on tasks and done them, with community discussion of their charters and with community discussion as their documents went through the process. They are process change groups, and they work. Let's say I put forward a charter like the following: WG Name: New Queues (NQ) Description of Working Group: The IETF has too many decisions passing through the same body, the IESG. The creation of the IASA and IAD has removed one set of tasks from that queue, but there are a considerable number of others which might be moved. In order to return the IESG to its historic task of managing working groups and their output, this working group will describe a process by which new decision making queues can come into being. While the process will be general, the working group will fully specify the creation of a process management decision making body. Among other targets for new queues: oversight of registered values in IANA registries; IETF responses to RFC-Editor queries related to RFC-Editor published documents; approval of experimental and informational documents that are not created by working groups. Goals and Milestones: 1st Draft of document describing general queue creation mechanism 1st Draft of document describing process management decision making body 2nd Draft of GQCM 2nd Draft of PMDM WGLC GQCM WGLC PMDM Publish QGCM Publish PMDM Re-charter to use GQCM for new queues, or close. Can the IETF community not discuss whether this is the output it wants and this is the direction of change it wants in terms of this charter? It may say no, but how to say yes or no to a charter is pretty clear, as is how to participate in the group or react to its output. Using an ad hoc mechanism to get from the existing process change mechanism to a new one would work well if we had strong consensus on where we want to go in process change, but that is the same condition in which working groups achieve success as well. If we do not have strong consensus on the desired process change, the ad hoc mechanism has far muddier mechanisms by which it is created, by which people participate, and by which its output may be challenged. The most obvious mechanism for the last is for someone to put forward an alternate proposal. If there are alternate proposals than those coming from the design team, how do you want to decide among them in the absence of a working group? Sure, we can invent all kinds of mechanisms to handle it that are equally ad hoc, but as I said in the Paris plenary, the hard but probably right answer is to use the existing mechanism one last time to replace it, then move on. That will require a lot of work from the Area Director, the WG Chair, and the community, but it is still the right answer. regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Process Evolution
Groups like NomCom and IPR have taken on tasks and done them, with community discussion of their charters and with community discussion as their documents went through the process. They are process change groups, and they work. Ted, Groups like nomcom and ipr have not had a multi-year crisis with a history of extensive activity and little measurable improvement to show for it. (How long ago was Yokohama?) So, Ted, how long should be allocated for this process to define a charter to define a working group that will define process changes? How long to get community acceptance for it? How long to get a resulting working group to produce something useful? And since all other public development efforts for process change have frankly fallen flat, as Brian has cited, what is your basis for believing that a working group charter will somehow make yet-another public process more effective at developing a specification for change? Design teams design solutions, not plans for solutions or charters for working groups. If the design team knows enough about its topic -- especially when the topic is complex and not all that well understood -- it is usually a far more effective vehicle for solution specification than is the working group framework. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Process Evolution
On Fri, 16 Sep 2005, Ted Hardie wrote: At 1:39 PM -0500 9/16/05, Spencer Dawkins wrote: While it seems plausible that we could use the same mechanism for protocol design and for process evolution, my understanding of the Problem working group's efforts and the subsequent newtrk/icar/proto/mpowr (and yes, there were others) efforts is that this approach simply does not work. Spencer, simply does not work is good rhetoric, but it doesn't fit all the facts. Groups like NomCom and IPR have taken on tasks and done them, with community discussion of their charters and with community discussion as their documents went through the process. They are process change groups, and they work. From my perspective I would have to say that the preponderance of the evidence supports Spencer's position. My reaction to your initial response to Brian's message proposing yet another WG was oh, and it will be as successful as newtrk. Of course I could have added icar or sirs or the others that Spencer mentioned. And it's funny that you metion IPR as a success ... it seems to me that a lot of energy was spent to get very little, and in may ways it was a step backward (e.g., non-IETF folks now have to go to document authors to get permission to use a MIB etract or program fragment). For sure, the IPR effort has resulted in a delay of at least 18 months (with the clock still ticking) in getting the MIB review guidelines doc published (and I suspect, but cannot prove, that it is largely responsible for the long delay in getting rfc2223bis published). Even granting that nomcom has been a success -- I don't know the evidence in that case one way or another -- I'd have to say that the overall record for process change WGs has been very poor. In any case I would like to go on record as strongly supporting Brian's initiative. Given the lack of progress in newtrk and the like I think it's the only hope of moving forward. Mike Heard ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Process Evolution
At 2:28 PM -0700 9/16/05, Dave Crocker wrote: And since all other public development efforts for process change have frankly fallen flat, as Brian has cited, what is your basis for believing that a working group charter will somehow make yet-another public process more effective at developing a specification for change? Possibly I'm wrong in this, but I believe that the public process works when the community cares about the outcome. The IASA work is done, and I believe it is a success because enough people cared about the outcome to make it one. As you noted a few days ago: Successful IETF work begins by developing support to do the development work and support to use the output of that work. The work is then done for development and deployment. The procedural simplicity and practical utility of this model tend to be vastly under-appreciated. I believe the community will care enough about this to get it to work, and I hope I'm right, as it will be a requirement whatever process we use to get to a new change process. As I said at the beginning of this thread, I believe using PESCI to scope the work and develop support for is fine. I'm deeply concerned, however, about it doing the development work itself, as a process in which selected volunteers replace the public work of those who will use the outcome. regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Process Evolution
Two observations: 1) Having been an active participant in the Nomcom working group, it is amaxing it actually worked. The process took an absurdly long time to converge on a very small set of changes. Having tried to drive ICAR, which many people said was important, I again conclude that WGs are just the wrong tool for this. 2) If we were at the point that we knew that the changes below were what we wanted, that might be reasonable. But at the moment we have a polarized community who collectively want multiple incompatible things. And they want them all now. A working group will not resolve such a situation. Yours, Joel PS: I don't know if Brian's proposal is the right answer. But it is sure a heck of a lot better than chartering anotehr working group. At 03:22 PM 9/16/2005, Ted Hardie wrote: At 1:39 PM -0500 9/16/05, Spencer Dawkins wrote: While it seems plausible that we could use the same mechanism for protocol design and for process evolution, my understanding of the Problem working group's efforts and the subsequent newtrk/icar/proto/mpowr (and yes, there were others) efforts is that this approach simply does not work. Spencer, simply does not work is good rhetoric, but it doesn't fit all the facts. Groups like NomCom and IPR have taken on tasks and done them, with community discussion of their charters and with community discussion as their documents went through the process. They are process change groups, and they work. Let's say I put forward a charter like the following: WG Name: New Queues (NQ) Description of Working Group: The IETF has too many decisions passing through the same body, the IESG. The creation of the IASA and IAD has removed one set of tasks from that queue, but there are a considerable number of others which might be moved. In order to return the IESG to its historic task of managing working groups and their output, this working group will describe a process by which new decision making queues can come into being. While the process will be general, the working group will fully specify the creation of a process management decision making body. Among other targets for new queues: oversight of registered values in IANA registries; IETF responses to RFC-Editor queries related to RFC-Editor published documents; approval of experimental and informational documents that are not created by working groups. Goals and Milestones: 1st Draft of document describing general queue creation mechanism 1st Draft of document describing process management decision making body 2nd Draft of GQCM 2nd Draft of PMDM WGLC GQCM WGLC PMDM Publish QGCM Publish PMDM Re-charter to use GQCM for new queues, or close. Can the IETF community not discuss whether this is the output it wants and this is the direction of change it wants in terms of this charter? It may say no, but how to say yes or no to a charter is pretty clear, as is how to participate in the group or react to its output. Using an ad hoc mechanism to get from the existing process change mechanism to a new one would work well if we had strong consensus on where we want to go in process change, but that is the same condition in which working groups achieve success as well. If we do not have strong consensus on the desired process change, the ad hoc mechanism has far muddier mechanisms by which it is created, by which people participate, and by which its output may be challenged. The most obvious mechanism for the last is for someone to put forward an alternate proposal. If there are alternate proposals than those coming from the design team, how do you want to decide among them in the absence of a working group? Sure, we can invent all kinds of mechanisms to handle it that are equally ad hoc, but as I said in the Paris plenary, the hard but probably right answer is to use the existing mechanism one last time to replace it, then move on. That will require a lot of work from the Area Director, the WG Chair, and the community, but it is still the right answer. regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Process Evolution
Dear Ted, As I said at the beginning of this thread, I believe using PESCI to scope the work and develop support for is fine. I'm deeply concerned, however, about it doing the development work itself, as a process in which selected volunteers replace the public work of those who will use the outcome. I understand this concern. If I am parsing correctly, you and I are closer than I thought after seeing your first note. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Process Evolution
Ted, I finding myself agreeing with you in many ways, but probably for different reasons. I'm trying to better formulate the differences instead of (or at least before) posting something incoherent, but, in the meantime... --On Friday, 16 September, 2005 16:45 -0700 Ted Hardie [EMAIL PROTECTED] wrote: At 2:28 PM -0700 9/16/05, Dave Crocker wrote: And since all other public development efforts for process change have frankly fallen flat, as Brian has cited, what is your basis for believing that a working group charter will somehow make yet-another public process more effective at developing a specification for change? Possibly I'm wrong in this, but I believe that the public process works when the community cares about the outcome. The IASA work is done, and I believe it is a success because enough people cared about the outcome to make it one. I think there are two conditions. The first is caring and the second is a very narrow and specific focus, with serious thought and debate going into that focus. There were good things about the AdminRest-IASA process and bad things about it, but there was a clearly-defined problem to be solved and a process that produced a solution. Dave believes, I think, that, as it worked out, it was the wrong problem to be solving at the time and I'm at least sympathetic to that view, but that doesn't change the properties of fairly well-defined problem, fairly well-defined solution space, mechanisms that were fairly open at critical times (although, IMO, not nearly open enough at others). In that regard, I see the difference between, e.g., IPR and Poisson as being the difference between creating a WG with a very specific focus and problem to be solved and creating a more or less standing WG and telling them to look at Process issues, figure out what needs to be done, and do it. As we could all predict from our experience with technical/engineering WGs with narrow and well-understood scope versus those that are expected to figure out what the problem is before trying to solve it, IPR was productive while Poisson spent a lot of time in the weeds. In that context, part of what concerns me about the PESCI idea is that the is no clear problem definition. If there were a clear and concise problem definition on which there was obvious community consensus, I wouldn't worry much about the committee -- the problem definition would provide a good platform from which to evaluate success. If it were a spontaneously-occurring design team in which a few colleagues got together to sort out a problem and generate a proposal that would be treated as an individual submission with not more authority than any other such submission, I wouldn't worry about it: as Dave points out, some of our best work comes out of such teams. But this one appears to represent neither of those cases. But this is neither of those cases. Instead, either the problem area is open-ended or there are ideas that will steer it that Brian has not made public (I assume from his note that it is the first). The group isn't going to be spontaneous, it is going to be hand-picked by the IETF Chair and presided over by him and that will give it and its product a certain level of authority. There is also actually a difference between sufficient people who care to do the work and a sufficient number of experienced and relevant people in the community who care and are involved enough to be sure the work is right. That, to me, is the area of greatest difference between process WGs and engineering/ specification ones: with the latter, most of the people who get in there and do serious work are directly involved with the quality of the outcome (whether they do well or not is a separate matter). Process WGs tend to draw a disproportionate number of people who are interested in and care about process but who are not otherwise significantly contributing to the IETF's technical work. So... As I said at the beginning of this thread, I believe using PESCI to scope the work and develop support for is fine. I'm even concerned about that for the reasons above. Agenda-setting is an important part of the process and the historical observations about the importance of being the party who picks the battlefield or moves first are relevant. If the group were to be chosen via a more open process, including some advice and consent by, e.g., the IESG or IAB or Nomcom, than Brian apparently contemplates, I'd feel better about it. But... I'm deeply concerned, however, about it doing the development work itself, as a process in which selected volunteers replace the public work of those who will use the outcome. While we agree, I think, about the risks of the selected volunteers part, I'm not sure whether we agree or not on the rest of the sentence. If, by public work of those who will use the outcome you intend to suggest a process that is controlled by the IESG, I don't think that works either. The
