Subject: [Pesci-discuss] pesci-next-steps

From: "Michael Richardson" <[email-masked]>
Date: Thu, 23 Feb 2006 17:08:49 -0500

Elwyn, I read your nice simple document today.
I felt an immediate response was waranteed, so I'm typing on the bus.

I agree with everything.

Please I'd improve.
2.0:	recall I kept asking if this was the meta-process or
	the meta-meta-process.

I want to suggest that this be made explicite --- your document
is describing a meta-meta-process. 
      process:		      what a WG uses (such as "IPSEC")
      meta-process:	      what a meta-WG uses (such as "newtrk")
      meta-meta-process:      your document

2.1:  I think it is important to say that your meta-meta-process is
      simply a choice of a common IETF methodology --- the design team.
      i.e. no new technology is being proposed.

      It should be clear that newtrk, for instance, didn't really go
      the design team method. To a large extent, I'd call all WG lists
      "self-selected committee of the whole".
      A design team is often not self-selected, and does not represent
      the whole.

3.0:  you could consider reducing the problem set to just "IETF Chair",
      I doubt that any solution could be found to deal with that problem
      that didn't involve the IESG.

Maybe, instead of worrying about how to streamline the IETF, we should
restrict ourself to streamlining the IESG.

<SOLUTIONISM>
I would see things like bringing the IRTF in formally under the IAB,
maybe changing the name from "IETF #65 meeting" to "IAB #65 plenary".

I'd like to see things like having people/design-team publish an
Informational RFC as being the basis for a WG charter, for instance.
</SOLUTIONISM>

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

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

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 24 Feb 2006 12:09:28 +0000

Hi.

I updated the draft - new version and diff attached

I addressed the two sets of comments included below plus a couple of 
editorials:

Scott W Brim wrote:
> Hi there.  Tiny things ...
>
> On 02/23/2006 13:53 PM, Elwyn Davies allegedly wrote:
>>    This document sets out a strawman proposal for how to organize the
>>    revision and update of any part of the Internet Engineering Task
>>    Force (IETF) processes including those for developing standards and
>>    other specifications.  It does not propose specific changes to any of
>>    these processes, which should be the subject of future documents.
>>    However, it does identify some initial target areas for process
>
>                       propose ??
>
Done.
>>    change.
>
>>    In a previous document [I-D.davies-pesci-initial-considerations][ref]
>>    a design team selected by the IETF Chair suggested some goals and
>>    guidelines that should be followed in setting out to change any of
>>    the processes used in the IETF.  In the light of the design team's
>>    experience, this document suggests a possible way of organizing such
>>    process change work and also identifies a target area which should be
>
> should be?  --> perhaps s/which should be/as/
>
> The "should" later on is appropriate.
>
Done.
>>    the initial focus for process change to address the problems that
>>    were summarized in [I-D.davies-pesci-initial-considerations].
>
>>    [I-D.davies-pesci-initial-considerations] also contains a extensive
>>    reading list of background material which documents many of the
>>    processes which might be the subject of change through the process
>>    suggested in this document.  One problem that has been identified is
>>    that this material has been built up piecemeal over the lifetime of
>>    the IETF and it is neither entirely self-consistent nor easy to
>>    navigate even for experienced IETF participants.  An overview and
>>    guide to the existing and draft material has been developed
>>    [I-D.carpenter-procdoc-roadmap].  Over time it would be desirable to
>>    develop a more coherent and consistent set of documents for the
>>    processes.
>
> Either this should be a recommended task or it shouldn't be in here.
> I'd like to see it deleted here and added to the bullets -- something
> like "propose a structure for the documentation of the IETF process that
> would result from their recommendations".
>
Agreed - done.
>>    This should include:
>
> This review should include
Done.
>
> Finally, you'll fix up the xrefs?
Done.
Michael Richardson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
I think this is clear enough from the intro to s2 so I haven't done 
anything more.
>       A design team is often not self-selected, and does not represent
I removed the word 'new' from the first sentence in s2 and added a 
sentence to s2.1 to reinforce this.
> restrict ourself to streamlining the IESG.
In a sense that is what is suggested.  I am not actioning this one.

The rest is for later...
> ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
Regards,
Elwyn

draft-davies-pesci-next-steps-00.txt

draft-davies-pesci-next-steps-00-02.txt

Network Working Group E. Davies, Ed.

