Subject: Re: Last Call: 'Progressive Posting Rights Supsensions' to BCP (draft-carpenter-rescind-3683)

From: "Tom.Petch" <[email-masked]>
Date: Mon, 23 Oct 2006 11:04:19 +0200

----- Original Message -----
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Sent: Saturday, October 21, 2006 12:29 AM
Subject: Last Call: 'Progressive Posting Rights Supsensions' to BCP
(draft-carpenter-rescind-3683)

> The IESG has received a request from an individual submitter to consider
> the following document:
>
> - 'Progressive Posting Rights Supsensions '
>    <draft-carpenter-rescind-3683-03.txt> as a BCP
>    This document abolishes the existing form of indefinite Posting
>    Rights Action and restores the previous option of finite posting
>    rights suspensions authorized by an Area Director.  It obsoletes RFC
>    3683 and updates RFC 2418 and RFC 3934.
>
>    Publication of this document will classify RFC 3683 as historic.
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2006-11-17.
>
> During IESG evaluation, an AD raised the concern that the
> consensus shown during the last call of this document might not be
> strong enough to justify approval. In order to determine the strength
> of the consensus, the IESG asks the community to focus on the following
> questions in last call responses:
>
> 1) Do you support the proposal in section 2 of the draft to restore
> the AD and IESG's ability to suspend posting rights for longer than
> 30 days and to approve alternative methods of mailing list control
> as originally documented in RFC 2418?
>
Not as it is documented in this I-D; the wording is not careful enough - eg
RFC2418 spells out that direct communication should be off list; RFC3934 may
have removed this but it should reinstated to improve clarity.
>
> 2) Do you support the proposal in section 3 to rescind RFC 3683?
>
No; RFC3683 does not remove or modify the toolkit available, it adds a new one.
The bald statement that the present IESG have found it
'troublesome and contentious in practice'
is inadequate to justify its repeal.

> 3) Do you have any concerns about approving one part of the draft
> without approving the other?
>
Yes, most definitely.
>
> 4) Do you have any other comments on the document?

Rather than patch RFC2418, that RFC should be reissued; this is a key process
for the IETF and we should not have to try and work out from multiple RFC what
the current state is.

Tom Petch

>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-carpenter-rescind-3683-03.txt
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 23 Oct 2006 17:46:47 +0200

Tom,

> have removed this but it should reinstated to improve clarity.

It's true that the phrase "communicating directly with the offending
individual" is no longer qualified by "rather than on the open mailing
list." I would have no problem restoring that phrase, although I
think it's redundant.

> is inadequate to justify its repeal.

Actually, this document doesn't *need* to contain any rationale.
The question is whether the community agrees. It doesn't say the IESG;
it uses the passive tense, and I think evidence for the whole community
finding it troublesome and contentious is to be found in the IETF mailing
list archive. Did you think those were useful and edifying discussions?

> for the IETF and we should not have to try and work out from multiple RFC what

In general, I agree. But so far the energy to revise 2418 as a whole
is lacking, and we are actively hampered by this specific issue.

    Brian

---

From: Robert Elz <[email-masked]>
Date: Tue, 24 Oct 2006 00:47:59 +0700

Date:        Mon, 23 Oct 2006 17:46:47 +0200
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | Actually, this document doesn't *need* to contain any rationale.
  | The question is whether the community agrees. It doesn't say the IESG;
  | it uses the passive tense, and I think evidence for the whole community
  | finding it troublesome and contentious is to be found in the IETF mailing
  | list archive. Did you think those were useful and edifying discussions?

If the current state is troublesome, a useful step would be to
enumerate the problems, and see if there's a way to fix them.
Only if it seems that the only acceptable solution is to completely
start afresh should that approach be adopted, more frequently some
revision of the process will improve things.

On the other hand, contentious can be, and in this case probably is,
a good thing, and is not a rationale for changing anything.

>From time to time, any community needs a way to let off steam, and
air all of the grudges.   Without that, things just simmer, and
end up getting worse and worse - what's more, with more and more
people getting disillusioned and simply leaving (especially those
who actually do productive work, rather than those who participate
just because it is part of their job description).

In general, at least as things are now, I would prefer that this
current draft simply be dropped, and the current status be retained.

To change that, at the very least, all of the issues in Ned Freed's
message would need to be dealt with.

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 23 Oct 2006 21:22:35 +0200

Hi Robert,

> revision of the process will improve things.

