ietf
[Top] [All Lists]

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

2006-10-21 22:00:49

John,

On Sat, Oct 21, 2006 at 07:14:41PM -0400, John Leslie wrote:
Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:

RFC 3683 defines _two_ different types of Posting Rights Actions
(PR-Actions): Ones to rescind posting rights and ones to _restore_
previously rescinded rights...

   Indeed. Both, inevitably, will prove contentious. I strongly
recommend obsoleting both.

   Whether or not we obsolete RFC 3683, I'd be surprised if any AD
will want to restore "posting rights" for the folks involved. But if
RFC 3683 remains in force, AD's will surely be asked to start a
process to restore rights. Can we be sure how they'll reply?

   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 ?

The PR actions that have been taken so far resulted in some lengthy
discussions but the resulting actions seem to have solved this problem
quite effectively. Without the PR actions, the IESG would have had to
discuss every longer than 30 day suspension every so often. 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).

The PR Action mechanism on the other hand, allows for community input,
and after the decision has been taken, it will be possible to appeal
the PR action itself, but any further posting right suspensions will
be taken with a very strong mandate which makes it a lot less likely
that lot of time needs to be spend on appeals of later suspension
decisions based on a PR action taken earlier.

   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. This draft allows the
IESG way more leeway than necessary to perform its job. 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.

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:

 If the disruptive behavior still persists and after explicit
 warnings, the Area Director, with the approval of the IESG, may
 request that the mailing list maintainer block the ability of the
 offending individual to post to the mailing list for periods
 longer than 30 days.

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.

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 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.

The only real change for the working group chair's authority is that
no consultation with the AD is necessary anymore for 30 day
suspensions. However, I don't think there are many working group
chairs who would even consider making such a decision without
consulting their AD. And whether it is required or not, as an AD, I
would certainly be very unhappy if a working group chair would not
discuss such a decision with me first (for the record, since I believe
in delegation, a consultation does *not* mean that I have to agree
with each and every decision that the working group chair makes).

Second, I'll ask whether people support rescinding RFC 3683.

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. Not having this mechanism created
way bigger problems than having this mechanism. This mechanism was
created for a reason and it worked. That doesn't mean that anybody
believes that this is mechanism should be invoked very often though,
it is designed for extreme cases and it is not a pleasure at all to
invoke it. 

In fact, that alone is good a way to make sure that it will not be used
for minor cases. I personally was very involved in one of the PR
actions. It was an enormous amount of work but I believe that it was
worth it as the results are that we can now finally hold a civilized
discussion on this list again.

- it rescinds 3683
- it allows longer than 30 day mailing list posting suspension

From a management perspective, these actions would normally be used
together: eg. 3883 actions would only be used after longer than 30
day mailing list suspension have been tried and were unsuccessful.

   David has had quite a while to propose an I-D to allow that. There
has been no such proposal. If one emerges, I'll be happy to comment on
it; but unless it actually _required_ say 90-day suspensions to have
been tried and failed, I'd worry about denial-of-service on the lists.

We already have an experiment on the books that allows us to just do
this as an experiment. I don't see any reason why we need more process
and procedures.

It is haphazardous at best to rescind one control mechanism and to
replace it with one that leaves non working group mail management
completely out in the dark, especially considering that we have had
most problems recently on non working group mailing lists and that the
only PR actions that were taken were specifically used to deal with
issues on non working group lists.

   This, IMHO, is David's strongest point. But I believe we have to,
first, get RFC 3683 out of the way, and second, look at why we've found
ourselves discussing P-R actions when possibly honest differences of
opinion arise (by which I mean only that Dean Anderson and JFC Morfin
appeared to honestly believe what they were saying).

So what do people do who manage non-working group IETF lists in the mean
time ?

   I don't believe we _know_ the right apprach for non-WG lists. I
strongly support trying the geometrically-increasing suspensions being
tried on <ietf(_at_)ietf(_dot_)org>

   We need experience with such ideas before we can claim to have a
solution for non-WG lists. We should not hold up Brian's proposal in
search of a perfection which may be beyond our reach.

Is there any particular reason why you believe that problem is really
so different from working group lists ? I for one note that the
problems that we have had with certain individuals were no different
whether they had chosen to disrupt working group mailing lists or non
working group mailing lists.

David Kessens
---

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