--On Friday, 28 April, 2006 13:39 +0200 Brian E Carpenter
<brc@xxxxxxxxxxxxxx> wrote:
> 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.
>...
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
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf