[mpowr] Re: Fwd: I-D ACTION:draft-wasserman-rfc2418-ml-update-00.txt

John C Klensin <john-ietf@jck.com> Wed, 11 February 2004 21:24 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26549 for <mpowr-archive@odin.ietf.org>; Wed, 11 Feb 2004 16:24:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1q5-00089l-57 for mpowr-archive@odin.ietf.org; Wed, 11 Feb 2004 16:24:09 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BLO9tS031352 for mpowr-archive@odin.ietf.org; Wed, 11 Feb 2004 16:24:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1q4-00089b-OJ for mpowr-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 16:24:09 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26428 for <mpowr-web-archive@ietf.org>; Wed, 11 Feb 2004 16:24:05 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1q2-0001OS-00 for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 16:24:06 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1oU-00010m-00 for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 16:22:31 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar1nV-0000kr-00 for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 16:21:29 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar1iG-0006Ij-9q for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 16:16:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1iD-00073l-Bv; Wed, 11 Feb 2004 16:16:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1hI-00072G-Up for mpowr@optimus.ietf.org; Wed, 11 Feb 2004 16:15:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25061 for <mpowr@ietf.org>; Wed, 11 Feb 2004 16:15:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1hH-0007JZ-00 for mpowr@ietf.org; Wed, 11 Feb 2004 16:15:03 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1g7-00074Z-00 for mpowr@ietf.org; Wed, 11 Feb 2004 16:13:52 -0500
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar1es-0006kd-00 for mpowr@ietf.org; Wed, 11 Feb 2004 16:12:34 -0500
Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 1Ar1er-000KW8-00; Wed, 11 Feb 2004 16:12:33 -0500
Date: Wed, 11 Feb 2004 16:12:33 -0500
From: John C Klensin <john-ietf@jck.com>
To: Margaret Wasserman <margaret@thingmagic.com>
cc: mpowr@ietf.org
Message-ID: <27428319.1076515953@scan.jck.com>
In-Reply-To: <5.1.0.14.2.20040211142958.03fec7e8@ms101.mail1.com>
References: <5.1.0.14.2.20040211142958.03fec7e8@ms101.mail1.com>
X-Mailer: Mulberry/3.1.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Subject: [mpowr] Re: Fwd: I-D ACTION:draft-wasserman-rfc2418-ml-update-00.txt
Sender: mpowr-admin@ietf.org
Errors-To: mpowr-admin@ietf.org
X-BeenThere: mpowr@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpowr>, <mailto:mpowr-request@ietf.org?subject=unsubscribe>
List-Id: Management Positions -- Oversight, Work and Results <mpowr.ietf.org>
List-Post: <mailto:mpowr@ietf.org>
List-Help: <mailto:mpowr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpowr>, <mailto:mpowr-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

--On Wednesday, 11 February, 2004 14:49 -0500 Margaret Wasserman 
<margaret@thingmagic.com> wrote:

>
> Hi John,
>
> At 02:05 PM 2/11/2004 -0500, John C Klensin wrote:
>
>> I think this summarizes what I have gotten out of the
>> discussions, with  one qualification, noted below.  I'd love
>> to see this be a candidate for  either an immediate IETF Last
>> Call or the procedure outlined in
>> draft-klensin-process-july14-00.txt, since I have no reason
>> to imagine  that more debates about charters, or debates
>> within a WG, would tell us  anything we don't know already.
>
> I prefer an approach that runs:  (1) Tune as needed, (2) Four
> week last call, (3) Publish.
>
> I'd accept the experimental July 14 approach, though.