One bit of missing context is that in the General Area open meeting
in Montreal, we did discuss the general issue and Jim Galvin took the
action to follow up with a few interested parties. We don't have a
draft yet, but the idea of the present draft was to fix a couple
of immediate issues, not to be the end of the matter.

> current draft simply be dropped, and the current status be retained.

The problem with the current status is that we have no tools
intermediate between 30 days suspension by a WG Chair and
indefinite suspension by PR-action. That gives us a small hammer
and a very big hammer, and nothing for medium size nails.

     Brian

---

From: John C Klensin <[email-masked]>
Date: Mon, 23 Oct 2006 16:14:10 -0400

--On Monday, 23 October, 2006 21:22 +0200 Brian E Carpenter
<[email-masked]> wrote:

>...
>> In general, at least as things are now, I would prefer that
>> this current draft simply be dropped, and the current status
>> be retained.
> 

Brian,

I've been trying to avoid this discussion, but it appears to me
that, especially if the plan is to tune things further, there is
a middle ground in the proposals and comments that have been
made... and the subject draft isn't it.

I think that middle ground has the following elements:

(1) Any language in 3683 that appears to limit other actions
with regard to mailing list abuse needs to be overridden.  In
Montreal, I was convinced that the best way to do that, given
levels of discussion that turned into what, IMO, were
self-inflicted DoS attacks on getting any IETF list work done,
was to get rid of 3683.  I'm no longer convinced and think that,
maybe, the right thing to do in the short term is a very short
document (or piece of document), that simply overrides any
provisions of 3683, 3934, 2418, and even 4633 that appear to
constrain other options for dealing with a problem.  If we can
remember that we aren't a legislature trying to write laws that
cannot be interpreted in unreasonable ways, I think that
material should be moderately easy to write.

(2) We should let the experiment of 4633 run its course before
doing major retuning.  It seems to me that the intent of that
document is to provide ways to establish, and experiment with,
exactly the type of "hammer for medium-sized nails" that you
suggest is missing.  Indeed, if I read 4633 correctly, we can do
the overriding suggested above at our collective leisure, since
it seems to permit any or all of the intermediate measures.

(3) 3683, at least for the present, should remain on the table.
Efforts to initiate 3683 proceedings should consider not only
the behavior of the claimed offender but also the amount of
community energy a 3683 action takes up.  If that deters some
3683-type PR actions as just not worth the energy, fine.  If
not, then perhaps the comments suggesting that an indefinite
suspension that is expected to be more or less permanent should
require community discussion are correct... 

(4) It seems to me that the arguments that we should not permit
indefinite (or very long) suspensions without some more formal
action and opportunity for community comment have merit.   If
so, I would hope that can be taken as guidance for those
involved, especially when approving actions under 4633.   If
that guidance is not heeded, that would seem to be grounds for a
"procedures aren't working adequately or as intended" appeal,
which would force the then-required community discussion.
Otherwise, we revisit that question at the end of the 4633
period, i.e., revisit that and other questions in 16 months,
more or less.

Given 4633 and the comments above, what do you think we need to
do now... other than, possibly, un-doing the sections of the
existing specs that appear to limit, rather than expand, options?

    john

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 23 Oct 2006 17:13:17 -0400

On Monday, October 23, 2006 04:14:10 PM -0400 John C Klensin 
<[email-masked]> wrote:

> with regard to mailing list abuse needs to be overridden.

Agree.  IMHO this is by far the most important part of Brian's proposal, or 
of its intent, anyway.

> doing major retuning.

Agree.

> action and opportunity for community comment have merit.

3683 is a _very_ big hammer.  Such tools should not be difficult to use, 
but they should not be used without careful consideration of whether they 
are appropriate.  You can do a lot of damage trying to use s sledgehammer 
to drive a finishing nail.

I don't think the PR-action mechanism needs to be rescinded, but I do think 
it needs to be used with care, and I definitely think we need alternatives.

-- Jeff

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Oct 2006 21:05:39 +0200

> with regard to mailing list abuse needs to be overridden.

Ah, but the limiting language is in 3934. Hence the restructuring
of the -03 version of the draft.

> In

Given my reading of the various documents, it's written: sections
1 and 2 of the -03 draft.

> it seems to permit any or all of the intermediate measures.

I would completely agree with that. See
http://www.ietf.org/IESG/content/experiments.html

> existing specs that appear to limit, rather than expand, options?

Well, I'll wait until Sam summarizes this Last Call. My own
personal feeling is that we *really* need to fix the problem caused
by 3934, so that we can tune the hammers to the nails. As you say,
applying 3683 is not compulsory, so the world will not come to an
end if it lies on the books.

    Brian

