Mon blog

Une des particularités de l'IETF est son extrême ouverture. Tout le monde peut suivre le travail en cours, les documents de travail (les Internet Drafts) sont publiquement accessibles, l'état de chaque document dans le processus de publication peut être suivi sur le Web. Bref, sans avoir à se ruiner en déplacements physiques, le participant à l'IETF a accès à tout ce qu'il faut. Mais ce système a aussi ses insuffisances, notamment parce qu'il ne permet pas d'accès personnalisé et que seuls certains participants ont un accès en écriture. Ce RFC est donc le cahier des charges d'un nouveau système de suivi des Internet Drafts, système qui a finalement été déployé début juillet 2012.

Le système de suivi du travail de l'IETF repose sur un ensemble d'outils non-officiels maintenus par des volontaires, http://tools.ietf.org/, et par un site officiel de suivi, le « Datatracker » (http://datatracker.ietf.org/. Le Datatracker permet de s'identifier, pour certaines actions, mais cette possibilité n'était pas ouverte aux participants ordinaires, seulement à ceux chargés d'une tâche comme le pilotage d'un groupe de travail. (Notez que « participant IETF » = « public » puisque l'IETF n'a pas d'adhesion formelle, tout le monde en est membre dès qu'il participe, cf. section 1.3.)

Le Datatracker donne accès à plein d'informations sur les documents en cours (la section 1 résume les possibilités de l'actuel Datatracker). Prenons l'exemple de l'Internet Draft que demandait l'ICANN sur la syntaxe des noms de TLD, draft-liman-tld-names. On peut connaître son état en visitant http://datatracker.ietf.org/doc/draft-liman-tld-names/ : au 23 juin 2011, la version actuelle est la n° 5, datant du 12 avril, et il est en état I-D Exists, qui est l'état normal de tout Internet Draft. Il n'est donc pas en vue d'une publication comme RFC, juste en discussion. Si on veut suivre les évolutions du document, nul besoin de tout relire (comme c'est le cas dans d'autres organisations, où les diff ne sont pas fournies lors de la sortie d'un nouveau document), le Datatracker est serviable. Voici les différences entre les versions 4 et 5 : http://tools.ietf.org/rfcdiff?url1=draft-liman-tld-names-04&difftype=--html&submit=Go!&url2=draft-liman-tld-names-05 (dans ce cas précis, elles étaient purement administratives).

Si je m'intéresse plutôt au document sur le protocole de résolution de noms d'Apple appelé (bien à tort) Multicast DNS, je trouve l'information en http://datatracker.ietf.org/doc/draft-cheshire-dnsext-multicastdns/. Le document (actuellement en version 14) est approuvé par l'IESG mais a besoin d'une nouvelle version. Les opinions des membres de l'IESG sont accessibles en http://datatracker.ietf.org/doc/draft-cheshire-dnsext-multicastdns/ballot/ (Discuss signifiant une objection.).

Ce niveau de transparence est bien au delà de ce que font les autres SDO comme l'UIT ou l'AFNOR où tout le travail est fait derrière des portes closes, pour éviter que le public n'y participe. Mais on peut encore faire mieux.

Par exemple (section 1.1), on pourrait imaginer qu'un utilisateur veuille s'identifier pour retrouver les informations sur la liste des Internet Drafts qu'il suit, liste déterminée manuellement ou via une recherche. Il peut aussi vouloir recevoir une notification si une nouvelle version d'un de ces documents apparait.

La section 2 décrit plus précisement les exigences du nouveau Datatracker :

• Possibilité de se créer un compte automatiquement (et pas manuellement sur demande, comme aujourd'hui, ce qui n'est pas très 2.0), et ses propres listes de documents à suivre,
• Possibilité de modifier l'affichage dans le Datatracker (par exemple l'ordre de présentation des documents, la liste des attributs affichés, etc),
• Gestion de grandes listes (des dizaines de documents suivis),
• Définition des listes par des attributs comme « Tous les Internet Drafts du groupe de travail XXX », « Tous ls Internet Drafts écrits par Machin », « Tous les Internet Drafts qui citent le RFC yyyy », etc,
• Publication sous forme de flux Atom, notification par courrier, peut-être demain notification des changements via XMPP.

D'autres idées, dont la mise en œuvre n'est pas requise pour la première phase, figurent dans les annexes A et B. Par exemple, suivi des changements dans les registres IANA (ça, cela me serait très utile).

Le cahier des charges est donc fini, il ne restait plus que le développement et le déploiement, qui a été finalisé le 3 juillet 2012. Tout le monde peut désormais en bénéficier.