Progressive Posting Rights Suspensions
draft-carpenter-rescind-3683-03

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

[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

[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.

[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.

[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.