---

From: Robert Elz <[email-masked]>
Date: Wed, 25 Oct 2006 03:59:41 +0700

Date:        Fri, 20 Oct 2006 18:29:37 -0400
    From:        The IESG <[email-masked]>
    Message-ID:  <[email-masked]>

I guess I should reply to the questions...

  | 1) Do you support the proposal in section 2 of the draft to restore
  | the AD and IESG's ability to suspend posting rights for longer than
  | 30 days and to approve alternative methods of mailing list control
  | as originally documented in RFC 2418?

The proposal, as a general thing, yes, the method it does it, no.

  | 2) Do you support the proposal in section 3 to rescind RFC 3683?

Not at this time.

  | 3) Do you have any concerns about approving one part of the draft
  | without approving the other?

Yes, of course - the IESG can't (or shouldn't) do things like that,
the right way is to produce a new draft that contains the new proposal,
and have that last called, so the community can see and comment on the
new version.   Too many more than editorial changes get made to docs as
part of the approval process already, aside from trivia like spelling
mistakes and out of date references (which should be the RFC editor's
job to fix anyway) the draft approved (or not) should be exactly the draft
last called, and not something different - if it has problems, have them
corrected them and issue a new last call.

  | 4) Do you have any other comments on the document?

Since a whole new draft needs to be written anyway, more comments on
this one aren't worth anyone's time.

Lastly, in response to my last message, Brian said ...

  | One bit of missing context is that in the General Area open meeting in
  | Montreal, we did discuss the general issue and Jim Galvin took the action to
  | follow up with a few interested parties. We don't have a draft yet, but the
  | idea of the present draft was to fix a couple of immediate issues, not to be
  | the end of the matter.

That's interesting, but irrelevant.   Either this draft stands alone, and
should result in a workable situation, with only the changes in this draft,
or it is to be part of a set of changes, in which case it needs to wait until
the other changes are ready to proceed.   Saying "we're going to do something
else, but take this change as a short term fix, even though it isn't really
adequate" simply isn't acceptable.

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Oct 2006 12:42:38 +0200

> The proposal, as a general thing, yes, the method it does it, no.

Please be specific - what is wrong with the words?

    Brian

---

From: Robert Elz <[email-masked]>
Date: Wed, 25 Oct 2006 20:27:41 +0700

Date:        Wed, 25 Oct 2006 12:42:38 +0200
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | 
  | >   | 1) Do you support the proposal in section 2 of the draft to restore
  | >   | the AD and IESG's ability to suspend posting rights for longer than
  | >   | 30 days and to approve alternative methods of mailing list control
  | >   | as originally documented in RFC 2418?
  | > 
  | > The proposal, as a general thing, yes, the method it does it, no.
  | 
  | Please be specific - what is wrong with the words?

Because what's in the words in the draft is not doing what the question
above implies that it is doing, it isn't restoring 2418 to its state
before later rfcs (intentionally or not) messed with it, it (the draft) is
proposing a whole new set of words that actually alter 2418.

All that is needed is to say that "notwithstanding the wording of any
RFC between 2418 and this, all provisions of rfc2418 apply as written in
rfc2418".

That is restoring 2418.   What your draft does is change 2418.   Note that
nothing above removes anything of what is in 3934, except where it (seems to
or does) limit the 2418 options.

kre

---

From: John C Klensin <[email-masked]>
Date: Wed, 25 Oct 2006 13:43:34 -0400

--On Wednesday, 25 October, 2006 20:27 +0700 Robert Elz
<[email-masked]> wrote:

>   | >   | 1) Do you support the proposal in section 2 of the
> draft to restore   | >   | the AD and IESG's ability to
> suspend posting rights for longer than   | >   | 30 days and
> to approve alternative methods of mailing list control   | >
>   | > The proposal, as a general thing, yes, the method it
> does it, no.   | 
> Because what's in the words in the draft is not doing what the
> question above implies that it is doing, it isn't restoring
> 2418 to its state before later rfcs (intentionally or not)
> messed with it, it (the draft) is proposing a whole new set of
> words that actually alter 2418.
> 
> All that is needed is to say that "notwithstanding the wording
> of any RFC between 2418 and this, all provisions of rfc2418
> apply as written in rfc2418".
> 
> That is restoring 2418.   What your draft does is change 2418.
> Note that nothing above removes anything of what is in 3934,
> except where it (seems to or does) limit the 2418 options.

