ietf
[Top] [All Lists]

Re: [David Kessens] DISCUSS: draft-carpenter-rescind-3683

2006-10-22 15:11:04
David Kessens <david(_dot_)kessens(_at_)nokia(_dot_)com> wrote:
On Sat, Oct 21, 2006 at 07:14:41PM -0400, John Leslie wrote:

If we ever do have ADs interested in restoring the rights, I quite
specifically do _not_ want to repeat the denial-of-service attack on
this list.

What denial-of service attack are you talking about ?

   Caught me there: I was being intentionally vague... ;^(

Without the PR actions, the IESG would have had to discuss every
longer than 30 day suspension every so often.

   That is not the way I read Brian's draft. (Perhaps we should wordsmith
it so _nobody_ can read it that way?)

Every decision would be appealable and would result in using even more
valuable IESG resources each and every time we would make such a
decision as it would have been necessary to decide the merits of each
and every individual suspension over and over again (and for anybody
who has not been present during such discussions, we take this kind of
decisions very seriously and spend a lot of time to make sure that the
chosen approach is/was the proper/wrong one).

   A RFC 3683 P-R action _needs_ to be taken that seriously. A one-week
time-out on a single WG mailing list _shouldn't_ be taken that seriously.
In the middle, I'm not sure we have consensus...

   Brian's draft tries to _design_ a middle where we can have reasonable
consensus that the IESG doesn't need to discuss it, least of all reach
consensus about where the blame lies.

   You've been there, David: you _know_ it's hard!

IMHO, the strong majority of IETF participants are willing to let
the IESG design a process to deal with these two special cases _if_
the occasion even arises!

Although I am flattered that you have that much confidence in the
IESG, I believe it is not the right thing to do.

   Oh, I think it is! ;^)

This draft allows the IESG way more leeway than necessary to perform
its job.

   Perhaps -- but I _really_ don't want to risk allowing them _less_
than they need.

I agree that it is desirable that the IESG can allow longer suspensions
than 30 days that would fall between 30 day suspensions and a full
fledged PR action.

   That's a good start...

However, the current text in the draft allows the IESG to take
suspension actions without any limits that are way beyond what is
reasonable as there is no limit of the duration of the suspension as
the word 'progessively longer suspensions' is totally undefined and
there is no community oversight required when suspensions get really
lengthy:

   I freely admit that "progressively longer" can be interpreted to
mean "doubling for each similar infraction, without limit". In fact,
that is exactly what I would _like_ it to mean.

   I do not believe the current IESG members would endorse suspensions
that severe. The evidence is _quite_ strong that the IESG always will
choose a moderate path. (It drives me crazy sometimes!)

   I'm not sure what David means by "community oversight" here. In the
world as I observe it, the IESG is _never_ lacking community input.
Does David mean that somebody other than the appeal bodies above them
should be expected to overrule them? If so, who?

In addition, the following text is troublesome to me:

 Other methods of mailing list control may be considered but must be
 approved by the AD(s) and the IESG.

   Send text, please.

This basically allows the IESG to do whatever it pleases without
requiring community input. And because of this, it will also be hard
to appeal any decisions made this way as this draft supports the idea
that the IESG has the authority to do so.

   I don't read it that way. "Community input" can be something other
than a formal last-call; but a consensus-based body like the IESG isn't
likely to change its rules very much very often. Any "methods" approved
by the IESG _must_ be documented, and will most likely be published
in IETF Operational Notes. Rest assured, IESG members _will_ hear about
it if folks find them unreasonable.

Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:

I think what this draft describes is a reasonable thing to have, but
IMO it is not a substitute for RFC 3683.

It does not attempt to be a "substitute". It attempts to give needed
power to WGCs, subject to review by ADs under rules established by the
IESG. I believe this is what most folks want; and I do not believe that
most folks want to be subjected to lengthy arguments whether so-and-so
is a bad person.

I don't know where you read this: the only power it gives a working
group chair is that (s)he can ask an AD or the IESG for permission to
do a longer than 30 day suspension. Asking questions is not a lot of
power.

   Asking for something the AD is empowered to approve can be sufficient
power. (We need to wait to see what ADs _will_ be empowered to approve.)

This is where my problem lies. In the absence of a mechanism with
characteristics similar to RFC 3683, I cannot support rescinding it.

And, no surprise, I cannot support keeping a mechanism which generates
denial-of-service-like situations on this mailing-list and within the
IESG.

I don't see what you base this on.

   Personal opinion -- just like Ned's opinion above it.

   (It may help you understand if you consider how many years I watched
USENET flamewars develop, reaching the conclusion that they must be
de-fanged _quickly_...)

Not having this mechanism created way bigger problems than having this
mechanism. This mechanism was created for a reason and it worked.

   I recognize that David believes this; and I really doubt anything
any of us can say will change that belief. I only hope David will accept
that there might possibly be a better mechanism.

====
   That's enough for one post. I'll address David's question about the
difference between WG and non-WG lists in a separate post.

   (I think we're on the way to a productive exchange here; so I don't
mind risking a higher spot an the Narten list. ;^)

--
John Leslie <john(_at_)jlc(_dot_)net>

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf