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

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Oct 2006 16:33:34 -0400

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.

Subject: DISCUSS: draft-carpenter-rescind-3683
From: David Kessens <[email-masked]>
To: [email-masked]
Date: Thu, 12 Oct 2006 03:16:08 -0400
List-Id: iesg.ietf.org

Discuss:

Based on:

 http://tools.ietf.org/html/draft-iesg-discuss-criteria-02

 Section '3.1. DISCUSS Criteria':

 o  The IETF as a whole does not have consensus on the technical
    approach or document. There are cases where individual working
    groups or areas have forged rough consensus around a technical
    approach which does not garner IETF consensus. An AD may DISCUSS a
    document where she or he believes this to be the case. While the
    Area Director should describe the technical area where consensus
    is flawed, the focus of the DISCUSS and its resolution should be
    on how to forge a cross-IETF consensus.

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 find it somewhat ironic, that very recently, the grow working group
chair and list maintainer used the PR action tool to suspend somebody 
from the mailing list,
while the same thing happened on the IETF list and I have not heard a
single complaint about these actions. In addition, from my personal
experience, I am glad that the grow working group chair could take
immediate action, as opposed to having to wait for the chance to
discuss the issue at the IESG telechat.

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.

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.

In Section '1.  Posting Rights':

 An Area Director, with the approval of the IESG, may authorize
 posting rights suspensions of increasing length, i.e., the Area
 Director's power under [RFC2418] section 3.2 is reinstated at the
 time of approval of this document.

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.

 Management of non-working group mailing lists is not currently
 covered by this BCP, but is covered by relevant IESG Statements,
 which may be located via http://www.ietf.org/IESG/Statements.html.

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.

In addition, it is questionable and confusing to use two different
rulesets for IETF mailing lists.

In Section '2.  Specific Changes to RFC 2418':

 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.

I read this as saying that IESG approval is necessary for every
suspension longer than 30 days. For some reason one of the
contributors to this draft doesn't agree with my interpretation. It
seems a good idea to clarify what this sentence is supposed to mean as
the text seems to have a different meaning from what the author and
contributors meant to say.

I have choosen not to spend too much effort in elaborating these
flaws as I believe that it is questionable that the fundamental lack
of consensus on this draft can be bridged without significantly
changing the draft in a manner that would make the draft so different
from the original that it will have to be handled as completely new
submission.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 19 Oct 2006 16:54:54 -0400

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:

>Return-Path: <[email-masked]>
>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-masked]>
>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-masked]>; 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-masked]>; 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-masked]>; 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-masked]>; 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 [email-masked]; 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 [email-masked]; 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 [email-masked]; 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 <[email-masked]>; Thu, 12 Oct 2006 07:16:08 +0000 (GMT)
>Received: from mirror by ietf.org with local (Exim 4.43) id 1GXunY-0001qi-0W
>         for [email-masked]; Thu, 12 Oct 2006 03:16:08 -0400
>To: [email-masked]
>Cc:
>Message-Id: <[email-masked]>
>X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
>X-BeenThere: [email-masked]
>X-Mailman-Version: 2.1.5
>Precedence: list
>List-Id: iesg.ietf.org
>List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/iesg>,
>         <mailto:[email-masked]?subject=unsubscribe>
>List-Archive: <https://www1.ietf.org/mailman/private/iesg>
>List-Post: <mailto:[email-masked]>
>List-Help: <mailto:[email-masked]?subject=help>
>List-Subscribe: <https://www1.ietf.org/mailman/listinfo/iesg>,
>         <mailto:[email-masked]?subject=subscribe>
>Errors-To: [email-masked]
>X-Scanned-By: MIMEDefang 2.42
>X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on
>         solipsist-nation.suchdamage.org
>X-Spam-Level:
>X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO,
>         SUBJ_HAS_UNIQ_ID autolearn=no version=3.0.3
>MIME-Version: 1.0
>
>Discuss:
>
>Based on:
>

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Oct 2006 17:12:20 -0400

>>>>> "Joel" == Joel M Halpern <[email-masked]> 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.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 20 Oct 2006 04:01:13 +0200

Sam Hartman wrote:
 
> I'm going to last call the draft again.

The "discuss" was about -02, the new "last call" will be about
-03, here's a tiny URL for a diff: <http://tinyurl.com/y6c2nk> 

The iesg-discuss-criteria-02 I-D could be updated, it expired
two months ago, and there's apparently a bug in its chapter 4
"DISCUSS Resolution":

