Mon blog

Le processus de production de normes au sein de l'IETF était historiquement informel et peu documenté. Petit à petit, il s'est formalisé (voire ossifié) et a même reçu l'aide de logiciels permettant de suivre l'avancement des travaux. Ce RFC de processus décrit des nouveaux états que peut avoir un document en cours de discussion à l'IETF.

Une des particularités de l'IETF est son ouverture. Tout le monde doit pouvoir suivre l'état d'avancement des travaux, via l'Internet. C'est ce que permet par exemple le Datatracker de l'IETF qui donne accès à l'état (en février 2011) du document sur la syntaxe des TLD (apparemment abandonné, et tant mieux), à celui de la documentation de l'AS 112 (adopté par un groupe, mais perdu dans les sables bureaucratiques depuis très longtemps), à celui sur l'enregistrement DNS CERT (pas adopté par un groupe de travail), ou à celui sur le protocole LISP (en plein développement par un groupe de travail).

Les informations affichées par le Datatracker n'étaient pas toutes documentées et certaines, non actuellement affichées, pourraient être nécessaires. Ce RFC 6174 documente donc les états possibles des documents.

Le Datatracker gère bien d'autres choses que les documents, puisqu'il donne aussi accès aux revendications d'appropriation intellectuelle, et à d'autres aspects de la vie de l'IETF. Concernant le document, la version du Datatracker en service fin 2010 ne permettait de suivre que les documents présentés à l'IESG pour évaluation. Avant cela, il ne savait pratiquement d'un document que le fait qu'il soit Active (en cours de discussion) ou Expired (les Internet-Drafts ont une durée de validité de six mois). Or le processus (décrit dans le RFC 8729 est bien plus riche.

Comme le rappelle la section 2 de notre RFC, un Internet-Draft peut être complètement individuel ou bien être un Working Group I-D si un groupe de travail IETF a décidé de l'adopter et de travailler sur ce document. Dans ce cas, sa vie au sein du groupe passe par plusieurs stades qui étaient ignorés du Datatracker.

La section 3 résume en effet l'état du Datatracker fin 2010. Si ce dernier connaissait tous les détails de l'évaluation à l'IESG, la vie du document avant son passage devant cet aréopage était nettement moins détaillé, le Datatracker ne prenant en compte que la disponibilité du document. La section 3.1 donne une liste complète. Celle-ci inclut, comme vu plus haut, Active et Expired, mais aussi des états comme Replaces et Replaced-by qui indique le remplacement d'un Internet-Draft par un autre, équivalent. Cela se produit typiquement lors de l'adoption d'un draft par un groupe de travail. Si le document était nommé draft-authorname-topic-nn, il devient alors draft-ietf-wgname-topic-00. À noter qu'il n'existe pas de moyen automatique pour identifier ce remplacement (les Internet-Drafts n'ont pas de métadonnées structurées), le président du groupe de travail doit l'indiquer explicitement.

Une fois le document terminé par le groupe de travail, il passe à l'IESG pour évaluation. Cette phase est celle qui a suscité le plus de formalisation et celle-ci est décrite dans la section 3.2 (avec l'intégralité des états dans l'annexe A). Un Internet-Draft peut ainsi être, entre autres :

• Publication requested, le premier stade, suivant les procédures de la section 7.5 du RFC 2418.
• AD evaluation qui indique qu'un AD (un Area Director, la personne coresponsable d'une zone de travail de l'IESG comme le routage, la sécurité, les applications) est en train d'évaluer le document.
• IESG evaluation qui indique que le document est désormais évalué par toute l'IESG, c'est-à-dire par tous les AD. Chacun peut émettre une objection bloquante, connue sous le nom (fort mal choisi) de DISCUSS.

Quels sont les nouveux états possibles pour un document, créé par ce RFC 6174 ? La section 4 les détaille et s'appuie pour cela sur une machine à états (figure 1). Ils sont déjà mis en œuvre dans le Datatracker et se trouvent simplement documentés ici, par exemple (ce n'est pas une liste complète) :

• Call for adoption quand un document est encore individuel mais que son auteur a demandé qu'un groupe de travail l'adopte comme document de travail officiel du groupe,
• Adopted, une fois que c'est fait ; le document prendra alors un nom du genre draft-ietf-workingroupname-topic-00,
• Working Group document une fois que le travail du groupe a effectivement commencé,
• Working Group Last Call ; le sigle WGLC apparît souvent dans les listes IETF car cet état est une partie importante (quoique optionnelle, cf. RFC 2418) du folklore de cette organisation. C'est le dernier moment où le groupe peut donner son avis avant que le document, transmis à l'IESG, ne lui échappe.
• Working Group consensus, waiting for write-up, qui indique que le document fait l'objet d'un large consensus dans le groupe, et qu'il a juste besoin d'un write-up, le formulaire qui accompagne tout envoi à l'IESG et qui explique à celle-ci les points importants (comme l'existence de mises en œuvre, l'état effectif du consensus, les menaces d'appel, etc, voir RFC 4858),
• Submitted to IESG, lorsque le travail du groupe est fini,

Outre ces états, qui sont mutuellement exclusifs, le document peut porter un certain nombre d'étiquettes indiquant des points importants du processus, parmi lesquelles :

• Awaiting Expert Review/Resolution of Issues Raised qui indique qu'un examen du document par un expert du domaine est en cours (de tels examens existent, par exemple, pour toutes les MIB, qui sont vérifiées par un spécialiste ès-MIB),
• Waiting for Referencing Document, le document dépend d'un autre document, pas encore prêt,
• Revised I-D Needed - Issue raised by WGLC, lorsque le dernier appel à commentaires dans le groupe de travail a suscité des problèmes suffisamment sérieux pour justifier un nouvel ID (Internet-Draft).

Enfin, un autre champ est spécifié, en section 5. Tout document doit avoir un « niveau de normalisation visé » qui indique si le groupe de travail veut voir le futur RFC sur le chemin des normes, ou simplement « Pour information » ou encore purement « Expérimental ». (Ces niveaux sont expliqués dans le RFC 2026.)

La mise en œuvre de ces nouveaux états dans le Datatracker se fera suivant le cahier des charges contenu dans le RFC 6175.

Une lecture intéressante sur le sujet de la vie des Internet-Drafts est « Guidelines to Authors of Internet-Drafts ».