Mon blog

Le travail de normalisation au sein de l'IETF se fait dans des groupes de travail (Working Groups) dont la constitution nécessite un grand formalisme. L'écart est tel entre des discussions informelles dans un bistrot et la création d'un groupe de travail que des états intermédiaires se sont développés comme les BoF (Birds of a Feather, d'une expression anglophone intraduisible). Les BoF sont actives depuis de nombreuses années et le premier RFC qui les avait mentionnées était le RFC 2418, dans sa section 2.4.

L'idée est qu'un groupe de gens qui estiment que tel travail de normalisation peut et doit être fait vont se rassembler et approfondir leurs accords, avant de demander à l'IESG la création d'un vrai groupe de travail. Alors que les BoF étaient au début une réponse à la formalisation de plus en plus grande des groupes de travail (qui n'ont plus rien du rassemblement spontané et informel des débuts), les voici à leur tour normalisées. Ce RFC est bâti sur l'excellent exposé que fait Thomas Narten à chaque réunion IETF, à l'usage des débutants dans cet organisme.

Pour illustrer le RFC, je prendrais des exemples de la seule BoF où j'étais impliqué, celle sur le langage Cosmogol à l'IETF de Prague en mars 2007.

La section 1 commence par « Pourquoi une BoF ? » Il peut y avoir des tas de raisons, par exemple une présentation sur un problème particulier, qui ne rentre dans aucun groupe de travail précis. Mais la motivation la plus fréquente est la création future d'un groupe de travail, c'était clairement le but de la BoF sur Cosmogol (qui a échoué) ou de celle d'Alto à Dublin en juillet 2008, qui, elle, a finalement réussi.

L'IETF est très focalisée sur le résultat : le but n'est pas de parler, quoique ce soit sympa, c'est de produire des normes. Le RFC recommande donc fortement de s'assurer que le problème est bien défini, très focalisé, est soluble (« supprimer le spam » n'est donc pas un bon problème), que l'IETF est le bon endroit pour le traiter, et que des gens sont prêts à travailler concrètement en ce sens (car il existe beaucoup d'idées qui rassemblent un large soutien... mais peu de travailleurs).

Alors, quelles sont les étapes nécessaires ? La section 2 les détaille :

• Le groupe fondateur (le terme officiel est design team) se rencontre (physiquement ou bien en ligne) pour discuter le problème. Il cherche s'il n'existe pas déjà un groupe de travail sur ce sujet. Il discute avec des groupes existants. Si aucun groupe de travail ne correspond mais qu'il existe une zone (regroupement de plusieurs groupes) sur ce sujet, il en parle sur la liste de diffusion de la zone, etc. Et, surtout, il produit les premiers Internet-Drafts, pour aider à la discussion. (Pour Cosmogol, le groupe fondateur se limitait à une personne, ce qui était son principal handicap. Le premier Internet-Draft, draft-bortzmeyer-language-state-machines a été publié en septembre 2006.)
• Le groupe va ensuite approcher les directeurs de la zone envisagée, pour leur proposer la BoF. (Pour Cosmogol, la zone était l'Application Area et c'est Lisa Dusseault qui a géré la discussion du côté de l'IESG.)
• Le projet est alors rendu public et une liste de diffusion créée. (Pour Cosmogol, cela avait été fait le 27 décembre 2006.) Les inscriptions à cette liste et les discussions qui suivent permettent de jauger de l'intérêt du travail.
• Enfin, si le groupe fondateur n'est pas encore dérouragé, il peut faire une demande formelle d'une BoF. Si acceptée, la BoF peut alors être convoquée.
• Il reste à profiter du temps qui reste avant la prochaine réunion physique de l'IETF pour continuer la discussion, commencer à parler de la charte du futur groupe de travail, préparer la liste des questions qui devront être résolues par la BoF (« Avons-nous besoin d'un langage formel pour décrire les machines à états ? » « Si oui, faut-il le normaliser ? » « Si oui, peut-on utiliser les langages existants ? » « Est-ce que Cosmogol est un bon candidat ? »).

Les projets de BoF échouent souvent, non pas sur les solutions au problème, mais sur la définition du problème. C'est contre cet écueil que met en garde la section 3. Ainsi, le groupe de travail MARID, qui a connu une vie agitée et une fin brutale, était censé travailler uniquement sur l'authentification des serveurs de messagerie, un problème bien délimité, mais beaucoup de gens s'obstinaient à essayer de le tirer vers une solution générale au problème du spam, un bon moyen de n'aller nulle part, vue la taille et la complexité du problème.

Le risque est d'autant plus élevé que les ingénieurs ont une nette tendance à préférer les discussions sur les solutions aux discussions sur la définition du problème ! Ces discussions prématurées sont souvent une cause de perte de temps. Ainsi, alors même qu'une bonne partie de l'IETF n'était pas convaincue de la nécessité d'avoir un langage standard pour les machines à état, la plupart des messages sur la liste Cosmogol portaient sur des points subtils de l'ABNF du langage ou bien sur la question de savoir s'il fallait autoriser Unicode dans les identificateurs.

Enfin, si on a passé tous ces obstacles, la BoF elle-même commence (section 4). Parfois, c'est un échec et il n'y a que le groupe fondateur dans la salle. Parfois, c'est un succès quantitatif, comme les Bof d'Alto ou de Cosmogol où plus de cent personnes se serraient dans une salle trop petite. Comme les participants à l'IETF adorent discuter, le RFC conseille de rester focalisé : « Quel est le but de la BoF ? » « Qu'attend t-on comme résultat ? »

Un bon compte-rendu de la BoF sur Cosmogol (officiellement nommée Finite State Machines BOF) peut être lu sur le blog de Barry Leiba.

Après, on peut passer à la suite : compte-tenu de ce qui s'est passé à la BoF, quelle est l'étape suivante ? Si la BoF a été un succès, et si l'IESG a semblé favorable, on peut faire une demande formelle de création d'un groupe de travail. (Pour Cosmogol, l'IESG avait clairement manifesté que la création du groupe semblait lointaine, vu le manque de consensus sur le problème de base.)

Comme on apprend davantage des échecs que des réussites, la section 6 décrit les pièges les plus fréquemment observés :

• S'y prendre au dernier moment (les débutants sous-estiment la lenteur de toute SDO),
• Trop parler des solutions, avant d'être sûr d'avoir bien compris le problème,
• Mauvaise communication avec les potentiels participants. Les membres du groupe fondateur sont tellement pris par leur projet qu'ils en oublient d'expliquer clairement aux non-membres pourquoi le projet est nécessaire et pourquoi il faut venir à la BoF.

On le voit, créer une BoF est compliqué et long et ne réussit pas toujours. D'où la demande pour des réunions plus informelles comme les Bar BoF où les participants se rencontrent au bar. Trois ans après, un RFC a formalisé les Bar BoF.... (RFC 6771)