![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
--On Monday, 23 October, 2006 21:22 +0200 Brian E Carpenter <brc at zurich.ibm.com> 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.
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,
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.
Ah, but the limiting language is in 3934. Hence the restructuring of the -03 version of the draft.
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.
Given my reading of the various documents, it's written: sections 1 and 2 of the -03 draft.
(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.
I would completely agree with that. See http://www.ietf.org/IESG/content/experiments.html
(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?
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
john
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.