Last Modified: 2005-10-17
Minutes of PESCI BOF 2005-11-09 =============================== Notes taken by Rob Austein Intro by Brian: - Brian Carpenter is BOF chair - Sam Hartman and Bert Wijnen acting as GEN ADs for this BOF - See agenda slide "PESCI BOF 2005-11-09" - See "Introduction" slide - Baseline assumption is that any proposed outcomes must be subject to open debate in the community and rough consensus -- no process bypass. === Presentation by Elwyn Davies on behalf of PESCI initial design team "Goals and Principles for Process Change" [See Elwyn's slides -- Elwyn's presentation stuck very closely to his slides, so the following notes are on the few places where Elwyn's comments diverged slightly from his text] Slide "The actuality": - We're not discussing the part that should be changed today Slide "Process change goals - 1*" - Bullet items start from #2 because #1 was draft internal goal. - Want to concentrate on bits that don't work, not destroy pieces that do work. Slide "Process change goals - 2" - No total revolution - We don't have infinite resources Slide: Principles for the change process - 1 - A lot of discussion saying we must be open; team agrees. Slide "Principles for the change process - 2" - 4: Make sure WG chairs believe in what we're doing. - Technically, ISOC board has to approve of what we do, except that "approve" is not really the right word -- they "accept" that this is our description of our process. Slide "Principles for the change process - 3" - 6: Don't just want to update the ad hoc set of documents we have at the moment. Slide "Time for discussion" - And the question is: are these good goals and principles for the change process itself? - We want to avoid ratholes. [End of presentation] === 20-25 minutes of discussion, according to agenda. Ted Hardie: I understand that this is difficult task, and have a great deal of personal respect for the PESCI team. That said: the document is full of worst kind of empty headed management goop. No useful help to people trying to manage. We want stability of a process that destroys anybody we put into an IESG job? We have a very simple problem: we push everything through a single queue. This does not work. We need a mechanism to create different queues. Create discussion on goal and principle: things get faster, things don't cost as much. Could skip this whole thing: we need a group that creates a group that can manage and staff a change control group. Rest of this is goop. Such valuable people, such goop. Brian Carpenter: You feel strongly about this, Ted? Scott Bradner: Wouldn't phrase it quite like that, but not far from what I think. I'll reserve comments on process to do a process. Question about something that might have been a slip of the tongue: you said we need to be sure that we discuss this with the IESG. Does that "we" mean people currently in your role or whomever ends up in the role? Brian Carpenter: Am not assuming that it's the current people. Scott Bradner: OK, I'll talk about document itself. No principles there, just implementation details. Seeing some of the same thing here too. Don't see enough of higher level concepts here, just details. Battles all this week about being in the nits. We're not good enough at looking at things at higher level. Brian Carpenter: Hear you, but remember that this is a -00 draft. Aaron Falk: Principle was to focus on what's broken, but #6 says let's do a new document set. Scary. Huge amount of effort, disruptive, divisive, no assurance will accomplish ultimate goal. Brian Carpenter: I recently wrote a document attempting to catalogue all the process documents I could find. Found lots of them: we've accreted a lot over the last n years. Focusing on point #6 would take us off into the weeds, but 17 documents all amending RFC 2026 would also be pretty confusing. Aaron Falk: So look for consensus that complexity of those documents is the problem. Brian Carpenter: It's not -the- problem, but is -a- problem for new participants. Margaret Wasserman: I might have said it differently, but I agree with Ted. Lot of drivel in the doc, not a lot of specific principles that we could apply to process change. I don't believe that we can determine what we need to do by process change from first principles, it's the wrong end of the problem. I understand the tendency to say that the IESG shouldn't have to do it themselves. The IESG shouldn't have to do -anything- in this organization, can delegate almost anything. But if you want something to work, the people who are supposed to make the process work have to be involved in its design, or they will just complain about how broken it is. Let's not set up a "process group", that's the kiss of death. Sam Hartman: [AD hat on] Please scope comments narrowly to principles rather than to the document. Thomas Narten: Regarding point #6 on principles: a new doc set is worthy goal, but it's largely orthogonal to what we need to do here, so it's a distraction. Let's not add distractions. Brian Carpenter: Point #6 was somewhat contentious within the team. Thomas Narten: You didn't list a lot of principles, so it looks like you think #6 is important. John Klensin: I'm impressed by the comments so far, but want to amplify something Thomas just said. The amount of this kind of work we're doing is sucking energy out of the community that should be going into protocol work. It seems to be costing us senior people going away and junior people not signing on. Don't know how to interpret interpret some of the comments I'm hearing. Does each of these processes leverage IETF enough forward to be worth it? Bert Wijnen: I agree that it sucks away from technical work. John says this does too. But focus of this BOF is preventing having all these proposed process changes sucking up energy. We're trying to get the PESCI team going so it can do the process junk instead of sucking it out of the whole IETF. Brian Carpenter: I agree with Bert's statement. If nothing needs changing, we won't change anything. Leslie Daigle: When we've had difficult technical discussions in other groups we've tended to rathole, and gotten nowhere... Somebody needs to come up with a proposal, not just random proposal, but a good one. There are people here who understand our processes and what to do; not all of these necessarily people chosen by the chair. We don't need process, we need a document. Elwyn Davies (as individual): We don't need to think about how we do the change process. We need to find a bright spark of genius. Some discussion about role of IESG: we're assuming that IESG will remain largely unchanged, what if IESG's role changes here? Going to make it difficult for IESG to do the changes. Harald Alvestrand: A few years back, we had a doc which initiated this: draft-huston-ietf-pact-00.txt. It contained specific proposals that would have changed the IESG, and none of them would have helped. I agree with finding bright spark and nurturing it, but remember that 90% of everything is bunk, even in organizations. Margaret Wasserman: One issue here is, do we just need a document with a really good idea, and where do we start? If we form a group or committee, those people will try to do process change, will generate a certain amount of work that the community has to deal with, which creates a problem. Process groups want attention from community. On the other hand, we need to figure out a way to fix some of these problems, so we need to spend some attention on them. Don't understand where to start, should be starting with specific problems, not principles. Brian Carpenter: We tried to avoid solutionism; we were trying to figure out how process change should occur. You're suggesting that that was the wrong approach. Bert Wijnen (as individual): I share Margaret's concern if you create a team charged with process change, that's risky, and that's what we were talking about here, so if we're going to do that we need some principles in place to guide the team. I thought that's what this BOF was about. Brian Carpenter: Yep. Brian Carpenter: Comments on "goop". I have to agree, the draft is not lean and mean thing I had in mind. It's harder to write something in one page than in ten. Truisms and drivel and goop, I'll admit it, as will Elwyn. Elwyn Davies: Yes. It's a -00 draft, written in great hurry. Brian Carpenter: Seriously, send text if you think it has too much drivel and goop. Margaret Wasserman: there are a lot of people here, for an hour. Next time, let's finish drafts before we spend an hour of 80 people's time. Brian Carpenter: Felt we needed to show progress. Ted Hardie: With respect, this is marching in wrong direction. Don't want to send you text. This is just not the right starting point. If you accept that we're in a WG situation and different design teams can submit competing proposals, ok, I'll write something, but is this a WG? Margaret Wasserman: I don't know that anyone has made compelling case for why we need a new process change process. I understand concern about IESG bandwidth. But IESG bandwidth has not been problem with approving process changes community has come up with. Problem is that community can't get consensus on process changes we need to make. Need to use existing mechanisms to reach consensus on what to change, and we don't get to change anything if we don't get consensus. Michael Richardson: I kept asking that question, how many levels of meta are we at now? Process for process for process for... I think we're trying to build a team that is capable of figuring out what the consensus of the community is. This team is supposed to figure out what the place is to start. This team is supposed to figure out whether we've agreed on final answer. This doc is trying to design the team. [analogy about building a router...] Margaret Wassserman: I thought we were forming a team to write a document. I'm more scared now. I don't think there is consensus out there on the perfect process, just waiting to be extracted. If this team is going to write process proposals and then decide whether the IETF has consensus on them, that's just kooky. === Brian Carpenter: [Next steps slide] 1. We need a better quality version of this document. Document currently covers a lot more than it should. 2. We need to seek widespread consensus on "Principles for change process" (only). This is where we may go off the rails given the discussion today. 3. Commissioning a team to propose process seems to be where Margaret is saying "What?!?" Note that three of the bullets in this slide have nobody assigned to them. === Brian Carpenter: I get the impression that people are not particularly happy with this approach, but let's hear from the room. Thomas Narten: Yeah, I'm not happy with what I see here. Among other things, it'll take six to N months until we get to point of trying to fix anything. The IETF, in general, is a lot better at fixing a problem when it's clear what the IETF is trying to fix. I don't agree with the basic premise that we need a different process because current one is failing. Sam Hartman: Take a hum on whether we need new process, might cut this discussion short. Brian Carpenter: Ok, but let Thomas finish. Thomas Narten: Question to community: looking back at all the proposals that have been made for process change, point to one, or two, or three for which there is consensus but which couldn't make it through because the process failed. Did process fail, or were there other reasons why these proposals failed? Spencer Dawkins: We've talked a lot about do we need a new process. Recent experience in general area is that if you tell a WG to change almost nothing, you get something out, otherwise you don't. The IPR and NOMCOM WGs concluded, others didn't. Barbara Fraser: I get uncomfortable when I see "the change process". We have more than one change process. We need to get more work done more quickly. But the laundry list goes into lots of other stuff (appeals, ...). This is trying to get our arms around something larger than most critical problem. Just the most critical problem might be easier. Brian Carpenter: Now the hum. Trying to ask question properly. "Do people think that we do actually need a new process for process change?" In other words, is the target of item three a valid target? Adrian Farrel: I disagree; I want to qualify "What do we mean by process?" Any idea that fails is a process failure. Margaret Wasserman: I disagree [scribe infers that Margaret disagrees with Adrian]. Some ideas fail to get consensus, that -is- our process. === Brian Carpenter: Calling question: "Do people think that we do actually need a new process for process change?" - Yes (do think we need change): 13? 15? 20? hands. Ok, counting hands this time. 14.5, 15, 16. - No (do not think we need change): same number plus or minus two. This is not even rough consensus. 7 minutes left. === Scott Brim: That was the whole point: how can we decide if we need a process to change our process.... We need a metric. Isn't that what we're doing now? Spencer Dawkins: I'm asking Ted: We do have a process for process experiments, that's a BCP now. You (Ted) were in favor of starting to fix things, is that BCP a useful tool? Ted Hardie: There's a lot more to it in this case than the usual case. Brian Carpenter: And we haven't used that BCP very often. Harald Alvestrand: I'd like to ask the chair to ask a different question: whether or not we need to make serious changes to process. Brian Carpenter: Define "serious". Harald Alvestrand: Some changes are obviously serious, eg, moving document approval or WG creation to a different body. But requiring two discuss votes instead of one is not a serious change. Margaret Wasserman: "Fundamental change". Harald Alvestrand: I want to verify my impression that there's an IETF consensus that we need it [scribe infers that "it" means "a process change process"]. Brian Carpenter: I agree. === Brian Carpenter: Question: "Do we need one or more serious process changes?" - Yes (we do): about 20 hands - No (we don't): 3 or 4 hands Sam Hartman: Can anyone agree on what that serious change is? Room, almost in unison, laughing: NO! Sam Hartman: Right. But "should we" is not as useful as getting direction on particular direction === Lucy Lynch: We need working implementations of process changes. Lots of work done, few experiments. Need more volunteers to get more working implementations of process changes. Joel Halpern: I've observed extreme polarization during the time we've been doing this. Some people just want to get their work done, they're not in this room. People who show up here tend towards extremes on any question anyone can ask. We need a different process because with us this polarized, sticking to status quo doesn't work either. Pete Resnick: Pretty much what I was going to say. We have pretty wide consensus that something has to change, will never agree on what it is. Existing process won't work, need new process and need to change something. Leslie Daigle: I didn't raise my hand either way because the IETF needs to undertake major change but not it's clear what the change should be. I don't sign blank contracts. Put proposal on table. What we were asked was a blank check. Get over that first. Brian Carpenter: Should I plan to hold a GEN area meeting at next IETF? Sam Hartman: No. Hold plenary on process change. It will be awful, but is the only way it will get the work done. Brian Carpenter: Quite an informative meeting. I don't detect consensus for steps 1-5 on screen. But quite educational. I still think PESCI team should clean up the document, we know there are serious things wrong with it. I am going to have to do serious thinking about where we go with this. I'm tempted to say tell me (Brian, not the IETF list) what changes we need. Barbara Fraiser: Would it be reasonable to put out call for ideas? General IETF community could come forth with their ideas on what's needed in a particular area? Really large space, people are focusing and have personal pain points in different areas. Brian Carpenter: Yes, but that's a risky operation. Barbara Fraser: Otherwise you risk bringing on wrath of IETF as skunkworks project. Brian Carpenter: Yes, but a call for proposals...get a lot of email. Dave Crocker: There was a reference to at least one proposal submitted earlier. No shortage of proposals for specific changes. Problem is how proposals have been received. Any interesting proposal gets shot down. Pekka Savola: We tried a call for proposals before NEWTRK, didn't work well. I support what Dave Crocker said. Need somebody to shepherd these things forward. That probably calls for new process, although it may be possible some other way. Thomas Narten: I don't think we want another call for proposals. But would be useful to review proposals that have been submitted in past, figure out why they didn't fly, are there useful nuggets, what were the process issues that prevented those from going forward. Where do we go from here? Brian Carpenter: that would require some analysis of recent history. I'll do some thinking and consult with Bert and Sam. The BOF is over. Thank You.