Subject: [Pesci-discuss] Principles for the process vs Principles for Process Change

From: Sam Hartman <[email-masked]>
Date: Thu, 13 Oct 2005 08:17:57 -0400

Hi.  As sponsoring ADs for the BOF, Bert and I are concerned that the
principles discussion is drifting into an area that will get us
sidetracked, take up a lot of time, fail to get consensus and will
prevent us from getting the community feedback we need on the pesci
direction.

Based on the minutes, which is all we have seen, it sounds like a lot
of the principles being discussed are principles the team would like
to see in the final IETF process.  We think that what we need now is
principles for the process change process.  In addition to being hard
to agree to and taking up significant time, I'm concerned that long
discussions of principles for the resulting process will  encourage
revolutionary rather than evolutionary change.  

I talked to Brian about this.  he said you have been discussing the
issue internally and find it very challenging to separate process
change principles from process principles.  Can you help me understand
why that's hard so I can figure out what we want to do to focus the
BOF?

I tried a bit of brainstorming to figure out why it might be hard to
come up with process change principles.  Sometimes you find why
something is hard when you try to do it.  At least for me, I found it
fairly easy to brainstorm process change principles.  I think the
principles I came up with are fairly clearly process change not
process.  Perhaps the complexity comes at a later stage of the
process: evaluating, evaluating for completeness or something like
that.  Your help is greatly appreciated.  I did find that while I had
principles in my head, I was not able to crisply state these
principles.  I've never been good at that and I also ran into troubles
that while I think the principles are obvious, crisp statements would
imply decisions I should not be making as an AD for a BOF.

Alternatively, perhaps there is a problem of understanding.  Let me
give some examples of what I think are fairly obvious process change
principles.  I think these are reasonably well accepted and so I'm not
stepping outside of the AD role by suggesting them.

* This process change process is designed to support evolutionary
  change to the process not revolution.  There may be a need for
  revolution; there has been in the past.  However we are not
  designing that process today.  (This comes from the title of the
  effort; I understand some people believe that revolution is
  necessary, but presumably that's out of scope for the design team's
  thinking.)

* We need to say something about the interaction of process change and
   tools development/deployment.  The IESG has found that process
   changes can have fairly high costs if not accompanied by
   appropriate tool changes.  As an example, many parts of the proto
   process are very manual.  In that instance I think we all agree
   that the net result is positive.  In another example, the IESG
   adopted a procedure for mandating normative downreferences to
   documents be mentioned in last calls.  The IESG didn't have tools
   to notice these references, so it largely ignored the procedure it
   had adopted.  Bill wrote such a tool, but we do not yet have an
   infrastructure around this tool or a list of documents for which
   these references are not required.  Now, we're trying to apply the
   procedure, noticing things fairly late, delaying documents and
   generally not happy with the current state of things.  However as
   Harald and others have pointed out, with the right tools, this
   process would be fine and would not be a bad idea.  The general
   principle is that we need to consider the impact on tools in
   developing process.  

* The process change process is community focused in that there is a
 mechanism for the community to propose process change and that the
 process change process ultimately must build a community consensus
 around the process.  (It may be community focused in other ways as well.)

* Something about the strong community consensus has the power to
  effect process change.  Brian put this well on the ietf list and I
  think in plenary slides.  But see below: that may involve changing
  those tasked with implementing the process if they cannot buy into
  the new process.

* We need to get input from those affected by process change and make
  sure we understand how process change would  affect them.  (Wiggle
  words as appropriate; we cannot understand everything up front.)

* Process change is only effective if you have buy-in from those
  implementing the process change.  At some level, you need to either
  make sure people can implement the process (preferably willingly),
  drop the process change proposal, or find a new set of people who
  will implement the process.  I'm not sure how exactly you want to
  state this, but there is a principle about the process change
  process in here.    

* The process change process should support experiments.  You need a
  way to make changes that you might later decide are bad ideas
  and to evaluate the success of changes.

And here are some principles that I suggest as examples of things that
may or may not be good ideas.  I can think of arguments for and
against these and would be happy to give the arguments for both sides
if asked.  I want to make it clear that I'm not expressing an opinion
for or against the inclusion of these proposed principles.

