Mon blog

Voici un nouveau RFC procédural, consacré à la gestion des Internet Drafts, ces brouillons de futurs RFC. L'IETF est structurée en groupes de travail (WG, pour Working Groups) et ces groupes doivent, comme leur nom l'indique, travailler. Mais pour produire quoi ? Des documents. L'IETF n'écrit pas de logiciels, ne fabrique pas de matériel, cette organisation de normalisation est entièrement vouée à produire des documents, les fameux RFC. Mais avant d'être un RFC, le document passe par le stade Internet Draft. D'où viennent les Internet Drafts des groupes de travail ? Comment sont-ils créés ?

Quand un groupe de travail développe un Internet Draft, il y a eu plusieurs points de départ possibles. Le groupe a pu partir d'une feuille blanche, le document ayant été rédigé dans le cadre du travail du groupe. Parfois, également, le document existait avant, et a été adopté par le groupe de travail. Des fois, lors de son adoption, le document était très avancé, presque prêt et, des fois, il méritait largement son nom de draft (brouillon). L'IETF se méfie (en théorie) des processus trop formalisés et les groupes de travail ont donc une grande latitude dans les choix. Si la charte du groupe de travail met des limites, ces limites laissent souvent bien des possibilités. (Les chartes des groupes de travail existants sont disponibles en ligne ; notez que beaucoup d'entre elles font référence à des Internet Drafts avec des formules du genre « le groupe partira du document draft-smith-foo-bar ».) Ce RFC n'ajoute pas de nouvelles règles (mon opinion personnelle est qu'il y en a déjà beaucoup, pour une organisation qui aime bien afficher son mépris des règles bureaucratiques) mais décrit les pratiques existantes. « Pragmatics over niceties »

D'abord, un point important (section 1.1), il y a draft et draft. N'importe qui peut publier un draft, et il y a effectivement très peu de formalités pour cela. La plupart des drafts ne sont donc pas des Working Group drafts. Ces drafts des groupes de travail sont des documents sous le contrôle de l'IETF (et pas d'un individu, même pas de leur auteur, ou des présidents du groupe de travail), et leur avancement vers la publication en RFC dépend donc du consensus approximatif (rough consensus) au sein du groupe dans son ensemble. Ce mécanisme de décision est décrit dans le Tao et de manière plus formelle dans la section 3.3 du RFC 2418.

On peut dire que le draft individuel représente la liberté quasi-totale alors que le draft de groupe de travail est une œuvre collective, représentant l'opinion du groupe. Résultat, le processus est parfois laborieux, voire excessivement frustrant, mais c'est nécessaire pour s'assurer que le document représente bien une vue collective et a donc plus de signification qu'un article publié sur un blog personnel. L'auteur du document a un rôle particulier mais, en théorie, pas de pouvoir de décision (bien sûr, être celui qui tient le clavier a quelques avantages lorsqu'il faut traduire en mots le consensus du groupe). Comme le dit le proverbe africain, « si tu veux voyager vite, pars seul, si tu veux voyager loin, pars en groupe ». Les règles précises pour ces drafts sont formalisées dans le RFC 2026 (notamment la section 2.2), la liste des points à vérifier, le RFC 2418 (notamment sa section 7.2) et enfin bien sûr le Tao.

On reconnait un draft de groupe de travail à son nom. Il est nommé draft-ietf-WGNAME-... où WGNAME est le nom du groupe. Au contraire, le draft individuel se nomme draft-LASTNAME-... où LASTNAME est le nom de l'auteur. Ainsi, au moment où j'écris (avril 2014), le draft draft-ietf-precis-framework est un document du groupe de travail precis (dont le nom apparait comme deuxième composant du nom du document) alors que draft-bortzmeyer-dns-qname-minimisation est, pour l'instant, un document individuel (avec mon nom en deuxième composant). Certains drafts individuels seront adoptés par un groupe de travail et deviendront alors des documents de groupe, en changeant de nom. Par exemple, comme on peut le voir sur le « DataTracker », le draft individuel draft-sheffer-uta-tls-attacks a été adopté par le groupe de travail UTA et est devenu le draft-ietf-uta-tls-attacks.

Maintenant, les détails. La section 2 couvre l'adoption d'un draft individuel par un groupe de travail. Rappelez-vous, il n'y a pas de règles formelles et générales sur les critères d'adoption, le groupe de travail doit prendre ses responsabilités. En pratique, notre RFC note que les critères importants sont :

• Mention explicite du draft dans la charte du groupe,
• Document qui coïncide avec le sujet du groupe, et ne demande pas de modification de la charte, ou alors très légère,
• Document de qualité, suffisamment clair et réaliste pour que, en l'utilisant comme base de travail, le groupe ait des chances d'aboutir à un RFC (l'IETF se méfie des groupes qui s'agitent pendant des années sans rien produire),
• Risques liés à l'appropriation intellectuelle,
• Et, bien sûr, soutien du groupe.

Rappelez-vous que les groupes fonctionnent par consensus approximatif. L'unanimité n'est pas nécessaire. D'autre part, le draft est un... brouillon. Il n'est pas exigé qu'il soit paré pour la publication, tout juste vérifie-t-on quelques détails pratiques. Et le groupe peut toujours adopter un document qui sera finalement abandonné : l'adoption ne garantit absolument pas la publication. On voit même parfois des drafts d'un groupe de travail redevenir finalement des documents individuels (cf. section 5.2).

Une fois la décision prise, les présidents (ils sont toujours deux) du groupe de travail doivent ensuite :

• Vérifier que le groupe est d'accord pour cette adoption (curieusement, ce point n'est pas mis en premier dans le RFC).
• Bien s'assurer que l'auteur comprend que le contrôle est transféré à l'IETF. Ce n'est plus lui qui décide du contenu du document (il y a eu quelques cas contentieux, par exemple où l'auteur demandait qu'on retire son nom, car il n'était plus d'accord, mais les plus gros problèmes surviennent lorsque le document était issu d'une entreprise privée, et décrivait une technologie que cette entreprise aurait voulu voir l'IETF adopter sans discussion).
• Vérifier si les requins de l'appropriation intellectuelle ont des brevets possibles sur cette technique (cf. RFC 6302).
• Respecter quelques règles procédurales comme l'annonce officielle de l'adoption sur la liste de diffusion du groupe, la notification du changement de nom aux gérants du DataTracker pour que les outils IETF gardent l'historique, etc.

La section 3 décrit le rôle des auteurs et rédacteurs (editors). Certaines personnes à l'IETF font la différence entre ces deux concepts (voir « RFC Editorial Guidelines and Procedures -- Author Overload » et la section 6.3 du RFC 2418), l'auteur étant vu comme mettant réellement du sien dans le document, formant de nouvelles idées, et le rédacteur comme étant un simple exécutant, quasiment passif, des volontés du groupe de travail. Mais notre RFC ne fait pas de différence, estimant qu'elle serait trop subjective. Auteurs et/ou rédacteurs sont choisis par les présidents du groupe de travail (rappelez-vous qu'une fois un document adopté, le contrôle passe à l'IETF) et ne sont pas forcément le ou les auteurs originaux. En pratique, toutefois, il est fréquent que l'auteur original continue après l'adoption.

La section 4 couvre la façon de traiter les documents existants. Un groupe de travail n'est pas forcé de prendre ces documents, de corriger deux ou trois fautes d'orthographe, et de les publier comme RFC. Bien au contraire. L'IETF, contrairement à certaines SDO, ne se contente pas de mettre un coup de tampon approbateur sur des documents qui arrivent tout cuits. Les documents existants peuvent être considérés comme :

• Des idées, dont on peut s'inspirer, mais sans plus,
• Un mécanisme raisonnable dans son principe mais dont de nombreux points vont devoir être traités, révisés, détaillés,
• Une description d'un bon système, qui a juste besoin de quelques aménagements,
• Une technique déjà déployée, et où tout changement doit donc être abordé avec prudence, afin de ne pas remettre en cause la base installée.

Bref, la palette est très large. Tout document extérieur adopté par un groupe de travail ne sera pas traité de la même façon. Certains documents arrivent à l'IETF après des années d'usage de la technologie qu'ils décrivent, d'autres sont des idées purement théoriques, et encore, où l'analyse théorique est souvent sommaire.

Il y a aussi quelques points divers traités dans la section 5. D'abord, entre les drafts purement individuels et ceux d'un groupe de travail, il y a aussi des drafts individuels mais qui sont sous le parapluie d'un groupe de travail (voir le document « Guidance on Area Director Sponsoring of Documents »). On les reconnait à leur nom draft-LASTNAME-WGNAME-.... C'est rare, mais cela arrive. (Notez aussi qu'il n'existe pas de police des drafts, donc certains auteurs choisissent parfois des noms qui violent ces conventions.)

Autre cas spécifique, celui de drafts différents sur le même sujet, par exemple deux protocoles jouant le même rôle, chacun d'entre eux soutenu par une partie du groupe de travail. Un groupe n'est pas obligé de trancher. Les différences entre les deux propositions peuvent refléter des choix fondamentaux, chaque draft ayant ses mérites propres. Le groupe de travail peut suggérer une fusion, mais ce n'est pas obligatoire. Dans le domaine technique, la fusion de deux bons systèmes peut parfaitement donner une horreur, ce que le RFC illustre par l'histoire du sous-marin et de l'hélicoptère : les sous-marins sont utiles et bien adaptés à leur tâche. Les hélicoptères aussi. Mais tenter de concevoir un engin qui aurait les caractéristiques des deux produirait probablement une machine inadaptée aux deux rôles. (L'histoire est originellement due à Marshall Rose.)

Le problème des deux drafts concurrents est d'autant plus sensible si un des deux drafts arrive après l'autre : les auteurs du premier peuvent mal prendre cette « intrusion ». En même temps, l'IETF travaille par écrit et encourage fortement l'expression des idées sous forme d'un draft, pour obliger les concepteurs à raffiner leurs idées, à ne pas se contenter d'un résumé dans un message de deux paragraphes. Donc, ce genre de concurrence continuera à se produire.