Le Tao de l'IETF

De IRHM.MP
Aller à : navigation, rechercher

Le Tao de l'IETF

Guide du novice du groupe de travail sur l'ingénierie Internet

Niels ten Oever et Kathleen Moriarty, éditeurs

Copyright © 2019 IETF Trust. Tous les droits sont réservés.


Sommaire


À propos de ce document

La version actuelle de cette page Web se trouve toujours sur [1] . Pour contribuer à ce document ou pour discuter de son contenu, veuillez vous inscrire à la liste de diffusion "tao-discuter" [2] . Une histoire des principales versions du Tao peut être trouvée ici. Cette version particulière a été créée le 2018-11-08.

Cette page Web est en anglais. Il y a une liste de traductions du Tao de l'IETF. $ Résumé

Ce document vous présente les «voies de l'IETF»: il transmettra la puissance et la magie de la mise en réseau des personnes et des paquets dans les organismes de normalisation les plus importants d'Internet. Ci-dessous, nous décrivons le fonctionnement interne des réunions et des groupes de travail de l'IETF, discutons des organisations liées à l'IETF et introduisons le processus de normalisation. Ce n'est pas un document officiel du processus de l'IETF mais un aperçu informel et informatif.

1. Introduction

Depuis ses premières années, la participation à l'Internet Engineering Task Force (IETF) a augmenté de façon phénoménale. La présence en personne aux réunions en face à face se situe désormais en moyenne entre 1 000 et 1 400 participants [3] . Beaucoup de participants sont nouveaux à l'IETF à chaque réunion, et bon nombre d'entre eux deviennent des participants réguliers. Lorsque l'IETF était plus petit, il était relativement facile pour un nouveau venu de s'adapter. Aujourd'hui, cependant, un nouveau venu rencontre beaucoup plus de nouvelles personnes, dont certaines n'étaient auparavant connues que comme les auteurs de documents ou d'e-mails incitant à la réflexion.

Ce document décrit de nombreux aspects de l'IETF, dans le but d'expliquer aux nouveaux arrivants comment l'IETF fonctionne. Cela leur permettra de rendre les réunions et les discussions des groupes de travail plus productives pour tous. Ce document a commencé assez court, mais s'est élargi au fil du temps en réponse aux suggestions des nouveaux arrivants de l'IETF sur ce qu'ils auraient voulu en savoir de plus avant d'assister à leur première réunion en face à face ou de devenir actif dans leur premier groupe de travail.

Bien sûr, il est vrai que de nombreux participants de l'IETF ne vont pas du tout aux réunions en face à face. Au lieu de cela, ils sont actifs sur les listes de diffusion de divers groupes de travail de l'IETF. Étant donné que le fonctionnement interne des groupes de travail peut être difficile à comprendre pour les nouveaux arrivants, ce document fournit les informations banales dont les nouveaux arrivants auront besoin pour devenir des participants actifs.

L'IETF est toujours dans un état de changement. Bien que les principes énoncés dans ce document devraient rester sensiblement les mêmes au fil du temps, les détails pratiques pourraient bien avoir changé au moment où vous le lisez; par exemple, un outil Web peut avoir remplacé une adresse e-mail pour demander une sorte d'action.

De nombreux types de documentation IETF sont mentionnés dans le Tao, des BCP aux RFC et aux STD. L'IETF publie sa documentation technique sous forme de RFC, poliment connue sous le nom de «Demandes de commentaires»; et les MST sont des RFC identifiés comme des "normes". Les PCA sont la meilleure réflexion actuelle de la communauté sur les meilleures pratiques actuelles sur Internet et sont également des RFC; Les trois types de documents sont dans la série de documents RFC; voir la section 6 pour plus d'informations.

Cette page Web est une continuation de la série des RFC "Tao de l'IETF". Voir RFC 6722 pour une explication de la façon dont le dernier RFC de cette série est devenu cette page Web. Cette version Web du Tao est basée sur la RFC 4677 , a été co-écrite par Paul Hoffman et Susan Harris. La version originale de ce document, publiée en 1994, a été écrite par Gary Malkin.

Alors, pourquoi "le Tao"? Prononcé "dow", le Tao est le principe de base derrière les enseignements de Lao-tse, un maître chinois. Son symbole familier est le cercle yin-yang noir et blanc. Le taoïsme conçoit l'univers comme un organisme unique et les êtres humains comme des parties interdépendantes d'un tout cosmique. Tao est parfois traduit par «la voie», mais selon la philosophie taoïste, le vrai sens du mot ne peut pas être exprimé en mots.

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

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

Terme Signification 
AD Area Director 
BCP Best Current Practice (a type of RFC) 
BOF Birds of a Feather $ FAQ Foire aux questions 
FYI For Your Information (a type of RFC) 
IAB Internet Architecture Board 
IAD Directeur administratif de l'IETF 
IANA Internet Assigned Numbers Authority 
IAOC IETF Administrative Oversight Committee 
IASA IETF Administrative Support Activity 
ICANN Internet Corporation for Assigned Names and Numbers 
ID Internet-Draft 
IESG Internet Engineering Steering Group 
IPR Intellectual property rights 
IRTF Internet Research Groupe de travail 
ISOC Internet Society 
RFC Request for Comments 
Standard STD (un type de RFC) 
WG Working Group

Le Tao de l'IETF

Guide du novice du groupe de travail sur l'ingénierie Internet

Niels ten Oever et Kathleen Moriarty, éditeurs

Copyright © 2019 IETF Trust. Tous les droits sont réservés.


À propos de ce document

La version actuelle de cette page Web se trouve toujours sur [1] . Pour contribuer à ce document ou pour discuter de son contenu, veuillez vous inscrire à la liste de diffusion "tao-discuter" [2] . Une histoire des principales versions du Tao peut être trouvée ici. Cette version particulière a été créée le 2018-11-08.

Cette page Web est en anglais. Il y a une liste de traductions du Tao de l'IETF.

Résumé

Ce document vous présente les «voies de l'IETF»: il transmettra la puissance et la magie de la mise en réseau des personnes et des paquets dans les organismes de normalisation les plus importants d'Internet. Ci-dessous, nous décrivons le fonctionnement interne des réunions et des groupes de travail de l'IETF, discutons des organisations liées à l'IETF et introduisons le processus de normalisation. Ce n'est pas un document officiel du processus de l'IETF mais un aperçu informel et informatif.

1. Introduction

Depuis ses premières années, la participation à l'Internet Engineering Task Force (IETF) a augmenté de façon phénoménale. La présence en personne aux réunions en face à face se situe désormais en moyenne entre 1 000 et 1 400 participants [3] . Beaucoup de participants sont nouveaux à l'IETF à chaque réunion, et bon nombre d'entre eux deviennent des participants réguliers. Lorsque l'IETF était plus petit, il était relativement facile pour un nouveau venu de s'adapter. Aujourd'hui, cependant, un nouveau venu rencontre beaucoup plus de nouvelles personnes, dont certaines n'étaient auparavant connues que comme les auteurs de documents ou d'e-mails incitant à la réflexion.

Ce document décrit de nombreux aspects de l'IETF, dans le but d'expliquer aux nouveaux arrivants comment l'IETF fonctionne. Cela leur permettra de rendre les réunions et les discussions des groupes de travail plus productives pour tous. Ce document a commencé assez court, mais s'est élargi au fil du temps en réponse aux suggestions des nouveaux arrivants de l'IETF sur ce qu'ils auraient voulu en savoir de plus avant d'assister à leur première réunion en face à face ou de devenir actif dans leur premier groupe de travail.

Bien sûr, il est vrai que de nombreux participants de l'IETF ne vont pas du tout aux réunions en face à face. Au lieu de cela, ils sont actifs sur les listes de diffusion de divers groupes de travail de l'IETF. Étant donné que le fonctionnement interne des groupes de travail peut être difficile à comprendre pour les nouveaux arrivants, ce document fournit les informations banales dont les nouveaux arrivants auront besoin pour devenir des participants actifs.

L'IETF est toujours dans un état de changement. Bien que les principes énoncés dans ce document devraient rester sensiblement les mêmes au fil du temps, les détails pratiques pourraient bien avoir changé au moment où vous le lisez; par exemple, un outil Web peut avoir remplacé une adresse e-mail pour demander une sorte d'action.

De nombreux types de documentation IETF sont mentionnés dans le Tao, des BCP aux RFC et aux STD. L'IETF publie sa documentation technique sous forme de RFC, poliment connue sous le nom de «Demandes de commentaires»; et les MST sont des RFC identifiés comme des "normes". Les PCA sont la meilleure réflexion actuelle de la communauté sur les meilleures pratiques actuelles sur Internet et sont également des RFC; Les trois types de documents sont dans la série de documents RFC; voir la section 6 pour plus d'informations.

Cette page Web est une continuation de la série des RFC "Tao de l'IETF". Voir RFC 6722 pour une explication de la façon dont le dernier RFC de cette série est devenu cette page Web. Cette version Web du Tao est basée sur la RFC 4677 , a été co-écrite par Paul Hoffman et Susan Harris. La version originale de ce document, publiée en 1994, a été écrite par Gary Malkin.

Alors, pourquoi "le Tao"? Prononcé "dow", le Tao est le principe de base derrière les enseignements de Lao-tse, un maître chinois. Son symbole familier est le cercle yin-yang noir et blanc. Le taoïsme conçoit l'univers comme un organisme unique et les êtres humains comme des parties interdépendantes d'un tout cosmique. Tao est parfois traduit par «la voie», mais selon la philosophie taoïste, le vrai sens du mot ne peut pas être exprimé en mots.

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

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

Terme Signification
AD Area Director
BCP Best Current Practice (a type of RFC)
BOF Birds of a Feather
FAQ Foire aux questions
FYI For Your Information (a type of RFC)
IAB Internet Architecture Board
IAD Directeur administratif de l'IETF
IANA Internet Assigned Numbers Authority
IAOC IETF Administrative Oversight Committee
IASA IETF Administrative Support Activity
ICANN Internet Corporation for Assigned Names and Numbers
ID Internet-Draft
IESG Internet Engineering Steering Group
IPR Intellectual property rights
IRTF Internet Research Groupe de travail
ISOC Internet Society
RFC Request for Comments
Standard STD (un type de RFC)
WG Working Group

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

L'IETF est un groupe de personnes vaguement auto-organisé qui contribue à l'ingénierie et à l'évolution des technologies Internet. Il s'agit du principal organisme engagé dans l'élaboration de nouvelles spécifications de normes Internet. L'IETF est inhabituel en ce qu'il existe comme un ensemble d'événements, en ligne et en personne, auxquels les individus participent volontairement. Il n'a ni membres, ni cotisations; voir RFC 3935 , «A Mission Statement for the IETF», pour plus de détails.

Sa mission comprend les éléments suivants:

  • Identifier et proposer des solutions aux problèmes opérationnels et techniques urgents sur Internet
  • Spécification du développement ou de l'utilisation de protocoles et de l'architecture à court terme pour résoudre de tels problèmes techniques pour Internet
  • Faire des recommandations au Internet Engineering Steering Group (IESG) concernant la normalisation des protocoles et l'utilisation des protocoles sur Internet
  • Faciliter le transfert de technologie de l'Internet Research Task Force (IRTF) à la communauté Internet au sens large
  • Fournir un forum pour l'échange d'informations au sein de la communauté Internet entre les fournisseurs, les utilisateurs, les chercheurs, les entrepreneurs d'agence, les opérateurs et les gestionnaires de réseau

La mission de l'IETF déclare en outre que l'Internet n'est pas neutre en termes de valeur, pas plus que l'IETF. L'IETF veut que l'Internet soit utile pour les communautés qui partagent notre engagement à l'ouverture et l'équité. L'IETF embrasse des concepts techniques tels que le contrôle décentralisé, l'autonomisation des utilisateurs de périphérie et le partage des ressources, car ces concepts résonnent avec les valeurs fondamentales de la communauté IETF. Ces concepts ont peu à voir avec la technologie qui est possible, et beaucoup à voir avec la technologie que nous choisissons de créer.

La réunion de l'IETF n'est pas une conférence, bien qu'il y ait des présentations techniques. L'IETF n'est pas une organisation de normalisation traditionnelle, bien que de nombreuses spécifications produites deviennent des normes. L'IETF est composé de bénévoles, dont beaucoup se réunissent trois fois par an pour remplir la mission de l'IETF.

Il n'y a pas d'adhésion à l'IETF. N'importe qui peut s'inscrire aux listes de diffusion des groupes de travail, ou s'inscrire à une réunion, puis y assister. Ce qui se rapproche le plus de la qualité de membre de l'IETF, c'est d'être un participant sur les listes de diffusion de l'IETF ou du groupe de travail (voir section 2.3). C'est là que se trouvent les meilleures informations sur les activités et les priorités actuelles de l'IETF.

Bien sûr, aucune organisation ne peut réussir autant que l'IETF sans avoir une sorte de structure. Dans le cas de l'IETF, cette structure est fournie par d'autres organisations, comme décrit dans la RFC 2028 , «Les organisations impliquées dans le processus de normalisation de l'IETF». Si vous participez à l'IETF et ne lisez qu'un seul BCP, c'est celui que vous devez lire.

Le site Web de l'IETF est la meilleure source d'informations sur les réunions à venir de l'IETF, les matériaux pour les nouveaux arrivants. L'IETF Datatracker est la meilleure source d'informations sur les brouillons Internet, les RFC et les groupes de travail.

À bien des égards, l'IETF fonctionne sur les croyances de ses participants. L'une des "croyances fondatrices" est incarnée dans une première citation sur l'IETF de David Clark: "Nous rejetons les rois, les présidents et le vote. Nous croyons au consensus et au code en vigueur". Une autre première citation qui est devenue une croyance populaire dans l'IETF vient de Jon Postel: "Soyez conservateur dans ce que vous envoyez et libéral dans ce que vous acceptez".

L'IETF est vraiment au sujet de ses participants. L'IETF accueille toutes les personnes intéressées: les participants à l'IETF viennent du monde entier et de nombreuses parties différentes de l'industrie Internet. L'IETF mène ses travaux uniquement en anglais. Voir la section 3.12 pour plus d'informations sur la manière dont de nombreuses personnes s'intègrent à l'IETF.

Une dernière chose qui est importante pour les nouveaux arrivants: l'IETF ne "gère en aucun cas Internet", malgré ce que certaines personnes pourraient dire à tort. L'IETF établit des normes volontaires qui sont souvent adoptées par les utilisateurs d'Internet, les opérateurs de réseau et les fournisseurs d'équipement, mais elle ne contrôle pas, ni même ne patrouille, Internet. Si votre intérêt pour l'IETF est que vous voulez faire partie des superviseurs, vous pouvez être déçu par l'IETF.

2.1 Humble débuts

La première réunion de l'IETF s'est tenue en janvier 1986 à Linkabit à San Diego, avec 21 participants. La 4e IETF, tenue au SRI à Menlo Park en octobre 1986, a été la première à laquelle les vendeurs ont assisté. Le concept des groupes de travail a été présenté lors de la 5e réunion de l'IETF au NASA Ames Research Center en Californie en février 1987. La 7e IETF, tenue au MITRE à McLean, Virginie, en juillet 1987, était la première réunion avec plus de 100 participants.

La 14e réunion de l'IETF s'est tenue à l'Université de Stanford en juillet 1989. Elle a marqué un changement majeur dans la structure de l'univers de l'IETF. La structure de l'IAB (alors Internet Activités Board, maintenant Internet Architecture Board), qui jusque-là supervisait de nombreux "groupes de travail", a été modifiée, ne laissant que deux: l'IETF et l'IRTF. L'IRTF est chargé d'examiner les problèmes de recherche à long terme sur Internet. L'IETF a également changé à cette époque.

Après la création de l'Internet Society (ISOC) en janvier 1992, l'IAB a proposé à l'ISOC que les activités de l'IAB se déroulent sous les auspices de l'Internet Society. Lors de l'INET92 à Kobe, au Japon, les administrateurs de l'ISOC ont approuvé une nouvelle charte pour l'IAB afin de refléter la relation proposée.

L'IETF s'est réunie à Amsterdam, aux Pays-Bas, en juillet 1993. Il s'agissait de la première réunion de l'IETF en Europe, et la répartition des participants américains / non américains était de près de 50/50. L'IETF s'est réunie pour la première fois en Asie (à Adélaïde, Australie) en 2000.

L'IETF s'efforce actuellement d'avoir une politique de réunions 1-1-1 dans le but de répartir les réunions également entre l'Amérique du Nord, l'Europe et l'Asie. Ce sont les endroits où la plupart des participants de l'IETF sont venus dans un passé récent. La politique de rotation des réunions vise principalement à répartir l'effort de voyage pour les participants actuels de l'IETF qui assistent physiquement aux réunions et à répartir la difficulté du fuseau horaire pour ceux qui participent à distance. L'IETF s'est également réuni en Amérique latine et en Océanie, mais ces continents ne font actuellement pas partie du calendrier de rotation 1-1-1.

La participation à distance aux réunions de l'IETF a considérablement augmenté au cours des dernières années, en partie grâce aux efforts continus pour améliorer les outils et les processus utilisés pour faciliter ce mode de participation.

2.2 La hiérarchie

2.2.1 L'IETF LLC (IETF Administration LLC) et l'ISOC (Internet Society)

L'Internet Society est une organisation internationale à but non lucratif qui soutient et promeut le développement d'Internet en tant qu'infrastructure technique mondiale, ressource pour enrichir la vie des gens et force du bien dans la société. Une des façons pour l'ISOC de le faire est de soutenir l'IETF.

À partir du printemps 2005, l'ISOC est devenu le port d'attache du personnel administratif directement employé de l'IETF. Ceci est décrit plus en détail dans le BCP 101, "Structure de l'IETF Administrative Support Activity (IASA)". Le personnel comprenait uniquement un directeur administratif (IAD) qui travaillait à plein temps pour superviser la planification des réunions de l'IETF, les aspects opérationnels des services de soutien (le secrétariat, l'IANA (Internet Assigned Numbers Authority) et l'éditeur RFC, qui sont décrits plus loin dans cette section. ) et le budget. L'IAD a dirigé l'activité de soutien administratif de l'IETF (IASA), qui a pris en charge des tâches telles que la collecte des frais de réunion et le paiement des factures, et prend également en charge les outils pour le travail des groupes de travail de l'IETF, l'IESG, l'IAB et l'IRTF (plus à ce sujet plus loin dans cette section).

Récemment, sur la base des discussions au sein du groupe de travail IASA2, l'IETF Administration LLC a été créée en tant qu'entité ignorée de l'Internet Society (c'est-à-dire qu'elle est traitée comme une succursale ou une division à des fins fiscales). Il n'a aucun rôle dans la surveillance ou le pilotage du processus de normalisation tel qu'il est actuellement mené par l'IESG et l'IAB, la chaîne d'appel, les organismes de confirmation des nominations actuelles à l'IETF et à l'IAB, l'IRTF ou les adhésions de l'ISOC à d'autres organisations. Les responsabilités de l'IETF LLC comprennent:

  • Soutenir les opérations en cours de l'IETF, y compris les réunions et les activités hors réunion,
  • Gestion des finances et du budget de l'IETF,
  • Collecte de fonds au nom de l'IETF, et
  • Établir et appliquer des politiques pour garantir la conformité avec les lois, réglementations et règles applicables.

L'IETF et l'ISOC continuent d'être fortement alignés sur les principes clés. Les initiatives de l'ISOC liées à l'IETF continuent de soutenir la participation et le déploiement des normes créées par l'IETF. La nouvelle structure juridique est conçue pour permettre à l'IETF de répondre aux changements de taille et de portée des besoins administratifs de l'IETF, elle clarifie la responsabilité et l'autorité sur l'administration de l'IETF, et est suffisamment flexible pour s'adapter aux changements à mesure que les besoins de l'IETF continuent de évoluer.

2.2.2 IESG (Internet Engineering Steering Group)

L'IESG est responsable de la gestion technique des activités de l'IETF et du processus des normes Internet. Il administre le processus conformément aux règles et procédures qui ont été ratifiées par le Conseil d'administration de l'ISOC. Cependant, l'IESG n'exerce pas beaucoup de leadership direct, comme celui que vous trouverez dans de nombreux autres organismes de normalisation. Comme son nom l'indique, son rôle est de donner des orientations plutôt que de donner des ordres. L'IESG ratifie ou dirige la sortie des groupes de travail (GT) de l'IETF, démarre et termine les GT et s'assure que les brouillons non-GT qui sont sur le point de devenir des RFC sont corrects.

Consultez les pages Web de l'IESG pour trouver des informations à jour sur les relevés de l'IESG, les projets traités, les RFC publiés et les documents dans Last Call, ainsi que les rapports mensuels de statut de l'IETF.

L'IESG est composé des directeurs régionaux (souvent appelés "AD"), qui sont sélectionnés par le comité des candidatures (qui est généralement appelé "le NomCom") et sont nommés pour deux ans. Le processus de sélection des membres de l'IESG est détaillé dans le BCP 10, "Processus de sélection, de confirmation et de rappel de l'IAB et de l'IESG: Fonctionnement des comités de nomination et de rappel".

Les zones et abréviations actuelles sont indiquées ci-dessous (plus d'informations peuvent être trouvées ici: [4] ). Description de la zoneApplications et protocoles de zone (art) en temps réel vus par les programmes utilisateur, tels que le courrier électronique et le Web et sensibles aux retards

communications interpersonnellesProcessus général (gen) IETF, et fourre-tout pour les groupes de travail qui ne correspondent pas à d'autres domaines (qui est très peu)Internet (int) Différentes façons de déplacer les paquets IP et les informations DNSOpérations et gestion (ops) Gestion de réseau, AAA et divers problèmes opérationnels auxquels est confronté InternetRoutage (rtg) Acheminement des paquets vers leurs destinationsSécurité (sec) Confidentialité, intégrité, authentification, non-répudiation, confidentialité et contrôle d'accèsTransport (tsv) Transport pour de gros volumes de trafic à des bandes passantes potentiellement élevées

Parce que l'IESG examine tous les projets Internet avant qu'ils ne deviennent des RFC, les directeurs de zone ont pas mal d'influence. Certaines personnes hésitent donc à s'engager directement avec les directeurs régionaux, alors qu'elles peuvent être une ressource importante et vous aider à trouver la personne ou la réponse que vous recherchez. Lors d'une réunion, ils pourraient être très occupés. Un courriel pour planifier une réunion est un excellent moyen d'entrer en contact. L'envoi d'un e-mail avec la question réelle avant ou après une réunion est également efficace.

Les AD pour une zone particulière devraient en savoir plus que quiconque sur le travail combiné des groupes de travail dans cette zone. Cela est dû au fait que les AD suivent activement les groupes de travail dont ils sont responsables et aident les groupes de travail et les présidents à réviser la charte et les étapes. L'IESG dans son ensemble examine chaque projet Internet qui est proposé pour devenir un RFC et doit être au courant des tendances générales qui peuvent être glanées à partir des produits de travail collectif de l'IETF. Dans le cadre de l'examen des documents, les DA déposent des bulletins de vote pouvant contenir des commentaires sur les documents. L'AD prend une position qui peut être OUI, PAS D'OBJECTION, DISCUTER, ABSTENIR ou RECUSER à la suite de leur examen. Tout AD peut enregistrer une position de vote "DISCUTER" contre un projet s'il a de sérieuses préoccupations et souhaite en discuter. Il est assez courant que les documents soient approuvés avec un ou deux bulletins "OUI", et la majorité des autres votes de l'IESG "PAS D'OBJECTION".

Cela ne veut pas dire que l'IESG n'exerce jamais de pouvoir. Lorsque l'IESG voit un groupe de travail s'écarter de sa charte, ou lorsqu'un GT demande à l'IESG de faire du protocole mal conçu du GT une norme, l'IESG agira. En fait, en raison de sa charge de travail élevée, l'IESG se déplace généralement de manière réactive. Il approuve finalement la plupart des demandes de GT pour que les brouillons Internet deviennent des RFC, et n'intervient généralement que lorsque quelque chose a très mal tourné. Une autre façon de penser à cela est que les AD sont sélectionnés pour réfléchir, pas simplement pour exécuter le processus. La qualité des normes de l'IETF provient à la fois de l'examen qu'ils obtiennent dans les groupes de travail et de l'examen que l'examen du GT reçoit des AD.

L'IETF est géré par un consensus approximatif, et c'est l'IESG qui juge si un groupe de travail a abouti à un résultat qui a le consensus de la communauté IETF. (Voir la section 4.2 pour plus d'informations sur le consensus du GT.) Pour cette raison, l'une des principales raisons pour lesquelles l'IESG pourrait bloquer quelque chose qui a été produit dans un GT est que le résultat n'a pas vraiment obtenu un consensus dans l'IETF dans son ensemble, que est, parmi tous les groupes de travail dans tous les domaines. Par exemple, le résultat d'un GT pourrait entrer en conflit avec une technologie développée dans un autre groupe de travail, peut-être dans un autre domaine. Un travail important de l'IESG est de surveiller la sortie de tous les groupes de travail pour aider à empêcher les protocoles IETF qui sont en désaccord les uns avec les autres. C'est pourquoi les DA sont censés examiner les ébauches provenant de zones autres que les leurs.

2.2.3 IAB (Internet Architecture Board)

L'IAB est chargé de garder un œil sur la «vue d'ensemble» de l'Internet, et il se concentre sur la planification à long terme et la coordination entre les différents domaines d'activité de l'IETF. L'IAB reste informé des problèmes importants à long terme sur Internet et il porte ces sujets à l'attention des personnes qu'il pense devoir connaître à leur sujet.

Les membres de l'IAB accordent une attention particulière aux activités émergentes de l'IETF. Lorsqu'un nouveau groupe de travail de l'IETF est proposé, l'IAB revoit sa charte pour la cohérence et l'intégrité architecturales. Avant même que le groupe soit agréé, les membres de l'IAB sont plus que disposés à discuter de nouvelles idées avec les personnes qui les proposent.

L'IAB parraine et organise également le groupe de travail sur la recherche sur Internet et organise des ateliers sur invitation qui fournissent des analyses approfondies de problèmes architecturaux spécifiques à Internet. En règle générale, les rapports d'atelier font des recommandations à la communauté de l'IETF et à l'IESG. L'IAB tient la communauté informée grâce à des articles de blog et en publiant des RFC.

L'IAB a également:

  • Approuve les nominations IESG de NomCom
  • Agit en tant que commission d'appel pour les appels contre les actions de l'IESG et de l'ISOC,
  • Supervise la série RFC par le biais du Comité de surveillance de la série RFC (RSOC),
  • Approuve la nomination de l'IANA
  • Agit en tant qu'organe consultatif auprès de l'ISOC
  • Supervise les liaisons de l'IETF avec d'autres organismes de normalisation

Comme l'IESG, les membres de l'IAB sont sélectionnés pour des postes de deux ans par le NomCom et sont approuvés par le Conseil d'administration de l'ISOC.

2.2.4 IANA (Internet Assigned Numbers Authority)

Le bureau d'enregistrement principal pour les activités de l'IETF est l'IANA (voir https://www.iana.org ). De nombreux protocoles Internet nécessitent que quelqu'un garde une trace des éléments de protocole qui ont été ajoutés après la sortie du protocole. Des exemples typiques des types de registres nécessaires sont pour les numéros de port TCP et les types MIME. L'IAB a désigné l'organisation IANA pour effectuer ces tâches, et les activités de l'IANA sont soutenues financièrement par l'ICANN, Internet Corporation for Assigned Names and Numbers. L'IAB a sélectionné l'ICANN et les activités de l'IANA sont fournies gratuitement comme spécifié dans la RFC 2860 .