* There should be a set of principles agreed to by the community
  against which process change proposals can be evaluated.  In effect,
  we should have a community consensus on where we're going.  I can
  think of models where this is part of things and I can also think of
  at least one model where this is unnecessary.

* The process change process should minimize the number of process
  documents.

--Sam

_______________________________________________
Pesci-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pesci-discuss

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Oct 2005 11:33:14 +0200

Sam,

My reaction is that this is excellent input and germane
to the discussion and to the impending draft (which really
is impending; we have no intention to be secretive but the draft
was only started 3 weeks ago). So I think I'll delay responding
in detail until the draft is available, within the next 4 days.

As I said to you privately, it proves hard to write down principles
for change in a vacuum, but our desire is absolutely to focus
on principles for change. To the extent that we've failed, the draft
will need more work.

     Brian

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 14 Oct 2005 14:44:11 +0200

At 11:33 14/10/2005, Brian E Carpenter wrote:
>on principles for change.

Brian,
not exactly a vacuum. Your own RFC 1958 basic principle seems to give 
a good historic ground.

Changes are to match problems and opportunities. It would be non 
committing change to add to the process a serious way to know and 
quantify reality. Also, the Internet has acquired enough importance 
in the current society to create and support changes in the world 
reality. There is therefore a need to qualify changes against 
something external to its own loop: a politic ethic. The case of RFC 
3066 bis is of interest. IESG refused to consider the change and 
sided in a main politic/commercial camp. It is likely it will hit 
back: may be a good occasion for experience.

The Internet standard process and the IETF culture is incredibly 
affected in its own past because its deliverables never change (once 
an RFC always an RFC). This drags down innovation and I am not sure 
it preserves retro-compatibility. But it preserves status quo to the 
benefit of stakeholders. The digital divide starts to be political 
and soon architectural (balkanisation). Now, let consider a IETF 
context where RFCs would be Internet Book updates (what the users are 
used to and expect). The change in the culture would probably be 
important. Including about progressive non-committing changes too 
(what you look for) in process and in architecture.

The impact of changes in architecture goes with and induces changes 
in process. There are many parallel concepts, option and processes. 
How many RFC are effective? May be 2000? Who can even read 2000 RFCs 
and actually more as deprecated RFC are still documented in further 
documents and debates? Let imagine the architecture would change and 
accept parallel links (at lowest level), i.e. multi-internet instead 
of mono-for-ever-internet. Many processes/concepts would be seen 
differently. The corresponding architectural culture would 
contributed to the general process. Instead of seeing alternatives as 
conflicting, they would be seen as complementary.

>To the extent that we've failed, the draft will need more work.

May be a good occasion to read Derrida too? (deconstruction)

IMHO the first IETF problem is the efficiency of its own deliverable: 
the Internet. Internet (as a whole set of propositions) should be 
useful to communities (like IETF). So, the efficiency of the IETF 
solutions and management is the very gauge of the IETF success. Seen 
as this the question is reduced to the Internet tools which should 
support and lead the process changes.

In addition if we are to change so many things because we want to 
change a process, we will never change the process. BTW this 
translates in a lack of update policy in the Internet systems, and 
97.5% of illegitimate calls on the root servers mostly because 
machines have not been updated for years and continue issuing 
erroneous requests.

The first need IMHO is to work on the IETF deliverables. What are 
they, how should they be presented, how can they be expected to 
change. From this, how can they be produced, and enhanced (for 
example where is experimentation to fit). In all that what are the 
invariants, what are the components, the parameters, etc. What can be 
independently changed. Then let see the underlying object structure, 
work on the metadata, build an ontology, and from this let build a 
management networked language to write/update management tools 
everyone can use, the IETF first.

Once you have that, you can discuss what is done today. Test the 
management language to replace current tools by a unified similar 
system. Then use the debate on process change to adapt and test small 
changes, which will test your management language. etc. Then adapt 
and come back if it does not work. You "enhance", you do not "change" 
anymore. You do not have IETF specific and may be erroneous 
solutions, like crazy RFC 3683, you have a source forge based 
community effort for a serious development culture instead of status 
quo smart maintenance as documented by Harald's "last" mail as IETF Chair.

jfc