Le Tao de l'IETF : Guide destiné aux nouveaux participants à l'Internet Engineering Task Force

Paul Hoffman, Editor


About This Document

Copyright © 2012 IETF Trust. All rights reserved.

The current version of this web page can always be found at http://www.ietf.org/tao.html; that page can also be retrieved protected by TLS. To contribute to this document or to discuss its content, please join the "tao-discuss" mailing list. A history of the major versions of the Tao can be found here. This particular version was created on 2012-11-02.

Cette page Web est en Français. Il y a une liste de traductions du Tao de l’IETF.


1. Introduction

Depuis ces dernières années, la participation aux réunions physiques de l'Internet Engineering Task Force (IETF) s'est considérablement accrue. On recense à chaque réunion un grand nombre de nouveaux participants qui, pour beaucoup d'entre eux, reviendront ensuite régulièrement. Lorsque les réunions étaient moins fréquentées, il était relativement aisé pour un nouveau participant de se joindre au mouvement. Mais aujourd'hui, on y rencontre beaucoup plus de monde et on met parfois un visage sur des noms connus pour avoir signé certains travaux ou certains e-mails ayant suscité la réflexion.

Ce document décrit de nombreux aspects de l'IETF et explique son fonctionnement aux nouveaux participants. Cela crée une motivation et leur permet de rendre les réunions et les discussions des groupes de travail beaucoup plus productives. Au début, ce document était assez court, puis il a été étoffé au fil du temps en réponse aux suggestions des nouveaux participants à l’IETF sur ce qu’ils auraient voulu savoir avant de participer à leur première réunion en face à face ou avant de s’engager activement dans leur premier groupe de travail.

De nombreux participants à l'IETF n'assistent jamais aux réunions en personne, mais ils sont cependant actifs sur les listes de diffusion des divers groupes de travail. Le fonctionnement interne de ces groupes pouvant paraître obscur au début, ce document fournit des informations élémentaires qui aideront les nouveaux participants à s'impliquer dans les travaux.

L’IETF est en évolution constante. Même si les principes énoncés dans ce document sont supposés rester sensiblement les mêmes au fil du temps, les détails pratiques peuvent avoir changé au moment de la lecture ; un outil du Web, par exemple, peut avoir remplacé une adresse électronique pour susciter une action.

On trouvera dans le Tao des références à de nombreux types de documents IETF, des BCP aux RFC et STD. Les BCP, Best Current Practices, proposent des recommandations concernant les meilleures pratiques de l’Internet ; les RFC (Requests for Comments) sont les principaux documents techniques de l’IETF, connus sous le nom de « Demandes de commentaires » ; et les STD sont des RFC identifiés comme « normes ». En fait, les trois types de documents sont des RFC. ConsultezSection 6 pour en savoir plus.

Cette page Web est une continuation de la série de RFC « Tao de l'IETF ». Consultez[RFC6722] pour comprendre comment le dernier RFC de cette série est devenu cette page Web. Cette version du Tao accessible sur le Web, basée sur [RFC4677][RFC4677], a été co-écrite avec Susan Harris. La version originale de ce document, publiée en 1994, a été rédigée par Gary Malkin.

Qu’est-ce que le « Tao » ? Le Tao, qui se prononce « daow » en anglais, est le principe de base des enseignements de Lao-Tseu, un maître chinois. Son symbole connu est le cercle noir et blanc représentant le Ying et le Yang. Le Taoïsme conçoit l'univers comme un seul organisme, et les êtres humains comme des parties interdépendantes d'un tout cosmique. On traduit parfois le Tao par « la voie », mais la philosophie taoïste considère que son sens véritable ne peut se traduire par des mots.

1.1 Acronymes et abréviations utilisés dans le Tao

Certains des acronymes et abréviations utilisés dans ce document sont énumérés ci-dessous.

