Re: Last Call: 'Email Submission Between Independent Networks' to BCP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ned Freed <ned.freed@xxxxxxxxxxx> wrote:
> [Pekka Savola <pekkas@xxxxxxxxxx> wrote:]
>> On Wed, 8 Jun 2005, Ned Freed wrote:
>>> [Pekka Savola <pekkas@xxxxxxxxxx> wrote:]
>>>
>>>> A practical issue I have with this doc is that the recommendations are
>>>> relatively few, and most of them are rather generic or vague.
>>>> Haven't we learned more on email BCPs by now?
>>>
>>> What we have learned and what we are able to reach consensus on are two 
>>> very different things.

   I submit they are not different after all: where we are unable to reach
consensus, there's a _strong_ indication that not all of us have learned
the lesson yet.

   There _are_ genuine areas of difficulty in reaching consensus, alas.
These need to be explored...

>> My point is that when we are writing a document like this, making it
>> intentionally very generic and vague seems much less useful.
> 
> And my point is that a less generic document we cannot reach consensus on
> is and which therefore cannot be published of no use at all to anyone.

   And here we have the war of the generations. :^(

   (I call it the war of the generations because the _typical_ youngster
believes the world can be conquered before breakfast, while the _typical_
oldster has failed to conquer the world so often as to have given up
trying. In point of fact, though, I'm a definite oldster but I'm on Pekka's
side here.)

   We could easily lather, rinse, and repeat those two statements, getting
nowhere. Or we could easily have Pekka make specific suggestions, each of
which could be shot down by some weird case; and lather, rinse, repeat...

   Stepping back a bit, we note that Pekka is standing on grounds of
vagueness -- the sands shifting so fast as to obscure our sight -- while
Ned is standing on grounds of Catch-22 -- daring us to try to find a
consensus that he (or his friends) can't torpedo.

   We need to find common grounds on which to argue this, or we're doomed
to "lather, rinse, repeat". :^(

   When I was younger, I liked to propose where to find the common grounds;
I was even pretty decent at making successful suggestions. But I'm not
young anymore: so until one or the other shows some interest in finding
common grounds, I'm content to watch from the sidelines.

   However...

   There's an issue for all of us here: we are evolving into a paradigm
where the IESG can't agree to form a Working Group to tackle a known
problem (this is particularly obvious where spam is concerned); so they
wait for individual submissions; the individual submissions provoke
controversy; the controversy gets aired a bit on the IETF general list;
no consensus ensues; and eventually the IESG agrees that consensus will
never be reached, so it's better to publish what we have.

   This has obvious implications for the quality of documents approved by
the IESG. The implications are perhaps less obvious on the quality of
people _willing_ to serve on the IESG. (I'm still completely amazed that
Brian agreed to do so!)

   My point is that "Consensus will never be reached!" is a self-fulfilling
prophesy if we never even try the methods we have evolved for doing so.
These include:

 - forming a group which includes enough folks interested in a solution;
 - designating a moderator empowered to redirect efforts towards a goal;
 - designating a document editor to propose language;
 - issuing consensus calls on pieces of the solution;
 - exposing the consensus to review by non-participants;
 - et cetera...

   I've seen a lot of stuff on this list claiming that the IESG has only
itself to blame if its workload increases, because it was foolish enough
to create too many Working Groups. I've been biting my tongue, trying to
avoid shouting, "TANSSATMWG!" (There ain't no such thing as too many
Working Groups.)

   I know a lot of folks disagree with me there: that the "primary" job
of the IESG is managing Working Groups, so there must be some limit to
how many they can manage. I would respond that the IETF seems tolerant
of most any management scheme the IESG may choose; so there's no reason
they couldn't manage thousands of Working Groups. This would, I admit,
require some changes in paradigms:

 - Working Groups would not automatically deserve a session at meetings;
 - dissolution would be automatic with some level of inactivity;
 - Area Directors would not necessarily follow every mailing-list;
 - (I could continue, but you get the idea...)

   I must question whether the IESG sees management of Working Groups as
its primary goal: I think there's increasing evidence that they see
Quality-Control of RFCs as their primary goal, and that they have become
as suspicious of the quality of Working-Group drafts as they are of
individual submissions.

   If so, this is sad, and I wish we could change it.

--
John Leslie <john@xxxxxxx>

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]