--On Wednesday, 25 October, 2006 20:27 +0700 Robert Elz
Date: Wed, 25 Oct 2006 12:42:38 +0200
From: Brian E Carpenter <brc(_at_)zurich(_dot_)ibm(_dot_)com>
| > | 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.
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
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
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").
Ietf mailing list