Network Working Group E. Davies, Ed.

Internet-Draft Folly Consulting

Internet-Draft Folly Consulting

Expires: August 27, 2006 February 23, 2006

Expires: August 28, 2006 February 24, 2006

Organizing IETF Process Change

Organizing IETF Process Change

draft-davies-pesci-next-steps-00

draft-davies-pesci-next-steps-00

Status of this Memo

Status of this Memo

By submitting this Internet-Draft, each author represents that any

By submitting this Internet-Draft, each author represents that any

applicable patent or other IPR claims of which he or she is aware

applicable patent or other IPR claims of which he or she is aware

have been or will be disclosed, and any of which he or she becomes

have been or will be disclosed, and any of which he or she becomes

aware will be disclosed, in accordance with Section 6 of BCP 79.

aware will be disclosed, in accordance with Section 6 of BCP 79.

skipping to change at page 1, line 33

skipping to change at page 1, line 33

and may be updated, replaced, or obsoleted by other documents at any

and may be updated, replaced, or obsoleted by other documents at any

time. It is inappropriate to use Internet-Drafts as reference

time. It is inappropriate to use Internet-Drafts as reference

material or to cite them other than as "work in progress."

material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at

The list of current Internet-Drafts can be accessed at

http://www.ietf.org/ietf/1id-abstracts.txt.

http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at

The list of Internet-Draft Shadow Directories can be accessed at

http://www.ietf.org/shadow.html.

http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 27, 2006.

This Internet-Draft will expire on August 28, 2006.

Copyright Notice

Copyright Notice

Copyright (C) The Internet Society (2006).

Copyright (C) The Internet Society (2006).

Abstract

Abstract

This document sets out a strawman proposal for how to organize the

This document sets out a strawman proposal for how to organize the

revision and update of any part of the Internet Engineering Task

revision and update of any part of the Internet Engineering Task

Force (IETF) processes including those for developing standards and

Force (IETF) processes including those for developing standards and

other specifications. It does not propose specific changes to any of

other specifications. It does not propose specific changes to any of

these processes, which should be the subject of future documents.

these processes, which should be the subject of future documents.

However, it does identify some initial target areas for process

However, it does propose an initial target area for process change.

change.

Table of Contents

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1. About This Document . . . . . . . . . . . . . . . . . . . . 3

1.1. About This Document . . . . . . . . . . . . . . . . . . . . 3

2. A Template for Process Change Organization . . . . . . . . . . 3

2. A Template for Process Change Organization . . . . . . . . . . 3

2.1. Change Process Proposal . . . . . . . . . . . . . . . . . . 4

2.1. Change Process Proposal . . . . . . . . . . . . . . . . . . 4

3. Immediate Tasks for the Change Process . . . . . . . . . . . . 4

3. Immediate Tasks for the Change Process . . . . . . . . . . . . 4

4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5

4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5

5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5

5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5

6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5

6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5

7. Informative References . . . . . . . . . . . . . . . . . . . . 6

7. Informative References . . . . . . . . . . . . . . . . . . . . 6

Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7

Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7

Intellectual Property and Copyright Statements . . . . . . . . . . 8

Intellectual Property and Copyright Statements . . . . . . . . . . 8

1. Introduction

1. Introduction

In a previous document [I-D.davies-pesci-initial-considerations][ref]

In a previous document [I-D.davies-pesci-initial-considerations] a

a design team selected by the IETF Chair suggested some goals and

design team selected by the IETF Chair suggested some goals and

guidelines that should be followed in setting out to change any of

guidelines that should be followed in setting out to change any of

the processes used in the IETF. In the light of the design team's

the processes used in the IETF. In the light of the design team's

experience, this document suggests a possible way of organizing such

experience, this document suggests a possible way of organizing such

process change work and also identifies a target area which should be

process change work and also identifies a target area as the initial

the initial focus for process change to address the problems that

focus for process change to address the problems that were summarized

were summarized in [I-D.davies-pesci-initial-considerations].

in [I-D.davies-pesci-initial-considerations].

[I-D.davies-pesci-initial-considerations] also contains a extensive

[I-D.davies-pesci-initial-considerations] also contains a extensive

reading list of background material which documents many of the

reading list of background material which documents many of the

processes which might be the subject of change through the process

processes which might be the subject of change through the process

suggested in this document. One problem that has been identified is

suggested in this document. One problem that has been identified is

