Mon blog

Comme toute organisation qui manipule de grandes quantités de documents, et des processus formalisés complexes, l'IETF a besoin de logiciels qui mettent en œuvre ces processus. Le principal outil est le Datatracker et ce RFC 6175 est le cahier des charges pour une nouvelle extension du Datatracker.

Le Datatracker sert entre autres à suivre l'état des Internet-Drafts. Il était traditionnellement très détaillé pour la phase d'évaluation à l'IESG de ces documents, et nettement moins précis pour les autres phases. Ce service était très réclamé depuis longtemps. Ce cahier des charges demande donc que le Datatracker soit mis à jour pour gérer les états décrits par le RFC 6174.

Quelques rappels, en section 2, pour les gens qui ne suivent pas l'évolution du vocabulaire IETF. Tous les Internet-Drafts ne sont pas forcément liés à un groupe de travail de l'IETF. Ceux qui le sont, parce qu'un groupe a décidé de les adopter, sont qualifiés de WG draft. Leur nom est du type draft-ietf-wgname-.... Ces drafts, et ceux qui sont candidats à l'adoption mais n'ont pas encore été adoptés, sont ensemble les associated with a WG. Dans le cas où ils ne sont pas encore adoptés, leur nom inclus l'acronyme du groupe de travail mais ne commence pas par draft-ietf. Enfin, tous les autres Internet-Drafts sont qualifiés d' « individuels ».

Les exigences générales sur le « nouveau » Datatracker figurent en section 3. Chacune est numérotée. La première, R-001, est que le Datatracker doit permettre aux présidents des groupes de travail de l'IETF de saisir directement l'état des I-D, en suivant les états décrits dans le RFC 6174. Parmi les autres exigences (consultez le RFC pour une liste complète), le fait que tout changement doit être estampillé, lié à une personne précise (R-007) et que la date et l'heure de ce changement soient affichées. Le Datatracker doit étendre la machine à états existante (illustrée en https://datatracker.ietf.org/images/state_diagram.gif), pas la remplacer (R-011). Et les présidents d'un groupe de travail doivent pouvoir agir sur l'état d'un I-D, indépendemment de son statut à l'IESG (R-012).

La section 4 est consacrée aux questions d'autorisation. En lecture, le Datatracker est accessible à tous (R-013), l'IETF tirant une grande fierté de son ouverture au public (contrairement à la majorité des SDO, qui travaillent derrière des portes closes). Mais en écriture, les personnes qui peuvent modifier l'état d'un I-D doivent d'abord s'authentifier auprès du Datatracker (et inutile de dire que l'IETF n'utilise pas Facebook Connect). La section 11 note d'ailleurs les conséquences que cela peut avoir en matière de sécurité.

Les présidents des groupes de travail doivent avoir la possibilité (section 4.2) de modifier l'état de tous les Internet-Drafts de leur groupe, en restant dans la liste d'états pré-définie (cf. RFC 6174 et voir aussi la section 5.1), peuvent désigner jusqu'à trois délégués pour les aider, etc. Une autre population intéressante est celle des pasteurs (sheperds, cf. RFC 4858). Ceux-ci (section 4.4) sont chargés de suivre un document particulier et doivent donc pouvoir déposer le write-up, le formulaire rempli qui indique à l'IESG les points importants du document (voir aussi la section 5.3). Au sommet de cette série de personnes privilégiées, se trouvent évidemment les directeurs de secteurs (Area Directors), qui couvrent chacun plusieurs groupes de travail et doivent également pouvoir mettre à jour l'état des documents (section 4.5).

Certains états des documents posent des problèmes particuliers et la section 6 les énumère. Ainsi, un document peut être garé (parked document, section 6.4) lorsqu'il a perdu son auteur. Le directeur de secteur a alors des pouvoirs supplémentaires, comme de le transférer à un autre groupe de travail. Plus triste, un document peut aussi mourir (dead document, section 6.5) lorsque tout travail le concernant a été abandonné. Là encore, le directeur peut le transférer.

Jusqu'ici, on a parlé des changements manuels, comme lorsque le président d'un groupe de travail met à jour l'état d'un I-D (Internet-Draft). Y a-t-il aussi des changements automatiques ? Oui, et la section 7 liste les cas où le Datatracker doit agir seul. Par exemple, si une nouvelle version d'un document a un nom qui commence par draft-ietf, le document devient automatiquement document d'un groupe de travail (avant, c'était juste une convention : désormais, cela fait partie des règles mises en œuvre automatiquement).

Quelles sont les informations qui doivent être affichées par le Datatracker ? Les sections 8 et 9 les définissent. Par exemple, le Datatracker doit garder trace de l'historique complet du document puisqu'il doit pouvoir le montrer à quiconque a les droits d'écriture (la foule anonyme n'a droit qu'à l'affichage de l'état actuel).