| the IESG has an alternative balloting procedure that can be
| used to override a single discuss position.  In the alternative
| procedure, all ADs are required to enter a "yes" or "no" 
| position on the document.  A document will be published if 
| two-thirds of the IESG state a position of "yes", and no more
| than two ADs state a "no" position.  Two-thirds of the IESG is
| formally defined as two-thirds of the sitting ADs (current 9),
| except for those who are recused from voting on the document
| in question, rounded up to the next whole number.  If three or
| more ADs hold a "no" position on a document using the 
| alternative balloting procedure, or if a document fails to 
| gather the required number of "yes" positions, the document
| will be returned to the WG with a "no" answer

That's more or less clear for an IESG with 9 members:

4 "Abstain" would kill the document anyway, 5:4 is less than 2/3.
3 "Abstain" could still pass for an outcome 6:3.

In the case of a pending DISCUSS and this alternative procedure
6:3 would fail, and 7:2 would pass, in essence 1/3 "no" is a veto.

But the IESG has now 15 members, and it takes 6 "Abstain" to kill
a document, while at most 5 "Abstain" could result in 10:5.  

With the same logic as above I'd expect that 10:5 would fail in
the alternative procedure, and 11:4 would pass.  But the draft
gives 3 members a veto no matter how many members the IESG has.

For the draft in question that means that it's now at 12:2, and
if one member changes his or her mind it could fail with a 11:3.

Frank

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 19 Oct 2006 23:12:04 -0400

> if one member changes his or her mind it could fail with a 11:3.

You are confusing the normal balloting process with the alternative one. 
Under the normal process, three IESG members have voted "yes" on this 
document (which is 3x the usual number), 9 have voted no-obj, two have 
abstained (including Brian, who's recused himself because he is the 
author), and there is one discuss.

The alternative balloting procedure is designed to allow the IESG to 
approve a document over the strong objections of one of its members 
(presumably, an IESG member having only weak objections would enter an 
"abstain", as Ted Hardie has done in this case).  This is an unusual step 
requiring a strong consensus, and it is not designed to be easy.  As far as 
I can tell, it also has not been invoked for this document.

but since you brought it up, let's look at this.  The text you quoted 
matches that at <http://www.ietf.org/u/ietfchair/discuss-criteria.html>, 
and requires two-thirds "yes" and not more than two "no" votes.  Note that 
these are votes entered specifically under the alternative balloting 
procedure; they are not derived from any normal votes which may have been 
entered.  In particular, there is no reason to assume that someone who 
voted "yes" or "no-objection" under the normal procedure will vote "yes" 
under the alternative procedure.  Under the normal procedure, a "yes" vote 
means "I think this document should be published" and a no-obj means "I 
don't have any strong feelings against publishing this document"; under the 
alternative procedure, a "yes" mean "I really think this document should be 
published, even though person X has objections".  The latter is rather a 
stronger statement.

Now, since Brian is the document author and has recused himself, there are 
14 sitting AD's who would be eligible to cast votes under the alternative 
procedure.  Since ceil(14*2/3) == 10, that means that publishing the 
document would require at least 10 "yes" votes and not more than 2 "no" 
votes.  Since "abstain" and "no" do not mean the same thing, the document 
could pass under that procedure with as many as 4 IESG members abstaining 
-- but not with more than 2 actively voting "no".

Finally, note that the alternative balloting procedure is intended to be 
applied as a last resort, when it is clear that the AD holding the discuss 
and the WG or individual who submitted the document cannot reconcile their 
differences.  I would be quite surprised to see this procedure invoked for 
the document now under discussion, since it is clear that steps are 
actively being undertaken to try to address David's concerns.

-- Jeff

---

From: Ted Hardie <[email-masked]>
Date: Thu, 19 Oct 2006 21:08:49 -0700

At 11:12 PM -0400 10/19/06, Jeffrey Hutzelman wrote:

