Progressive Posting Rights Suspensions
draft-carpenter-rescind-3683-03
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14
|
03 | (System) | Notify list changed from brc@zurich.ibm.com to (None) |
2007-10-11
|
03 | (System) | Document has expired |
2007-10-10
|
03 | Sam Hartman | Note field has been cleared by Sam Hartman |
2007-10-10
|
03 | Sam Hartman | State Changes to Dead from Waiting for AD Go-Ahead by Sam Hartman |
2007-10-10
|
03 | Sam Hartman | Approximately a year ago, on October 20, 2006, draft-carpenter-rescind-3683 entered its second last call. Today, I bring you the results of that last call. Before … Approximately a year ago, on October 20, 2006, draft-carpenter-rescind-3683 entered its second last call. Today, I bring you the results of that last call. Before I start, I want to make it clear that I do generally get back to documents in time periods much shorter than a year. Had I believed there was consensus to publish, I would have made this a much higher priority. However as it was, there were a lot of messages to go through, I had a lot more important things to do than go through the messages in detail and the general outcome was clear both to me and the draft author. However I have taken the time to go through all the last call comments and to get the issues fresh in my mind. I hope now to close out this draft. There is not consensus to publish the draft in its current form; thanks David for bringing up your concern leading to the second last call. I think there is rough consensus against publishing a draft containing text similar to section 3 of this draft. In other words, the community wants RFC 3683 to remain an option. However there are several areas where we may be able to achieve consensus to do something. Interested participants should consider writing drafts in these areas: 1) Several people expressed support for undoing the effects of RFC 3934 that limit suspensions previously allowed by RFC 2418. Brian believes that section 2 of this draft accomplishes that. Others are less sure. It may be that we could achieve rough consensus behind section 2. It seems like there may be even more support for text that simply clarified that RFC 3934 did not limit RFC 2418 but that did not itself amend RFC 2418. 2) There was general discussion about whether the IESG had an appropriate range of tools. It may be that creating new options with severity less than RFC 3683 but greater than a 30 day suspension is useful. For example would it be appropriate for the IESG to limit a PR-action to a specific set of lists? Etc? Are there other tools that the IESG needs? Any additional work in this area would require a new draft. If that draft were to be approved it would need to start the publication process at the beginning by finding a sponsoring AD. Brian, thanks for all your work on this issue. While we did not end up approving your draft, I think the discussion was informative and useful. Sam Hartman Area Director |
2007-05-23
|
03 | Sam Hartman | [Note]: 'It''s clear from the last call that there is not consensus to publish in current form. There was a lot of discussion though that … [Note]: 'It''s clear from the last call that there is not consensus to publish in current form. There was a lot of discussion though that I need to sort through to see if there are any suggestions that have consensus. I expect that any draft that is published will be significantly different than this one. Doing that sorting is a low priority for me, although I will eventually get to it. If you disagree with my prioritization send me mail.' added by Sam Hartman |
2007-05-23
|
03 | Sam Hartman | Status date has been changed to 2007-06-30 from |
2006-11-17
|
03 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2006-11-08
|
03 | (System) | Request for Last Call review by SECDIR Completed. Reviewer: Sandra Murphy. |
2006-11-08
|
03 | (System) | Requested Last Call review by SECDIR |
2006-10-23
|
03 | Yoshiko Fong | IANA 2nd Last Call Comment: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
2006-10-20
|
03 | Amy Vezza | Last call sent |
2006-10-20
|
03 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2006-10-20
|
03 | Amy Vezza | Last Call was requested by Amy Vezza |
2006-10-20
|
03 | Amy Vezza | State Changes to Last Call Requested from IESG Evaluation::AD Followup by Amy Vezza |
2006-10-18
|
03 | (System) | New version available: draft-carpenter-rescind-3683-03.txt |
2006-10-12
|
03 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
2006-10-12
|
03 | David Kessens | [Ballot discuss] Based on: http://tools.ietf.org/html/draft-iesg-discuss-criteria-02 Section '3.1. DISCUSS Criteria': o The IETF as a whole does not have consensus on the technical approach … [Ballot discuss] Based on: http://tools.ietf.org/html/draft-iesg-discuss-criteria-02 Section '3.1. DISCUSS Criteria': o The IETF as a whole does not have consensus on the technical approach or document. There are cases where individual working groups or areas have forged rough consensus around a technical approach which does not garner IETF consensus. An AD may DISCUSS a document where she or he believes this to be the case. While the Area Director should describe the technical area where consensus is flawed, the focus of the DISCUSS and its resolution should be on how to forge a cross-IETF consensus. 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 find it somewhat ironic, that very recently, the grow working group used the PR action tool to suspend somebody from the mailing list, while the same thing happened on the IETF list and I have not heard a single complaint about these actions. In addition, from my personal experience, I am glad that the grow working group chair could take immediate action, as opposed to having to wait for the chance to discuss the issue at the IESG telechat. 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. 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. In Section '1. Posting Rights': An Area Director, with the approval of the IESG, may authorize posting rights suspensions of increasing length, i.e., the Area Director's power under [RFC2418] section 3.2 is reinstated at the time of approval of this document. 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. 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 hazardous 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. In addition, it is questionable and confusing to use two different rulesets for IETF mailing lists. In Section '2. Specific Changes to RFC 2418': If the disruptive behavior still persists and after explicit warnings, the Area Director, with the approval of the IESG, may request that the mailing list maintainer block the ability of the offending individual to post to the mailing list for periods longer than 30 days. I read this as saying that IESG approval is necessary for every suspension longer than 30 days. For some reason one of the contributors to this draft doesn't agree with my interpretation. It seems a good idea to clarify what this sentence is supposed to mean as the text seems to have a different meaning from what the author and contributors meant to say. I have choosen not to spend too much effort in elaborating these flaws as I believe that it is questionable that the fundamental lack of consensus on this draft can be bridged without significantly changing the draft in a manner that would make the draft so different from the original that it will have to be handled as completely new submission. |
2006-10-12
|
03 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by IESG Secretary |
2006-10-12
|
03 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2006-10-12
|
03 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Yes from No Objection by Jari Arkko |
2006-10-12
|
03 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2006-10-12
|
03 | David Kessens | [Ballot discuss] Based on: http://tools.ietf.org/html/draft-iesg-discuss-criteria-02 Section '3.1. DISCUSS Criteria': o The IETF as a whole does not have consensus on the technical approach … [Ballot discuss] Based on: http://tools.ietf.org/html/draft-iesg-discuss-criteria-02 Section '3.1. DISCUSS Criteria': o The IETF as a whole does not have consensus on the technical approach or document. There are cases where individual working groups or areas have forged rough consensus around a technical approach which does not garner IETF consensus. An AD may DISCUSS a document where she or he believes this to be the case. While the Area Director should describe the technical area where consensus is flawed, the focus of the DISCUSS and its resolution should be on how to forge a cross-IETF consensus. 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 find it somewhat ironic, that very recently, the grow working group chair and list maintainer used the PR action tool to suspend somebody from the mailing list, while the same thing happened on the IETF list and I have not heard a single complaint about these actions. In addition, from my personal experience, I am glad that the grow working group chair could take immediate action, as opposed to having to wait for the chance to discuss the issue at the IESG telechat. 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. 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. In Section '1. Posting Rights': An Area Director, with the approval of the IESG, may authorize posting rights suspensions of increasing length, i.e., the Area Director's power under [RFC2418] section 3.2 is reinstated at the time of approval of this document. 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. 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. In addition, it is questionable and confusing to use two different rulesets for IETF mailing lists. In Section '2. Specific Changes to RFC 2418': If the disruptive behavior still persists and after explicit warnings, the Area Director, with the approval of the IESG, may request that the mailing list maintainer block the ability of the offending individual to post to the mailing list for periods longer than 30 days. I read this as saying that IESG approval is necessary for every suspension longer than 30 days. For some reason one of the contributors to this draft doesn't agree with my interpretation. It seems a good idea to clarify what this sentence is supposed to mean as the text seems to have a different meaning from what the author and contributors meant to say. I have choosen not to spend too much effort in elaborating these flaws as I believe that it is questionable that the fundamental lack of consensus on this draft can be bridged without significantly changing the draft in a manner that would make the draft so different from the original that it will have to be handled as completely new submission. |
2006-10-12
|
03 | David Kessens | [Ballot discuss] /hazaBased on: http://tools.ietf.org/html/draft-iesg-discuss-criteria-02 Section '3.1. DISCUSS Criteria': o The IETF as a whole does not have consensus on the technical approach … [Ballot discuss] /hazaBased on: http://tools.ietf.org/html/draft-iesg-discuss-criteria-02 Section '3.1. DISCUSS Criteria': o The IETF as a whole does not have consensus on the technical approach or document. There are cases where individual working groups or areas have forged rough consensus around a technical approach which does not garner IETF consensus. An AD may DISCUSS a document where she or he believes this to be the case. While the Area Director should describe the technical area where consensus is flawed, the focus of the DISCUSS and its resolution should be on how to forge a cross-IETF consensus. 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 find it somewhat ironic, that very recently, the grow working group chair and list maintainer used the PR action tool to suspend somebody from the mailing list, while the same thing happened on the IETF list and I have not heard a single complaint about these actions. In addition, from my personal experience, I am glad that the grow working group chair could take immediate action, as opposed to having to wait for the chance to discuss the issue at the IESG telechat. 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. 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. In Section '1. Posting Rights': An Area Director, with the approval of the IESG, may authorize posting rights suspensions of increasing length, i.e., the Area Director's power under [RFC2418] section 3.2 is reinstated at the time of approval of this document. 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. 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. In addition, it is questionable and confusing to use two different rulesets for IETF mailing lists. In Section '2. Specific Changes to RFC 2418': If the disruptive behavior still persists and after explicit warnings, the Area Director, with the approval of the IESG, may request that the mailing list maintainer block the ability of the offending individual to post to the mailing list for periods longer than 30 days. I read this as saying that IESG approval is necessary for every suspension longer than 30 days. For some reason one of the contributors to this draft doesn't agree with my interpretation. It seems a good idea to clarify what this sentence is supposed to mean as the text seems to have a different meaning from what the author and contributors meant to say. I have choosen not to spend too much effort in elaborating these flaws as I believe that it is questionable that the fundamental lack of consensus on this draft can be bridged without significantly changing the draft in a manner that would make the draft so different from the original that it will have to be handled as completely new submission. |
2006-10-12
|
03 | David Kessens | [Ballot Position Update] New position, Discuss, has been recorded by David Kessens |
2006-10-11
|
03 | Ted Hardie | [Ballot comment] I have some serious doubts about the quality of the consensus here, but I'll hold my nose. |
2006-10-11
|
03 | Ted Hardie | [Ballot Position Update] New position, Abstain, has been recorded by Ted Hardie |
2006-10-11
|
03 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2006-10-11
|
03 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2006-10-11
|
03 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2006-10-11
|
03 | Lars Eggert | [Ballot comment] > Progressive Posting Rights Supsensions Nit: s/Supsensions/Suspensions/ throughout the document |
2006-10-11
|
03 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2006-10-11
|
03 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2006-10-10
|
03 | Russ Housley | [Ballot Position Update] New position, Yes, has been recorded by Russ Housley |
2006-10-10
|
03 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
2006-10-06
|
03 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2006-10-05
|
03 | Brian Carpenter | [Ballot Position Update] New position, Recuse, has been recorded by Brian Carpenter |
2006-10-05
|
03 | Sam Hartman | State Changes to IESG Evaluation from Waiting for Writeup by Sam Hartman |
2006-10-05
|
03 | Sam Hartman | [Ballot Position Update] New position, Yes, has been recorded for Sam Hartman |
2006-10-05
|
03 | Sam Hartman | Ballot has been issued by Sam Hartman |
2006-10-05
|
03 | Sam Hartman | Created "Approve" ballot |
2006-10-04
|
02 | (System) | New version available: draft-carpenter-rescind-3683-02.txt |
2006-09-25
|
03 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2006-09-22
|
03 | Sam Hartman | Telechat date was changed to 2006-10-12 from 2006-09-28 by Sam Hartman |
2006-09-22
|
03 | Sam Hartman | Pushed forward one telechat; Ted Ts'o's comments suggest we need a new version |
2006-09-21
|
03 | Sam Hartman | Placed on agenda for telechat - 2006-09-28 by Sam Hartman |
2006-09-15
|
03 | Yoshiko Fong | IANA Last Call Comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
2006-08-28
|
03 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2006-08-28
|
03 | Sam Hartman | State Changes to Last Call Requested from AD Evaluation by Sam Hartman |
2006-08-28
|
03 | Sam Hartman | Last Call was requested by Sam Hartman |
2006-08-28
|
03 | (System) | Ballot writeup text was added |
2006-08-28
|
03 | (System) | Last call text was added |
2006-08-28
|
03 | (System) | Ballot approval text was added |
2006-08-26
|
03 | Sam Hartman | Draft Added by Sam Hartman in state AD Evaluation |
2006-08-17
|
01 | (System) | New version available: draft-carpenter-rescind-3683-01.txt |
2006-08-09
|
00 | (System) | New version available: draft-carpenter-rescind-3683-00.txt |