Sam Hartman writes: > 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. I am already on record as opposing the adoption of an earlier version of this draft. I see nothing in the current version that would cause me to change my position. I just noticed another serious problem with this draft that I don't think anyone has commented on previously. RFC 3683 defines _two_ different types of Posting Rights Actions (PR-Actions): Ones to rescind posting rights and ones to _restore_ previously rescinded rights. From RFC 3683 section 2: One year after the PR-action is approved, a new PR-action MAY be introduced which restores the posting rights for that individual. The IESG SHOULD consider the frequency of nullifying requests when evaluating a new PR-action. If the posting rights are restored the individual is responsible for contacting the owners of the mailing lists to have them restored. This draft has this to say about RFC 3683: BCP 83 [RFC3683] has been found troublesome and contentious in practice. It is hereby rescinded. Any suspensions in place under BCP 83 at the time of approval of this document are not affected. So the two (?) existing PR-Actions will remain in effect, but the mechanism to rescind those PR-Actions will be gone if RFC 3693 is obsoleted. I really don't think this is an acceptable state of affairs - either the restoration mechanim has to be retained or the current PR-Actions would have to be terminated. The former is quite messy procedurally, the latter would IMO be a really bad idea. > 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. I have no problem with restoring this ability, but I do note that this doesn't return things to the pre-RFC 3934 state. In particular, the original text in RFC 2418 imposed no limits on the amount of time a suspension could remain in effect. The current draft allows suspensions of up to 30 days by WG chairs, with longer suspensions requiring AD/IESG approval. I think what this draft describes is a reasonable thing to have, but IMO it is not a substitute for RFC 3683. > Second, I'll ask whether people support rescinding RFC 3683. This is where my problem lies. In the absence of a mechanism with characteristics similar to RFC 3683, I cannot support rescinding it. David Kessens writes: > Discuss: > ... > 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 agree with David here. Unless the IESG is in receipt of a large number of favorable comments sent privately, I don't believe the necessary consensus exists. > ... > 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. Exactly. This document attempts to do too much at once and conflates things that should be separate. The devil in these things is always in the details, and the fact that problems like what I pointed out above are still turning up argues quite strongly that even if you agree with the goal (which I don't) the approach here is fatally flawed. > 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. I hadn't thought of the analogy, but I think it is a good one. And I don't think recent changes have addressed the underlying issue. > 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. I think this issue has been addressed in the revision. > 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. Another reason what's being proposed is not a substitute for RFC 3683. Ned _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf