Procédures de l’IESG pour le traitement
des soumissions indépendantes et du flux de l’IRTF

Résumé

Le présent document décrit les procédures utilisées par l’IESG pour traiter les documents soumis pour publication comme RFC provenant des flux de soumission indépendant et IRTF.

Le présent document met à jour les procédures décrites dans les RFC 2026 et RFC 3710.

Statut du présent mémoire

Le présent mémoire rapporte les bonnes pratiques actuelles de l’Internet.

Le présent document est un produit de l'équipe d'ingénierie de l'Internet (IETF, Internet Engineering Task Force). Il représente le consensus de la communauté de l'IETF. Il a fait l'objet d'une revue publique et sa publication a été approuvée par le groupe de pilotage de l'ingénierie de l'Internet (IESG, Internet Engineering Steering Group). Plus d'informations sur les BCP figurent à la Section 2 de la RFC 5741.

Des informations sur le statut actuel du présent document, sur tout errata, et sur la façon de fournir des retours seront obtenues à http://www.rfc-editor.org/info/rfc5742 .

Notice de droits de reproduction

Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l'IETF Trust sur les documents de l'IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication du présent document. Prière de relire attentivement ces documents, car ils décrivent vos droits et obligations à l'égard du présent document.

1. Introduction et historique

La [RFC4844] définit quatre flux de RFC. Lorsque un document est présenté à la publication, les relectures qu'il subit dépendent du flux dans lequel il sera publié. Les quatre flux définis dans la RFC 4844 sont :

- Le flux de l'IETF

- Le flux de l'IAB

- Le flux de l'IRTF

- Le flux de soumission indépendante

L'IETF est chargée de la maintenance du processus des normes de l'Internet, qui inclut les exigences de développement, de revue et d'approbation des RFC en cours de normalisation et des bonnes pratiques actuelles. Ces RFC, et tous les autres documents expérimentaux et pour information générés par l'IETF, sont revus par les organes appropriés de l'IETF [RFC2026] et publiés au titre du flux de l'IETF.

Les documents publiés dans des flux autres que le flux de l'IETF peuvent ne recevoir aucune relecture de la part de l'IETF pour des choses comme la sécurité, le contrôle d'encombrement, ou une interaction inappropriée avec les protocoles déployés. Généralement, il n'y a pas de tentative de consensus de l'IETF ou d'approbation de l'IESG. Donc, l'IETF décline, pour tous les documents qui ne sont pas du flux de l'IETF, toute responsabilité sur l'adéquation de ces RFC à quelque objet que ce soit.

Le traitement de l'IESG décrit dans le présent document ne concerne que les deux dernières catégories, qui se composent respectivement du flux de soumission indépendante et du flux de l'IRTF [RFC4844].

Suite à l'approbation de la [RFC2026] et avant la publication de la [RFC3932], l'IESG revoyait tous les documents du flux de soumission indépendante avant leur publication. Cette revue était souvent un examen extensif du contenu technique, les directeurs de zone (AD, Area Director) tentant d'éclaircir certains points avec les auteurs, de stimuler la révision des documents, d'encourager les auteurs à contacter les groupes de travail (WG, working group) appropriés, et ainsi de suite. C'était une ponction considérable sur les ressources de l'IESG, et comme cette tâche n'était pas de la plus haute priorité pour les membres de l'IESG, il en résultait souvent des retards significatifs.

En mars 2004, l'IESG a décidé d'apporter un changement majeur à ce modèle de revue, l'IESG prenant seulement la responsabilité de la recherche de conflits entre le travail de l'IETF et les documents soumis. Solliciter une revue technique est réputé être de la responsabilité de l'éditeur des RFC. Si un AD individuel choisit de revoir le contenu technique du document et qu'il trouve des problèmes, cet AD va communiquer ces problèmes à l'éditeur des RFC, et ils seront traités de la même façon que des commentaires sur les documents provenant des autres sources.

Avant 2006, les documents provenant de l'IRTF étaient traités soit comme des soumissions de l'IAB soit comme des soumissions indépendantes via l'éditeur des RFC. Cependant, le groupe de pilotage de la recherche de l'Internet (IRSG, Internet Research Steering Group) a établi un processus de revue pour la publication des RFC provenant du flux de l'IRTF [RFC5743]. Une fois ces procédures pleinement adoptées, l'IESG ne sera responsable que de chercher des conflits entre le travail de l'IETF et les documents soumis, mais les résultats de la vérification feront l'objet d'un rapport à l'IRTF. Ces résultats peuvent être envoyés en copie à l'éditeur des RFC, par courtoisie.

Le présent document ne décrit que le processus de revue effectué par l'IESG lorsque l'éditeur des RFC ou l'IRTF demande cette revue. L'éditeur des RFC va demander la revue des documents du flux de soumission indépendante, et l'IRTF va demander la revue des documents du flux de l'IRTF. Il y a de nombreuses autres interactions entre les éditeurs de documents et l'IESG, par exemple, un AD peut suggérer qu'un auteur soumette un document comme apport pour un travail au sein de l'IETF plutôt que l'éditeur des RFC au titre du flux de soumission indépendante, ou l'IESG peut suggérer qu'un document soumis à l'IETF ferait mieux d'être soumis à l'éditeur des RFC au titre du flux des soumissions indépendantes, mais ces interactions ne sont pas décrites dans le présent mémoire.

Pour l'agrément du lecteur, le présent document inclut des descriptions des actions de l'éditeur des RFC, de l'IAB, et de l'IRSG. L'inclusion de ces actions n'est pas normative. Ces actions sont plutôt incluses pour décrite le processus global qui environne les procédures normatives de l'IESG décrites dans ce document. Le présent document ne fixe aucune procédure de l'éditeur des RFC, de l'IAB, ou de l'IRSG.

1.1 Changements par rapport à la RFC 3932

La RFC 3932 fournissait les procédures de revue des soumissions du flux de soumission indépendante. Avec la définition par l'IESG des procédures du flux de l'IRTF, il est devenu clair que des procédures similaires s'appliquent à la revue par l'IESG des documents du flux de l'IRTF.

L'IAB et l'éditeur des RFC ont fait des mises à jour au formatage de la page de titre de toutes les RFC [RFC5741]. Avec ces changements, le coin supérieur gauche de la page de titre indique le flux qui a produit la RFC. Cette étiquette remplace certaines des informations qui étaient antérieurement fournies dans les notes obligatoires de l'IESG sur les documents qui n'étaient pas du flux de l'IETF.

L'IESG peut demander l'inclusion d'une note de l'IESG dans un document du flux de soumission indépendante ou de l'IRTF pour expliquer la relation spécifique, s'il en est, avec le travail de l'IETF. En cas de conflit sur le contenu d'une note de l'IESG, le présent document fournit un processus de résolution de conflit.

2. Matériaux de base

La revue des soumissions indépendantes par l'IESG était prescrite par le paragraphe 4.2.3 de la [RFC2026]. La procédure décrite dans le présent document est compatible avec cette description.

Les procédures développées par l'IRTF pour les documents créés par les groupes de recherche comportent aussi la revue par l'IESG [RFC5743].

La charte de l'IESG [RFC3710] décrit dans son paragraphe 5.2.2 le processus de revue qui était employé au printemps de 2003 (bien que la RFC n'ait pas été publiée avant 2004) ; avec la publication de la [RFC3932], la procédure décrite dans la RFC3710 n'était plus pertinente pour les documents soumis via l'éditeur des RFC. La publication du présent document met aussi à jour le paragraphe 5.2.2 de la RFC3710, couvrant maintenant les deux flux de l'IRTF et de la soumission indépendante.

3. Description détaillée de la révision par l’IESG

L'éditeur des RFC revoit les soumissions du flux de soumission indépendant pour s'assurer qu'elles conviennent pour être publiées comme RFC. Comme décrit dans la [RFC4846], l'éditeur des RFC demande à l'IESG de revoir les documents pour chercher d'éventuels conflits avec le processus de normalisation de l'IETF ou des travaux conduits dans la communauté de l'IETF.

De façon similaire, les documents destinés à la publication au titre du flux de l'IRTF sont envoyés à l'IESG pour revue à la recherche de conflits avec le processus de normalisation de l'IETF ou des travaux conduits dans la communauté de l'IETF [RFC5743].

La revue par l'IESG de ces documents des flux de soumission indépendante et de l'IRTF résulte en un de cinq types de conclusion suivants, dont chacun peut être accompagné d'une demande d'inclure une note de l'IESG si le document est publié.

1. L'IESG a conclu qu'il n'y a pas de conflit entre ce document et le travail de l'IETF.

2. L'IESG a conclu que ce travail est en rapport avec les travaux conduits dans le groupe de travail <X> de l'IETF, mais que cette relation n'empêche pas la publication.

3. L'IESG a conclu que la publication pourrait éventuellement perturber les travaux conduits dans le groupe de travail <X> de l'IETF et recommande de ne pas publier le document pour le moment.

4. L'IESG a conclu que le document viole les procédures de l'IETF pour <Y> et ne devrait donc pas être publié sans une revue par l'IETF et l'approbation de l'IESG.

5. L'IESG a conclu que le document étend un protocole de l'IETF d'une façon qui exige l'examen de l'IETF et ne devrait donc pas être publié sans un examen par l'IETF et l'approbation de l'IESG.

Les en-têtes et mentions communes des RFC [RFC5741] sont destinées à décrire les relations du document avec le processus des normes de l'IETF. Dans des cas exceptionnels, lorsque les relations du document avec le processus des normes de l'IETF peuvent paraître indécises, l'IESG peut demander l'inclusion d'une note de l'IESG pour clarifier les relations du document avec le processus des normes de l'IETF. Une telle note va vraisemblablement inclure des pointeurs sur les RFC de l'IETF en relation. Le processus de résolution de conflit de la Section 4 est fourni pour traiter les situations dans lesquelles l'IRSG ou l'éditeur des RFC ont un souci avec le contenu de la note demandée à l'IESG.

Les deux dernières réponses sont incluses respectivement, pour le cas où un document tente des actions (comme d'enregistrer un nouveau schéma d'URI) qui exige une revue de l'IETF, une action de normalisation, ou l'approbation de l'IESG (ces termes sont définis dans la [RFC5226]) et pour le cas où un changement ou une extension sont proposés à un protocole de l'IETF qui n'étaient pas prévus par les auteurs d'origine et qui pourraient être au détriment de l'usage normal du protocole, mais où les documents du protocole ne disent pas explicitement que ce type d'extension exige une revue par l'IETF.

Si un document exige une revue de l'IETF, l'IESG va offrir à l'auteur l'opportunité de demander la publication comme un document individuel parrainé par un AD, ce qui est soumis à une pleine revue de l'IETF, incluant une possible allocation à un groupe de travail ou le rejet. La redirection sur le chemin de la pleine revue de l'IESG n'est pas une garantie que l'IESG va accepter le sujet de travail, ou même que l'IESG va lui donner une priorité particulière ; la seule garantie est que l'IESG va examiner le document.

L'IESG va normalement achever la revue dans les quatre semaines de la notification par l'éditeur des RFC ou l'IRTF. Dans le cas d'un éventuel conflit, l'IESG peut contacter un groupe de travail ou son président pour avoir une opinion extérieure sur le caractère dommageable de la publication du document pour ce groupe de travail, et dans le cas d'un possible conflit avec une procédure d'enregistrement de l'IANA, l'expert de l'IANA pour ce registre.

Si l'IESG ne trouve pas de conflit entre une soumission indépendante et un travail de l'IETF, l'éditeur des RFC est alors chargé de juger des mérites techniques de cette soumission, incluant la considération de possibles dommages pour l'Internet. Si l'IESG ne trouve pas de conflit entre une soumission de l'IRTF et le travail de l'IETF, l'IRSG est alors chargée de juger des mérites techniques de cette soumission, incluant la considérations de possibles dommages pour l'Internet.

L'éditeur des RFC, en accord avec l'IAB, devra gérer les mécanismes d'une revue technique appropriée des soumissions indépendantes. De même, l'IRSG, en accord avec l'IAB, devra gérer les mécanismes d'une revue technique appropriée des soumissions de l'IRTF.

4. Résolution de conflit

L'expérience a montré que l'IESG et l'éditeur des RFC ont bien travaillé ensemble en ce qui concerne les recommandations de publication et les notes de l'IESG. Lorsque des questions ont surgi, elles ont été rapidement résolues lorsque toutes les parties ont été mises au courant du problème. Cependant, si un conflit devait se produire, un tiers peut aider à la résolution. Donc, cette procédure de conflit a une phase de dialogue informel suivie par une phase d'arbitrage si la question n'est pas résolue.

Si l'IESG demande l'inclusion d'une note de l'IESG et si l'IRSG ou l'éditeur des RFC a l'intention de publier le document sans la note demandée par l'IESG, ils doivent alors fournir une description claire et concise du problème à l'IESG avant de poursuivre. Une proposition d'un autre texte de note de l'IESG de la part de l'IRSG ou de l'éditeur des RFC est très souhaitable.

Si l'IESG ne veut pas que le document soit publié sans la note de l'IESG demandée, l'IESG doit initier un dialogue informel. Le dialogue ne devrait pas prendre plus de six semaines. Cette période permet à l'IESG de mener un dernier appel à l'IETF concernant le contenu de la note de l'IESG demandée (et non sur le document dans son ensemble) pour déterminer si désiré le consensus de la communauté. À la fin du dialogue, l'IESG peut réaffirmer la note originale, fournir une autre note de l'IESG, ou retirer la note. Si une note de l'IESG est demandée, l'IRSG ou l'éditeur des RFC doit déclarer si il a l'intention de l'inclure.

Si le dialogue échoue à résoudre les problèmes de l'IRSG ou de l'éditeur des RFC au sujet du contenu d'une note de l'IESG demandée et si il a l'intention de publier le document comme RFC sans la note de l'IESG demandée, alors l'IESG peut demander formellement à l'IAB d'arbitrer. L'IAB n'est pas obligé d'effectuer l'arbitrage et peut refuser la demande. Si l'IAB refuse, l'éditeur des RFC va décider si la note de l'IESG est incluse. Si l'IAB accepte, la revue de l'IAB va se faire selon des procédures choisies par l'IAB. L'IAB peut ordonner l'inclusion de la note de l'IESG, ordonner la suppression de la note de l'IESG, ou laisser la décision finale à l'éditeur des RFC. À la différence des revues de l'IAB spécifiées dans la [RFC4846], si l'IAB ordonne l'inclusion ou la suppression de la note de l'IESG, la décision de l'IAB est exécutoire, et non consultative.

5. Exemples de cas où la publication est dommageable

La présente section donne deux exemples où retarder ou empêcher la publication d'un document peut être approprié à cause d'un conflit avec le travail de l'IETF. Elle fait partie de la description du contexte, et non de la procédure.

Rejet d'une alternative déviante :

Alors qu'un groupe de travail recherche une solution à un problème, un participant décide de demander la publication comme soumission indépendante d'une solution que le groupe de travail a rejetée. La publication du document va donner à celui qui publie un numéro de RFC avant que le groupe de travail ait fini. Il semble préférable que le produit du groupe de travail soit publié en premier, et que le document non adopté soit publié ensuite, avec une note de déclinaison de responsabilité disant que "la technologie de l'IETF pour cette fonction est X".

Exemple : Photuris (RFC 2522), qui a été publié après IKE (RFC 2409).

Note : En général, l'IESG n'a pas de problème avec le fait de rendre disponibles à la communauté les alternatives rejetées ; de telles publications peuvent être une contribution précieuse pour la littérature technique. Cependant, il est nécessaire d'éviter la confusion avec les solutions adoptées par le groupe de travail.

Réutilisation inappropriée de bits "libres" :

En 2003, une proposition de RFC expérimentale a été publiée demandant la réutilisation des bits de poids fort de la partie "décalage de fragment" de l'en-tête IP pour un autre objet. Aucune considération relative à l'IANA ne disait comment ces bits pouvaient être réalloués, mais le texte définissait une signification spécifique pour eux. L'IESG a conclu que les mises en œuvre de cette expérimentation risquaient de causer des problèmes d'interopérabilité difficiles à démêler et a recommandé de ne pas publier le document dans la série des RFC. L'éditeur des RFC a accepté cette recommandation.

La série des RFC est un canal de publication parmi de nombreux autres disponibles ; le présent document ne prend pas position sur la question de quels documents sont appropriés pour publication dans la série des RFC. C'est un sujet à discuter au sein de la communauté de l'Internet.

6. Déclaration de l’IAB

En sa qualité d'organe d'approbation de la politique générale suivie par l'éditeur des RFC (voir la [RFC2850]) l'IAB a revu la présente proposition et la soutient en tant que changement du fonctionnement qui est en accord avec les rôles respectifs de l'IESG, de l'IRTF, et de l'éditeur des RFC. L'IAB continue de surveiller les discussions au sein de l'IETF sur d'éventuels ajustements du processus de publication des documents de l'IETF et reconnaît que le processus décrit dans ce document, comme tous les autres processus généraux de publication de l'IETF, peut devoir être ajusté en fonction des changements qui résultent de telles discussions.

7. Considérations sur la sécurité

Le changement de traitement décrit dans le présent mémoire n'a pas de conséquence directe sur la sécurité de l'Internet.

8. Remerciements

La RFC 3932 a été produite par l'IESG en octobre 2004, et elle a été revue par l'IETF, par l'éditeur des RFC, et par l'IAB. Des remerciements particuliers pour le développement de la RFC3932 sont dus (par ordre alphabétique) à Scott Bradner, Brian Carpenter, Paul Hoffman, John Klensin, Eliot Lear, Keith Moore, Pete Resnick, Kurt Zeilenga, et à tous les autres participants à la communauté de l'IETF qui ont fourni de précieux retours.

Cette mise à jour de la RFC3932 a été produite par l'IESG en juillet et août 2008, et a été revue par l'IETF, par l'éditeur des RFC, par l'IRSG, et par l'IAB. Des remerciements particuliers pour le développement de cette mise à jour sont dus à (par ordre alphabétique) Jari Arkko, Ran Atkinson, Leslie Daigle, Lars Eggert, Aaron Falk, Sam Hartman, John Klensin, Olaf Kolkman, et Andy Malis.

9. Références

[RFC2026] S. Bradner, "Le processus de normalisation de l'Internet -- Révision 3", (BCP0009) octobre 1996. (Remplace RFC1602, RFC1871) (MàJ par RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378, RFC6410)

[RFC2850] Bureau de l'architecture Internet, B. Carpenter, éd. "Charte de l'IAB", mai 2000. (BCP0039)

[RFC3710] H. Alvestrand, "Charte de l'IESG", février 2004. (MàJ par RFC3932) (Information)

[RFC3932] H. Alvestrand, "Procédures des documents de l'IESG et de l'éditeur de RFC", octobre 2004. (BCP0092) (Obsolète, voir RFC5742)

[RFC4844] L. Daigle, éd., Internet Architecture Board, "La série des RFC et l'éditeur des RFC", juillet 2007. (Information)

[RFC4846] J. Klensin et D. Thaler, éd., "Soumissions indépendantes à l'éditeur des RFC", juillet 2007. (Information)

[RFC5226] T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434)

[RFC5741] L. Daigle et O. Kolkman, éd., IAB, "Flux de RFC, en-têtes et mentions communes", décembre 2009. (Information)

[RFC5743] A. Falk, "Définition d'un flux de documents provenant de la mission Recherche de l'Internet (IRTF)", décembre 2009. (Information)

Adresses des auteurs

Harald Alvestrand

mél : harald@alvestrand.no

Russell Housley

mél : housley@vigilsec.com