Of course, the two differ only in how much time one spends 
tuning before the Last Call is issued.  The "July 14" approach 
would move a little closer toward "issue four week last call, 
then make tuning improvements suggested during the last call 
before publication".  That difference is not significant enough 
to spend time on, unless the "tune as needed" process is likely 
to consume an unbounded amount of time.  Of course, were one to 
make an inference from the charter discussion, that may be worth 
worrying about :-(


>> (i) The intent, as I understand it, is to permit a WG chair
>> to rather  quickly suspend posting privileges in an abusive
>> situation and for a short  period of time.  Even the
>> possibility of attaching a second 30 day  suspension to the
>> end of the first one smells like abuse, and was not what
>> seems to be intended. So the WG Chair gets one 30 day
>> suspension as  specified, but longer or additional ones need
>> some additional  consultation, up through and including
>> application of  draft-mrose-ietf-posting-04.txt.
>
> I'm not sure that I fully agree....
>
> I agree that a chair should not ban someone from a mailing
> list for longer
> than 30 days by issuing back-to-back 30 day suspensions.
> However, I do think
> that a chair should be able to suspend a person for 30 days,
> let him back on
> the list, and eventually suspend him for 30 days again if
> there is another
> period of disruptive behaviour.

Ok.  I don't have a strong feeling one way or the other.  And I 
think this falls clearly into the category of things about which 
will learn more by trying it than by endless debate.  I'd rather 
see us get moving --on either model-- and then tune as/if 
needed, than spend a lot of time debating this.

> How about changing that final sentence to a separate paragraph
> that says:
>
> This mechanism is intended to permit a WG chair to suspend
> posting privileges
> of a disruptive individual for a short period of time.  This
> mechanism does
> not permit WG chairs to suspend an individual's posting
> privileges for
> a period longer than 30 days regardless of the type or
> severity of the
> disruptive incident.  However, further disruptive behaviour by
> the same
> individual will be considered separately and may result in
> further warnings
> or suspensions.  Other methods of mailing list control,
> including longer
> suspensions, must be approved by the IESG or carried out in
> accordance with
> other IESG-approved procedures.

Sure.  Whatever turns you on.  See above.

>> (2) The -01 version of this, if there is one, needs
>> spell-checking.
>
> Sorry, I produced it under a rather tight deadline.  I expect
> to publish
> an -01 update shortly after Seoul (hopefully for IETF Last
> Call), and I'll do better.

Not a problem.  I noticed and thought it was worth flagging.

>> (3) The procedural change I'd most like to see --not, in any
>> sense, the  one that is the most important, but one of those
>> I find most irritating --  would result in an Internet Draft
>> with two or three pages of substance not  ending up nine
>> pages long. I think those 8 1/2 pages are yet another
>> symptom that things have gotten somewhat out of hand.
>
> Me, too.  Some of the length can be attributed to the fact
> that the
> formatting tool I use puts each section on a new page.  Does
> anyone
> know if there is an option in xml2rfc to override that?

You are probably looking for
   <?rfc compact='yes'?>
but should be warned that it has other consequences, such as 
squeezing lists up against preceding and subsequent text.

> But, there are at least 4 pages of overhead, most of which has
> very limited utility.

Dear IESG member :-) ...my recollection is that almost every 
time the lawyers have been carefully asked about this, they have 
agreed that much of that text can be incorporated by reference, 
especially in I-Ds.  Somehow, we have ended up with a 
requirement for all of the text in the I-Ds themselves, and it 
wasn't because there was a community discussion, a Last Call, 
etc.  The one argument I've heard for its inclusion is that, if 
I'm forced to explicitly include it, I at least can't claim I 
don't know what I've agreed to.  But tools like xml2rfc make 
that argument largely, if not completely, obsolete, since the 
only thing that actually gets included is
   <rfc ipr="full2026" docName="draft-bozo-fubar-00.txt">
and it then spews out all of the boilerplate, including the bits 
that flunk my spell and/or grammar checkers.

At the risk of turning this into a mantra, "the IESG created 
this problem, the IESG can fix it (with no in-depth or amateur 
lawyer help from the community)".   And, that said, I strongly 
suspect the IESG has more important priorities, and I trust you 
(collectively) to make that decision too.

best,
    john


_______________________________________________
mpowr mailing list
mpowr@ietf.org
https://www1.ietf.org/mailman/listinfo/mpowr