RFC 3160
Août 2001

Le Secrétariat tient à remercier Susan Harris pour tous ses efforts engagés dans la mise à jour du Tao et la production d'une version html du document, avec l'aide de Paul Hoffman.
Résumé

Destiné aux nouveaux participants à l'Internet Engineering Task Force, ce document décrit le fonctionnement interne des réunions et des groupes de travail de l'IETF, examine les organisations liées à l'IETF et présente le processus de standardisation.

Table des Matières

Introduction
Remerciements
1. Qu'est-ce que l'IETF ? 
   1.1 Des débuts modestes
   1.2 La Hiérarchie 
      1.2.1 ISOC (Internet Society)
      1.2.2 IESG (Internet Engineering Steering Group)
      1.2.3 IAB (Internet Architecture Board)
      1.2.4 IANA (Internet Assigned Numbers Authority)
      1.2.5 Le Rédacteur en Chef des RFCs
      1.2.6 Le Secrétariat de l'IETF
   1.3 Les listes de diffusion 
2. Les réunions IETF 
   2.1 Inscription
   2.2 S'orienter en arrivant 
   2.3 Code vestimentaire
   2.4 Pastilles de couleur
   2.5 La salle des terminaux
   2.6 Repas et autres délices
   2.7 La Soirée de Gala (Social Event)
   2.8 Le programme
   2.9 Comment puis-je participer ?
      2.9.1 Directeurs des Systèmes d'Information
      2.9.2 Opérateurs de réseaux et Fournisseurs d'accès Internet 
      2.9.3 Distributeurs d'équipement réseau (matériel et logiciel) 
      2.9.4 Universitaires
      2.9.5 Presse spécialisée
   2.10 Comptes-rendus
   2.11 Autres généralités
3. Les groupes de travail 
   3.1 Les animateurs des groupes de travail
   3.2 Méthodologie des groupes de travail 
   3.3 Préparation aux réunions des groupes de travail
   3.4 Listes de diffusion des groupes de travail
   3.5 Réunions intermédiaires des groupes de travail
4. Les réunions BOFs 
5. Nouveau à l'IETF ? Arrêtez vous ici (pour le moment) 
6. RFCs et Internet Drafts 
   6.1 Vers la publication d'un standard
   6.2 Lâcher prise 
   6.3 Internet Drafts 
      6.3.1 Lecture recommandée aux auteurs
      6.3.2 Noms de fichiers et autres 
   6.4 Processus de standardisation des RFCs
      6.4.1 Les mots pour le dire : MUST, SHOULD et MAY
      6.4.2 Références aux normes dans les standards
      6.4.3 A propos de l'IANA
      6.4.4 A propos de la sécurité
      6.4.5 La question des brevets dans les standards IETF
   6.5 RFCs à caractère expérimental et informatif
7. Comment contribuer à l'IETF ?
   7.1 Contribution de votre entreprise
8. L'IETF et le reste du monde
   8.1 L'IETF et les autres organismes de standardisation
   8.2 Couverture de l'IETF par la presse 
9. Références
   9.1 Le Tao 
   9.2 Adresses E-mail utiles
   9.3 Documents et fichiers utiles
   9.4 Acronymes et abréviations utilisés dans le Tao
   9.5 Documents cités dans le Tao
Remarques sur la sécurité 
Adresse de la rédactrice 
Déclaration de Copyright

 

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 trouve à 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 voit 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, afin de mieux exploiter les travaux réalisés pendant les réunions et dans les groupes de travail.

De nombreux participants à l'IETF n'assistent jamais aux réunions mais ils sont cependant actifs sur les listes de diffusion des divers groupes de travail. Le fonctionnement interne de ces groupes pouvant paraître obscure au début, ce document de type FYI (For Your Information, pour votre information) fournit l'information de base qui aidera le nouveau participant à s'impliquer dans les travaux.

On trouvera dans le Tao des références à de nombreux types de documents IETF, des BCPs aux RFCs en passant par les FYI (les BCPs, Best Current Practices, proposent des recommandations concernant les meilleures pratiques de l'Internet; les RFCs, Requests for Comments, sont les principaux documents techniques et les FYIs, For Your Information, fournissent une vue d'ensemble sur l'actualité et les technologies et une introduction

destinées à un plus large public (voir le chapitre 6 pour des explications détaillées).

Les acronymes et autres abréviations utilisés dans ce document sont généralement détaillés dans le texte et sont expliqués au chapitre 9.

Remerciements

La version originale de ce document, publiée en 1994, a été rédigée par Gary Malkin. Sa connaissance de l'IETF, sa perspicacité et son style d'écriture inégalé ont servi de base pour cette dernière version à laquelle il a également contribué. Paul Hoffman a rédigé une part significative du document et apporté son soutien, son expertise et de précieux conseils dans la conduite de ce projet. On citera également les contributions de Scott Bradner, Michael Patton, Donald E. Eastlake III, du secrétariat de l'IETF et des membres du groupe de travail Services aux Utilisateurs (User Services Working Group).

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

L'Internet Engineering Task Force 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 le développement 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.

Elle a pour but de :

Identifier les problèmes urgents opérationnels et techniques liés à l'Internet et proposer des solutions;
Spécifier le développement ou l'usage des protocoles et définir les architectures les mieux adaptées à court terme pour résoudre ces problèmes;
Faire des recommandations à l'IESG (Internet Engineering Steering Group) sur la standardisation et l'usage des protocoles appliqués à l'Internet;
Faciliter le transfert technologique entre l'IRTF (Internet Research Task Force) et la communauté de l'Internet en général;
Favoriser l'échange d'informations entre tous les acteurs de l'Internet : fournisseurs de matériel, utilisateurs, chercheurs, opérateurs de réseaux et fournisseurs de services.
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 standards. L'IETF est composée de volontaires, 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 à toutes les réunions. Devenir membre de l'IETF, c'est avant tout s'inscrire sur une des listes de diffusion afin d'accéder à toutes les informations relatives aux activités et débats en cours (voir chapitre 1.3).

Bien sur, 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, comme cela est décrit dans le BCP 11,

"The Organizations Involved in the IETF Standards Process" (les organisations impliquées dans le processus de standardisation de l'IETF). Si vous décidez de participer aux travaux de l'IETF et ne deviez lire qu'un seul BCP, ce devrait être celui-là.

1.1 Des débuts modestes

La première rencontre de l'IETF a eu lieu en Janvier 1986 au Linkabit de San Diego avec 21 participants.

La quatrième rencontre, 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 Février 1987. La 7ème rencontre, au MITRE de McLean, en Virginie, au mois de Juillet 1987, a réunit pour la première fois plus d'une centaine de participants.

La 14è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. 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é en deux pôles principaux : l'IETF et l'IRTF. L'IRTF fut en charge des recherches sur le long terme concernant l'Internet. L'IETF a évolué également à 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 Bureau de l'ISOC (Board of Trustees) ont approuvé une nouvelle charte pour entériner cette proposition.

L'IETF s'est réunit à Amsterdam aux Pays-Bas, en Juillet 1993. C'était la première rencontre en Europe et la proportion de participants américains en a été réduite de moitié. Une rencontre sur cinq se tient désormais en Europe ou en Asie et la proportion de participants extérieurs aux Etats-Unis continue d'être élevée - environ la moitié, même aux réunions organisées sur le sol américain.

1.2 La Hiérarchie

1.2.1 ISOC (Internet Society)

L'Internet Society est une organisation internationale à but non lucratif visant à favoriser le développement de l'Internet. Elle est constituée de membres adhérents et fonctionne grâce à l'appui financier et juridique aux autres groupes décrits ici (les groupes "I"), en particulier de l'IETF. Le rôle de supervision de l'ISOC sur l'IETF est particulièrement souple, à tel point que la plupart des participants ignorent jusqu'à son existence. L'ISOC fournit une assurance à de nombreux participants engagés dans les travaux de l'IETF et prends 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 (et financièrement démuni) de l'Internet.

1.2.2 IESG (Internet Engineering Steering Group)

L'IESG est responsable de la direction technique des activités de l'IETF et du processus de standardisation, tels qu'il a été défini et ratifié par le Bureau de l'ISOC. L'IESG n'a cependant pas un rôle de direction tel qu'il peut exister pour d'autres organismes de standardisation. 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.

L'IESG est constitué des Responsables de Domaines (Area Directors, ici abrégé en "ADs"), 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 le BCP 10, "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 :

Applications (APP) - Protocoles vus par les utilisateurs des programmes, tels que l'e-mail et le Web
General (GEN) - Divers Travaux 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) - Administration et contrôle
Routing (RTG) - Acheminer les paquets jusqu'à leur destination
Security (SEC) - Authentification et confidentialité
Transport (TSV) - Services spéciaux pour les paquets spéciaux
User Services (USV) - Support à l'utilisateur final et aux organisations de support aux utilisateurs
Etant donné que l'IESG a une grande influence sur le fait qu'un document de travail (Internet draft) devienne ou non un RFC, de nombreuses personnes ont tendance à considérer les ADs comme des demi-dieux et à s'adresser à eux avec vénération pour leur demander leur avis sur un problème particulier, alors que la plupart des ADs 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 ADs s'en remettent souvent aux autres membres qui ont à leurs yeux d'avantage de connaissances dans tel ou tel domaine.

Les responsables de domaine sont censés connaître mieux que personne l'ensemble du travail combiné des groupes de travail oeuvrant dans leur domaine. D'un autre côté, l'ensemble de l'IESG vote sur chaque Internet Draft pour en faire un RFC et il suffit de deux votes négatifs pour bloquer le processus. Ceci sert à empêcher que le projet d'un AD, simplement parce qu'il serait son propre "bébé", n'acquiert le statut de standard au détriment des protocoles IETF déjà existants.

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. La plupart des demandes faites par les groupes de travail pour qualifier un Internet Draft en RFC sont acceptées et les interventions n'ont lieu qu'en cas de problème véritable. On peut malgré tout dire que les ADs sont élus pour penser et pas seulement pour administrer le processus de standardisation. La qualité des standards définis 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 ADs.

L'IETF fonctionne sur le mode du consensus approximatif (rough consensus) et c'est l'IESG qui décide si un groupe de travail a abouti à un résultat réellement consensuel. 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. Une des missions importantes de l'IESG consiste donc à 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 responsables de domaines sont censés relire les travaux effectués en dehors de leurs domaines respectifs.

1.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 sponsorise et organise également l'Internet Research Task Force, sous forme d'ateliers (invitational workshops) qui proposent des études approfondies sur certains sujets concernant l'architecture de l'Internet. Ces documents font des recommandations à l'IETF et à l'IESG. Le rôle de l'IAB est aussi de :

Approuver les nominations proposées par l'IESG
Examiner en appel les actions engagées contre certaines décisions de l'IESG
Nommer et encadrer le rédacteur en chef des RFC (RFC editor)
Approuver la nomination de l'IANA
Conseiller l'ISOC
Encadrer les liens de l'IETF avec les autres organismes de standardisation
A l'instar de l'IESG, les membres de l'IAB sont désignés pour plusieurs années par le Nomcom et sont approuvés par le Bureau de l'ISOC (Board of Trustees).

1.2.4 IANA (Internet Assigned Numbers Authority)

L'IANA fait office de bureau central d'enregistrement des activités de l'IETF. En effet, il est souvent indispensable de conserver 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. L'IANA est soutenu financièrement par l'ICANN (Internet Corporation for Assigned Names and Numbers).

Il y a encore cinq 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. 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ée 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 qui remplit scrupuleusement sa mission permet d'expérimenter beaucoup plus facilement sans craindre de tout mélanger.

Le fondateur de l'IANA, Jon Postel, s'est vu confié 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.

1.2.5 Le Rédacteur en Chef des RFCs

Le rédacteur en chef des RFCs (RFC Editor) prépare, formate et publie les travaux qui prennent alors le statut de RFC. Il travaille en concertation avec l'IESG. Une autre fonction importante du rédacteur en chef est de fournir un répertoire de tous les RFCs. 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 RFCs 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. L'IAB approuve la nomination de l'organisation qui remplira la fonction de rédacteur en chef des RFCs ainsi que sa ligne de conduite. Le rédacteur en chef des RFCs est financé par l'ISOC et peut être contacté par e-mail à rfc-ed@rfc-editor.org.

1.2.6 Le Secrétariat de l'IETF

Très peu de personnes sont rétribué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 et à gérer les listes de diffusion autres que celles des groupes de travail. Le secrétariat a aussi en charge de conserver et de classer le répertoire officiel des documents de travail (Internet Drafts) et le site web. Il aide également l'IESG dans l'accomplissement de sa mission. Une part importante du financement du secrétariat est assurée par les frais d'inscription aux réunions de l'IETF.

1.3 Les listes de diffusion

Pour qui souhaite assister à une réunion IETF, il est fortement conseillé de s'inscrire sur la liste des annonces ietf-announce@ietf.org. Elle fournit toutes les informations sur les réunions mais aussi sur la parution des Internet Drafts, des RFCs. C'est également sur cette liste que les plans d'action sur les protocoles et les derniers appels à commentaires (Last Calls) de l'IESG sont postés. Pour les personnes impliquées au niveau technique, il existe aussi la liste de discussion ietf@ietf.org. 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 leur travaux).

L'inscription à ces listes et à toute liste de l'IETF est gérée par un programme appelé Majordomo. 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 sauce. Par exemple, pour vous inscrire sur la liste des annonces, envoyez un message à :

ietf-announce-request@ietf.org

avec le mot "subscribe" (sans les guillemets) dans le sujet et dans le corps du message. Pour une inscription sur la liste de discussion technique de l'IETF, envoyez un message à :

ietf-request@ietf.org

en répétant la même démarche avec la commande "subscribe". Si vous décidez de vous retirer d'une liste, utilisez la commande "unsubscribe". Vos messages envoyés à Majordomo ne devraient contenir rien d'autre que les mots "subscribe" ou "unsubscribe".

Chacune de ces listes est archivée sur le site web de l'IETF.

Il est formellement interdit, sous aucun prétexte et en toutes circonstances, d'envoyer une requête d'inscription à une liste sur la liste elle-même ! Les milliers d'inscrits n'ont que faire d'apprendre qu'une nouvelle personne a rejoint la liste. De la même manière, lorsque vous changez d'adresse électronique ou que vous quittez une liste, envoyez votre demande uniquement à l'adresse de type "-request".

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 pour l'envoi de messages d'une autre nature, comme des sollicitations ou de la promotion, qu'ils émanent d'entreprises ou de particuliers (voir le RFC 3005 : "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. Seul le secrétariat est habilité à poster des messages sur la liste d'annonces.

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 aux listes.

2. Les réunions IETF

Le monde de l'informatique regorge de conférences, séminaires, expositions et autres réunions. Cependant, les rencontres de l'IETF sont d'une toute autre nature. Elles ont lieu trois fois par an et rassemblent pendant une semaine de jeunes technicos dans une ambiance festive avec pour objectif principal de revigorer le travail des groupes mais aussi de 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'ISOC qui rajoute quelques moyens supplémentaires pour permettre par exemple la retransmission vidéo en direct et multicast de certaines sessions des groupes de travail.

Les réunions de l'IETF sont souvent attendues comme une bouffée d'air frais dans le monde des conférences sur les standards de l'informatique. Pas de hall d'exposition, très peu de travaux pratiques et aucune grand messe servie par un gourou de l'industrie. Au lieu de cela, l'ambiance y est plutôt très studieuse, mais permet aussi les rencontres informelles. 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.

La plupart des réunions IETF se tiennent en Amérique du Nord car c'est là que vivent la plupart des participants, bien qu'elles aient lieu sur d'autres continents une fois tous les ans ou tous les deux ans. Les dernières réunions ont rassemblé 2500 participants. 49 réunions ont eu lieu depuis le début et la liste des réunions à venir est disponible sur http://www.ietf.org/meetings/0mtg-sites.txt

Les nouveaux participants à une réunion IETF 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. Un des traits particuliers depuis une période récente est l'utilisation de l'Internet sans fil sur tout l'espace de réunion. Il est devenu courant de voir la moitié des personnes assistant à la réunion d'un groupe de travail lire leur courrier électronique ou naviguer sur le web pendant une présentation qui les laisse insensibles.

2.1 Inscription

L'inscription aux réunions de l'IETF est obligatoire et payante. 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 sur la liste de diffusion des annonces et simultanément publiée sur le site web de l'IETF.

L'inscription se fait en ligne sur le web de différentes manières. Vous pouvez vous inscrire et payer immédiatement, vous inscrire maintenant et retourner plus tard payer sur le web, vous inscrire sur le web et payer sur le lieu de la réunion ou encore tout faire à ce moment-là.

Cependant, 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.

Les paiements en ligne par carte de crédit sont sécurisés mais vous pouvez aussi utiliser votre clé PGP pour envoyer votre paiement au service des inscriptions à ietf-registrar@ietf.org

L'inscription reste ouverte toute la semaine de la réunion. Le secrétariat vous conseille néanmoins de vous présenter à l'ouverture des inscriptions qui a lieu à partir du dimanche midi jusqu'à 17 heures, début de la réception d'accueil. C'est un moment très prisé pendant lequel vous pourrez manger un morceau et faire connaissance avec les premiers arrivants.

Une fois inscrit, un guide du participant vous est remis. Il contient des informations très utiles, comme une feuille d'orientation générale, un agenda à jour et un badge à votre nom. Les participants ayant effectué un paiement d'avance y trouveront également une facture.

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

2.2 S'orienter en arrivant

Il est conseillé aux personnes qui viennent pour la première fois, d'assister à la réunion d'orientation (Newcomers' Orientation) qui leur est spécialement destinée. Organisée par le secrétariat de l'IETF, elles permet de recueillir les premières informations utiles. Elle dure généralement une demie heure et couvre les sujets abordés dans le guide remis aux participants, comme la signification des pastilles sur les badges, la structure de l'IETF et beaucoup d'autres éléments essentiels et éclairants pour un débutant à l'IETF.

La réunion d'orientation est immédiatement suivie par une autre session d'orientation sur le processus de standardisation de l'IETF, afin de montrer les différentes étapes que franchit un document avant de devenir un standard et la façon dont il peut progresser. Cette mise au point sur les standards dure elle aussi à peu près 30 minutes.

Il reste toujours du temps à la fin pour les questions. Le secrétariat fournit également une documentation de présentation de l'IETF, une liste des documents importants disponibles en ligne ainsi que les versions papier des slides de présentation de la structure de l'IETF et du processus de standardisation. Cette documentation très utile est aussi en ligne sur www.ietf.org dans la partie "Additional Information".

Les réunions d'orientation ont lieu le dimanche avant la réception de 17h (consultez le planning pour l'heure et l'endroit exacts). Notez que votre participation aux réunions d'orientation ne vous ouvre pas plus tôt les portes de la réception !

2.3 Code vestimentaire

Puisque les participants doivent porter leur badge avec leur nom, autant porter une chemise ou autre chose. Pantalons ou jupes sont aussi fortement conseillées. 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 jean (ou en short si le temps le permet), t-shirt et sandales. Il y a bien sûr à l'IETF ceux qui refusent absolument de porter autre chose que leur costume, mais 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" !

2.4 Pastilles de couleur

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 offrir bénévolement beaucoup de travail supplémentaire. Les couleurs ont les significations suivantes :

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 Nominating Committee
Les journalistes portent des badges de couleur orange.

Les membres de l'organisme qui accueille pourront vous renseigner sur la salle des terminaux, les restaurants et autres lieux 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. En effet, si les membres de l'IAB, de l'IESG, ou les animateurs des groupes de travail ou de BOF ne voulaient pas communiquer, ils ne porteraient pas ces badges en évidence.

2.5 La salle des terminaux

Une des choses essentielles qu'apporte la structure d'accueil est l'accès Internet à tous les participants. En général, qu'il soit avec ou sans fil, il est d'excellente qualité et résulte des efforts olympiens fournis par les hôtes et leur capacité à négocier, emprunter et magouiller. Toutes les personnes et les entreprises qui fournissent du matériel, des compétences 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. La salle des terminaux est équipée de stations de travail, d'une ou deux imprimantes et de prises réseau pour les portables.

2.6 Repas et autres délices

Marshall Rose fit un jour la remarque que l'IETF était un endroit branché pour les amateurs de bonne cuisine. Bien qu'il soit exacte 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. Par contre, le secrétariat fournit les amuse-gueules à la réception d'accueil (qui ne sont toutefois pas censés remplacer un dîner), les petits déjeuners chaque matin, ainsi que les (meilleurs) cookies, brownies et autres gourmandises pendant les pauses de l'après-midi.

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.

2.7 La Soirée de Gala (Social Event)

La soirée de gala est une autre part importante des services fournis par l'organisme d'accueil local. Il peut s'agir d'un événement lié à l'informatique ou aux nouvelles technologies. A la réunion IETF de Boston, par exemple, cela consistait en un dîner au musée de l'Ordinateur. D'autres fois, cela peut être une croisière gastronomique ou la visite d'une galerie d'art.

Nous encourageons les nouveaux participants à se joindre à cet événement. Chacun devrait 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.

2.8 Le programme

Le programme des réunions à l'IETF est très fluctuant. Une mise à jour est envoyée à trois reprises avant la réunion sur la liste des annonces et publiée sur le web. Le programme de la 50ème réunion, par exemple, est sur http//www.ietf.org/meetings/agenda_50.html. La version définitive est fournie dans le guide du participant. Evidemment, "définitif" n'a pas le même sens à l'IETF que partout ailleurs. 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).

L'attribution des salles de réunion pour les groupes de travail et les BOFs est indiquée sur le programme, ainsi qu'un plan de leur situation. Elle peut également 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.

2.9 Comment puis-je participer ?

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 devriez pas vous sentir obligé de venir aux réunions 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, peut 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 participation aux rencontres de l'IETF.

2.9.1 Directeurs des Systèmes d'Information

Comme évoqué précédemment, une rencontre de l'IETF n'est en rien comparable avec les salons professionnels que vous connaissez. C'est 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 (Internet drafts) 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.

2.9.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 en pointe et que vous suiviez assidûment les travaux des groupes s'y rattachant, vous jugerez peut-être les réunions IETF intéressantes. Plus votre activité sera en pointe dans les réseaux, en particulier dans les domaines du routage et de la commutation, et plus vous serez en mesure d'apprendre et de contribuer lors d'une rencontre IETF.

2.9.3 Distributeurs d'équipement réseau (matériel et logiciel)

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. Si vous êtes fabriquant 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 activité.

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.

2.9.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 domaines des réseaux et de la communication peuvent puiser une mine d'information en participant aux groupes de travail qui les concernent. Se promener d'un groupe de travail à l'autre peut avoir autant d'effet que vous rendre à un symposium ou à un séminaire organisé par votre département d'étude.

2.9.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 8.2

2.10 Comptes-rendus

Les comptes-rendus de l'IETF (Proceedings) sont réalisés dans les deux mois suivant chaque rencontre et sont disponibles sur le web, sur CD et en version imprimée. Ne les ratez pas, ils contiennent des informations sur l'IETF que vous ne trouverez nul part ailleurs. Par exemple, vous trouverez une photographie actualisée 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) signé Steve Coya, le Directeur Général (Executive Director) de l'IETF. Chaque édition contient le programme final (rétrospectivement mis à jour), une présentation de l'IETF, les rapports d'activité par domaines et groupes de travail ainsi que les slides 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é remise à temps au secrétariat pour leur publication.

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

2.11 Autres généralités

Les membres du secrétariat de l'IETF et ceux de l'IETF dans leur ensemble sont 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 rendre le jargon et les acronymes compréhensibles !

Les conversations de couloir 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).

