Allison,
A question/comment inspired by parts of a discussion with two of your
colleagues, the notes below, and assorted recent events. I am asking
now because it might be helpful for the ombudsteam to discuss the
issue, and possibly even factor it into the promised report, should
you want to do that. No obligation, of course but, if the team has
thoughts on the subject, it would probably be helpful to have them
rather than putting an uninformed I-D on the table that would take us
into the next giant rathole.
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.
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. 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.
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). 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 Subject) under discussion and the
ombudsteam allowed to respond without disclosing any details.
* 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.
* Should the conclusion of the ombudsteam in a particular case be
that there is no reasonable remedy other than imposition of
restrictions on the Subject'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. The broader community may also
have sufficient information to make inferences --correct or not--
about what happened. There is also the possibility that the Subject
would discuss the decision and their opinion of it in non-IETF
contexts, in the worst case misrepresenting the discussion and
decisions. 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
Subject, some ability to reveal selected information to all or part
of the broader community.
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. 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. 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.
Thanks for your consideration.
john
--On Wednesday, August 28, 2024 13:43 -0400 Allison Mankin
<allison.mankin@xxxxxxxxx> wrote:
> Hi S and Roman,
>
> We appreciate the interest of the community in this, starting with
> Adrian's plenary question.
>
> As Pete mentioned, we want to complete the new ombudsteam members'
> onboarding process before we publish the methods document. The
> training sessions, if all goes well, will be complete September
> 20th. This makes us a little bit behind Pete's statement in
> Vancouver, but not much. We have started the document and hope to
> share it within September.
>
> Allison for the Ombudsteam
>
> On Wed, Aug 28, 2024 at 08:54 Roman Danyliw <rdd@xxxxxxxx> wrote:
>
>> Hi!
>>
>> > -----Original Message-----
>> > From: S Moonesamy <sm+ietf@xxxxxxxxxxxx>
>> > Sent: Wednesday, August 28, 2024 3:03 AM
>> > To: ietf@xxxxxxxx
>> > Subject: Re: Ombudsteam remedies and confidentiality
>> >
>> > Warning: External Sender - do not click links or open
>> > attachments unless
>> you
>> > recognize the sender and know the content is safe.
>> >
>> >
>> > Hello,
>> >
>> > RFC 7776 (Section 4.1) stated that: "These [operating] practices
>> > must be discussed with the IESG and published in a publicly
>> > visible place (such
>> as on the
>> > IETF web site). Discussion with the IETF community is
>> > encouraged and,
>> ..."
>> >
>> > RFC 7776 was published in 2016.
>> >
>> > (a) The operating practices have not been published up to
>> > this day.
>>
>> I'll let the Ombudsteam answer for itself on their planned next
>> steps.
>>
>> I will share that when Adrian Farrel asked an almost identical
>> version of this question at the IETF 120 plenary, Pete Resnick
>> provided a timeline of publishing these practices as "well before
>> the next IETF Meeting" [1].
>>
>> ==[ snip ]==
>> > ADRIAN FARREL:
>> ...
>> RFC 7776 is now eight years old. One of the things it says is the
>> Ombudsteam is
>> responsible for devising and documenting their operating
>> practices. These practices must
>> be discussed with IESG and published in a publicly visible place,
>> such as on the IETF
>> website.
>> It was understandable in the first couple of years, the processes
>> were not written up
>> because they were being developed, and it's a self-organizing
>> team, but what I would like
>> to do is ask you to put a bit of pressure on them now to get those
>> processes properly
>> published.
>> ...
>> >> PETE RESNICK: Funny you should mention that, Adrian.
>> Yes, we are very much aware of this, and we agree it is something
>> we need to do.
>> ...
>> We are, I believe, going to pull it off the first or so week of
>> September. Once we
>> get everybody onboarded and trained up, we're using that moment to
>> sit down and write
>> up what we currently do, make changes to what we think now we
>> really should do, and get
>> those to the IESG and the public. Hopefully, you should see those
>> well before the next IETF
>> meeting.
>> ==[ snip ]==
>>
>> Regards,
>> Roman
>>
>> [1]
>> https://datatracker.ietf.org/meeting/120/materials/minutes-120-iet
>> f-202407250030-00
>>
>>
>>