>(presumably, an IESG member having only weak objections would enter an "abstain",

This is not what an abstain means in the IESG's procedures.    The text
from http://www.ietf.org/u/ietfchair/voting-procedures.txt says:

> - "Abstain" means "I cannot vote to send this document forward."
>    There are two obvious reasons one might vote this way:
>	- so strongly opposed to document that I am unwilling to "discuss".
>	  (note that this should be very unusual)
>	- I oppose this document for some philosophical reason but
>	  understand that others differ and am not going to stand
>	  in the way of the others

In the normal case, the "Comments" field will indicate why an
AD decided to abstain.

Note that a large number of Abstains sends a document back to
the working group.  Unlike recuse positions, which are not counted
in the 2/3 totals, abstains are counted along with yes, no objection,
and discuss.

			Ted Hardie

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 20 Oct 2006 06:45:01 +0200

> You are confusing the normal balloting process with the alternative one.

s/confusing/comparing/ - assuming that "yes + no objection" end up as "yes",
and "discuss + abstain" as "no".  Skipping Brian's "R" to get 14 ballots.

> there is no reason to assume that someone who voted "yes" or
> "no-objection" under the normal procedure will vote "yes" under the
> alternative procedure.

Sure, they can change their mind, the "abstain" also doesn't necessarily
end up as "no" if it's as you say a weak "abstain".  But apparently the
"at most 2 NO" limit in the I-D was designed for an IESG with 9 members,
not 15.

> Since ceil(14*2/3) == 10, that means that publishing the document would
> require at least 10 "yes" votes and not more than 2 "no" votes.

Yes, 11:3 would fail, 3 "no" have a veto in this procedure.  But it was
apparently tuned for 6:3, not 11:3 or even 12:3 (= 80% majority blocked
by 20%).

> the alternative balloting procedure is intended to be applied as a last
> resort, when it is clear that the AD holding the discuss and the WG or
> individual who submitted the document cannot reconcile their differences

Yes, that's clear, I only looked at it again because the DISCUSS in this
example explicitly mentioned the discuss-criteria I-D.  Nothing's wrong
if folks who think "no" can say "no" when asked.  But maybe they won't
if this can have the dubious side-effect of a 20% veto.

Frank

---

From: Sam Hartman <[email-masked]>
Date: Fri, 20 Oct 2006 08:57:05 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:
    Jeffrey> Finally, note that the alternative balloting procedure is
    Jeffrey> intended to be applied as a last resort, when it is clear
    Jeffrey> that the AD holding the discuss and the WG or individual
    Jeffrey> who submitted the document cannot reconcile their
    Jeffrey> differences.  I would be quite surprised to see this
    Jeffrey> procedure invoked for the document now under discussion,
    Jeffrey> since it is clear that steps are actively being
    Jeffrey> undertaken to try to address David's concerns.

Also, note that the alternative balloting procedure is mor intended
for disagreements over the text of the document than for questions of
process.  I guess it could be used in a case like this.  However I'd
rather avoid doing so.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Oct 2006 17:26:08 +0200

Just a couple of points since I think my colleagues have covered
most of this.

> matches that at <http://www.ietf.org/u/ietfchair/discuss-criteria.html>, 

Note that this document is part of the current informal set of
operational notes, and is pretty sure to become an early ION under
RFC 4693, as soon as the ION system is up and running. In other
words it's a living document and not frozen legislation.

> and requires two-thirds "yes" and not more than two "no" votes. 

etc. What these ballotting procedures are about, IMHO, is to allow the
IESG to work in something close to a "consensus if possible,
rough consensus otherwise" mode *and* to take decisions reasonably
quickly when the consensus is rough. (And yes, we know we are not
always reasonably quick.) But they all fit under the clause in
RFC 2026 that refers to "collective judgment of the IESG."

    Brian

---

From: John C Klensin <[email-masked]>
Date: Fri, 20 Oct 2006 14:48:04 -0400

--On Friday, 20 October, 2006 06:45 +0200 Frank Ellermann
<[email-masked]> wrote:

>> "no-objection" under the normal procedure will vote "yes"
>> under the alternative procedure.
> 
> Sure, they can change their mind, the "abstain" also doesn't
> necessarily end up as "no" if it's as you say a weak
> "abstain".  But apparently the "at most 2 NO" limit in the I-D
> was designed for an IESG with 9 members, not 15.

Frank, I am (obviously) not speaking for the IESG here, but I
don't think that "at most 2 NO" is, or should be, dependent on
the number of IESG members.  This should not be about a
sufficiently large majority.  Instead, I believe that, if one AD
has a serious problem with a document, it might be an aberration
or individual issue.  On the other hand, if there are two ADs
with problems serious enough to justify a "NO" vote --especially
if they are in different areas-- that we need some mechanism
other than voting to resolve the issues.

    john

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 21 Oct 2006 04:37:36 +0200

John C Klensin wrote:
 
> I don't think that "at most 2 NO" is, or should be, dependent on
> the number of IESG members.

Certainly not "is" in the DISCUSS draft, I wondered about "should".

Somebody (thanks!) told me off list that I got "(current 9)" wrong,
it's not the size of the IESG last year, it's ceil( 13*2/3 ) for a
9:4 result.  And 5 "abstain" could always kill any really bad idea
last year, now it takes 6 in the normal procedure without recuses.

> On the other hand, if there are two ADs with problems serious 
> enough to justify a "NO" vote --especially if they are in different
> areas-- that we need some mechanism other than voting to resolve
> the issues.

The draft says three ADs, 10:2 could pass.  Was this alternative 
procedure ever used ?  I'm a bit perplexed that there's no timeout
for a pending DISCUSS.  Nothing rush, a year or so, enough time to
discuss issues, and eventually agree to disagree.

Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Oct 2006 10:38:15 +0200

> procedure ever used ? 

Rarely if ever, but we have come close several times and found
a compromis instead.

> I'm a bit perplexed that there's no timeout

That is, I think, intentional. A firm timeout would make it
too easy to stop looking for a consensus solution.

     Brian

---

From: Sam Hartman <[email-masked]>
Date: Sat, 21 Oct 2006 09:51:51 -0400

We almost used the alternative procedure on the DHCP civil addresses
draft.  We almost used the alternative procedure on the unique local
addresses draft.

We used the alternate procedure on both PR actions even though they
are not really drafts.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Oct 2006 17:35:15 +0200

> draft.  We almost used the alternative procedure on the unique local

Right, but the keyword is "almost".

> We used the alternate procedure on both PR actions even though they

Correct, but the thread here was about DISCUSSes and drafts.

     Brian

---

From: Ned Freed <[email-masked]>
Date: Sat, 21 Oct 2006 13:12:06 -0700 (PDT)

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

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

> ...

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

> ...

> example, I suspect that longer mailing list suspensions are actually

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.

> them seperately. I don't believe it is good idea that we seem to be

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.

> described in this document in section 2.

I think this issue has been addressed in the revision.

> issues on non working group lists.

Another reason what's being proposed is not a substitute for RFC 3683.

				Ned

---

From: John Leslie <[email-masked]>
Date: Sat, 21 Oct 2006 19:14:41 -0400

Ned Freed <[email-masked]> wrote:
> Sam Hartman writes:
> 
>> David filed the following discuss on Brian's draft to rescind 3683.
> 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.

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

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

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

>> From a process perspective, it seemed more appropriate to separate
>> 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.

   Nobody has proposed them separately. I'd _much_ rather not react to
something which hasn't even been proposed.

> The devil in these things is always in the details,

   I absolutely agree!

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

   I hope I've explained the first "flaw" Ned mentioned. I there's
another, I'm willing to explain it too. But we need to understand that
"perfect" procedures simply don't happen except by iteration, with a
serious commitment by all involved to improve things.

   I see no "fatal" flaws here.

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

> Another reason what's being proposed is not a substitute for RFC 3683.

   I don't believe we _know_ the right apprach for non-WG lists. I
strongly support trying the geometrically-increasing suspensions being
tried on <[email-masked]>

   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.

--
John Leslie <[email-masked]>

---

From: David Kessens <[email-masked]>
Date: Sat, 21 Oct 2006 21:51:26 -0700

John,

> specifically do _not_ want to repeat the denial-of-service attack on

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.

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

> most folks want to be subjected to lengthy arguments whether so-and-so

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

> denial-of-service-like situations on this mailing-list and within the

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.

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

> appeared to honestly believe what they were saying).

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

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

