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
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 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 .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 ? 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. ) 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 ),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 .)
La mise en œuvre de ces nouveaux états dans le
Datatracker se fera suivant le cahier des charges
contenu dans le .
Une lecture intéressante sur le sujet de la vie des Internet-Drafts est « Guidelines to
Authors of Internet-Drafts ».