Brian, kre,

It seems to me that part of the source of your disconnect is
that not only has 3683 been taken, intentionally or otherwise,
as modifying and restricting 2418, but 3934, intentionally or
otherwise, restricted the provisions of 2418 by (apparently)
banning any suspension longer than 30 days although permitting a
sequence of 30 day suspensions.

I believe it is that state of affairs that, as construed, has
led to the conclusion that we have no tools for dealing with
disruptive behavior that lie between "30 day suspension by WG
Chair and unclear situation wrt non-WG lists" and "PR-Actions
under 3863".  

We also have 4633 on the table.  Many of us believed that was
the necessary and sufficient measure to permit investigation of
ways to fill that gap. Its presence leaves me wishing for two
things, and two things only, at this point:

(1) If the existence of 3683, or 3934, or both, really impede
whatever would be sensible to do under 4633, then we should
clear those impediments away.    If that is needed, I think
kre's suggestion, and language, are exactly right: we affirm
that neither 3683 nor 3934 were intended to restrict 2418 but to
add additional possible mechanisms and then we move on.

(2) If they don't impede doing whatever it is sensible to do
under 4633, then we drop this until we have the experience that
4633 should give us plus whatever Jim's group concludes..  After
that, if necessary, we write a new, comprehensive, mailing list
document that pulls things back together -- we don't try to do
more patchwork.

And, finally, in the interim, people don't believe that the use
of 3683 is worth the energy it takes, then we don't use it.
Having it available as a mechanism that is not used is certainly
no worse than having a standards-track document lying around
that no one is paying attention to and no one is is moving to
have withdrawn ("declared historic").

    john

---

From: Ned Freed <[email-masked]>
Date: Wed, 25 Oct 2006 11:36:35 -0700 (PDT)

> sequence of 30 day suspensions.

RFC 3934 explicitly updates RFC 2418 and I have no problem rescinding that
update. RFC 3683 does not, and actually uses terms like "consistent with" and
"those guidelines will produce the desired modification in behaviour" when
referring RFC 2418. I therefore see no way to read RFC 3683 as eliminating any
actions possible under RFC 2418 and that means it is not necessary to obsolete
RFC 3683 to "fix" RFC 2418. If anyone believes otherwise, I'd like to hear some
justificaiton for how they have arrived at this conclusion.

Kre is also correct in stating that the current proposal does not restore RFC
2418. Rather, it replaces a piece of RFC 2418 with a new and slightly different
mechanism. I have no problem with making this change but kre is right in saying
that labelling this as "RFC 2418 restoration" is bogus.

> Chair and unclear situation wrt non-WG lists" and "PR-Actions

I understand how RFC 3934 leads to this conclusion. I don't understand how RFC
3683 does.

> add additional possible mechanisms and then we move on.

I guess I have no problem with a statement that says "any such effect by RFC
3683 was unintentional and is hereby voided" but really, this reminds me of a
bunch of mathematics papers written some years back about a particular class of
paracompact sets. It turned out the only such set is the empty set, and much
work had been done to understand, characteriize and clarify ... exactly
nothing.

> document that pulls things back together -- we don't try to do

Nodulo obsoleting RFC 3934, I think a wait-and-see approach makes
a ton of sense. Once we see how this plays out over a period of time
I think we'll be in a much better position to obsolete all of the
current documents with a single coherent set of mailing list guidelines.

> have withdrawn ("declared historic").

I will again point out that RFC 3683 defines two sorts of PR actions, one to
suspect posting rights and one to restore them. One of my objections to the
current draft is that it obsoletes both types of action while leaving the
current suspensions in place. I don't think this is a good thing.

				Ned

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Oct 2006 22:50:06 +0200

My head is spinning.

The draft (ignoring 3683) restores 2418 and adds the extra powers
created by 3934. I've been told by the author of 3934 that removing
the powers created by 2418 was not intended (even though there is
no other way to read the words in 3934). So I think the question on
the table is: does the community want the union of the powers created
by 2418 and 3934?

I can certainly agree that 4633, for its lifetime, seems to grant
at least these powers. But of course if we go that way, this discussion
will be back again in a year.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Oct 2006 22:50:06 +0200

My head is spinning.

     Brian

---

From: Ned Freed <[email-masked]>
Date: Wed, 25 Oct 2006 15:03:50 -0700 (PDT)

> My head is spinning.

Not a good sign given that you wrote the draft in question...

> created by 3934.