Terme Signification
AD Area Director (directeur de domaine)
BCP Best Current Practice (bonnes pratiques)
BOF Birds of a Feather (du proverbe « birds of feather flock together » : qui se ressemble s'assemble)
FAQ Frequently Asked Question(s) (foire aux questions)
FYI For Your Information (RFC) (pour information)
IAB Internet Architecture Board (Conseil pour l’architecture d’Internet)
IAD IETF Administrative Director (directeur administratif de l’IETF)
IANA Internet Assigned Numbers Authority (autorité d'attribution des adresses Internet)
IAOC IETF Administrative Oversight Committee (comité de surveillance administrative de l’IETF)
IASA IETF Administrative Support Activity (activité de soutien administratif de l’IETF)
ICANN Internet Corporation for Assigned Names and Numbers (Société pour l'attribution des noms de domaine et des numéros sur Internet)
I-D Internet-Draft (document de travail)
IESG Internet Engineering Steering Group
IETF Internet Engineering Task Force (Groupe de travail en ingénierie Internet)
IPR Intellectual property rights (Droits de propriété intellectuelle)
IRTF Internet Research Task Force (groupe de recherche)
ISOC Internet Society
RFC Request for Comments (Demande de commentaires)
STD Standard (RFC)
WG Working Group (groupe de travail)

2. Qu'est-ce que l'IETF ?

L’IETF est un groupe informel et auto-organisé dont les membres contribuent à l'ingénierie et à l'évolution des technologies de l'Internet. C'est la principale structure engagée dans l’élaboration des spécifications pour les nouveaux standards de l'Internet. L’IETF est atypique dans la mesure où elle est constituée d'une série d'événements, sans cadre statutaire ni conseil d'administration, sans membres ni adhésion ; Consultez[BCP95], d’« Un énoncé de mission de l'IETF », pour plus de détails.

Elle a pour but de :

Une réunion IETF n'est pas une conférence, même si on y trouve des présentations techniques. L'IETF n'est pas une organisation de normalisation au sens traditionnel, même si nombre de spécifications produites deviennent des normes. L'IETF est composée de bénévoles, qui se réunissent en grand nombre trois fois par an afin de mener à bien sa mission.

Il n'y a pas d'adhésion formelle à l'IETF. Tout le monde peut s'inscrire et participer aux réunions. Devenir membre de l'IETF, c'est avant tout s'inscrire sur une des listes de diffusion de l’IETF ou des groupes de travail (voirSection 2.3) afin d'accéder à toutes les informations relatives aux activités et débats en cours.

Bien sûr, l'IETF ne pourrait pas être aussi efficace sans s'appuyer sur une quelconque structure. En fait, elle est prise en charge par d'autres organisations, tel que décrit dans[BCP11], « Les organisations impliquées dans le processus de standardisation de l'IETF ». Si vous décidez de participer aux travaux de l'IETF et si vous ne deviez lire qu'un seul BCP, ce devrait être celui-là.

Le site Web de l'IETF,http://www.ietf.org, est la meilleure source d'informations sur les réunions, groupes de travail, documents Internet, RFC, adresses e-mail de l’IETF, et bien plus encore.

À bien des égards, l'IETF repose sur les croyances de ses participants. L’une des « croyances fondatrices » est incarnée dans une citation sur l’IETF de David Clark : « Nous rejetons les rois, les présidents et le vote. Nous croyons en un consensus approximatif et un code qui fonctionne ». Une autre citation qui est devenue une croyance communément répandue à l’IETF vient de Jon Postel : « Soyez conservateur dans ce que vous envoyez et libéral dans ce que vous acceptez ».

L’IETF n’existe vraiment que par ses membres. En raison des mesures non restrictives d’adhésion à l’IETF, les participants sont originaires de toutes les régions du monde et de différentes parties de l’industrie de l’Internet. L'IETF mène ses activités uniquement en anglais. ConsultezSection 3.12 pour des informations sur les façons d’adhérer à l’IETF.

Une autre chose importante pour les nouveaux arrivants : l’IETF n’a en aucun cas le monopole de l’Internet, malgré ce que certains pensent à tort. L’IETF élabore des normes qui sont souvent adoptées par les internautes, mais ne joue pas le rôle de surveillant voire de censeur de l’Internet. Si l’IETF vous intéresse parce que vous voulez faire partie des superviseurs, vous risquez d’être sérieusement déçu par l’ IETF.

2.1 Des débuts modestes

La première rencontre de l'IETF a eu lieu en janvier 1986 au Linkabit de San Diego et réunissait 21 participants. La quatrième rencontre, qui s’est tenue au SRI de Menlo Park en octobre 1986, a été la première à laquelle des fournisseurs privés ont assisté. Le concept de groupes de Travail (Working Groups) est apparu au cours de la cinquième rencontre de l'IETF au centre de recherche Ames de la NASA, en Californie, en février 1987. La septième rencontre, au MITRE de McLean, en Virginie, au mois de juillet 1987, a réuni pour la première fois plus d'une centaine de participants.

La quatorzième rencontre de l'IETF a été organisée à l'université de Stanford en juillet 1989. Elle a marqué un changement radical dans la structuration de l'IETF. La structure de l’IAB (à l’époque Internet Activities Board, aujourd’hui Internet Architecture Board), qui jusque là veillait sur de nombreux groupes (task forces) s'est réorganisée en deux pôles principaux : l’IETF et l’IRTF. L'IRTF était chargé des problèmes de recherches à long terme concernant l'Internet. L'IETF a également évolué à cette époque.

Après la formation de l'Internet Society (ISOC) en janvier 1992, l'IAB a proposé que l'ISOC prenne sous son aile ses propres activités. C'est au cours de la rencontre INET92 à Kobe, au Japon, que les membres du Conseil de l'ISOC ont approuvé une nouvelle charte pour entériner cette proposition.

L'IETF s'est réuni à Amsterdam aux Pays-Bas, en juillet 1993. C'était la première rencontre de l’IETF en Europe et la proportion de participants américains a été réduite de moitié. La première rencontre de l’IETF en Asie (à Adelaide, Australie) a eu lieu en 2000.

Actuellement, l'IETF se réunit en Amérique du Nord, en Europe et en Asie. L'intention est de se réunir une fois par an dans chaque région, bien qu'en raison de problèmes de calendrier, il y ait souvent plus de réunions en Amérique du Nord et moins en Asie et en Europe. La proportion de participants non américains continue d'être élevée — environ la moitié, même aux réunions organisées sur le sol américain.

2.2 La hiérarchie

2.2.1 ISOC (Internet Society)

L'Internet Society (l’ISOC) est une organisation internationale à but non lucratif visant à favoriser le développement de l'Internet. L’ISOC fonctionne, entre autres, grâce à l'appui financier et juridique des autres groupes décrits ici (les groupes « I »), en particulier l’IETF. L'ISOC fournit une assurance à de nombreux participants engagés dans les travaux de l'IETF et prend en charge les relations publiques lorsque l'un des groupes « I » veut s'adresser à la presse. L'ISOC est l'un des principaux héros méconnus de l’ Internet.

Depuis ses débuts au printemps 2005, l’ISOC est également le siège des membres du bureau exécutif de l’IETF. Ceci est décrit plus en détail dans [BCP101], « Structure de l’IETF Administrative Support Activity (IASA) ». Au début, le bureau n’avait qu’un seul directeur administratif (IAD) qui travaillait à plein temps pour superviser l’organisation des réunions de l’IETF, les aspects opérationnels des services de soutien (le secrétariat, l’IANA (Internet Assigned Numbers Authority) et l’édition des RFC, qui sont décrits plus loin dans ce chapitre), et le budget. Il ou elle (actuellement il) dirige l’IASA (IETF Administrative Support Activity), qui s’occupe de tâches telles que la collecte des jetons de présence et le paiement des factures, et subventionne les outils de travail des groupes de travail de l’IETF, l’IESG, l’IAB et le IRTF (plus d’informations à ce sujet plus loin dans ce chapitre).

Le Comité de contrôle administratif de l’IETF (IAOC, IETF Administrative Oversight Committee) est constitué de bénévoles, tous choisis directement ou indirectement par la communauté de l’IETF, ainsi que des membres ex officio de l’ISOC et de la direction de l’IETF. L’IASA et l’IAD sont dirigés par l’IAOC.

Ni l’IAD ni l’IAOC n’ont d’influence sur l’élaboration des normes de l’IETF, que nous allons aborder maintenant.

2.2.2 IESG (Internet Engineering Steering Group)

L’IESG est responsable de la gestion technique des activités de l’IETF et du processus de standardisation de l’Internet. Il administre le processus conformément aux règles et procédures qui ont été ratifiées par le Conseil d’administration de l’ISOC. L'IESG n'a cependant pas un rôle de direction tel que cela peut-être le cas pour d'autres organismes de standardisation. Comme son nom l'indique, son rôle est de définir les objectifs plutôt que de donner des ordres. L'IESG ratifie ou corrige les résultats issus des groupes de travail de l'IETF, déclare la création et la dissolution de ces derniers et s'assure de la qualité des documents non issus des groupes de travail et destinés à devenir des RFC.

Consultez les pages Web de l’IESG, http://www.ietf.org/iesg.html, pour trouver des informations mises à jour sur les documents traités, les RFC publiés et les documents dans Last Call, ainsi que les rapports mensuels de situation de l’IETF.

L'IESG est constitué des directeurs de domaines (Area Directors, ici abrégé en « AD »), sélectionnés par un comité de nomination (Nominations Committee, souvent appelé « Nomcom ») et nommés pour deux ans. Le processus de nomination des membres de l'IESG est détaillé dans [BCP10], « IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees ».

Les domaines d'activité actuels et leurs abréviations sont indiqués ci-dessous.

Superficie Description
Applications (APP) Protocoles vus par les utilisateurs des programmes, tels que l'e-mail et le Web
General (GEN) Processus de l’IETF et travaux divers pour les groupes de travail qui n'entrent dans aucune autre catégorie (ce qui est rare)
Internet (INT) Les différentes façons d'acheminer des paquets IP et les informations DNS
Operations and Management (OPS) Aspects opérationnels, surveillance du réseau et configuration
Real-time Applications and Infrastructure (RAI) Communications interpersonnelles sensibles aux délais
Routing (RTG) Acheminer les paquets jusqu'à leur destination
Security (SEC) Authentification et confidentialité
Transport (TSV) Services spéciaux pour les paquets spéciaux

Étant donné que l'IESG a une grande influence sur le fait que les documents de travail (avant-projet Internet) deviennent ou non des RFC, de nombreuses personnes ont tendance à considérer les AD comme des demi-dieux. IETF Les participants à l’IETF s’adressent parfois à eux avec vénération pour leur demander leur avis sur un sujet particulier. Cependant, la plupart des AD ne sont pas différents des simples mortels et s’adressent rarement aux autres depuis un piédestal. En fait, lorsqu'on leur demande un avis technique particulier, les AD s'en remettent souvent aux participants à l’IETF qui ont à leurs yeux d'avantage de connaissances dans tel ou tel domaine.

Les AD sont censés connaître mieux que personne l'ensemble du travail combiné des groupes de travail œuvrant dans leur domaine. D'un autre côté, l'ensemble de l'IESG revoit chaque Internet-Draft proposé pour en faire un RFC. Tout AD peut voter pour une « DISCUSSION » contre un document si il ou elle a de graves préoccupations. Se ces problèmes ne peuvent pas être résolus par la discussion, une procédure de dérogation est définie de telle sorte qu’au moins deux membres de l’IESG expriment leurs préoccupations avant de bloquer le processus. Cette procédure permet d’assurer que le « bébé » d’un AD n’acquiert le statut de norme au détriment des autres protocoles de l’IETF déjà existants et que la « bête noire » d’un AD ne puisse bloquer quelque chose indéfiniment.

Pour autant, il ne s'agit pas de dire que l'IESG n'exerce jamais son pouvoir. Lorsque l'IESG constate qu'un groupe de travail s'éloigne de sa charte constitutive ou lorsqu'un groupe de travail lui demande de transformer tel protocole mal dégrossi en standard, l'IESG réagit. En fait, à cause de sa charge de travail considérable, l'IESG agit souvent de manière réactive. Il accepte la plupart des demandes faites par les groupes de travail pour qualifier un Internet Draft en RFC et n’intervient qu’en cas de problème véritable. On peut malgré tout dire que les AD sont élus pour penser et non pas seulement pour administrer le processus. La qualité des normes définies par l'IETF provient à la fois des critiques qu'ils reçoivent des groupes de travail et de celles que les groupes de travail reçoivent des AD.

L'IETF fonctionne sur le mode du consensus approximatif et c'est l'IESG qui décide si un groupe de travail a abouti à un résultat réellement consensuel. (Voir Section 4.2 pour plus d'informations sur le consensus des groupes de travail.) Ainsi, une des raisons principales qui peut conduire l'IESG à bloquer le travail d'un groupe est que celui-ci n'a pas obtenu un vrai consensus au sein de l'ensemble de l'IETF, c'est à dire dans tous les groupes de travail de l'ensemble des domaines. Par exemple, le résultat produit par un groupe peut éventuellement se retrouver en contradiction avec une technologie développée dans un autre groupe de travail, peut-être d’un autre domaine. Une des missions importantes de l’IESG consiste à veiller au travail de l'ensemble des groupes pour éviter toute incohérence entre les protocoles définis par l’IETF. C'est pour cette raison que les AD sont censés relire les travaux effectués en dehors de leurs domaines respectifs.

2.2.3 IAB (Internet Architecture Board)

L'IAB est en charge de conserver une vision d'ensemble de l’Internet et se concentre sur la planification et la coordination à long terme des différents domaines d'activité de l'IETF. L'IAB est en veille permanente sur les enjeux fondamentaux de l'Internet et en informe le grand public lorsqu'il l'estime nécessaire.

Les membres de l'IAB portent une attention particulière aux activités émergentes de l'IETF. Lorsqu'un nouveau groupe de travail se crée à l'IETF, l'IAB vérifie l'intégrité et la cohérence architecturale de sa charte. Avant même que la charte du groupe soit définie, les membres de l'IAB sont toujours très volontaires pour échanger sur les nouvelles idées avec leurs initiateurs.

L'IAB parraine et organise également l'Internet Research Task Force sous forme d'ateliers qui proposent des études approfondies sur certains sujets concernant l'architecture de l'Internet. Ces ateliers font des recommandations à l'IETF et à l'IESG.

Le rôle de l'IAB est aussi de :

À l'instar de l'IESG, les membres de l'IAB sont désignés pour deux ans par le Nomcom et sont approuvés par le Conseil d’administration de l'ISOC.

2.2.4 IANA (Internet Assigned Numbers Authority)

Le bureau central d’enregistrement des activités de l’IETF est l’IANA (voir http://www.iana.org). Il est souvent indispensable de garder la trace d’éléments de protocole qui ont été ajoutés à un protocole Internet existant. Par exemple, la numérotation des ports TCP et les types MIME exigent une telle conservation. L'IAB a désigné l’IANA comme responsable de cette mission, et les activités de l’IANA sont soutenues financièrement par l'ICANN (Internet Corporation for Assigned Names and Numbers). L’IAB a choisi l’ICANN, et les activités de l’IANA sont fournies gratuitement tel que spécifié dans [RFC2860].

Il y a encore dix ans, personne n'aurait imaginé voir un jour l'IANA apparaître en première page d'un journal. Le rôle de l'IANA avait jusque là été très mineur. La Le fait que l'IANA fut aussi le gestionnaire de la racine des noms de domaine le propulsa sur le devant de la scène, en même temps qu'il fut soumis au feu des critiques injustifiées de certaines personnes qui n'avaient pas même pris la peine d'examiner sa véritable fonction. Aujourd'hui, l'IETF n'est plus à proprement parler engagé dans les activités de l'IANA d'attribution des noms de domaine et des adresses IP, qui sont encadrées désormais par l'ICANN.

Bien que ce rôle d'enregistrement ne semble pas passionnant, de nombreux participants à l'IETF pourront témoigner de l'importance de l'apport de l'IANA au développement de l'Internet. La possibilité d'avoir un dépositaire pérenne et stable géré par des opérateurs prudents et conservateurs permet d'expérimenter beaucoup plus facilement sans craindre de tout mélanger. Le fondateur de l'IANA, Jon Postel, s'est vu confier la lourde responsabilité d'ordonner les choses au moment où l'Internet évoluait à grands pas, ce qu'il fit très bien jusqu'à sa mort prématurée en 1998.

2.2.5 Rédacteur en chef des RFC

Le rédacteur en chef des RFC (RFC Editor) prépare, formate et publie les travaux qui prennent alors le statut de RFC, en travaillant en concertation avec l'IESG. Une autre fonction importante du rédacteur en chef est de fournir un répertoire définif de tous les RFC (voir http://www.rfc-editor.org). Une fois qu’un RFC est publié, il n'est jamais modifié. Si le standard qu'il décrit change, celui-ci sera de nouveau publié sous la forme d'un nouveau RFC qui rendra le premier obsolète.

Une des confusions les plus courantes au sein de la communauté des membres de l'IETF est de penser que la fonction du rédacteur en chef des RFC est assurée par l'IANA. En fait, il s'agit d'un poste bien distinct, bien que l'on y ait trouvé les mêmes personnes pendant plusieurs années. Aujourd'hui, ces travaux sont effectués par des organismes distincts. L'IAB approuve l'organisation qui remplira la fonction de rédacteur en chef des RFC ainsi que sa ligne de conduite. Le rédacteur en chef des RFC est subventionné par l’IASA.

Jusqu’à la fin de l’année 2009, le rédacteur en chef des RFC était une entité à part entière. En collaboration avec les membres de l’IETF, l’IAB a scindé son rôle en plusieurs fonctions pouvant être exercées par des personnes ou organisations différentes, dirigées par le rédacteur en chef des RFC nommé par l’IAB. Le modèle de Rédacteur en chef des RFC est décrit dans [RFC6635].

2.2.6 Secrétariat de l'IETF

Très peu de personnes sont rémunérées pour s'occuper de l'IETF. Le secrétariat de l'IETF fournit le support logistique au quotidien qui consiste surtout à coordonner les réunions en face à face et à gérer les listes de diffusion spécifiques à l’IETF. Le secrétariat est également chargé de conserver et de classer le répertoire officiel des documents de travail (avant-projet Internet) et de tenir à jour le site Web de l’IETF ainsi que d’aider l’IESG dans l’accomplissement de sa mission. Il fournit différents outils à utiliser par la communauté et l’IESG. Le secrétariat de l'IETF est sous contrat avec l'IASA, qui à son tour est soutenu financièrement par les droits perçus pour assister aux réunions en face à face.

2.2.7 l’IETF Trust

Vers la fin de l’année 2005, l’IETF Trust a été créé pour s’occuper de la propriété intellectuelle de l’IETF. La raison de la création de l’IETF Trust est que quelqu’un doit détenir la propriété intellectuelle et que ce quelqu’un doit être une entité stable et légalement constituée. Les fiduciaires de l’IETF sont les mêmes personnes qui siègent en tant que membres de l’IAOC à un moment donné dans le temps. Peu de participants à l’IETF prennent contact avec l’IETF Trust, ce qui prouve l’efficacité de son travail. Vous trouverez plus d’informations sur l’IETF Trust sur son site Web, http://trustee.ietf.org.

2.3 Listes de diffusion de l'IETF

Pour les personnes souhaitant assister à une réunion IETF, il est fortement conseillé de s'inscrire sur la liste de diffusion des annonces (voir https://www.ietf. org/mailman/listinfo/IETF-Announce). Elle fournit toutes les informations sur les réunions et la parution des RFC. C’est également sur cette liste que les plans d’actions sur les protocoles et les derniers appels à commentaires (Last Calls) de l’IESG sont postés. Pour les personnes impliquées au niveau technique et souhaitant se joindre à l’IETF, il existe aussi la liste de discussion (voir https://www.ietf.org/ mailman/listinfo/ietf). C'est l'endroit où l'on discute de sujets d'une portée cosmique (les groupes de travail ont leur propre liste pour discuter des sujets qui concernent leurs travaux). Une autre liste de diffusion publie la nouvelle version de chaque document de travail tel qu’il est publié (voir https://www.ietf. org/mailman/listinfo/I-D-Announce).

L'inscription à ces listes et à toute liste de l'IETF est gérée par un programme appelé « mailman ». Ce dernier tend à se montrer quelque peu pointilleux sur les formats des messages d'inscription, fonctionnant moins bien par exemple avec les e-mails au format html. Mais il se montrera docile si vous formatez vos messages à sa façon.

La liste de discussion de l’IETF n'est pas modérée. Cela signifie que tout le monde peut exprimer ses opinions sur des sujets concernant l'Internet. Par contre, elle n'est pas du tout appropriée aux entreprises ou aux particuliers pour l’envoi de messages tels que des sollicitations ou de la promotion, comme indiqué dans[BCP45], « IETF Discussion List Charter ». Il est judicieux de lire en entier ce court RFC avant d'envoyer un premier message sur la liste de discussion. En fait, la liste contient deux « sergents d’armes » qui surveillent les envois inappropriés, et il existe un processus permettant d’exclure les récidivistes de la liste, mais ce cas est heureusement rare.

Seuls le secrétariat et un petit nombre de dirigeants de l’IETF peuvent approuver les messages envoyés à la liste des annonces, même si ces messages proviennent d’une variété de personnes.

Bien que les listes de diffusion de l’IETF « représentent » l’appartenance à la communauté des membres de l’IETF, il faut préciser que la participation à une réunion IETF n'implique aucune inscription automatique aux listes.


3. Réunions de l'IETF

Le monde de l'informatique regorge de conférences, séminaires, expositions et réunions en tous genres. Cependant, les rencontres de l'IETF sont d'une toute autre nature. Les réunions, organisées trois fois par an, rassemblent pendant une semaine des jeunes technicos et ont pour principal objectif de revigorer le travail des groupes, mais aussi permettre des échanges entre les différents domaines et groupes de travail. Les coûts d'organisation sont financés par les participants et par l'institution hôte de la réunion, sans oublier l’IASA qui rajoute quelques moyens supplémentaires pour permettre par exemple la retransmission audio de certaines sessions des groupes de travail.

Pour beaucoup de gens, les réunions IETF constituent une bouffée d’air frais comparées aux conférences standard de l’industrie informatique. Il n’y a pas de hall d’exposition, peu de travaux pratiques, et aucun pontife de l’industrie de grand renom. Il y a plutôt beaucoup de travail, et pas mal de temps pour les rencontres informelles des participants. Les réunions de l'IETF présentent peu d'intérêt pour les commerciaux ou les spécialistes marketing et s'adressent plutôt aux ingénieurs et développeurs.

En règle générale, une réunion de l’IETF commence par des travaux pratiques et un rassemblement informel le dimanche, suivis de réunions des groupes de travail et BoF du lundi au vendredi. Les réunions des groupes de travail durent entre 1h et 2h30 chacune et certains groupes de travail ont plusieurs réunions au cours de la semaine, en fonction de la quantité de travail qu’ils prévoient de faire.

Il y a deux séances plénières, l’une technique et l’autre administrative, en soirée pendant la semaine. La réunion plénière technique est organisée par l’IAB et compte généralement un ou deux panels d’experts abordant des sujets d’intérêt de nombreux groupes de travail et domaines. La réunion plénière administrative, organisée par le président de l’IETF, couvre des éléments tels que les rapports d’avancement du rédacteur en chef des RFC et les annonces des prochaines réunions. Les séances plénières sont un bon moment à partager avec l’IESG et l’IAOC. Les éloges sont les bienvenus, mais le plus souvent ce sont des préoccupations et des plaintes qui sont soulevées.

Actuellement l’IETF se réunit en Amérique du Nord, en Europe et en Asie, environ une fois par an dans chaque région. Les dernières réunions ont rassemblé environ 1200 participants. Il y a eu plus de 80 réunions de l’IETF à ce jour et une liste des réunions à venir est disponible surhttp://www.ietf.org/meeting/upcoming.html.

Les nouveaux participants à une réunion IETF en face à face sont souvent très surpris. Ils s'attendent à ce qu'elle se déroule comme dans un organisme de standardisation ou comme une conférence informatique. Heureusement, au bout d'un jour ou deux, la surprise laisse place à l'enthousiasme des nouveaux participants suscité par le côté plaisant de l’événement. D’autre part, les participants à l’IETF peuvent se révéler parfois étonnamment grossiers en haussant la voix lors d’une présentation au micro ou en se précipitant dans la foule pour se faire servir de la nourriture ou des boissons. Ce type de comportement anti-social semble être plus fréquent lors des réunions IETF que pendant les conférences informatiques.

3.1 Inscription

Pour assister à une réunion de l'IETF, vous devez vous inscrire et payer les frais d'inscription. Le lieu de la réunion et l'ouverture des inscriptions sont annoncés à peu près deux mois à l'avance— plus tôt si possible. L'information est communiquée par e-mail sur la liste de diffusion des annonces et publiée sur le site Web de l’IETF http://www.ietf.org, le même jour.

Vous pouvez vous inscrire et payer sur le Web avant la réunion, ou personnellement lors de la réunion. Pour bénéficier d'un tarif réduit, l'inscription doit être effectuée avant une date limite (environ une semaine avant la réunion). Les frais d'inscription comprennent l'accès à toutes les réunions de la semaine, la réception d'accueil du dimanche soir (cash bar), les petits déjeuners et les pauses café de l’après-midi.

L'inscription reste ouverte toute la semaine de la réunion. Néanmoins, le secrétariat conseille aux participants de se présenter à l'ouverture des inscriptions, qui a lieu généralement à partir du dimanche midi jusqu’en fin d’après-midi, début de la réception d’accueil. La réception est un moment très prisé pendant lequel vous pourrez manger un morceau et faire connaissance avec les premiers arrivants.

Il est important de noter que les informations relatives aux coordonnées des participants ou aux listes de diffusion ne sont jamais commercialisées.

Avant de vous inscrire, consultez la page Web intitulée « nota bene ». Lisez-la attentivement car elle énonce les règles concernant les droits de propriété intellectuelle de l’IETF.

Si vous avez besoin de laisser des messages à d’autres participants, vous pouvez le faire sur les tableaux d’affichage qui se trouvent à proximité du comptoir d’accueil. Sur ces tableaux figurent également les changements de réunion de dernière minute et les changements de salles.

Vous pouvez également déposer des objets trouvés au comptoir d’accueil. À la fin de la réunion, les objets trouvés et non récupérés sont généralement remis à l’hôtel ou ramenés au secrétariat.

Par ailleurs, le comptoir d’accueil de l’IETF sert souvent de point de rencontre. Si quelqu’un vous demande de le retrouver à l’accueil, demandez-lui s’il s’agit du comptoir d’accueil de l’IETF ou de l’hôtel. De nombreux rendez-vous ont été ratés par manque de précision.

3.2 Faites le pas et restez toute la semaine !

Les réunions des groupes de travail de l’IETF sont programmées du lundi matin au vendredi après-midi. Les réunions autres que celles des groupes de travail ont souvent lieu le week-end précédent ou suivant. Il est préférable de prévoir d’être présent toute la semaine pour profiter des échanges entre les groupes de travail et des discussions informelles. Vous verrez ci-dessous que le programme est simple. Nombreux sont les participants qui ont raté d’importantes séances à cause des changements de dernière minute survenus après la programmation de leur voyage. Être présent toute la semaine est le seul moyen d'éviter ce désagrément.

Si vous ne trouvez pas de réunions intéressantes toute la semaine, vous pouvez toujours profiter au mieux de la réunion de l’IETF en travaillant entre les séances. La plupart des participants à l’IETF apportent leur ordinateur portable et il n’est pas rare d’en voir plusieurs d’entre eux dans la salle des terminaux ou dans les couloirs pendant les réunions. Il y a souvent une bonne couverture Internet sans fil dans de nombreux endroits de l’espace de réunion (restaurants, cafés, etc.). La lecture du courrier électronique est devenue une pratique courante parmi les participants à l’IETF.

3.3 Formation des nouveaux venus

Les nouveaux venus sont encouragés à participer à la réunion d’orientation du dimanche après-midi qui leur est spécialement destinée. Cette réunion d'orientation est organisée par l'équipe EDU de l'IETF, elle permet de recueillir les premières informations utiles. La réunion couvre les sujets tels que la signification des pastilles sur les badges, la structure de l'IETF et beaucoup d'autres éléments essentiels et instructifs pour les débutants à l’IETF.

Plus tard dans l’après-midi a lieu une réception d’accueil exclusivement réservée aux nouveaux arrivants et aux présidents des groupes de travail. Il s’agit d’un endroit idéal pour essayer de rencontrer des gens compétents dans les domaines qui vous intéressent. N'hésitez pas à vous adresser à un président de groupe de travail, pas forcément celui de votre domaine, afin d’en savoir plus sur son groupe de travail ou pour qu’il vous aide à trouver quelqu’un dans le vôtre.

3.4 Code vestimentaire

Puisque les participants doivent porter leur badge avec leur nom, autant porter une chemise ou un chemisier. Les pantalons ou jupes sont également fortement recommandés. Plus sérieusement, de nombreux participants qui viennent pour la première fois se trouvent gênés en arrivant en costume le lundi matin lorsqu'ils découvrent que tout le monde est en t-shirt, jean (ou en short si le temps le permet) et sandales. Il y a bien sûr à l'IETF ceux qui refusent absolument de porter autre chose que leur costume. Fort heureusement, ils seront pardonnés pour ce particularisme au profit d'une reconnaissance de leur travail. La règle générale est de s'habiller en fonction du temps qu'il fait, à moins que vous prévoyiez de travailler si dur que vous resterez cloîtré, auquel cas la règle qui s’applique est « habillez-vous à votre aise » !

3.5 Réunions de groupes de travail

Le cœur d'une rencontre de l'IETF sont les réunions des groupes de travail. Les différents présidents des groupes de travail ayant leur propre style, il est impossible de généraliser la façon dont une réunion de groupe de travail se déroule. Même si presque tous les groupes de travail ont des programmes de réunions, certains s’y tiennent fermement alors que d’autres les suivent à peine.

Il y a quelques éléments importants qui sont vrais pour toutes les réunions des groupes de travail lors d’une rencontre de l’IETF. Au début de la réunion, le président fait circuler des « feuilles bleues » qui sont des formulaires sur lesquels chaque participant inscrit son nom et son adresse e-mail. Elles sont archivées et ont pour but de connaître le nombre de participants à une réunion donnée et, dans de rares cas, pouvoir les identifier. En règle générale, il faut regarder d’où viennent les feuilles bleues et les faire passer dans le même sens.

Pour prendre la parole dans une réunion, dirigez-vous toujours vers les micros placés dans la salle. Pour les sujets controversés, les personnes feront la queue au micro, mais n’hésitez pas à être le premier si vous avez une question à poser ou une contribution à apporter à la discussion. Le président du groupe de travail ou le présentateur vous dira à quel moment vous pourrez prendre la parole. Bien qu'il soit plus facile de simplement lever la main de l'endroit où vous êtes assis, les micros sont très utiles et permettent aux participants en ligne et dans la salle d’entendre vos questions ou commentaires. Pensez également à donner votre nom avant d’intervenir pour permettre à la personne qui rédige le compte-rendu de savoir qui parle.

3.6 Signification des badges

Certaines personnes à l'IETF portent une petite pastille de couleur sur leur badge. Seule une petite minorité en porte plusieurs. Ces pastilles sont là pour identifier ceux qui sont assez fous pour fournir bénévolement beaucoup de travail supplémentaire. Les couleurs ont les significations suivantes.

Couleur Signification
Bleu animateur d'un groupe de travail ou d'une BOF
Vert groupe d’accueil
Rouge membre de l’IAB
Jaune membre de l’IESG
Orange membre du comité de nomination
Violet IAOC
Rose IRSG
Bleu sarcelle RSE

(Les journalistes portent des badges de couleur orange.)

Les membres de l'organisme qui accueille pourront vous renseigner sur la salle des des terminaux, les restaurants et autres points d'intérêt aux alentours.

Il est important lorsque l'on vient pour la première fois de ne pas hésiter à interpeller les personnes qui portent ces badges. Si les membres de l’IAB et de l’IESG et les présidents des groupes de travail et BOF ne voulaient pas communiquer, ils ne porteraient pas ces badges en évidence. Notez cependant que les réunions de l’IETF sont généralement des moments intenses pour les directeurs de domaines (AD, Area Directors). Si vous vous adressez à un AD au cours d’une réunion de l’IETF, dans la plupart des cas il vous demandera de lui envoyer un courriel environ deux semaines plus tard. De même, lorsque vous entamez une conversation informelle avec un directeur de domaine (ou même un président de groupe de travail d’ailleurs), il est souvent bon de lui donner environ 30 secondes de contexte pour la discussion.

3.7 Salle des terminaux

Une des choses essentielles (selon votre point de vue) qu'apporte la structure d'accueil est l'accès Internet à tous les participants. En général, la connectivité sans fil est excellente dans toutes les salles de réunion et dans la majorité des espaces communs, de plus la connectivité par câble est disponible dans la salle des terminaux. Toutes les personnes et les entreprises qui fournissent du matériel, des services et du temps peuvent être remerciées chaleureusement.

Bien que nous encouragions la préparation des réunions très en amont, il se peut qu'un travail de dernière minute soit nécessaire. La salle des terminaux est l’endroit propice. Elle peut également servir à rédiger un rapport du séjour ou un compte-rendu de réunion, tant que les choses sont encore fraîches dans les esprits.

Vous devez porter votre badge pour accéder à la salle des terminaux. La salle des terminaux est équipée de nombreuses multiprises, de prises réseau pour les portables, d’une connexion sans fil (pour ceux qui n’ont pas besoin d’Ethernet mais de puissance), d'une imprimante et parfois de postes de travail. Par contre, on n'y trouve pas de « terminaux » malgré le nom qui lui a été attribué. Le service d’assistance dans la salle des terminaux est l’endroit idéal pour poser des questions sur les pannes de réseau, même si l’on vous demande de vous adresser au personnel technique.

3.8 Repas et autres plaisirs

Marshall Rose fit un jour la remarque que l'IETF était un endroit branché pour les amateurs de bonne cuisine. Bien qu'il soit exact que certaines personnes profitent de copieux repas, ils se chargent eux-mêmes d'en composer le menu ; les repas du midi et les dîners ne sont pas compris dans les frais d'inscription. Le secrétariat fournit les amuse-gueules à la réception d'accueil du dimanche (qui ne sont toutefois pas censés remplacer un dîner), les petits déjeuners du lundi au vendredi matin (selon le lieu de la réunion) et les (meilleurs) cookies, brownies, fruits et autres gourmandises pendant les pauses de l'après-midi. Ceux-ci sont très souvent pris en charge par l’organisateur de la réunion ou un sponsor.

Si vous préférez prendre vos repas à l'extérieur de l'hôtel, l'organisme d'accueil local fournit habituellement une liste de restaurants à proximité du lieu de réunion.

3.9 Soirée de gala

La soirée de gala (Social Event) de l’IETF est un autre aspect important des services fournis par l'organisme d'accueil local. Il peut s'agir d'un événement lié à l'informatique, ou la soirée peut avoir lieu dans un musée d’art ou encore une salle de réception. Notez, cependant, que toutes les réunions de l’IETF ne proposent pas de soirées de gala.

Nous encourageons les nouveaux participants à se joindre à cet événement. Il est recommandé de porter le badge nominatif et délaisser son ordinateur portable. L'événement social est conçu pour permettre aux gens de se rencontrer de façon conviviale, hors du cadre technique.

3.10 Ordre du jour

Le programme des réunions de l'IETF est très fluctuant. Il est disponible sur le Web quelques semaines avant la réunion. Des programmes miniatures sont disponibles au comptoir d’accueil pour ceux qui ont une bonne vue et veulent avoir un exemplaire dans leur poche ou au verso de leur badge. Évidemment, « définitif » n’a pas le même sens à l’IETF que partout ailleurs dans le monde. Le programme définitif désigne simplement la version envoyée à l’imprimeur. Le secrétariat affichera les modifications du programme sur le panneau situé à proximité du comptoir d'accueil (celui de la réunion, pas celui de l'hôtel). Ces changements tardifs ne sont pas des caprices : ils sont faits « juste à temps » au fur et à mesure que les présidents de séances et les intervenants sont informés des contretemps. L’IETF est trop dynamique pour que les programmes soient fixés des semaines à l’avance.

Un plan de situation des salles de réunion figure également sur le programme. L’attribution des salles de réunion peut changer avec le programme. Certains groupes de travail se réunissent plusieurs fois dans la semaine et dans la mesure du possible une salle unique leur est attribuée.

3.11 L'EDU à la rescousse

Si vous avez toujours des inquiétudes sur certains aspects de l’IETF (même après avoir lu le Tao), vous devriez vous tourner vers la formation proposée par l’équipe éducationnelle (EDU). Elle est destinée autant aux nouveaux arrivants qu’aux anciens de l’IETF. Outre la formation pour débutants, l’équipe EDU propose des ateliers pour les rédacteurs de documents et les présidents de groupes de travail, de même qu’un tutoriel de sécurité indispensable pour les nouveaux et anciens participants de l’IETF. Les cours EDU ont généralement lieu les dimanches après-midi. Vous trouverez plus d’informations concernant l’équipe EDU sur http://www.ietf.org/edu/.

3.12 Où est ma place ?

L'IETF ne signifie pas la même chose pour tout le monde. De nombreuses personnes ont été très actives sans jamais assister à une seule rencontre IETF. Vous ne devez pas vous sentir obligé de venir à une réunion dans le seul but de vous faire une idée de l'IETF. Les indications suivantes (basées sur une classification des acteurs de l'industrie) peuvent vous aider à décider si vous tenez vraiment à faire le déplacement et si oui, à utiliser au mieux votre temps lors de votre première réunion.

3.12.1 Responsables industriels

Comme évoqué précédemment, une rencontre de l'IETF n'est en rien comparable aux salons professionnels que vous connaissez. Les réunions de l’IETF sont le dernier endroit où vous rendre si votre intention est de découvrir quels seront les prochains enjeux industriels de l'Internet. Au contraire, assister aux travaux des groupes de travail ne rendra que plus confuse la situation actuelle ou à venir de ces enjeux.

Il ne s'agit pas d'affirmer que les acteurs de l'industrie n'ont pas leur place dans les réunions IETF. En tant que responsable industriel, il peut être pertinent d'y envoyer les personnes responsables des technologies en cours de développement à l’IETF. Si elles consultent les travaux en cours (avant-projet Internet) et sont abonnées aux listes de diffusion des groupes de travail les concernant, elles seront en mesure de juger de l'utilité de leur présence pour leur société ou au sein des groupes de travail.

3.12.2 Opérateurs de réseaux et fournisseurs d'accès Internet

La gestion d'un réseau est suffisamment complexe sans que l'on ait à se débattre avec de nouveaux protocoles ou les nouvelles versions de protocoles que vous utilisez déjà. Si le type de réseau que vous développez requiert constamment les machines et les logiciels les plus performants et que vous suiviez assidûment les travaux des groupes de travail s’y rattachant, vous jugerez peut-être les réunions IETF intéressantes. Une grande partie des travaux de l’IETF couvre également plusieurs autres aspects des opérations des fournisseurs d’accès Internet et des grandes entreprises, et la contribution des opérateurs est très précieuse pour que ces travaux soient dynamiques et pertinents. La plupart des documents de qualité de l’IETF proviennent de la contribution des opérateurs et non des fournisseurs et des universitaires.

3.12.3 Matériel de réseau et fournisseurs de logiciels

L'image de l'IETF vue comme la tour d'ivoire de quelques universitaires reflétait peut-être une certaine réalité dans le passé mais aujourd'hui la plupart des participants sont issus de l'industrie. Dans la plupart des domaines d'activité de l'IETF, ce sont les salariés des distributeurs qui rédigent les protocoles et animent les groupes de travail. Il est donc normal que les fournisseurs y participent. Si vous êtes fabricant de matériel ou de logiciel Internet et que jamais personne de votre entreprise n'a assisté à une réunion IETF, il vous appartient de venir, ne serait-ce que pour dire autour de vous si cela a apporté ou non quelque chose à votre entreprise.

Cela ne signifie pas que les entreprises concernées doivent baisser le rideau durant la semaine des rencontres IETF pour que tout le monde puisse y assister. Les personnels du marketing et même ceux du marketing technique peuvent sans problème rester à l'écart dans la mesure où des techniciens sont envoyés pour participer. De même qu'il est plutôt inutile d'envoyer tout le personnel d'un département technique, dans la mesure où tous ne lisent pas les documents ou ne suivent pas les travaux des groupes sur les listes de diffusion. La plupart des entreprises ont désigné quelques personnes en fonction de leur aptitude à fournir des comptes rendus détaillés et utiles de leur participation. En outre, de nombreuses entreprises disposent de méthodes de coordination interne et d’une stratégie de normalisation. Une entreprise qui dépend de l’Internet pour mener une partie ou la totalité de ses activités aura certainement une stratégie IETF.

3.12.4 Universitaires

Les réunions de l'IETF sont généralement très utiles aux chercheurs en informatique qui y découvrent les protocoles sur le point de sortir. Les professeurs ainsi que les étudiants de troisième cycle qui mènent leur recherche dans le domaine des réseaux et de la communication peuvent obtenir une mine d'informations en participant aux groupes de travail qui les concernent. Se promener d'un groupe de travail à l'autre peut être aussi enrichissant que de se rendre à un symposium ou à un séminaire organisé par votre département d'étude. Les chercheurs peuvent aussi être intéressés par les activités de l’IRTF.

3.12.5 Presse spécialisée

Si vous travaillez pour la presse et souhaitez suivre une rencontre de l'IETF, vous trouverez dans le Tao un chapitre tout spécialement conçu à votre intention. — Rendez-vous au chapitre Section 8.2.

3.13 Comptes-rendus

Les comptes-rendus de l'IETF sont réalisés dans les deux mois suivant chaque rencontre et sont disponibles sur le web. Ne les ratez pas — ils contiennent des informations sur l'IETF que vous ne trouverez nulle part ailleurs. Par exemple, vous trouverez des photographies actualisées de la plupart des chartes des groupes de travail en vigueur à la date de la rencontre, permettant de mieux saisir l'évolution des travaux.

Les comptes-rendus commencent souvent par un édito éclairant (et très distrayant). Chaque édition contient le programme final (rétrospectivement mis à jour), une présentation de l'IETF, les rapports d'activité par domaine et groupe de travail ainsi que les diapositives des présentations techniques et des protocoles. Les présentations et comptes-rendus des groupes de travail sont parfois incomplets lorsque les épreuves n'ont pas été remises à temps au secrétariat pour leur publication.

Les comptes-rendus contiennent aussi la liste des participants avec leur nom et coordonnées tels qu'ils ont été indiqués sur le formulaire d'inscription. Pour savoir comment obtenir une copie des comptes-rendus, consultez le web à cette adresse http://www.ietf.org/meeting/proceedings.html.

3.14 Autres généralités

Les membres de l’IETF sont généralement très facilement accessibles. N'hésitez pas à les approcher et à vous présenter. De même, n'ayez aucune crainte à poser vos questions, surtout s'il s'agit de comprendre le jargon et les acronymes.

Les conversations informelles sont très importantes. Une part significative du travail réalisé se fait de manière tout à fait efficace par des gens qui discutent ensemble entre deux réunions ou pendant les déjeuners et les dîners. Chaque minute qui passe à l'IETF peut être considérée comme du travail (au grand dam de certains).

Une réunion parallèle (appelé historiquement mais inexactement « bar BOF ») est un rassemblement informel entre les réunions des groupes de travail, tard dans la soirée, au cours duquel on travaille beaucoup. Ces « bars BOF » fleurissent un peu partout sur place, dans les restaurants, les cafés, les espaces inutilisés et autour d’une piscine (si on a la chance d’en disposer).

Il serait périlleux de s'interposer entre un participant affamé (ce qui est souvent le cas) et les brownies et cookies servis pendant la pause café, quel que soit l'intérêt de la conversation. Steve Coya, le premier directeur général de l’IETF, disait souvent : « Prenez votre cookie et éloignez-vous de la table. »

Les membres de l’IETF sont farouchement indépendants. C’est pourquoi il faut plutôt demander le point de vue des autres que d’imposer le vôtre.

Les réunions IETF, et en particulier la session plénière, n'est pas le bon endroit lorsqu'un distributeur cherche à vendre ses produits. On peut tout à fait renseigner les autres sur son entreprise et ses produits, mais en gardant à l'esprit que l'IETF n'est pas une foire commerciale. Ce qui ne veut pas dire que l'on ne puisse pas rentrer dans ses frais en vendant des articles liés à l'IETF : T-shirts, pins et protège-poches.

Il y a toujours une table pour la distribution de documentation près du comptoir d’accueil. Cette documentation regroupe toutes les informations utiles aux participants (par exemple, une copie des travaux en cours dans un groupe de travail ou un descriptif du contenu en ligne sur le site de l'IETF). Veuillez consulter le secrétariat avant de placer vos informations à cet endroit. Le secrétariat se réserve le droit de retirer toute documentation jugée inappropriée.

Si vous utilisez votre ordinateur portable lors des réunions, prévoyez une batterie supplémentaire. Il n’est pas toujours évident de trouver une prise de courant disponible dans certaines salles de réunion et l’utilisation de l’accès sans fil peut décharger votre batterie plus vite que vous ne le pensez. Si vous êtes assis à côté d’une prise dans une salle de réunion, vous serez appelé à brancher et débrancher les équipements de vos voisins. Certaines personnes apportent une rallonge avec une multiprise, ce qui est une bonne façon de se faire des amis pendant une réunion. Si vous avez besoin d’un adaptateur, essayez de l’acheter à l’avance car celui qu’il vous faut est généralement plus facile à trouver dans votre pays d’origine.


4. Groupes de travail

La plus grande partie du travail effectué à l'IETF se passe dans les groupes de travail. Ils sont au nombre de 115 à la date de création de ce document. [BCP25]Le document « IETF Working Group Guidelines and Procedures » est une excellente ressource pour quiconque participe à une discussion de groupe de travail.

Un groupe de travail n’est rien d’autre qu’une liste de diffusion modérée. Vous rejoignez un groupe de travail en vous inscrivant sur une liste ; toutes les listes sont publiques. Certaines de ces listes permettent seulement aux inscrits de poster des messages, d'autres sont ouvertes aux contributions extérieures. Chaque groupe de travail est dirigé par un ou deux (ou rarement, trois) présidents.

Plus important encore, chaque groupe de travail possède une charte qu'il est censé respecter. Elle établit le cadre de travail ainsi que les objectifs du groupe. La liste de diffusion d'un groupe et les réunions en face à face sont supposées traiter des thèmes inscrits dans la charte en évitant de s’éparpiller sur d'autres sujets passionnants. Un coup d'œil de temps en temps en dehors du cadre établi peut parfaitement être utile, mais la grande majorité des débats doit porter sur les sujets inscrits dans la charte. De fait, certains groupes de travail n'hésitent pas à spécifier ce qu'ils ne feront pas, comme c'est parfois le cas lorsque des idées intéressantes mais nébuleuses surgissent pendant la rédaction de la charte. La liste des chartes de l'ensemble des groupes constitue une littérature intéressante pour qui veut connaître les activités des groupes de travail en cours.

4.1 Présidents des groupes de travail

Le rôle des présidents des groupes de travail est décrit dans [BCP11] et [BCP25].

En tant que bénévole, la mission principale d’un président est de déterminer les objectifs de consensus et les étapes du groupe de travail tout en maintenant la charte à jour. Ensuite, souvent avec l’aide des secrétaires du groupe de travail ou des rédacteurs, le président gère les discussions du groupe de travail, aussi bien sur la liste qu’en convoquant des réunions lorsqu’il le juge nécessaire. Certaines discussions deviennent interminables et il incombe au président d’orienter les gens vers une interaction fructueuse. Il se prononce s’il y a un consensus et met fin à la discussion. Il arrive parfois que des présidents engagent également des échanges avec des participants non issus d’un groupe de travail ou des membres de l’IESG, surtout lorqu’un document est prêt à être publié. Les présidents ont la responsabilité de la qualité technique et non technique des résultats du groupe de travail. Comme vous pouvez l’imaginez, compte tenu de la diversité des demandes administratives, interpersonnelles et techniques, certains présidents de groupes de travail sont plus à l’aise que d’autres dans leur travail.

Les présidents des groupes de travail sont fortement encouragés à se rendre à la formation de leadership qui se déroule habituellement le dimanche précédant la réunion de l’IETF. Il y a également un déjeuner de sensibilisation en milieu de semaine au cours duquel des sujets spécifiques sont présentés et traités. Si vous êtes intéressé par ce qui se dit à ce moment-là, vous pouvez consulter les diapositives surhttp://edu.ietf.org.

4.2 Avancer dans les groupes de travail

Un des aspects déroutants lorsque l'on découvre l'IETF est l’importance mineure accordée aux réunions en face à face des groupes de travail, ce qui n'est généralement pas le cas dans la plupart des autres organisations. Toute décision prise lors d'une réunion doit également être approuvée sur la liste de diffusion du groupe de travail. Il existe de nombreux exemples où un choix majeur décidé en réunion a ensuite été rejeté par la liste de diffusion ; souvent parce qu'une personne qui n'était pas présente ce jour-là a ensuite relevé une sérieuse incohérence dans la démarche amenant à la décision. Enfin, les réunions des groupes de travail ne sont pas des séances de rédaction de document, comme cela se fait dans d’autres organismes de standardisation : à l’IETF, la rédaction de document se fait ailleurs.

Un autre aspect des groupes de travail souvent mal interprété est le fait qu'il n'existe pas de vote formel. La règle générale pour aboutir sur un sujet en cours de discussion est de parvenir à un consensus approximatif, ce qui signifie qu'une très large majorité des personnes concernées par le débat approuvent la décision. La méthode employée pour déterminer ce consensus varie d'un groupe de travail à l'autre. Quelquefois, ce consensus est déterminé par des bruits. — Si vous approuvez une proposition, vous émettez un bruit particulier lorsque le président vous y invite. La plupart des questions à « bruits » demande deux types de réponse : vous faites un type de bruit si vous approuvez la proposition, ou alors vous en faites un autre pour exprimer votre désaccord. Les nouveaux arrivants trouvent cela bizarre, mais ça marche. Il Il appartient au président de décider quand le groupe de travail a atteint un consensus approximatif.

Si l'absence de vote a pu prolonger le temps nécessaire pour aboutir à certaines décisions, la plupart des membres de l'IETF qui ont pratiqué le consensus approximatif après d'âpres débats sont convaincus de son efficacité pour aboutir à de meilleurs résultats. (Et à bien y réfléchir, comment voter dans un groupe ouvert à tout le monde et où il est impossible de compter le nombre exact de participants ?) Le consensus approximatif a été défini dedifférentes façons. L’une des plus simples est qu’à chaque fois qu’il y a une objection sérieure, il faudra en débattre jusqu'à ce que la majorité se rende compte du non fondement del’objection.

Certaines personnes pensent que leurs propositions doivent être discutées au sein du groupe de travail, même si les présidents n’en voient pas l’opportunité. Par exemple, si le travail proposé ne fait pas vraiment partie du cadre de la charte, les présidents des groupes de travail peuvent limiter la discussion de la proposition afin que le groupe de travail reste concentré sur l’objectif visé par la charte. Ceux qui pensent qu’un groupe de travail doit aborder un sujet considéré comme sortant du cadre de la charte par les présidents des groupes de travail, peuvent faire part de leurs préoccupations au directeur de domaine (AD) responsable ; l’AD peut convenir d’ajouter la proposition à la charte, ou confirmer qu’elle existe déjà dans la charte, ou que les présidents des groupes de travail ont raison et que le participant doit en discuter en dehors du groupe de travail.

Lorsqu’un document d’un groupe de travail a été minutieusement examiné, il passe généralement par un dernier appel à commentaires (appelé WGLC, Working Group Last Call). Il s’agit pour le groupe de travail de régler les problèmes pour la dernière fois (on l’espère). Parfois, le WGLC soulignera tellement de problèmes qu’il faudra un deuxième WGLC après avoir révisé le document. Il n’y a pas de règles formelles pour le déroulement d’un WGLC ni même si un WGLC est nécessaire : il revient aux présidents des groupes de travail d’en décider.

Une autre méthode adoptée par certains groupes de travail consiste à nommer un secrétaire pour s’occuper des documents et y apporter les modifications nécessaires. Le secrétaire peut traiter le suivi des problèmes le cas échéant, ou simplement veiller à ce que toutes les décisions prises sur la liste de diffusion soient reportées dans les nouvelles versions des documents.

Lorsqu'un groupe de travail a rempli les objectifs inscrits à sa charte, il est censé interrompre ses activités. (La plupart des listes de diffusion continuent d'exister après la clôture d'un groupe de travail, prolongeant les discussions sur les mêmes sujets.) À l'IETF, la clôture d'un groupe est synonyme de succès puisque cela signifie qu'il a rempli la mission définie par sa charte. C’est un des aspects les plus déroutants pour ceux qui rejoignent l'IETF en ayant déjà l'expérience d'autres organismes de standardisation. Malgré tout, il arrive que certains présidents de groupes de travail ne parviennent pas à faire aboutir leur groupe de travail ou qu'ils ne cessent d'ajouter de nouvelles actions à la charte, ce qui peut prolonger l'existence du groupe de plusieurs années (ou dans certains cas, plusieurs décennies). Les résultats produits par ces groupes vieillissants sont souvent moins pertinents qu'ils ne l'étaient au début et leur apparence parfois embrouillée s'apparente à ce qu'on appelle alors le « syndrome de dégénérescence du groupe de travail ».

4.3 Documents des groupes de travail

Il existe une distinction officielle entre les documents des groupes de travail et les documents indépendants, mais dans la pratique, il n’y a pas de grande différence de traitement entre les documents. Par exemple, de nombreuses listes de diffusion des groupes de travail discutent aussi des documents indépendants (à la discrétion du président du groupe de travail). Les présidents des groupes de travail décident si les documents seront considérés comme des documents de groupe de travail et qui en seront les auteurs ou rédacteurs, le plus souvent en collaboration avec le groupe de travail et quelquefois avec le directeur de domaine. Ce processus peut être délicat dans la mesure où les gens sont nombreux à vouloir devenir l’auteur d’un document, mais peut être tout aussi difficile lorsque personne ne souhaite en être l’auteur et que la charte du groupe détermine une activité spécifique. Les procédures concernant les documents officiels (avant-projet Internet) seront traitées par la suite plus en détail dans ce document.

Certains groupes de travail ont des documents complexes ou des séries de documents complexes (ou même les deux). Corriger tous les bugs de ces documents n’est pas une tâche facile. Pour résoudre ce problème, certains groupes de travail se servent de « issue trackers » qui sont des listes en ligne sur lesquelles figurent les questions ouvertes portant sur les documents, la situation du problème, les corrections proposées, etc. L’utilisation d’un « issue tracker » permet au groupe de travail de ne rien oublier d’important, mais aussi de conserver une trace de pourquoi quelque chose a été fait d’une certaine façon.

Pour les documents du groupe de travail, le rédacteur est soumis au bon vouloir du président. Il y a souvent plus d’un rédacteur, surtout pour les documents complexes. Le rédacteur doit s’assurer que le contenu du document respecte les décisions du groupe de travail, notamment lors de la création d’un nouveau protocole ou d’une extension. Au cas où un rédacteur ne respecte pas le consensus du groupe de travail, le président du groupe se trouvera dans l’obligation d’opérer des changements correspondant au consensus ou de remplacer le rédacteur par quelqu’un de plus réactif au groupe de travail. Au fur et à mesure de l’avancement d’un document, les participants font part de leurs remarques sur la liste de diffusion du groupe de travail et les rédacteurs sont invités à suivre la discussion et à apporter les modifications quand il y a accord.

Lorsqu’un participant fait une contribution pertinente, le rédacteur ou le président peut l’inviter à devenir le co-éditeur, avec l’approbation des présidents du groupe de travail. Parfois, un groupe de travail considérera plusieurs alternatives avant de sélectionner un document particulier comme. Document du groupe de travail. Un groupe de travail trouvera souvent ses idées dans les différentes alternatives afin de créer un seul document du groupe de travail ; le cas échéant, le responsable décide des auteurs qui seront répertoriés sur la page titre et qui seront présentés comme les collaborateurs (-trices) dans le corps du document.

Quand un document du GT (Groupe de travail) est prêt à évoluer au-delà du GT, les responsables du GT nommeront un « berger » qui prendra en charge le processus final. Le rôle du berger associé au document est décrit dans [RFC4858].

4.4 Préparation aux réunions de groupes de travail

La chose la plus importante que tout le monde (nouveaux venus et experts temporaires) doit faire avant de se rendre à une réunion en face à face est de prendre connaissance des avant-projets Internet et des RFC (Requests for Comments ou demandes de commentaires) à l’avance. Les réunions du GT ne sont pas explicitement des séances de formation : ce sont des réunions pour développer les documents du groupe. Même si vous n’avez pas l’intention de parler lors de la réunion, vous devez lire, ou du moins passer en revue, les documents du groupe avant de participer à la réunion afin de comprendre ce qui se dit.

C’est au responsable du GT de décider de l’ordre du jour de la réunion, en principe plusieurs semaines à l’avance. Si vous souhaitez qu’un sujet soit abordé à la réunion, assurez-vous de le faire savoir au responsable. Les ordres du jour de toutes les réunions du GT sont disponibles à l’avance sur le site web de l’IETF, même si certains responsables de GT sont laxistes (pour ne pas dire totalement négligeants) quand il s’agit de les communiquer.

Le secrétariat programme des réunions pour les GT quelques semaines à l’avance seulement, et le programme change souvent dans des délais aussi courts qu’une semaine avant la première journée. Si vous vous déplacez pour une seule réunion du GT, il vous sera peut-être difficile de réserver votre billet d’avion aussi peu de temps à l’avance, en particulier si la date de la réunion du groupe de travail est modifiée. Assurez-vous de garder une trace de l’ordre du jour en cours afin de pouvoir réserver vos billets d’avion et vos chambres d’hôtel. Mais, à y regarder de plus près, vous ne devriez sans doute pas vous déplacer pour une seule réunion du GT. Il est probable que vos connaissances pourront être précieuses à plusieurs GT, étant entendu que vous aurez pris connaissance des avant-projets et des RFC de ces groupes.

Si vous être prévu à l’ordre du jour d’une réunion en face à face, vous devriez sans doute préparer quelques diapositives. Mais ne venez pas avec un tutoriel ; les participants sont censés avoir lu les avant-projets à l’avance. Des projecteurs pour effectuer des présentations à partir d’ordinateurs portables sont disponibles dans toutes les salles de réunion.

Et voici un conseil pour la présentation de vos diapositives en GT ou lors de séances plénières : ne placez pas le logo de votre entreprise sur chaque diapositive, même s’il s’agit d’une pratique courante hors de l’IETF. L’IETF fait les gros yeux à ce genre de publicité d’entreprise (exception faite du sponsor de la réunion lors de la présentation en plénière), et la plupart des personnes qui présentent ne mettent même pas leur logo sur la diapositive d’ouverture. L’IETF s’intéresse au contenu technique, pas au prosélytisme d’entreprise. Les diapositives sont souvent en noir et blanc pour faciliter la lisibilité et les couleurs sont utilisées uniquement pour rendre les choses encore plus claires. Une fois encore, le contenu est l’élément le plus important des diapositives, pas la manière dont celles-ci sont présentées.

Une chose que vous pourriez trouver utile, et peut-être même amusante, pendant les séances du groupe de travail est de suivre les commentaires en continu dans le salon de discussion associé au groupe de travail. Le commentaire en continu sert souvent de base à la rédaction des minutes de la réunion, mais il peut également faire état de blagues, de soupirs et autres paroles superflues. Jabber est une technologie XML de flux gratuit utilisée principalement pour la messagerie instantanée. Vous pouvez trouver des indicateurs vers des clients Jabber sur de nombreuses plateformes à l’adresse suivantehttp://xmpp.org/xmpp-software/ clients. Les salons de discussion prennent le nom du groupe de travail suivi de "@jabber.ietf.org". En réalité, ces salons sont disponibles toute l’année, et pas seulement pendant les rencontres de l’IETF, et certains sont utilisés par des participants actifs du groupe de travail lors de la phase de développement du protocole.

4.5 Listes de diffusion des groupes de travail

Comme cela a été mentionné précédemment, l’annonce de l’IETF et les listes de diffusion pour la discussion constituent les listes de diffusion essentielles aux activités de l’IETF. Il existe cependant diverses listes de diffusion, en grand nombre, liées au travail de l’IETF. Par exemple, chaque groupe de travail a sa propre liste de diffusion. De plus, il existe des débats techniques inscrits dans la durée qui ont été déplacés de la liste de l’IETF vers des listes créées spécifiquement pour ces sujets. Il est vous fortement conseillé de suivre les discussions sur les listes de diffusion des groupes de travail auxquels vous souhaitez participer. Plus il y aura de travail accompli par le biais des listes de diffusion et moins il y aura de travail à faire pendant la réunion. ce qui permettra de débloquer du temps pour la pollinisation croisée (c’est-à-dire la participation à des groupes de travail en marge de l’intérêt principal des individus en vue d’élargir leurs perspectives).

Les listes de diffusion sont également un forum destiné à ceux qui souhaitent suivre, ou contribuer, aux efforts du groupe de travail, mais qui ne peuvent pas participer aux réunions de l'IETF. C’est pour cette raison que les procédures de l’IETF exigent que toutes les décisions soient confirmées « sur la liste » et que vous entendrez souvent un responsable de groupe de travail dire : « discutons-en sur la liste » pour clore une discussion.

Bon nombre de listes de discussion de l’IETF utilisent le « mailman » ou un autre gestionnaire de liste, Majordomo. Elles disposent généralement d’une adresse spéciale « -requêtes » pour la gestion des détails administratifs liés à l’inscription et à la désinscription sur la liste. (Voir Section 2.3 pour plus d’informations sur « mailman ».) Ces détails administratifs sont généralement mal vus quand ils apparaissent sur la liste de diffusion des discussions.

Les listes de discussion de l’IETF sont archivées. Autrement dit, tous les messages envoyés vers la liste sont automatiquement stockés sur un serveur hébergeur qui permet un accès HTTP ou FTP anonyme. Bon nombre de ces archives sont répertoriées en ligne à l’adresse suivante ftp://ftp.ietf.org/ietf-mail-archive ou elles se trouvent sur une archive basée web. Si vous ne trouvez pas la liste que vous cherchez, envoyez un message à l’adresse spéciale « -requêtes » de la liste (pas la liste elle-même). Les listes de la charte du groupe de travail à l’adresse suivante : http://datatracker.ietf.org/wg sont une source utile. http://www.ietf.org/wg/concluded est une liste d’anciens groupes de travail, terminés.

Certaines listes de groupe de travail définissent des limites en termes de volume pour les messages, notamment afin d’éviter que des présentations ou que des documents volumineux ne finissent dans la boîte aux lettres de tout le monde. Il est bon de se rappeler que les participants n’ont pas tous accès au haut débit (et même ceux qui ont accès au haut débit ont parfois un accès ralenti à leur courrier électronique lors de leurs déplacements), donc les messages les plus courts sont aussi les plus appréciés. Les documents peuvent être mis en ligne au titre d’avant-projets Internet ; les documents de présentation peuvent être mis en ligne sur un site web contrôlé par l’expéditeur ou envoyés personnellement aux individus qui le demandent. Certains GT créent des sites spéciaux pour conserver ces documents volumineux de sorte que les expéditeurs peuvent faire suivre leur document en premier, puis simplement envoyer l’URL du document à la liste.

4.6 Réunions de groupes de travail intermédiaires

Les groupes de travail organisent parfois des réunions intermédiaires entre les réunions IETF. Les réunions intermédiaires ne se substituent pas aux réunions de l’IETF, toutefois — un groupe ne peut pas décider de faire l’impasse sur une réunion qui a lieu dans un endroit que ne lui plaît pas et de se réunir à Cancun (ou même dans un endroit quelconque) trois semaines plus tard, par exemple. Les réunions intérimaires doivent être autorisées par un directeur de zone (DZ) et être annoncées au moins un mois à l’avance. Le lieu et le calendrier retenus doivent garantir un accès équitable à tous les participants. Comme pour les réunions habituelles de l’IETF, une personne doit prendre des notes et les membres du groupe doivent faire acte de présence. Les décisions provisoires prises lors d’une réunion intérimaire du GT doivent aussi être ratifiées sur la liste de diffusion.

Au cours des dernières années, certains groupes de travail ont commencé à organiser des « réunions virtuelles intermédiaires » par téléphone et / ou en ligne au lieu de rencontres en face à face. Les réunions virtuelles intermédiaires peuvent être utiles pour permettre aux groupes de travail de prêter attention à leur travail entre les rencontres habituelles de l’IETF en face à face, et pour que les coûts du présentiel soient beaucoup moins élevés que ceux des rencontres intermédiaires en face à face. Les réunions intermédiaires virtuelles sont soumises aux mêmes exigences de reporting que les rencontres virtuelles en face à face.

L’IESG dispose de règles concernant le dépôt de préavis dans les délais, le lieu des réunions intermédiaires du groupe de travail ainsi que le reporting des résultats des réunions. L’objet de ces règles est de rendre les réunions intermédiaires accessibles à autant de membres de groupes de travail que possible et de préserver la transparence du processus du groupe de travail.


5. Réunions BOF

Afin de former un groupe de travail, il vous faut une charte et une personne qui est capable de le diriger. Afin d’y parvenir, il vous faut intéresser des gens afin que ceux-ci puissent maintenir le cap de la charte et convaincre un Directeur de domaine de la valeur du projet. Une rencontre en face à face est utile pour cela. En réalité, peu de groupes de travail sont lancés par un Directeur de domaine ; la plupart démarrent après une réunion « Bird of a feather » (« qui se ressemble s’assemble ») en face à face parce que les participants ont manifesté leur intérêt pour le sujet.

Une réunion « Birds of a feather » (BOF) doit être approuvée par le directeur de domaine de la zone concernée avant d’être programmée. Si vous pensez avoir vraiment besoin d’un nouveau GT, soumettez votre proposition à un directeur de domaine de manière informelle et attendez de voir ce qu’il ou ce qu’elle pense. L’étape suivante concerne la demande d’un créneau horaire pour la réunion lors de la rencontre suivante en face à face. Bien évidemment, vous ne devez pas attendre cette réunion pour commencer à travailler, et pour créer une liste de diffusion, par exemple, et pour commencer à discuter de la charte.

Le registre des réunions BOF est très différent de celui des réunions du GT. Le but d’une réunion BOF est de s’assurer qu’une bonne charte et que de bons repères peuvent être définis et qu’il y a suffisamment de personnes prêtes à faire le travail nécessaire pour créer des normes. Certaines réunions BOF disposent d’avant-projets Internet en cours de rédaction, tandis que d’autres sont organisées à partir de rien.

L’avantage de disposer d’un avant-projet avant la réunion BOF est que celui-ci permet de maintenir le fil de la discussion. D’un autre côté, le fait de disposer d’un avant-projet peut avoir tendance à limiter ce que les autres personnes qui participent à la réunion BOF veulent faire avec la charte. Il est important de ne pas oublier que la plupart des réunions BOF sont organisées afin d’obtenir un soutien pour un éventuel groupe de travail, et non d’obtenir un soutien pour un document en particulier.

Bon nombre de réunions BOF ne débouchent pas sur la création d’un GT pour un certain nombre de raisons. Un problème courant est que le nombre de personnes qui s’accordent sur le cap à suivre pour le travail n’est pas suffisant. Une autre raison habituelle est que le travail ne peut pas aboutir à créer une norme — si, par exemple, les auteurs du document ne veulent vraiment pas céder le contrôle du changement à un GT. (Nous aborderons la question du contrôle du changement plus tard dans ce document.) Deux réunions BOF seulement peuvent être programmées pour aborder un sujet particulier ; soit un GT est formé, soit le sujet doit être abandonné.


6. RFC et avant-projets Internet

Si vous êtes un nouveau participant de l’IETF et que vous recherchez un RFC particulier ou un avant-projet Internet, rendez-vous sur les pages web de l’éditeur RFC, http://www.rfc-editor.org/rfc.html. Ce site contient également des liens vers d’autres collections RFC dont un grand nombre est doté de capacités de recherche. Si vous connaissez le numéro du RFC que vous recherchez, rendez-vous sur les pages RFC de l’éditeur RFC, http://www.rfc-editor.org/rfc.html. Pour les avant-projets Internet, une bonne ressource est le site web de l’IETF, https://datatracker.ietf.org/doc, qui vous permet d’effectuer une recherche à partir du titre et d’un mot-clé.

6.1 Faire publier un RFC

L’une des questions les plus fréquentes adressées aux participants expérimentés de l’IETF par les nouveaux venus est la suivante : « Comment puis-je faire publier une norme IETF ? » Une bien meilleure question est : « Dois-je écrire une norme IETF ? » car la réponse n’est pas toujours « oui ». Si vous décidez d’essayer de rédiger un document qui puisse devenir une norme IETF, soyez averti que le processus général peut être ardu, même si les étapes individuelles sont assez simples. Beaucoup de gens sortent cependant indemnes du processus et il existe de nombreux conseils écrits qui aident les auteurs à s’en sortir en sauvegardant leur égo plus ou moins intact.

Il vous faudra décider en priorité, entre autres, si vous souhaitez que votre document soit pris en compte par un groupe de travail, ou si vous souhaitez qu’il soit considéré comme une soumission individuelle (c’est-à-dire n’émanant pas d’un GT) faite à l’IETF. Même si la plupart des normes IETF proviennent de groupes de travail, certaines émanent d’efforts individuels : il se peut qu’aucun groupe de travail adéquat n’existe, ou qu’un groupe de travail potentiellement adéquat soit trop occupé par une autre activité pour tenir compte de votre idée.

Chaque norme IETF est publié en tant que RFC (« Request for Comments » ou demande de commentaires), et chaque RFC débute comme un avant-projet Internet (souvent appelé « I-D » ou simplement « avant-projet »). Les étapes élémentaires à suivre pour publier un document au titre de norme IETF sont les suivantes :

  1. Publier le document comme un avant-projet Internet.
  2. Recevoir des commentaires sur l’avant-projet.
  3. Modifier votre avant-projet en tenant compte des commentaires.
  4. Répétez les étapes 1 à 3 plusieurs fois.
  5. Demandez à un Directeur de domaine de transmettre l’avant-projet à l’IESG (s’il s’agit d’une soumission individuelle). Si l’avant-projet est une production officielle du groupe de travail, le responsable du GT demande au Directeur de domaine de le transmettre à l’IESG.
  6. Si le Directeur de domaine accepte la soumission, ils effectueront leur propre examen initial et pourront demander des mises à jour avant de le faire évoluer.
  7. Obtenez des bilans auprès d’une base élargie de membres de l’IETF. En particulier, certains domaines de l’IETF ont organisé des équipes de bilan pour vérifier les avant-projets qui sont déjà prêts à être envoyés à l’IESG. Deux des équipes de bilan les plus actives proviennent du Directorat de la sécurité (« SecDir ») et de l’équipe du bilan du domaine général (« Gen-Art »). N’oubliez pas que tous ces bilans permettent d’améliorer la qualité du RFC éventuel.
  8. Discutez des problèmes avec les membres de l’IESG. Leurs problèmes peuvent être résolus en apportant une réponse simple, ou ils peuvent impliquer des ajouts ou des modifications au document.
  9. Attendez que le document soit publié par l’éditeur RFC.

Une explication beaucoup plus complète des ces étapes est donnée dans [BCP9], « Le processus des normes de l’Internet ». Ceux qui rédigent des avant-projets en espérant que ceux-ci deviennent des normes IETF doivent lire le BCP 9 de manière à pouvoir suivre le parcours de leur document tout au long du processus. On peut suivre l’évolution sur le Datatracker (suivi des données) de l’IETFhttp://datatracker.ietf.org. Le BCP 9 (et autres documents divers qui le mettent à jour) entre dans le détail d’un sujet qui est souvent mal compris, y compris par les participants expérimentés de l’IETF : divers types de RFC suivent différents processus et obtiennent différents classements. Il existe six genres de RFC :

Seuls les deux premiers genres, proposés et complets, sont des normes au sein de l’IETF. Une bonne synthèse de cela est disponible à la rubrique justement intitulée[RFC1796], « Toutes les RFC ne sont pas des normes ».

Il existe également deux sous-genres de RFC, appelés « BCP » et « STD ». Les documents concernant les meilleures pratiques actuelles décrivent l’application de diverses technologies de l’Internet et sont également couramment utilisés pour documenter les nombreuses étapes du processus de l’IETF. Les sous-séries de FYI comprennent des « documents à valeur d’information » au sens défini dans la liste ci-dessus, auxquels est appliqué un marquage spécial. (Il existait également une sous-série RFC intitulée « Pour votre information » créée pour documenter les vues d’ensemble et les sujets d’introduction ou présentant un intérêt pour un large public ; cette série a cependant été officiellement supprimée.)

La sous-série RFC « STD » a été créée pour identifier les RFC qui précisent, en réalité, les normes Internet. Certains STD sont en réalité des séries de plus d’un RFC, et l’appellation « norme » s’applique à l’ensemble des documents.

6.2 Savoir céder élégamment

La raison principale pour laquelle certaines personnes ne veulent pas que leurs documents soient placés sur le parcours de mise aux normes de l’IETF est dû au fait qu’elles doivent abandonner le contrôle de modification du protocole. Autrement dit, dès que vous proposez de transformer votre protocole en une norme IETF, vous devez totalement abandonner le contrôle du protocole. S’il existe un accord général, certaines parties du protocole peuvent être complètement modifiées, des articles entiers peuvent être retirés, de nouvelles choses peuvent être ajoutées, et le nom peut être modifié.

Certains auteurs trouvent qu’il est difficile d’abandonner le contrôle de leur jouet. Si vous êtes l’une de ces personnes, n’essayez même pas de transformer votre protocole en une norme IETF. D’autre part, si votre objectif est la mise en œuvre la plus large de la meilleure norme possible, alors il se peut que le processus de l’IETF soit à votre goût.

Incidemment, le contrôle du changement des normes de l’Internet ne se termine pas quand le protocole est placé sur le parcours des normes. Le protocole lui-même peut être modifié ultérieurement pour un certain nombre de raisons dont la plus courante est que les personnes chargées de la mise en œuvre découvrent un problème au moment de la mise en œuvre de la norme. Cette les modifications ultérieures sont également sous le contrôle de l’IETF, et non sous celui des éditeurs du document concernant les normes.

les normes IETF existent afin que les utilisateurs les emploient pour rédiger des programmes Internet inter-opérationnel. Elles n’existent pas pour documenter les idées (sans doute merveilleuses) de leurs auteurs, ni pour qu’une entreprise puisse dire : « nous avons une norme IETF ». Si un RFC avec un parcours pour les normes fait l’objet d’une seule mise en œuvre (alors que deux mises en œuvre sont exigées pour avancer sur le parcours des normes), il était sans doute malvenu de le mettre sur le parcours des normes en premier lieu.

Veuillez noter que les nouveaux auteurs ne peuvent pas prendre le document d’un tiers et se l’approprier ; Consultez[BCP78], article 5.6, point (a).

6.3 Avant-projets Internet

Commençons par le commencement. Chaque document qui finit dans le référentiel RFC commence une nouvelle vie comme avant-projet Internet. Les avant-projets Internet sont des documents provisoires — ils sont destinés à faire l’objet de commentaires de la part des lecteurs, de sorte que les auteurs puissent réfléchir auxdits commentaires et choisir ceux qui intégreront l’avant-projet. Afin de rappeler aux gens leur caractère provisoire, les avant-projets Internet sont automatiquement retirés des répertoires actifs en ligne au bout de six mois. Ce ne sont assurément pas des normes. Comme cela est indiqué dans [BCP9]:

« Un avant-projet Internet n’est PAS un moyen de « publier » une spécification les spécifications sont publiées par le biais du mécanisme RFC.... Les avant-projets Internet n’ont aucun statut formel, et peuvent faire l’objet de modification ou de retrait à tout moment. Un avant-projet Internet ne doit en aucune circonstance être référencé dans un article, un rapport ou une demande de proposition ; de même un vendeur ne doit pas faire valoir la conformité à un avant-projet Internet. »

Il est toujours possible de dire à une personne qui ne comprend pas l’IETF (ou qui tente volontairement de duper les gens), au moment où il ou elle se vante d’avoir publié un avant-projet Internet ; que cela ne demande aucun effort particulier.

Quand vous soumettez un avant-projet sur Internet, vous cédez des droits de publication à l’ IETF. C’est comme cela que votre avant-projet Internet peut être mis à la disposition gratuitement de tous ceux qui veulent le lire et y apporter des commentaires. Les droits que vous cédez, ou pas, à l’IETF sont décrits à la rubrique [BCP78], « Droits de l’IETF sur les contributions ».

Il existe un outil de vérification très utile à l’adresse suivante : http://tools.ietf.org/tools/idnits. L’utilisation de cet outil avant de mettre un avant-projet sur Internet vous permettra d’éviter que ledit avant-projet ne soit rejeté en raison d’erreurs de forme ou de mise en page.

Un I-D (Internet-Draft ou avant-projet Internet) doit être approximativement au même format qu’un RFC. Contrairement à ce que pensent beaucoup de gens, un I-D ne doit pas nécessairement avoir la même apparence qu’un RFC, mais si vous le pouvez, employez les mêmes procédures de formatage que pour l’éditeur RFC quand vous créez vos avant-projets Internet, cela simplifiera le travail de l’éditeur RFC quand votre essai est publié en RFC. [RFC2223], « Instructions pour les auteurs RFC », décrit le format de la soumission. Il existe également un outil appelé « xml2rfc », Disponible à l'adresse : http://xml.resource.org, qui prend le texte formaté XML et le transforme en un avant-projet Internet valide.

Un avant-projet Internet peut être soit un groupe de travail soit une soumission individuelle. Les avant-projets du groupe de travail sont en général révisés par le groupe de gravail avant d’être acceptés comme article GT, bien que les responsables aient le dernier mot.

Si cela vous intéresse de vérifier le statut d’un avant-projet particulier, ou si vous ne vous rappelez pas du nom exact, ou voulez savoir sur quel avant-projet un GT travaille, deux outils sont disponibles. L’ « interface Base de données avant-projet Internet » , sur https://datatracker.ietf.org/doc, vous permet de faire des recherches sur un avant-projet par auteur, par groupe de travail, par date, ou par nom de fichier. Ceci est particulièrement utile pour les auteurs qui veulent suivre l’avancement de leur avant-projet au cours du processus de publication.

Il existe des règles informelles pour la dénomination d’avant-projets Internet qui ont évolués au cours des années. Les avant-projets Internet qui examinant des RFC existants ont souvent des noms avec « bis » signifiant « une fois de plus » ou « deux fois » ; par exemple un avant-projet peut être appelé « draft-someone-rfc2345bis-00.txt ».

6.3.1 Lectures recommandées pour les auteurs

Avant de créer la première version de votre avant-projet internet, vous devez lire quatre documents :

Vous devriez également visiter les pages Web des outils IETF,http://tools.ietf.org, où vous trouverez des pointeurs vers d’autres outils qui automatiseront certaines de vos tâches pour l’IETF.

6.3.2 Noms de fichiers et autres sujets

Une fois que vous êtes prêt à soumettre votre avant-projet internet, envoyez-le à http://datatracker.ietf.org/submit. Les instructions de cette page Internet vous guideront à travers les étapes nécessaires, et vous trouverez également une adresse email en cas de besoin.

Lorsque vous soumettez la première version de votre avant-projet, vous communiquez également à l’administrateur de votre avant-projet le nom proposé pour ce dernier. Si l’avant-projet est une produit officiel d’un groupe de travail, son nom commencera par « draft-ietf- » suivi de la désignation du GT, puis par un ou deux mots de description, suivis de « 00.txt ».

Par exemple, un avant-projet dans le GT S/MIME sur la création de clés peut être nommé « draft-ietf-smime-keying-00.txt ». Si ce n’est pas le produit d’un groupe de travail, le nom commencera par « draft » et le nom d’un des auteurs suivi d’un ou deux mots de description, suivi de « 00.txt ». Par exemple, un avant-projet écrit par quelqu’un dont le nom est Smith peut être nommé « draft-smith-keying-00.txt ». Si un avant-projet est une soumission individuelle mais est relatif à un groupe de travail, les auteurs font parfois suivre leur nom du nom de leur groupe de travail, tel que « draft-smith-smime-keying-00.txt ». Si vous suivez les directives énoncées sur http://www.ietf.org/ietf/1id-guidelines.txt, il y a de grandes chances que le nom du fichier soit bon.

Après la première édition d’un avant-projet, le numéro du nom de fichier est incrémenté ; par exemple, la seconde édition de l’avant-projet S/MIME nommé ci-dessus sera « draft-ietf-smime-keying-01.txt ». Notez qu’il existe des cas où le nom de fichier change après une ou plusieurs versions, comme quand un effort personnel est investi dans le groupe de travail ; quand un fichier voit son nom changer, le numéro redevient -00. Les présidents de GT communiqueront aux administrateurs d’avant-projet Internet l’ancien nom de l’avant-projet en présence d’un tel changement pour que les bases de données restent exactes.

6.4 RFC de suivi de normes

La procédure pour créer et faire progresser une norme est décrite dans [BCP9]. Une fois qu’un avant-projet Internet a été suffisamment discuté et et qu’un consensus reconnaît que c’est une norme utile, il est présenté à l’IESG pour être pris en compte. Si l’avant-projet est un avant-projet de GT officiel, le GT l’envoie au Directeur de domaine concerné. Si l’avant-projet est un soumission individuelle, l’auteur ou l’éditeur de l’avant-projet le soumet au Directeur de domaine concerné. BCP 9 décrit également le processus d’appel pour les personnes qui pensent que le responsable de groupe de travail, un Directeur de domaine, ou l’IESG a pris la mauvaise décision en considérant la création ou la progression d’une norme.

Une fois que l’avant-projet est soumis à l’IESG, celui-ci annonce un dernier appel concernant toute l'organisation (souvent abrévié « LC » pour last call ). Cela attire l’attention des gens qui n’ont pas suivi l’avancement de l’avant-projet, et qui pourraient éventuellement être à l’origine d’autres changements de l’avant-projet. Il s’agit également d’un moment où les personnes du GT, qui pensent ne pas avoir été entendues, peuvent faire leur commentaire devant tout le monde. Le dernier appel IETF est d’ au moins deux semaines pour les avant-projets provenant de GT et de quatre semaines pour les soumissions individuelles.

L’objectif du dernier appel de l’IETF est d’initier une discussion dans toute la communauté concernant les documents avant que l’IESG ne les prennent en considération. Notez le mot « discussion » à cet endroit. Il est généralement considéré comme malvenu d’envoyer des commentaires sur le dernier appel de l’IETF concernant des documents que vous n’avez pas lus, ou d’envoyer des commentaires sans être prêt à discuter votre point de vue. Le dernier appel de l’IETF n’est pas un vote, et les campagnes incitant les gens à apporter leur soutien ou leur opposition à un document ont généralement un effet pervers. Cela dit, les commentaires de dernier appel de l’IETF provenant de personnes qui viennent juste de lire le document pour la première fois exposent des problèmes que l’IETF et les GT n’avaient pas décelés, c’est pourquoi la discussion est ouverte à tous.

Si l’IESG approuve un avant-projet pour qu’il devienne un RFC de suivi des normes, ils demandent au rédacteur RFC de le publier comme projet de norme. En général, plusieurs choses se produisent à ce moment-là. Premièrement, il est fréquent de constater que certaines spécifications de la norme ont besoin d’être retravaillées car un réalisateur pensait qu’elles voulaient dire une chose tandis qu’un autre réalisateur pensait qu’elles voulaient dire autre chose. Un autre phénomène courant est le fait qu’aucune des mises en œuvre n’essaie de mettre réellement en place quelques aspects de la norme ; ces dispositifs sont retirés non pas seulement parce que personne ne les a testés mais surtout parce qu’ils n’étaient pas nécessaires.

Ne soyez pas surpris si une norme particulière ne progresse pas du statut de projet de norme à celui de norme Internet. Pour devenir une norme Internet, un RFC doit présenter plusieurs implantations interopérables et les fonctions inutilisées dans le projet de norme doivent être supprimées ; il existe d’autres conditions énumérées dans[BCP9]. La plupart des normes couramment utilisées sont des projets de normes qui ne progressent jamais. Cela peut être dû au fait que personne n’ait pris le temps d’essayer de les faire passer en norme Internet, ou au fait que certaines références normatives de la norme sont toujours en projet, ou encore parce que les gens ont des choses plus importantes à faire.

6.4.1 Dire les choses comme elles sont — utilisation de DOIT DEVRAIT et PEUT

La rédaction de spécifications qui seront mises en œuvre selon votre volonté est un art. Vous pouvez opter pour une spécification très concise, avec simplement une liste de conditions, mais cela a tendance à amener les réalisateurs à prendre trop de libertés. Si, au contraire, vous rédigez une spécification très élaborée avec de nombreuses suggestions, les réalisateurs tendent à passer à côté des exigences (et ne sont, de toute façon, pas d’accord avec vos suggestions). Une spécification optimale se situe à mi-chemin entre les deux.

Une façon d’encourager les développeurs à créer des mises en œuvre interopérables des normes consiste à être clair sur ce qui est précisé dans une spécification. Au départ, les RFC utilisaient toutes sortes d’expressions pour expliquer ce qui était nécessaire, les réalisateurs ne savaient donc pas toujours quelles parties étaient des suggestions et lesquelles étaient des exigences. Par conséquent, les auteurs de normes de l’IETF s’accordaient généralement à limiter leur énoncé à quelques mots particuliers avec peu de significations spécifiques.

[STD3], « Demandes pour les hôtes Internet -- application et support », écrit en 1989, présentait une courte liste de mots qui sont devenus utiles comme « doit », « devrait », et « peut ». Ces définitions ont été mises à jour puis peaufinées dans [BCP14], « Mots-clés à utiliser dans des RFC pour indiquer les niveaux d’exigences », ce qui est largement référencé dans les normes Internet actuelles. Le BCP 14 définit également spécifiquement « ne doit pas » et « ne devrait pas », et il énumère une liste de quelques synonymes pour les mots définis.

Concernant une norme, afin d’affirmer clairement que vous utilisez les définitions du BCP 14, vous devez faire deux choses. D’abord, se référer au BCP 14 (bien que la plupart des gens l’appellent RFC 2119, parce que c’est ce que le BCP 14 vous dit de faire), de sorte que le lecteur sache comment vous définissez vos termes. Deuxièmement, vous devez définir quels sont les formes du mot que vous utilisez et qui proviennent du BCP 14. La pratique admise pour cela consiste à écrire les mots en majuscules. C’est pour cela que vous voyez « DOIT » et « DEVRAIT » écrits en majuscules dans les normes IETF Internet actuelles.

Le BCP 14 est un document court, qui devrait être consulté par tous ceux qui lisent ou écrivent les normes IETF. Bien que les définitions de « doit » et « ne doit pas » soient assez claires, les définitions de « devrait » et « ne devrait pas » entraînent de longues discussions au sein de nombreux GT. En examinant un avant-projet Internet, la question suivante, « Cette phrase doit-elle comporter DOIT ou DEVRAIT ? » est souvent posée.C’est vraiment une bonne question, car les spécifications ne doivent pas renfermer l’expression DOIT inutilement, mais ne doivent pas non plus comporter de DEVRAIT quand un DOIT est nécessaire pour une question d’interopérabilité. La question de fond porte sur la sur-spécification et la sous-spécification des demandes dans les normes.

6.4.2 Références normatives dans les normes

Un aspect de l’écriture des normes IETF qui fait réagir de nombreux novices (ainsi que des participants à l’IETF de longue date) est la règle concernant la rédaction des « références normatives » à des documents non-IETF ou à d’autres RFC dans une norme. Une référence normative est une référence à un document qui doit être suivie afin que la norme puisse entrer en vigueur. Une référence non-normative (parfois appelée « référence informative ») est utile à un réalisateur mais n’est pas indispensable.

Une norme IETF peut faire une référence normative à n’importe quel autre RFC de suivi de norme qui se situe au même niveau de norme ou à un niveau plus élevé, ou à toute « norme ouverte » qui a été développée en-dehors de l’IETF. La règle de « même niveau ou de niveau plus élevé » signifie qu’avant qu’une norme puisse passer du statut de projet à celui d’avant-projet, tous les RFC pour lesquels il existe une référence normative, doivent aussi être en avant-projet ou constituer une norme Internet. Cette règle est décrite dans[BCP97]. Cette règle donne aux réalisateurs l’assurance que tout ce qui est contenu dans la norme Internet est stable, même ce qui est référencé en-dehors de la norme. Ceci peut également retarder la publication de l’avant-projet ou de la norme Internet de plusieurs mois (parfois même de plusieurs années) alors que d’autres documents rattrapent le retard.

Il n’y a pas de règle absolue concernant une « norme ouverte » mais en général, cela correspond à une norme stable dont tout le monde peut se procurer une copie (bien que cela puisse être payant) et qui a été rédigée par un groupe de normes généralement reconnu. Si la norme externe change, vous devez référencer l’instance particulière de cette norme dans votre spécification, avec une désignation de la date de la norme. Quelques organismes de normes externes ne mettent plus les anciennes normes à disposition ce qui représente un problème pour les normes IETF devant être utilisées à l’avenir. En cas de doute, l’auteur d’un avant-projet doit demander au responsable du GT ou au Directeur de domaine concerné si une norme externe particulière peut être utilisée dans une norme IETF.

6.4.3 Considérations de l'IANA

De plus en plus de normes IETF exigent l’enregistrement de divers paramètres de protocole, comme les options attribuées dans le protocole. Comme nous l’avons relevé dans Section 2.2.4, le registre principal pour toutes les normes IETF est depuis longtemps l’IANA. En raison des registres divers et variés exigés par les normes, l’IANA a besoin d’informations spécifiques sur la manière d'enregistrer les paramètres, sur ce qu’il ne faut pas enregistrer, qui décidera (le cas échéant) ce qui sera enregistré, etc.

Toute personne rédigeant une norme Internet ayant besoin d’un nouveau registre IANA ou de nouvelles valeurs dans un registre existant doit lire [BCP26], « Directives pour écrire une section de considérations IANA en RFC », qui décrit comment les auteurs RFC doivent demander pour que l’IANA démarre ou reprenne un registre. De meme, l’IANA conserve des registres qui ont débuté longtemps avant que le BCP 26 ne soit produit.

6.4.4 Considérations de sécurité

Un aspect obligatoire de tous les RFC et tous les avant-projets Internet est la section sur les « Considérations de sécurité ». Cette section doit décrire toute vulnérabilité connue du protocole, les menaces éventuelles, et les mécanismes ou les stratégies pour les aborder. Ne passez pas la section — en particulier, ne dites pas, « C’est notre protocole, si vous voulez de la sécurité, utilisez simplement IPsec ». Cela ne fonctionnera pas, car cela ne répond pas à la question de savoir comment IPsec interagit avec votre protocole et inversement. Consultez[BCP72], « Directives pour rédiger un texte RFC sur les considérations de sécurité », pour plus d’informations sur l’écriture des sections de considérations de sécurité.

6.4.5 Les brevets dans les normes IETF

Les problèmes de propriété intellectuelle sont apparus de plus en plus souvent ces dernières années, en particulier en ce qui concerne les brevets. Le but de l’EITF est d’avoir des normes largement utilisées et validées sur le marché. Si la création d’un produit qui utilise une norme nécessite l’obtention d’une licence de brevet, les gens seront moins enclins à appliquer la norme. Sans surprise, la règle générale consiste donc à « utiliser une bonne technologie sans brevet lorsque cela est possible ».

Bien entendu, cela n’est pas toujours possible. Parfois, des brevets apparaissent après qu’une norme ait été établie. Parfois, il y a un brevet sur quelque chose qui a tant de valeur qu’il n’y a pas d’équivalent sans brevet. Parfois le détenteur du brevet est généreux et promet de fournir à tous les réalisateurs d’une norme une licence sans royalties, la rendant aussi facile à mettre en vigueur que si le brevet n’existait pas.

Les méthodes IETF pour gérer les brevets des normes sont sujettes à débat. Les règles officielles pour tous les droits de propriété intellectuelle (IPR) dans les documents IETF (pas seulement les brevets) sont couvertes dans[BCP78] et [BCP79], « Droits de propriété intellectuelle dans la technologie IETF ». Tous ceux qui participent aux groupes de travail IETF trouveront probablement ces documents intéressants car ils exposent les règles que tout le monde accepte de suivre.

Les détenteurs de brevet qui laissent leurs brevets être utilisés librement par les personnes appliquant les normes IETF bénéficient généralement d’un important capital de sympathie auprès des participants de l’IETF. Une telle générosité est plus courante que vous ne le croyez. Par exemple, RFC 1822 est une licence d’IBM pour l’un de ses brevets de sécurité dans un contexte de protocole particulier, et la communauté de la sécurité a répondu très favorablement à IBM (alors que de nombreuses autres compagnies ont été exclues pour leur inflexibilité concernant leurs brevets de sécurité).

Si vous rédigez un avant-projet Internet et que vous connaissez un brevet qui s’applique à la technologie sur laquelle vous écrivez. Ne citez pas le brevet dans le document. Veuillez plutôt consulter la page IETF IPR sur http://www.ietf.org/ipr pour savoir comment procéder. Les droits de propriété intellectuelle ne sont pas mentionnés dans les RFC car ces derniers ne changent jamais après avoir été publiés, mais la reconnaissance d’un IPR peut changer à tout moment. Par conséquent, une liste IPR dans un RFC peut être incomplète et induire le lecteur en erreur. [BCP79] fournit un texte spécifique qui doit être ajouté aux RFC lorsque l’auteur a conscience de problèmes IPR.

6.5 RFC informatifs et expérimentaux

Comme nous l’avons mentionné précédemment, tous les RFC ne sont pas des normes. En fait, beaucoup de RFC importants ne sont pas du tout dans le domaine des normes. Actuellement, il existe deux désignations pour les RFC qui ne sont pas censés être des normes : informatif, comme le TAO, et expérimental. (Il existe en fait une troisième désignation, historique, mais elle est réservée aux documents qui figuraient dans les normes et qui ont été retirés à cause du manque d’utilisation, ou lorsqu’une réflexion plus récente indique que la technologie est en fait nuisible pour Internet.)

Le rôle des RFC informatifs est souvent débattu à l’IETF. Bon nombre de gens aiment en disposer, en particulier pour des spécifications qui sont créées en-dehors de l’IETF mais qui sont référencées par des documents IETF. Ils sont également utiles pour des spécifications qui sont les précurseurs du travail effectué par les groupes de travail IETF. D’autre part, certaines personnes appellent les RFC informatifs des « normes » même si ce n’est pas le cas, généralement pour berner un public crédule à propos de que la personne a à vendre ou à proposer. Lorsque cela se produit, le débat sur les RFC informatifs est relancé.

Les RFC expérimentaux concernent des spécifications qui pourraient être intéressantes, mais pour lesquelles l’intérêt de les mettre en œuvre n’est pas clair. Leur bon fonctionnement une fois déployées n’est pas non plus évident. Cela dit, une spécification peut résoudre un problème, mais il est difficile de savoir si beaucoup de personnes pensent que le problème est important, ou pensent prendre la peine de régler le problème avec la spécification, la spécification pouvant être labellisée comme RFC expérimental. Si, par la suite, la spécification devient populaire (ou s’avère bien fonctionner), elle peut être rééditée comme un RFC de suivi de norme. Les RFC expérimentaux sont également utilisés pour permettre aux gens d’expérimenter une technologie susceptible de devenir une norme mais pour laquelle il subsiste des questions sans réponse.

L’IESG a créé des directives sur le choix entre les statuts informatifs et expérimentaux : http://www.ietf.org/iesg/informational-vs-experimental.html. Si vous êtes en train de créer un document que vous pensez pouvoir devenir un RFC expérimental, la connaissance de la position actuelle vous aidera à justifier votre choix proposé.


7. Comment apporter votre contribution à l'IETF

7.1 Ce que vous pouvez faire

Lire — Examinez les avant-projets internet dans votre domaine d’expertise et commentez-les dans les groupes de travail. Prenez part aux discussions de façon amicale et utile dans le but de créer la meilleure norme Internet possible. Ecoutez beaucoup plus que vous ne parlez. Si vous n’êtes pas d’accord, débatez des problèmes techniques ; n’attaquez jamais les gens.

MettreÉcrivez en oeuvre — Ecrivez des programmes qui utilisent les normes Internet actuelles. Les normes ne valent pas grand-chose tant qu'elles ne sont pas à la disposition des internautes. Veillez à appliquer même les normes dites « mineures », car celles-ci prendront de l'importance si elles sont reprises dans davantage de logiciels. Signalez tout problème rencontré au sujet de normes au groupe de travail concerné, de sorte que la norme puisse être clarifiée dans les versions suivantes. L’un des principes les plus cités de l’IETF est « les règles évolutives l’emportent ». Ainsi vous pouvez aider une norme à devenir plus répandue en créant davantage de règles évolutives. Vous pouvez participer au développement de protocoles avant qu’ils ne deviennent des normes en mettant en œuvre (mais non pas en déployant) des avant-projets Internet pour prouver que les auteurs ont fait un bon travail. Si vous trouvez des erreurs ou des omissions, proposez des améliorations sur la base de votre expérience d’application.

Écrire — Modifiez ou collaborez à la rédaction d'avant-projets Internet dans votre domaine d’expertise. Faites cela au bénéfice de la communauté Internet, et non pas pour avoir votre nom (ou pire, le nom de votre société) sur un document. Les auteurs d’avant-projets sont soumis à toutes sortes de critiques techniques (et parfois personnelles) ; recevez-les avec sérénité et utilisez-les pour améliorer votre avant-projet pour produire la meilleure norme possible avec un degré d’interopérabilité élevé.

7.2 Ce que peut faire votre société

Partager — Évitez les normes propriétaires. Si vous êtes un réalisateur, affichez une forte préférence pour les normes IETF. Si les normes IETF ne valent pas les normes propriétaires, faites votre possible pour rendre les normes IETF meilleures. Si vous êtes acheteur, évitez les produits qui font appel à des normes propriétaires en concurrence avec les normes ouvertes de l’IETF et dites-le aux sociétés auprès desquelles vous achetez.

Ouvrez-vous — Si votre société contrôle un brevet utilisé dans une norme IETF, convainquez la société de mettre le brevet gratuitement à disposition de tous ceux qui appliquent la norme. Ces dernières années, des brevets ont causé beaucoup de problèmes graves pour les normes Internet car ils empêchent des sociétés d’appliquer librement les normes. Heureusement, de nombreuses sociétés ont généreusement offert des licences illimitées pour des brevets afin d’aider les normes IETF à s’épanouir. Ces sociétés sont généralement récompensées par une publicité positive pour leur générosité et leur clairvoyance, contrairement à d’autres détenteurs de brevet.

Rejoignez — Devenez un membre de l’ISOC. Plus Important encore, incitez les sociétés qui ont bénéficié de l’Internet à devenir membre de l’ISOC, puisque cela représente le plus grand bénéfice financier pour le groupe. Cela profitera, bien entendu, à l’Internet dans son ensemble.


8. L'IETF et le monde extérieur

8.1 L'IETF et les autres groupes de normalisation

Bien que beaucoup de participants à l’IETF aimeraient penser autrement, l’IETF n’est pas une machine à normes. Il y a beaucoup (peut-être trop) d’autres organismes de standardisation dont les décisions affectent l’Internet. Il existe également un bon nombre d’organismes de standardisation qui ont longtemps ignoré Internet et qui maintenant veulent leur part du gâteau.

En général, l’IETF essaie d’entretenir de bonnes relations avec les autres organismes de standardisation. Ce n’est pas toujours facile, car de nombreux autres organismes présentent des structures différentes de l’IETF et l’IETF est constitué de bénévoles qui préfèreraient probablement rédiger des normes plutôt que de rencontrer des représentants des autres organisations. Malgré tout, d’autres organismes de standardisation fournissent de gros efforts pour encourager de bonnes relations avec l’IETF en dépit des différences culturelles évidentes.

Au moment de la rédaction de ce document, l’IETF entretient des relations avec de grandes organisations de normalisation y-compris l’ITU-T (la branche de normalisation des télécommunications de l’Union internationale des télécommunications), le W3C (World Wide Web Consortium), l’IEEE (the Institute of Electrical and Electronics Engineers), et l’Unicode Consortium. Comme stipulé dans l’IAB Charter [BCP39], « Les relations sont aussi informelles que possible et doivent prouver leur capacité à améliorer la qualité des spécifications de l’IETF ». En pratique, l’IETF préfère que les interactions aient lieu directement au niveau du groupe de travail , les relations formelles et les documents de liaison jouant un rôle d’appoint.

Certaines de ces relations sont entretenues par l’IESG, d’autres par l’IAB. Les lecteurs avides de détails en apprendront beaucoup sur les méthodes formelles d’interaction avec les autres organismes de standardisation dans [BCP102], « Processus IAB pour la gestion des relations de l’IETF », et dans [BCP103], « Procédures pour traiter les notes de liaison vers et en provenance de l’IETF ». Le meilleur moyen de vérifier si l’IETF a des liaisons formelles est la liste des liaisons de l’IETF, http://www.ietf.org/liaison. La liste révèle qu’il existe de nombreuses liaisons différentes avec les sous-comités ISO/IEC JTC1.

8.2 Couverture médiatique de l'IETF

Étant donné que l’IETF est l’une des organisations les plus connues qui participent à la progression d’Internet, il est normal que la presse spécialisée (et même la presse commerciale) veuille couvrir ses actions. Ces dernières années, un petit nombre de magazines ont envoyé des journalists et des rédacteurs pour couvrir l’IETF en profondeur pendant une longue période. Ces journalists ont été marqués par une multitude d’articles erronés, d’évaluations fausses sur les statuts des avant-projets Internet, de citations de gens qui n’ont rien à voir avec le travail de l’IETF, et ainsi de suite.

Les principales erreurs de presse tombent dans deux catégories : dire que l’IETF réfléchit à un projet alors qu’il n’existe en fait qu’un avant-projet Internet dans un groupe de travail, et dire que l’IETF a approuvé quelque chose alors qu’il ne s’agissait que de la publication du RFC informatif. Dans les deux cas, la presse ne peut être entièrement accusée pour le problème, puisqu’en général elle est alertée par une société essayant de se faire de la publicité pour un protocole qu’elle a développé ou pour le moins soutenu. Bien entendu, si les journalists prenaient la peine de faire des recherches, ils pourraient entrer en contact avec quelqu’un qui rétablirait la vérité, comme un responsable de GT ou un Directeur de domaine. Le lieu incontournable où la presse devrait chercher des contacts de presse concernant l’IETF est<http://www.ietf.org/media.html>.

Le fait que les reporters qui se sont trompés une fois reviennent aux réunions de l’IETF prouve qu’en fin de compte, il est possible de bien faire les choses. Toutefois, les réunions de l’IETF ne s’adressent pas du tout aux reporters ignorant le processus de l’IETF (quoi que si vous êtes un reporter et que vous lisez ce document, c’est un très bon signe!). De plus, si vous pensez dénicher un scoop en venant aux réunions de l’IETF, vous risquez d’être déçu.

Au regard de cela, il n’est pas étonnant que certains participants à l’IETF préféreraient tenir la presse aussi loin que possible des réunions. Un peu de publicité pour les protocoles sur le point d’être terminés et qui compteront dans l’industrie l’année prochaine peut être une bonne chose. Cependant, il est rare qu’un reporter puisse résister à la tentation de présenter un protocole naissant comme le prochain sauveur d’Internet. De telles histoires font plus de mal que de bien, que ce soit pour les lecteurs de l’article ou pour l’IETF.

La raison principale qui peut pousser un reporter à assister à une réunion de l’EITF n’est pas la couverture des technologies de pointe (puisque cela peut être fait confortablement dans son bureau en lisant les listes de mailing) mais la rencontre avec certaines personnes. Malheureusement, les personnes les plus intéressantes sont celles qui sont également les plus occupées pendant les réunions de l’EITF et certaines ont tendance à se sauver quand elles aperçoivent un badge de presse. Cependant, les réunions de l’EITF sont d’excellents endroits pour rencontrer et parler avec les auteurs de document et avec les responsables de groupes de travail ; cela peut s’avérer très utile pour les reporters qui couvrent l’avancement des protocoles.

Les reporters qui cherchent à savoir « où en est l’IETF » sur un thème particulier seraient bien avisés de parler à plusieurs personnes actives sur ce thème au sein l’IETF, et devraient essayer de s’entretenir avec le responsable du GT. Il est impossible de savoir ce qu’il adviendra d’un avant-projet en le lisant ou en en parlant avec son auteur. Heureusement, tous les GT disposent d’archives que les journalists peuvent consulter pour avoir des indications récentes sur l’avancement d’un avant-projet ; malheureusement, peu de reporters ont le temps ou l’envie de faire ce genre de recherche. Comme l’IETF n’a pas de correspondant de presse, les magazines ou journaux qui produisent une histoire fausse, ne seront pas directement contactés par l’IETF et ne sauront donc quasiment jamais qu’ils se sont trompés, étant alors susceptibles de recommencer la fois suivante.


9. Considérations de sécurité

Section 6.4.4 explique pourquoi chaque RFC doit contenir une section de considérations de sécurité et donne quelques idées sur ce qu’il devrait contenir et ne pas contenir. En-dehors de cette information, ce document ne touche pas à la sécurité d’Internet.

10. Informative References

[BCP9] Bradner, S., “Les normes Internet Processus -- Révision 3”, BCP 9, RFC 2026, RFC 6410, October 1996.
[BCP10] Galvin, J., “Processus de sélection, de confirmation et de rappel d’IAB et d’IESG : Opération des Comités de nomination et de rappel”, BCP 10, RFC 3777, June 2004.
[BCP11] Hovey, R. and S. Bradner, “Les organisations impliquées dans le processus de normalisation d’IETF”, BCP 11, RFC 2028, October 1996.
[BCP14] Bradner, S., “Mots-clés à utiliser dans les RFC pour Indiquer les niveaux d’exigences”, BCP 14, RFC 2119, March 1997.
[BCP22] Scott, G., “Guide pour les auteurs de normes Internet”, BCP 22, RFC 2360, June 1998.
[BCP25] Bradner, S., “Directives du groupe de travail IETF et Procédures”, BCP 25, RFC 2418, September 1998.
[BCP26] Narten, T. and H. Alvestrand, “Directives pour Écrire une section de considérations IANA dans les RFC”, BCP 26, RFC 5226, May 2008.
[BCP39] Internet Architecture Board (Conseil pour l’architecture d’Internet) and B. Carpenter, “Charte de l’Internet Architecture Board (IAB)”, BCP 39, RFC 2850, May 2000.
[BCP45] Harris, S., “Charte de la liste de discussions IETF”, BCP 45, RFC 3005, November 2000.
[BCP72] Rescorla, E. and B. Korver, “Directives pour écrire un texte RFC sur la sécurité Considérations”, BCP 72, RFC 3552, July 2003.
[BCP78] Bradner, S., “Droits de l’IETF dans les contributions”, BCP 78, RFC 5378, November 2008.
[BCP79] Bradner, S., “Droits de propriété intellectuelle dans la Technologie IETF”, BCP 79, RFC 3979, March 2005.
[BCP95] Alvestrand, H., “Un énoncé de mission pour l’IETF”, BCP 95, RFC 3935, October 2004.
[BCP97] Bush, R. and T. Narten, “Clarification lorsque les documents de suivi de normes peuvent faire référence normativement à des documents de niveau inférieur”, BCP 97, RFC 3967, December 2004.
[BCP101] Austein, R. and B. Wijnen, “Structure de l’activité de soutien administratif de l’IETF (IASA)”, BCP 101, RFC 4071, April 2005.
[BCP102] Daigle, L. and Internet Architecture Board (Conseil pour l’architecture d’Internet), “Processus IAB pour la gestion de liaison IETF Relations”, BCP 102, RFC 4052, April 2005.
[BCP103] Trowbridge, S., Bradner, S., and F. Baker, “Procédures pour le traitement des évaluations des relations vers et en provenance de l’IETF”, BCP 103, RFC 4053, April 2005.
[RFC1796] Huitema, C., Postel, J., and S. Crocker, “Tous les RFC ne sont pas des normess”, RFC 1796, April 1995.
[RFC2223] Postel, J. and J. Reynolds, “Instructions pour les auteurs de RFC”, RFC 2223, October 1997.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, “Protocole d'accord concernant le travail technique de l'Internet Assigned Numbers Authority”, RFC 2860, June 2000.
[RFC6635] Kolkman, O. and J. Halpern, “Modèle de rédacteur RFC (Version 2)”, RFC 6635, March 2012.
[RFC4677] Hoffman, P. and S. Harris, “Le Tao de l’IETF – Un guide du débutant à l’Internet Engineering Task Force”, RFC 4677, September 2006.
[RFC4858] Levkowetz, H., Meyer, D., Eggert, L., and A. Mankin, “Document depuis le dernier appel du groupe de travail jusqu’à la publication”, RFC 4858, May 2007.
[RFC6722] Hoffman, P., “Publication de "Tao de l’IETF" comme page Web”, RFC 6722, August 2012.
[STD3] Braden, R., “Conditions pour les hôtes Internet - Application et Support”, STD 3, RFC 1123, October 1989.

A. Principes directeurs de l'IETF

Si vous êtes arrivé aussi loin dans le TAO, vous en avez appris beaucoup sur les travaux de l’IETF. Ce que vous trouverez dans cette annexe résume le plus gros de ce que vous avez lu et ajoute de nouveaux points à méditer. Assurez-vous de lire tous les principes ; considérés dans leur ensemble, ils vous donneront un nouveau regard sur ce que fait l’IETF.

A.1 Généralités

L’IETF travaille selon un processus ouvert et selon un consensus approximatif. Cela s’applique à tous les aspects du fonctionnement de l’IETF, y-compris à la création de documents IETF et aux décisions sur les processus qui sont utilisés. Mais l’IETF observe également les expériences et la règle évolutive avec intérêt, et cela devrait aussi s’appliquer aux processus opérationnels de l’organisation.

L’IETF œuvre dans des domaines où il présente, ou peut trouver, des compétences techniques.

L’IETF dépend d’un groupe de bénévoles très actifs.

La participation à l’IETF ou à ses GT n’est pas payante ni définie en fonction des organisations, mais se base sur l’auto-identification et la participation active des individus.

A.2 Direction et leadership

L’IETF reconnait les positions de leadership et accorde le pouvoir de décision aux leaders, mais ces décisions sont sujettes à appel.

La délégation de pouvoir et de responsabilité est essentielle au fonctionnement efficace de l’IETF. Autant d’individus que possible seront encouragés à prendre le leadership des tâches de l’EITF.

Les différences d’opinion, les réclamations et l’appel sont des conséquences de la nature de l’IETF et doivent être considérés comme des événements normaux, mais en définitive, il faut reconnaître qu’il ne peut être fait appel de certaines décisions.

Les positions de leadership présentent une durée fixe (bien que nous n’ayons aucune limite formelle sur le nombre de mandats qui peuvent être accomplis).

Il est important de former les futurs leaders dans la communauté active.

Un processus communautaire est utilisé pour choisir le leader.

Les leaders ont le pouvoir de décider qu’un consensus de base a été démontré. Sans adhésion formelle, il n’y a pas de règles formelles pour le consensus.

A.3 Processus

Bien que l’IETF ait besoin de règles de processus clairement et publiquement documentées il doit y avoir suffisamment de flexibilité pour que des cas inhabituels soient traités avec bon sens. Nous appliquons un jugement personnel et ne codifions que si nous sommes certains. (Mais nous codifions ceux qui peuvent rendre des jugements personnels).

Le travail de développement technique doit être effectué par des groupes de travail agréés et focalisés.

Les aspects du processus qui se sont avérés être impraticables doivent être retirés ou rendus optionnels.

A.4 Groupes de travail

Les groupes de travail (GT) sont de prime abord responsables pour la qualité de ce qu’ils émettent; les responsables de GT en tant que leaders de GT, soutenus par le leadership de l’IETF, doivent agir en tant que garants de la qualité.

Les GT doivent être de prime abord responsables de l’évaluation de l’impact négatif de leur travail sur Internet et doivent donc être examinés ; le leader d’EITF doit agir comme un écran entre les domaines.

L’examen précoce des documents, en particulier par les GT, est plus efficace pour traiter les problèmes majeurs que s’il est fait plus tard.

Les Directeurs de domaine sont responsables de la formation et de l’engagement des GT, pour leur donner la direction nécessaire, et pour les interrompre. Les représentants de GT exercent leurs fonctions à la discrétion du Directeur de domaine responsable.

Les représentants de GT sont responsables et doivent s’assurer que les GT appliquent leurs chartes, sont conformes à leurs objectifs et produisent des documents prêts à la publication. Les rédacteurs de documents exercent leurs fonctions à la discrétion du responsable du GT.

Les Directeurs de domaines sont responsables de l’organisation des examens de qualité et de l’approbation des documents finaux.

A.5 Documents

Les normes IETF débutent souvent comme des avant-projets personnels, peuvent devenir des avant-projets de GT et sont approuvées pour la publication permanente par un organisme de leadership indépendant du GT ou par les individus qui les produisent.

Les normes IETF appartiennent à la communauté et non pas à leurs auteurs. Mais la paternité est reconnue et mise en valeur comme le sont les contributions modestes autant que la paternité complète.

La qualité technique et l’exactitude sont le premier critère pour atteindre le consensus sur des documents.

Les spécifications IETF peuvent être publiées comme informelles, expérimentales, standards, historiques ou meilleures pratiques actuelles.

Les spécifications des normes IETF ne sont pas considérées satisfaisantes jusqu’à ce qu’une application indépendante et interopérable ait été démontrée. (C’est l’application du slogan « règle évolutive »). Cependant, l’IETF n’assume aucune responsabilité sur les tests d’interopérabilité et ne certifie pas l’interopérabilité.

Les processus de l’IETF sont publiés comme les documents des Meilleures Pratiques actuelles.

Des informations utiles qui ne sont ni une spécification ni un processus peuvent être publiées comme informelles.

Des spécifications obsolètes peuvent être déclassées au rang d’historiques.

Le suivi des normes doit distinguer les spécifications qui ont démontré être interopérantes.

Le suivi des normes et les documents de Meilleures Pratiques Actuelles doivent être sujets au consensus approximatif de l’IETF (processus de Dernier Appel). Le consensus approximatif du GT est normalement suffisant pour d’autres documents.

Des changements substantiels réalisés à la suite du Dernier Appel de l’EITF ou de l’évaluation de l’IESG doivent être référencés au GT.

L’IETF détermine les conditions pour la publication et la mise en archive de ses documents.