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: <iesg-bounces@xxxxxxxx>
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: <iesg-bounces@xxxxxxxx>
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 <hartmans@xxxxxxxxxxxxxx>; 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 <hartmans@xxxxxxxxxxxxxx>; 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 <hartmans-ietf@xxxxxxx>; 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 <hartmans-ietf@xxxxxxx>; 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@xxxxxxxx; 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@xxxxxxxx; 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@xxxxxxxx; 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@xxxxxxxx>; 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 iesg@xxxxxxxx; Thu, 12 Oct 2006 03:16:08 -0400
To: iesg@xxxxxxxx
Cc:
From: David Kessens <david.kessens@xxxxxxxxx>
Message-Id: <E1GXunY-0001qi-0W@xxxxxxxx>
Date: Thu, 12 Oct 2006 03:16:08 -0400
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
Subject: DISCUSS: draft-carpenter-rescind-3683
X-BeenThere: iesg@xxxxxxxx
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: iesg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/iesg>,
<mailto:iesg-request@xxxxxxxx?subject=unsubscribe>
List-Archive: <https://www1.ietf.org/mailman/private/iesg>
List-Post: <mailto:iesg@xxxxxxxx>
List-Help: <mailto:iesg-request@xxxxxxxx?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/iesg>,
<mailto:iesg-request@xxxxxxxx?subject=subscribe>
Errors-To: iesg-bounces@xxxxxxxx
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:
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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf