Mon blog

Les RFC les plus connus sont ceux produits directement par l'IETF. Ils subissent alors tous un examen par l'IESG, garante de leur qualité et de leur cohérence. On l'ignore souvent mais ce n'est pas le cas de tous les RFC. Certains peuvent être soumis directement au RFC editor (Independent stream), d'autres soumis par d'autres organisations (comme l'IRTF). Que doit faire l'IESG avec eux ?

Le RFC 3932 répondait à cette question. Depuis le RFC 4844, qui formalise les différentes voies (streams) de soumission d'un RFC, il fallait le mettre à jour, ce qui a pris beaucoup de temps, entrainant le blocage d'un grand nombre de RFC indépendants, techniquement au point mais ne pouvant pas être publiés car on ignorait comment les gérer administrativement.

Deux des quatre voies sont traitées dans notre RFC 5742 : celle de l'IRTF et la voie indépendante, celle des documents soumis par des individus. Lorsqu'un document n'est pas passé par l'IETF, il n'a pas forcément été examiné sur les points où le protocole décrit peut causer des problèmes : sécurité, contrôle de congestion, mauvaise interaction avec les protocoles existants (section 1). L'IETF n'assume donc aucune responsabilité pour ces RFC indépendants.

Par contre, ils étaient traditionnellement (RFC 2026, section 4.2.3, puis RFC 3710) examinés par l'IESG. C'était un véritable examen, avec discussion des points techniques avec les auteurs, aller-retour, et discussions qui prenaient des ressources à l'IESG et retardaient sérieusement la publication du RFC. L'IESG avait décidé en mars 2004 de passer à une procédure plus légère (RFC 3932) où l'IESG vérifiait surtout qu'il n'y avait pas de conflit avec un travail en cours à l'IETF. Les commentaires de fond étaient envoyés au RFC editor qui les traitait comme n'importe quel autre commentaire. Quant aux documents de l'IRTF, ils étaient traités, soit comme venant de l'IAB, soit comme soumissions individuelles (ils ont maintenant leur propre voie, décrite dans le RFC 5743).

Notre RFC 5742 décrit la procédure qui est désormais suivie lorsque le RFC editor ou l'IRTF demande un examen plus complet à l'IESG (voir aussi le RFC 4846, qui détaille la voie indépendante).

Quels sont les changements par rapport au RFC 3932 ? La section 1.1 les résume :

• Nouvel en-tête pour les RFC, indiquant explicitement la voie empruntée (RFC 5741, depuis remplacé par le RFC 7841),
• Mécanisme de résolution de conflits si l'IESG demande l'ajout d'une note au RFC et que cette note soulève des objections. L'insertion de cette note était obligatoire auparavant (RFC 3932, section 4).

Les détails de l'examen par l'IESG sont désormais dans la section 3. Après étude du document, l'IESG peut décider, au choix :

• Qu'il n'y a pas de conflit entre ce document et le travail de l'IETF,
• Qu'il y a une relation avec le travail d'un groupe de l'IETF, sans que cela empêche la publication du document,
• Qu'il y a risque de gêne du travail d'un groupe et que le document ne devrait pas être publié dans l'immédiat,
• Que le document empiète sur un travail réservé à l'IETF (par exemple l'ajout d'un élément à un protocole lorsque la norme de ce protocole prescrit une procédure particulière pour de tels ajouts).

Des exemples concrets de conflits sont fournis dans la section 5. Par exemple, la publication d'un protocole « alternatif » (Photuris, RFC 2522) à celui de l'IETF (IKE, RFC 2409) devrait attendre pour laisser le protocole « officiel » être publié en premier. De tels protocoles alternatifs ne posent pas de problème en soi, le choix est une bonne chose, mais il est important qu'ils soient clairement différenciés du protocole de l'IETF. Un autre exemple est la réutilisation de bits « libres » dans un en-tête de paquet lorsque ces bits ont une autre signification dans la norme.

Et si les auteurs ou le RFC editor sont en désaccord avec la conclusion de l'IESG ? C'est la grande nouveauté de notre RFC 5742, une procédure de résolution des conflits, qui fait l'objet de la section 4. Même l'IETF, suivant la judiciarisation croissante de la société, a ses Dispute Resolution Procedures. En quoi consiste t-elle ici ? Dans l'introduction d'une tierce partie, l'IAB, qui sera chargée d'arbitrer tout conflit entre l'IESG et le RFC Editor, si les six semaines de dialogue obligatoire n'ont pas résolu le problème. L'IAB pourra donner raison à l'un ou l'autre et pourra donc, par exemple, imposer au RFC editor l'inclusion d'une note de l'IESG qu'il ne voulait pas.