Is this really where we want to go? (was: Re: Selecting leadership, take 2)

[Leslie Daigle]

John,

Let me declare myself as an original proponent of the problem-statement
concept, and give my perspective.

Personally, my own belief in the need to focus on the problem
statement side of things dates back to mid-October, when it was clear
that there was a lot of angst in the IETF and not a lot of direction for
sorting it out.   In my estimation, it would be very easy to
wind up with a considerable number of proposals of things to
change (solutions) -- and then very hard to achieve consensus
behind which one or ones to implement, if we as a community don't
have a shared idea of what we are trying to achieve (what problems
we are trying to solve).

If we "just" start discussing proposed solutions, there is the
very real danger that we will rathole on discussions how to
arrange the deck chairs.

If we don't get an agreement of the fundamental nature
of what we are (or are not) trying to achieve, then we truly
can only make rather incremental changes, because we'll never
get consensus on gathering the energy to implement anything
more involved.

Now, I'm not saying that I think we will have to do major
surgery.  But there was enough energy in the IESG plenary in
Yokohama to convince me, anyway, that people have some pretty
serious concerns, and we need to at least seriously consider
major change before we decide to make only incremental ones.

And I'm {insert appropriate adjective here :-) } enough to
believe in the IETF community being able to undertake that serious
consideration.

Around the time of the Atlanta IETF, I posted a note to this list
trying to describe what I think a problem is -- excerpted below.
The key point is:  drill down on an issue until you're sure you
understand the fundamental problem, and aren't dealing with
something that is "only" a symptom of some other larger issue.
(Is the IETF doing a Titanic?  If so, does that deck chair
  arrangement *really* matter?).

Additional perspectives:  as Randy Bush said, it's hard to
have a single focused discussion of solutions when you have
more than one problem that is driving the discussion; how
can you tease them apart and evaluate interplay?  And
Margaret Wasserman pointed out that there isn't even a shared
agreement on what *success* is.  Without that, how indeed
can we get consensus on which way to go next, except by
having flame-wars & p'ing contests?

Enough theory, let's look concretely at how this thread evolved
on the mailing list:

	. Someone suggested that a problem was:  not enough
	  face time discussions.  You proposed changing the
	  IETF meeting schedule structure -- noting that
	  there would be effects to mitigate (e.g., to retain
	  cross-fertilization, etc), and *enforcing* interim
	  meetings of working groups.

	  How about:  (re)empowering WG chairs, and reminding
	  them that they have design teams and interim meetings
	  as potential tools they can use to achieve the WG's
	  work items?

	  As solutions, these are apples & oranges.  How to compare?
	  Which to choose?  DEPENDS...  and we'd better figure out
	  "on what".  (I think it depends on what problem you
	  are actually trying to solve -- face time, or work item
	  closure, but I digress...).

	. Someone suggested that a problem was:  milestones that
	  don't really count.  That's an age-old issue, and it
	  got the standard "yes, isn't it amazing how we miss
	  our milestones regularly", and "other SDOs don't",
	  then "silence" reaction.  If timeliness is really, really
	  a problem, shouldn't we get consensus that is high on
	  our priority list, so we can break through and SOLVE
	  it? Or, if it's not, let's stop talking about it.


	. The discussion of the proposed solution "longer meetings
	  or more interim ones" spawned 2 separate threads on
	  the issue of costs of participation (travel costs) and
	  on the issue of whether vendors are in fact the most
	  important participants in the IETF.  I.e., possibly
	  2 other issues, ppossibly 2 ratholes, but definitely
	  not (IMO) the right criteria by which to decide whether
	  or not to make fundamental changes to the IETF's meeting
	  structure, which was the proposal at hand.


So, to your specific points about the shortcomings of working
groups in the IETF, and the unsuitability of a problem-statement
working group:

John C Klensin wrote:
>     * We have discovered that Working Groups are rarely a
>     good way to get from <interesting-buzzword> to a serious
>     set of definitions and requirements.  Working groups
>     charged with coming up with requirements in ill-defined
>     areas often go on rathole tours and even more often take
>     much longer than anyone expects to produce anything.
>     And the results are rarely suitable for real evaluation
>     and examination, as evidenced by the number of
>     subsequent "protocol" WGs who end up ignoring or
>     rejecting a significant fraction of the "requirements".

Yep.  But see my last bullet above -- discussing "solutions"
is at least as prone to sight-seeing, and ultimately, flamage.
No matter what we do here, it is going to require *discipline*.
This has to be a successful effort, whether it is a WG, a mailing
list, or a paper plane flying contest.

>     * We have discovered that Working Groups are rarely good
>     at doing real "blank sheet" design.  Either some design
>     shows up from outside the WG and the WG endorses it,
>     perhaps with some tuning, or the WG ends up going around
>     in circles until it either produces garbage (which gets
>     approved because everyone but a few advocates are
>     exhausted and no one has the heart to say "no" because
>     so much time and energy has been invested.

True -- but this is an argument that there should be a design
team with a short list of potential problem-statements,
brought to a WG destined to reach consensus on it.  It's not
an argument to not have a problem-statement WG.

>     * And we have discovered that we don't do "thinking
>     about process" WGs very well.  Given a clear problem and
>     a forced schedule, such as was the case with the
>     original Poised group, we can often figure out something
>     decent.  But, with a looser schedule and a vague problem
>     definition, we wallow, nit-pick, practice becoming
>     amateur lawyers, and spend huge amounts of time on
>     things that are unlikely to make very much difference.
>     And we often spend even more time looking at cases that
>     haven't occurred and are unlikely to do so.  The more we
>     wander in those weeds, the more we devise "solutions"
>     that aren't testable -- we may have code, but we don't
>     have a clue as to whether or not it actually runs.  The
>     last couple of years of Poisson were a fairly good
>     example, but we have many more specific ones.

I would use this as an argument to not have a solutions-based
approach.  We need the problem-definition.  And I believe (although
I seem to be in the minority) that we need to get IETF-wide buy
in on a large portion of that problem statement, because whatever
choices are made, it is the IETF community that is going to implement
it.

Perhaps that sentiment is motivated by one thing that I believe
is a problem:  disaffectation of the IETF community.  People feel
(and act) very un-involved, as compared even with when I started
participating in the IETF.

For those who've made it this far (in what, for me, is an
astonishingly long message -- my sincere apologies for not
being able to make it shorter), take everything I have just
said and consider:

[You suggested it would be valuable to collect input in the form:]
 >
>     * X appears to me/us to be a problem
>     
>     * Because of X, the following bad things happen: A, B,
>     C,...
>     
>     * One could do Y, which would change or modify X so that
>     those things would not happen

It is possible that proposed solutions could be included in the
discussion -- if, and ONLY if, they did not become the focus
of discussion.  It is my personal concern that could not be
managed, so I suggested problems-only discussion.  That was
a solution-proposal on my part ;-)


Leslie.

[Excerpt from my message on "what is a problem" of November 13,
  2002]
 >
> I think we need to spend some more time figuring out what is
> "a problem" and what is "a symptom that is really bothersome."
> 
> I would argue that the IESG not having a charter is not the
> problem [0].  The IESG not being transparent is not the problem.
> A simple test:  if a charter popped into existence, and
> transparency were instantly achieved, would everything be
> wonderful?  No -- we (for the value of "we" looking for
> these things) would feel better equipped to... solve our
> problems.  So, what are *those* problems?
[snip]
> [0] Note that I am not saying: I don't believe an IESG
> charter should exist.  I'm saying it's not what we need
> to discuss first.  What is agitating people that causes
> them to say "we need an IESG charter"? 



-- 

-------------------------------------------------------------------
"An essential element of a successful journey
    is recognizing when you have arrived."
       -- ThinkingCat (c.1983 - 2002)

Leslie Daigle
leslie@thinkingcat.com
-------------------------------------------------------------------