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

2006-10-23 Thread Robert Sayre

On 10/22/06, David Kessens [EMAIL PROTECTED] wrote:


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 think the IESG should be granted more tautological authority.
Thanks to David Kessens for making enough noise to let the subject
surface from my spam filters, unlike recent spurious process
documents.

--

Robert Sayre

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


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

2006-10-22 Thread John Leslie
David Kessens [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 

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

2006-10-21 Thread Ned Freed
Sam Hartman writes:

 david filed the following discuss on Brian's draft to rescind 3683.
 David is concerned that the IETF consensus is not strong enough to
 approve this draft.

 We definitely could use your feedback on this issue.

I am already on record as opposing the adoption of an earlier version of this
draft. I see nothing in the current version that would cause me to change my
position.

I just noticed another serious problem with this draft that I don't think
anyone has commented on previously. RFC 3683 defines _two_ different types of
Posting Rights Actions (PR-Actions): Ones to rescind posting rights and ones to
_restore_ previously rescinded rights. From RFC 3683 section 2:

   One year after the PR-action is approved, a new PR-action MAY be
   introduced which restores the posting rights for that individual.
   The IESG SHOULD consider the frequency of nullifying requests when
   evaluating a new PR-action.  If the posting rights are restored the
   individual is responsible for contacting the owners of the mailing
   lists to have them restored.

This draft has this to say about RFC 3683:

   BCP 83 [RFC3683] has been found troublesome and contentious in
   practice.  It is hereby rescinded.  Any suspensions in place under
   BCP 83 at the time of approval of this document are not affected.

So the two (?) existing PR-Actions will remain in effect, but the mechanism to
rescind those PR-Actions will be gone if RFC 3693 is obsoleted. I really don't
think this is an acceptable state of affairs - either the restoration mechanim
has to be retained or the current PR-Actions would have to be terminated. The
former is quite messy procedurally, the latter would IMO be a really bad idea.

 In order to address David's concern, I'm going to last call the draft
 again.  The last call will will include two specific questions.
 First, I'll ask whether people support restoring the IESG/AD's ability
 to make longer than 30-day suspensions and to engage in alternate
 methods of mailing list control as described in RFC 2418.

I have no problem with restoring this ability, but I do note that this doesn't
return things to the pre-RFC 3934 state. In particular, the original text in
RFC 2418 imposed no limits on the amount of time a suspension could remain in
effect. The current draft allows suspensions of up to 30 days by WG chairs,
with longer suspensions requiring AD/IESG approval. I think what this draft
describes is a reasonable thing to have, but IMO it is not a substitute for RFC
3683.

 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.

David Kessens writes:

 Discuss:

 ...

 I don't see that there is IETF wide consensus on this draft at all.
 Based on that, I don't believe that this document should be published.

I agree with David here. Unless the IESG is in receipt of a large number of
favorable comments sent privately, I don't believe the necessary consensus
exists.

 ...

 Note that besides the lack of consensus, this document contains
 serious flaws:

 The biggest general problem is that this draft does two things at the
 same time:

 - 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. By
 coupling these two issues, the community got the suggestion that one
 needed to either to do both, or neither of them. From a process
 perspective, it seemed more appropriate to seperate both issues. For
 example, I suspect that longer mailing list suspensions are actually
 not controversial.

Exactly. This document attempts to do too much at once and conflates things
that should be separate. The devil in these things is always in the details,
and the fact that problems like what I pointed out above are still turning up
argues quite strongly that even if you agree with the goal (which I don't) the
approach here is fatally flawed.

 To say it in a different way: this approach feels way too much like
 what politicians in US congress do: add an unrelated measure to a bill
 and than force a vote on the issues together instead of considering
 them seperately. I don't believe it is good idea that we seem to be
 following this example.

I hadn't thought of the analogy, but I think it is a good one. And I don't
think recent changes have addressed the underlying issue.

 I have read section 3.2 of RFC 2418 repeatedly but I cannot find a
 similar sentence. Based on that, this document is ambiguous in what is
 now valid: is section 3.2 of RFC2418 reinstated or the replacement as
 described in this document in section 2.

I think this issue has been addressed in the revision.

  Management of non-working group mailing lists is not currently
  

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

2006-10-21 Thread John Leslie
Ned Freed [EMAIL PROTECTED] wrote:
 Sam Hartman writes:
 
 David filed the following discuss on Brian's draft to rescind 3683.
 David is concerned that the IETF consensus is not strong enough to
 approve this draft.
 
 We definitely could use your feedback on this issue.
 
 I am already on record as opposing the adoption of an earlier version
 of this draft. I see nothing in the current version that would cause
 me to change my position.

   I'm afraid that neither Ned nor I have anything to add to or subtract
from the strength of consensus on this issue. However, last call has
started, and we must tolerate a certain amount of repetition. If _any_
of us start flaming, please call us to task...

 I just noticed another serious problem with this draft that I don't
 think anyone has commented on previously.

   Indeed, though I noticed it beore the first I-D was even published,
I have not commented previously. But at Ned's prompting, I shall.

 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.

   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!

 So the two (?) existing PR-Actions will remain in effect, but the
 mechanism to rescind those PR-Actions will be gone if RFC 3693 is
 obsoleted.

   Exactly! That mechanism to restore rights is a bad mechanism.

 I really don't think this is an acceptable state of affairs - either
 the restoration mechanism has to be retained or the current PR-Actions
 would have to be terminated...

   Ned's view is too limited: there are many other ways to handle this.
He is seeing _only_ two ways; and those two are pretty close to the worst
I can imagine.

 In order to address David's concern, I'm going to last call the draft
 again.  The last call will will include two specific questions.
 First, I'll ask whether people support restoring the IESG/AD's ability
 to make longer than 30-day suspensions and to engage in alternate
 methods of mailing list control as described in RFC 2418.
 
 I have no problem with restoring this ability, but I do note that this
 doesn't return things to the pre-RFC 3934 state...

   I agree with Ned on both points here. I strongly support more options
for ADs. The draft being last-called is the product of negotiations
among IESG members. I quite agree it doesn't return to exactly where we
were; but I believe other considerations are more important.

 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.

 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.

 David Kessens writes:
 
 I don't see that there is IETF wide consensus on this draft at all.
 Based on that, I don't believe that this document should be published.
 
 I agree with David here. Unless the IESG is in receipt of a large number
 of favorable comments sent privately, I don't believe the necessary
 consensus exists.

   Most last-calls generate few comments. It's common for the IESG to
review negative comments and decide to publish the RFC anyway. I suspect
the IESG members have private conversations to help them decide whether
issues raised in the negative comments are serious enough to block
publication. (Goodness knows, I've had enough of _my_ negative comments
determined to be not serious enough.)

   Truth is, neither Ned nor I are charged to decide what is serious
enough.

 The biggest general problem is that this draft does two things at the
 same time:
 
 - 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 

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

2006-10-21 Thread David Kessens

John,

On Sat, Oct 21, 2006 at 07:14:41PM -0400, John Leslie wrote:
 Ned Freed [EMAIL PROTECTED] 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 

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

2006-10-19 Thread Joel M. Halpern
After re-read Brian's draft, RFC 3683, RFC 3934, and the relevant 
portions of RFC2418
I support the IESG/ADs ability to make longer than 30-day suspensions 
and to engage in alternate methods of mailing list control, as 
described in 2418.
I agree that the IESG having only the option of 1 year suspension, as 
required by RFC 3683, is unduly restrictive, does not help us, and 
should be rescinded.
If 3683 were rescinded without explicitly restoring the ability to 
make longer suspensions, then we would have to explain what other 
courses of action we did intend to have available.  Hypothetically, 
there might be some better alternative, so I am not coupling my 
response to the two questions.


Yours,
Joel M. Halpern

At 04:33 PM 10/19/2006, Sam Hartman wrote:




Hi, folks.


david filed the following discuss on Brian's draft to rescind 3683.
David is concerned that the IETF consensus is not strong enough to
approve this draft.

We definitely could use your feedback on this issue.

In order to address David's concern, I'm going to last call the draft
again.  The last call will will include two specific questions.
First, I'll ask whether people support restoring the IESG/AD's ability
to make longer than 30-day suspensions and to engage in alternate
methods of mailing list control as described in RFC 2418.  Second,
I'll ask whether people support rescinding RFC 3683.

I understand that the answers may be linked.  For example, I suspect
many people would view rescinding 3683 without granting ADs/WG chairs
the ability to make longer suspensions as a bad idea.
If so, you can explain how your answers are linked in your last call response.

Brian has also made other changes to the draft in order to clearly
separate the two aspects of the draft and to address some of David's
other concerns.


Hopefully enough people will respond that declaring rough consensus on
this issue will be easy.


Return-Path: [EMAIL PROTECTED]
Received: from solipsist-nation ([unix socket])
by solipsist-nation (Cyrus v2.1.18-IPv6-Debian-2.1.18-1+sarge2) with
LMTP; Thu, 12 Oct 2006 03:16:52 -0400
X-Sieve: CMU Sieve 2.2
Return-Path: [EMAIL PROTECTED]
Received: from south-station-annex.mit.edu (SOUTH-STATION-ANNEX.MIT.EDU
[18.72.1.2])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by suchdamage.org (Postfix) with ESMTP id A69131320D
for [EMAIL PROTECTED]; Thu, 12 Oct 2006 03:16:51 -0400 (EDT)
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
[18.7.7.76])
by south-station-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
k9C7GpL6010955
for [EMAIL PROTECTED]; Thu, 12 Oct 2006 03:16:51 -0400 (EDT)
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
k9C7Gipg025042
for [EMAIL PROTECTED]; Thu, 12 Oct 2006 03:16:44 -0400 (EDT)
Received: from megatron.ietf.org (megatron.ietf.ORG [156.154.16.145])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mit.edu (Spam Firewall) with ESMTP id 1B2BD1E926B
for [EMAIL PROTECTED]; Thu, 12 Oct 2006 03:16:39 -0400 (EDT)
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GXuo3-0007VZ-88; Thu, 12 Oct 2006 03:16:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1GXuo2-0007VT-NR
for iesg@ietf.org; Thu, 12 Oct 2006 03:16:38 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
helo=chiedprmail1.ietf.org)
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXuo2-0004kW-LA
for iesg@ietf.org; Thu, 12 Oct 2006 03:16:38 -0400
Received: from ns4.neustar.com ([156.154.24.139])
by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GXuo2-0001rb-Af
for iesg@ietf.org; Thu, 12 Oct 2006 03:16:38 -0400
Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42])
by ns4.neustar.com (Postfix) with ESMTP id 3FA412AC7F
for iesg@ietf.org; Thu, 12 Oct 2006 07:16:08 + (GMT)
Received: from mirror by ietf.org with local (Exim 4.43) id 1GXunY-0001qi-0W
for iesg@ietf.org; Thu, 12 Oct 2006 03:16:08 -0400
To: iesg@ietf.org
Cc:
From: David Kessens [EMAIL PROTECTED]
Message-Id: [EMAIL PROTECTED]
Date: Thu, 12 Oct 2006 03:16:08 -0400
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
Subject: DISCUSS: draft-carpenter-rescind-3683
X-BeenThere: iesg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: iesg.ietf.org
List-Unsubscribe: https://www1.ietf.org/mailman/listinfo/iesg,
mailto:[EMAIL PROTECTED]
List-Archive: https://www1.ietf.org/mailman/private/iesg
List-Post: mailto:iesg@ietf.org
List-Help: mailto:[EMAIL PROTECTED]
List-Subscribe: 

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

2006-10-19 Thread Sam Hartman
 Joel == Joel M Halpern [EMAIL PROTECTED] writes:

Joel After re-read Brian's draft, RFC 3683, RFC 3934, and the
Joel relevant portions of RFC2418 I support the IESG/ADs ability
Joel to make longer than 30-day suspensions and to engage in
Joel alternate methods of mailing list control, as described in
Joel 2418.  I agree that the IESG having only the option of 1
Joel year suspension, as required by RFC 3683, is unduly
Joel restrictive, does not help us, and should be rescinded.  If
Joel 3683 were rescinded without explicitly restoring the ability
Joel to make longer suspensions, then we would have to explain
Joel what other courses of action we did intend to have
Joel available.  Hypothetically, there might be some better
Joel alternative, so I am not coupling my response to the two
Joel questions.

To clarify, I have not issued the last call yet, I was just forwarding David's 
discuss comment to the appropriate list and letting people know how I plan to 
proceed.

There's no need to re-respond to the LC when it does come out though.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf