Groupe de travail Réseau	M. Rose, Dover Beach Consulting, Inc.	
Request for Comments : 3683	mars 2004	
BCP : 83		
Catégorie : Bonnes pratiques actuelles	Traduction Claude Brière de L'Isle	

Pratique pour la révocation des droits d'envoi 
aux listes de diffusion de l'IETF

Statut du présent mémoire
Le présent document spécifie les bonnes pratiques actuelles de l’Internet pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright
Copyright (C) The Internet Society (2004).

Résumé
Tous les organismes autonomes ont des moyens de gérer les interactions de leurs participants. L'IETF utilise un processus fondé sur le consensus pour développer des normes de communications informatiques d'une façon ouverte. Une partie importante de ce processus fondé sur le consensus est l'utilisation intensive de listes de diffusion pour la discussion. Il est vrai que dans un petit nombre de cas, un participant s'engage dans une attaque de "déni de service" pour perturber le processus de construction du consensus. Malheureusement, comme ces attaques de mauvaise foi deviennent plus fréquentes, l'IETF a besoin d'établir une pratique qui réduise ou élimine ces attaques. Le présent mémoire recommande qu'une telle pratique soit utilisée par l'IETF.

Table des Matières
1. Introduction	1
2. Pratique de la révocation	2
3. Remerciements	3
4. Considérations sur la sécurité	3
5. Références	3
Adresse de l'auteur	4
Déclaration complète de droits de reproduction	4

1.	Introduction

Tous les organismes autonomes ont des moyens pour gérer la portée des interactions des participants. Par exemple, les assemblées délibératives emploient souvent des "règles d'ordre" pour déterminer qui a la parole, quand, et pour combien de temps. De façon similaire, il y a un accord général dans les sociétés dites "libérales" sur le fait que le droit de parler librement n'est pas absolu, par exemple, le discours politique a plus de latitude que le discours commercial, et certaines formes de discours (par exemple, une attaque outrancière ou une incitation à la violence) sont considérées comme inacceptables.

L'IETF utilise un processus fondé sur le consensus pour développer des normes de communications informatiques d'une façon ouverte. Une part importante de ce processus fondé sur le consensus est l'utilisation intensive de listes de diffusion pour la discussion. À la différence de nombreuses autres organisations, tout le monde peut envoyer des messages sur ces listes de diffusion de l'IETF, et ce faisant, participer au processus de l'IETF. Historiquement, cette approche a très bien fonctionné dans l'IETF, car elle nourrit la participation d'une large gamme de membres. (Pour les besoins du présent mémoire, le terme de "liste de diffusion de l'IETF" se réfère à toute liste de diffusion qui fonctionne sous les auspices de l'IETF, comme la liste de discussion générale de l'IETF, ou d'un groupe de travail, ou la liste de diffusion d'une équipe de conception.)

On a remarqué que dans un petit nombre de cas, un participant s'engage dans ce qui revient à une "attaque de déni de service" pour perturber le processus fondé sur le consensus. Typiquement, ces attaques sont faites en envoyant de façon répétée des messages qui sont hors sujet, incendiaires, ou autrement contre productifs. À l'opposé, un désaccord de bonne foi est une partie saine du processus fondé sur le consensus.

Par exemple, si un groupe de travail n'arrive pas à réaliser le consensus, c'est un résultat acceptable, bien que malheureux ; cependant, si ce groupe de travail échoue à réaliser le consensus parce qu'il est continuellement perturbé, la perturbation constitue un abus du processus fondé sur le consensus. Les interactions de ce type sont fondamentalement différentes de "la seule voix discordante" dans laquelle un participant exprime une position qui est discutée mais ne réalise pas le consensus. En d'autres termes, la mauvaise foi d'un individu ne devrait pas tromper la bonne volonté de la communauté.