Yes, I think that's a fair statement of the intent and pretty close
to the specifics as well - as long as you ignore 3683.

> I've been told by the author of 3934 that removing

Well, my understanding is that the questions on the table are first,
whether or not this draft should move forward as-is, and if it should
not, what parts of it are OK and what parts aren't.

My objection to the current draft is quite simply that it obsoletes 3683. I
would be OK with what it does to 2418 and 3934 as long any material that
changes the status of 3683 is removed.

				Ned

---

From: "Tom.Petch" <[email-masked]>
Date: Thu, 26 Oct 2006 09:49:45 +0200

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "Ned Freed" <[email-masked]>
Cc: "John C Klensin" <[email-masked]>; <[email-masked]>; "Robert Elz"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, October 25, 2006 10:50 PM
Subject: Re: Last Call: 'Progressive Posting Rights Supsensions' toBCP
(draft-carpenter-rescind-3683)

> My head is spinning.
>
> The draft (ignoring 3683) restores 2418

<rant>
No, it does not.  I said so, others said so, and you do not get it.  You are
changing 2418; you may consider the changes trivial and of no consequence,
others are concerned that they may turn out not to be (as happened with
Wasserman).

Previously, I commented on the clarifying clause about warnings off-list; I see
that clause as useful, you see it as unnecessary.  It is a change.

'Progress' has become 'process'; this suggests that if a WG 's process consists
of going round in circles (quite common, actuallly) and I disrupt that in order
to get some progress, then I should be banned, under Carpenter or Wasserman (but
not under 2418).  Ok, this is not so serious but it is a change.

More seriously, Carpenter stops ADs from imposing 7-day suspensions; only Chairs
can do that; why is irrelevant, Carpenter makes changes, Carpenter does not
restore.

etc etc
</rant>

So I am absolutely with kre and Ned Freed on this; originator of last call
please note.

Tom Petch.

> and adds the extra powers

---

From: Robert Elz <[email-masked]>
Date: Thu, 26 Oct 2006 16:38:45 +0700

Date:        Wed, 25 Oct 2006 22:50:06 +0200
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | The draft (ignoring 3683) restores 2418 and adds the extra powers
  | created by 3934.

I'm sure  that's what you're intending, and it may even be that that
is the result, but it is not what the draft actually does.   What it
does is make a change to 2418 that might, or might not, undo the
unintentional side effects of 3934.   I don't really want to have to
consider whether it achieves that fully, and correctly, or not, as
we don't need to - given the intention, all that is needed is to
explicitly say that 3934 (whatever its words seem to say) does not
alter 2418, and 2418 remains in force, fully, as written.

That way, there's no need to combine together the words from two
docs, written by different people and try to consider them to be
one - instead we can just read 2418 alone, and follow it.  If anyone
ever attempts to use 3934 to limit 2418 we just refer them to your new
(not the existing) draft/rfc and say "no it doesn't, see rfcPQRS"

  | So I think the question on
  | the table is: does the community want the union of the powers created
  | by 2418 and 3934?

As Ned said, no it isn't - the current question is the last call of your -03
draft.   If you withdraw that from the IESG we could then move on to new
questions.

  | I can certainly agree that 4633, for its lifetime, seems to grant
  | at least these powers. But of course if we go that way, this discussion
  | will be back again in a year.

That has to happen anyway, to evaluate the 4633 experiment.   In a year
we'll have a year more of experience, and perhaps be better able to judge
what tools are really needed.

That however doesn't mean that I have any problems with issuing a doc that
simply says "3934 does not limit 2418 in any way" - without rescinding
3934 or altering its mechanisms (and completely ignoring 3683).  We do
not need to rewrite a part of 2418 to make a combined 2418+3934 in order
to achieve that, and not creating yet a third (or fifth or...) doc to have to
contend with seems like a win to me.

kre

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 31 Oct 2006 00:40:00 +0100

I think nobody is surprised by the opinions being given below....

> as originally documented in RFC 2418?
Yes.
> 2) Do you support the proposal in section 3 to rescind RFC 3683?
No. I believe this action to not be in the best long term interest of 
the IETF.
> without approving the other?
I don't find it clear what this means, so I'm answering two other questions:
- Would you support a document with section 2 and not the current 
section 3? Yes, with no concerns.
- Would you support a document with section 3 and not section 2? No, and 
I would be more concerned about such a document than I am about the 
current document.
> 4) Do you have any other comments on the document?
This document, if published as an RFC, requires infinite maintenance of 
the "Statements.html" URL specified herein.