6. LE PROCESSUS DE NORMALISATION INTERNET
- LE PROCESSUS DE NORMALISATION INTERNET (THE INTERNET STANDARDS PROCESS)
La mécanique du processus de normalisation Internet implique des décisions de l'IESG concernant l'élévation d'une spécification sur la filière des standards ou le déplacement d'une spécification de la filière des standards d'un niveau de maturité à un autre. Bien qu'un certain nombre de critères raisonnablement objectifs (décrits ci-dessous et dans la section 4) soient disponibles pour guider l'IESG dans la prise de décision pour déplacer une spécification sur, le long ou hors de la filière des standards, il n'y a aucune garantie algorithmique d'élévation à ou de progression le long de la filière des standards pour toute spécification. Le jugement collectif expérimenté de l'IESG concernant la qualité technique d'une spécification proposée pour l'élévation à ou l'avancement dans la filière des standards est un composant essentiel du processus décisionnel.
6.1 Actions de normalisation (Standards Actions)
Une "action de normalisation" -- faire entrer une spécification particulière dans, la faire avancer à l'intérieur de, ou la retirer de la filière des standards -- doit être approuvée par l'IESG.
6.1.1 Initiation de l'action (Initiation of Action)
Une spécification qui est destinée à entrer ou à avancer dans la filière des standards Internet doit d'abord être publiée en tant qu'Internet-Draft (voir section 2.2) à moins qu'elle n'ait pas changé depuis sa publication en tant que RFC. Elle doit rester en tant qu'Internet-Draft pendant une période de temps, d'au moins deux semaines, qui permet un examen communautaire utile, après quoi une recommandation d'action peut être initiée.
Une action de normalisation est initiée par une recommandation du groupe de travail IETF responsable d'une spécification à son directeur de zone, copiée au secrétariat IETF ou, dans le cas d'une spécification non associée à un groupe de travail, une recommandation d'un individu à l'IESG.
6.1.2 Examen et approbation par l'IESG (IESG Review and Approval)
L'IESG détermine si une spécification qui lui est soumise conformément à la section 6.1.1 satisfait les critères applicables pour l'action recommandée (voir sections 4.1 et 4.2), et détermine en outre si la qualité technique et la clarté de la spécification sont cohérentes avec celles attendues pour le niveau de maturité auquel la spécification est recommandée.
Afin d'obtenir toutes les informations nécessaires pour prendre ces déterminations, en particulier lorsque la spécification est considérée par l'IESG comme extrêmement importante en termes de son impact potentiel sur l'Internet ou sur la suite de protocoles Internet, l'IESG peut, à sa discrétion, commander un examen technique indépendant de la spécification.
L'IESG enverra un avis à l'IETF de l'examen IESG en attente du ou des documents pour permettre un examen final par la communauté Internet générale. Cette notification de "Last-Call" (dernier appel) se fera par courrier électronique à la liste de diffusion IETF Announce. Les commentaires sur un Last-Call seront acceptés de quiconque et doivent être envoyés comme indiqué dans l'annonce du Last-Call.
La période de Last-Call ne sera pas inférieure à deux semaines, sauf dans les cas où l'action de normalisation proposée n'a pas été initiée par un groupe de travail IETF, auquel cas la période de Last-Call ne sera pas inférieure à quatre semaines. Si l'IESG estime que l'intérêt de la communauté serait servi en permettant plus de temps pour les commentaires, elle peut décider d'une période de Last-Call plus longue ou de prolonger explicitement une période de Last-Call en cours.
L'IESG n'est pas liée par l'action recommandée lorsque la spécification a été soumise. Par exemple, l'IESG peut décider d'envisager la spécification pour publication dans une catégorie différente de celle demandée. Si l'IESG détermine cela avant que le Last-Call ne soit émis, alors le Last-Call devrait refléter le point de vue de l'IESG. L'IESG pourrait également décider de changer la catégorie de publication en fonction de la réponse à un Last-Call. Si cette décision conduirait à publier une spécification à un niveau "supérieur" à celui pour lequel le Last-Call original était prévu, un nouveau Last-Call devrait être émis indiquant la recommandation de l'IESG. De plus, l'IESG peut décider de recommander la formation d'un nouveau groupe de travail en cas de controverse importante en réponse à un Last-Call pour une spécification ne provenant pas d'un groupe de travail IETF.
Dans un délai opportun après l'expiration de la période de Last-Call, l'IESG prendra sa détermination finale d'approuver ou non l'action de normalisation, et notifiera l'IETF de sa décision par courrier électronique à la liste de diffusion IETF Announce.
6.1.3 Publication (Publication)
Si une action de normalisation est approuvée, une notification est envoyée à l'éditeur RFC et copiée à l'IETF avec des instructions pour publier la spécification en tant que RFC. La spécification sera à ce moment-là retirée du répertoire Internet-Drafts.
Un résumé officiel des actions de normalisation terminées et en attente apparaîtra dans chaque numéro du bulletin d'information de l'Internet Society. Cela constituera la "publication d'enregistrement" pour les actions de normalisation Internet.
L'éditeur RFC publiera périodiquement un RFC "Internet Official Protocol Standards" [1], résumant le statut de toutes les spécifications de protocole et de service Internet.
6.2 Avancement dans la filière des standards (Advancing in the Standards Track)
La procédure décrite dans la section 6.1 est suivie pour chaque action qui accompagne l'avancement d'une spécification le long de la filière des standards.
Une spécification restera au niveau Proposed Standard pendant au moins six (6) mois.
Une spécification restera au niveau Draft Standard pendant au moins quatre (4) mois, ou jusqu'à ce qu'au moins une réunion IETF ait eu lieu, selon ce qui arrive en dernier.
Ces périodes minimales sont destinées à assurer une opportunité adéquate pour l'examen de la communauté sans impacter sévèrement l'actualité. Ces intervalles seront mesurés à partir de la date de publication du ou des RFC correspondants, ou, si l'action n'entraîne pas de publication RFC, la date de l'annonce de l'approbation de l'IESG de l'action.
Une spécification peut être (en fait, est susceptible d'être) révisée à mesure qu'elle progresse à travers la filière des standards. À chaque étape, l'IESG déterminera la portée et l'importance de la révision de la spécification, et, si nécessaire et approprié, modifiera l'action recommandée. Des révisions mineures sont attendues, mais une révision importante peut nécessiter que la spécification accumule plus d'expérience à son niveau de maturité actuel avant de progresser. Enfin, si la spécification a été modifiée de manière très significative, l'IESG peut recommander que la révision soit traitée comme un nouveau document, réentrant dans la filière des standards au début.
Un changement de statut entraînera la republication de la spécification en tant que RFC, sauf dans le cas rare où il n'y a eu aucun changement du tout dans la spécification depuis la dernière publication. Généralement, les modifications souhaitées seront "regroupées" pour incorporation au niveau suivant dans la filière des standards. Cependant, le report des modifications à la prochaine action de normalisation sur la spécification ne sera pas toujours possible ou souhaitable; par exemple, une erreur typographique importante, ou une erreur technique qui ne représente pas un changement dans la fonction globale de la spécification, peut nécessiter d'être corrigée immédiatement. Dans de tels cas, l'IESG ou l'éditeur RFC peut être invité à republier le RFC (avec un nouveau numéro) avec des corrections, et cela ne réinitialisera pas l'horloge du temps minimum au niveau.
Lorsqu'une spécification de la filière des standards n'a pas atteint le niveau Internet Standard mais est restée au même niveau de maturité pendant vingt-quatre (24) mois, et tous les douze (12) mois par la suite jusqu'à ce que le statut soit changé, l'IESG examinera la viabilité de l'effort de normalisation responsable de cette spécification et l'utilité de la technologie. Après chaque examen, l'IESG approuvera la résiliation ou la poursuite de l'effort de développement, en même temps l'IESG décidera de maintenir la spécification au même niveau de maturité ou de la déplacer vers le statut Historic. Cette décision sera communiquée à l'IETF par courrier électronique à la liste de diffusion IETF Announce pour permettre à la communauté Internet une opportunité de commenter. Cette disposition n'est pas destinée à menacer un effort de groupe de travail légitime et actif, mais plutôt à fournir un mécanisme administratif pour mettre fin à un effort moribond.
6.3 Révision d'un standard (Revising a Standard)
Une nouvelle version d'un Standard Internet établi doit progresser à travers le processus complet de normalisation Internet comme s'il s'agissait d'une spécification complètement nouvelle. Une fois que la nouvelle version a atteint le niveau Standard, elle remplacera généralement la version précédente, qui sera déplacée vers le statut Historic. Cependant, dans certains cas, les deux versions peuvent rester comme Standards Internet pour honorer les exigences d'une base installée. Dans cette situation, la relation entre la version précédente et la nouvelle version doit être explicitement déclarée dans le texte de la nouvelle version ou dans un autre document approprié (par exemple, une déclaration d'applicabilité; voir section 3.2).
6.4 Retrait d'un standard (Retiring a Standard)
À mesure que la technologie change et mûrit, il est possible qu'une nouvelle spécification Standard soit si clairement supérieure techniquement qu'une ou plusieurs spécifications existantes de la filière des standards pour la même fonction devraient être retirées. Dans ce cas, ou lorsqu'il est estimé pour une autre raison qu'une spécification existante de la filière des standards devrait être retirée, l'IESG approuvera un changement de statut de l'ancienne ou des anciennes spécifications vers Historic. Cette recommandation sera émise avec les mêmes procédures de Last-Call et de notification utilisées pour toute autre action de normalisation. Une demande de retrait d'un standard existant peut provenir d'un groupe de travail, d'un directeur de zone ou d'une autre partie intéressée.
6.5 Résolution de conflits et appels (Conflict Resolution and Appeals)
Des différends sont possibles à divers stades du processus IETF. Autant que possible, le processus est conçu pour que des compromis puissent être faits et qu'un véritable consensus soit atteint, cependant il y a des moments où même les personnes les plus raisonnables et les plus compétentes sont incapables de se mettre d'accord. Pour atteindre les objectifs d'ouverture et d'équité, de tels conflits doivent être résolus par un processus d'examen et de discussion ouverts. Cette section spécifie les procédures qui doivent être suivies pour traiter les questions de standards Internet qui ne peuvent être résolues par les processus normaux par lesquels les groupes de travail IETF et d'autres participants au processus de normalisation Internet atteignent habituellement un consensus.
6.5.1 Différends de groupe de travail (Working Group Disputes)
Un individu (qu'il soit ou non participant au groupe de travail concerné) peut être en désaccord avec une recommandation du groupe de travail en raison de sa conviction que soit (a) ses propres opinions n'ont pas été adéquatement prises en compte par le groupe de travail, soit (b) le groupe de travail a fait un choix technique incorrect qui met en péril significatif la qualité et/ou l'intégrité du ou des produits du groupe de travail. La première question est une difficulté avec le processus du groupe de travail; la seconde est une affirmation d'erreur technique. Ces deux types de désaccord sont assez différents, mais les deux sont traités par le même processus d'examen.
Une personne qui est en désaccord avec une recommandation du groupe de travail doit toujours d'abord discuter de la question avec le ou les présidents du groupe de travail, qui peuvent impliquer d'autres membres du groupe de travail (ou le groupe de travail dans son ensemble) dans la discussion.
Si le désaccord ne peut être résolu de cette manière, l'une des parties impliquées peut le porter à l'attention du ou des directeurs de zone pour la zone dans laquelle le groupe de travail est constitué. Le ou les directeurs de zone tenteront de résoudre le différend.
Si le désaccord ne peut être résolu par le ou les directeurs de zone, l'une des parties impliquées peut alors faire appel à l'IESG dans son ensemble. L'IESG examinera alors la situation et tentera de la résoudre d'une manière de son propre choix.
Si le désaccord n'est pas résolu à la satisfaction des parties au niveau de l'IESG, l'une des parties impliquées peut faire appel de la décision à l'IAB. L'IAB examinera alors la situation et tentera de la résoudre d'une manière de son propre choix.
La décision de l'IAB est finale en ce qui concerne la question de savoir si les procédures de normalisation Internet ont été suivies ou non et en ce qui concerne toutes les questions de mérite technique.
6.5.2 Échecs de processus (Process Failures)
Ce document établit des procédures qui doivent être suivies pour assurer l'ouverture et l'équité du processus de normalisation Internet, et la viabilité technique des standards créés. L'IESG est l'agent principal de l'IETF à cette fin, et c'est l'IESG qui est chargée de s'assurer que les procédures requises ont été suivies et que tous les prérequis nécessaires à une action de normalisation ont été satisfaits.
Si un individu devait être en désaccord avec une action prise par l'IESG dans ce processus, cette personne devrait d'abord discuter de la question avec le président de l'IESG. Si le président de l'IESG n'est pas en mesure de satisfaire le plaignant, alors l'IESG dans son ensemble devrait réexaminer l'action prise, avec l'apport du plaignant, et déterminer si d'autres actions sont nécessaires. L'IESG émettra un rapport sur son examen de la plainte à l'IETF.
Si le plaignant n'est pas satisfait du résultat de l'examen de l'IESG, un appel peut être déposé auprès de l'IAB. L'IAB examinera alors la situation et tentera de la résoudre d'une manière de son propre choix et de rapporter à l'IETF sur le résultat de son examen.
Si les circonstances le justifient, l'IAB peut ordonner qu'une décision de l'IESG soit annulée, et la situation sera alors telle qu'elle était avant que la décision de l'IESG ne soit prise. L'IAB peut également recommander une action à l'IESG, ou faire d'autres recommandations qu'elle juge appropriées. L'IAB ne peut cependant pas préempter le rôle de l'IESG en prenant une décision que seule l'IESG est habilitée à prendre.
La décision de l'IAB est finale en ce qui concerne la question de savoir si les procédures de normalisation Internet ont été suivies ou non.
6.5.3 Questions de procédure applicable (Questions of Applicable Procedure)
Un recours supplémentaire n'est disponible que dans les cas où les procédures elles-mêmes (c'est-à-dire les procédures décrites dans ce document) sont jugées inadéquates ou insuffisantes pour la protection des droits de toutes les parties dans un processus de normalisation Internet équitable et ouvert. Les réclamations sur cette base peuvent être faites au conseil d'administration de l'Internet Society. Le président de l'Internet Society accusera réception d'un tel appel dans les deux semaines et informera le pétitionnaire au moment de l'accusé de réception de la durée prévue de l'examen de l'appel par les administrateurs. Les administrateurs examineront la situation d'une manière de leur propre choix et rapporteront à l'IETF sur le résultat de leur examen.
La décision des administrateurs à l'issue de leur examen sera finale en ce qui concerne tous les aspects du différend.
6.5.4 Procédure d'appel (Appeals Procedure)
Tous les appels doivent inclure une description détaillée et spécifique des faits du différend.
Tous les appels doivent être initiés dans les deux mois suivant la connaissance publique de l'action ou de la décision à contester.
À toutes les étapes du processus d'appel, les individus ou organismes responsables de la prise de décisions ont le pouvoir discrétionnaire de définir les procédures spécifiques qu'ils suivront dans le processus de prise de décision.
Dans tous les cas, une décision concernant la disposition du différend, et la communication de cette décision aux parties impliquées, doivent être accomplies dans un délai raisonnable.
[NOTE: Ces procédures n'établissent intentionnellement et explicitement pas de période de temps maximale fixe qui serait considérée comme "raisonnable" dans tous les cas. Le processus de normalisation Internet accorde une importance au consensus et aux efforts pour l'atteindre, et renonce délibérément à une exécution déterministe rapide des procédures en faveur d'une latitude dans laquelle des accords techniques plus authentiques peuvent être atteints.]