Des lignes directrices ont été développées pour traiter les comportements abusifs (voir le paragraphe 3.2 de la [RFC2418] et la [RFC3005]). Bien qu'ils ne soient pas exhaustifs, des exemples d'envois abusifs et d'envois par ailleurs inappropriés aux listes de diffusion de l'IETF incluent :
o	des messages électroniques en masse non sollicités ;
o	des discussions de sujets sans relation avec la politique, les réunions, les activités, ou des sujets techniques de l'IETF ;
o	des commentaires non professionnels, sans considération du sujet général ; 
o	des annonces de conférences, événements, ou activités qui ne sont pas patronnées ou soutenues par la Société Internet ou l'IETF.

En pratique, l'application de ces lignes directrices a inclus la suspension temporaire des droits d'envoi à une liste de diffusion spécifique. Si nécessaire, la durée de la suspension a été augmentée à chaque suspension successive. Dans de nombreux cas, l'application de ces lignes directrices va produire la modification de comportement désirée. Cependant, lorsque ces lignes directrices échouent à produire la modification de comportement désirée, des mesures plus drastiques devraient être disponibles pour réduire ou éliminer l'impact de ces attaques contre le processus de l'IETF.

Le présent document décrit une telle mesure drastique.

2.	Pratique de la révocation

Prière de se référer à la [RFC2119] pour la signification des mots en majuscules dans cette section.

Au titre de ses activités, le groupe de pilotage de l'ingénierie de l'Internet (IESG, Internet Engineering Steering Group) prend des décisions sur les "actions". Normalement, une action se réfère à la publication d'un document sur la voie de la normalisation, au mandat d'un groupe de travail, et ainsi de suite. Le présent mémoire recommande que l'IESG entreprenne aussi un nouveau type d'action, appelée une PR-action (action de "droits d'envoi").

Une PR-action identifie un ou plusieurs individus, citant des messages envoyés par ces individus à une liste de diffusion de l'IETF, qui apparaissent comme abusifs par rapport au processus fondé sur le consensus. Si c'est approuvé par l'IESG, alors :
o	les personnes identifiées par la PR-action ont leurs droits d'envoi à cette liste de diffusion de l'IETF supprimés ; 
o	les personnes chargées de la maintenance de toute liste de diffusion de l'IETF peuvent, à leur discrétion, supprimer aussi les droits d'envoi à cette liste de diffusion de l'IETF.

Une fois prise, cette action reste en vigueur jusqu'à ce qu'elle soit explicitement annulée et DEVRAIT rester en vigueur pendant au moins un an.

Un an après l'approbation de la PR-action, une nouvelle PR-action PEUT être introduite qui restaure les droits d'envoi pour cet individu. L'IESG DEVRAIT considérer la fréquence des demandes d'annulation lorsque il évalue une nouvelle PR-action. Si les droits d'envoi sont restaurés, il appartient à l'individu de contacter les gestionnaires des listes de diffusion pour que ses droits soient restaurés.

Que la PR-action révoque ou restaure les droits d'envoi, l'IESG suit le même algorithme qu'avec ses autres actions :
1.	elle est introduite par un directeur de zone de l'IESG qui, avant de le faire, peut choisir d'informer les parties intéressées ;
2.	elle est publiée comme un dernier appel de l'IESG sur la liste de discussion générale de l'IETF ;
3.	elle est discutée par la communauté ;
4.	elle est discutée par l'IESG ; et finalement,
5.	en utilisant le processus usuel fondé sur le consensus, elle est décidée par l'IESG.

Bien sûr, comme pour toutes les actions de l'IESG, le processus d'appel mentionné dans la [RFC2026] peut être invoqué pour contester une PR-action approuvée par l'IESG.

Les groupes de travail DEVRAIENT s'assurer que leur liste de diffusion associée est gérable. Par exemple, certains peuvent essayer de circonvenir la révocation de leurs droits d'envoi en changeant leurs adresses de messagerie électronique ; en conséquence, il devrait être possible d'interdire la nouvelle adresse de messagerie.

Finalement, on notera que la portée d'une PR-action traite seulement des droits d'envoi. En cohérence avec le dernier alinéa du paragraphe 3.2 de la [RFC2418], aucune action ne peut être entreprise pour empêcher des individus de recevoir des messages envoyés sur une liste de diffusion.

3.	Remerciements

L'auteur remercie chaleureusement de leurs contributions Brian Carpenter, Jim Galvin, Jeff Haas, Ted Hardie, Russ Housley, Thomas Narten, Jon Peterson, Margaret Wasserman, et Bert Wijnen.

4.	Considérations sur la sécurité

Le présent mémoire traite des affaires de processus, pas de protocoles.

Une personne raisonnable peut noter que ce mémoire décrit un mécanisme pour étouffer les attaques actives de déni de service contre le processus fondé sur le consensus utilisé par l'IETF.

5.	Références

[RFC2026]	S. Bradner, "Le processus de normalisation de l'Internet -- Révision 3", (BCP0009) octobre 1996. (Remplace RFC1602, RFC1871) (MàJ par RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378, RFC6410)

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC2418]	S. Bradner, "Lignes directrices et procédures pour les groupes de travail de l'IETF", septembre 1998. (MàJ par RFC3934) (BCP0025) 

[RFC3005]	S. Harris, "Charte de la liste de diffusion de l'IETF", novembre 2000. (BCP0045)  

Appendice A	Questions & réponses
Question : Un an n'est-il pas trop long ?
Réponse : Non. Une PR-action initiale n'est pas prise à la légère. Elle n'est approuvée qu'après une période de considération et un examen de la communauté substantiels. Si une PR-action est approuvée, cela indique qu'une situation sérieuse s'est produite.

Question : Pourquoi ne pas exiger une PR-action par liste de diffusion de l'IETF ?
Réponse : Faire ainsi permettrait une série prolongée d'attaques de déni de service. Si quelqu'un se conduit mal sur une liste de diffusion de l'IETF, mais bien sur une autre, le gérant de la seconde liste de diffusion de l'IETF n'a pas besoin de révoquer les droits d'envoi. Cependant, le scénario le plus vraisemblable est que quelqu'un qui se conduit mal sur une liste de diffusion de l'IETF ne veut pas bien se conduire sur toutes les liste de diffusion de l'IETF.

Question : L'initiation d'une PR-action devrait elle venir de l'extérieur de l'IESG ?
Réponse : Informellement, certainement ; formellement, non. Dans le processus fondé sur le consensus de l'IETF, les actions de l'IESG sont toujours formellement initiées par un directeur de zone de l'IESG. En pratique, la motivation pour qu'un membre de l'IESG initie une action vient presque toujours de l'extérieur de l'IESG. Par exemple, quand un groupe de travail arrive à un consensus sur un document, le président du groupe de travail informe le directeur de zone pertinent que le document est prêt pour que le directeur de zone l'examine pour une action de document. Dans le cas de ce document ci -- une soumission individuelle de l'IETF – l'auteur va faire circuler de façon itérative le document pour une large discussion et faire des révisions. À un certain moment, l'auteur va contacter un directeur de zone et demander une action de document pour publier ce document comme bonne pratiques actuelles (BCP, Best Current Practice).

Question : Est ce de la censure ?
Réponse : Seulement si on croit à l'anarchie. Ce qui est important est que les règles qui entourent les PR-actions affichent les mêmes propriétés qu'utilisées par le reste du processus fondé sur le consensus.

Question : Allons ! c'est du fascisme.
Réponse : Non, je suis un libertaire. Franchement, je préfèrerais que les gens se comportent raisonnablement et agissent de bonne foi. Depuis mon premier engagement auprès de l'IETF (dans GADS, vers 1983) chacun comprend qu'un comportement raisonnable est une bonne chose. Après 20 années, j'ai le regret de vous informer que cette étape est inévitable.

Adresse de l'auteur

Marshall T. Rose
Dover Beach Consulting, Inc.
POB 255268
Sacramento, CA  95865-5268
US
téléphone : +1 916 483 8878
mél : mrose@dbc.mtview.ca.us 

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2004)

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations qui y sont contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY, l’IETF TRUST et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement
Le financement de la fonction d'édition des RFC est actuellement assuré par la Internet Society.