Subject: Possible General Area MiniBOF 1: IESG structure and charter

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Apr 2006 13:40:53 +0200

People willing to work actively (i.e draft or
and edit) a document on this topic are
invited to contact me immediately. The objective
is to plan a mini-BOF during the General Area open
meeting at IETF 66. Without committed volunteers
in the community, this work will not happen.

The IESG charter (RFC 3710) was intentionally published
as an Informational RFC to fill a known gap, without the
overhead and formality of a BCP. It may now be appropriate
to refine and adapt it, based on experience and changes
since RFC 3710 was published. At minimum, the creation
of IASA requires makes some updates necessary.
(Note that draft-carpenter-ietf-chair-tasks contains
some relevant comments.)

RFC 3710 was produced by the IESG itself. I would certainly
want IESG members to be involved in any revision, but
it is important that members of the community also
take an active role, to ensure that the result meets
community expectations as well as practical reality.

   Brian Carpenter
   General Area Director

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

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 28 Apr 2006 15:27:13 +0200

Brian,

before asking for volunteers, you should state clearly whether you want 
people who will:

- DOCUMENT the EXISTING way the IESG works, and seek approval for that
- PROPOSE a NEW way the IESG can work, that fits the needs of the 
community better

The last one is what draft-davies-pesci-next-steps-00 was trying to 
suggest when it said:

   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:

   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

Your words suggest a far more timid approach.

                     Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Apr 2006 17:03:16 +0200

Harald,

I believe (speaking personally) that the analysis described below
would take enormous effort and would probably take a couple of years.
And despite the description, it isn't really focussed on the IESG -
the IESG's role is actually defined more or less automatically
by all the surrounding entities, procedures, and external forces.

I think we need to take smaller bites. My ambition is much less, indeed.

Of course, anyone who thinks they can identify energetic
resources to tackle what you cite below is free to propose
a BOF (but it clearly can't be a mini-BOF within another
meeting, for such a big topic.)

    Brian