Un "bar BOF" est un rassemblement non formel, souvent tard le soir, pendant lequel on travaille beaucoup autour d'un verre. Les "bars BOF" fleurissent un peu partout sur place, dans les restaurants, les salons de thé ou autour d'une piscine, si on a la chance d'en disposer.

Il serait provocateur de s'interposer entre un participant affamé (ce qui est souvent le cas) et les brownies et cookies servis pendant la pause café, quelque soit l'intérêt de la conversation.

L'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 doit pas payer les objets dérivés de l'IETF: T-Shirts, pins, etc.

Il y a toujours un présentoir avec une documentation près du comptoir d'enregistrement. Il regroupe toutes les informations utiles aux participants (par exemple, une copie des travaux en cours dans un groupe ou un descriptif du contenu en ligne sur le site de l'IETF). Vous êtes priés de 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.

3. Les 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. Le BCP 25, IETF Working Group Guidelines and Procedures, est un document précieux pour quiconque participe à un groupe de travail.

Un groupe de travail n'est rien d'autre qu'une liste de discussion 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 animé par une ou deux personnes.

Encore plus important, 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 ses réunions physiques sont censés traiter des thèmes inscrits dans la charte en évitant de s'éparpiller sur d'autres sujets passionnants. Un coup d'oeil 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 en cours.

3.1 Les animateurs des groupes de travail

Le rôle des animateurs est décrit dans les BCP11 et BCP25.

En fait, leur travail consiste à faire en sorte que la discussion puisse avancer à partir des étapes posées par la charte du groupe et jusqu'à la publication d'un ou plusieurs RFCs. Ils ne sont pas censés diriger les travaux mais sont responsables de leur avancement effectif en empêchant toute déviation aléatoire.

Comme vous pouvez l'imaginer, certains animateurs sont plus à l'aise que d'autres dans ce travail. Lorsqu'un groupe de travail a rempli les objectifs inscrits à sa charte, il est censé interrompre ses activités (en fait, 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). A 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 animateurs 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. Les résultats produits par ces groupes vieillissant sont souvent moins pertinents qu'ils ne l'étaient au début et leur apparence parfois embrouillée s'apparentent à ce qu'on appelle alors le "syndrome de dégénérescence".

L'animateur a aussi la mission essentielle de choisir les documents de travail (Internet Draft) qui seront officiellement publiés par le groupe et ceux qui ne le seront pas. Dans la pratique, il n'y a pas grande différence de traitement entre les documents issus d'un groupe et les autres.

Par exemple, de nombreuses listes discutent aussi des documents indépendants (à la discrétion de l'animateur). Les procédures concernant les documents officiels (Internet Drafts) seront traitées par la suite plus en détail.

Les animateurs des groupes de travail sont fortement encouragés à se rendre au déjeuner de sensibilisation qui leur est, depuis tout récemment, spécialement destiné et qui se déroule le premier jour de la rencontre. Si vous êtes intéressé par ce qui se dit à ce moment-là, vous pouvez consulter les transparents sur http://www.ietf.org/wgchair/index.htm

3.2 Méthodologie des groupes de travail

Un des aspects déroutants lorsque l'on découvre l'IETF est la place mineure des réunions physiques des groupes de travail, ce qui n'est généralement pas le cas ailleurs. Toute décision prise lors d'une réunion doit également être approuvée sur la liste de diffusion. 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.

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 à l'autre. 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 exacte de participants ?)

3.3 Préparation aux réunions des groupes de travail

Il est essentiel que chaque participant (les nouveaux comme les plus anciens) lise les documents de travail (Internet Drafts) ainsi que les RFCs avant chaque réunion. Les réunions des groupes de travail ne sont pas destinés à la pédagogie mais à faire avancer la production des documents. Même si vous ne prévoyez pas d'intervenir pendant la réunion, vous êtes conviés à lire en amont les documents existants afin d'être en mesure de comprendre les débats en cours.

L'animateur du groupe est chargé de définir l'ordre du jour de la réunion, en principe quelques semaines à l'avance. Si vous souhaitez aborder un point particulier, assurez-vous de mettre l'animateur au courant. Ces informations sont disponibles à l'avance pour chaque groupe de travail (voir http://www.ietf.org/meetings/agenda_xx.html où "xx" est le numéro de la réunion IETF) même si certains animateurs négligent parfois de faire ce travail.

Le secrétariat publie le programme des réunions seulement quelques semaines à l'avance et celui-ci change souvent jusqu'à une semaine avant la date de la première réunion. Si vous venez juste pour une seule réunion de groupe de travail, il vous sera peut-être difficile de réserver votre avion avec aussi peu d'information, surtout si la date de réunion est modifiée au dernier moment. Assurez-vous de posséder la version à jour du programme afin de réserver votre avion et votre chambre d'hôtel.

Dans votre intérêt, il est souhaitable de ne pas venir pour une seule réunion. Il est probable que vos connaissances soient utiles dans plusieurs groupes, dans la mesure où vous aurez auparavant lu les documents de travail (Internet Drafts) et les RFCs concernant ces groupes.

Si vous faites une présentation pendant une réunion, il est conseillé d'avoir quelques transparents à montrer. Le matériel nécessaire à la projection est disponible dans chaque salle.

Un conseil pour vos transparents : ne mettez pas le logo de votre entreprise sur toutes les pages, bien que ce soit chose courante ailleurs. L'IETF est plutôt hostile à ce genre de pratique promotionnelle et la plupart des intervenants n'inscrivent même pas leur logo sur le premier transparent. En effet, nous insistons bien sur le fait que les préoccupations à l'IETF sont d'ordre technique uniquement.

3.4 Listes de diffusion des groupes de travail

Comme nous l'avons vu plus haut, les listes IETF d'annonce et de discussion sont les listes pivots des activités de l'IETF. Il existe cependant bien d'autres listes de diffusion concernant les travaux de l'IETF. Tous les groupes de travail, par exemple, possèdent leur propre liste. De plus, certains sujets techniques ayant une portée à long terme et développés sur la liste de discussion de l'IETF ont été déplacés vers de nouvelles listes qui leur sont spécialement dédiées. Il est fortement recommandé de suivre les discussions sur les listes des groupes de travail auxquels on a l'intention de participer. Plus il y aura de travail accompli sur la liste, moins il y aura de travail à faire en réunion, ce qui laissera ainsi du temps pour une pollinisation croisée (par exemple de pouvoir assister aux travaux de groupes concernant d'autres domaines afin d'élargir ses propres perspectives).

Les listes de diffusion offrent aussi un moyen d'expression aux participants qui suivent les travaux des groupes ou contribuent à leurs efforts, sans pouvoir assister aux réunions.

La plupart des listes de l'IETF utilisent Majordomo et possèdent une adresse de type "-request" qui prend en charge les démarches administratives d'inscription et de désinscription (voir le chapitre 1.3 pour plus d'informations sur Majordomo). Ce genre de détail administratif est du plus mauvais effet lorsqu'il est envoyé sur la liste elle-même.

La plupart des listes de discussion de l'IETF sont archivées : tous les messages postés sur une liste sont automatiquement stockés sur un serveur accessible en FTP anonyme. On trouvera de nombreuses archives de ce type à l'adresse ftp://ftp.ietf.org/ietf-mail-archive/. Si la liste que vous cherchez reste introuvable, envoyez un message à l'adresse "-request" de celle-ci (mais pas à la liste elle-même !).

3.5 Réunions intermédiaires des groupes de travail

Il arrive que les groupes de travail tiennent des réunions intermédiaires entre deux rencontres de l'IETF. Cependant, ces réunions ne doivent pas se substituer aux réunions régulières, même s'il s'agit d'éviter une réunion prévue dans un lieu peu alléchant pour en organiser une trois semaines plus tard aux Baléares. Une réunion intermédiaire nécessite l'autorisation du responsable de domaine et doit être annoncée au moins un mois à l'avance. Le lieu ainsi que les horaires doivent permettre un accès équitable à tous les participants. Comme pour une réunion ordinaire, quelqu'un doit prendre des notes et envoyer un compte-rendu à minutes@ietf.org ainsi que tenir à jour la liste des participants.

4. Les réunions BOFs

Pour constituer un groupe de travail, il est nécessaire d'avoir une charte et quelqu'un qui puisse assurer le rôle d'animateur compétent. Pour remplir ces conditions, il vous faudra trouver des gens intéressés qui seront en mesure d'aider à la définition de la charte et de convaincre un responsable de domaine que le projet est valable. Une réunion en face à face s'avérera utile. En réalité, très peu de groupes de travail sont lancés par les Responsables de Domaines; la plupart sont le fruit d'une réunion BOF pendant laquelle les participants ont exprimé leur intérêt pour un sujet donné.

Une réunion BOF, avant d'être planifiée, doit être approuvée par le Responsable du domaine (Aera Director, AD) concerné. Si vous estimez qu'un nouveau groupe de travail est absolument nécessaire, vous pouvez contacter un AD en privé et voir ce qu'il pense de votre proposition. L'étape suivante consiste à demander un créneau de réunion lors de la prochaine rencontre IETF. Bien entendu, vous n'avez pas besoin d'attendre ce moment pour commencer le travail : vous pouvez déjà monter la liste et lancer la discussion sur la charte.

Les réunions BOF sont très différentes des réunions organisées par les groupes de travail. L'objectif d'une BOF est d'assurer qu'une charte de qualité aux contours bien définis soit possible et qu'il y ait suffisamment de monde pour faire le travail nécessaire à la création d'un standard. Certaines BOFs ont déjà produit des documents de travail (Internet Draft) tandis que d'autres partent de zéro. L'avantage d'avoir ces documents avant la réunion BOF est de pouvoir mieux cerner la discussion. D'un autre côté, cela peut avoir tendance à brider d'autres idées que certains participants souhaiteraient développer dans la charte. Il est important de garder à l'esprit que les BOFS sont généralement destinées à obtenir des soutiens pour la création éventuelle d'un groupe de travail et non à défendre un document en particulier.

De nombreuses BOFs ne donnent pas naissance à un groupe de travail, cela pour plusieurs raisons. Il est courant qu'il n'y ait pas assez de personnes d'accord sur un axe de travail ou encore que celui-ci ne pourrait aboutir à un standard - dans le cas où, par exemple, les auteurs du document se montrent réticents à accorder au groupe la possibilité de contrôler les changements (nous traiterons ce thème plus loin). Seules deux réunions BOF peuvent se tenir sur un même sujet : soit il en résulte la création d'un groupe de travail, soit le sujet est abandonné.

5. Nouveau à l'IETF ? Arrêtez vous ici (pour le moment)

Si vous rejoignez tout juste l'IETF et que ce texte est le seul document que vous prévoyez de lire avant de venir aux rencontres, mettez un terme ici à votre lecture - du moins pour le moment. Profitez ensuite du voyage de retour pour lire le reste du Tao. Vous serez alors en mesure de vous impliquer activement dans les groupes qui vous auront intéressé pendant la rencontre et le Tao vous guidera dans vos premiers pas.

6. RFCs et Internet Drafts

Si vous débutez à l'IETF et que vous cherchez un RFC ou un document de travail (Internet Draft) en particulier, allez sur les pages web du Rédacteur en chef des RFCs http://www.rfc-editor.org.

Vous y trouverez également des liens vers diverses collections de RFCs. Beaucoup disposent d'un moteur de recherche. Si vous connaissez le numéro du RFC que vous recherchez, allez sur les pages RFC de l'IETF http://www.ietf.org/rfc.html. Pour trouver un document de travail (Internet Draft), la meilleure source est http://www.ietf.org/ID.html où vous pouvez faire une requête par titre et mots clés.

6.1 Vers la publication d'un standard

Une des questions les plus courantes posée par les nouveaux arrivants aux "anciens" de l'IETF est "Comment puis-je faire publier un standard IETF ?". Une question bien plus pertinente est "Devrais-je écrire un standard IETF ?" dans la mesure où la réponse n'est pas toujours "oui". Si vous décidez de vous lancer dans l'écriture d'un document destiné à devenir un standard, soyez averti des obstacles qui vous guettent tout au long du parcours. Nombreux sont ceux qui s'en sortent indemnes cependant et il existe toute une documentation écrite qui aidera les auteurs à y parvenir en conservant leur ego à peu près intact.

Chaque standard de l'IETF est publié sous la forme d'un RFC (Request For Comments, mais tout le monde dit RFC) et chaque RFC commence par être un document de travail (Internet Draft, souvent désigné par "I-D"). Les principales étapes à franchir pour la publication d'un standard IETF sont :

Publier le document sous forme d'un document de travail (Internet Draft)
Recevoir des commentaires sur ce document
Rédiger une nouvelle version intégrant les commentaires
Répéter les étapes 1 à 3 plusieurs fois
Demander au Responsable du domaine de soumettre le document à l'IESG (en cas de proposition individuelle). Si le document est le résultat officiel du groupe de travail, c'est l'animateur du groupe qui fait la démarche auprès du Responsable.
Modifier le projet en fonction de l'avis rendu par l'IESG (qui peut aller jusqu'à l'abandon du standard envisagé)
Attendre que le document soit publié par le Rédacteur en chef des RFCs
Une description beaucoup plus détaillée du processus est donnée dans le BCP9, "The Internet Standards Process". Quiconque rédige un document qu'il espère voir devenir un standard doit lire le BCP9 afin d'être en mesure de suivre son cheminement tout au long du parcours. Le BCP9 fournit des explications détaillées sur un sujet qui est souvent mal compris, même par les participants réguliers de l'IETF : on trouve différents types de RFCs qui suivent différents processus et qui obéissent à des classements différents. Il existe six catégories différentes de RFCs :

Proposition de standard (Proposed standards)
Projet de standard (Draft Standard)
Standards Internet (Internet Standards, parfois appelés full standards)
Protocoles expérimentaux (Experimental protocols)
Documents d'information (Informational documents)
Standards historiques (Historic standards)
Seuls les trois premiers (proposed, draft et full) sont des standards de l'IETF. Un résumé explique clairement cela dans le RFC 1796 qui porte bien son nom : "Not all RFCs are Standards" (tous les RFCs ne sont pas des standards).

Il existe aussi trois sous catégories de RFCs, appelées FYIs, BCPs et STDs. La série For Your Information est destinée à documenter des aspects d'ordre général et des thèmes introductifs ou intéressant un large public. Les FYIs sont souvent rédigés par des groupes de travail au sein du domaine "services aux utilisateurs" (User Services Area). Les documents de type Best Current Practice décrivent l'application de différentes technologies de l'Internet. Les STDs sont destinés à identifier les RFCs qui spécifient les standards de l'Internet. Certains STDs sont en fait constitués de plusieurs RFCs et le terme "standard" s'applique à l'ensemble des documents.

6.2 Lâcher prise

La raison principale qui conduit certaines personnes à refuser que leurs documents prennent le chemin d'une standardisation IETF est le fait qu'ils doivent abandonner leur contrôle sur les évolutions du protocole. En effet, à partir du moment où vous proposez que votre protocole devienne un standard de l'IETF, vous devez pleinement renoncer à tout pouvoir de contrôle sur celui-ci. S'il y a un accord général, certaines parties du protocole pourront être complètement modifiées, des pans entiers supprimés, de nouveaux éléments ajoutés ou encore le nom pourra être changé.

Certains auteurs éprouvent beaucoup de difficulté à abandonner tout contrôle sur leur "créature". Si vous faites partie de cette catégorie de personnes, ce n'est même pas la peine de penser à tenter l'aventure. A l'opposé, si votre objectif est d'aboutir au meilleur standard possible et à une mise en oeuvre la plus large, le processus en vigueur à l'IETF peut vous convenir.

Précisons au passage que le contrôle sur les changements du protocole se poursuit même lorsque le protocole est un standard. En effet, le protocole peut encore être modifié ultérieurement pour un certain nombre de raisons, dont la plus courante est la découverte d'un problème au moment de sa mise en oeuvre. Ces changements tardifs sont également effectués sous l'autorité de l'IETF et non par les auteurs du standard.

Les standards IETF sont destinés à être utilisés pour écrire des applications Internet qui interopèrent. Ils n'ont pas vocation à exprimer les idées de leurs auteurs (qui peuvent être remarquables) ni à être pour une entreprise l'objet d'une publicité quelconque. Si un RFC en cours de standardisation ne présente qu'une seule mise en oeuvre (alors que deux sont nécessaires pour qu'un standard soit reconnu), on peut en déduire que l'on s'est trompé dès le début en le proposant comme un standard possible.

6.3 Internet Drafts

Tout document qui termine sa course dans le répertoire des RFCs a d'abord été un document de travail appelé Internet Draft (I-D). Ces derniers sont destinés à être lus et commentés puis enrichis des commentaires retenus. Provisoires, ils sont systématiquement retirés des archives en ligne au bout de six mois. Comme le précise le BCP9, ils ne peuvent être en aucun cas considérés comme des standards, ni même des spécifications :

Un Internet Draft n'est pas un moyen de publier une spécification. Elles doivent suivre la voie propre aux RFCs. Les documents de travail n'ont aucun statut formel et sont susceptibles d'être modifiés ou supprimés à tout moment. En aucun cas un ID ne doit être référencé par un article, rapport ou autre Request-for-Proposal, ni être l'objet de référence pour un produit commercial quelconque.

N'hésitez pas en faire la remarque à la personne qui ne comprend pas les règles de l'IETF (ou qui tente délibérément de tromper son monde) et qui se targue d'avoir publié un Internet Draft.

Un I-D doit avoir à peu près la même présentation qu'un RFC. Contrairement à une croyance assez répandue, un I-D ne doit pas nécessairement copier à l'identique le format d'un RFC mais plus il s'en rapprochera, plus vous faciliterez le travail du rédacteur lorsque votre document sera publié au titre de RFC. Le RFC 2223, "Instructions to RFC Authors", décrit la méthode de formatage utilisée par le rédacteur en chef des RFCs.

Un Internet Draft peut être le fruit du travail d'un groupe ou une soumission individuelle. Les documents produits par un groupe de travail sont en principe revus par l'animateur avant d'être acceptés comme une production du groupe.

6.3.1 Lecture recommandée aux auteurs

Avant de commencer l'ébauche de votre premier Internet Draft, vous devriez lire quatre documents :

Plus important encore que les simples aspects de formatage, le RFC 2223 explique également ce que doit contenir un I-D pour qu'il puisse devenir un RFC. Il décrit les paragraphes et les notifications qui devront se trouver dans votre document. Il est utile de les inclure dès le début afin que les lecteurs ne soient pas surpris lorsque vous les ajouterez plus tard.
Le BCP 22, "Guide for Internet Standards Writers", propose des conseils qui vous aideront à écrire un standard pleinement interopérable. Il explique par exemple comment choisir le nombre juste d'options du protocole, comment répondre aux comportements hors spécification ainsi que la façon de présenter un diagramme.
Le guide en ligne intitulé "Guidelines to Authors of Internet-Drafts" contient des informations à jour sur la manière de restituer un I-D ainsi que les principales informations de base à inclure.
Lorsque vous considérez avoir franchi l'étape du document de travail et êtes prêt à le soumettre comme RFC, lisez absolument le document intitulé "Considerations for Internet Drafts". Il s'agit d'une liste recensant les pièges courants qui ont amené l'IESG à refuser certains documents. En fait, vous devriez sans doute lire ce document bien avant d'avoir terminé afin d'éviter tout un tas de modifications au dernier moment.
6.3.2 Noms de fichiers et autres

Lorsque votre Internet Draft est prêt, envoyez-le au rédacteur en chef des I-D à drafts@ietf.org. Il y a réellement quelqu'un à l'autre bout de cette adresse e-mail et sa fonction consiste à vérifier que vous avez inclus les éléments de base indispensables dans votre document pour qu'il soit publié comme Internet Draft. Lorsque vous soumettez la première version d'un draft, le rédacteur en chef concerné fournit un nom de fichier pour le document. Si celui-ci est le résultat officiel du travail d'un groupe, le nom du draft commencera par "draft-ietf-" suivi par le nom du groupe de travail, puis par un mot ou deux de description et enfin par "00.txt".

Par exemple, un document du groupe S/MIME sur la création de clés serait désigné par "draft-ietf-smime-keying-00.txt". Si le document n'est pas le résultat d'un groupe de travail, son nom commencera par "draft-" et le nom de famille d'un des auteurs, suivi par une description d'un ou deux mots puis par "00.txt". Dans le cas par exemple où l'auteur s'appelle Smith, le nom du document sera "draft-smith-keying-00.txt". Si le document est soumis par un individuel mais se rattache à un groupe de travail précis, les auteurs ajoutent parfois après leur nom celui du groupe de travail concerné, comme par exemple : "draft-smith-smime-keying-00.txt". Vous pouvez suggérer vous-même des noms mais la décision finale appartient toujours au Rédacteur en chef des Internet Draft (et à l'animateur du groupe pour les documents officiellement produits par les groupes de travail). A la suite de la première publication d'un document, la numérotation dans le nom du fichier est incrémentée, c'est à dire que la seconde édition du document mentionné plus haut sera nommée "draft-ietf-smime-keying-01.txt". Notez que le nom de fichier peut changer dans certaines circonstances, par exemple lorsqu'une soumission individuelle est réintégrée dans un groupe de travail.

6.4 Processus de standardisation des RFCs

Le processus lié à la création et à la progression d'un standard est décrit dans le BCP9. Une fois qu'un Internet Draft a été suffisamment revu et qu'il a obtenu un consensus approximatif que ce qu'il explique serait utile comme standard, il est soumis à l'avis de l'IESG. Lorsque le document est le produit d'un groupe de travail, l'animateur du groupe l'envoie au responsable du domaine concerné après avoir passé avec succès le dernier appel à commentaires adressé au groupe de travail (last call). Si le document est le fruit d'un travail personnel, l'auteur ou le rédacteur en chef le soumet au responsable du domaine. Le BCP9 décrit également la procédure d'appel pour les cas où la décision de l'animateur d'un groupe, d'un responsable de domaine ou de l'IESG, concernant la création ou la progression d'un standard, est contestée.

Après soumission du draft à l'IESG, ce dernier lance un dernier appel à commentaires à l'ensemble de l'IETF, destiné à tous ceux qui n'ont pas suivi l'évolution du travail et qui peuvent parfois être à l'origine de modifications apportées au document. C'est aussi l'occasion pour ceux qui estiment ne pas avoir été entendu par le groupe de travail d'adresser leurs commentaires à une audience plus large. Le dernier appel à commentaires s'étend sur deux semaines pour un document issu d'un groupe de travail et sur quatre semaines lorsqu'il s'agit d'une soumission individuelle.

Lorsque l'IESG approuve le document comme standard Internet, il demande au rédacteur en chef des RFCs de le publier sous la forme d'une proposition de standard (Proposed Standard). Au bout d'au moins six mois de ce statut, l'auteur du RFC (ou l'animateur du groupe de travail concerné) peut demander qu'il devienne un document standard (Draft Standard). Avant cela, néanmoins, quelqu'un doit convaincre le responsable du domaine concerné qu'il existe au moins deux mises en oeuvre indépendantes et interopérables pour chaque partie du standard. C'est un test efficace de l'utilité du standard dans son ensemble et un excellent moyen de vérifier sa parfaite lisibilité.

Plusieurs choses peuvent se produire à ce stade. En premier lieu, il est courant de constater que certaines spécifications doivent être reformulées lorsque les tentatives de mise en oeuvre ont donné des interprétations radicalement différentes. Il arrive aussi couramment que certains aspects du standard ne soit pas mis en oeuvre. Ils sont donc retirés du standard, pas simplement pour n'avoir pas été testés mais parce qu'ils ne correspondaient à aucun besoin.

Ne soyez pas trop surpris si un standard particulier n'évolue pas de Proposed à Draft. En fait, la plupart des standards couramment utilisés sont des Proposed Standards et resteront tels quels. Cela peut être du au fait que personne n'a pris le temps d'essayer ou que les standards auxquels il fait référence sont elles-mêmes au stade de Proposed Standard ou encore que tout le monde avait quelque chose de plus important à faire.

Au bout de quelques années d'existence sous forme de Draft Standard, un document peut devenir un standard Internet (Internet Standard), également connu sous le nom de "full standard". Ceci ne se produit que très rarement, ce statut étant réservé aux protocoles qui sont absolument nécessaires au fonctionnement de l'Internet. Autant dire que l'IESG passe un Draft Standard au peigne au fin avant de lui donner le statut de standard Internet.

6.4.1 Les mots pour le dire : MUST, SHOULD et MAY

Pour qu'elles soient mises en oeuvre telles que vous les imaginez, l'écriture des spécifications se révèle être tout un art. Vous pouvez choisir de les réduire au maximum, avec juste une liste de conditions, mais au risque de voir différentes mises en oeuvre partir à la dérive. Si au contraire, vous rédigez une spécification trop verbeuse, avec de nombreuses suggestions, les développeurs auront tendance à ne pas voir ce qui est obligatoire (et de toute façon ils seront souvent en désaccord avec vos suggestions). Une spécification réussie se situe entre ces deux extrêmes.

Une des possibilités pour garantir au mieux que les développeurs aboutissent à des mises en oeuvre interopérables est d'exprimer clairement ce qui est obligatoire dans la spécification proposée. Les premiers RFCs utilisaient toutes sortes d'expressions pour expliquer ce qui était requis, de sorte que les développeurs ne savaient pas toujours distinguer les suggestions des aspects obligatoires. Pour cette raison, les rédacteurs de standards à l'IETF décidèrent d'un commun accord de limiter leur vocabulaire à quelques mots bien spécifiques correspondant à des significations bien précises.

Le RFC 1123 écrit en 1989 et intitulé "Requirements for Internet Hosts -- Application and Support", contenait une courte liste de mots qui s'avéraient utiles, comme "must", "should" et "may" (doit, devrait, peut). Ces définitions furent mises à jour et affinées plus tard dans le BCP 14, "Key words for use in RFCs to Indicate Requirement Levels", auquel de nombreux standards courants font référence. Le BCP 14 définit également très précisément "must not" et "should not" et propose quelques uns de leurs synonymes.

Pour un standard, afin de stipuler clairement que vous utilisez les définitions établies par le BCP 14, vous êtes invité à faire deux démarches. Premièrement, faites référence au BCP 14 (bien que la plupart des auteurs se réfèrent au RFC 2119, car c'est ce qu'indique le BCP 14) afin que le lecteur sache quel sens donner aux mots que vous employez. En second lieu, vous devriez mettre en valeur les expressions utilisées dont les définitions renvoient au BCP 14. La pratique couramment admise est d'écrire ces mots en majuscule. C'est pour cette raison que, dans les standards de l'IETF, vous trouvez des "MUST" et des "SHOULD" écrits en lettres capitales.

Le BCP 14 est un document court, que toute personne consultant ou rédigeant des standards IETF devrait lire. Bien que la distinction entre "must" et "must not" coule de source, celle entre "should" et "should not" soulève bien des questions au sein de nombreux groupes de travail. Lorsqu'il faut revoir un document (Internet Draft), la question suivante est généralement soulevée : "cette phrase devrait-elle contenir un MUST ou un SHOULD ?". C'est effectivement une très bonne question, car une spécification ne devrait pas employer de MUST à la légère mais ne devrait pas non plus utiliser SHOULD là où un MUST est requis pour garantir l'interopérabilité. Ce qui nous renvoie au coeur du problème de "sous-spécifier" ou "sur-spécifier" les éléments requis d'un standard.

6.4.2 Références aux normes dans les standards

Un des pièges de l'écriture d'un standard IETF dans lequel tombent souvent les débutants (mais aussi quelques anciens de l'IETF) est la règle sur la façon de faire référence à des normes extérieures à l'IETF ou à d'autres RFCs de l'IETF. Une référence normative est une référence à un document qui doit être suivie pour mettre en oeuvre le standard. Une référence non normative sera utile au développeur, mais pas nécessaire. Comme nous l'avons remarqué précédemment, une spécification utilisant le terme "MUST" (doit) sera certainement normative, donc toute référence devant impérativement être mise en oeuvre utilisera le terme "MUST" et sera normative. Une spécification contenant "SHOULD" (devrait) ou "MAY" (peut) n'est pas nécessairement normative, mais elle pourrait l'être en fonction de ce qu'elle requière. Il y a toujours de la place ici pour le débat...

Un standard IETF peut faire une référence normative à tout autre RFC au même niveau de standard - ou supérieur - ou de tout autre "standard ou norme ouvert" développé hors l'IETF. La règle du "même niveau ou supérieur" signifie qu'un standard, avant d'évoluer de "Proposed" à "Draft", ne doit contenir que des références normatives dont les RFCs d'origine sont eux-mêmes au niveau de Draft ou de standard Internet (Internet Standard). Cette règle donne l'assurance aux développeurs que tout ce que contient un Draft Standard ou un Internet Standard sera parfaitement stable, y compris les références extérieures au standard. Cela peut aussi avoir pour effet de retarder la publication d'un draft ou d'un standard Internet de plusieurs mois (parfois plusieurs années), le temps que les autres documents rattrapent leur retard.

Il n'y a pas de règle écrite et définitive pour définir un "standard ouvert" (open standard), mais cela désigne généralement un standard stable, accessible à tous (bien que cela soit parfois payant) et qui a été mis au point par un groupe de standardisation ou de normalisation reconnu. Si le standard extérieur change, vous devez référencer la version précise et datée utilisée dans votre spécification. Certains organismes de standardisation ne fournissent plus les anciens standards, ce qui peut poser problème aux futurs standards de l'IETF. En cas de doute, l'auteur d'un document pourra demander à l'animateur d'un groupe de travail ou au responsable de domaine concerné si tel standard extérieur peut être utilisé à l'IETF.

6.4.3 A propos de l'IANA

Un nombre croissant de standards IETF requiert l'enregistrement de différents paramètres de protocoles, tels que les noms des options dans un protocole. Comme nous l'avons vu au chapitre 1.2.4, le principal dépositaire de l'ensemble des standards de l'IETF a longtemps été l'IANA. Parce que les standards nécessitent un grand nombre d'enregistrements de toutes sortes, l'IANA a besoin d'instructions claires sur la manière d'enregistrer les paramètres, ce qui ne doit pas être enregistré, qui décidera de ce qui devra être enregistré... etc.

Quiconque écrit un standard Internet pouvant nécessiter un enregistrement par l'IANA doit prendre connaissance du BCP 26, "Guidelines for Writing an IANA Considerations Section in RFCs", décrivant comment les auteurs de RFCs peuvent faire une demande afin que l'IANA initie ou prenne en charge un enregistrement. L'IANA conserve également des enregistrements bien antérieurs à la rédaction du BCP 26.

6.4.4 A propos de la sécurité

Tout RFC doit prendre en compte les aspects de sécurité, au travers d'un chapitre intitulé "Security Considerations". Il doit contenir tous les aspects de vulnérabilité connus du protocole, les menaces possibles ainsi que les mécanismes ou stratégies à déployer pour les traiter. Ne faites pas l'impasse sur cette question et ne dites pas : "voilà le protocole et pour la sécurité, il suffit d'utiliser IPSEC." Cela ne suffira pas, car ça ne résout pas la question de savoir comment IPSEC se comporte avec votre protocole, et vice versa. Si vous ne vous sentez pas à l'aise pour traiter cette question, demandez conseil à l'animateur de votre groupe de travail.

6.4.5 La question des brevets dans les standards IETF

Les problèmes de propriété intellectuelle ont surgi de plus en plus souvent ces dernières années, en particulier dans les domaines des brevets. Le but de l'IETF est d'avoir des standards le plus largement utilisés et validés par le marché. Si la création d'un produit basé sur un standard nécessite l'achat d'une licence pour un brevet, il y a fort peu de chance pour que le standard soit mis en oeuvre. Aussi, la règle habituelle est d'utiliser chaque fois que possible une bonne technologie non brevetée.

Mais ceci n'est évidemment pas toujours possible. Il arrive parfois qu'un brevet sorte après l'établissement d'un standard. D'autres fois, il y a un brevet sur quelque chose d'extrêmement intéressant dont il n'existe pas d'équivalent non breveté. Il arrive aussi que le détenteur du brevet soit généreux et promette d'accorder à tous les développeurs d'un standard le droit d'utiliser gratuitement la licence, rendant ainsi la mise en oeuvre presque aussi facile que s'il n'y avait pas de brevet.

L'approche de l'IETF concernant les brevets présents dans les standards font l'objet de nombreux débats. Vous trouverez les règles officielles dans le BCP 9, mais vous devrez prendre en compte la flexibilité de ces règles qui dépendent du type de brevet, de son détenteur et de l'existence de technologies alternatives non soumises aux brevets.

Les détenteurs de brevets qui en permettent librement l'utilisation pour développer des standards de l'IETF obtiennent souvent une grande reconnaissance de la part de ses membres. Une telle générosité est plus courante qu'on pourrait le penser. Par exemple, le RFC 1822 est une licence d'IBM pour l'exploitation d'un de ses brevets ayant trait à la sécurité. 
La communauté IETF travaillant sur ce sujet s'est montrée pour cela très reconnaissante vis à vis d'IBM (à l'inverse, d'autres sociétés ont été stigmatisées pour leur attitude intraitable concernant l'utilisation de leur brevet).

Si en tant qu'auteur d'un RFC vous savez qu'un brevet s'applique à la technologie que vous traitez, ne le détaillez pas dans le document. Envoyez plutôt une note au secrétariat de l'IETF (ietf-secretariat@ietf.org) indiquant l'existence d'un brevet ou de tout autre droit relatif à la propriété intellectuelle. La note sera publiée sur IETF IPR (http://www.ietf.org/ipr.html).

Les droits de propriété intellectuelle ne sont jamais mentionné dans les RFCs puisque qu'ils ne changent pas après leur publication, alors que les données relatives aux droits de propriété intellectuelle , elles, peuvent changer à tout moment. Il est donc difficile de les inclure dans un RFC sans risquer d'être incomplet et d'induire le lecteur en erreur. Le BCP 9 apporte des informations sur le texte à inclure dans les RFCs lorsque les auteurs sont au courant que des questions de propriété intellectuelle se posent.

6.5 RFCs à caractère expérimental et informatif

Comme nous l'avons vu plus haut, les RFCs ne sont pas tous des standards. En fait, bon nombre de RFCs importants ne sont pas destinés à le devenir. On peut actuellement en définir deux types : informatifs, comme le Tao, et expérimentaux (il y a même un troisième type, historique, mais qui est réservé aux documents qui ont été retirés du processus de standardisation parce qu'ils se sont révélés inutiles, voire contre productifs au développement de l'Internet).

Le rôle des RFCs à caractère informatif (Informational RFCs) est souvent débattu à l'IETF. Ils sont souvent très appréciés, en particulier pour les spécifications étrangères à l'IETF référencées dans ses propres documents. Ils sont aussi utiles pour les spécifications qui sont à la base des activités menées par les groupes de travail. D'un autre côté, certaines personnes se réfèrent à tort à ces documents pour parler de standard, souvent dans l'intention de profiter de la crédulité des gens afin de promouvoir leurs propres intérêts, commerciaux ou autres. Lorsque cela se produit, le débat autour des RFCs à caractère informatif est relancé.

Les RFCs à caractère expérimental (Experimental RFCs) sont utilisés pour des spécifications qui pourraient se révéler intéressantes mais pour lesquelles l'intérêt d'une mise en oeuvre n'est pas démontré. Cela veut dire que si une spécification est faite pour résoudre un problème mais qu'il n'apparait pas clairement qu'un grand nombre de personnes considèrent ce problème comme important ou que cela les gêne de résoudre le problème avec cette spécification, alors elle devrait être qualifiée de RFC expérimental. Plus tard, si la spécification devient reconnue, elle pourra rejoindre le processus de standardisation. Les RFCs à caractère expérimental sont également destinés à encourager l'expérimentation d'une technologie qui pourrait devenir un standard mais qui pose encore certaines questions.

7. Comment contribuer à l'IETF ?

Lire. Etudiez les documents de travail (Internet Drafts) dans votre domaine d'expertise et commentez-les au sein des groupes de travail. Participez aux discussions de manière cordiale et constructive, dans le but d'obtenir le meilleur standard possible. Soyez beaucoup plus attentif que loquace.

Mettre en oeuvre. Ecrivez des programmes qui utilisent les standards actuels de l'Internet. Ils ne peuvent être utiles que si les utilisateurs peuvent s'en servir. Mettez aussi en oeuvre les standards considérés comme "mineurs", qui le seront moins si d'avantage de logiciels les utilisent. Faites part de tous les problèmes rencontrés dans un standard auprès du groupe de travail concerné afin qu'ils puissent être clarifiés dans une version ultérieure. Un des adages souvent répété à l'IETF est "running code wins" (c'est le code qui tourne qui marche), ce qui signifie que vous pouvez apporter votre soutien au standard que vous souhaitez voir se répandre en développant votre propre code.

Ecrire. Publiez seul ou à plusieurs des documents de travail dans votre domaine d'expertise. Faites cela pour le bénéfice de la communauté Internet et non pour le plaisir de voir votre nom (ou pire, celui de votre entreprise) sur un document. Les auteurs sont sujets à toutes sortes de critiques sur le plan technique (et parfois personnel). Restez serein et tirez-en parti pour améliorer votre travail afin d'aboutir à un standard qui soit le meilleur et le plus interopérable possible.

7.1 Contribution de votre entreprise

Partager. Evitez les standards propriétaires. Si vous êtes développeur, marquez votre préférence pour les standards IETF. Lorsque ceux-ci ne se montrent pas à la hauteur des standards propriétaires, apportez votre contribution afin de les améliorer. Si vous êtes acheteur, évitez les produits qui utilisent des standards propriétaires en concurrence avec les standards ouverts de l'IETF et informez vos fournisseurs de votre démarche.

Ouvrir. Si votre entreprise détient un brevet utilisé par un standard IETF, tentez de la convaincre de le mettre gratuitement à disposition de tous ceux qui le mettent en oeuvre. Ces dernières années, les brevets ont été la cause de sérieux problèmes posés aux standards de l'Internet en empêchant des entreprises de développer gratuitement certains standards. Par chance, un bon nombre d'entreprises ont généreusement offert l'utilisation illimitée de certains brevets afin de soutenir le développement des standards IETF. Elles sont généralement récompensées par une publicité gratifiante, montrant qu'elles ne sont pas aussi avides ou étroites d'esprit que d'autres détenteurs de brevets.

Souscrire. Devenez membre de l'ISOC. Mieux, recommandez fortement à toute entreprise qui a bénéficié de l'Internet de devenir membre de l'ISOC (corporate member), ce qui est le meilleur moyen de soutenir financièrement l'IETF. Cela bénéficiera bien sûr également à l'ensemble de la communauté Internet.

8. L'IETF et le reste du monde

8.1 L'IETF et les autres organismes de standardisation

Bien que soient nombreux les participants à l'IETF qui voudraient considérer les choses autrement, l'IETF n'est pas seul dans le monde des standards. Il existe de nombreux (peut-être trop) autres organismes de standardisation dont les décisions influent sur l'Internet. Il y a aussi un nombre important d'organismes qui ont ignoré longtemps l'Internet et qui veulent maintenant y jouer leur rôle.

L'IETF cherche en général à avoir des relations cordiales avec les principaux organismes de standardisation et de normalisation. Cela n'est pas toujours facile dans la mesure où la plupart ont des structures très différentes de l'IETF et que cette dernière est principalement dirigée par des bénévoles qui préféreraient probablement passer leur temps à écrire des standards plutôt qu'à rencontrer les représentants d'autres organisations. Malgré cela, certains organismes font tout leur possible pour maintenir de bonnes relations avec l'IETF, en dépit des très grandes différences culturelles.

Au moment de la rédaction de ce document, l'IESG est en lien avec de grands organismes de standardisation et de normalisation, tels que l'UIT (Union Internationale des Télécommunications), le W3C, le Consortium Unicode, le Forum ATM et l'ISO-IEC/JTC1 (le comité joint du comité international de normalisation et de la Commission d'Electrotechnique Internationale). La liste des liaisons de l'IETF, www.ietf.org/ietf/1iesg-liaisons.txt, montre aussi les différents liens avec les sous-comités de l'ISO-IEC/JTC1.

8.2 Couverture de l'IETF par la presse

Etant donné que l'IETF est un des organismes les plus connus qui permet à l'Internet de progresser, il est naturel pour la presse informatique (et même pour la presse économique) de vouloir couvrir ses actions. Depuis quelques années, un petit nombre de magazines ont chargé des journalistes de couvrir l'IETF de manière pointue et régulière. Certains portent encore les stigmates des erreurs qu'ils ont pu commettre dans leurs articles, que ce soit sur le statut des Internet Draft, sur les citations de personnes étrangères aux travaux de l'IETF, etc.

Les principales erreurs commises par les média se répartissent en deux catégories : affirmer que l'IETF est en train de réfléchir à telle chose alors qu'il s'agit seulement d'un document de travail en cours d'élaboration et affirmer que l'IETF a approuvé quelque chose là où a simplement été publié un RFC à caractère informatif. Dans les deux cas, on ne peut pas les en blâmer entièrement dans la mesure où ils ont souvent été mis sur cette piste par une entreprise essayant de médiatiser un protocole qu'elle a développé ou qu'elle soutient.

Mais il est évident que quelques recherches permettraient aux journalistes de trouver les informateurs qui les mettraient sur la bonne voie, qu'ils soient animateurs d'un groupe de travail ou responsables de domaines. Le contact presse officiel à l'IETF est le secrétariat.

Le fait que l'on revoit les journalistes qui se sont trompés assister de nouveau aux rencontres de l'IETF montre qu'il est possible de réussir malgré tout. Toutefois, les réunions de l'IETF sont à proscrire pour les journalistes qui ne sont pas au fait du fonctionnement de l'IETF (mais si vous êtes journaliste, le fait que vous soyez en train de lire ce document est plutôt bon signe...). De plus, si vous penser obtenir un scoop en assistant à une rencontre IETF, il y a toute les chances que vous soyez déçu.

Avec tout ça, il n'est pas surprenant que certains membres de l'IETF préféreraient voir la presse se tenir à l'écart. Il peut être bénéfique que celle-ci puisse faire un peu de publicité autour d'un protocole naissant qui peut devenir significatif dans l'industrie l'année suivante. Mais rares sont les journalistes capables de résister à la tentation de faire d'un protocole naissant le prochain sauveur de l'Internet. De telles affirmations font beaucoup plus de mal que de bien, autant pour les lecteurs de la presse que pour l'IETF.

L'intérêt principal que peut avoir un journaliste à assister aux réunions de l'IETF n'est pas la couverture des technologies émergentes (puisqu'il suffit pour cela de consulter tranquillement les listes de diffusion depuis son bureau) mais de pouvoir rencontrer les gens directement. Malheureusement, les personnes les plus intéressantes sont aussi les plus occupées pendant les réunions IETF et certaines ont tendance à fuir lorsqu'elles aperçoivent un badge presse. Cependant, les réunions de l'IETF sont le bon endroit pour rencontrer les auteurs de documents ou les animateurs des groupes de travail et discuter avec eux, ce qui peut être intéressant pour les journalistes qui couvrent l'évolution des protocoles.

Les journalistes qui veulent découvrir ce que fait l'IETF sur un sujet donné seraient bien inspirés de s'entretenir avec plus qu'une seule personne qui travaille sur le sujet et dans tous les cas devraient essayer de s'entretenir avec l'animateur du groupe de travail concerné. Il est impossible de déterminer ce que deviendra un draft simplement en le lisant ou en parlant avec son auteur. Par chance, tous les groupes de travail ont des archives mis à disposition de la presse où l'on peut s'informer des progrès récents d'un document. Par malchance, peu de journalistes ont le temps où la volonté de mener ces recherches préalables. Puisque l'IETF n'a pas d'attaché de presse, un magazine ou un journal diffusant de fausses informations ne sera pas averti et non conscient de ses erreurs, il pourra fort bien les répéter par la suite.

9. Références

9.1 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 en mots.

9.2 Adresses E-mail utiles

agenda@ietf.org Demande d'un créneau horaire dans le planning des réunions IETF

ietf-info@ietf.org Questions générales sur l'IETF

ietf-registrar@ietf.org Questions sur l'inscription, les lieux de réunions et les frais d'inscription

ietf-request@ietf.org Demandes d'inscription et de désinscription aux listes IETF

ietf-secretariat@ietf.org Questions adressées au secrétariat

ietf-web@ietf.org Questions et commentaires sur le site web de l'IETF

internet-drafts@ietf.org Soumission et questions sur les Internet Drafts

minutes@ietf.org Envoi des minutes d'un groupe de travail

proceedings@ietf.org Coordinateur des comptes-rendus IETF

iana@iana.org Autorité d'attribution des adresses Internet (IANA)

rfc-ed@rfc-editor.org Rédacteur en chef des RFCs

9.3 Documents et fichiers utiles

Le site web de l'IETF, http://www.ietf.org, est la source la plus fiable pour toutes les informations sur les réunions, les groupes de travail, les documents de travail (Internet Drafts), les RFCs, les adresses e-mail de l'IETF... etc. Cliquez sur "Additional Information" pour trouver des liens utiles. D'autres documents sont également disponibles dans le répertoire "ietf" sur des sites FTP anonymes maintenus partout dans le monde. Une liste de ces sites est disponible à l'adresse http://www.ietf.org/shadow.html. Pour trouver l'information à jour concernant les documents traités, les RFCs publiés, les documents soumis à dernier appel ainsi que les rapports mensuels de l'IETF, consultez les pages de l'IESG sur http://www.ietf.org/iesg.html.

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

AD Area Director (Responsable 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)

IANA Internet Assigned Numbers Authority (Autorité d'attribution des adresses Internet)

ICANN Internet Corporation for Assigned Names and Numbers

I-D Internet Draft (document de travail)

IESG Internet Engineering Steering Group

IETF Internet Engineering Task Force

INET Conférence de l'Internet Society

IRTF Internet Research Task Force

ISO Comité International de normalisation

ISO-IEC/JTC1 Joint Technical Committee of the International Organization for
Standardization and International Electrotechnical Commission (Comité joint du comité international de normalisation et de la Commission d'Electrotechnique Internationale)

ISOC Internet Society

ITU International Telecommunication Union (Union Internationale des Télécommunications)

RFC Request For Comments

STD Standard (RFC)

W3C World Wide Web Consortium

WG Working Group (groupe de travail)

9.5 Documents cités dans le Tao

BCP 9

The Internet Standards Process" (le processus de standardisation)

 	 
BCP 10

IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees (déroulement du comité de nomination et de révocation)

BCP 11

The Organizations Involved in the IETF Standards Process (organisations impliquées dans le processus de standardisation et de normalisation)

BCP 14

Key words for use inRFCs to Indicate Requirement Levels (termes à utiliser dans les RFCs pour indiquer les niveaux de spécification)

BCP 22

Guide for Internet Standards Writers (guide pour les auteurs de standards Internet)

BCP 25

IETF Working Group Guidelines and Procedures (guide et procédures relatifs aux groupes de travail IETF)

BCP 26

Guidelines for Writing an IANA Considerations Section in RFCs (guide pour la rédaction dans les RFCs d'un chapitre concernant l'IANA)

RFC 1123

Requirements for Internet Hosts -- Application and Support (besoins des serveurs Internet d'application et de service)

RFC 1796

Not All RFCs are Standards (tous les RFCs ne sont pas des standards)

RFC 2223

Instructions to RFC Authors (instructions aux auteurs de RFCs)

 	
Considerations for Internet Drafts (quelques réflexions sur les Internet Drafts)

 	
Guidelines to Authors of Internet-Drafts (guide pour la rédaction des Internet Drafts)

Remarques sur la sécurité

Le chapitre 6.4.4 explique la nécessité d'ajouter dans chaque RFC une section sur la sécurité et donne une première idée de ce qu'elle devrait ou ne devrait pas contenir. A part cette information, le présent document ne traite pas des problèmes relatifs à la sécurité sur Internet.

Adresse de la rédactrice

Susan Harris
Merit Network, Inc.
4251 Plymouth Road, Suite 2000
Ann Arbor, MI 48105
srh@merit.edu
Déclaration de Copyright

Copyright (C) The Internet Society (2001). Tous droits réservés.

Ce document et ses traductions peuvent être copiés et distribués. Les travaux dérivés destinés à le commenter, à l'expliquer ou à faciliter sa mise en oeuvre peuvent être rédigés, copiés, publiés et distribués, en partie ou en entier, sans restriction d'aucune sorte, à condition que la mention copyright ci-dessus ainsi que ce paragraphe soient inclus sur toutes les copies et les travaux dérivés. Cependant, le présent document ne doit pas être modifié d'aucune manière, que ce soit par la suppression de la mention copyright ou des références aux titulaires de droits (Internet Society et autres organismes), excepté si nécessaire dans le but de développer des standards Internet (dans ce cas, on appliquera les procédures de copyright définies par le document sur le processus de standardisation de l'Internet), ou bien si nécessaire pour le traduire dans les autres langues que l'anglais.

L'autorisation limitée aux conditions exprimées ci-dessus est permanente et ne saurait être annulée par l'Internet Society ni par ses successeurs ou ses représentants.

Ce document et les informations délivrées ici sont fournis "tels quels" et L'INTERNET SOCIETY ET L'INTERNET ENGINEERING TASK FORCE DECLINENT TOUTE GARANTIE, EXPLICITE OU IMPLICITE, INCLUANT ENTRE AUTRES LA GARANTIE QUE L'UTILISATION DE L'INFORMATION DELIVREE ICI NE CONTREVIENDRA PAS A UN DROIT QUELCONQUE NI A UNE GARANTIE TACITE DE COMMERCIALISATION OU D'ADAPTATION A TOUT AUTRE BUT PARTICULIER.

Copyright (C) The Internet Society (2001). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 

Traduit de l'anglais par Emmanuel Josse
Document original http://www.ietf.org/tao.html