Subject: Possible new work items in the General Area

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

As General Area Director, I am aware of several topics outside
the scope of existing WGs (ipr, newtrk) that appear ready
for attention in the General Area. This message is a summary;
I will follow up with separate messages for each of the
following topics.

1. IESG structure and charter.
2. WG Procedures.
3. Appeals procedures.
4. Mailing lists management procedures.

We have two ways to tackle these topics. One way is to set up
a WG for each one, with a precise charter. Another way is
to encourage design teams to prepare and submit drafts
for IETF review, and for approval by the IESG as individual
submissions. Experience in the past suggests that the design
team approach may converge faster for process issues, but of
course their output must be subject to open discussion,
four-week IETF Last Call, and ultimately to appeal. However,
it's important to remember that the existence of a design team
gives it no special authority; only IETF consensus can change
the IETF's rules.

I am considering hosting mini-BOFs in a General Area open
meeting at IETF 66 to discuss each of the above topics
and to consider whether a WG or a design team is the best
way forward in each case. For that to be possible, I invite
people willing to do writing and editorial work on the above
topics to contact me in response to my four following messages.

Additionally, Harald Alvestrand has a proposal for an
operational notes series (draft-alvestrand-ipod) and Jim Galvin
is considering a maintenance update of BCP 10 (NomCom procedures).
I would expect these efforts also to be covered in the General Area
open meeting.

Meanwhile, the [email-masked] list remains open to all
those interested, for general discussion of process change issues.
https://www1.ietf.org/mailman/listinfo/pesci-discuss

    Brianwith ESMTP id
	k3SBo5H6057544 for <[email-masked]>; Fri, 28 Apr 2006 12:50:05 +0100
Date: Fri, 28 Apr 2006 13:39:14 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: IETF discussion list <[email-masked]>
Subject: Possible new work items in the General Area

As General Area Director, I am aware of several topics outside
the scope of existing WGs (ipr, newtrk) that appear ready
for attention in the General Area. This message is a summary;
I will follow up with separate messages for each of the
following topics.

1. IESG structure and charter.
2. WG Procedures.
3. Appeals procedures.
4. Mailing lists management procedures.

We have two ways to tackle these topics. One way is to set up
a WG for each one, with a precise charter. Another way is
to encourage design teams to prepare and submit drafts
for IETF review, and for approval by the IESG as individual
submissions. Experience in the past suggests that the design
team approach may converge faster for process issues, but of
course their output must be subject to open discussion,
four-week IETF Last Call, and ultimately to appeal. However,
it's important to remember that the existence of a design team
gives it no special authority; only IETF consensus can change
the IETF's rules.

I am considering hosting mini-BOFs in a General Area open
meeting at IETF 66 to discuss each of the above topics
and to consider whether a WG or a design team is the best
way forward in each case. For that to be possible, I invite
people willing to do writing and editorial work on the above
topics to contact me in response to my four following messages.

Additionally, Harald Alvestrand has a proposal for an
operational notes series (draft-alvestrand-ipod) and Jim Galvin
is considering a maintenance update of BCP 10 (NomCom procedures).
I would expect these efforts also to be covered in the General Area
open meeting.

Meanwhile, the [email-masked] list remains open to all
those interested, for general discussion of process change issues.
https://www1.ietf.org/mailman/listinfo/pesci-discuss

    Brian Carpenter
    General Area Director

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

with ESMTP id
	k3SBo5H6057544 for <[email-masked]>; Fri, 28 Apr 2006 12:50:05 +0100
Date: Fri, 28 Apr 2006 13:39:14 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: IETF discussion list <[email-masked]>
Subject: Possible new work items in the General Area

As General Area Director, I am aware of several topics outside
the scope of existing WGs (ipr, newtrk) that appear ready
for attention in the General Area. This message is a summary;
I will follow up with separate messages for each of the
following topics.

1. IESG structure and charter.
2. WG Procedures.
3. Appeals procedures.
4. Mailing lists management procedures.

We have two ways to tackle these topics. One way is to set up
a WG for each one, with a precise charter. Another way is
to encourage design teams to prepare and submit drafts
for IETF review, and for approval by the IESG as individual
submissions. Experience in the past suggests that the design
team approach may converge faster for process issues, but of
course their output must be subject to open discussion,
four-week IETF Last Call, and ultimately to appeal. However,
it's important to remember that the existence of a design team
gives it no special authority; only IETF consensus can change
the IETF's rules.