Il y a dix ans, personne ne s'attendait à voir l'IANA mentionnée en première page d'un journal. Le rôle de l'IANA a toujours été très discret. Le fait que l'IANA était également le gardien de la racine du système de noms de domaine l'a forcée à devenir une entité beaucoup plus publique, qui a été gravement décriée par une variété de personnes qui n'ont jamais regardé quel était son rôle. De nos jours, l'IETF n'est généralement plus impliquée dans les fonctions d'attribution de noms de domaine et d'adresses IP de l'IANA, qui sont supervisées par l'ICANN.

Même si être un registraire peut ne pas sembler intéressant, de nombreux participants à l'IETF témoigneront de l'importance de l'IANA pour Internet. Avoir un référentiel stable et à long terme géré par des opérateurs prudents et conservateurs permet aux gens d'expérimenter beaucoup plus facilement sans se soucier de gâcher les choses. Les premiers responsables de l'IANA, Jon Postel et Joyce Reynolds, étaient fortement sollicités pour maintenir les choses en ordre tandis qu'Internet ne cessait de croître à pas de géant.

2.2.5 Editeur RFC

L'éditeur RFC édite, met en forme et publie Internet-Drafts en tant que RFC, en collaboration avec l'IESG pour les RFC IETF, le président de l'IRTF pour les RFC IRTF, l'IAB pour les RFC IAB et l'éditeur de soumissions indépendant pour les RFC de flux indépendant, et de cours de travail avec les auteurs. Un autre rôle important est de fournir un référentiel définitif pour tous les RFC (voir [5] ). Une fois qu'un RFC est publié, il n'est jamais révisé. Si la spécification qu'elle décrit change, la norme sera republiée dans une autre RFC qui "obsolète" la première. Si une erreur technique ou éditoriale est trouvée dans un RFC, un errata peut être déposé pour examen. S'ils sont acceptés, les errata seront liés au RFC et pourront être conservés pour la prochaine mise à jour du document.

L'IAB approuve l'organisation qui agira en tant qu'éditeur RFC et la politique générale de l'éditeur RFC. L'éditeur RFC est financé par l'IASA. Jusqu'à la fin de 2009, l'éditeur RFC était une entité unique. La fonction a été divisée par l'IAB, en coordination avec la communauté de l'IETF, en de nombreux rôles pouvant être exécutés par différentes personnes ou organisations, dirigés par l'éditeur RFC Series nommé par l'IAB. Le modèle de l'éditeur RFC est décrit dans la RFC 6635 .

Une idée fausse commune est que tous les RFC sont le travail de l'IETF. En fait, parmi les quatre sources de RFC énumérées ci-dessus (IETF, IAB, IRTF et soumissions indépendantes), seules celles provenant directement de l'IETF par le biais de groupes de travail ou parrainées par des AD sont capables d'avoir un consensus IETF et d'être décrites comme des spécifications IETF ou normes.

2.2.6 Secrétariat de l'IETF

Il y a, en fait, quelques personnes qui sont payées pour entretenir l'IETF. Le Secrétariat de l'IETF fournit un soutien logistique au jour le jour, ce qui signifie principalement la coordination des réunions en face à face et la gestion des listes de diffusion spécifiques à l'IETF. Le Secrétariat est également responsable de la mise à jour et de la mise à jour du répertoire officiel des projets Internet, de la maintenance du site Web de l'IETF et de l'aide à l'IESG dans son travail. Il fournit divers outils à l'usage de la communauté et de l'IESG. Le Secrétariat de l'IETF est sous contrat avec l'IASA, qui à son tour est financièrement soutenu par les frais perçus pour assister aux réunions en face à face, les parrainages et les contributions de l'ISOC.

2.2.7 IETF Trust

Vers la fin de 2005, l'IETF Trust a été créé pour détenir et concéder sous licence la propriété intellectuelle de l'IETF. La raison pour laquelle l'IETF Trust a été créé est que quelqu'un doit détenir une propriété intellectuelle et que quelqu'un doit être une entité stable et légalement identifiable. Peu de participants à l'IETF entrent en contact avec l'IETF Trust, ce qui est un bon signe qu'ils font tranquillement leur travail. Vous pouvez en savoir plus sur la confiance de l'IETF sur leur site Web.

2.3 Listes de diffusion IETF

Quiconque envisage de participer à l'IETF, y compris d'assister à une réunion de l'IETF, devrait rejoindre la liste de diffusion d'annonces de l'IETF (voir [6] ). C'est là que toutes les informations de réunion, les annonces RFC et les actions de protocole IESG et les derniers appels sont affichés. Les personnes qui souhaitent "devenir techniques" peuvent également rejoindre la liste de discussion générale de l'IETF (voir [7] ). C'est là que se déroulent les discussions générales (les groupes de travail ont leurs propres listes de diffusion pour les discussions liées à leur travail). Une autre liste de diffusion annonce chaque nouvelle version de chaque Internet-Draft au fur et à mesure de sa publication (voir [8] ).

Les abonnements à ces listes de diffusion et à d'autres listes de diffusion gérées par l'IETF sont gérés par un programme appelé "mailman". Mailman peut être quelque peu pointilleux sur le format des messages d'abonnement et interagit parfois mal avec les programmes de messagerie qui transforment tous les messages électroniques en fichiers HTML. Mailman vous traitera bien, cependant, si vous formatez vos messages comme il le souhaite.

La liste de discussion de l'IETF n'est pas modérée. Cela signifie que tous peuvent exprimer leurs opinions sur les problèmes affectant Internet. Cependant, ce n'est pas un endroit pour les entreprises ou les particuliers pour solliciter ou faire de la publicité, comme indiqué dans le BCP 45, "IETF Discussion List Charter". C'est une bonne idée de lire l'intégralité du RFC (c'est court!) Avant de poster sur la liste de discussion de l'IETF. En fait, la liste contient deux «sergents d'armes» qui gardent un œil ouvert pour les affectations inappropriées, et il existe un processus pour interdire les délinquants persistants de la liste, mais heureusement, cela est extrêmement rare.

Seul le Secrétariat et un petit nombre de dirigeants de l'IETF peuvent approuver les messages envoyés à la liste d'annonces, bien que ces messages puissent provenir de diverses personnes.

Même si les listes de diffusion de l'IETF "représentent" les participants de l'IETF en général, il est important de noter que la participation à une réunion de l'IETF ne signifie pas que vous serez automatiquement ajouté à l'une ou l'autre liste de diffusion.

3. Réunions de l'IETF

L'industrie informatique regorge de conférences, de séminaires, d'expositions et de toutes sortes d'autres types de réunions. Les réunions face à face de l'IETF ne sont pas comme celles-ci. Les réunions, tenues trois fois par an, sont des rassemblements d'une semaine dont l'objectif principal est de revigorer les GT pour accomplir leurs tâches, et dont l'objectif secondaire est de promouvoir un bon mélange entre les GT et les zones.

Pour beaucoup de gens, les réunions de l'IETF sont une bouffée d'air frais par rapport aux conférences standard de l'industrie informatique. Il n'y a pas de salle d'exposition, peu de tutoriels et pas de grands experts de l'industrie. Au lieu de cela, il y a beaucoup de travail, ainsi que beaucoup de temps pour socialiser pour de nombreux participants. Les réunions de l'IETF intéressent peu les commerciaux et le marketing, mais intéressent fortement les ingénieurs et les développeurs.

Le flux général d'une réunion de l'IETF est qu'elle commence par un hackathon le samedi et le dimanche, des tutoriels et une réunion informelle le dimanche, et qu'il y a des réunions du GT et de la BoF du lundi au vendredi. Les réunions des groupes de travail durent entre 1 et 2,5 heures chacune, et certains groupes de travail se réunissent plusieurs fois au cours de la semaine, selon la quantité de travail qu'ils prévoient de faire.

Il y a une session plénière pendant la semaine. Habituellement, une partie de la plénière comprend une présentation technique organisée par l'IAB et avec un ou deux groupes d'experts sur des sujets d'intérêt dans de nombreux groupes de travail et domaines. La partie administrative de la session plénière, organisée par le président de l'IETF, couvre des choses comme les rapports d'avancement du RFC Editor et les annonces des prochaines réunions. Les plénières comprennent également une partie "micro ouvert", qui est un bon moment pour partager avec l'IESG et l'IAOC. La louange est la bienvenue, mais le plus souvent, des inquiétudes et des reproches sont soulevés.

Actuellement, l'IETF se réunit en Amérique du Nord, en Europe et en Asie, environ une fois par an dans chaque région. Il y a eu plus de 100 réunions de l'IETF à ce jour, et une liste des réunions à venir est disponible sur les pages Web de l'IETF. Vous pouvez en savoir plus sur la politique et le processus de sélection des réunions ici.

Les nouveaux arrivants aux réunions en face à face de l'IETF s'attendent souvent à ce qu'ils soient comme d'autres organismes de normalisation ou comme des conférences informatiques. Heureusement, de nombreux nouveaux participants s'animent assez sur le plaisir qu'ils ont. D'un autre côté, les IETFers peuvent parfois être étonnamment directs, parfois à la grossièreté. Pour créer un climat dans lequel des personnes d'horizons différents sont traitées avec dignité, décence et respect, l'IETF a une politique anti-harcèlement, ombudsteam.

3.1 Inscription

Pour assister à une réunion de l'IETF en personne, vous devez vous inscrire et payer des frais d'inscription. Le lieu de la réunion et l'inscription à l'avance sont annoncés au moins deux mois avant la réunion - plus tôt si possible. Une annonce est envoyée par e-mail à la liste de diffusion des annonces de l'IETF, et des informations sont publiées sur le site Web de l'IETF, le même jour.

Vous devez également vous inscrire pour participer à distance; il n'y a actuellement aucun frais d'inscription pour la participation à distance.

Vous pouvez vous inscrire et payer sur le Web avant la réunion, ou en personne à la réunion. Pour obtenir des frais d'inscription moins élevés, vous devez payer avant la date limite d'inscription hâtive (au moins sept semaines avant la réunion). La fenêtre des frais d'inscription standard se ferme 2 semaines avant la réunion, si vous vous inscrivez à tout moment par la suite, vous devrez payer les frais d'inscription tardive. Les frais d'inscription couvrent toutes les réunions de la semaine, la réception de bienvenue du dimanche soir et les pauses boissons et collations l'après-midi.

L'inscription est ouverte toute la semaine de la réunion. Vous pouvez en savoir plus sur la façon dont l'IETF traite vos données personnelles ici: [9] .

Si vous participez à une réunion de l'IETF pour la première fois, vous pouvez également envisager de vous abonner à la liste de diffusion spécifique à la réunion, qui est présentée en option lorsque vous vous inscrivez pour participer à la réunion en personne ou à distance. Les discussions sur la liste des réunions peuvent être volumineuses et assez variées sur des questions spécifiques à la réunion, mais c'est également un moyen de partager des informations que beaucoup trouvent utiles pour comprendre ce qui se passe pendant la réunion elle-même.

Le dimanche est une excellente journée pour rejoindre la réunion, sauf si vous nous avez déjà rejoint lors du hackathon samedi. Le dimanche est le jour du tutoriel pour les nouveaux arrivants, ainsi que de la session Quick Connections où les nouveaux arrivants rencontrent des participants expérimentés de l'IETF et du Newcomer's Meet and Greet où les nouveaux arrivants peuvent rencontrer les directeurs régionaux et les présidents des groupes de travail. Après ces sessions, il y a la réception qui est un événement populaire où vous pouvez prendre une petite bouchée à manger et socialiser avec d'autres participants.

Avant de vous inscrire, vous voyez une page Web intitulée «Note bien». Vous devez en effet le lire attentivement car il énonce les règles relatives aux droits de propriété intellectuelle de l'IETF. La note indique les documents justificatifs pour les DPI, la lutte contre le harcèlement et d'autres politiques d'orientation importantes pour l'IETF.

Si vous devez laisser des messages à d'autres participants, vous pouvez le faire aux panneaux de liège qui sont souvent près du bureau d'inscription. Ces planches de liège auront également des changements de réunion de dernière minute et des changements de salle.

Vous pouvez également remettre les objets trouvés au bureau d'inscription. À la fin de la réunion, tout ce qui restera des objets trouvés sera généralement remis à l'hôtel ou ramené au bureau du Secrétariat.

Soit dit en passant, le bureau d'inscription de l'IETF est souvent un endroit pratique pour organiser des rencontres. Si quelqu'un dit "me rencontrer lors de l'inscription", vous devez préciser s'il s'agit du bureau d'inscription de l'IETF ou du bureau d'inscription de l'hôtel. Cela a été une cause fréquente de connexions manquées.

3.2 Faites le grand saut et restez toute la semaine!

Les réunions du groupe de travail de l'IETF sont prévues du lundi matin au vendredi après-midi. Les réunions non-GT associées ont souvent lieu le week-end précédent ou suivant. Il est préférable de prévoir d'être présent toute la semaine, de bénéficier de la fertilisation croisée entre les groupes de travail et des discussions sur les couloirs. Comme indiqué ci-dessous, l'ordre du jour est fluide et il y a eu de nombreux cas où les participants ont manqué des sessions importantes en raison de changements d'horaire de dernière minute après que leurs plans de voyage ont été fixés. Être présent toute la semaine est le seul moyen d'éviter ce désagrément.

Si vous ne trouvez pas de réunions toute la semaine pour vous intéresser, vous pouvez toujours tirer le meilleur parti de la réunion de l'IETF en travaillant entre les sessions. La plupart des participants à l'IETF portent des ordinateurs portables, et il est courant d'en voir beaucoup dans la salle des terminaux ou dans les couloirs pendant les sessions de réunion. Il y a souvent une bonne couverture Internet sans fil dans de nombreux endroits du lieu de réunion (restaurants, cafés, etc.), donc rattraper son retard sur les e-mails en dehors des réunions est une tâche assez courante pour les IETFers.

3.3 Formation des nouveaux arrivants

Les nouveaux arrivants sont encouragés à assister au tutoriel pour les nouveaux arrivants le dimanche après-midi, qui est spécialement conçu pour les nouveaux participants. Le tutoriel est organisé et mené par l'équipe IETF EDU et est destiné à fournir des informations d'introduction utiles. La session couvre ce que signifient tous les points sur les étiquettes de nom, la structure de l'IETF et de nombreux autres sujets essentiels et éclairants pour les nouveaux IETFers. Si vous ne pouvez pas assister à cette session, les sessions enregistrées des réunions précédentes sont disponibles ( [10] ).

Plus tard dans l'après-midi est la session Quick Connections où les nouveaux arrivants ont la chance de connaître les participants seniors de l'IETF et de poser des questions. La session Quick Connections est suivie du Meet and Greet du nouvel arrivant, qui est uniquement ouvert aux nouveaux arrivants et aux présidents des groupes de travail. C'est un excellent endroit pour essayer de trouver des personnes compétentes dans les domaines qui vous intéressent. C'est une bonne occasion de vous connecter aux présidents des groupes de travail qui vous intéressent. Si vous ne trouvez pas facilement la bonne personne ou si vous ne savez pas à quel groupe de travail vos intérêts sont liés, n'hésitez pas à contacter quiconque sans ruban pour nouveaux arrivants pour vous aider à entrer en contact avec les bonnes personnes.

3.4 Code vestimentaire

Lors des réunions, les gens s'habillent généralement de manière informelle. Les nouveaux arrivants sont parfois déplacés lorsqu'ils se présentent lundi matin en costume. La règle générale est «habillez-vous pour la météo» (à moins que vous ne prévoyiez travailler si dur que vous ne sortiez pas, auquel cas, «habillez-vous pour le confort» est la règle!).

3.5 réunions du GT

Le cœur d'une réunion de l'IETF est les réunions du GT elles-mêmes. Les différents présidents des groupes de travail ont des styles très différents, il est donc impossible de généraliser la sensation d'une réunion de groupe de travail. Même si presque tous les groupes de travail ont des ordres du jour pour leurs réunions, certaines réunions respectent strictement leur ordre du jour tandis que d'autres sont plus lâches.

Il y a quelques choses importantes qui sont vraies pour toutes les réunions du GT lors d'une réunion de l'IETF. Vers le début de la réunion, le président fera le tour des "draps bleus", qui sont des formulaires papier sur lesquels chacun inscrit son nom et son affiliation. Ils sont utilisés à des fins d'archivage à long terme pour montrer combien de personnes sont venues à une réunion particulière et, dans de rares cas, exactement qui s'est présenté. L'étiquette normale est de regarder d'où viennent les draps bleus et de les faire passer dans la même direction.

Lorsque vous parlez en réunion, vous devez toujours vous rendre aux microphones de la salle. Pour les sujets controversés, il y aura une ligne au micro, mais n'hésitez pas à être la première personne au micro si vous avez une question ou une contribution à la discussion. Le président ou le présentateur du GT indiquera quand vous pourrez parler. Bien qu'il soit plus facile de simplement lever la main d'où vous êtes assis, les micros effectuent une tâche très utile: ils permettent aux personnes qui écoutent à distance et dans la pièce d'entendre votre question ou votre commentaire. On s'attend également à ce que vous prononciez votre nom au micro pour que la personne qui prend les minutes sache qui parle.

3.6 Voir les taches sous vos yeux

Certaines personnes à l'IETF auront un petit point coloré sur leur étiquette de nom. Quelques personnes en ont plus d'un. Ces points identifient les personnes qui sont assez stupides pour se porter volontaires pour faire beaucoup de travail supplémentaire. Les couleurs ont la signification indiquée ici.