that this material has been built up piecemeal over the lifetime of

that this material has been built up piecemeal over the lifetime of

the IETF and it is neither entirely self-consistent nor easy to

the IETF and it is neither entirely self-consistent nor easy to

navigate even for experienced IETF participants. An overview and

navigate even for experienced IETF participants. An overview and

guide to the existing and draft material has been developed

guide to the existing and draft material has been developed

[I-D.carpenter-procdoc-roadmap]. Over time it would be desirable to

[I-D.carpenter-procdoc-roadmap] as an interim measure.

develop a more coherent and consistent set of documents for the

processes.

1.1. About This Document

1.1. About This Document

This document was produced by the PESCI design team selected by the

This document was produced by the PESCI design team selected by the

IETF Chair and is submitted to the IETF community for discussion,

IETF Chair and is submitted to the IETF community for discussion,

modification, and hopefully expeditious approval. PESCI stands for

modification, and hopefully expeditious approval. PESCI stands for

Process Evolution Committee of the IETF and is in the IETF's naming

Process Evolution Committee of the IETF and is in the IETF's naming

tradition as a successor of the earlier POISSON working group. The

tradition as a successor of the earlier POISSON working group. The

membership of the design team is listed in the Acknowledgements and

membership of the design team is listed in the Acknowledgements and

the original announcement of PESCI is given as an Appendix. PESCI

the original announcement of PESCI is given as an Appendix. PESCI

has no special status in the IETF process; it is simply the group of

has no special status in the IETF process; it is simply the group of

people who produced this document under the leadership of the IETF

people who produced this document under the leadership of the IETF

Chair.

Chair.

Discussion of this draft is welcomed on the [email-masked]

Discussion of this draft is welcomed on the [email-masked]

