John,
I'm not Allison, and we haven't discussed all of these issues as a team, but a few comments and, more importantly, a few clarifications from 7776 that I'm pretty sure you know but can't hurt to remind everyone. I think these issues are worth discussing, but they are definitely complicated:
On 29 Aug 2024, at 14:51, John C Klensin wrote:
It seems to me that, while the privacy provisions of RFC 7776 are
very important, it appears that there may be edge cases where strict
adherence to a narrow reading of those rules might not be in the best
interests of the parties involved, the IETF community, or both.
Absolutely. In many cases, it would be very much in the interest of the community to know that bad behavior has been recognized and is being addressed so future behavior by others might be deterred and so people in the community could feel some sense of justice being served. But for better or worse, 5.2 of 7776 specifically says, "Because the handling of incidents of harassment (including the imposition of remedies) is confidential, an imposed remedy cannot itself serve as a deterrent to others, nor can it be used to 'teach' the community how to behave." Revisiting that provision is going to be tricky, for all of the reasons that the confidentiality provision was put originally put in (i.e., the well-being of both the subject and the respondent).
Examples:
- The ombudsteam interactions with Reporters and Subjects involve, at least as I have always understood things, a preference for resolving disputes and improving bad behavior rather than punishment if the latter can be avoided.
It's more than a preference; it's a mandate. Again from 5.2:
However, any remedy is imposed to try to make sure that the incident
does not escalate and to ensure that a similar situation is unlikely
to occur with the same Respondent in the future.
and
Furthermore, a remedy is not to be imposed for the
purposes of retribution.
and from section 9:
This process is designed to provide remedies not punishment
That is in sharp contrast with a public process like BCP 83 posting rights consideration which is about protecting the community and, directly or indirectly, publicly punishing offers by exclusion from selected IETF mailing lists, etc.
Definitely the public part is a sharp contrast, and that goes for the RFC 3934 process as well, which asks WG chairs to publicly warn disruptive participants before suspending any posting privileges.
That said, I do want to disagree with the characterization of "punishment". Neither 3683 nor 3934 use the word "punishment". Rather, both documents refer to stopping behavior that "disrupts" or is "disruptive to" the consensus process. Like 7776, each of the procedures is designed to simply stop the bad behavior. In 7776, it's to address what are "problematic behavior that may be more personal...that does not directly disrupt working group progress but nonetheless is unacceptable behavior between IETF Participants" whereas 3683 and 3934 are to address behavior that is "disruptive to the WG process", but neither is intended (as written) to be punitive. 3683 and 3934 actions might have the effect (unlike Ombudsteam action) of making the community feel more like justice was done or have deterrent effects, but that is certainly not overtly stated as an intent of either 3683 or 3934.
Whether or not it has ever occurred, having the ombudsteam consider a Subject while the community is debating a PR-action against that subject seems to me to create a situation that is the worst of both worlds for both the community and the Subject (more details about that on request if the reasons are not clear).
[N.B.: You meant "Respondent", not "Subject" here; the "Reporter" reports an incident, the "Subject" is the person to whom the behavior was directed (who might also be the Reporter), and the "Respondent" is the person who is claimed to have engaged in the behavior. I'll put in corrections below.]
Yes, the possibility of this kind of situation was what prompted the message that SM replied to. It is possible for a BCP 83 PR-Action and a complaint to the Ombudsteam to occur regarding the same participant, and perhaps the same set of incidents, and the message we sent was because we wanted the community to be aware that this was a possibility. But remember, depending on the timing, the Ombudsteam could always conclude, "Well, this person is now subject to a PR-Action, and we think that is sufficient to stop future problematic behavior, so we need impose no further remedy, or remove the remedy we already imposed." Or they might conclude, "Well, the PR-Action solves the problem for WG disruptions, but we have other concerns and therefore need additional or other sorts of remedies on top of that."
One remedy would be to allow the ombudsteam, upon discovering an overlap, to confidentially notify the IESG that there is an issue under discussion that might interact with the PR-action and ask the IESG to hold off. Alternatively, the IESG might, while contemplating announcing a Last Call on a PR-action, ask the ombudsteam whether there was a relevant subject (or [Respondent]) under discussion and the ombudsteam allowed to respond without disclosing any details.
This seems tricky: If I go to the IESG and say, "I want a PR-Action against John", and the Ombudsteam says to the IESG, "We've already got this", what is the IESG going to tell me, or others that reported John's terribly disruptive behavior? If the IESG explains, it becomes public to more than just the IESG. Maybe that's OK. But remember, 4.1 of 7776 says:
o In all cases, the Ombudsteam will strive to maintain
confidentiality for all parties, including the very fact of
contact with the Ombudsteam.
If the IESG does not explain, I'm going to be pretty grumpy about John's actions being unaddressed.
- The privacy provisions appear to be based on the assumption that privacy is in the best interests of all involved, especially those most directly involved. That might not be perceived as true, especially by a Subject [???] who is concerned that the privacy rules are being used to hide discriminatory or otherwise inappropriate actions or behavior. In such situations, the ombudsteam probably should have the discretion to reveal some information, presumably with the permission of the affected parties and anyone who might therefore be identified.
I think you're going to need to be more specific on this one, because I'm not sure whether you're really talking about the Subject or the Respondent, and who might be engaging in the "discriminatory or otherwise inappropriate actions or behavior".
- Should the conclusion of the ombudsteam in a particular case be that there is no reasonable remedy other than imposition of restrictions on the [Respondent]'s participation in the IETF, implementation of such a decision presumably requires at least some of: notification of list managers that the individual is to be removed from those lists, notification of the LLC that the individual is not allowed to register for meetings, and so on. The decision, at that point, is still secret from the broader IETF community but not from a range of individuals outside the ombudsteam who may or may not feel bound by the same privacy rules.
7776 section 8 is pretty clear on this point:
Third-party receivers of output from the Ombudsteam (for example, ADs
or the IETF Secretariat who are asked to take action) are required to
keep such output confidential.
They may or may not fell bound, but they definitely are!
The broader community may also have sufficient information to make inferences --correct or not-- about what happened. There is also the possibility that the [Respondent] would discuss the decision and their opinion of it in non-IETF contexts, in the worst case misrepresenting the discussion and decisions.
These you're right about. The only thing 7776 says on these two is:
Participants in an investigation (Reporters, Subjects, Respondents,
and anyone interviewed by the Ombudsteam during an investigation) are
requested to keep the details of the events and investigation
confidential.
It is likely that members of the community will want to know more
when they have become aware of some details of a case of harassment.
The community is asked to show restraint and to trust the Ombudsteam.
This process is designed to provide remedies not punishment, as
described in Section 5.2, and public discussion of the events or
remedies does not form part of this process.
Not exactly a hard and fast requirement, so there is a good possibility things get more public than desired.
Should any such situation arise, it is probably in the best interests of the community and the process that the ombudsteam have, at their discretion and ideally with the consent of the [Respondent], some ability to reveal selected information to all or part of the broader community.
I would want not only the consent of the Respondent but that of the Subject and perhaps Reporter: Part of the reason for confidentiality is to assure that people feel they can come to the Ombudsteam without fear of their personal circumstances being revealed publicly, let alone fear of potential retaliation.
Those are just examples and hypothetical ones at that. While I, like
anyone who reads this, can speculate, I have no evidence that any of
these situations have occurred and am, in any event, more concerned
about the future than in trying to revisit the past.
Obviously none of us on the Ombudsteam can talk about what has occurred in the past. But I can say that we've talked about these issues independent of any real case.
I would be
quite disappointed if the only way the perceived potential problems
could be addressed required an attempt to enumerate cases and spell
out details and specific actions in a document. I'd also predict
that trying to do that would be very painful and probably harmful to
the community.
I agree, that would not be good.
However, hypothetical situations like those argue for
explicitly giving the ombudsteam somewhat more discretion about
privacy should they, or other relevant edge cases, arise, especially
if a waiver of privacy involved a request of any of individuals who
might be identified or their prior consent.
I certainly would not object to the community trying to find ways to make that happen, but I haven't figured out any that don't give me agita.
pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