Couleur SignificationBlue Working Group / BOF ChairGroupe d'accueil vertMembre IAB rougeMembre IESG jauneMembre du comité de nomination d'OrangeTableau noir IETF LLCIRSG roseÉditeur de séries RFC Teal (Les membres de la presse portent des badges teintés d'orange avec le mot «presse» dessus.)

Il est important que les nouveaux arrivants à l'IETF n'aient pas peur d'entamer des conversations avec les personnes qui portent ces points. Si les membres de l'IAB et de l'IESG et les présidents des groupes de travail et BOF ne voulaient parler à personne, ils ne porteraient pas les points en premier lieu. Notez, cependant, que les réunions de l'IETF sont généralement des moments intenses pour les directeurs de zone. Parler à un AD lors d'une réunion de l'IETF conduira souvent à une demande de lui envoyer un e-mail environ deux semaines plus tard. De plus, lorsque vous commencez une conversation dans un couloir avec un directeur de secteur (ou même un président de GT, d'ailleurs), il est souvent bon de leur donner environ 30 secondes de contexte pour la discussion.

3.7 Terminal Room

Le centre des opérations réseau (NOC) fournit un accès Internet aux participants à chaque réunion. En général, la connectivité sans fil est excellente dans toutes les salles de réunion et les zones les plus communes, et la connectivité filaire est fournie dans la salle des terminaux. Les personnes et les entreprises qui donnent leur équipement, leurs services et leur temps doivent être chaleureusement félicitées et remerciées.

Bien que la préparation bien avant la réunion soit encouragée, il peut y avoir des choses inévitables de "dernière minute" qui peuvent être accomplies dans la salle des terminaux. Il peut également être utile aux personnes qui ont besoin de faire des rapports de voyage ou des rapports d'état alors que les choses sont encore fraîches dans leur esprit.

Vous devez porter votre badge pour entrer dans la salle des terminaux. Le terminal propose de nombreuses barrettes d'alimentation, de nombreux ports Ethernet pour les ordinateurs portables, sans fil (pour les personnes qui n'ont pas besoin d'Ethernet mais qui veulent de l'énergie) et généralement une imprimante à usage public. Ce qu'il ne fournit pas, ce sont des terminaux; le nom est historique. Le service d'assistance dans la salle des terminaux est un bon endroit pour poser des questions sur les pannes de réseau, bien qu'il puisse vous orienter vers différents membres du réseau.

3.8 Repas et autres délices

Marshall Rose a dit un jour que l'IETF était un endroit où aller pour "de nombreux déjeuners et dîners raffinés". Bien qu'il soit vrai que certaines personnes mangent très bien à l'IETF, elles trouvent la nourriture par elles-mêmes; les déjeuners et dîners ne sont pas inclus dans les frais d'inscription. Si le parrainage est assuré, le Secrétariat organise des amuse-gueules lors de la réception de bienvenue du dimanche soir (non destinée à remplacer le dîner), dans certains lieux, un petit-déjeuner continental du lundi au vendredi matin et (mieux encore) des biscuits, des brownies , fruits et autres délicieux pendant certaines des pauses de l'après-midi. Ceux-ci sont très souvent payés par l'hôte de la réunion ou un sponsor de la réunion.

Si vous préférez sortir de l'hôtel pour les repas, l'hôte local fournit généralement une liste des endroits où manger à proximité du lieu de la réunion.

3.9 Événement social

Une autre des choses les plus importantes organisées et gérées par l'hôte est l'événement social de l'IETF. L'événement social est parfois un événement lié à la haute technologie, ou il peut être dans un musée d'art ou une salle de réception. Notez, cependant, que toutes les réunions de l'IETF ont des événements sociaux.

Les nouveaux arrivants à l'IETF sont encouragés à assister à l'événement social. Tous sont encouragés à porter leur porte-nom et à laisser leur ordinateur portable derrière. L'événement social est conçu pour donner aux gens une chance de se rencontrer à un niveau social plutôt que technique.

3.10 Agenda

L'ordre du jour des réunions de l'IETF est une chose très fluide. Il est disponible sur le Web et via les applications mobiles de l'IETF à partir de quelques semaines avant la réunion. Des agendas de petite taille sont disponibles pour le ramassage au bureau d'inscription pour ceux qui ont une bonne vue et qui veulent garder une copie dans leur poche ou attachée au dos de leur badge. Bien sûr, «final» dans l'IETF ne signifie pas la même chose qu'ailleurs dans le monde. L'ordre du jour final est simplement la version qui est allée à l'imprimante. Le Secrétariat affichera les modifications de l'ordre du jour sur le babillard près du bureau d'inscription de l'IETF (pas le bureau d'inscription de l'hôtel). Ces changements tardifs ne sont pas capricieux: ils sont effectués «juste à temps» lorsque les présidents de séance et les intervenants prennent conscience d’affrontements imprévus. L'IETF est trop dynamique pour que les programmes soient fixés des semaines à l'avance.

Une carte indiquant l'emplacement des salles figure également à l'ordre du jour. L'attribution des salles peut changer à mesure que l'agenda change. Certains groupes de travail se réunissent plusieurs fois au cours d'une réunion, et chaque tentative est faite pour qu'un groupe de travail se réunisse dans la même salle pour chaque session.

3.11 EDU à la rescousse

Si certains aspects de l'IETF vous mystifient encore (même après avoir fini de lire le Tao), vous voudrez vous inscrire à la formation sur place offerte par l'équipe de l'éducation (EDU). Ces cours informels sont conçus pour les nouveaux arrivants et les IETFers chevronnés. En plus de la formation des nouveaux arrivants, l'équipe EDU propose des tutoriels approfondis qui sont indispensables pour les nouveaux arrivants et les participants de longue date de l'IETF. Les sessions EDU ont généralement lieu le dimanche après-midi et sont également affichées à regarder plus tard.

Lors de l'inscription, il vous sera également proposé d'être lié à un mentor. Ceci est également organisé par l'équipe EDU; vous serez jumelé avec des bénévoles qui ont de l'expérience dans l'IETF et peuvent vous aider à démarrer rapidement. Idéalement, vous avez un appel avec votre mentor avant la réunion, une réunion au début de la réunion et vous vous enregistrez à un moment donné pendant la réunion, afin qu'il puisse vous aider avec toutes les questions que vous pourriez avoir.

Vous trouverez plus d'informations sur l'équipe EDU sur [11] .

3.12 Où dois-je m'intégrer?

L'IETF est différent pour différentes personnes. Il y a beaucoup de gens qui ont été très actifs dans l'IETF qui n'ont jamais assisté à une réunion de l'IETF. Vous ne devriez pas vous sentir obligé de venir à une réunion de l'IETF juste pour avoir une idée de l'IETF. Si vous décidez toutefois de venir, la RFC4144 fournit quelques conseils sur la façon de faire de votre réunion un succès [12] . Les lignes directrices suivantes (basées sur des stéréotypes de personnes dans diverses industries) pourraient vous aider à décider si vous voulez réellement venir et, dans l'affirmative, quelle pourrait être la meilleure utilisation de votre temps lors de votre première réunion.

3.12.1 Gestionnaires de systèmes d'information

Comme discuté tout au long de ce document, une réunion de l'IETF ne ressemble en rien à un salon professionnel auquel vous avez assisté. Les réunions de l'IETF sont des endroits singulièrement mauvais à visiter si votre intention est de découvrir ce qui sera chaud dans l'industrie Internet l'année prochaine. Vous pouvez supposer avec certitude que la participation aux réunions des groupes de travail vous rendra plus confuse qu'elle ne vous aidera à comprendre ce qui se passe ou se passera dans l'industrie.

Cela ne veut pas dire que personne de l'industrie ne devrait assister aux réunions de l'IETF. En tant que gestionnaire de SI, vous voudrez peut-être envisager d'envoyer des personnes spécifiques qui sont responsables des technologies en cours de développement dans l'IETF. Au fur et à mesure que ces personnes liront les brouillons Internet actuels et le trafic sur les listes de groupes de travail pertinentes, ils auront une idée de la pertinence de leur présence pour votre entreprise ou pour les groupes de travail.

3.12.2 Opérateurs de réseau et FAI

Faire fonctionner un réseau est déjà assez difficile sans avoir à se débattre avec de nouveaux protocoles ou de nouvelles versions des protocoles avec lesquels vous traitez déjà. Si vous travaillez pour le type de réseau qui utilise toujours le matériel et les logiciels les plus récents et que vous suivez les groupes de travail pertinents pendant votre temps libre copieux, vous pourriez certainement trouver utile de participer à l'IETF. Une bonne partie du travail de l'IETF couvre également de nombreuses autres parties des opérations des FAI et des grandes entreprises, et la contribution des opérateurs de chacun de ces types d'organisations est très précieuse pour maintenir ce travail dynamique et pertinent. Bon nombre des meilleurs documents d'exploitation de l'IETF proviennent d'opérateurs du monde réel, pas de fournisseurs et d'universitaires.

3.12.3 Mise en réseau des fournisseurs de matériel et de logiciels

L'image de l'IETF étant principalement des chercheurs du réseau peut avoir été vraie dans un passé lointain, mais les emplois des participants typiques sont maintenant dans l'industrie. Dans la plupart des domaines de l'IETF, les employés des fournisseurs sont ceux qui rédigent les protocoles et dirigent les groupes de travail, il est donc tout à fait approprié pour les fournisseurs d'y assister. Si vous créez du matériel ou des logiciels Internet et qu'aucun membre de votre entreprise n'a jamais assisté à une réunion de l'IETF, il vous appartient de venir à une réunion si pour aucune autre raison que de dire aux autres dans quelle mesure la réunion était ou n'était pas pertinente pour votre entreprise .

Cela ne veut pas dire que les entreprises devraient fermer boutique pendant les semaines de réunion de l'IETF afin que tout le monde puisse aller à la réunion. Les gens du marketing, même les gens du marketing technique, sont généralement en sécurité en restant loin de l'IETF tant que certains des techniciens de l'entreprise sont à la réunion. De même, il n'est pas nécessaire, ou probablement utile, que tous les membres d'un service technique se rendent, en particulier s'ils ne lisent pas tous les brouillons Internet et ne suivent pas les listes de diffusion du groupe de travail. De nombreuses entreprises ne comptent que quelques participants aux réunions désignés, choisis pour leur capacité à rédiger des rapports de voyage complets et utiles. De plus, de nombreuses entreprises ont des efforts de coordination interne et une stratégie de normalisation. Si une entreprise dépend d'Internet pour tout ou partie de ses activités, la stratégie devrait probablement couvrir l'IETF. Les participants participent à l'IETF en tant qu'individus.

3.12.4 Universitaires

Les réunions de l'IETF sont souvent d'excellents endroits pour que les informaticiens découvrent ce qui se passe sur le chemin des protocoles qui seront bientôt déployés. Les professeurs et les étudiants diplômés (et parfois dépassant le premier cycle) qui effectuent des recherches en réseautage ou en communication peuvent obtenir une mine d'informations en suivant les groupes de travail dans leurs domaines d'intérêt spécifiques. Se promener dans différentes réunions de groupes de travail peut avoir le même effet que d'aller à des colloques et des séminaires dans votre département. Bien entendu, les chercheurs sont également susceptibles d'être intéressés par les activités de l'IRTF.

3.12.5 Computer Trade Press

Si vous êtes membre de la presse et envisagez de participer à l'IETF, nous avons préparé une section spéciale du Tao rien que pour vous - veuillez consulter la section 8.2.

3.13 Actes

Les actes de l'IETF sont compilés dans les deux mois suivant chaque réunion et sont disponibles sur le web. Soyez sûr de regarder à travers une copie - les procédures sont remplies d'informations sur l'IETF que vous ne trouverez probablement nulle part ailleurs. Par exemple, vous trouverez des instantanés de la plupart des chartes des groupes de travail au moment de la réunion, vous permettant de mieux comprendre l'évolution d'un effort donné.

Une liste des participants est également incluse, qui contient les noms et affiliations comme indiqué sur le formulaire d'inscription. Pour plus d'informations sur l'obtention de copies de la procédure, consultez la liste Web à l' adresse https://www.ietf.org/how/meetings/proceedings . Les actes de l'IETF sont compilés dans les deux mois suivant chaque réunion et sont disponibles sur le web. Soyez sûr de regarder à travers une copie - les procédures sont remplies d'informations sur l'IETF que vous ne trouverez probablement nulle part ailleurs. Par exemple, vous trouverez des instantanés de la plupart des chartes des groupes de travail au moment de la réunion, vous permettant de mieux comprendre l'évolution d'un effort donné.

La procédure débute parfois par un message informatif (et très divertissant). Chaque volume contient l'agenda final (rétrospectivement), un aperçu de l'IETF, des rapports de zone et de groupe de travail, et des diapositives du protocole et des présentations techniques. Les rapports et présentations des groupes de travail sont parfois incomplets, si les documents n'ont pas été remis au Secrétariat à temps pour publication.

3.14 Autres choses générales

Les IETFers en général sont très abordables. N'ayez jamais peur d'approcher quelqu'un et de vous présenter. N'ayez pas peur de poser des questions, surtout en ce qui concerne le jargon et les acronymes.

Les conversations dans les couloirs sont très importantes. Beaucoup de très bon travail est fait par des gens qui parlent ensemble entre les réunions et au cours des déjeuners et dîners. Chaque minute de l'IETF peut être considérée comme du temps de travail (à la grande consternation de certaines personnes).

Une réunion parallèle (historiquement mais souvent à tort appelée "bar BOF") est une réunion officieuse entre les réunions du GT ou en fin de soirée, au cours de laquelle beaucoup de travail est effectué. Ces réunions parallèles se produisent dans de nombreux endroits différents autour d'une réunion de l'IETF, tels que des restaurants, des cafés, des espaces de salle inutilisés et (si nous sommes si chanceux) des piscines. Vous pouvez en savoir plus sur les BOF (sessions Birds-of-a Feather) dans la section 5.

Il n'est pas judicieux de se mettre entre un IETFer affamé (et il n'y en a pas d'autre) et des brownies et des biscuits pour la pause-café, peu importe à quel point la conversation dans le couloir est intéressante. Steve Coya, le premier directeur exécutif de l'IETF, a souvent dit: "Prenez votre cookie, puis éloignez-vous de la table."

Les IETFers sont farouchement indépendants. Il est sûr de remettre en question les opinions et d'offrir des alternatives, mais ne vous attendez pas à ce qu'un IETFer suive les commandes.

Les réunions de l'IETF, et la session plénière en particulier, ne sont pas des endroits où les vendeurs peuvent essayer de vendre leurs marchandises. Les gens peuvent certainement répondre aux questions sur leur entreprise et ses produits, mais gardez à l'esprit que l'IETF n'est pas un salon professionnel. Cela n'empêche pas les gens de récupérer les coûts des T-shirts, boutons et protecteurs de poche liés à l'IETF.

Il y a toujours une «table de distribution des matériaux» près du bureau d'inscription. Ce bureau est utilisé pour mettre les informations appropriées à la disposition des participants (par exemple, des copies de quelque chose discuté lors d'une session du groupe de travail, des descriptions des informations en ligne liées à l'IETF). Veuillez vérifier auprès du Secrétariat avant de placer des documents sur le bureau; le Secrétariat a le droit de retirer tout matériel qu'il juge inapproprié.

Si vous comptez sur votre ordinateur portable pendant la réunion, c'est une bonne idée d'apporter une batterie supplémentaire. Il n'est pas toujours facile de trouver une prise de secours dans certaines salles de réunion, et l'utilisation de l'accès sans fil peut décharger votre batterie plus rapidement que vous ne le pensez. Si vous êtes assis près d'une multiprise dans une salle de réunion, attendez-vous à ce qu'il soit branché et débranché pour les autres autour de vous. Beaucoup de gens apportent une rallonge avec des prises de rechange, ce qui est un bon moyen de se faire des amis avec votre voisin lors d'une réunion. Si vous avez besoin d'un adaptateur de prise, vous devriez essayer de l'acheter à l'avance car celui dont vous avez besoin est généralement plus facile à trouver dans votre pays d'origine.

3.15 Participation à distance

Les gens ont rejoint les réunions de l'IETF à distance depuis longtemps, mais les outils pour cela ont beaucoup changé au fil des ans. Actuellement, toutes les réunions des groupes de travail et de recherche ainsi que les plénières sont retransmises en direct et ouvertes à une participation à distance. Pour participer à distance, vous devez vous inscrire en tant que participant à distance [13] , il n'y a pas de frais pour cela, mais l'inscription est requise pour des raisons administratives. Vous pouvez également utiliser des flux audio ainsi que Jabber (ce qui est expliqué ci-dessous). Les liens pour les salles Meetecho, les flux audio et les salles Jabber se trouvent toujours dans l'agenda de la réunion. Plus d'informations peuvent être trouvées ici: [14] . Toutes les sessions sont enregistrées, la vidéo, l'audio, les journaux de discussion et les notes sont accessibles après la réunion.

4. Groupes de travail

La grande majorité du travail de l'IETF est effectuée dans de nombreux groupes de travail; au moment d'écrire ces lignes, il existe environ 115 groupes de travail différents. Le BCP 25, «Lignes directrices et procédures du groupe de travail de l'IETF», est une excellente ressource pour toute personne participant aux discussions du GT.

Un GT est vraiment juste une liste de diffusion avec un peu de supervision et de facilitation. Vous "rejoignez" le GT en vous inscrivant à la liste de diffusion; toutes les listes de diffusion sont ouvertes à tous. Tout le monde peut publier sur une liste de diffusion du GT, bien que la plupart des listes exigent que les non-abonnés voient leurs publications modérées. Chaque groupe de travail a un ou deux (ou, rarement, trois) présidents.

Plus important encore, chaque GT a une charte que le GT est censé suivre. La charte énonce la portée des discussions du groupe de travail, ainsi que ses objectifs. La liste de diffusion du GT et les réunions en face-à-face sont censées se concentrer uniquement sur ce qui est dans la charte et ne pas s'égarer sur d'autres sujets "intéressants". Bien sûr, regarder un peu en dehors du cadre du GT est parfois utile, mais la grande majorité de la discussion devrait porter sur les sujets énumérés dans la charte. En fait, certaines chartes du GT précisent en fait ce que le GT ne fera pas, en particulier s'il y a eu des sujets attrayants mais nébuleux lors de la rédaction de la charte. La liste de toutes les chartes du GT rend la lecture intéressante pour les gens qui veulent savoir ce que les différents groupes de travail sont censés faire.

4.1 Présidents des groupes de travail

Le rôle des présidents des GT est décrit dans les BCP 11 et BCP 25.

En tant que gardiens de chats bénévoles, le premier travail d'un président est de déterminer les objectifs et les étapes du consensus du GT, en gardant la charte à jour. Ensuite, souvent avec l'aide des secrétaires des GT ou des éditeurs de documents, le président doit gérer les discussions du GT, à la fois sur la liste et en planifiant des réunions le cas échéant. Parfois, les discussions sont bloquées sur des points litigieux et le président peut avoir besoin d'orienter les gens vers une interaction productive, puis de déclarer quand un consensus approximatif a été atteint et que la discussion est terminée. Parfois, les présidents gèrent également les interactions avec les non-participants au GT ou l'IESG, en particulier lorsqu'un document du GT approche de la publication. Les présidents sont responsables de la qualité technique et non technique des résultats des GT. Comme vous pouvez l'imaginer compte tenu de la combinaison de demandes de secrétariat, de relations interpersonnelles et techniques, certains présidents de groupe de travail sont bien meilleurs dans leur travail que d'autres.

Il est conseillé aux présidents des GT de participer au déjeuner des présidents des GT en milieu de semaine pendant la réunion où les sujets spécifiques aux présidents sont présentés et discutés. Les diapositives des versions précédentes de cette session se trouvent dans le datatracker.

4.2 Faire avancer les choses dans un groupe de travail

Un fait qui déroute de nombreux nouveaux arrivants est que les réunions en face à face du GT sont beaucoup moins importantes dans l'IETF que dans la plupart des autres organisations. Toute décision prise lors d'une réunion en face à face doit également obtenir un consensus sur la liste de diffusion du GT. Il existe de nombreux exemples de décisions importantes prises lors des réunions du GT qui sont par la suite annulées sur la liste de diffusion, souvent parce qu'une personne qui n'a pas pu assister à la réunion a signalé un grave défaut dans la logique utilisée pour prendre la décision. Enfin, les réunions du GT ne sont pas des «séances de rédaction», comme c'est le cas dans certains autres organismes de normalisation: dans l'IETF, la rédaction se fait ailleurs.

Un autre aspect des groupes de travail qui déconcerte de nombreuses personnes est le fait qu'il n'y a pas de vote formel. La règle générale sur les sujets controversés est que le groupe de travail doit parvenir à un "consensus approximatif", ce qui signifie qu'une très grande majorité de ceux qui se soucient doivent être d'accord. La méthode exacte de détermination d'un consensus approximatif varie d'un groupe de travail à l'autre. Parfois, le consensus est déterminé en "fredonnant" - si vous êtes d'accord avec une proposition, vous fredonnez lorsque vous y êtes invité par le président. La plupart des questions "fredonnées" se divisent en deux parties: vous fredonnez à la première partie si vous êtes d'accord avec la proposition, ou vous fredonnez à la deuxième partie si vous n'êtes pas d'accord avec la proposition. Les nouveaux arrivants trouvent cela assez particulier, mais cela fonctionne. Il appartient au président de décider quand le groupe de travail est parvenu à un consensus approximatif.

L'absence de vote formel a entraîné des retards très longs pour certaines propositions, mais la plupart des participants à l'IETF qui ont été témoins d'un consensus approximatif après des débats acrimonieux estiment que les retards entraînent souvent de meilleurs protocoles. (Et, si vous y réfléchissez, comment pourriez-vous «voter» dans un groupe qui invite toutes les personnes intéressées à participer, et quand il est impossible de compter les participants?) Un consensus approximatif a été défini de plusieurs façons; une version simple est que cela signifie que les objections fermement tenues doivent être débattues jusqu'à ce que la plupart des gens soient convaincus que ces objections sont fausses.

Un problème connexe est que certaines personnes pensent que leurs propositions devraient être discutées au sein du GT même lorsque les présidents des GT ne le font pas. Par exemple, si le travail proposé ne fait pas vraiment partie de la charte, les présidents des GT peuvent restreindre la discussion de la proposition afin de garder le GT concentré sur le travail affrété. Les personnes qui pensent qu'un GT devrait aborder un sujet considéré comme hors charte par les présidents des GT peuvent faire part de leurs préoccupations au DA responsable; l'AD peut accepter d'ajuster la charte pour ajouter le sujet avec le groupe de travail, ou qu'il est déjà couvert dans la charte, ou que les présidents des GT sont corrects et que le participant devrait travailler sur la proposition en dehors du GT.

Lorsqu'un document du GT a été entièrement discuté, il passe généralement par le dernier appel du groupe de travail (souvent abrégé en "WGLC"). C'est, espérons-le, la dernière fois que le GT règle les problèmes. Parfois, le WGLC soulèvera tellement de problèmes qu'il y aura un deuxième WGLC après que les révisions auront été incorporées. Il n'y a pas de règles formelles sur la façon dont un WGLC se produit, ou même si un WGLC est nécessaire: c'est aux présidents du WG.

Une autre méthode adoptée par certains groupes de travail consiste à avoir un "secrétaire" de groupe de travail pour gérer le jonglage des documents et les modifications. Le secrétaire peut exécuter le suivi des problèmes s'il en existe un, ou peut simplement être chargé de veiller à ce que toutes les décisions prises sur la liste de diffusion soient reflétées dans les nouvelles versions des documents.

Lorsqu'un GT a rempli sa charte, il est censé cesser ses activités. (La plupart des listes de diffusion du groupe de travail continuent après la fermeture d'un groupe de travail, discutant toujours des mêmes sujets que le groupe de travail.) Dans l'IETF, c'est une marque de succès que le groupe de travail ferme parce qu'il a rempli sa charte. C'est l'un des aspects de l'IETF que les nouveaux arrivants qui ont de l'expérience avec d'autres organismes de normalisation ont du mal à comprendre. Cependant, certains présidents de GT n'arrivent jamais à terminer leur GT, ou continuent d'ajouter de nouvelles tâches à la charte de sorte que le groupe de travail s'éternise pendant de nombreuses années (ou, dans certains cas, des décennies). La production de ces GT vieillissants n'est souvent pas aussi utile que les produits précédents, et les résultats désordonnés sont parfois attribués à ce que l'on appelle le "syndrome dégénératif du groupe de travail".

4.3 Documents du groupe de travail

Il existe une distinction officielle entre les projets du GT et les projets individuels, mais dans la pratique, il n'y a parfois pas beaucoup de différence de procédure. Par exemple, de nombreuses listes de diffusion du GT discutent également de projets individuels (à la discrétion du président du GT). Les présidents des groupes de travail prennent les décisions concernant les projets qui deviendront des projets du groupe de travail et qui seront les auteurs ou les éditeurs de ces projets, généralement sur la base de consultations avec le groupe de travail, et parfois avec leur directeur régional. Ce processus peut être délicat dans les cas où de nombreuses personnes veulent être un rédacteur, mais peut être tout aussi délicat lorsque personne ne veut être rédacteur mais que le GT est conçu pour effectuer un travail spécifique. Les procédures pour les brouillons Internet sont traitées plus en détail plus loin dans ce document.

Certains groupes de travail ont des documents complexes ou un ensemble complexe de documents (ou même les deux). Éliminer tous les bogues d'un ou plusieurs documents complexes est une tâche intimidante. Afin d'aider à résoudre ce problème, certains groupes de travail utilisent des «suiveurs de problèmes», qui sont des listes en ligne des problèmes ouverts avec les documents, l'état du problème, les correctifs proposés, etc. L'utilisation d'un outil de suivi des problèmes permet non seulement au GT de ne pas oublier de faire quelque chose d'important, mais aussi lorsque quelqu'un pose une question plus tard sur les raisons pour lesquelles quelque chose a été fait d'une manière particulière.

Pour les documents des groupes de travail, l'éditeur de documents sert au gré du président du GT. Il existe souvent plus d'un éditeur pour les documents du groupe de travail, en particulier pour les documents complexes. L'éditeur de document est chargé de s'assurer que le contenu du document reflète fidèlement les décisions du groupe de travail, en particulier lors de la création d'un nouveau protocole ou d'une nouvelle extension; Lorsqu'un éditeur de documents ne suit pas le consensus du GT, les présidents des GT seront plus énergiques pour obtenir des changements qui correspondent au consensus ou remplaceront l'éditeur de documents par une personne plus sensible au GT. Alors qu'un document du groupe de travail progresse, les participants suggèrent des changements sur la liste de diffusion du groupe de travail; les rédacteurs devraient suivre la discussion et apporter des modifications en cas d'accord.

Si un participant apporte des contributions importantes, l'éditeur ou le président du document peut inviter le participant à devenir co-auteur ou co-éditeur, bien qu'un tel ajout doive être approuvé par les présidents des GT. Parfois, un groupe de travail examinera plusieurs alternatives avant de sélectionner un projet Internet particulier comme document de groupe de travail. Un groupe de travail prendra souvent des idées de plusieurs des alternatives pour créer un seul document de groupe de travail; dans un tel cas, le président détermine qui sera inscrit comme auteur sur la page de titre et qui sera reconnu comme contributeur dans le corps du document.

Lorsqu'un document du GT est prêt à progresser au-delà du GT, les présidents des GT désigneront un "berger" pour prendre en charge le processus final. Le rôle du berger de document est décrit dans la RFC 4858 .

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

La chose la plus importante que tout le monde (nouveaux arrivants et experts chevronnés) devrait faire avant de venir à une réunion en face-à-face est de lire les brouillons Internet et les RFC à l'avance. Les réunions des GT ne sont explicitement pas destinées à l'éducation: elles visent à développer les documents du groupe. Même si vous n'avez pas l'intention de dire quoi que ce soit au cours de la réunion, vous devez lire, ou du moins parcourir les documents du groupe avant de participer afin de comprendre ce qui se dit.

C'est aux présidents des GT de fixer l'ordre du jour de la réunion, généralement quelques semaines à l'avance. Si vous voulez que quelque chose soit discuté lors de la réunion, assurez-vous d'en informer le président. Les ordres du jour de toutes les réunions du GT sont disponibles à l'avance sur le site Web de l'IETF, mais certains présidents de GT sont laxistes (sinon totalement négligents) à propos de leur remise.

Le Secrétariat ne planifie les réunions du GT que quelques semaines à l'avance, et le calendrier change souvent aussi peu qu'une semaine avant le premier jour. Si vous venez seulement pour une réunion du GT, vous pouvez avoir du mal à réserver votre vol avec si peu de préavis, en particulier si la réunion du groupe de travail change d'horaire. Assurez-vous de suivre l'agenda actuel afin de pouvoir planifier des vols et des hôtels. Mais, en fin de compte, vous ne devriez probablement pas venir pour une seule réunion du GT. Il est probable que vos connaissances puissent être utiles dans quelques groupes de travail, en supposant que vous avez lu les ébauches et les RFC pour ces groupes. Le travail dans l'IETF est souvent réciproque, contribue positivement au travail des autres et vous êtes plus susceptible de recevoir des commentaires et des retours sur votre travail.

Si vous êtes à l'ordre du jour d'une réunion en personne, vous devriez probablement venir avec quelques diapositives préparées. Mais ne venez pas avec un tutoriel; les gens sont censés lire les ébauches à l'avance. Des projecteurs pour présentations sur ordinateur portable sont disponibles dans toutes les salles de réunion.