---

From: John Leslie <[email-masked]>
Date: Sun, 22 Oct 2006 18:01:43 -0400

> 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

   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!

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

> there is no community oversight required when suspensions get really

   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?

>  approved by the AD(s) and the IESG.

   Send text, please.

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

> do a longer than 30 day suspension. Asking questions is not a lot of

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

> 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. ;^)

---

From: "Robert Sayre" <[email-masked]>
Date: Mon, 23 Oct 2006 02:51:46 -0400

> 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

---

From: John Leslie <[email-masked]>
Date: Mon, 23 Oct 2006 09:54:01 -0400

David Kessens <[email-masked]> wrote:
>>> [David's DICUSS stated:]
>>>> 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.
>> 
>> 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 ?
> 
>> strongly support trying the geometrically-increasing suspensions
>> being tried on <[email-masked]>
>> 
> so different from working group lists ?

   There are several.

   First: We have a better understanding of the problems on WG lists.
They generally cover a narrow enough focus that it's pretty clear who's
working towards consensus and whose beating a dead horse.

   Second: there's an immediacy about the tasks. The WG has charter
deadlines and must sometimes give ideas less discussion time than they
otherwise might deserve.

   Third: There are built-in checks against ignoring important input.
The output of a WG must go to last-call, at which point the ideas of
anyone who has been silenced _will_ be given attention. If those ideas
have merit, the process will be delayed, if not actually sent back for
rework.

   Non-WG lists, OTOH, cover a much wider range. Some of them are small
enough that "Please don't feed the troll" always works. Some of them
are already "by invitation only". Others, like <[email-masked]>, exist
as a catch-all to cover issues not dealt with elsewhere: such lists
_need_ to draw out discussions (like this) which seem like a waste of
time to most list participants.

   I'm not saying there are no problems on non-WG lists: just that
they're different enough that one size may not fit all -- and that we
should concentrate on fixing what we understand well.