list (join via https://www1.ietf.org/mailman/listinfo/pesci-discuss).

list (join via https://www1.ietf.org/mailman/listinfo/pesci-discuss).

2. A Template for Process Change Organization

2. A Template for Process Change Organization

The PESCI design team is proposing a new process for developing

The PESCI design team is proposing a process for developing changes

changes to the IETF processes especially in the area of developing

to the IETF processes especially in the area of developing standards

standards documentation and other specifications. It is intended

documentation and other specifications. It is intended that this

that this should be a template for any future change process that

should be a template for any future change process that appears to be

appears to be required, but in the best traditions of the IETF the

required, but in the best traditions of the IETF the process should

process should itself be tested by experiment and modified if it is

itself be tested by experiment and modified if it is found wanting.

found wanting.

This proposed new process

This proposed new process

o would be used by all individuals, design teams, and working groups

o would be used by all individuals, design teams, and working groups

who wish to propose changes or additions to IETF processes,

who wish to propose changes or additions to IETF processes,

o should involve consultation with the IESG, the IAB, the IAOC, the

o should involve consultation with the IESG, the IAB, the IAOC, the

Working Group chairs, and IETF participants generally, but

Working Group chairs, and IETF participants generally, but

o must avoid requiring the IESG to develop the new processes or

o must avoid requiring the IESG to develop the new processes or

micromanage this process of development and approval.

micromanage this process of development and approval.

The new proposals, both for the change process and any resulting

The new proposals, both for the change process and any resulting

changed processes, should be implemented as a matter of urgency and

changed processes, should be implemented as a matter of urgency and

should be handled expeditiously by the existing approvals and

should be handled expeditiously by the existing approvals and

publishing process.

publishing process.

2.1. Change Process Proposal

2.1. Change Process Proposal

We propose that the design team model is the most effective way of

We propose that the design team model is the most effective way of

engineering process changes. Within the context of the existing IETF

engineering process changes. The design team is a tried-and-tested

process, this could be arranged by constituting a set of design teams

IETF methodology especially suitable for creating concrete solutions

with appropriate oversight and the charter of carrying out process

applicable to constrained problems. Within the context of the

change. The design teams would operate within these charters: the

existing IETF process, the model would be applied by constituting a

overseers would invite design team members to participate, but

set of design teams with appropriate oversight and the charter of

alternative teams could offer solutions if they feel they have better

carrying out process change. The design teams would operate within

solutions.

these charters: the overseers would invite design team members to

participate, but alternative teams could offer solutions if they feel

they have better solutions.

The teams should function with an open discussion list, in the same

The teams should function with an open discussion list, in the same

way that the PESCI committee has done. The result of the committee

way that the PESCI committee has done. The result of the committee

should be tested against the IETF consensus in the normal fashion; we

should be tested against the IETF consensus in the normal fashion; we

believe that if there is clear IETF consensus that the proposal makes

believe that if there is clear IETF consensus that the proposal makes

sense, the IESG (and the ISOC Board of Trustees) will respect that

sense, the IESG (and the ISOC Board of Trustees) will respect that

consensus and approve of it.

consensus and approve of it.

3. Immediate Tasks for the Change Process

3. Immediate Tasks for the Change Process

skipping to change at page 5, line 5

skipping to change at page 4, line 50

The most important single management role in the IETF at the moment

The most important single management role in the IETF at the moment

is that of the IESG, including the role of IETF Chair. This should

is that of the IESG, including the role of IETF Chair. This should

therefore also receive the most scrutiny. It's unreasonable to ask

therefore also receive the most scrutiny. It's unreasonable to ask

people to grade their own performance, or to attempt to perform a

people to grade their own performance, or to attempt to perform a

role at full speed while having to review how it could be done

role at full speed while having to review how it could be done

otherwise. Therefore, a review of the roles the IESG has should be

otherwise. Therefore, a review of the roles the IESG has should be

rooted outside the IESG - while asking current and former IESG

rooted outside the IESG - while asking current and former IESG

members for information and advice at every opportunity.

members for information and advice at every opportunity.

This should include:

This review should include:

o Creating a list of the tasks that currently gate on the IESG

o Creating a list of the tasks that currently gate on the IESG

o Identifying any additional related tasks that might be appropriate

o Identifying any additional related tasks that might be appropriate

to improve efficiency and effectiveness

to improve efficiency and effectiveness

o Making proposals for discarding or restructuring the existing

o Making proposals for discarding or restructuring the existing

tasks in combination with the new tasks

tasks in combination with the new tasks

o Making a proposal for grouping those tasks into separate task

o Making a proposal for grouping those tasks into separate task

groups that can be assigned to different bodies at need.

groups that can be assigned to different bodies at need.

o Developing a proposal for how the standards development work of

o Developing a proposal for how the standards development work of

the IETF should be partitioned to provide optimum efficiency while

the IETF should be partitioned to provide optimum efficiency while

allowing the IETF to take on all appropriate work.

allowing the IETF to take on all appropriate work.

o Developing a suggestion for an initial set of bodies for handling

o Developing a suggestion for an initial set of bodies for handling

those tasks in the new work partitioning scheme, including, if

those tasks in the new work partitioning scheme, including, if

appropriate, a restructuring of the IESG.

appropriate, a restructuring of the IESG.

o Describing the process by which the set of bodies gets modified.

o Describing the process by which the set of bodies gets modified.

o Describing how members of the proposed bodies get selected,

o Describing how members of the proposed bodies get selected,

replaced, and (if needed) removed.

replaced, and (if needed) removed.

o Proposing a structure for the documentation of the IETF process

that would result from their recommendations

4. Security Considerations

4. Security Considerations

This document has no direct impact on the security of the Internet.

This document has no direct impact on the security of the Internet.

However, a smooth and efficient IETF process is necessary to deal

However, a smooth and efficient IETF process is necessary to deal

rapidly with emerging security threats. Also, a badly designed

rapidly with emerging security threats. Also, a badly designed

process may be subject to social denial of service attacks that could

process may be subject to social denial of service attacks that could

damage both the IETF and indirectly the Internet itself. We should

damage both the IETF and indirectly the Internet itself. We should

also note that the change process (and the evaluation of potential

also note that the change process (and the evaluation of potential

change) is itself vulnerable to social DoS.

change) is itself vulnerable to social DoS.

skipping to change at page 6, line 7

skipping to change at page 6, line 8

The members of the PESCI team at the time this document was written

The members of the PESCI team at the time this document was written

were:

were:

Harald Alvestrand

Harald Alvestrand

Scott Brim

Scott Brim

Brian Carpenter

Brian Carpenter

Elwyn Davies

Elwyn Davies

Adrian Farrel

Adrian Farrel

Michael Richardson

Michael Richardson

This document was produced using the xml2rfc tool [RFC2629] and

edited with the xxe editor plug-in.

7. Informative References

7. Informative References

[I-D.carpenter-procdoc-roadmap]

[I-D.carpenter-procdoc-roadmap]

Carpenter, B., "The IETF Process: a Roadmap",

Carpenter, B., "The IETF Process: a Roadmap",

draft-carpenter-procdoc-roadmap-03 (work in progress),

draft-carpenter-procdoc-roadmap-03 (work in progress),

December 2005.

December 2005.

[I-D.davies-pesci-initial-considerations]

[I-D.davies-pesci-initial-considerations]

Davies, E., "Moving Forwards with IETF Process Evolution",

Davies, E., "Moving Forwards with IETF Process Evolution",

draft-davies-pesci-initial-considerations-01 (work in

draft-davies-pesci-initial-considerations-01 (work in

End of changes. 11 change blocks.

27 lines changed or deleted

31 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/

Network Working Group                                     E. Davies, Ed.
Internet-Draft                                          Folly Consulting
Expires: August 28, 2006                               February 24, 2006

                     Organizing IETF Process Change
                    draft-davies-pesci-next-steps-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 28, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document sets out a strawman proposal for how to organize the
   revision and update of any part of the Internet Engineering Task
   Force (IETF) processes including those for developing standards and
   other specifications.  It does not propose specific changes to any of
   these processes, which should be the subject of future documents.
   However, it does propose an initial target area for process change.

Davies                   Expires August 28, 2006                [Page 1]

Internet-Draft          Organizing Process Change          February 2006

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  About This Document . . . . . . . . . . . . . . . . . . . . 3
   2.  A Template for Process Change Organization  . . . . . . . . . . 3
     2.1.  Change Process Proposal . . . . . . . . . . . . . . . . . . 4
   3.  Immediate Tasks for the Change Process  . . . . . . . . . . . . 4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   7.  Informative References  . . . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8

Davies                   Expires August 28, 2006                [Page 2]

Internet-Draft          Organizing Process Change          February 2006

1.  Introduction

   In a previous document [I-D.davies-pesci-initial-considerations] a
   design team selected by the IETF Chair suggested some goals and
   guidelines that should be followed in setting out to change any of
   the processes used in the IETF.  In the light of the design team's
   experience, this document suggests a possible way of organizing such
   process change work and also identifies a target area as the initial
   focus for process change to address the problems that were summarized
   in [I-D.davies-pesci-initial-considerations].

   [I-D.davies-pesci-initial-considerations] also contains a extensive
   reading list of background material which documents many of the
   processes which might be the subject of change through the process
   suggested in this document.  One problem that has been identified is
   that this material has been built up piecemeal over the lifetime of
   the IETF and it is neither entirely self-consistent nor easy to
   navigate even for experienced IETF participants.  An overview and
   guide to the existing and draft material has been developed
   [I-D.carpenter-procdoc-roadmap] as an interim measure.

1.1.  About This Document

   This document was produced by the PESCI design team selected by the
   IETF Chair and is submitted to the IETF community for discussion,
   modification, and hopefully expeditious approval.  PESCI stands for
   Process Evolution Committee of the IETF and is in the IETF's naming
   tradition as a successor of the earlier POISSON working group.  The
   membership of the design team is listed in the Acknowledgements and
   the original announcement of PESCI is given as an Appendix.  PESCI
   has no special status in the IETF process; it is simply the group of
   people who produced this document under the leadership of the IETF
   Chair.

   Discussion of this draft is welcomed on the [email-masked]
   list (join via https://www1.ietf.org/mailman/listinfo/pesci-discuss).

2.  A Template for Process Change Organization

   The PESCI design team is proposing a process for developing changes
   to the IETF processes especially in the area of developing standards
   documentation and other specifications.  It is intended that this
   should be a template for any future change process that appears to be
   required, but in the best traditions of the IETF the process should
   itself be tested by experiment and modified if it is found wanting.

   This proposed new process

Davies                   Expires August 28, 2006                [Page 3]

Internet-Draft          Organizing Process Change          February 2006

   o  would be used by all individuals, design teams, and working groups
      who wish to propose changes or additions to IETF processes,
   o  should involve consultation with the IESG, the IAB, the IAOC, the
      Working Group chairs, and IETF participants generally, but
   o  must avoid requiring the IESG to develop the new processes or
      micromanage this process of development and approval.
   The new proposals, both for the change process and any resulting
   changed processes, should be implemented as a matter of urgency and
   should be handled expeditiously by the existing approvals and
   publishing process.

2.1.  Change Process Proposal

   We propose that the design team model is the most effective way of
   engineering process changes.  The design team is a tried-and-tested
   IETF methodology especially suitable for creating concrete solutions
   applicable to constrained problems.  Within the context of the
   existing IETF process, the model would be applied by constituting a
   set of design teams with appropriate oversight and the charter of
   carrying out process change.  The design teams would operate within
   these charters: the overseers would invite design team members to
   participate, but alternative teams could offer solutions if they feel
   they have better solutions.

   The teams should function with an open discussion list, in the same
   way that the PESCI committee has done.  The result of the committee
   should be tested against the IETF consensus in the normal fashion; we
   believe that if there is clear IETF consensus that the proposal makes
   sense, the IESG (and the ISOC Board of Trustees) will respect that
   consensus and approve of it.

3.  Immediate Tasks for the Change Process

   Assuming that the model suggested in Section 2.1 is adopted, the
   following process change task appears to be the most urgent one, and
   a team should start on this as soon as possible.

   The most important single management role in the IETF at the moment
   is that of the IESG, including the role of IETF Chair.  This should
   therefore also receive the most scrutiny.  It's unreasonable to ask
   people to grade their own performance, or to attempt to perform a
   role at full speed while having to review how it could be done
   otherwise.  Therefore, a review of the roles the IESG has should be
   rooted outside the IESG - while asking current and former IESG
   members for information and advice at every opportunity.

   This review should include:

Davies                   Expires August 28, 2006                [Page 4]

Internet-Draft          Organizing Process Change          February 2006

   o  Creating a list of the tasks that currently gate on the IESG
   o  Identifying any additional related tasks that might be appropriate
      to improve efficiency and effectiveness
   o  Making proposals for discarding or restructuring the existing
      tasks in combination with the new tasks
   o  Making a proposal for grouping those tasks into separate task
      groups that can be assigned to different bodies at need.
   o  Developing a proposal for how the standards development work of
      the IETF should be partitioned to provide optimum efficiency while
      allowing the IETF to take on all appropriate work.
   o  Developing a suggestion for an initial set of bodies for handling
      those tasks in the new work partitioning scheme, including, if
      appropriate, a restructuring of the IESG.
   o  Describing the process by which the set of bodies gets modified.
   o  Describing how members of the proposed bodies get selected,
      replaced, and (if needed) removed.
   o  Proposing a structure for the documentation of the IETF process
      that would result from their recommendations

4.  Security Considerations

   This document has no direct impact on the security of the Internet.
   However, a smooth and efficient IETF process is necessary to deal
   rapidly with emerging security threats.  Also, a badly designed
   process may be subject to social denial of service attacks that could
   damage both the IETF and indirectly the Internet itself.  We should
   also note that the change process (and the evaluation of potential
   change) is itself vulnerable to social DoS.

5.  IANA Considerations

   This document does not require action by the IANA.  However, IANA
   activities do form part of the IETF process and process changes may
   affect IANA.

6.  Acknowledgements

   The members of the PESCI team at the time this document was written
   were:

      Harald Alvestrand
      Scott Brim
      Brian Carpenter

Davies                   Expires August 28, 2006                [Page 5]

Internet-Draft          Organizing Process Change          February 2006

      Elwyn Davies
      Adrian Farrel
      Michael Richardson

   This document was produced using the xml2rfc tool [RFC2629] and
   edited with the xxe editor plug-in.

7.  Informative References

   [I-D.carpenter-procdoc-roadmap]
              Carpenter, B., "The IETF Process: a Roadmap",
              draft-carpenter-procdoc-roadmap-03 (work in progress),
              December 2005.

   [I-D.davies-pesci-initial-considerations]
              Davies, E., "Moving Forwards with IETF Process Evolution",
              draft-davies-pesci-initial-considerations-01 (work in
              progress), January 2006.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

Davies                   Expires August 28, 2006                [Page 6]

Internet-Draft          Organizing Process Change          February 2006

Author's Address

   Elwyn Davies (editor)
   Folly Consulting
   Soham,
   UK

   Phone: +44 7889 488 335
   Fax:
   Email: [email-masked]
   URI:

Davies                   Expires August 28, 2006                [Page 7]

Internet-Draft          Organizing Process Change          February 2006

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Davies                   Expires August 28, 2006                [Page 8]