Et voici une astuce pour vos diapositives en GT ou en présentations plénières: ne mettez pas le logo de votre entreprise sur chacun, même si c'est une pratique courante en dehors de l'IETF. L'IETF fronce les sourcils sur ce type de publicité d'entreprise (à l'exception du sponsor de la réunion dans la présentation plénière), et la plupart des présentateurs ne mettent même pas leur logo sur leur diapositive d'ouverture. L'IETF concerne le contenu technique, pas le boosterisme des entreprises. Les diapositives sont souvent en noir et blanc uni pour plus de lisibilité, avec une couleur utilisée uniquement lorsqu'elle ajoute vraiment de la clarté. Encore une fois, le contenu est la partie la plus importante des diapositives, pas la façon dont il est présenté.

Une chose que vous pourriez trouver utile, et peut-être même divertissante, pendant les sessions du groupe de travail est de suivre le commentaire en cours sur la salle Jabber associée à ce groupe de travail. Le commentaire en cours est souvent utilisé comme base pour le procès-verbal de la réunion, mais il peut également inclure des blagues, des soupirs et d'autres bavardages superflus. Jabber est une technologie XML en streaming gratuite principalement utilisée pour la messagerie instantanée. Vous pouvez trouver des pointeurs vers les clients Jabber pour de nombreuses plates-formes à [15] . Les salons de discussion Jabber portent le nom du groupe de travail suivi de "@ jabber.ietf.org". Ces salles sont, en fait, disponibles toute l'année, pas seulement pendant les réunions de l'IETF, et certaines sont utilisées par les participants actifs du groupe de travail pendant l'élaboration du protocole.

4.5 Listes de diffusion du groupe de travail

Comme nous l'avons mentionné précédemment, les listes de diffusion d'annonces et de discussions de l'IETF sont les listes de diffusion centrales pour les activités de l'IETF. Cependant, il existe de nombreuses autres listes de diffusion liées au travail de l'IETF. Par exemple, chaque groupe de travail a sa propre liste de discussion. En outre, certains débats techniques à long terme ont été déplacés de la liste de l'IETF vers des listes créées spécifiquement pour ces sujets. Il est fortement recommandé de suivre les discussions sur les listes de diffusion des groupes de travail auxquels vous souhaitez participer. Plus il y a de travail sur les listes de diffusion, moins il y aura de travail à faire lors de la réunion, ce qui laisse du temps pour la pollinisation croisée (c.-à-d. Assister à des groupes de travail en dehors de son domaine d'intérêt principal afin d'élargir sa perspective).

Les listes de diffusion fournissent également un forum pour ceux qui souhaitent suivre ou contribuer aux efforts des groupes de travail, mais ne peuvent pas assister aux réunions de l'IETF. C'est pourquoi les procédures de l'IETF exigent que toutes les décisions soient confirmées "sur la liste" et vous entendrez souvent un président du GT dire "Prenons-le sur la liste" pour clore une discussion.

De nombreuses listes de discussion de l'IETF utilisent Mailman ou un autre gestionnaire de listes, Majordomo. Ils ont généralement une adresse "demande" qui gère les détails administratifs de l'adhésion et de la sortie de la liste. (Voir la section 2.3 pour plus d'informations sur mailman.) Il est généralement mal vu quand un tel administrateur apparaît sur la liste de diffusion de discussion.

Les listes de discussion de l'IETF sont archivées. Autrement dit, tous les messages envoyés à la liste sont automatiquement stockés et rendus accessibles. Beaucoup de ces archives sont répertoriées en ligne. Si vous ne trouvez pas la liste que vous recherchez, envoyez un message à l'adresse "-demande" de la liste (pas à la liste elle-même!). Les listes de chartes du groupe de travail sont une source utile. Il existe une liste d'anciens GT conclus.

Certaines listes de groupes de travail appliquent des limites de taille aux messages, en particulier pour éviter que des documents ou des présentations volumineux arrivent dans la boîte aux lettres de chacun. Il convient de se rappeler que bien que la plupart des participants n'en aient pas, tous n'ont pas de connexions à large bande (ceux qui se trouvent dans des endroits éloignés peuvent toujours compter sur une bande passante plus faible, une connexion plus lente lorsque Internet leur est disponible), donc les messages plus courts sont grandement appréciés. Les documents peuvent être publiés sous forme de brouillons Internet; le matériel de présentation peut être affiché sur un site Web contrôlé par l'expéditeur ou envoyé personnellement aux personnes qui le demandent. Certains groupes de travail ont mis en place des sites spéciaux pour stocker ces gros documents afin que les expéditeurs puissent y publier d'abord, puis simplement envoyer à la liste l'URL du document.

4.6 Réunions du groupe de travail intérimaire

Les groupes de travail tiennent parfois des réunions intérimaires entre les IETF. Les réunions intérimaires ne remplacent cependant pas les réunions de l'IETF - un groupe ne peut pas décider de sauter une réunion dans un endroit qu'il n'aime pas et de se réunir à Cancun (ou même dans un endroit banal) trois semaines plus tard, par exemple. Les réunions intérimaires doivent être approuvées par le CN et doivent être annoncées au moins un mois à l'avance. L'emplacement et le calendrier doivent permettre un accès équitable à tous les participants. Comme pour les réunions régulières de l'IETF, quelqu'un doit prendre des notes et le groupe doit prendre part. Les décisions provisoirement prises lors d'une réunion intérimaire du GT doivent encore être ratifiées sur la liste de diffusion.

Certains groupes de travail organisent des «réunions intérimaires virtuelles» qui ont lieu via les outils collaboratifs en ligne ou par téléphone au lieu de face à face. Les réunions intermédiaires virtuelles peuvent être utiles pour amener les groupes de travail à prêter attention à leur travail entre les réunions en face à face régulières de l'IETF, accélérer le travail et avoir un coût de participation beaucoup plus faible que les réunions intermédiaires en face à face. Les réunions virtuelles intermédiaires ont les mêmes exigences de rapport que les réunions virtuelles en face à face.

L'IESG a des règles pour la notification à l'avance de l'heure et du lieu des réunions de groupe de travail intérimaires, ainsi que pour rendre compte des résultats des réunions. Le but de ces règles est de rendre les réunions intérimaires accessibles au plus grand nombre possible de membres du Groupe de travail et de maintenir la transparence du processus du Groupe de travail.

5. BOFs

Pour former un groupe de travail, vous avez besoin d'une charte et d'une personne capable de présider. Pour obtenir ces choses, vous devez intéresser les gens afin qu'ils puissent aider à concentrer la charte et convaincre un directeur régional que le projet en vaut la peine. Une réunion en face à face est utile pour cela. En fait, très peu de groupes de travail sont lancés par un directeur régional; la plupart commencent après un BOF en face-à-face car les participants ont manifesté leur intérêt pour le sujet.

Une réunion Birds of a Feather (BOF) doit être approuvée par le directeur régional de la zone concernée avant de pouvoir être programmée. Si vous pensez que vous avez vraiment besoin d'un nouveau groupe de travail, contactez un AD de manière informelle avec votre proposition et voyez ce qu'il en pense. L'étape suivante consiste à demander un créneau de réunion lors de la prochaine réunion en personne. Bien sûr, vous n'avez pas besoin d'attendre cette réunion pour faire un travail, comme la mise en place d'une liste de diffusion et commencer à discuter d'une charte.

Les réunions du BOF ont un ton très différent de celui des réunions du GT. Le but d'un BOF est de s'assurer qu'une bonne charte avec de bons jalons peut être créée et qu'il y a suffisamment de personnes prêtes à faire le travail nécessaire pour créer des normes. Certains BOF ont déjà des projets Internet en cours, tandis que d'autres partent de zéro.

Un avantage d'avoir un projet avant le BOF est d'aider à concentrer la discussion. D'un autre côté, avoir un projet pourrait avoir tendance à limiter ce que les autres membres de la BOF veulent faire dans la charte. Il est important de se rappeler que la plupart des BOF sont organisés afin d'obtenir un soutien pour un éventuel groupe de travail, et non pour obtenir un soutien pour un document particulier.

De nombreux BOF ne se transforment pas en GT pour diverses raisons. Un problème commun est que trop peu de personnes peuvent se mettre d'accord sur un objectif pour le travail. Une autre raison typique est que le travail ne deviendrait pas une norme - si, par exemple, les auteurs de documents ne veulent pas vraiment abandonner le contrôle des modifications à un groupe de travail. (Nous discuterons du contrôle des modifications plus loin dans ce document.) Seules deux réunions d'un BOF peuvent être programmées sur un sujet particulier; soit un groupe de travail doit se former, soit le sujet doit être supprimé.

6. RFC et Internet-Brouillons

Cette section traite des brouillons Internet et des RFC dans le flux IETF, c'est-à-dire qu'elle décrit comment les documents sont produits et avancés au sein de l'IETF. Pour une brève note sur les autres flux RFC, voir la section 2.2.5.

Si vous êtes un nouveau participant à l'IETF et que vous recherchez un RFC ou un brouillon Internet particulier, accédez à l'IETF Datatracker. Ce site dispose de nombreuses capacités de recherche et peut vous aider à trouver le bon document et les informations sur son état, ses dépendances, ses mises à jour potentielles et d'autres informations. Un autre point d'entrée pour la recherche et la navigation dans les RFC est EveryRFC de Mark Nottingham.

6.1 Obtenir un RFC publié

L'une des questions les plus courantes que les IETFers chevronnés entendent de la part des nouveaux arrivants est: "Comment puis-je faire publier une norme IETF?" Une bien meilleure question est: "Dois-je écrire une norme IETF?" car la réponse n'est pas toujours «oui». Si vous décidez d'essayer d'écrire un document qui devient une norme IETF, sachez que le processus global peut être ardu, même si les étapes individuelles sont assez simples. Beaucoup de gens traversent le processus indemne, cependant, et il y a beaucoup de conseils écrits qui aident les auteurs à émerger avec leur ego plus ou moins intact.

L'une des premières choses que vous devez décider est de savoir si vous voulez que votre document soit examiné dans un groupe de travail, ou si vous voulez qu'il soit considéré comme une soumission individuelle (c'est-à-dire non-WG) à l'IETF. Même si la plupart des normes de l'IETF proviennent de groupes de travail, certains sont des efforts individuels: il pourrait ne pas y avoir de groupe de travail approprié, ou un groupe de travail potentiellement approprié pourrait être occupé à d'autres travaux pour examiner votre idée.

Chaque norme IETF est publiée en tant que RFC ("Request for Comments"), et chaque RFC commence comme un Internet-Draft (souvent appelé "ID" ou simplement "draft"). Les étapes de base pour obtenir quelque chose publié en tant que norme IETF sont les suivantes:

  • Publiez le document en tant que brouillon Internet.
  • Recevez des commentaires sur le projet.
  • Modifiez votre brouillon en fonction des commentaires.
  • Répétez les étapes 1 à 3 plusieurs fois.
  • Demandez à un directeur régional de présenter le projet à l'IESG (s'il s'agit d'une soumission individuelle). Si le projet est un produit officiel du groupe de travail, le président du GT demande à la DA de le porter à l'IESG.
  • Si le directeur régional accepte la soumission, il procédera à son propre examen initial et demandera peut-être des mises à jour avant de l'avancer.
  • Obtenez des avis des membres plus larges de l'IETF. En particulier, certains des domaines de l'IETF ont formé des équipes d'examen pour examiner les projets qui sont prêts à être soumis à l'IESG.
  • Discutez des préoccupations avec les membres de l'IESG. Leurs préoccupations peuvent être résolues par une réponse simple, ou ils peuvent nécessiter des ajouts ou des modifications au document.
  • Attendez que le document soit publié par l'éditeur RFC.

Une explication beaucoup plus complète de ces étapes est contenue dans le BCP 9, "The Internet Standards Process". Ceux qui rédigent des brouillons qu'ils espèrent devenir des normes IETF doivent lire le BCP 9 afin de pouvoir suivre le chemin de leur document tout au long du processus. Vous pouvez suivre la progression sur l'IETF Datatracker. BCP 9 (et divers autres documents qui le mettent à jour) aborde en détail un sujet qui est très souvent mal compris, même par les participants chevronnés de l'IETF: différents types de RFC passent par différents processus et ont des classements différents. Il existe six types de RFC:

  • Normes proposées
  • Normes Internet (parfois appelées «normes complètes»)
  • Documents sur les meilleures pratiques actuelles (PCA)
  • Documents d'information
  • Documents expérimentaux
  • Documents historiques

Seuls les deux premiers, proposés et complets, sont des normes au sein de l'IETF. Un bon résumé de ceci peut être trouvé dans le bien intitulé RFC 1796 , "Pas tous les RFC sont des normes".

Il existe également deux sous-séries de RFC, appelées BCP et STD. Les documents sur les meilleures pratiques actuelles décrivent l'application de diverses technologies sur Internet et sont également couramment utilisés pour documenter les nombreuses parties du processus de l'IETF. Les sous-séries de FYI sont composées de "documents d'information" au sens de l'énumération ci-dessus, avec un marquage spécial appliqué. (Il y avait aussi une sous-série RFC "Pour votre information" qui a été créée pour documenter des aperçus et des sujets qui sont introductifs ou qui plaisent à un large public; cependant, cette série a été officiellement clôturée.)

La sous-série STD RFC a été créée pour identifier les RFC qui spécifient en fait les normes Internet. Certaines MST sont en fait des ensembles de plusieurs RFC, et la désignation "standard" s'applique à l'ensemble des documents.

6.2 Lâcher prise avec grâce

La plus grande raison pour laquelle certaines personnes ne veulent pas que leurs documents soient mis sur la voie des normes IETF est qu'elles doivent abandonner le contrôle des modifications du protocole. Autrement dit, dès que vous proposez que votre protocole devienne une norme IETF, vous devez entièrement abandonner le contrôle du protocole. S'il y a accord général, des parties du protocole peuvent être complètement modifiées, des sections entières peuvent être arrachées, de nouvelles choses peuvent être ajoutées et le nom peut être changé.

Certains auteurs trouvent qu'il est très difficile de renoncer au contrôle de leur protocole pour animaux de compagnie. Si vous êtes une de ces personnes, la poursuite d'une norme IETF peut ne pas être une voie fructueuse. D'un autre côté, si votre objectif est le meilleur standard possible avec l'implémentation la plus large, alors vous pourriez trouver le processus IETF à votre goût.

Par ailleurs, le contrôle des modifications sur les normes Internet ne se termine pas lorsque le protocole est mis sur la voie des normes. Le protocole lui-même peut être modifié ultérieurement pour un certain nombre de raisons, la plus courante étant que les implémenteurs découvrent un problème lorsqu'ils implémentent la norme. Ces modifications ultérieures sont également sous le contrôle de l'IETF, et non des éditeurs du document de normes.

Les normes IETF existent pour que les gens les utilisent pour écrire des programmes Internet qui interagissent. Ils n'existent pas pour documenter les idées (peut-être merveilleuses) de leurs auteurs, pas plus qu'ils n'existent pour qu'une entreprise puisse dire: «Nous avons une norme IETF». Si un RFC de voie normalisée n'a qu'une seule implémentation (alors qu'il en faut deux pour avancer sur la voie normative), c'était probablement une erreur de le mettre sur la voie normative en premier lieu.

Notez que les nouveaux auteurs ne peuvent pas prendre le document de quelqu'un d'autre et le faire passer pour le leur; voir BCP 78, section 5.6, point a).

6.3 Internet-Drafts

Tout d'abord. Chaque document qui se retrouve dans le référentiel RFC commence sa vie en tant que brouillon Internet. Les brouillons Internet sont des documents provisoires - ils sont destinés aux lecteurs de commenter, afin que les auteurs puissent réfléchir à ces commentaires et décider lesquels incorporer dans le projet. Afin de rappeler aux gens leur caractère provisoire, les brouillons Internet sont automatiquement supprimés des répertoires en ligne actifs après six mois. Ce ne sont certainement pas des normes. Comme le dit BCP 9:

"Un projet Internet n'est PAS un moyen de" publier "une spécification; les spécifications sont publiées par le biais du mécanisme RFC. Les projets Internet n'ont pas de statut officiel et peuvent être modifiés ou supprimés à tout moment. En aucun cas, un projet Internet doit être référencé par un document, un rapport ou une demande de proposition, et un fournisseur ne doit pas non plus prétendre être conforme à un projet Internet ".

Lorsque vous soumettez un projet Internet, vous accordez certains droits de publication à l'IETF. C'est ainsi que votre Internet-Draft est librement accessible à tous ceux qui veulent le lire et le commenter. Les droits que vous accordez et ne donnez pas à l'IETF sont décrits dans le BCP 78, "Droits de l'IETF sur les contributions".

Il existe un outil de vérification très utile à [16] . L'utilisation de cet outil avant de remettre un brouillon Internet aidera à empêcher le brouillon d'être rejeté en raison d'erreurs de forme et de formatage.

Un ID doit avoir approximativement le même format qu'un RFC. Contrairement à la croyance de beaucoup de gens, un ID n'a pas besoin de ressembler exactement à un RFC, mais si vous pouvez utiliser les mêmes procédures de formatage que celles utilisées par l'éditeur RFC lorsque vous créez vos I-D, cela simplifiera le travail de l'éditeur RFC lorsque votre brouillon est publié en tant que RFC. La RFC 2223 , «Instructions aux auteurs RFC», décrit le format de soumission. Il existe également un outil appelé xml2rfc, qui prend le texte au format XML et le transforme en un brouillon Internet valide, vous pouvez également utiliser un outil appelé kramdown, qui prend le texte au format markdown et le transforme en un brouillon Internet valide.

Un projet Internet peut être un projet de groupe de travail ou une soumission individuelle. Les ébauches des groupes de travail sont généralement examinées par le groupe de travail avant d'être acceptées en tant que point du GT, bien que les présidents aient le dernier mot.

Si vous souhaitez vérifier l'état d'un brouillon particulier, ou ne vous souvenez pas de son nom exact, ou si vous souhaitez savoir sur quels brouillons un groupe de travail travaille, deux outils pratiques sont disponibles. L '"interface de base de données Internet-Drafts", sur https://datatracker.ietf.org/doc , vous permet de rechercher un brouillon par auteur, groupe de travail, date ou nom de fichier. Cela est particulièrement utile pour les auteurs qui souhaitent suivre l'avancement de leur projet au fur et à mesure qu'il progresse dans le processus de publication.

Il existe des règles informelles pour la dénomination Internet-Draft qui ont évolué au fil des ans. Internet-brouillons qui révisent les RFC existants ont souvent des projets de noms avec "bis" en eux, ce qui signifie "à nouveau" ou "deux fois"; par exemple, un brouillon pourrait être appelé "draft-quelqu'un-rfc2345bis-00.txt".

6.3.1 Lecture recommandée pour les écrivains

Avant de créer le premier brouillon de votre brouillon Internet, vous devez lire quatre documents:

  • Plus important que d'expliquer simplement le formatage, la RFC 2223 explique également ce qui doit être dans un brouillon Internet avant qu'il ne devienne un RFC. Ce document décrit toutes les sections et les avis qui devront figurer dans votre document, et il est bon de les avoir dès le début afin que les lecteurs ne soient pas surpris lorsque vous les mettez dans des versions ultérieures.
  • BCP 22, "Guide pour les rédacteurs de normes Internet", fournit des conseils qui vous aideront à rédiger une norme qui mène à l'interopérabilité. Par exemple, il explique comment choisir le bon nombre d'options de protocole, comment réagir à un comportement hors spécifications et comment afficher des diagrammes d'état.
  • Les Lignes directrices en ligne pour les auteurs de projets Internet contiennent des informations à jour sur le processus de conversion des projets Internet, ainsi que les informations les plus récentes qui doivent être incluses dans chaque projet Internet.
  • Lorsque vous pensez que vous avez terminé le processus de brouillon et êtes prêt à demander que le brouillon devienne un RFC, vous devriez certainement lire la Liste de contrôle pour les brouillons Internet (I-D) soumis pour publication RFC, une liste des problèmes courants qui ont été connus. pour arrêter les documents dans l'IESG. En fait, vous devriez probablement lire ce document bien avant d'avoir terminé, afin de ne pas avoir à faire un tas de changements de dernière minute.

Il existe également des guides spécifiques aux domaines importants à couvrir dans votre brouillon, tels que les considérations de sécurité et même des modèles de brouillons qui se produisent fréquemment, tels que les modules YANG et les MIB. Les modèles et scripts de Martin Thomson pourraient vous aider à rédiger plus facilement un projet Internet et à automatiser le processus de soumission.

En outre, vous devriez visiter les pages Web des outils de l'IETF, où vous trouverez des pointeurs vers d'autres outils qui automatiseront une partie de votre travail pour l'IETF.

6.3.2 Noms de fichiers et autres sujets

Lorsque vous êtes prêt à rendre votre brouillon Internet, vous le soumettez à [17] . Les instructions sur cette page Web vous guideront à travers les étapes nécessaires, et il y a aussi une adresse e-mail au cas où vous auriez besoin d'une aide personnalisée.

Lorsque vous soumettez la première version du brouillon, vous indiquez également à l'administrateur du brouillon le nom de fichier proposé pour le brouillon. Si le projet est un produit officiel du groupe de travail, le nom commencera par "draft-ietf-" suivi de la désignation du groupe de travail, suivi d'un ou deux mots descriptifs, suivis de "00.txt".

Par exemple, un brouillon dans le groupe de travail S / MIME sur la création de clés peut être nommé "draft-ietf-smime-keying-00.txt". Si ce n'est pas le produit d'un groupe de travail, le nom commencera par "draft-" mais ne sera pas suivi par "ietf-". Souvent, le nom de famille de l'un des auteurs (ou d'un autre identifiant) est suivi d'un ou deux mots descriptifs, suivis de "00.txt". Par exemple, un brouillon qu'une personne nommée Smith a écrit pourrait être nommé "draft-smith-keying-00.txt". Si un projet est une soumission individuelle mais concerne un groupe de travail particulier, les auteurs suivent parfois leur nom avec le nom du groupe de travail, tel que "draft-smith-smime-keying-00.txt". Si vous suivez les directives de dénomination données dans [18] , il y a de fortes chances que votre nom de fichier suggéré soit correct.

Après la première édition d'un brouillon, le numéro du nom de fichier est incrémenté; par exemple, la deuxième édition du brouillon S / MIME nommé ci-dessus serait "draft-ietf-smime-keying-01.txt". Notez qu'il existe des cas où le nom de fichier change après une ou plusieurs versions, par exemple lorsqu'un effort personnel est déployé dans un groupe de travail; lorsqu'un brouillon a son nom de fichier changé, le nombre revient à -00. Les présidents des GT informeront l'administrateur d'Internet-Drafts du nom précédent du brouillon lorsqu'un tel changement de nom se produit afin que les bases de données puissent être tenues à jour.

6.4 RFC de suivi des normes

La procédure de création et d'avancement d'une norme est décrite dans le BCP 9. Après qu'un projet Internet a été suffisamment discuté et qu'il y ait un consensus approximatif sur ce qu'il dit serait une norme utile, il est présenté à l'IESG pour examen. Si le projet est un projet officiel du GT, le président du GT l'envoie au directeur régional approprié. Si l'ébauche est une soumission individuelle, l'auteur ou l'éditeur de l'ébauche la soumet au directeur régional approprié. Le BCP 9 décrit également le processus d'appel pour les personnes qui estiment qu'un président de groupe de travail, un AD ou l'IESG a pris la mauvaise décision en envisageant la création ou l'avancement d'une norme.

Une fois l'ID soumis à l'IESG, l'IESG annonce un dernier appel à l'échelle de l'IETF (souvent abrégé en "LC"). Cela permet d'attirer l'attention des personnes qui ne suivaient pas la progression du projet et peut parfois entraîner d'autres modifications du projet. C'est aussi un moment où les membres du GT qui sentent qu'ils n'ont pas été entendus peuvent faire leurs commentaires à tout le monde. Le dernier appel de l'IETF est d'au moins deux semaines pour les projets émanant des groupes de travail et de quatre semaines pour les soumissions individuelles.

Le but de l'IETF Last Call est d'obtenir une discussion à l'échelle de la communauté sur les documents avant que l'IESG les examine. Notez le mot «discussion» ici. Il est généralement considéré comme une mauvaise forme d'envoyer des commentaires de dernier appel de l'IETF sur des documents que vous n'avez pas lus, ou d'envoyer des commentaires mais ne pas être prêt à discuter de vos opinions. Le dernier appel de l'IETF n'est pas un vote, et les campagnes visant à amener les gens à envoyer un soutien ou une opposition à un document se retournent généralement. Cela dit, les commentaires du dernier appel de l'IETF provenant de personnes qui viennent de lire le document pour la première fois peuvent révéler des problèmes que les habitués de l'IETF et du GT peuvent avoir complètement manqués, c'est pourquoi la discussion est ouverte à tous.

Si l'IESG approuve le projet de devenir un RFC de suivi des normes, il demande à l'éditeur du RFC de le publier en tant que norme proposée. Quelques choses se produisent généralement à ce stade. Tout d'abord, il est courant de constater que certaines des spécifications de la norme doivent être reformulées parce qu'un implémenteur pensait qu'elles signifiaient une chose tandis qu'un autre implémenteur pensait qu'elles signifiaient autre chose. Une autre occurrence courante est qu'aucune des implémentations n'a réellement essayé d'implémenter quelques-unes des fonctionnalités de la norme; ces fonctionnalités sont supprimées non seulement parce que personne ne les a testées, mais aussi parce qu'elles n'étaient pas nécessaires.

Ne soyez pas surpris si une norme particulière ne passe pas de la norme proposée à la norme Internet. Pour devenir une norme Internet, un RFC doit avoir plusieurs implémentations interopérables et les fonctionnalités inutilisées de la norme proposée doivent être supprimées; le BCP 9 contient des exigences supplémentaires. La plupart des normes couramment utilisées sont des normes proposées et ne progressent jamais. Cela peut être dû au fait que personne n'a pris le temps d'essayer de les faire accéder à Internet Standard, ou que certaines des références normatives dans la norme sont toujours à la norme proposée, ou il se peut que tout le monde ait trouvé des choses plus importantes à faire.

6.4.1 Dire les choses telles qu'elles sont - Utiliser MUST et SHOULD et MAY

Écrire des spécifications qui sont implémentées comme vous le souhaitez est un peu un art. Vous pouvez garder la spécification très courte, avec juste une liste d'exigences, mais cela tend à amener les implémenteurs à prendre trop de latitude. Si vous rendez plutôt la spécification très verbeuse avec beaucoup de suggestions, les implémenteurs ont tendance à manquer les exigences (et sont souvent en désaccord avec vos suggestions de toute façon). Une spécification optimale se situe quelque part entre les deux.

Une façon de rendre plus probable que les développeurs créeront des implémentations interopérables de normes est d'être clair sur ce qui est obligatoire dans une spécification. Les premiers RFC utilisaient toutes sortes d'expressions pour expliquer ce qui était nécessaire, de sorte que les implémenteurs ne savaient pas toujours quelles parties étaient des suggestions et quelles étaient les exigences. En conséquence, les rédacteurs de normes de l'IETF ont généralement accepté de limiter leur formulation à quelques mots spécifiques avec quelques significations spécifiques.

La norme STD 3, "Conditions requises pour les hôtes Internet - Application et support", écrite en 1989, contenait une courte liste de mots qui semblaient utiles, à savoir "doit", "devrait" et "peut". Ces définitions ont été mises à jour et affinées dans le BCP 14, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", qui est largement référencé dans les normes Internet actuelles. BCP 14 définit également spécifiquement "ne doit pas" et "ne devrait pas", et il énumère quelques synonymes pour les mots définis.

Dans une norme, afin d'indiquer clairement que vous utilisez les définitions du BCP 14, vous devez faire deux choses. Tout d'abord, référez-vous au BCP 14 (bien que la plupart des gens l'appellent RFC 2119 , car c'est ce que le BCP 14 vous dit de faire), afin que le lecteur sache comment vous définissez vos mots. Deuxièmement, vous devez indiquer quelles instances des mots que vous utilisez proviennent de BCP 14. La pratique acceptée pour cela est de mettre les mots en majuscule. C'est pourquoi vous voyez "DOIT" et "DEVRAIT" capitalisé dans les normes IETF. La RFC 8174 est une référence utile pour déterminer ce qui doit être capitalisé.

BCP 14 comprend deux courts documents, et il devrait être lu par tous ceux qui lisent ou écrivent les normes IETF. Bien que les définitions de «doivent» et «ne doivent pas» soient assez claires, les définitions de «devraient» et «ne devraient pas» suscitent beaucoup de discussions dans de nombreux groupes de travail. Lors de l'examen d'un projet Internet, la question est souvent posée: "Cette phrase devrait-elle contenir un MUST ou un DEVRAIT?" C'est, en effet, une très bonne question, car les spécifications ne devraient pas avoir de MUST gratuits, mais ne devraient pas non plus avoir de DOIT où un MUST est nécessaire pour l'interopérabilité. Cela va au cœur de la question de la sur-spécification et de la sous-spécification des exigences dans les normes.

6.4.2 Références normatives dans les normes

Un aspect de l'écriture des normes IETF qui fait voyager de nombreux nouveaux arrivants (et pas mal de gens de longue date de l'IETF) est la règle sur la façon de faire des "références normatives" à des documents non-IETF ou à d'autres RFC dans une norme. Une référence normative est une référence à un document qui doit être suivi pour mettre en œuvre la norme. Une référence non normative (parfois appelée "référence informative") est une référence utile à un implémenteur mais non nécessaire.

Une norme IETF peut faire une référence normative à tout autre RFC de suivi de normes qui est au même niveau de normes ou supérieur, ou à toute "norme ouverte" qui a été développée en dehors de l'IETF. La règle du "même niveau ou supérieur" signifie qu'avant qu'une norme puisse passer de Proposé à Brouillon, tous les RFC pour lesquels il existe une référence normative doivent également être à la norme Brouillon ou Internet. Cette règle est décrite dans BCP 97. Cette règle donne aux implémenteurs l'assurance que tout dans une norme Internet est assez stable, même les éléments référencés en dehors de la norme. Cela peut également retarder la publication du projet ou de la norme Internet de plusieurs mois (parfois même des années) pendant que les autres documents se rattrapent.

Il n'y a pas de règle stricte sur ce qu'est une "norme ouverte", mais cela signifie généralement une norme stable dont tout le monde peut obtenir une copie (bien qu'ils puissent avoir à payer pour cela) et qui a été établie par un organisme généralement reconnu. groupe de normes. Si la norme externe change, vous devez faire référence à l'instanciation particulière de cette norme dans votre spécification, comme avec une désignation de la date de la norme. Certains organismes de normalisation externes ne rendent pas les anciennes normes disponibles, ce qui est un problème pour les normes IETF qui doivent être utilisées à l'avenir. En cas de doute, un projet d'auteur doit demander au président du GT ou au directeur régional approprié si une norme externe particulière peut être utilisée dans une norme IETF.

6.4.3 Considérations IANA

De plus en plus de normes IETF nécessitent l'enregistrement de divers paramètres de protocole, tels que des options nommées dans le protocole. Comme nous l'avons noté dans la section 2.2.4, le registre principal pour toutes les normes IETF est depuis longtemps l'IANA. En raison des types de registres importants et divers que les normes exigent, l'IANA doit avoir des informations spécifiques sur la façon d'enregistrer les paramètres, ce qu'il ne faut pas enregistrer, qui (le cas échéant) décidera de ce qui doit être enregistré, etc.

Toute personne écrivant une norme Internet qui peut avoir besoin d'un nouveau registre IANA ou de nouvelles valeurs dans un registre IANA actuel doit lire BCP 26, "Directives pour la rédaction d'une section de considérations IANA dans les RFC", qui décrit comment les auteurs de RFC doivent correctement demander à l'IANA de démarrer ou reprendre un registre. L'IANA maintient également des registres qui ont été ouverts bien avant la production du BCP 26.

6.4.4 Considérations de sécurité

Une chose qui est requise dans chaque RFC et Internet-Draft est une section "Considérations de sécurité". Cette section doit décrire toutes les vulnérabilités connues du protocole, les menaces possibles et les mécanismes ou stratégies pour y remédier. Ne passez pas sous silence cette section - en particulier, ne dites pas: «Voici notre protocole, si vous voulez de la sécurité, utilisez simplement IPsec». Cela ne fonctionnera pas du tout, car cela ne répond pas à la question de savoir comment IPsec interagit avec votre protocole, et vice versa. Voir BCP 72, "Directives pour la rédaction de texte RFC sur les considérations de sécurité", pour plus d'informations sur la rédaction de bonnes sections sur les considérations de sécurité.

6.4.5 Brevets dans les normes IETF

Les problèmes de propriété intellectuelle sont apparus de plus en plus souvent ces dernières années, notamment en ce qui concerne les brevets. Le but de l'IETF est d'avoir ses normes largement utilisées et validées sur le marché. Si la création d'un produit qui utilise une norme nécessite d'obtenir une licence pour un brevet, les gens sont moins susceptibles de mettre en œuvre la norme. Il n'est donc pas surprenant que la règle générale ait été "d'utiliser une bonne technologie non brevetée dans la mesure du possible".

Bien sûr, ce n'est pas toujours possible. Parfois, les brevets apparaissent après l'établissement d'une norme. Parfois, il y a un brevet sur quelque chose de si précieux qu'il n'y a pas d'équivalent non breveté. Parfois, le titulaire du brevet est généreux et promet d'accorder à tous les exécutants d'une norme une licence libre de droits pour le brevet, ce qui le rendrait presque aussi facile à mettre en œuvre qu'il l'aurait été si aucun brevet n'avait existé.

Les méthodes de l'IETF pour traiter les brevets dans les normes font l'objet de nombreux débats. Les règles officielles pour tous les droits de propriété intellectuelle (DPI) dans les documents de l'IETF (pas seulement les brevets) sont couvertes dans les BCP 78 et BCP 79, "Droits de propriété intellectuelle sur la technologie IETF". Tous ceux qui participent aux groupes de travail de l'IETF trouveront probablement ces documents intéressants car ils énoncent les règles que tout le monde accepte de suivre.

Les titulaires de brevets qui autorisent librement l'utilisation de leurs brevets par des personnes appliquant les normes de l'IETF obtiennent souvent beaucoup de bonne volonté de la part des gens de l'IETF. Une telle générosité est plus courante que vous ne le pensez. Par exemple, RFC 1822 est une licence d'IBM pour l'un de ses brevets de sécurité dans un contexte de protocole particulier, et la communauté de la sécurité a répondu très favorablement à IBM pour cela (alors qu'un certain nombre d'autres sociétés se sont fait des parias pour leur intractabilité sur leur brevets de sécurité).

Si vous rédigez un projet Internet et que vous connaissez un brevet qui s'applique à la technologie sur laquelle vous écrivez, ne mentionnez pas le brevet dans le document. Consultez plutôt la page IETF IPR sur https://datatracker.ietf.org/ipr/about pour déterminer comment procéder. Les droits de propriété intellectuelle ne sont pas mentionnés dans les RFC car les RFC ne changent jamais après leur publication, mais la connaissance des DPI peut changer à tout moment. Par conséquent, une liste de DPI dans un RFC pourrait être incomplète et induire le lecteur en erreur. Le BCP 79 fournit un texte spécifique qui devrait être ajouté aux RFC lorsque l'auteur connaît les problèmes de DPI.

6.5 RFC informatifs et expérimentaux

Comme nous l'avons noté précédemment, tous les RFC ne sont pas des normes. En fait, de nombreux RFC importants ne sont pas du tout conformes aux normes. Actuellement, il existe deux désignations pour les RFC qui ne sont pas censées être des normes: informative, comme le Tao, et expérimentale. (Il existe en fait une troisième désignation, Historique, mais qui est réservée aux documents qui étaient sur la voie des normes et qui ont été supprimés en raison du manque d'utilisation actuelle, ou que des réflexions plus récentes indiquent que la technologie est réellement nocive pour Internet.)

Le rôle des RFC informationnels est souvent débattu dans l'IETF. Beaucoup de gens aiment les avoir, en particulier pour les spécifications qui ont été créées en dehors de l'IETF mais qui sont référencées par des documents de l'IETF. Ils sont également utiles pour les spécifications qui sont les précurseurs du travail effectué par les groupes de travail de l'IETF. D'un autre côté, certaines personnes qualifient les RFC d'information de «normes» même si les RFC ne sont pas des normes, généralement pour tromper le public crédule sur quelque chose que la personne vend ou soutient. Lorsque cela se produit, le débat sur les RFC informationnels est renouvelé.

Les RFC expérimentaux concernent des spécifications qui peuvent être intéressantes, mais pour lesquelles il n'est pas clair s'il y aura beaucoup d'intérêt à les mettre en œuvre, ou si elles fonctionneront une fois déployées. Autrement dit, une spécification peut résoudre un problème, mais s'il n'est pas clair que beaucoup de gens pensent que le problème est important, ou pensent qu'ils prendront la peine de résoudre le problème avec la spécification, la spécification peut être étiquetée RFC expérimentale. Si, plus tard, la spécification devient populaire (ou prouve qu'elle fonctionne bien), elle peut être réémise en tant que RFC standard. Les RFC expérimentaux sont également utilisés pour amener les gens à expérimenter avec une technologie qui semble être du matériel conforme aux normes, mais pour laquelle il reste des questions sans réponse.

L'IESG a créé des lignes directrices sur la façon dont il choisit entre le statut informationnel et expérimental: [19] . Si vous créez un document qui, selon vous, pourrait devenir un RFC expérimental, connaître la réflexion actuelle vous aidera à justifier votre choix proposé.

7. Comment contribuer à l'IETF

7.1 Ce que vous pouvez faire

Lire - Passez en revue les projets Internet dans votre domaine d'expertise et commentez-les dans les groupes de travail. Participez à la discussion de manière amicale et utile, dans le but d'être les meilleurs standards Internet possibles. Écoutez bien plus que vous ne parlez. Si vous n'êtes pas d'accord, débattez des problèmes techniques: n'attaquez jamais les gens.

Mettre en œuvre - Écrire des programmes qui utilisent les normes Internet actuelles. Les normes ne valent pas grand-chose à moins qu'elles ne soient accessibles aux internautes. Implémentez même les normes "mineures", car elles deviendront moins mineures si elles apparaissent dans plus de logiciels. Signalez tout problème que vous rencontrez avec les normes au groupe de travail approprié afin que la norme puisse être clarifiée dans des révisions ultérieures. L'un des principes les plus souvent cités de l'IETF est «l'exécution de code gagne», vous pouvez donc aider à prendre en charge les normes que vous souhaitez généraliser en créant plus de code en cours d'exécution. Vous pouvez aider au développement de protocoles avant qu'ils ne deviennent des normes en implémentant (mais pas en déployant) à partir d'I-D pour vous assurer que les auteurs ont fait du bon travail. Si vous constatez des erreurs ou des omissions, proposez des améliorations en fonction de votre expérience de mise en œuvre.

Écrire - Modifier ou co-rédiger des brouillons Internet dans votre domaine d'expertise. Faites cela au profit de la communauté Internet, et non pour obtenir votre nom (ou, pire encore, le nom de votre entreprise) sur un document. Les projets d'auteurs font l'objet de toutes sortes de critiques techniques (et parfois personnelles); recevez-le avec sérénité et utilisez-le pour améliorer votre brouillon afin de produire la norme la meilleure et la plus interopérable.

7.2 Ce que votre entreprise peut faire

Partager - Évitez les normes propriétaires. Si vous êtes un implémenteur, manifestez une forte préférence pour les normes IETF. Si les normes IETF ne sont pas aussi bonnes que les normes propriétaires, travaillez pour améliorer les normes IETF. Si vous êtes un acheteur, évitez les produits qui utilisent des normes propriétaires qui sont en concurrence avec les normes ouvertes de l'IETF et dites aux entreprises que vous achetez que vous le faites.

Ouvrir - Si votre entreprise contrôle un brevet qui est utilisé dans une norme IETF, convaincre l'entreprise de rendre le brevet disponible sans frais pour tous ceux qui mettent en œuvre la norme. Au cours des dernières années, les brevets ont causé de nombreux problèmes graves pour les normes Internet car ils empêchent certaines entreprises de pouvoir appliquer librement les normes. Heureusement, de nombreuses entreprises ont généreusement offert des licences illimitées pour des brevets particuliers afin d'aider les normes de l'IETF à prospérer. Ces entreprises sont généralement récompensées par une publicité positive du fait qu'elles ne sont pas aussi gourmandes ou myopes que les autres titulaires de brevets.

Rejoignez - Devenez membre de l'ISOC. Plus important encore, exhortez toute entreprise qui a profité d'Internet à devenir membre corporatif de l'ISOC, car cela présente le plus grand avantage financier pour le groupe. Bien entendu, cela profitera également à Internet dans son ensemble.

8. IETF et le monde extérieur

8.1 IETF et autres groupes de normes

Autant que de nombreux participants de l'IETF voudraient penser le contraire, l'IETF n'existe pas dans un vide de normes. Il existe de nombreux autres organismes de normalisation (peut-être trop) dont les décisions affectent Internet. Il existe également un bon nombre d'organismes de normalisation qui ont longtemps ignoré Internet et veulent maintenant obtenir une part de l'action.

En général, l'IETF essaie d'avoir des relations cordiales avec d'autres organismes de normalisation. Ce n'est pas toujours facile, car de nombreux autres organismes ont des structures très différentes de celles de l'IETF, et l'IETF est principalement gérée par des bénévoles qui préféreraient probablement rédiger des normes plutôt que de rencontrer des représentants d'autres organismes. Malgré cela, certains autres organismes de normalisation font un grand effort pour bien interagir avec l'IETF malgré les différences culturelles évidentes.

Au moment d'écrire ces lignes, l'IETF entretient des liaisons avec de grands organismes de normalisation, notamment l'UIT-T (le Secteur de la normalisation des télécommunications de l'Union internationale des télécommunications), le W3C (World Wide Web Consortium), l'IEEE (Institute of Electrical et ingénieurs en électronique) et le consortium Unicode. Comme indiqué dans la charte de l'IAB (BCP39), "les liaisons sont maintenues aussi informelles que possible et doivent avoir une valeur démontrable pour améliorer la qualité des spécifications de l'IETF". Dans la pratique, l'IETF préfère que les liaisons aient lieu directement au niveau du groupe de travail, avec des relations formelles et des documents de liaison dans un rôle de secours.

Certaines de ces tâches de liaison incombent à l'IESG, tandis que d'autres incombent à l'IAB. Les lecteurs soucieux des détails apprendront beaucoup sur les méthodes formelles de traitement avec d'autres organismes de normalisation dans le BCP 102, "Processus IAB pour la gestion des relations de liaison avec l'IETF", et le BCP 103, "Procédures de traitement des déclarations de liaison vers et depuis l'IETF". Le meilleur endroit pour vérifier si l'IETF a une quelconque liaison officielle est la liste des liaisons IETF.

8.2 Couverture médiatique de l'IETF

Étant donné que l'IETF est l'un des organismes les plus connus qui aident à faire avancer Internet, il est naturel que la presse informatique (et même la presse professionnelle) veuille couvrir ses actions. Mais il peut être difficile de couvrir l'IETF. Un malentendu commun est que l'IETF envisage quelque chose alors qu'en fait il n'y a qu'un projet Internet dans un groupe de travail, et rapporte que l'IETF a approuvé quelque chose quand tout ce qui s'est passé, c'est qu'un RFC d'information a été publié. Dans les deux cas, la presse n'est pas vraiment à blâmer pour le problème, car elle est généralement alertée de l'histoire par une entreprise qui essaie de faire connaître un protocole qu'elle a développé ou au moins à soutenir. L'endroit par défaut où la presse doit rechercher les contacts presse pour l'IETF est [20] .

Les journalistes qui veulent savoir "ce que fait l'IETF" sur un sujet particulier seraient bien avisés de parler à plus d'une personne active sur ce sujet à l'IETF, et devraient probablement essayer de parler au président du GT dans tout les cas. Il est impossible de déterminer ce qui se passera avec un brouillon en consultant le brouillon ou en discutant avec l'auteur du brouillon. Heureusement, tous les groupes de travail ont des archives qu'un journaliste peut consulter pour obtenir des indications récentes sur l'état d'avancement d'un projet; malheureusement, peu de journalistes ont le temps ou l'envie de faire ce genre de recherche.

Les journalistes qui recherchent des informations sur l'IETF, ou des pointeurs vers des participants de l'IETF travaillant sur un sujet particulier intéressant l'IETF, sont encouragés à envoyer un courrier électronique à media@ietf.org. Les réponses sont généralement envoyées dans un délai d'un jour. Même si une réponse directe à une requête particulière n'est pas disponible, des pointeurs vers des ressources ou des personnes qui peuvent fournir plus d'informations sur un sujet sont souvent fournis.

9. Considérations de sécurité

La section 6.4.4 explique pourquoi chaque RFC doit avoir une section sur les considérations de sécurité et donne une idée de ce qu'elle devrait et ne devrait pas contenir. À part ces informations, ce document ne touche pas à la sécurité Internet.

10. Références informatives

BCP9 Bradner, S., «The Internet Standards Process - Revision 3», BCP 9, RFC 2026 , RFC 6410 , octobre 1996.

BCP10 Galvin, J., «Processus de sélection, de confirmation et de rappel de l'IAB et de l'IESG: fonctionnement des comités de nomination et de rappel», BCP 10, RFC 3777 , juin 2004.

BCP11 Hovey, R. et S. Bradner, «Les organisations impliquées dans le processus de normalisation de l'IETF», BCP 11, RFC 2028 , octobre 1996.

BCP14 Bradner, S., «Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence», BCP 14, RFC 2119 , mars 1997.

BCP22 Scott, G., «Guide for Internet Standards Writers», BCP 22, RFC 2360 , juin 1998.

BCP25 Bradner, S., «IETF Working Group Guidelines and Procedures», BCP 25, RFC 2418 , septembre 1998.

BCP26 Narten, T. et H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226 , mai 2008.

BCP39 Internet Architecture Board et B. Carpenter, «Charte de l'Internet Architecture Board (IAB)», BCP 39, RFC 2850 , mai 2000.

BCP45 Harris, S., «IETF Discussion List Charter», BCP 45, RFC 3005 , novembre 2000.

BCP72 Rescorla, E. et B. Korver, «Guidelines for Writing RFC Text on Security Considerations», BCP 72, RFC 3552 , juillet 2003.

BCP78 Bradner, S., «IETF Rights in Contributions», BCP 78, RFC 5378 , novembre 2008.

BCP79 Bradner, S., «Droits de propriété intellectuelle sur la technologie IETF», BCP 79, RFC 3979 , mars 2005.

BCP95 Alvestrand, H., «Un énoncé de mission pour l'IETF», BCP 95, RFC 3935 , octobre 2004.

BCP97 Bush, R. et T. Narten, «Clarifying when Standards Track Documents can refer Normably to Documents at a Lower Level», BCP 97, RFC 3967 , décembre 2004.

BCP101 Austein, R. et B. Wijnen, «Structure de l'IETF Administrative Support Activity (IASA)», BCP 101, RFC 4071 , avril 2005.

BCP102 Daigle, L. et Internet Architecture Board, «IAB Processes for Management of IETF Liaison Relationships», BCP 102, RFC 4052 , avril 2005.

BCP103 Trowbridge, S., Bradner, S. et F. Baker, «Procédures de traitement des déclarations de liaison vers et depuis l'IETF», BCP 103, RFC 4053 , avril 2005

RFC1796 Huitema, C., Postel, J. et S. Crocker, «Pas tous les RFC sont des normes», RFC 1796 , avril 1995.

RFC2223 Postel, J. et J. Reynolds, «Instructions aux auteurs RFC», RFC 2223 , octobre 1997.

RFC2860 Carpenter, B., Baker, F. et M. Roberts, «Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority», RFC 2860 , juin 2000.

RFC6635 Kolkman, O. et J. Halpern, «RFC Editor Model (Version 2)», RFC 6635 , mars 2012.

RFC4677 Hoffman, P. et S. Harris, «The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force», RFC 4677 , septembre 2006.

RFC4858 Levkowetz, H., Meyer, D., Eggert, L. et A. Mankin, «Document Shepherding from Working Group Last Call to Publication», RFC 4858 , mai 2007.

RFC6722 Hoffman, P., «Publication du« Tao de l'IETF »en tant que page Web», RFC 6722 , août 2012.

STD3 Braden, R., «Configuration requise pour les hôtes Internet - Application et support», STD 3, RFC 1123 , octobre 1989.

A. Principes directeurs de l'IETF

Si vous êtes allé aussi loin dans le Tao, vous avez beaucoup appris sur le fonctionnement de l'IETF. Ce que vous trouverez dans cette annexe résume une grande partie de ce que vous avez lu et ajoute quelques nouveaux points à méditer. Assurez-vous de lire tous les principes; pris dans leur ensemble, ils vous donneront une nouvelle perspective sur ce qui fait fonctionner l'IETF.

A.1 Général

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

L'IETF travaille dans des domaines où elle possède ou peut trouver des compétences techniques.

L'IETF dépend d'un noyau bénévole de participants actifs.

La participation à l'IETF ou à ses groupes de travail n'est pas payante ou définie sur le plan organisationnel, mais repose sur l'auto-identification et la participation active des individus.

A.2 Gestion et leadership

L'IETF reconnaît les postes de direction et accorde le pouvoir de décision aux dirigeants, mais les décisions sont susceptibles d'appel.

La délégation de pouvoir et de responsabilité est essentielle au fonctionnement efficace de l'IETF. Autant de personnes que possible seront encouragées à assumer le leadership des tâches de l'IETF.

La dissidence, la plainte et l'appel sont une conséquence de la nature de l'IETF et doivent être considérés comme des événements normaux, mais en fin de compte, c'est un fait que certaines décisions ne peuvent pas être effectivement appelées.

Les postes de direction sont à durée déterminée (bien que nous n'ayons aucune limitation formelle sur le nombre de mandats pouvant être servis).

Il est important de former de futurs leaders au sein de la communauté active.

Un processus communautaire est utilisé pour sélectionner les dirigeants.

Les dirigeants ont le pouvoir de juger qu'un consensus approximatif a été démontré. Sans adhésion officielle, il n'y a pas de règles formelles de consensus.

A.3 Processus

Bien que l'IETF ait besoin de règles de processus claires et documentées publiquement pour les cas normaux, il devrait y avoir suffisamment de flexibilité pour permettre aux cas inhabituels d'être traités selon le bon sens. Nous appliquons un jugement personnel et ne codifions que lorsque nous en sommes certains. (Mais nous codifions qui peut porter des jugements personnels.)

Les travaux de développement technique devraient être menés par des groupes de travail à charte étroite et ciblés.

Les parties du processus qui se sont révélées impraticables doivent être supprimées ou rendues facultatives.

A.4 Groupes de travail

Les groupes de travail (GT) devraient être principalement responsables de la qualité de leurs résultats; Les présidents des groupes de travail en tant que dirigeants des groupes de travail, appuyés par la direction de l'IETF, devraient agir comme un filet de sécurité de qualité.

Les groupes de travail devraient être principalement chargés d'évaluer l'impact négatif de leur travail sur Internet dans son ensemble, et donc d'obtenir un examen intersectoriel; la direction de l'IETF devrait agir comme un filet de sécurité intersectoriel.

Un examen précoce des documents, en particulier par des groupes de travail, est plus efficace pour traiter des problèmes majeurs qu'un examen tardif.

Les directeurs régionaux (AD) sont chargés d'orienter la formation et la constitution des groupes de travail, de leur donner des directives si nécessaire et de les mettre fin. Les présidents des GT siègent au gré de l'AD responsable.

Les présidents des GT sont chargés de veiller à ce que les GT exécutent leurs chartes, respectent leurs jalons et produisent des livrables prêts à être publiés. Les éditeurs de documents sont à la disposition du président du GT.

Les DA sont responsables de l'organisation de la révision du filet de sécurité et de l'approbation finale du document. A.5 Documents

Les normes de l'IETF commencent souvent comme des projets personnels, peuvent devenir des projets du GT et sont approuvées pour publication permanente par un organe de direction indépendant du GT ou des personnes qui les ont produites.

Les normes IETF appartiennent à la communauté, pas à leurs auteurs. Mais la paternité est reconnue et valorisée, tout comme les contributions moindres que la paternité totale.

La qualité technique et l'exactitude sont les principaux critères pour parvenir à un consensus sur les documents.

Les spécifications de l'IETF peuvent être publiées en tant qu'informationnel, expérimental, normalisé, historique ou meilleure pratique actuelle.

Les spécifications IETF Standards Track ne sont pas considérées comme des normes satisfaisantes tant que des implémentations indépendantes interopérables n'ont pas été démontrées. (Il s'agit de l'incarnation du slogan «code en cours d'exécution».) Cependant, l'IETF ne prend pas la responsabilité des tests d'interopérabilité et ne certifie pas l'interopérabilité.

Les processus de l'IETF sont publiés en tant que documents sur les meilleures pratiques actuelles.

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

Les spécifications et processus obsolètes ou obsolètes peuvent être rétrogradés à Historique.

La voie des normes devrait distinguer les spécifications dont il a été démontré qu'elles interagissent.

Les documents Standards Track et Best Current Practice doivent être soumis au consensus général de l'IETF (processus Last Call). Un consensus approximatif du GT est normalement suffisant pour d'autres documents.

Les modifications substantielles apportées à la suite du dernier appel de l'IETF ou de l'évaluation de l'IESG doivent être renvoyées au GT.

L'IETF détermine les exigences de publication et d'archivage de ses documents.

3. Réunions de l'IETF

L'industrie informatique regorge de conférences, de séminaires, d'expositions et de toutes sortes d'autres types de réunions. Les réunions face à face de l'IETF ne sont pas comme celles-ci. Les réunions, tenues trois fois par an, sont des rassemblements d'une semaine dont l'objectif principal est de revigorer les GT pour accomplir leurs tâches, et dont l'objectif secondaire est de promouvoir un bon mélange entre les GT et les zones.

Pour beaucoup de gens, les réunions de l'IETF sont une bouffée d'air frais par rapport aux conférences standard de l'industrie informatique. Il n'y a pas de salle d'exposition, peu de tutoriels et pas de grands experts de l'industrie. Au lieu de cela, il y a beaucoup de travail, ainsi que beaucoup de temps pour socialiser pour de nombreux participants. Les réunions de l'IETF intéressent peu les commerciaux et le marketing, mais intéressent fortement les ingénieurs et les développeurs.

Le flux général d'une réunion de l'IETF est qu'elle commence par un hackathon le samedi et le dimanche, des tutoriels et une réunion informelle le dimanche, et qu'il y a des réunions du GT et de la BoF du lundi au vendredi. Les réunions des groupes de travail durent entre 1 et 2,5 heures chacune, et certains groupes de travail se réunissent plusieurs fois au cours de la semaine, selon la quantité de travail qu'ils prévoient de faire.

Il y a une session plénière pendant la semaine. Habituellement, une partie de la plénière comprend une présentation technique organisée par l'IAB et avec un ou deux groupes d'experts sur des sujets d'intérêt dans de nombreux groupes de travail et domaines. La partie administrative de la session plénière, organisée par le président de l'IETF, couvre des choses comme les rapports d'avancement du RFC Editor et les annonces des prochaines réunions. Les plénières comprennent également une partie "micro ouvert", qui est un bon moment pour partager avec l'IESG et l'IAOC. La louange est la bienvenue, mais le plus souvent, des inquiétudes et des reproches sont soulevés.

Actuellement, l'IETF se réunit en Amérique du Nord, en Europe et en Asie, environ une fois par an dans chaque région. Il y a eu plus de 100 réunions de l'IETF à ce jour, et une liste des réunions à venir est disponible sur les pages Web de l'IETF. Vous pouvez en savoir plus sur la politique et le processus de sélection des réunions ici.

Les nouveaux arrivants aux réunions en face à face de l'IETF s'attendent souvent à ce qu'ils soient comme d'autres organismes de normalisation ou comme des conférences informatiques. Heureusement, de nombreux nouveaux participants s'animent assez sur le plaisir qu'ils ont. D'un autre côté, les IETFers peuvent parfois être étonnamment directs, parfois à la grossièreté. Pour créer un climat dans lequel des personnes d'horizons différents sont traitées avec dignité, décence et respect, l'IETF a une politique anti-harcèlement, ombudsteam.

3.1 Inscription

Pour assister à une réunion de l'IETF en personne, vous devez vous inscrire et payer des frais d'inscription. Le lieu de la réunion et l'inscription à l'avance sont annoncés au moins deux mois avant la réunion - plus tôt si possible. Une annonce est envoyée par e-mail à la liste de diffusion des annonces de l'IETF, et des informations sont publiées sur le site Web de l'IETF, le même jour.

Vous devez également vous inscrire pour participer à distance; il n'y a actuellement aucun frais d'inscription pour la participation à distance.

Vous pouvez vous inscrire et payer sur le Web avant la réunion, ou en personne à la réunion. Pour obtenir des frais d'inscription moins élevés, vous devez payer avant la date limite d'inscription hâtive (au moins sept semaines avant la réunion). La fenêtre des frais d'inscription standard se ferme 2 semaines avant la réunion, si vous vous inscrivez à tout moment par la suite, vous devrez payer les frais d'inscription tardive. Les frais d'inscription couvrent toutes les réunions de la semaine, la réception de bienvenue du dimanche soir et les pauses boissons et collations l'après-midi.

L'inscription est ouverte toute la semaine de la réunion. Vous pouvez en savoir plus sur la façon dont l'IETF traite vos données personnelles ici: [9] .

Si vous participez à une réunion de l'IETF pour la première fois, vous pouvez également envisager de vous abonner à la liste de diffusion spécifique à la réunion, qui est présentée en option lorsque vous vous inscrivez pour participer à la réunion en personne ou à distance. Les discussions sur la liste des réunions peuvent être volumineuses et assez variées sur des questions spécifiques à la réunion, mais c'est également un moyen de partager des informations que beaucoup trouvent utiles pour comprendre ce qui se passe pendant la réunion elle-même.

Le dimanche est une excellente journée pour rejoindre la réunion, sauf si vous nous avez déjà rejoint lors du hackathon samedi. Le dimanche est le jour du tutoriel pour les nouveaux arrivants, ainsi que de la session Quick Connections où les nouveaux arrivants rencontrent des participants expérimentés de l'IETF et du Newcomer's Meet and Greet où les nouveaux arrivants peuvent rencontrer les directeurs régionaux et les présidents des groupes de travail. Après ces sessions, il y a la réception qui est un événement populaire où vous pouvez prendre une petite bouchée à manger et socialiser avec d'autres participants.

Avant de vous inscrire, vous voyez une page Web intitulée «Note bien». Vous devez en effet le lire attentivement car il énonce les règles relatives aux droits de propriété intellectuelle de l'IETF. La note indique les documents justificatifs pour les DPI, la lutte contre le harcèlement et d'autres politiques d'orientation importantes pour l'IETF.

Si vous devez laisser des messages à d'autres participants, vous pouvez le faire aux panneaux de liège qui sont souvent près du bureau d'inscription. Ces planches de liège auront également des changements de réunion de dernière minute et des changements de salle.

Vous pouvez également remettre les objets trouvés au bureau d'inscription. À la fin de la réunion, tout ce qui restera des objets trouvés sera généralement remis à l'hôtel ou ramené au bureau du Secrétariat.

Soit dit en passant, le bureau d'inscription de l'IETF est souvent un endroit pratique pour organiser des rencontres. Si quelqu'un dit "me rencontrer lors de l'inscription", vous devez préciser s'il s'agit du bureau d'inscription de l'IETF ou du bureau d'inscription de l'hôtel. Cela a été une cause fréquente de connexions manquées.

3.2 Faites le grand saut et restez toute la semaine!

Les réunions du groupe de travail de l'IETF sont prévues du lundi matin au vendredi après-midi. Les réunions non-GT associées ont souvent lieu le week-end précédent ou suivant. Il est préférable de prévoir d'être présent toute la semaine, de bénéficier de la fertilisation croisée entre les groupes de travail et des discussions sur les couloirs. Comme indiqué ci-dessous, l'ordre du jour est fluide et il y a eu de nombreux cas où les participants ont manqué des sessions importantes en raison de changements d'horaire de dernière minute après que leurs plans de voyage ont été fixés. Être présent toute la semaine est le seul moyen d'éviter ce désagrément.

Si vous ne trouvez pas de réunions toute la semaine pour vous intéresser, vous pouvez toujours tirer le meilleur parti de la réunion de l'IETF en travaillant entre les sessions. La plupart des participants à l'IETF portent des ordinateurs portables, et il est courant d'en voir beaucoup dans la salle des terminaux ou dans les couloirs pendant les sessions de réunion. Il y a souvent une bonne couverture Internet sans fil dans de nombreux endroits du lieu de réunion (restaurants, cafés, etc.), donc rattraper son retard sur les e-mails en dehors des réunions est une tâche assez courante pour les IETFers.

3.3 Formation des nouveaux arrivants

Les nouveaux arrivants sont encouragés à assister au tutoriel pour les nouveaux arrivants le dimanche après-midi, qui est spécialement conçu pour les nouveaux participants. Le tutoriel est organisé et mené par l'équipe IETF EDU et est destiné à fournir des informations d'introduction utiles. La session couvre ce que signifient tous les points sur les étiquettes de nom, la structure de l'IETF et de nombreux autres sujets essentiels et éclairants pour les nouveaux IETFers. Si vous ne pouvez pas assister à cette session, les sessions enregistrées des réunions précédentes sont disponibles ( [10] ).

Plus tard dans l'après-midi est la session Quick Connections où les nouveaux arrivants ont la chance de connaître les participants seniors de l'IETF et de poser des questions. La session Quick Connections est suivie du Meet and Greet du nouvel arrivant, qui est uniquement ouvert aux nouveaux arrivants et aux présidents des groupes de travail. C'est un excellent endroit pour essayer de trouver des personnes compétentes dans les domaines qui vous intéressent. C'est une bonne occasion de vous connecter aux présidents des groupes de travail qui vous intéressent. Si vous ne trouvez pas facilement la bonne personne ou si vous ne savez pas à quel groupe de travail vos intérêts sont liés, n'hésitez pas à contacter quiconque sans ruban pour nouveaux arrivants pour vous aider à entrer en contact avec les bonnes personnes.

3.4 Code vestimentaire

Lors des réunions, les gens s'habillent généralement de manière informelle. Les nouveaux arrivants sont parfois déplacés lorsqu'ils se présentent lundi matin en costume. La règle générale est «habillez-vous pour la météo» (à moins que vous ne prévoyiez travailler si dur que vous ne sortiez pas, auquel cas, «habillez-vous pour le confort» est la règle!).

3,5 réunions du GT

Le cœur d'une réunion de l'IETF est les réunions du GT elles-mêmes. Les différents présidents des groupes de travail ont des styles très différents, il est donc impossible de généraliser la sensation d'une réunion de groupe de travail. Même si presque tous les groupes de travail ont des ordres du jour pour leurs réunions, certaines réunions respectent strictement leur ordre du jour tandis que d'autres sont plus lâches.

Il y a quelques choses importantes qui sont vraies pour toutes les réunions du GT lors d'une réunion de l'IETF. Vers le début de la réunion, le président fera le tour des "draps bleus", qui sont des formulaires papier sur lesquels chacun inscrit son nom et son affiliation. Ils sont utilisés à des fins d'archivage à long terme pour montrer combien de personnes sont venues à une réunion particulière et, dans de rares cas, exactement qui s'est présenté. L'étiquette normale est de regarder d'où viennent les draps bleus et de les faire passer dans la même direction.

Lorsque vous parlez en réunion, vous devez toujours vous rendre aux microphones de la salle. Pour les sujets controversés, il y aura une ligne au micro, mais n'hésitez pas à être la première personne au micro si vous avez une question ou une contribution à la discussion. Le président ou le présentateur du GT indiquera quand vous pourrez parler. Bien qu'il soit plus facile de simplement lever la main d'où vous êtes assis, les micros effectuent une tâche très utile: ils permettent aux personnes qui écoutent à distance et dans la pièce d'entendre votre question ou votre commentaire. On s'attend également à ce que vous prononciez votre nom au micro pour que la personne qui prend les minutes sache qui parle.

3.6 Voir les taches sous vos yeux