I am considering hosting mini-BOFs in a General Area open
meeting at IETF 66 to discuss each of the above topics
and to consider whether a WG or a design team is the best
way forward in each case. For that to be possible, I invite
people willing to do writing and editorial work on the above
topics to contact me in response to my four following messages.

Additionally, Harald Alvestrand has a proposal for an
operational notes series (draft-alvestrand-ipod) and Jim Galvin
is considering a maintenance update of BCP 10 (NomCom procedures).
I would expect these efforts also to be covered in the General Area
open meeting.

Meanwhile, the [email-masked] list remains open to all
those interested, for general discussion of process change issues.
https://www1.ietf.org/mailman/listinfo/pesci-discuss

    Brian Carpenter
    General Area Director

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

 Carpenter
    General Area Director

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

---

From: John C Klensin <[email-masked]>
Date: Fri, 28 Apr 2006 13:33:02 -0400

--On Friday, 28 April, 2006 13:39 +0200 Brian E Carpenter
<[email-masked]> wrote:

>...

Brian,

While I'm sympathetic to what you are trying to accomplish here,
I have to join Harald and Dave in wondering whether the efforts
are precisely what we need right now.  I'd cite two reasons that
are different, but complementary, to theirs and one that
reinforces the part of Dave's comment that kindly cited me.

(1) Efforts like this, unless tightly focused (and perhaps even
if they are tightly focused), tend to produce lists of problems.
We already have a WG-produced and community-approved list of
problems in RFC 3774 which is somewhat over two years old.
>From briefly skimming through that list, it would appear that
the number of those problems that have been successfully
addressed and solved via real proposals that have gone through
the system, been approved, and led to observable improvements
is, well, small.

While we should continue to evolve and not become complacent
about that state of things, making lists of problems is not
necessarily healthy for the IETF community unless we have a plan
about doing something useful and effective about them.  A focus
on lists of problems which we never get around to usefully
addressing tends to induce depression and maybe even reduced
participation, or reduced commitment, by those who actually do
substantive work around here.  To turn part of Dave's comments
around, it would be better to focus on our positive record of
timely and high-leverage accomplishments.  Neither drawing more
people who want to talk about process into the IETF, nor sucking
resources into process/problem considerations and away from
technical work, contributes to that positive focus.

(2) If they are successful, efforts like this also generate
specific proposals for change.    But we have had many specific
proposals for change in the time since the work that led to RFC
3774 was concluded.  In an attempt to stimulate some focused
discussion, I have written several of them.  I am, of course,
not the only one. To take a handy current example, there is at
least one plausible proposal on the table in the mailing list
management area (draft-hartman-mailinglist-experiment-01): it
may need tuning, but it went through Last Call and, the last I
heard, we deal with documents that have gotten through Last Call
by processing them, not by declaring them "in discussion" and
then holding [mini]BOFs that might subsume them.  With the
exception of RFC 3933 and possibly that mailing list draft, the
proposals for substantive changes have pretty much vanished
without a trace, unable to even generate serious discussion
(except, in some cases, complaints from selected present or past
IESG members about the ways in which they would change their
roles).

If the community were to go to the effort to generate additional
or different proposals, it would be useful to have some
assurance that those proposals would get serious consideration
and be accepted.  I don't feel that assurance right now.  The
reason I don't feel it is not an assumption about IESG behavior
-- I assume the IESG would approve anything that has clear
community consensus -- but because I think the majority of the
community has reached the point of not caring enough to
participate in the discussion and generate that consensus.   If
the community doesn't care, then either every proposal will die
or the IESG will need to make decisions based on their
assumptions about what they community would want if only it
cared.  That sense of community indifference is, itself, a
problem, at least IMO. But I am fairly sure that the fix to it
is not to generate yet more procedural work and the noise that
surrounds it.   Conversely, putting the IESG into a position in
which we _require_ that they substitute their judgment for
missing community consensus does not strike me as a good idea
from any point of view.

(3) Dave alluded to my efforts to point out situations in which
our documented processes are simply ignored when they are judged
to be inconvenient.  Again taking Sam's mailing list draft as a
possible handy case, I hope it isn't becoming the latest
example: the Last Call closed over a month ago and, while I am
personally sympathetic with David's comments, they came with a
"No Objection".  There is nothing else in the tracker that can
be interpreted as anything other than "AD (or the IESG more
generally) is sitting on it".  I've been repeated assured that
all abuses in which process definitions are ignored are ancient
history, but this one is beginning to acquire a bad odor, at
least as seen from the outside.

Unless there is a way to assure the community that any revised
rules will actually be followed, I see little value in working
on revised rules.  If any IESG member can say, ever, "I am going
to do what I, personally, believe to be the right thing even if
the community disagrees and, if they don't like it, they can
recall me", then the first procedural change we need is a more
effective way of controlling that sort of attitude than the
current recall procedure.  Without it, anything else is likely
to become pointless.  And I note that a miniBOF on making sure
that IESG (and IESG member behaviors) are aligned with community
consensus is not on your list.

To rephrase the comment I made at the beginning of this note, I
believe we need some procedural changes and am in favor of
anything that would actually produce ones that are effective and
represent community consensus.  I am not convinced that
community consensus --not just among those who enjoy focusing on
procedures but across the community of IETF contributors and
participants -- agrees with that belief.  But I think we have
"working code" that more statements of problems (no matter how
clear) and more proposals will not move us forward.  And I fear
that pulling more energy in those directions and away from
engineering and standardization work is more likely to be
harmful than helpful to the IETF.

I find the conclusion sad and difficult, but I am coming to the
conclusion that, except for problems that can be identified as
either

	(i) blocking factors in a clear cause and effect chain
	to getting quality work out and for which we have
	potential solutions that address that chain, or
	
	(ii) real solutions to identifiable (not hypothetical)
	abuses

I think the mailing list work --in the form of giving us
effective mechanisms to protect against denial of service
attacks on WGs and other efforts-- may fall into the first
category.  But the other things you have listed don't obviously
do so.  For those other things, it is may be time to take a few
years to recover from the pre-IASA work, the noise level in IPR,
what we didn't accomplish in the "Problem" WG, etc., and just
focus our energy on proving, by results, that the IETF can be a
good place to get productive and high-impact work done.

       john

---

From: Sam Hartman <[email-masked]>
Date: Fri, 28 Apr 2006 17:31:51 -0400

>>>>> "John" == John C Klensin <[email-masked]> writes:

    John> (2) If they are successful, efforts like this also generate
    John> specific proposals for change.  But we have had many
    John> specific proposals for change in the time since the work
    John> that led to RFC 3774 was concluded.  In an attempt to
    John> stimulate some focused discussion, I have written several of
    John> them.  I am, of course, not the only one. To take a handy
    John> current example, there is at least one plausible proposal on
    John> the table in the mailing list management area
    John> (draft-hartman-mailinglist-experiment-01): it may need
    John> tuning, but it went through Last Call and, the last I heard,
    John> we deal with documents that have gotten through Last Call by
    John> processing them, not by declaring them "in discussion" and
    John> then holding [mini]BOFs that might subsume them.  With the
    John> exception of RFC 3933 and possibly that mailing list draft,
    John> the proposals for substantive changes have pretty much
    John> vanished without a trace, unable to even generate serious
    John> discussion (except, in some cases, complaints from selected
    John> present or past IESG members about the ways in which they
    John> would change their roles).

In Brian's defense my draft's current delays are entirely on my
shoulders.  My day job ended up taking up a lot of time post IETF 65;
then I had to catch up on technical IESg work; I've mostly done that.
I have not had a chance to address last call comments.

I actually see Brian's proposal to have a mini-bof on mailing lists as
entirely complimentary to my draft.  My goal was to run an experiment
to give the community flexibility while working through what the real
requirements and solutions are.  If Brian can pull that effort
together that would be great.

Now, I don't know what will happen when I try to address those last
call comments and I don't know what will happen when you formally put
forward some of your proposals as RFC 3933 experiments.  If those
processes fail, and if RFC 3933 ends up being useless in practice,
I'll join you in arguing that I don't see a point.  As I said at IETf
65, RFC 3933 is my last hope for forward progress on process issues.
If we cannot make even that work, things are grim; I'll go ignore the
process issues completely until I find that's no longer an option.
Perhaps someone else will find a solution.  Perhaps the problems don't
need to be solved; we are getting a lot of technical work done,
efficiency and openness continue to improve; I at least am (other than
a few acute problems) happy with the IETF.  Or perhaps Dave is right
and we aren't producing timely relevant output and we'll eventually
all move on.