Mon blog

L'articulation compliquée entre l'IETF qui produit les normes TCP/IP et le RFC Editor qui les publie, n'a jamais cessé de faire couler de l'encre (ou d'agiter des électrons). Dans ce document, l'IAB décrit un modèle pour le RFC Editor, modèle où les fonctions de ce dernier sont éclatées en plusieurs fonctions logiques. Aujourd'hui effectuées par la même organisation, elles pourraient demain être réparties entre plusieurs groupes. Ce RFC était un premier essai (« version 1 ») et il a ensuite été remplacé par le RFC 6635.

Le document de référence actuel est le RFC 4844. Comme le rappelle la section 1, il décrit les tâches du RFC Editor de manière globale, comme si c'était forcément une seule entité (c'était, à l'origine, une seule personne, Jon Postel). La section 2 note que la tâche de RFC Editor est actuellement une partie de l'IASA et financée par son budget.

La section 3 s'attaque à la définition du rôle du RFC Editor sous forme de fonctions séparées. L'IAB voit quatre fonctions :

• Éditeur des RFC,
• Éditeur des contributions indépendantes,
• Producteur des RFC,
• Publieur des RFC.

Chaque section va ensuite détailler ces tâches.

L'Éditeur de la série des RFC (RFC Series Editor) est décrit en premier, en section 3.1. Il est responsable du travail à long terme, définir les principes qui assurent la pérennité des RFC, garder à jour les errata, développer le guide de style des RFC (ce qui inclus la délicate question du format), etc. Notre RFC décrit les compétences nécessaires, qui comprennent une expérience des RFC en tant qu'auteur.

L'Éditeur des contributions indépendantes (Independent Submission Editor) fait l'objet de la section 3.2. Les contributions indépendantes sont celles qui sont envoyées directement au RFC Editor, sans passer par l'IETF. Le RFC Editor doit donc jouer un rôle bien plus actif avec elles, notamment pour juger de leur valeur technique. Le responsable de cette tâche doit donc avoir une solide compétence technique et jouir d'une bonne réputation auprès des participants à l'IETF. (Le premier a été nommé en février 2010.) Son rôle est désormais décrit par le RFC 6548.

Le travail quotidien est, lui, assuré par le Producteur des RFC (RFC Production Center) dont parle la section 3.3. Il reçoit les documents bruts, les corrige, en discute avec les auteurs, s'arrange avec l'IANA pour l'allocation des numéros de protocoles, attribue le numéro au RFC, etc.

Les RFC n'étant publiés que sous forme numérique, il n'y a pas d'imprimeur mais le numérique a aussi ses exigences de publication et il faut donc un Publieur des RFC (RFC Publisher), détaillé en section 3.4. Celui-ci s'occupe de... publier, de mettre le RFC dans le dépôt où on les trouve tous, d'annoncer sa disponibilité, et de s'assurer que les RFC restent disponibles, parfois pendant de nombreuses années.

Chacune de ces fonctions pourra faire l'objet d'une attribution spécifique (à l'heure actuelle, elles sont toutes effectuées par le même groupe à l'ISI). L'annexe A décrit le mécanisme de sélection actuellement en cours.