Certaines personnes à l'IETF auront un petit point coloré sur leur étiquette de nom. Quelques personnes en ont plus d'un. Ces points identifient les personnes qui sont assez stupides pour se porter volontaires pour faire beaucoup de travail supplémentaire. Les couleurs ont la signification indiquée ici. Couleur SignificationBlue Working Group / BOF ChairGroupe d'accueil vertMembre IAB rougeMembre IESG jauneMembre du comité de nomination d'OrangeTableau noir IETF LLCIRSG roseÉditeur de séries RFC Teal (Les membres de la presse portent des badges teintés d'orange avec le mot «presse» dessus.)

Il est important que les nouveaux arrivants à l'IETF n'aient pas peur d'entamer des conversations avec les personnes qui portent ces points. Si les membres de l'IAB et de l'IESG et les présidents des groupes de travail et BOF ne voulaient parler à personne, ils ne porteraient pas les points en premier lieu. Notez, cependant, que les réunions de l'IETF sont généralement des moments intenses pour les directeurs de zone. Parler à un AD lors d'une réunion de l'IETF conduira souvent à une demande de lui envoyer un e-mail environ deux semaines plus tard. De plus, lorsque vous commencez une conversation dans un couloir avec un directeur de secteur (ou même un président de GT, d'ailleurs), il est souvent bon de leur donner environ 30 secondes de contexte pour la discussion.

3.7 Terminal Room

Le centre des opérations réseau (NOC) fournit un accès Internet aux participants à chaque réunion. En général, la connectivité sans fil est excellente dans toutes les salles de réunion et les zones les plus communes, et la connectivité filaire est fournie dans la salle des terminaux. Les personnes et les entreprises qui donnent leur équipement, leurs services et leur temps doivent être chaleureusement félicitées et remerciées.

Bien que la préparation bien avant la réunion soit encouragée, il peut y avoir des choses inévitables de "dernière minute" qui peuvent être accomplies dans la salle des terminaux. Il peut également être utile aux personnes qui ont besoin de faire des rapports de voyage ou des rapports d'état alors que les choses sont encore fraîches dans leur esprit.

Vous devez porter votre badge pour entrer dans la salle des terminaux. Le terminal propose de nombreuses barrettes d'alimentation, de nombreux ports Ethernet pour les ordinateurs portables, sans fil (pour les personnes qui n'ont pas besoin d'Ethernet mais qui veulent de l'énergie) et généralement une imprimante à usage public. Ce qu'il ne fournit pas, ce sont des terminaux; le nom est historique. Le service d'assistance dans la salle des terminaux est un bon endroit pour poser des questions sur les pannes de réseau, bien qu'il puisse vous orienter vers différents membres du réseau.

3.8 Repas et autres délices

Marshall Rose a dit un jour que l'IETF était un endroit où aller pour "de nombreux déjeuners et dîners raffinés". Bien qu'il soit vrai que certaines personnes mangent très bien à l'IETF, elles trouvent la nourriture par elles-mêmes; les déjeuners et dîners ne sont pas inclus dans les frais d'inscription. Si le parrainage est assuré, le Secrétariat organise des amuse-gueules lors de la réception de bienvenue du dimanche soir (non destinée à remplacer le dîner), dans certains lieux, un petit-déjeuner continental du lundi au vendredi matin et (mieux encore) des biscuits, des brownies , fruits et autres délicieux pendant certaines des pauses de l'après-midi. Ceux-ci sont très souvent payés par l'hôte de la réunion ou un sponsor de la réunion.

Si vous préférez sortir de l'hôtel pour les repas, l'hôte local fournit généralement une liste des endroits où manger à proximité du lieu de la réunion.

3.9 Événement social

Une autre des choses les plus importantes organisées et gérées par l'hôte est l'événement social de l'IETF. L'événement social est parfois un événement lié à la haute technologie, ou il peut être dans un musée d'art ou une salle de réception. Notez, cependant, que toutes les réunions de l'IETF ont des événements sociaux.

Les nouveaux arrivants à l'IETF sont encouragés à assister à l'événement social. Tous sont encouragés à porter leur porte-nom et à laisser leur ordinateur portable derrière. L'événement social est conçu pour donner aux gens une chance de se rencontrer à un niveau social plutôt que technique.

3.10 Agenda

L'ordre du jour des réunions de l'IETF est une chose très fluide. Il est disponible sur le Web et via les applications mobiles de l'IETF à partir de quelques semaines avant la réunion. Des agendas de petite taille sont disponibles pour le ramassage au bureau d'inscription pour ceux qui ont une bonne vue et qui veulent garder une copie dans leur poche ou attachée au dos de leur badge. Bien sûr, «final» dans l'IETF ne signifie pas la même chose qu'ailleurs dans le monde. L'ordre du jour final est simplement la version qui est allée à l'imprimante. Le Secrétariat affichera les modifications de l'ordre du jour sur le babillard près du bureau d'inscription de l'IETF (pas le bureau d'inscription de l'hôtel). Ces changements tardifs ne sont pas capricieux: ils sont effectués «juste à temps» lorsque les présidents de séance et les intervenants prennent conscience d’affrontements imprévus. L'IETF est trop dynamique pour que les programmes soient fixés des semaines à l'avance.

Une carte indiquant l'emplacement des salles figure également à l'ordre du jour. L'attribution des salles peut changer à mesure que l'agenda change. Certains groupes de travail se réunissent plusieurs fois au cours d'une réunion, et chaque tentative est faite pour qu'un groupe de travail se réunisse dans la même salle pour chaque session.

3.11 EDU à la rescousse

Si certains aspects de l'IETF vous mystifient encore (même après avoir fini de lire le Tao), vous voudrez vous inscrire à la formation sur place offerte par l'équipe de l'éducation (EDU). Ces cours informels sont conçus pour les nouveaux arrivants et les IETFers chevronnés. En plus de la formation des nouveaux arrivants, l'équipe EDU propose des tutoriels approfondis qui sont indispensables pour les nouveaux arrivants et les participants de longue date de l'IETF. Les sessions EDU ont généralement lieu le dimanche après-midi et sont également affichées à regarder plus tard.

Lors de l'inscription, il vous sera également proposé d'être lié à un mentor. Ceci est également organisé par l'équipe EDU; vous serez jumelé avec des bénévoles qui ont de l'expérience dans l'IETF et peuvent vous aider à démarrer rapidement. Idéalement, vous avez un appel avec votre mentor avant la réunion, une réunion au début de la réunion et vous vous enregistrez à un moment donné pendant la réunion, afin qu'il puisse vous aider avec toutes les questions que vous pourriez avoir.

Vous trouverez plus d'informations sur l'équipe EDU sur [11] .

3.12 Où dois-je m'intégrer?

L'IETF est différent pour différentes personnes. Il y a beaucoup de gens qui ont été très actifs dans l'IETF qui n'ont jamais assisté à une réunion de l'IETF. Vous ne devriez pas vous sentir obligé de venir à une réunion de l'IETF juste pour avoir une idée de l'IETF. Si vous décidez toutefois de venir, la RFC4144 fournit quelques conseils sur la façon de faire de votre réunion un succès [12] . Les lignes directrices suivantes (basées sur des stéréotypes de personnes dans diverses industries) pourraient vous aider à décider si vous voulez réellement venir et, dans l'affirmative, quelle pourrait être la meilleure utilisation de votre temps lors de votre première réunion.

3.12.1 Gestionnaires de systèmes d'information

Comme discuté tout au long de ce document, une réunion de l'IETF ne ressemble en rien à un salon professionnel auquel vous avez assisté. Les réunions de l'IETF sont des endroits singulièrement mauvais à visiter si votre intention est de découvrir ce qui sera chaud dans l'industrie Internet l'année prochaine. Vous pouvez supposer avec certitude que la participation aux réunions des groupes de travail vous rendra plus confuse qu'elle ne vous aidera à comprendre ce qui se passe ou se passera dans l'industrie.

Cela ne veut pas dire que personne de l'industrie ne devrait assister aux réunions de l'IETF. En tant que gestionnaire de SI, vous voudrez peut-être envisager d'envoyer des personnes spécifiques qui sont responsables des technologies en cours de développement dans l'IETF. Au fur et à mesure que ces personnes liront les brouillons Internet actuels et le trafic sur les listes de groupes de travail pertinentes, ils auront une idée de la pertinence de leur présence pour votre entreprise ou pour les groupes de travail.

3.12.2 Opérateurs de réseau et FAI

Faire fonctionner un réseau est déjà assez difficile sans avoir à se débattre avec de nouveaux protocoles ou de nouvelles versions des protocoles avec lesquels vous traitez déjà. Si vous travaillez pour le type de réseau qui utilise toujours le matériel et les logiciels les plus récents et que vous suivez les groupes de travail pertinents pendant votre temps libre copieux, vous pourriez certainement trouver utile de participer à l'IETF. Une bonne partie du travail de l'IETF couvre également de nombreuses autres parties des opérations des FAI et des grandes entreprises, et la contribution des opérateurs de chacun de ces types d'organisations est très précieuse pour maintenir ce travail dynamique et pertinent. Bon nombre des meilleurs documents d'exploitation de l'IETF proviennent d'opérateurs du monde réel, pas de fournisseurs et d'universitaires.

3.12.3 Mise en réseau des fournisseurs de matériel et de logiciels

L'image de l'IETF étant principalement des chercheurs du réseau peut avoir été vraie dans un passé lointain, mais les emplois des participants typiques sont maintenant dans l'industrie. Dans la plupart des domaines de l'IETF, les employés des fournisseurs sont ceux qui rédigent les protocoles et dirigent les groupes de travail, il est donc tout à fait approprié pour les fournisseurs d'y assister. Si vous créez du matériel ou des logiciels Internet et qu'aucun membre de votre entreprise n'a jamais assisté à une réunion de l'IETF, il vous appartient de venir à une réunion si pour aucune autre raison que de dire aux autres dans quelle mesure la réunion était ou n'était pas pertinente pour votre entreprise .

Cela ne veut pas dire que les entreprises devraient fermer boutique pendant les semaines de réunion de l'IETF afin que tout le monde puisse aller à la réunion. Les gens du marketing, même les gens du marketing technique, sont généralement en sécurité en restant loin de l'IETF tant que certains des techniciens de l'entreprise sont à la réunion. De même, il n'est pas nécessaire, ou probablement utile, que tous les membres d'un service technique se rendent, en particulier s'ils ne lisent pas tous les brouillons Internet et ne suivent pas les listes de diffusion du groupe de travail. De nombreuses entreprises ne comptent que quelques participants aux réunions désignés, choisis pour leur capacité à rédiger des rapports de voyage complets et utiles. De plus, de nombreuses entreprises ont des efforts de coordination interne et une stratégie de normalisation. Si une entreprise dépend d'Internet pour tout ou partie de ses activités, la stratégie devrait probablement couvrir l'IETF. Les participants participent à l'IETF en tant qu'individus.

3.12.4 Universitaires

Les réunions de l'IETF sont souvent d'excellents endroits pour que les informaticiens découvrent ce qui se passe sur le chemin des protocoles qui seront bientôt déployés. Les professeurs et les étudiants diplômés (et parfois dépassant le premier cycle) qui effectuent des recherches en réseautage ou en communication peuvent obtenir une mine d'informations en suivant les groupes de travail dans leurs domaines d'intérêt spécifiques. Se promener dans différentes réunions de groupes de travail peut avoir le même effet que d'aller à des colloques et des séminaires dans votre département. Bien entendu, les chercheurs sont également susceptibles d'être intéressés par les activités de l'IRTF.

3.12.5 Computer Trade Press

Si vous êtes membre de la presse et envisagez de participer à l'IETF, nous avons préparé une section spéciale du Tao rien que pour vous - veuillez consulter la section 8.2.

3.13 Actes

Les actes de l'IETF sont compilés dans les deux mois suivant chaque réunion et sont disponibles sur le web. Soyez sûr de regarder à travers une copie - les procédures sont remplies d'informations sur l'IETF que vous ne trouverez probablement nulle part ailleurs. Par exemple, vous trouverez des instantanés de la plupart des chartes des groupes de travail au moment de la réunion, vous permettant de mieux comprendre l'évolution d'un effort donné.

Une liste des participants est également incluse, qui contient les noms et affiliations comme indiqué sur le formulaire d'inscription. Pour plus d'informations sur l'obtention de copies de la procédure, consultez la liste Web à l' adresse https://www.ietf.org/how/meetings/proceedings . Les actes de l'IETF sont compilés dans les deux mois suivant chaque réunion et sont disponibles sur le web. Soyez sûr de regarder à travers une copie - les procédures sont remplies d'informations sur l'IETF que vous ne trouverez probablement nulle part ailleurs. Par exemple, vous trouverez des instantanés de la plupart des chartes des groupes de travail au moment de la réunion, vous permettant de mieux comprendre l'évolution d'un effort donné.

La procédure débute parfois par un message informatif (et très divertissant). Chaque volume contient l'agenda final (rétrospectivement), un aperçu de l'IETF, des rapports de zone et de groupe de travail, et des diapositives du protocole et des présentations techniques. Les rapports et présentations des groupes de travail sont parfois incomplets, si les documents n'ont pas été remis au Secrétariat à temps pour publication.

3.14 Autres choses générales

Les IETFers en général sont très abordables. N'ayez jamais peur d'approcher quelqu'un et de vous présenter. N'ayez pas peur de poser des questions, surtout en ce qui concerne le jargon et les acronymes.

Les conversations dans les couloirs sont très importantes. Beaucoup de très bon travail est fait par des gens qui parlent ensemble entre les réunions et au cours des déjeuners et dîners. Chaque minute de l'IETF peut être considérée comme du temps de travail (à la grande consternation de certaines personnes).

Une réunion parallèle (historiquement mais souvent à tort appelée "bar BOF") est une réunion officieuse entre les réunions du GT ou en fin de soirée, au cours de laquelle beaucoup de travail est effectué. Ces réunions parallèles se produisent dans de nombreux endroits différents autour d'une réunion de l'IETF, tels que des restaurants, des cafés, des espaces de salle inutilisés et (si nous sommes si chanceux) des piscines. Vous pouvez en savoir plus sur les BOF (sessions Birds-of-a Feather) dans la section 5.

Il n'est pas judicieux de se mettre entre un IETFer affamé (et il n'y en a pas d'autre) et des brownies et des biscuits pour la pause-café, peu importe à quel point la conversation dans le couloir est intéressante. Steve Coya, le premier directeur exécutif de l'IETF, a souvent dit: "Prenez votre cookie, puis éloignez-vous de la table."

Les IETFers sont farouchement indépendants. Il est sûr de remettre en question les opinions et d'offrir des alternatives, mais ne vous attendez pas à ce qu'un IETFer suive les commandes.

Les réunions de l'IETF, et la session plénière en particulier, ne sont pas des endroits où les vendeurs peuvent essayer de vendre leurs marchandises. Les gens peuvent certainement répondre aux questions sur leur entreprise et ses produits, mais gardez à l'esprit que l'IETF n'est pas un salon professionnel. Cela n'empêche pas les gens de récupérer les coûts des T-shirts, boutons et protecteurs de poche liés à l'IETF.

Il y a toujours une «table de distribution des matériaux» près du bureau d'inscription. Ce bureau est utilisé pour mettre les informations appropriées à la disposition des participants (par exemple, des copies de quelque chose discuté lors d'une session du groupe de travail, des descriptions des informations en ligne liées à l'IETF). Veuillez vérifier auprès du Secrétariat avant de placer des documents sur le bureau; le Secrétariat a le droit de retirer tout matériel qu'il juge inapproprié.

Si vous comptez sur votre ordinateur portable pendant la réunion, c'est une bonne idée d'apporter une batterie supplémentaire. Il n'est pas toujours facile de trouver une prise de secours dans certaines salles de réunion, et l'utilisation de l'accès sans fil peut décharger votre batterie plus rapidement que vous ne le pensez. Si vous êtes assis près d'une multiprise dans une salle de réunion, attendez-vous à ce qu'il soit branché et débranché pour les autres autour de vous. Beaucoup de gens apportent une rallonge avec des prises de rechange, ce qui est un bon moyen de se faire des amis avec votre voisin lors d'une réunion. Si vous avez besoin d'un adaptateur de prise, vous devriez essayer de l'acheter à l'avance car celui dont vous avez besoin est généralement plus facile à trouver dans votre pays d'origine.

3.15 Participation à distance

Les gens ont rejoint les réunions de l'IETF à distance depuis longtemps, mais les outils pour cela ont beaucoup changé au fil des ans. Actuellement, toutes les réunions des groupes de travail et de recherche ainsi que les plénières sont retransmises en direct et ouvertes à une participation à distance. Pour participer à distance, vous devez vous inscrire en tant que participant à distance [13] , il n'y a pas de frais pour cela, mais l'inscription est requise pour des raisons administratives. Vous pouvez également utiliser des flux audio ainsi que Jabber (ce qui est expliqué ci-dessous). Les liens pour les salles Meetecho, les flux audio et les salles Jabber se trouvent toujours dans l'agenda de la réunion. Plus d'informations peuvent être trouvées ici: [14] . Toutes les sessions sont enregistrées, la vidéo, l'audio, les journaux de discussion et les notes sont accessibles après la réunion.

4. Groupes de travail

La grande majorité du travail de l'IETF est effectuée dans de nombreux groupes de travail; au moment d'écrire ces lignes, il existe environ 115 groupes de travail différents. Le BCP 25, «Lignes directrices et procédures du groupe de travail de l'IETF», est une excellente ressource pour toute personne participant aux discussions du GT.

Un GT est vraiment juste une liste de diffusion avec un peu de supervision et de facilitation. Vous "rejoignez" le GT en vous inscrivant à la liste de diffusion; toutes les listes de diffusion sont ouvertes à tous. Tout le monde peut publier sur une liste de diffusion du GT, bien que la plupart des listes exigent que les non-abonnés voient leurs publications modérées. Chaque groupe de travail a un ou deux (ou, rarement, trois) présidents.

Plus important encore, chaque GT a une charte que le GT est censé suivre. La charte énonce la portée des discussions du groupe de travail, ainsi que ses objectifs. La liste de diffusion du GT et les réunions en face-à-face sont censées se concentrer uniquement sur ce qui est dans la charte et ne pas s'égarer sur d'autres sujets "intéressants". Bien sûr, regarder un peu en dehors du cadre du GT est parfois utile, mais la grande majorité de la discussion devrait porter sur les sujets énumérés dans la charte. En fait, certaines chartes du GT précisent en fait ce que le GT ne fera pas, en particulier s'il y a eu des sujets attrayants mais nébuleux lors de la rédaction de la charte. La liste de toutes les chartes du GT rend la lecture intéressante pour les gens qui veulent savoir ce que les différents groupes de travail sont censés faire.

4.1 Présidents des groupes de travail

Le rôle des présidents des GT est décrit dans les BCP 11 et BCP 25.

En tant que gardiens de chats bénévoles, le premier travail d'un président est de déterminer les objectifs et les étapes du consensus du GT, en gardant la charte à jour. Ensuite, souvent avec l'aide des secrétaires des GT ou des éditeurs de documents, le président doit gérer les discussions du GT, à la fois sur la liste et en planifiant des réunions le cas échéant. Parfois, les discussions sont bloquées sur des points litigieux et le président peut avoir besoin d'orienter les gens vers une interaction productive, puis de déclarer quand un consensus approximatif a été atteint et que la discussion est terminée. Parfois, les présidents gèrent également les interactions avec les non-participants au GT ou l'IESG, en particulier lorsqu'un document du GT approche de la publication. Les présidents sont responsables de la qualité technique et non technique des résultats des GT. Comme vous pouvez l'imaginer compte tenu de la combinaison de demandes de secrétariat, de relations interpersonnelles et techniques, certains présidents de groupe de travail sont bien meilleurs dans leur travail que d'autres.

Il est conseillé aux présidents des GT de participer au déjeuner des présidents des GT en milieu de semaine pendant la réunion où les sujets spécifiques aux présidents sont présentés et discutés. Les diapositives des versions précédentes de cette session se trouvent dans le datatracker.

4.2 Faire avancer les choses dans un groupe de travail

Un fait qui déroute de nombreux nouveaux arrivants est que les réunions en face à face du GT sont beaucoup moins importantes dans l'IETF que dans la plupart des autres organisations. Toute décision prise lors d'une réunion en face à face doit également obtenir un consensus sur la liste de diffusion du GT. Il existe de nombreux exemples de décisions importantes prises lors des réunions du GT qui sont par la suite annulées sur la liste de diffusion, souvent parce qu'une personne qui n'a pas pu assister à la réunion a signalé un grave défaut dans la logique utilisée pour prendre la décision. Enfin, les réunions du GT ne sont pas des «séances de rédaction», comme c'est le cas dans certains autres organismes de normalisation: dans l'IETF, la rédaction se fait ailleurs.

Un autre aspect des groupes de travail qui déconcerte de nombreuses personnes est le fait qu'il n'y a pas de vote formel. La règle générale sur les sujets controversés est que le groupe de travail doit parvenir à un "consensus approximatif", ce qui signifie qu'une très grande majorité de ceux qui se soucient doivent être d'accord. La méthode exacte de détermination d'un consensus approximatif varie d'un groupe de travail à l'autre. Parfois, le consensus est déterminé en "fredonnant" - si vous êtes d'accord avec une proposition, vous fredonnez lorsque vous y êtes invité par le président. La plupart des questions "fredonnées" se divisent en deux parties: vous fredonnez à la première partie si vous êtes d'accord avec la proposition, ou vous fredonnez à la deuxième partie si vous n'êtes pas d'accord avec la proposition. Les nouveaux arrivants trouvent cela assez particulier, mais cela fonctionne. Il appartient au président de décider quand le groupe de travail est parvenu à un consensus approximatif.

L'absence de vote formel a entraîné des retards très longs pour certaines propositions, mais la plupart des participants à l'IETF qui ont été témoins d'un consensus approximatif après des débats acrimonieux estiment que les retards entraînent souvent de meilleurs protocoles. (Et, si vous y réfléchissez, comment pourriez-vous «voter» dans un groupe qui invite toutes les personnes intéressées à participer, et quand il est impossible de compter les participants?) Un consensus approximatif a été défini de plusieurs façons; une version simple est que cela signifie que les objections fermement tenues doivent être débattues jusqu'à ce que la plupart des gens soient convaincus que ces objections sont fausses.

Un problème connexe est que certaines personnes pensent que leurs propositions devraient être discutées au sein du GT même lorsque les présidents des GT ne le font pas. Par exemple, si le travail proposé ne fait pas vraiment partie de la charte, les présidents des GT peuvent restreindre la discussion de la proposition afin de garder le GT concentré sur le travail affrété. Les personnes qui pensent qu'un GT devrait aborder un sujet considéré comme hors charte par les présidents des GT peuvent faire part de leurs préoccupations au DA responsable; l'AD peut accepter d'ajuster la charte pour ajouter le sujet avec le groupe de travail, ou qu'il est déjà couvert dans la charte, ou que les présidents des GT sont corrects et que le participant devrait travailler sur la proposition en dehors du GT.

Lorsqu'un document du GT a été entièrement discuté, il passe généralement par le dernier appel du groupe de travail (souvent abrégé en "WGLC"). C'est, espérons-le, la dernière fois que le GT règle les problèmes. Parfois, le WGLC soulèvera tellement de problèmes qu'il y aura un deuxième WGLC après que les révisions auront été incorporées. Il n'y a pas de règles formelles sur la façon dont un WGLC se produit, ou même si un WGLC est nécessaire: c'est aux présidents du WG.

Une autre méthode adoptée par certains groupes de travail consiste à avoir un "secrétaire" de groupe de travail pour gérer le jonglage des documents et les modifications. Le secrétaire peut exécuter le suivi des problèmes s'il en existe un, ou peut simplement être chargé de veiller à ce que toutes les décisions prises sur la liste de diffusion soient reflétées dans les nouvelles versions des documents.

Lorsqu'un GT a rempli sa charte, il est censé cesser ses activités. (La plupart des listes de diffusion du groupe de travail continuent après la fermeture d'un groupe de travail, discutant toujours des mêmes sujets que le groupe de travail.) Dans l'IETF, c'est une marque de succès que le groupe de travail ferme parce qu'il a rempli sa charte. C'est l'un des aspects de l'IETF que les nouveaux arrivants qui ont de l'expérience avec d'autres organismes de normalisation ont du mal à comprendre. Cependant, certains présidents de GT n'arrivent jamais à terminer leur GT, ou continuent d'ajouter de nouvelles tâches à la charte de sorte que le groupe de travail s'éternise pendant de nombreuses années (ou, dans certains cas, des décennies). La production de ces GT vieillissants n'est souvent pas aussi utile que les produits précédents, et les résultats désordonnés sont parfois attribués à ce que l'on appelle le "syndrome dégénératif du groupe de travail".

4.3 Documents du groupe de travail

Il existe une distinction officielle entre les projets du GT et les projets individuels, mais dans la pratique, il n'y a parfois pas beaucoup de différence de procédure. Par exemple, de nombreuses listes de diffusion du GT discutent également de projets individuels (à la discrétion du président du GT). Les présidents des groupes de travail prennent les décisions concernant les projets qui deviendront des projets du groupe de travail et qui seront les auteurs ou les éditeurs de ces projets, généralement sur la base de consultations avec le groupe de travail, et parfois avec leur directeur régional. Ce processus peut être délicat dans les cas où de nombreuses personnes veulent être un rédacteur, mais peut être tout aussi délicat lorsque personne ne veut être rédacteur mais que le GT est conçu pour effectuer un travail spécifique. Les procédures pour les brouillons Internet sont traitées plus en détail plus loin dans ce document.

Certains groupes de travail ont des documents complexes ou un ensemble complexe de documents (ou même les deux). Éliminer tous les bogues d'un ou plusieurs documents complexes est une tâche intimidante. Afin d'aider à résoudre ce problème, certains groupes de travail utilisent des «suiveurs de problèmes», qui sont des listes en ligne des problèmes ouverts avec les documents, l'état du problème, les correctifs proposés, etc. L'utilisation d'un outil de suivi des problèmes permet non seulement au GT de ne pas oublier de faire quelque chose d'important, mais aussi lorsque quelqu'un pose une question plus tard sur les raisons pour lesquelles quelque chose a été fait d'une manière particulière.

Pour les documents des groupes de travail, l'éditeur de documents sert au gré du président du GT. Il existe souvent plus d'un éditeur pour les documents du groupe de travail, en particulier pour les documents complexes. L'éditeur de document est chargé de s'assurer que le contenu du document reflète fidèlement les décisions du groupe de travail, en particulier lors de la création d'un nouveau protocole ou d'une nouvelle extension; Lorsqu'un éditeur de documents ne suit pas le consensus du GT, les présidents des GT seront plus énergiques pour obtenir des changements qui correspondent au consensus ou remplaceront l'éditeur de documents par une personne plus sensible au GT. Alors qu'un document du groupe de travail progresse, les participants suggèrent des changements sur la liste de diffusion du groupe de travail; les rédacteurs devraient suivre la discussion et apporter des modifications en cas d'accord.

Si un participant apporte des contributions importantes, l'éditeur ou le président du document peut inviter le participant à devenir co-auteur ou co-éditeur, bien qu'un tel ajout doive être approuvé par les présidents des GT. Parfois, un groupe de travail examinera plusieurs alternatives avant de sélectionner un projet Internet particulier comme document de groupe de travail. Un groupe de travail prendra souvent des idées de plusieurs des alternatives pour créer un seul document de groupe de travail; dans un tel cas, le président détermine qui sera inscrit comme auteur sur la page de titre et qui sera reconnu comme contributeur dans le corps du document.

Lorsqu'un document du GT est prêt à progresser au-delà du GT, les présidents des GT désigneront un "berger" pour prendre en charge le processus final. Le rôle du berger de document est décrit dans la RFC 4858 .

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

La chose la plus importante que tout le monde (nouveaux arrivants et experts chevronnés) devrait faire avant de venir à une réunion en face-à-face est de lire les brouillons Internet et les RFC à l'avance. Les réunions des GT ne sont explicitement pas destinées à l'éducation: elles visent à développer les documents du groupe. Même si vous n'avez pas l'intention de dire quoi que ce soit au cours de la réunion, vous devez lire, ou du moins parcourir les documents du groupe avant de participer afin de comprendre ce qui se dit.

C'est aux présidents des GT de fixer l'ordre du jour de la réunion, généralement quelques semaines à l'avance. Si vous voulez que quelque chose soit discuté lors de la réunion, assurez-vous d'en informer le président. Les ordres du jour de toutes les réunions du GT sont disponibles à l'avance sur le site Web de l'IETF, mais certains présidents de GT sont laxistes (sinon totalement négligents) à propos de leur remise.

Le Secrétariat ne planifie les réunions du GT que quelques semaines à l'avance, et le calendrier change souvent aussi peu qu'une semaine avant le premier jour. Si vous venez seulement pour une réunion du GT, vous pouvez avoir du mal à réserver votre vol avec si peu de préavis, en particulier si la réunion du groupe de travail change d'horaire. Assurez-vous de suivre l'agenda actuel afin de pouvoir planifier des vols et des hôtels. Mais, en fin de compte, vous ne devriez probablement pas venir pour une seule réunion du GT. Il est probable que vos connaissances puissent être utiles dans quelques groupes de travail, en supposant que vous avez lu les ébauches et les RFC pour ces groupes. Le travail dans l'IETF est souvent réciproque, contribue positivement au travail des autres et vous êtes plus susceptible de recevoir des commentaires et des retours sur votre travail.

Si vous êtes à l'ordre du jour d'une réunion en personne, vous devriez probablement venir avec quelques diapositives préparées. Mais ne venez pas avec un tutoriel; les gens sont censés lire les ébauches à l'avance. Des projecteurs pour présentations sur ordinateur portable sont disponibles dans toutes les salles de réunion.

Et voici une astuce pour vos diapositives en GT ou en présentations plénières: ne mettez pas le logo de votre entreprise sur chacun, même si c'est une pratique courante en dehors de l'IETF. L'IETF fronce les sourcils sur ce type de publicité d'entreprise (à l'exception du sponsor de la réunion dans la présentation plénière), et la plupart des présentateurs ne mettent même pas leur logo sur leur diapositive d'ouverture. L'IETF concerne le contenu technique, pas le boosterisme des entreprises. Les diapositives sont souvent en noir et blanc uni pour plus de lisibilité, avec une couleur utilisée uniquement lorsqu'elle ajoute vraiment de la clarté. Encore une fois, le contenu est la partie la plus importante des diapositives, pas la façon dont il est présenté.

Une chose que vous pourriez trouver utile, et peut-être même divertissante, pendant les sessions du groupe de travail est de suivre le commentaire en cours sur la salle Jabber associée à ce groupe de travail. Le commentaire en cours est souvent utilisé comme base pour le procès-verbal de la réunion, mais il peut également inclure des blagues, des soupirs et d'autres bavardages superflus. Jabber est une technologie XML en streaming gratuite principalement utilisée pour la messagerie instantanée. Vous pouvez trouver des pointeurs vers les clients Jabber pour de nombreuses plates-formes à [15] . Les salons de discussion Jabber portent le nom du groupe de travail suivi de "@ jabber.ietf.org". Ces salles sont, en fait, disponibles toute l'année, pas seulement pendant les réunions de l'IETF, et certaines sont utilisées par les participants actifs du groupe de travail pendant l'élaboration du protocole.

4.5 Listes de diffusion du groupe de travail

Comme nous l'avons mentionné précédemment, les listes de diffusion d'annonces et de discussions de l'IETF sont les listes de diffusion centrales pour les activités de l'IETF. Cependant, il existe de nombreuses autres listes de diffusion liées au travail de l'IETF. Par exemple, chaque groupe de travail a sa propre liste de discussion. En outre, certains débats techniques à long terme ont été déplacés de la liste de l'IETF vers des listes créées spécifiquement pour ces sujets. Il est fortement recommandé de suivre les discussions sur les listes de diffusion des groupes de travail auxquels vous souhaitez participer. Plus il y a de travail sur les listes de diffusion, moins il y aura de travail à faire lors de la réunion, ce qui laisse du temps pour la pollinisation croisée (c.-à-d. Assister à des groupes de travail en dehors de son domaine d'intérêt principal afin d'élargir sa perspective).

Les listes de diffusion fournissent également un forum pour ceux qui souhaitent suivre ou contribuer aux efforts des groupes de travail, mais ne peuvent pas assister aux réunions de l'IETF. C'est pourquoi les procédures de l'IETF exigent que toutes les décisions soient confirmées "sur la liste" et vous entendrez souvent un président du GT dire "Prenons-le sur la liste" pour clore une discussion.

De nombreuses listes de discussion de l'IETF utilisent Mailman ou un autre gestionnaire de listes, Majordomo. Ils ont généralement une adresse "demande" qui gère les détails administratifs de l'adhésion et de la sortie de la liste. (Voir la section 2.3 pour plus d'informations sur mailman.) Il est généralement mal vu quand un tel administrateur apparaît sur la liste de diffusion de discussion.

Les listes de discussion de l'IETF sont archivées. Autrement dit, tous les messages envoyés à la liste sont automatiquement stockés et rendus accessibles. Beaucoup de ces archives sont répertoriées en ligne. Si vous ne trouvez pas la liste que vous recherchez, envoyez un message à l'adresse "-demande" de la liste (pas à la liste elle-même!). Les listes de chartes du groupe de travail sont une source utile. Il existe une liste d'anciens GT conclus.

Certaines listes de groupes de travail appliquent des limites de taille aux messages, en particulier pour éviter que des documents ou des présentations volumineux arrivent dans la boîte aux lettres de chacun. Il convient de se rappeler que bien que la plupart des participants n'en aient pas, tous n'ont pas de connexions à large bande (ceux qui se trouvent dans des endroits éloignés peuvent toujours compter sur une bande passante plus faible, une connexion plus lente lorsque Internet leur est disponible), donc les messages plus courts sont grandement appréciés. Les documents peuvent être publiés sous forme de brouillons Internet; le matériel de présentation peut être affiché sur un site Web contrôlé par l'expéditeur ou envoyé personnellement aux personnes qui le demandent. Certains groupes de travail ont mis en place des sites spéciaux pour stocker ces gros documents afin que les expéditeurs puissent y publier d'abord, puis simplement envoyer à la liste l'URL du document.

4.6 Réunions du groupe de travail intérimaire

Les groupes de travail tiennent parfois des réunions intérimaires entre les IETF. Les réunions intérimaires ne remplacent cependant pas les réunions de l'IETF - un groupe ne peut pas décider de sauter une réunion dans un endroit qu'il n'aime pas et de se réunir à Cancun (ou même dans un endroit banal) trois semaines plus tard, par exemple. Les réunions intérimaires doivent être approuvées par le CN et doivent être annoncées au moins un mois à l'avance. L'emplacement et le calendrier doivent permettre un accès équitable à tous les participants. Comme pour les réunions régulières de l'IETF, quelqu'un doit prendre des notes et le groupe doit prendre part. Les décisions provisoirement prises lors d'une réunion intérimaire du GT doivent encore être ratifiées sur la liste de diffusion.

Certains groupes de travail organisent des «réunions intérimaires virtuelles» qui ont lieu via les outils collaboratifs en ligne ou par téléphone au lieu de face à face. Les réunions intermédiaires virtuelles peuvent être utiles pour amener les groupes de travail à prêter attention à leur travail entre les réunions en face à face régulières de l'IETF, accélérer le travail et avoir un coût de participation beaucoup plus faible que les réunions intermédiaires en face à face. Les réunions virtuelles intermédiaires ont les mêmes exigences de rapport que les réunions virtuelles en face à face.

L'IESG a des règles pour la notification à l'avance de l'heure et du lieu des réunions de groupe de travail intérimaires, ainsi que pour rendre compte des résultats des réunions. Le but de ces règles est de rendre les réunions intérimaires accessibles au plus grand nombre possible de membres du Groupe de travail et de maintenir la transparence du processus du Groupe de travail.

5. BOFs

Pour former un groupe de travail, vous avez besoin d'une charte et d'une personne capable de présider. Pour obtenir ces choses, vous devez intéresser les gens afin qu'ils puissent aider à concentrer la charte et convaincre un directeur régional que le projet en vaut la peine. Une réunion en face à face est utile pour cela. En fait, très peu de groupes de travail sont lancés par un directeur régional; la plupart commencent après un BOF en face-à-face car les participants ont manifesté leur intérêt pour le sujet.

Une réunion Birds of a Feather (BOF) doit être approuvée par le directeur régional de la zone concernée avant de pouvoir être programmée. Si vous pensez que vous avez vraiment besoin d'un nouveau groupe de travail, contactez un AD de manière informelle avec votre proposition et voyez ce qu'il en pense. L'étape suivante consiste à demander un créneau de réunion lors de la prochaine réunion en personne. Bien sûr, vous n'avez pas besoin d'attendre cette réunion pour faire un travail, comme la mise en place d'une liste de diffusion et commencer à discuter d'une charte.

Les réunions du BOF ont un ton très différent de celui des réunions du GT. Le but d'un BOF est de s'assurer qu'une bonne charte avec de bons jalons peut être créée et qu'il y a suffisamment de personnes prêtes à faire le travail nécessaire pour créer des normes. Certains BOF ont déjà des projets Internet en cours, tandis que d'autres partent de zéro.

Un avantage d'avoir un projet avant le BOF est d'aider à concentrer la discussion. D'un autre côté, avoir un projet pourrait avoir tendance à limiter ce que les autres membres de la BOF veulent faire dans la charte. Il est important de se rappeler que la plupart des BOF sont organisés afin d'obtenir un soutien pour un éventuel groupe de travail, et non pour obtenir un soutien pour un document particulier.

De nombreux BOF ne se transforment pas en GT pour diverses raisons. Un problème commun est que trop peu de personnes peuvent se mettre d'accord sur un objectif pour le travail. Une autre raison typique est que le travail ne deviendrait pas une norme - si, par exemple, les auteurs de documents ne veulent pas vraiment abandonner le contrôle des modifications à un groupe de travail. (Nous discuterons du contrôle des modifications plus loin dans ce document.) Seules deux réunions d'un BOF peuvent être programmées sur un sujet particulier; soit un groupe de travail doit se former, soit le sujet doit être supprimé.

6. RFC et Internet-Brouillons

Cette section traite des brouillons Internet et des RFC dans le flux IETF, c'est-à-dire qu'elle décrit comment les documents sont produits et avancés au sein de l'IETF. Pour une brève note sur les autres flux RFC, voir la section 2.2.5.

Si vous êtes un nouveau participant à l'IETF et que vous recherchez un RFC ou un brouillon Internet particulier, accédez à l'IETF Datatracker. Ce site dispose de nombreuses capacités de recherche et peut vous aider à trouver le bon document et les informations sur son état, ses dépendances, ses mises à jour potentielles et d'autres informations. Un autre point d'entrée pour la recherche et la navigation dans les RFC est EveryRFC de Mark Nottingham.

6.1 Obtenir un RFC publié

L'une des questions les plus courantes que les IETFers chevronnés entendent de la part des nouveaux arrivants est: "Comment puis-je faire publier une norme IETF?" Une bien meilleure question est: "Dois-je écrire une norme IETF?" car la réponse n'est pas toujours «oui». Si vous décidez d'essayer d'écrire un document qui devient une norme IETF, sachez que le processus global peut être ardu, même si les étapes individuelles sont assez simples. Beaucoup de gens traversent le processus indemne, cependant, et il y a beaucoup de conseils écrits qui aident les auteurs à émerger avec leur ego plus ou moins intact.

L'une des premières choses que vous devez décider est de savoir si vous voulez que votre document soit examiné dans un groupe de travail, ou si vous voulez qu'il soit considéré comme une soumission individuelle (c'est-à-dire non-WG) à l'IETF. Même si la plupart des normes de l'IETF proviennent de groupes de travail, certains sont des efforts individuels: il pourrait ne pas y avoir de groupe de travail approprié, ou un groupe de travail potentiellement approprié pourrait être occupé à d'autres travaux pour examiner votre idée.

Chaque norme IETF est publiée en tant que RFC ("Request for Comments"), et chaque RFC commence comme un Internet-Draft (souvent appelé "ID" ou simplement "draft"). Les étapes de base pour obtenir quelque chose publié en tant que norme IETF sont les suivantes:

  • Publiez le document en tant que brouillon Internet. Recevez des commentaires sur le projet. Modifiez votre brouillon en fonction des commentaires. Répétez les étapes 1 à 3 plusieurs fois. Demandez à un directeur régional de présenter le projet à l'IESG (s'il s'agit d'une soumission individuelle). Si le projet est un produit officiel du groupe de travail, le président du GT demande à la DA de le porter à l'IESG. Si le directeur régional accepte la soumission, il procédera à son propre examen initial et demandera peut-être des mises à jour avant de l'avancer. Obtenez des avis des membres plus larges de l'IETF. En particulier, certains des domaines de l'IETF ont formé des équipes d'examen pour examiner les projets qui sont prêts à être soumis à l'IESG. Discutez des préoccupations avec les membres de l'IESG. Leurs préoccupations peuvent être résolues par une réponse simple, ou ils peuvent nécessiter des ajouts ou des modifications au document. Attendez que le document soit publié par l'éditeur RFC. $


Une explication beaucoup plus complète de ces étapes est contenue dans le BCP 9, "The Internet Standards Process". Ceux qui rédigent des brouillons qu'ils espèrent devenir des normes IETF doivent lire le BCP 9 afin de pouvoir suivre le chemin de leur document tout au long du processus. Vous pouvez suivre la progression sur l'IETF Datatracker. BCP 9 (et divers autres documents qui le mettent à jour) aborde en détail un sujet qui est très souvent mal compris, même par les participants chevronnés de l'IETF: différents types de RFC passent par différents processus et ont des classements différents. Il existe six types de RFC:

  • Normes proposées
  • Normes Internet (parfois appelées «normes complètes»)
  • Documents sur les meilleures pratiques actuelles (PCA)
  • Documents d'information
  • Documents expérimentaux
  • Documents historiques

Seuls les deux premiers, proposés et complets, sont des normes au sein de l'IETF. Un bon résumé de ceci peut être trouvé dans le bien intitulé RFC 1796 , "Pas tous les RFC sont des normes".

Il existe également deux sous-séries de RFC, appelées BCP et STD. Les documents sur les meilleures pratiques actuelles décrivent l'application de diverses technologies sur Internet et sont également couramment utilisés pour documenter les nombreuses parties du processus de l'IETF. Les sous-séries de FYI sont composées de "documents d'information" au sens de l'énumération ci-dessus, avec un marquage spécial appliqué. (Il y avait aussi une sous-série RFC "Pour votre information" qui a été créée pour documenter des aperçus et des sujets qui sont introductifs ou qui plaisent à un large public; cependant, cette série a été officiellement clôturée.)

La sous-série STD RFC a été créée pour identifier les RFC qui spécifient en fait les normes Internet. Certaines MST sont en fait des ensembles de plusieurs RFC, et la désignation "standard" s'applique à l'ensemble des documents.

6.2 Lâcher prise avec grâce

La plus grande raison pour laquelle certaines personnes ne veulent pas que leurs documents soient mis sur la voie des normes IETF est qu'elles doivent abandonner le contrôle des modifications du protocole. Autrement dit, dès que vous proposez que votre protocole devienne une norme IETF, vous devez entièrement abandonner le contrôle du protocole. S'il y a accord général, des parties du protocole peuvent être complètement modifiées, des sections entières peuvent être arrachées, de nouvelles choses peuvent être ajoutées et le nom peut être changé.

Certains auteurs trouvent qu'il est très difficile de renoncer au contrôle de leur protocole pour animaux de compagnie. Si vous êtes une de ces personnes, la poursuite d'une norme IETF peut ne pas être une voie fructueuse. D'un autre côté, si votre objectif est le meilleur standard possible avec l'implémentation la plus large, alors vous pourriez trouver le processus IETF à votre goût.

Par ailleurs, le contrôle des modifications sur les normes Internet ne se termine pas lorsque le protocole est mis sur la voie des normes. Le protocole lui-même peut être modifié ultérieurement pour un certain nombre de raisons, la plus courante étant que les implémenteurs découvrent un problème lorsqu'ils implémentent la norme. Ces modifications ultérieures sont également sous le contrôle de l'IETF, et non des éditeurs du document de normes.

Les normes IETF existent pour que les gens les utilisent pour écrire des programmes Internet qui interagissent. Ils n'existent pas pour documenter les idées (peut-être merveilleuses) de leurs auteurs, pas plus qu'ils n'existent pour qu'une entreprise puisse dire: «Nous avons une norme IETF». Si un RFC de voie normalisée n'a qu'une seule implémentation (alors qu'il en faut deux pour avancer sur la voie normative), c'était probablement une erreur de le mettre sur la voie normative en premier lieu.

Notez que les nouveaux auteurs ne peuvent pas prendre le document de quelqu'un d'autre et le faire passer pour le leur; voir BCP 78, section 5.6, point a).

6.3 Internet-Drafts

Tout d'abord. Chaque document qui se retrouve dans le référentiel RFC commence sa vie en tant que brouillon Internet. Les brouillons Internet sont des documents provisoires - ils sont destinés aux lecteurs de commenter, afin que les auteurs puissent réfléchir à ces commentaires et décider lesquels incorporer dans le projet. Afin de rappeler aux gens leur caractère provisoire, les brouillons Internet sont automatiquement supprimés des répertoires en ligne actifs après six mois. Ce ne sont certainement pas des normes. Comme le dit BCP 9:

"Un projet Internet n'est PAS un moyen de" publier "une spécification; les spécifications sont publiées par le biais du mécanisme RFC. Les projets Internet n'ont pas de statut officiel et peuvent être modifiés ou supprimés à tout moment. En aucun cas, un projet Internet doit être référencé par un document, un rapport ou une demande de proposition, et un fournisseur ne doit pas non plus prétendre être conforme à un projet Internet ".

Lorsque vous soumettez un projet Internet, vous accordez certains droits de publication à l'IETF. C'est ainsi que votre Internet-Draft est librement accessible à tous ceux qui veulent le lire et le commenter. Les droits que vous accordez et ne donnez pas à l'IETF sont décrits dans le BCP 78, "Droits de l'IETF sur les contributions".

Il existe un outil de vérification très utile à [16] . L'utilisation de cet outil avant de remettre un brouillon Internet aidera à empêcher le brouillon d'être rejeté en raison d'erreurs de forme et de formatage.

Un ID doit avoir approximativement le même format qu'un RFC. Contrairement à la croyance de beaucoup de gens, un ID n'a pas besoin de ressembler exactement à un RFC, mais si vous pouvez utiliser les mêmes procédures de formatage que celles utilisées par l'éditeur RFC lorsque vous créez vos I-D, cela simplifiera le travail de l'éditeur RFC lorsque votre brouillon est publié en tant que RFC. La RFC 2223 , «Instructions aux auteurs RFC», décrit le format de soumission. Il existe également un outil appelé xml2rfc, qui prend le texte au format XML et le transforme en un brouillon Internet valide, vous pouvez également utiliser un outil appelé kramdown, qui prend le texte au format markdown et le transforme en un brouillon Internet valide.

Un projet Internet peut être un projet de groupe de travail ou une soumission individuelle. Les ébauches des groupes de travail sont généralement examinées par le groupe de travail avant d'être acceptées en tant que point du GT, bien que les présidents aient le dernier mot.

Si vous souhaitez vérifier l'état d'un brouillon particulier, ou ne vous souvenez pas de son nom exact, ou si vous souhaitez savoir sur quels brouillons un groupe de travail travaille, deux outils pratiques sont disponibles. L '"interface de base de données Internet-Drafts", sur https://datatracker.ietf.org/doc , vous permet de rechercher un brouillon par auteur, groupe de travail, date ou nom de fichier. Cela est particulièrement utile pour les auteurs qui souhaitent suivre l'avancement de leur projet au fur et à mesure qu'il progresse dans le processus de publication.

Il existe des règles informelles pour la dénomination Internet-Draft qui ont évolué au fil des ans. Internet-brouillons qui révisent les RFC existants ont souvent des projets de noms avec "bis" en eux, ce qui signifie "à nouveau" ou "deux fois"; par exemple, un brouillon pourrait être appelé "draft-quelqu'un-rfc2345bis-00.txt".

6.3.1 Lecture recommandée pour les écrivains

Avant de créer le premier brouillon de votre brouillon Internet, vous devez lire quatre documents:

   Plus important que d'expliquer simplement le formatage, la RFC 2223 explique également ce qui doit être dans un brouillon Internet avant qu'il ne devienne un RFC. Ce document décrit toutes les sections et les avis qui devront figurer dans votre document, et il est bon de les avoir dès le début afin que les lecteurs ne soient pas surpris lorsque vous les mettez dans des versions ultérieures.   BCP 22, "Guide pour les rédacteurs de normes Internet", fournit des conseils qui vous aideront à rédiger une norme qui mène à l'interopérabilité. Par exemple, il explique comment choisir le bon nombre d'options de protocole, comment réagir à un comportement hors spécifications et comment afficher des diagrammes d'état.   Les Lignes directrices en ligne pour les auteurs de projets Internet contiennent des informations à jour sur le processus de conversion des projets Internet, ainsi que les informations les plus récentes qui doivent être incluses dans chaque projet Internet.   Lorsque vous pensez que vous avez terminé le processus de brouillon et êtes prêt à demander que le brouillon devienne un RFC, vous devriez certainement lire la Liste de contrôle pour les brouillons Internet (I-D) soumis pour publication RFC, une liste des problèmes courants qui ont été connus. pour arrêter les documents dans l'IESG. En fait, vous devriez probablement lire ce document bien avant d'avoir terminé, afin de ne pas avoir à faire un tas de changements de dernière minute. $ 


Il existe également des guides spécifiques aux domaines importants à couvrir dans votre brouillon, tels que les considérations de sécurité et même des modèles de brouillons qui se produisent fréquemment, tels que les modules YANG et les MIB. Les modèles et scripts de Martin Thomson pourraient vous aider à rédiger plus facilement un projet Internet et à automatiser le processus de soumission.

En outre, vous devriez visiter les pages Web des outils de l'IETF, où vous trouverez des pointeurs vers d'autres outils qui automatiseront une partie de votre travail pour l'IETF.

6.3.2 Noms de fichiers et autres sujets

Lorsque vous êtes prêt à rendre votre brouillon Internet, vous le soumettez à [17] . Les instructions sur cette page Web vous guideront à travers les étapes nécessaires, et il y a aussi une adresse e-mail au cas où vous auriez besoin d'une aide personnalisée.

Lorsque vous soumettez la première version du brouillon, vous indiquez également à l'administrateur du brouillon le nom de fichier proposé pour le brouillon. Si le projet est un produit officiel du groupe de travail, le nom commencera par "draft-ietf-" suivi de la désignation du groupe de travail, suivi d'un ou deux mots descriptifs, suivis de "00.txt".

Par exemple, un brouillon dans le groupe de travail S / MIME sur la création de clés peut être nommé "draft-ietf-smime-keying-00.txt". Si ce n'est pas le produit d'un groupe de travail, le nom commencera par "draft-" mais ne sera pas suivi par "ietf-". Souvent, le nom de famille de l'un des auteurs (ou d'un autre identifiant) est suivi d'un ou deux mots descriptifs, suivis de "00.txt". Par exemple, un brouillon qu'une personne nommée Smith a écrit pourrait être nommé "draft-smith-keying-00.txt". Si un projet est une soumission individuelle mais concerne un groupe de travail particulier, les auteurs suivent parfois leur nom avec le nom du groupe de travail, tel que "draft-smith-smime-keying-00.txt". Si vous suivez les directives de dénomination données dans [18] , il y a de fortes chances que votre nom de fichier suggéré soit correct.

Après la première édition d'un brouillon, le numéro du nom de fichier est incrémenté; par exemple, la deuxième édition du brouillon S / MIME nommé ci-dessus serait "draft-ietf-smime-keying-01.txt". Notez qu'il existe des cas où le nom de fichier change après une ou plusieurs versions, par exemple lorsqu'un effort personnel est déployé dans un groupe de travail; lorsqu'un brouillon a son nom de fichier changé, le nombre revient à -00. Les présidents des GT informeront l'administrateur d'Internet-Drafts du nom précédent du brouillon lorsqu'un tel changement de nom se produit afin que les bases de données puissent être tenues à jour.

6.4 RFC de suivi des normes

La procédure de création et d'avancement d'une norme est décrite dans le BCP 9. Après qu'un projet Internet a été suffisamment discuté et qu'il y ait un consensus approximatif sur ce qu'il dit serait une norme utile, il est présenté à l'IESG pour examen. Si le projet est un projet officiel du GT, le président du GT l'envoie au directeur régional approprié. Si l'ébauche est une soumission individuelle, l'auteur ou l'éditeur de l'ébauche la soumet au directeur régional approprié. Le BCP 9 décrit également le processus d'appel pour les personnes qui estiment qu'un président de groupe de travail, un AD ou l'IESG a pris la mauvaise décision en envisageant la création ou l'avancement d'une norme.

Une fois l'ID soumis à l'IESG, l'IESG annonce un dernier appel à l'échelle de l'IETF (souvent abrégé en "LC"). Cela permet d'attirer l'attention des personnes qui ne suivaient pas la progression du projet et peut parfois entraîner d'autres modifications du projet. C'est aussi un moment où les membres du GT qui sentent qu'ils n'ont pas été entendus peuvent faire leurs commentaires à tout le monde. Le dernier appel de l'IETF est d'au moins deux semaines pour les projets émanant des groupes de travail et de quatre semaines pour les soumissions individuelles.

Le but de l'IETF Last Call est d'obtenir une discussion à l'échelle de la communauté sur les documents avant que l'IESG les examine. Notez le mot «discussion» ici. Il est généralement considéré comme une mauvaise forme d'envoyer des commentaires de dernier appel de l'IETF sur des documents que vous n'avez pas lus, ou d'envoyer des commentaires mais ne pas être prêt à discuter de vos opinions. Le dernier appel de l'IETF n'est pas un vote, et les campagnes visant à amener les gens à envoyer un soutien ou une opposition à un document se retournent généralement. Cela dit, les commentaires du dernier appel de l'IETF provenant de personnes qui viennent de lire le document pour la première fois peuvent révéler des problèmes que les habitués de l'IETF et du GT peuvent avoir complètement manqués, c'est pourquoi la discussion est ouverte à tous.

Si l'IESG approuve le projet de devenir un RFC de suivi des normes, il demande à l'éditeur du RFC de le publier en tant que norme proposée. Quelques choses se produisent généralement à ce stade. Tout d'abord, il est courant de constater que certaines des spécifications de la norme doivent être reformulées parce qu'un implémenteur pensait qu'elles signifiaient une chose tandis qu'un autre implémenteur pensait qu'elles signifiaient autre chose. Une autre occurrence courante est qu'aucune des implémentations n'a réellement essayé d'implémenter quelques-unes des fonctionnalités de la norme; ces fonctionnalités sont supprimées non seulement parce que personne ne les a testées, mais aussi parce qu'elles n'étaient pas nécessaires.

Ne soyez pas surpris si une norme particulière ne passe pas de la norme proposée à la norme Internet. Pour devenir une norme Internet, un RFC doit avoir plusieurs implémentations interopérables et les fonctionnalités inutilisées de la norme proposée doivent être supprimées; le BCP 9 contient des exigences supplémentaires. La plupart des normes couramment utilisées sont des normes proposées et ne progressent jamais. Cela peut être dû au fait que personne n'a pris le temps d'essayer de les faire accéder à Internet Standard, ou que certaines des références normatives dans la norme sont toujours à la norme proposée, ou il se peut que tout le monde ait trouvé des choses plus importantes à faire.

6.4.1 Dire les choses telles qu'elles sont - Utiliser MUST et SHOULD et MAY

Écrire des spécifications qui sont implémentées comme vous le souhaitez est un peu un art. Vous pouvez garder la spécification très courte, avec juste une liste d'exigences, mais cela tend à amener les implémenteurs à prendre trop de latitude. Si vous rendez plutôt la spécification très verbeuse avec beaucoup de suggestions, les implémenteurs ont tendance à manquer les exigences (et sont souvent en désaccord avec vos suggestions de toute façon). Une spécification optimale se situe quelque part entre les deux.

Une façon de rendre plus probable que les développeurs créeront des implémentations interopérables de normes est d'être clair sur ce qui est obligatoire dans une spécification. Les premiers RFC utilisaient toutes sortes d'expressions pour expliquer ce qui était nécessaire, de sorte que les implémenteurs ne savaient pas toujours quelles parties étaient des suggestions et quelles étaient les exigences. En conséquence, les rédacteurs de normes de l'IETF ont généralement accepté de limiter leur formulation à quelques mots spécifiques avec quelques significations spécifiques.

La norme STD 3, "Conditions requises pour les hôtes Internet - Application et support", écrite en 1989, contenait une courte liste de mots qui semblaient utiles, à savoir "doit", "devrait" et "peut". Ces définitions ont été mises à jour et affinées dans le BCP 14, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", qui est largement référencé dans les normes Internet actuelles. BCP 14 définit également spécifiquement "ne doit pas" et "ne devrait pas", et il énumère quelques synonymes pour les mots définis.

Dans une norme, afin d'indiquer clairement que vous utilisez les définitions du BCP 14, vous devez faire deux choses. Tout d'abord, référez-vous au BCP 14 (bien que la plupart des gens l'appellent RFC 2119 , car c'est ce que le BCP 14 vous dit de faire), afin que le lecteur sache comment vous définissez vos mots. Deuxièmement, vous devez indiquer quelles instances des mots que vous utilisez proviennent de BCP 14. La pratique acceptée pour cela est de mettre les mots en majuscule. C'est pourquoi vous voyez "DOIT" et "DEVRAIT" capitalisé dans les normes IETF. La RFC 8174 est une référence utile pour déterminer ce qui doit être capitalisé.

BCP 14 comprend deux courts documents, et il devrait être lu par tous ceux qui lisent ou écrivent les normes IETF. Bien que les définitions de «doivent» et «ne doivent pas» soient assez claires, les définitions de «devraient» et «ne devraient pas» suscitent beaucoup de discussions dans de nombreux groupes de travail. Lors de l'examen d'un projet Internet, la question est souvent posée: "Cette phrase devrait-elle contenir un MUST ou un DEVRAIT?" C'est, en effet, une très bonne question, car les spécifications ne devraient pas avoir de MUST gratuits, mais ne devraient pas non plus avoir de DOIT où un MUST est nécessaire pour l'interopérabilité. Cela va au cœur de la question de la sur-spécification et de la sous-spécification des exigences dans les normes.

6.4.2 Références normatives dans les normes

Un aspect de l'écriture des normes IETF qui fait voyager de nombreux nouveaux arrivants (et pas mal de gens de longue date de l'IETF) est la règle sur la façon de faire des "références normatives" à des documents non-IETF ou à d'autres RFC dans une norme. Une référence normative est une référence à un document qui doit être suivi pour mettre en œuvre la norme. Une référence non normative (parfois appelée "référence informative") est une référence utile à un implémenteur mais non nécessaire.

