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.