Mon blog

Comme toute organisation humaine, l'IETF doit gérer le cas de personnes pénibles, qui font perdre du temps à tout le monde, mettent une mauvaise ambiance ou cherchent activement à perturber le travail commun. Ce RFC (qui remplace les RFC 3683 et RFC 3934) établit la politique de l'IETF vis-à-vis de ces gens : être patient mais pas trop.

Les principes de base de la gestion des abusifs sont les principes de l'IETF (RFC 3935 et RFC 7154). Il ne s'agit pas d'empêcher les désaccords (ils sont attendus et sains). L'IETF est une organisation très ouverte et ses participant·es sont divers·es. On recherche un consensus approximatif (RFC 7282) mais, bien sûr, s'opposer au consensus n'est pas en soi un problème. L'IETF n'est pas une religion. Mais certains vont « sortir des clous ». L'annexe B du RFC donne quelques exemples (messages hors-sujet sur un groupe, ton agressif, remise en cause permanente des décisions et une pratique que je ne connaissais pas, le sealioning). L'IETF devra réagir, en suivant ces lignes directrices :

• Avoir une politique qui soit cohérente et équitable. Elle doit s'appliquer uniquement sur la base du comportement de la personne et pas, par exemple, selon le nombre de RFC qu'elle a écrit, ni selon son ancienneté.
• Permettre des appels contre les décisions prises (le contrôle est une activité délicate et les décisions seront parfois difficiles).
• Essayer de respecter la vie privée tout en maintenant une certaine transparence (exemple de problème : les sanctions doivent-elles être publiques ?).
• Être flexible car il faudra pouvoir s'appliquer à des cas variés. (Notez la tension entre cet objectif et le premier cité…)

Le travail de contrôle reposera essentiellement sur l'équipe de contrôle (moderation team), décrite en section 2. Elle comportera au moins cinq personnes, nommées par l'IESG, qui devra essayer de respecter une certaine diversité. Ces personnes ne doivent pas être membres de l'IESG ou de l'IAB. La diversité souhaitée inclut celle des fuseaux horaires car l'équipe devra parfois réagir vite. L'IETF LLC, la structure administrative décrite dans le RFC 8711, se chargera de leur financer une formation.

Leur travail couvrira toutes les discussions publiques en ligne à l'IETF, qu'elles soient sur une liste de diffusion, un dépôt GitHub, etc. Le RFC distingue les administrateurs, qui gèrent un de ces lieux de discussion, de l'équipe de contrôle. Les administrateurs signalent les problèmes et appliquent les décisions de l'équipe de contrôle. Mais, évidemment, pour éviter de surcharger cette équipe, les administrateurs sont aussi censés gérer la plupart des problèmes localement. L'idée derrière l'équipe centrale (moderators) est d'avoir un groupe formé et qui pourra s'assurer d'une politique cohérente au niveau de l'IETF. Vu la taille de l'IETF, les contrôleurs ne pourront pas tout surveiller préventivement et dépendront donc beaucoup des signalements faits, par exemple par les administrateurs.

Vous ne l'avez peut-être pas noté plus haut mais le mot important est « publiques ». L'équipe de contrôle ne va pas gérer les communications privées. Par ailleurs, elle contrôle des comportements, pas le contenu (donc, pas la peine de lui demander de censurer telle ou telle partie d'un Internet-Draft). Quand au spam, il est effectivement un exemple de comportement perturbateur mais il y a déjà une politique à ce sujet.

Ce sera à l'équipe de contrôle de définir ses processus de fonctionnement et ses détails de politique, pour ce qui n'est pas déjà couvert dans ce RFC 9945. Tout cela devra évidemment être discuté au sein de l'IETF et, au bout du compte, approuvé par l'IESG et rendu public (mais pas forcément dans un RFC).

Qu'est-ce que pourra faire en pratique l'équipe de contrôle ? Le RFC donne quelques exemples (section 4) :

• Faire passer les messages d'une personne par un système d'approbation explicite (par défaut, l'IETF n'a pas de contrôle a priori),
• Engueuler quelqu'un, en privé ou en public,
• Supprimer complètement le droit d'écriture à une personne.

Et l'équipe de contrôle devra évidemment garder trace de ces actions, pour en rendre compte. Et des appels sont possibles (RFC 2026, sections 6.5.1 et 6.5.4).

Il y a d'autres fonctions dans l'IETF qui ont un rapport avec cette nécessité de contrôler les débordements de certains participants (section 5). C'est le cas de l'ombudsteam et de l'incarnation administrative de l'IETF, la LLC (notamment si le comportement de certains entraine des risques juridiques pour l'IETF). Il y a aussi plein d'autres RFC à lire, comme le RFC 7776, sur les mesures contre le harcèlement ou le RFC 9245, sur la gestion des listes de diffusion (rappelez-vous que l'équipe de contrôle ne sera pas limitée à ces listes).

Le RFC remarque à juste titre (section 6) que toute politique peut être utilisée de manière abusive, par exemple à des fins de censure. La section 6 revient sur les différentes décisions décrites par le RFC et comment elles contribuent à minimiser ce risque.

Notez que ce RFC s'applique à l'IETF uniquement, et pas aux autres organisations proches comme l'IRTF.

Enfin, l'annexe A explique les motivations derrière ce RFC et le pourquoi des différents choix. Malgré la quantité de RFC et de décisions documentées, il n'était pas toujours évident de reconnaitre ce qui était un comportement perturbateur. Et les processus existants étaient trop lents, en partie parce qu'ils supposaient que tout le monde était de bonne foi. D'où ce nouveau RFC qui explique comment un meilleur mécanisme va être défini.