Une norme IETF peut faire une référence normative à tout autre RFC de suivi de normes qui est au même niveau de normes ou supérieur, ou à toute "norme ouverte" qui a été développée en dehors de l'IETF. La règle du "même niveau ou supérieur" signifie qu'avant qu'une norme puisse passer de Proposé à Brouillon, tous les RFC pour lesquels il existe une référence normative doivent également être à la norme Brouillon ou Internet. Cette règle est décrite dans BCP 97. Cette règle donne aux implémenteurs l'assurance que tout dans une norme Internet est assez stable, même les éléments référencés en dehors de la norme. Cela peut également retarder la publication du projet ou de la norme Internet de plusieurs mois (parfois même des années) pendant que les autres documents se rattrapent.

Il n'y a pas de règle stricte sur ce qu'est une "norme ouverte", mais cela signifie généralement une norme stable dont tout le monde peut obtenir une copie (bien qu'ils puissent avoir à payer pour cela) et qui a été établie par un organisme généralement reconnu. groupe de normes. Si la norme externe change, vous devez faire référence à l'instanciation particulière de cette norme dans votre spécification, comme avec une désignation de la date de la norme. Certains organismes de normalisation externes ne rendent pas les anciennes normes disponibles, ce qui est un problème pour les normes IETF qui doivent être utilisées à l'avenir. En cas de doute, un projet d'auteur doit demander au président du GT ou au directeur régional approprié si une norme externe particulière peut être utilisée dans une norme IETF.

6.4.3 Considérations IANA

De plus en plus de normes IETF nécessitent l'enregistrement de divers paramètres de protocole, tels que des options nommées dans le protocole. Comme nous l'avons noté dans la section 2.2.4, le registre principal pour toutes les normes IETF est depuis longtemps l'IANA. En raison des types de registres importants et divers que les normes exigent, l'IANA doit avoir des informations spécifiques sur la façon d'enregistrer les paramètres, ce qu'il ne faut pas enregistrer, qui (le cas échéant) décidera de ce qui doit être enregistré, etc.

Toute personne écrivant une norme Internet qui peut avoir besoin d'un nouveau registre IANA ou de nouvelles valeurs dans un registre IANA actuel doit lire BCP 26, "Directives pour la rédaction d'une section de considérations IANA dans les RFC", qui décrit comment les auteurs de RFC doivent correctement demander à l'IANA de démarrer ou reprendre un registre. L'IANA maintient également des registres qui ont été ouverts bien avant la production du BCP 26.

6.4.4 Considérations de sécurité

Une chose qui est requise dans chaque RFC et Internet-Draft est une section "Considérations de sécurité". Cette section doit décrire toutes les vulnérabilités connues du protocole, les menaces possibles et les mécanismes ou stratégies pour y remédier. Ne passez pas sous silence cette section - en particulier, ne dites pas: «Voici notre protocole, si vous voulez de la sécurité, utilisez simplement IPsec». Cela ne fonctionnera pas du tout, car cela ne répond pas à la question de savoir comment IPsec interagit avec votre protocole, et vice versa. Voir BCP 72, "Directives pour la rédaction de texte RFC sur les considérations de sécurité", pour plus d'informations sur la rédaction de bonnes sections sur les considérations de sécurité.

6.4.5 Brevets dans les normes IETF

Les problèmes de propriété intellectuelle sont apparus de plus en plus souvent ces dernières années, notamment en ce qui concerne les brevets. Le but de l'IETF est d'avoir ses normes largement utilisées et validées sur le marché. Si la création d'un produit qui utilise une norme nécessite d'obtenir une licence pour un brevet, les gens sont moins susceptibles de mettre en œuvre la norme. Il n'est donc pas surprenant que la règle générale ait été "d'utiliser une bonne technologie non brevetée dans la mesure du possible".

Bien sûr, ce n'est pas toujours possible. Parfois, les brevets apparaissent après l'établissement d'une norme. Parfois, il y a un brevet sur quelque chose de si précieux qu'il n'y a pas d'équivalent non breveté. Parfois, le titulaire du brevet est généreux et promet d'accorder à tous les exécutants d'une norme une licence libre de droits pour le brevet, ce qui le rendrait presque aussi facile à mettre en œuvre qu'il l'aurait été si aucun brevet n'avait existé.

Les méthodes de l'IETF pour traiter les brevets dans les normes font l'objet de nombreux débats. Les règles officielles pour tous les droits de propriété intellectuelle (DPI) dans les documents de l'IETF (pas seulement les brevets) sont couvertes dans les BCP 78 et BCP 79, "Droits de propriété intellectuelle sur la technologie IETF". Tous ceux qui participent aux groupes de travail de l'IETF trouveront probablement ces documents intéressants car ils énoncent les règles que tout le monde accepte de suivre.

Les titulaires de brevets qui autorisent librement l'utilisation de leurs brevets par des personnes appliquant les normes de l'IETF obtiennent souvent beaucoup de bonne volonté de la part des gens de l'IETF. Une telle générosité est plus courante que vous ne le pensez. Par exemple, RFC 1822 est une licence d'IBM pour l'un de ses brevets de sécurité dans un contexte de protocole particulier, et la communauté de la sécurité a répondu très favorablement à IBM pour cela (alors qu'un certain nombre d'autres sociétés se sont fait des parias pour leur intractabilité sur leur brevets de sécurité).

Si vous rédigez un projet Internet et que vous connaissez un brevet qui s'applique à la technologie sur laquelle vous écrivez, ne mentionnez pas le brevet dans le document. Consultez plutôt la page IETF IPR sur https://datatracker.ietf.org/ipr/about pour déterminer comment procéder. Les droits de propriété intellectuelle ne sont pas mentionnés dans les RFC car les RFC ne changent jamais après leur publication, mais la connaissance des DPI peut changer à tout moment. Par conséquent, une liste de DPI dans un RFC pourrait être incomplète et induire le lecteur en erreur. Le BCP 79 fournit un texte spécifique qui devrait être ajouté aux RFC lorsque l'auteur connaît les problèmes de DPI.

6.5 RFC informatifs et expérimentaux

Comme nous l'avons noté précédemment, tous les RFC ne sont pas des normes. En fait, de nombreux RFC importants ne sont pas du tout conformes aux normes. Actuellement, il existe deux désignations pour les RFC qui ne sont pas censées être des normes: informative, comme le Tao, et expérimentale. (Il existe en fait une troisième désignation, Historique, mais qui est réservée aux documents qui étaient sur la voie des normes et qui ont été supprimés en raison du manque d'utilisation actuelle, ou que des réflexions plus récentes indiquent que la technologie est réellement nocive pour Internet.)

Le rôle des RFC informationnels est souvent débattu dans l'IETF. Beaucoup de gens aiment les avoir, en particulier pour les spécifications qui ont été créées en dehors de l'IETF mais qui sont référencées par des documents de l'IETF. Ils sont également utiles pour les spécifications qui sont les précurseurs du travail effectué par les groupes de travail de l'IETF. D'un autre côté, certaines personnes qualifient les RFC d'information de «normes» même si les RFC ne sont pas des normes, généralement pour tromper le public crédule sur quelque chose que la personne vend ou soutient. Lorsque cela se produit, le débat sur les RFC informationnels est renouvelé.

Les RFC expérimentaux concernent des spécifications qui peuvent être intéressantes, mais pour lesquelles il n'est pas clair s'il y aura beaucoup d'intérêt à les mettre en œuvre, ou si elles fonctionneront une fois déployées. Autrement dit, une spécification peut résoudre un problème, mais s'il n'est pas clair que beaucoup de gens pensent que le problème est important, ou pensent qu'ils prendront la peine de résoudre le problème avec la spécification, la spécification peut être étiquetée RFC expérimentale. Si, plus tard, la spécification devient populaire (ou prouve qu'elle fonctionne bien), elle peut être réémise en tant que RFC standard. Les RFC expérimentaux sont également utilisés pour amener les gens à expérimenter avec une technologie qui semble être du matériel conforme aux normes, mais pour laquelle il reste des questions sans réponse.

L'IESG a créé des lignes directrices sur la façon dont il choisit entre le statut informationnel et expérimental: [19] . Si vous créez un document qui, selon vous, pourrait devenir un RFC expérimental, connaître la réflexion actuelle vous aidera à justifier votre choix proposé.

7. Comment contribuer à l'IETF

7.1 Ce que vous pouvez faire

Lire - Passez en revue les projets Internet dans votre domaine d'expertise et commentez-les dans les groupes de travail. Participez à la discussion de manière amicale et utile, dans le but d'être les meilleurs standards Internet possibles. Écoutez bien plus que vous ne parlez. Si vous n'êtes pas d'accord, débattez des problèmes techniques: n'attaquez jamais les gens.

Mettre en œuvre - Écrire des programmes qui utilisent les normes Internet actuelles. Les normes ne valent pas grand-chose à moins qu'elles ne soient accessibles aux internautes. Implémentez même les normes "mineures", car elles deviendront moins mineures si elles apparaissent dans plus de logiciels. Signalez tout problème que vous rencontrez avec les normes au groupe de travail approprié afin que la norme puisse être clarifiée dans des révisions ultérieures. L'un des principes les plus souvent cités de l'IETF est «l'exécution de code gagne», vous pouvez donc aider à prendre en charge les normes que vous souhaitez généraliser en créant plus de code en cours d'exécution. Vous pouvez aider au développement de protocoles avant qu'ils ne deviennent des normes en implémentant (mais pas en déployant) à partir d'I-D pour vous assurer que les auteurs ont fait du bon travail. Si vous constatez des erreurs ou des omissions, proposez des améliorations en fonction de votre expérience de mise en œuvre.

Écrire - Modifier ou co-rédiger des brouillons Internet dans votre domaine d'expertise. Faites cela au profit de la communauté Internet, et non pour obtenir votre nom (ou, pire encore, le nom de votre entreprise) sur un document. Les projets d'auteurs font l'objet de toutes sortes de critiques techniques (et parfois personnelles); recevez-le avec sérénité et utilisez-le pour améliorer votre brouillon afin de produire la norme la meilleure et la plus interopérable.

7.2 Ce que votre entreprise peut faire

Partager - Évitez les normes propriétaires. Si vous êtes un implémenteur, manifestez une forte préférence pour les normes IETF. Si les normes IETF ne sont pas aussi bonnes que les normes propriétaires, travaillez pour améliorer les normes IETF. Si vous êtes un acheteur, évitez les produits qui utilisent des normes propriétaires qui sont en concurrence avec les normes ouvertes de l'IETF et dites aux entreprises que vous achetez que vous le faites.

Ouvrir - Si votre entreprise contrôle un brevet qui est utilisé dans une norme IETF, convaincre l'entreprise de rendre le brevet disponible sans frais pour tous ceux qui mettent en œuvre la norme. Au cours des dernières années, les brevets ont causé de nombreux problèmes graves pour les normes Internet car ils empêchent certaines entreprises de pouvoir appliquer librement les normes. Heureusement, de nombreuses entreprises ont généreusement offert des licences illimitées pour des brevets particuliers afin d'aider les normes de l'IETF à prospérer. Ces entreprises sont généralement récompensées par une publicité positive du fait qu'elles ne sont pas aussi gourmandes ou myopes que les autres titulaires de brevets.

Rejoignez - Devenez membre de l'ISOC. Plus important encore, exhortez toute entreprise qui a profité d'Internet à devenir membre corporatif de l'ISOC, car cela présente le plus grand avantage financier pour le groupe. Bien entendu, cela profitera également à Internet dans son ensemble.

8. IETF et le monde extérieur

8.1 IETF et autres groupes de normes

Autant que de nombreux participants de l'IETF voudraient penser le contraire, l'IETF n'existe pas dans un vide de normes. Il existe de nombreux autres organismes de normalisation (peut-être trop) dont les décisions affectent Internet. Il existe également un bon nombre d'organismes de normalisation qui ont longtemps ignoré Internet et veulent maintenant obtenir une part de l'action.

En général, l'IETF essaie d'avoir des relations cordiales avec d'autres organismes de normalisation. Ce n'est pas toujours facile, car de nombreux autres organismes ont des structures très différentes de celles de l'IETF, et l'IETF est principalement gérée par des bénévoles qui préféreraient probablement rédiger des normes plutôt que de rencontrer des représentants d'autres organismes. Malgré cela, certains autres organismes de normalisation font un grand effort pour bien interagir avec l'IETF malgré les différences culturelles évidentes.

Au moment d'écrire ces lignes, l'IETF entretient des liaisons avec de grands organismes de normalisation, notamment l'UIT-T (le Secteur de la normalisation des télécommunications de l'Union internationale des télécommunications), le W3C (World Wide Web Consortium), l'IEEE (Institute of Electrical et ingénieurs en électronique) et le consortium Unicode. Comme indiqué dans la charte de l'IAB (BCP39), "les liaisons sont maintenues aussi informelles que possible et doivent avoir une valeur démontrable pour améliorer la qualité des spécifications de l'IETF". Dans la pratique, l'IETF préfère que les liaisons aient lieu directement au niveau du groupe de travail, avec des relations formelles et des documents de liaison dans un rôle de secours.

Certaines de ces tâches de liaison incombent à l'IESG, tandis que d'autres incombent à l'IAB. Les lecteurs soucieux des détails apprendront beaucoup sur les méthodes formelles de traitement avec d'autres organismes de normalisation dans le BCP 102, "Processus IAB pour la gestion des relations de liaison avec l'IETF", et le BCP 103, "Procédures de traitement des déclarations de liaison vers et depuis l'IETF". Le meilleur endroit pour vérifier si l'IETF a une quelconque liaison officielle est la liste des liaisons IETF.

8.2 Couverture médiatique de l'IETF

Étant donné que l'IETF est l'un des organismes les plus connus qui aident à faire avancer Internet, il est naturel que la presse informatique (et même la presse professionnelle) veuille couvrir ses actions. Mais il peut être difficile de couvrir l'IETF. Un malentendu commun est que l'IETF envisage quelque chose alors qu'en fait il n'y a qu'un projet Internet dans un groupe de travail, et rapporte que l'IETF a approuvé quelque chose quand tout ce qui s'est passé, c'est qu'un RFC d'information a été publié. Dans les deux cas, la presse n'est pas vraiment à blâmer pour le problème, car elle est généralement alertée de l'histoire par une entreprise qui essaie de faire connaître un protocole qu'elle a développé ou au moins à soutenir. L'endroit par défaut où la presse doit rechercher les contacts presse pour l'IETF est [20] .

Les journalistes qui veulent savoir "ce que fait l'IETF" sur un sujet particulier seraient bien avisés de parler à plus d'une personne active sur ce sujet à l'IETF, et devraient probablement essayer de parler au président du GT dans tout les cas. Il est impossible de déterminer ce qui se passera avec un brouillon en consultant le brouillon ou en discutant avec l'auteur du brouillon. Heureusement, tous les groupes de travail ont des archives qu'un journaliste peut consulter pour obtenir des indications récentes sur l'état d'avancement d'un projet; malheureusement, peu de journalistes ont le temps ou l'envie de faire ce genre de recherche.

Les journalistes qui recherchent des informations sur l'IETF, ou des pointeurs vers des participants de l'IETF travaillant sur un sujet particulier intéressant l'IETF, sont encouragés à envoyer un courrier électronique à media@ietf.org. Les réponses sont généralement envoyées dans un délai d'un jour. Même si une réponse directe à une requête particulière n'est pas disponible, des pointeurs vers des ressources ou des personnes qui peuvent fournir plus d'informations sur un sujet sont souvent fournis.

9. Considérations de sécurité

La section 6.4.4 explique pourquoi chaque RFC doit avoir une section sur les considérations de sécurité et donne une idée de ce qu'elle devrait et ne devrait pas contenir. À part ces informations, ce document ne touche pas à la sécurité Internet.

10. Références informatives

BCP9 Bradner, S., «The Internet Standards Process - Revision 3», BCP 9, RFC 2026 , RFC 6410 , octobre 1996.

BCP10 Galvin, J., «Processus de sélection, de confirmation et de rappel de l'IAB et de l'IESG: fonctionnement des comités de nomination et de rappel», BCP 10, RFC 3777 , juin 2004.

BCP11 Hovey, R. et S. Bradner, «Les organisations impliquées dans le processus de normalisation de l'IETF», BCP 11, RFC 2028 , octobre 1996.

BCP14 Bradner, S., «Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence», BCP 14, RFC 2119 , mars 1997.

BCP22 Scott, G., «Guide for Internet Standards Writers», BCP 22, RFC 2360 , juin 1998.

BCP25 Bradner, S., «IETF Working Group Guidelines and Procedures», BCP 25, RFC 2418 , septembre 1998.

BCP26 Narten, T. et H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226 , mai 2008.

BCP39 Internet Architecture Board et B. Carpenter, «Charte de l'Internet Architecture Board (IAB)», BCP 39, RFC 2850 , mai 2000.

BCP45 Harris, S., «IETF Discussion List Charter», BCP 45, RFC 3005 , novembre 2000.

BCP72 Rescorla, E. et B. Korver, «Guidelines for Writing RFC Text on Security Considerations», BCP 72, RFC 3552 , juillet 2003.

BCP78 Bradner, S., «IETF Rights in Contributions», BCP 78, RFC 5378 , novembre 2008.

BCP79 Bradner, S., «Droits de propriété intellectuelle sur la technologie IETF», BCP 79, RFC 3979 , mars 2005.

BCP95 Alvestrand, H., «Un énoncé de mission pour l'IETF», BCP 95, RFC 3935 , octobre 2004.

BCP97 Bush, R. et T. Narten, «Clarifying when Standards Track Documents can refer Normably to Documents at a Lower Level», BCP 97, RFC 3967 , décembre 2004.

BCP101 Austein, R. et B. Wijnen, «Structure de l'IETF Administrative Support Activity (IASA)», BCP 101, RFC 4071 , avril 2005.

BCP102 Daigle, L. et Internet Architecture Board, «IAB Processes for Management of IETF Liaison Relationships», BCP 102, RFC 4052 , avril 2005.

BCP103 Trowbridge, S., Bradner, S. et F. Baker, «Procédures de traitement des déclarations de liaison vers et depuis l'IETF», BCP 103, RFC 4053 , avril 2005

RFC1796 Huitema, C., Postel, J. et S. Crocker, «Pas tous les RFC sont des normes», RFC 1796 , avril 1995.

RFC2223 Postel, J. et J. Reynolds, «Instructions aux auteurs RFC», RFC 2223 , octobre 1997.

RFC2860 Carpenter, B., Baker, F. et M. Roberts, «Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority», RFC 2860 , juin 2000.

RFC6635 Kolkman, O. et J. Halpern, «RFC Editor Model (Version 2)», RFC 6635 , mars 2012.

RFC4677 Hoffman, P. et S. Harris, «The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force», RFC 4677 , septembre 2006.

RFC4858 Levkowetz, H., Meyer, D., Eggert, L. et A. Mankin, «Document Shepherding from Working Group Last Call to Publication», RFC 4858 , mai 2007.

RFC6722 Hoffman, P., «Publication du« Tao de l'IETF »en tant que page Web», RFC 6722 , août 2012.

STD3 Braden, R., «Configuration requise pour les hôtes Internet - Application et support», STD 3, RFC 1123 , octobre 1989.

A. Principes directeurs de l'IETF

Si vous êtes allé aussi loin dans le Tao, vous avez beaucoup appris sur le fonctionnement de l'IETF. Ce que vous trouverez dans cette annexe résume une grande partie de ce que vous avez lu et ajoute quelques nouveaux points à méditer. Assurez-vous de lire tous les principes; pris dans leur ensemble, ils vous donneront une nouvelle perspective sur ce qui fait fonctionner l'IETF.

A.1 Général

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

L'IETF travaille dans des domaines où elle possède ou peut trouver des compétences techniques.

L'IETF dépend d'un noyau bénévole de participants actifs.

La participation à l'IETF ou à ses groupes de travail n'est pas payante ou définie sur le plan organisationnel, mais repose sur l'auto-identification et la participation active des individus.

A.2 Gestion et leadership

L'IETF reconnaît les postes de direction et accorde le pouvoir de décision aux dirigeants, mais les décisions sont susceptibles d'appel.

La délégation de pouvoir et de responsabilité est essentielle au fonctionnement efficace de l'IETF. Autant de personnes que possible seront encouragées à assumer le leadership des tâches de l'IETF.

La dissidence, la plainte et l'appel sont une conséquence de la nature de l'IETF et doivent être considérés comme des événements normaux, mais en fin de compte, c'est un fait que certaines décisions ne peuvent pas être effectivement appelées.

Les postes de direction sont à durée déterminée (bien que nous n'ayons aucune limitation formelle sur le nombre de mandats pouvant être servis).

Il est important de former de futurs leaders au sein de la communauté active.

Un processus communautaire est utilisé pour sélectionner les dirigeants.

Les dirigeants ont le pouvoir de juger qu'un consensus approximatif a été démontré. Sans adhésion officielle, il n'y a pas de règles formelles de consensus.

A.3 Processus

Bien que l'IETF ait besoin de règles de processus claires et documentées publiquement pour les cas normaux, il devrait y avoir suffisamment de flexibilité pour permettre aux cas inhabituels d'être traités selon le bon sens. Nous appliquons un jugement personnel et ne codifions que lorsque nous en sommes certains. (Mais nous codifions qui peut porter des jugements personnels.)

Les travaux de développement technique devraient être menés par des groupes de travail à charte étroite et ciblés.

Les parties du processus qui se sont révélées impraticables doivent être supprimées ou rendues facultatives.

A.4 Groupes de travail

Les groupes de travail (GT) devraient être principalement responsables de la qualité de leurs résultats; Les présidents des groupes de travail en tant que dirigeants des groupes de travail, appuyés par la direction de l'IETF, devraient agir comme un filet de sécurité de qualité.

Les groupes de travail devraient être principalement chargés d'évaluer l'impact négatif de leur travail sur Internet dans son ensemble, et donc d'obtenir un examen intersectoriel; la direction de l'IETF devrait agir comme un filet de sécurité intersectoriel.

Un examen précoce des documents, en particulier par des groupes de travail, est plus efficace pour traiter des problèmes majeurs qu'un examen tardif.

Les directeurs régionaux (AD) sont chargés d'orienter la formation et la constitution des groupes de travail, de leur donner des directives si nécessaire et de les mettre fin. Les présidents des GT siègent au gré de l'AD responsable.

Les présidents des GT sont chargés de veiller à ce que les GT exécutent leurs chartes, respectent leurs jalons et produisent des livrables prêts à être publiés. Les éditeurs de documents sont à la disposition du président du GT.

Les DA sont responsables de l'organisation de la révision du filet de sécurité et de l'approbation finale du document. A.5 Documents

Les normes de l'IETF commencent souvent comme des projets personnels, peuvent devenir des projets du GT et sont approuvées pour publication permanente par un organe de direction indépendant du GT ou des personnes qui les ont produites.

Les normes IETF appartiennent à la communauté, pas à leurs auteurs. Mais la paternité est reconnue et valorisée, tout comme les contributions moindres que la paternité totale.

La qualité technique et l'exactitude sont les principaux critères pour parvenir à un consensus sur les documents.

Les spécifications de l'IETF peuvent être publiées en tant qu'informationnel, expérimental, normalisé, historique ou meilleure pratique actuelle.

Les spécifications IETF Standards Track ne sont pas considérées comme des normes satisfaisantes tant que des implémentations indépendantes interopérables n'ont pas été démontrées. (Il s'agit de l'incarnation du slogan «code en cours d'exécution».) Cependant, l'IETF ne prend pas la responsabilité des tests d'interopérabilité et ne certifie pas l'interopérabilité.

Les processus de l'IETF sont publiés en tant que documents sur les meilleures pratiques actuelles.

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

Les spécifications et processus obsolètes ou obsolètes peuvent être rétrogradés à Historique.

La voie des normes devrait distinguer les spécifications dont il a été démontré qu'elles interagissent.

Les documents Standards Track et Best Current Practice doivent être soumis au consensus général de l'IETF (processus Last Call). Un consensus approximatif du GT est normalement suffisant pour d'autres documents.

Les modifications substantielles apportées à la suite du dernier appel de l'IETF ou de l'évaluation de l'IESG doivent être renvoyées au GT.

L'IETF détermine les exigences de publication et d'archivage de ses documents. </pre>