Re: Last Call: <draft-farrresnickel-harassment-05.txt> (IETF Anti-Harassment Procedures) to Best Current Practice

[Sam Hartman <[e-mail]>]

>>>>> "Pete" == Pete Resnick <[e-mail]> writes:


    Pete> So I think this one is straightforward.

Agreed.

    Pete> As for the second issue, I think there's a basic piece that's
    Pete> missing in Sam's analysis, which we didn't get a chance to
    Pete> talk about offline:

    >> When I heard that the IESG added text saying that the ombudsteam
    >> cannot remove a leader, I felt a great anger.  How could they do
    >> that?

    Pete> The IESG *didn't* do that. Your premise is incorrect. The text
    Pete> that says that the ombudsteam cannot remove a leader has been
    Pete> in there since -03 due to public discussions. That bit was
    Pete> agreed to long ago and it has not been changed. What got
    Pete> changed during IESG Evaluation was to eliminate the one piece
    Pete> of text that said that the ombudsteam can *recommend*
    Pete> removal. The IESG did that because it was realized that the
    Pete> Ombudsteam *couldn't* recommend removal without revealing
    Pete> confidential information.

I read and reviewed 05 as a document that intended to have a plausible
way forward for removing leaders.  The IESG alone changed that to a
statement that leaders cannot be removed.

I'm sorry I did not clearly state my concern, but that transition from a
document that tries to support removing leaders but has a buggy
mechanism to one that does not support leaders has all the problems I
describe.

More over, the inability to remove leaders seems to be a inadequacy of
the procedures in the sense of RFC 2026 6.5.1 and 6.5.3.
This message is not any sort of formal process; it is simply a posting
to the ietf list.
However, my disagreement is that strong.