Re: Ombudsteam remedies and confidentiality

[John C Klensin <[e-mail]>]

Pete,

You raise several points I need to think about for a while and will
do so before responding to them (or not) but three quick
clarifications:

(i) Yes, I botched the terminology.  My apologies.

(ii) I obviously was not clear and am sorry about that, but my intent
was to open up the question of whether, after more than eight years
of experience, 7776 is completely right today (whether it was right
in 2016 or not) or whether it is time to review and possibly tweak it
a bit.  In a very general sense, every time your comments below
respond to something I wrote with the equivalent of "7776 requires
X", I am trying to open up the question of "is that really what we
want going forward or can we do better?"  I assume that, in the
overwhelming number of cases, the answer is "yes, that is what we
want".  But the others may be worth identifying and discussing.

(iii) I do know that much or all of it is complicated, definitely
complicated, or even more complicated that that.  I am not convinced
that somehow implies that it is not appropriate to examine the
questions from time to time.   I don't read your message as having
said otherwise, but it may be worth taking on.

best,
   john  

--On Thursday, August 29, 2024 21:10 -0500 Pete Resnick
<[e-mail]> wrote:

> 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