------------------------------------------------------------------------ Internet, le 5 février 2008, Ce document qui est une traduction du document RFC 2026 de l'IETF (Internet Engineering Task Force) peut comporter des erreurs ou en introduire de nouvelles. Seul le document original à ftp://ftp.rfc-editor.org/in-notes/rfc2026.txt fait référence. La traduction est disponible sous licence Creative Commons (http://creativecommons.org/licenses/by/2.0/fr/) Traduit par Jean-Jacques Solari et relu par Claude Briere de l'Isle et Olivier Miakinen. ------------------------------------------------------------------------ Network Working Group S. Bradner Document RFC : 2026 Harvard University Document BCP : 9 Octobre 1996 Remplace : 1602 Catégorie : Best Current Practice Le processus de standardisation Internet (3ème révision) Statut de ce mémoire Ce document recueille les pratiques exemplaires Internet courantes de la communauté Internet, et il appelle le débat et des suggestions d'amélioration. La distribution de ce mémoire est libre. Résumé Ce mémoire documente le processus utilisé par la communauté Internet pour la standardisation des protocoles et des procédures. Il définit les stades du processus de standardisation, les prérequis pour mouvoir un document d'un stade à l'autre et les types de documents utilisés au cours de ce processus. Il traite également des questions de droits de propriété intellectuelle et de droits d'auteur associées au processus de standardisation. Table des matières 1. Introduction 1.1. Les standards Internet 1.2. Le processus de standardisation Internet 1.3. Organisation de ce document 2. Les publications liées aux standards Internet 2.1. Les appels à commentaires (RFC) 2.2. Les projets Internet 3. Les spécifications de standards Internet 3.1. Spécification technique (TS) 3.2. Déclaration d'applicabilité (AS) 3.3. Niveaux d'exigence 4. Le circuit des standards Internet 4.1. Les niveaux de maturité du circuit des standards 4.1.1. Proposed Standard 4.1.2. Draft Standard 4.1.3. Internet Standard 4.2. Les niveaux de maturité hors du circuit des standards 4.2.1. Experimental 4.2.2. Informational 4.2.3. Les procédures des RFC expérimentaux et informationnels 4.2.4. Historic 5. Les RFC de pratiques exemplaires courantes (BCP) 5.1. Le processus de validation des BCP 6. Le processus de standardisation Internet 6.1. Les actions de standardisation 6.1.1. Le lancement d'une action 6.1.2. La validation et l'approbation de l'IESG 6.1.3. La publication 6.2. La progression dans le circuit des standards 6.3. La révision d'un standard 6.4. Le retrait d'un standard 6.5. La résolution des conflits et les appels 6.5.1. Les désaccords des groupes de travail 6.5.2. Les faillites du processus 6.5.3. La pertinence des procédures 6.5.4. La procédure d'appel 7. Les normes et spécifications externes 7.1. L'utilisation des spécifications externes 7.1.1. L'incorporation d'une norme ouverte 7.1.2. L'incorporation des autres spécifications 7.1.3. La prise en charge 8. Les annonces et la tenue des archives 9. La variation du processus 9.1. La procédure de dispense 9.2. Les exclusions 10. Les droits de propriété intellectuelle 10.1. La politique générale 10.2. Les obligations de confidentialité 10.3. Les droits et les permissions 10.3.1. Toutes les contributions 10.3.2. Les documents du circuit des standards 10.3.3. La détermination des termes raisonnables et non discriminatoires 10.4. Les mentions légales 11. Remerciements 12. Observations sur la sécurité 13. Références 14. Définitions des termes 15. Coordonnées de l'auteur Annexe A : Glossaire des abréviations 1. Introduction Ce mémoire documente le processus actuel utilisé par la communauté Internet pour la standardisation des protocoles et procédures. Le processus de standardisation Internet (Internet Standards process) est une activité de l'Internet Society organisée et administrée au nom de la communauté Internet par l'IAB (Internet Architecture Board) et l'IESG (Internet Engineering Steering Group). 1.1. Les standards Internet Internet, une collaboration internationale faiblement organisée de réseaux interconnectés autonomes, permet une communication hôte à hôte au travers d'une adhésion volontaire aux protocoles et procédures ouverts définis par les standards Internet. Il y a aussi beaucoup de réseaux interconnectés isolés qui ne sont pas connectés au réseau Internet global mais qui utilisent les standards Internet. Le processus de standardisation Internet décrit dans ce document concerne tous les protocoles, procédures et conventions utilisés au sein de et par Internet, qu'ils fassent partie ou non de la suite de protocoles TCP/IP. En revanche, dans le cas de protocoles développés ou standardisés par des organismes non Internet, le processus de standardisation Internet vaut habituellement pour l'application du protocole (ou de la procédure) dans le contexte d'Internet et non pour la spécification du protocole en question. En général, un standard Internet est une spécification stable et bien comprise, est techniquement suffisant, a plusieurs mises en œuvre indépendantes et interopérables avec une expérience en exploitation considérable, jouit d'un soutien important du public, et est reconnu utile dans une partie ou la totalité d'Internet. 1.2. Le processus de standardisation Internet En théorie, le processus de création d'un standard Internet est simple : une spécification endure une période de développement et une répétition de passages en revue par la communauté Internet et de révisions d'après les retours d'expériences, est adoptée comme standard par l'instance appropriée (voir ci-dessous) puis est publiée. Dans la pratique, le processus est plus compliqué en raison de 1) la difficulté à créer des spécifications de haute qualité technique, 2) la nécessité de tenir compte des intérêts de toutes les parties affectées, 3) l'importance d'obtenir un large consensus de la communauté et 4) la difficulté d'évaluer l'utilité d'une spécification particulière pour la communauté Internet. Les objectifs du processus de standardisation Internet sont : l'excellence technique ; une mise en œuvre et des essais préalables ; une documentation claire, concise et facilement compréhensible ; l'ouverture et l'impartialité ; la ponctualité. Les procédures décrites dans ce document sont élaborées dans le but d'être justes, ouvertes et objectives, de refléter une pratique existante (prouvée) et d'être flexibles. o Ces procédures sont destinées à établir une base juste, ouverte et objective pour le développement, l'évaluation et l'adoption des standards Internet. Elles laissent une grande place à la participation et aux commentaires de toutes les parties intéressées. À chaque stade du processus de standardisation, la spécification est discutée à plusieurs reprises et ses mérites débattus dans des réunions libres ou des listes de diffusion électroniques publiques, et elle est mise à disposition pour examen via des annuaires en ligne dans le monde entier. o Ces procédures visent explicitement la reconnaissance et l'adoption de pratiques généralement acceptées. Une spécification candidate doit ainsi faire l'objet d'une mise en œuvre, son bon fonctionnement et sa bonne interopérabilité doivent être testés par plusieurs tiers indépendants, et elle doit être utilisée dans des environnements de plus en plus exigeants, avant d'être adoptée comme standard Internet. o Ces procédures offent une grande flexibilité pour s'adapter aux situations très variées apparaissant dans le processus de standardisation. L'expérience montre que cette flexibilité est capitale pour réaliser les objectifs listés précédemment. L'objectif de qualité technique, la condition de mise en œuvre et d'essais préalables et la nécessité d'assurer les commentaires des parties intéressées, tout cela demande beaucoup de temps et d'effort. À l'inverse, l'essor actuel de la technologie des réseaux impose le développement à temps des standards. Le processus de standardisation Internet se veut un compromis entre ces termes contradictoires. On estime que le processus est aussi court et simple que possible sans sacrifier l'excellence technique, les essais exhaustifs avant adoption d'un standard, ou l'ouverture et l'impartialité. Depuis le début, Internet est, et entend rester, un système en évolution dans la conception et la mise en œuvre duquel ses participants élaborent régulièrement de nouvelles exigences et technologies. Les utilisateurs d'Internet et les fournisseurs d'équipements, de logiciels et de services qui le soutiennent devraient anticiper et accepter cette évolution comme une doctrine majeure de la philosophie Internet. Les procédures décrites dans ce document sont le résultat de longues années d'évolution, poussée à la fois par les besoins de la communauté Internet de plus en plus nombreuse et hétéroclite, et par l'expérience. 1.3. Organisation de ce document La section 2 décrit les publications et archives du processus de standardisation Internet. La section 3 décrit les types de spécifications de standard Internet. La section 4 décrit le circuit (track) des spécifications de standards Internet. La section 5 décrit les documents RFC de pratiques exemplaires courantes (Best Current Practice). La section 6 décrit le processus et les règles de standardisation Internet. La section 7 définit comment les spécifications et pratiques parrainées extérieurement, développées et contrôlées par d'autres instances de normalisation ou autres, sont prises en compte dans le processus de standardisation Internet. La section 8 décrit les exigences des annonces et de tenue des archives. La section 9 définit un processus de dispense (variance process) autorisant des exceptions ponctuelles aux exigences dans ce document. La section 10 présente les règles nécessaires pour protéger les droits de propriété intellectuelle dans le contexte de la mise en place et de l'utilisation des standards Internet. La section 11 remercie quelques unes des personnes impliquées dans la création de ce document. La section 12 fait valoir que les questions de sécurité ne sont pas traitées par ce document. La section 13 contient une liste de références numérotées. La section 14 contient les définitions de quelques termes utilisés dans ce document. La section 15 indique les coordonnées de l'auteur. L'annexe A contient une liste d'abréviations courantes. 2. Les publications liées aux standards Internet 2.1. Les appels à commentaires (RFC) Chaque version distincte d'une spécification liée aux standards Internet est publiée dans le cadre de la série des documents d'appels à commentaires, ou RFC (Request for Comments). Cette série d'archives est le canal de publication officiel des documents de standards Internet et d'autres publications de l'IESG, de l'IAB et de la communauté Internet. Les RFC peuvent être obtenus auprès de plusieurs hôtes Internet par FTP anonyme, gopher, le World Wide Web et d'autres système de récupération de documents Internet. La série RFC des documents à propos des réseaux a commencé en 1969 dans le cadre du projet original de mise en réseau étendu de l'ARPA (ARPANET), cf. l'annexe A pour un glossaire des abréviations. Les RFC couvrent un grand nombre de sujets en plus des standards Internet, allant des premières discussions de nouveaux concepts de recherche jusqu'aux mémoires de statut à propos d'Internet. La publication des RFC est sous la responsabilité directe de l'éditeur des RFC (RFC Editor), sous la direction générale de l'IAB. Les règles de formatage et de soumission des RFC sont définies dans un RFC [5]. Chaque RFC est disponible dans un format texte ASCII. Certains RFC sont également disponibles en d'autres formats. Les autres versions d'un RFC peuvent contenir des informations (telles que des schémas et des dessins) non présentes dans la version ASCII, et peuvent être formatées différemment. ************************************************************ * * * Une exigence plus stricte touche les spécifications * * du circuit des standards : la version en texte ASCII * * est la référence définitive et doit donc être une * * spécification complète et exacte du standard, incluant * * tous les schémas et illustrations nécessaires. * * * ************************************************************ Le statut des spécifications de protocoles et services Internet fait l'objet d'un compte-rendu périodique dans un RFC intitulé Internet Official Protocol Standards [1]. Ce RFC donne le niveau de maturité et d'autres renseignements utiles pour chaque spécification de protocole ou de service Internet (cf. la section 3). Certains RFC documentent les standards Internet. Ces RFC constituent la sous-série 'STD' de la série des RFC [4]. Lorsqu'une spécification est adoptée en tant que standard Internet, elle reçoit l'étiquette supplémentaire "STDxxx", mais conserve son numéro de RFC et sa place dans la série des RFC (cf. la section 4.1.3). Certains RFC standardisent les résultats des délibérations de communautés à propos de déclarations de principe ou à propos de la meilleure façon d'effectuer certaines opérations ou une fonction du processus IETF. Un tel RFC forme une spécification qui est adoptée comme document de pratique exemplaire BCP, il reçoit une étiquette supplémentaire de la forme "BCPxxx", mais conserve son numéro de RFC et sa place dans la série des RFC (cf. la section 5). Toutes les spécifications de protocoles ou de services pour Internet ne deviennent pas des standards Internet ou des BCP. Ces spécifications hors du circuit des standards ne sont pas soumises aux règles de standardisation Internet. Les spécifications hors du circuit des standards sont directement publiables en tant que RFC « expérimentaux » (Experimental) ou « informationnels » (Informational), à la discrétion de l'éditeur des RFC en concertation avec l'IESG (cf. la section 4.2). ************************************************************ * * * Il importe de se rappeler que les RFC ne sont pas tous * * des documents du circuit des standards, et que les * * documents du circuit des standards n'atteindront pas * * tous le niveau de standard Internet. De la même façon, * * les RFC décrivant des pratiques courantes n'ont pas * * tous été examinés et approuvés pour devenir des BCP. * * Cf. le RFC 1796 [6] pour des précisions. * * * ************************************************************ 2.2. Les projets Internet Au cours du développement d'une spécification, des ébauches du document sont mises à disposition et placées pour revue et commentaires informels dans le répertoire des « projets Internet » (Internet-Drafts) de l'IETF, lequel est répliqué sur plusieurs hôtes Internet. Cela rend accessible un document de travail en évolution à un large public, en facilitant le processus de validation (review) et de révision. Un projet Internet publié comme RFC, ou qui est resté inchangé dans le répertoire des projets Internet pendant plus de 6 mois sans être recommandé à la publication comme RFC par l'IESG, est simplement retiré du répertoire des projets Internet. Un projet Internet peut être remplacé à tout moment par une version plus récente de la même spécification, en renouvelant le délai de 6 mois. Un projet Internet N'EST PAS un moyen de « publier » une spécification : les spécifications sont publiées au travers du mécanisme des RFC décrit dans la section précédente. Les projets Internet n'ont pas de statut formel et sont susceptibles de changer ou de disparaître à tout moment. *********************************************************** * * * Un article, un rapport ou un appel à proposition ne * * devraient en aucune circonstance référencer un projet * * Internet, ni un vendeur revendiquer une conformité * * avec un projet Internet. * * * *********************************************************** Remarque : Il est admis de référencer une spécification du circuit des standards sur le point d'être publiée comme RFC en utilisant la formule consacrée Work in Progress (N.d.T. travaux en cours), sans référencer ainsi de projet Internet. On peut aussi le faire au sein même d'un document du circuit des standards, à condition que celui-ci constitue un document complet et intelligible, qu'il fasse référence ou non aux travaux en cours ailleurs. 3. Les spécifications de standards Internet Les spécifications soumises au processus de standardisation Internet tombent dans l'une des deux catégories suivantes : la spécification technique, ou TS (Technical Specification), et la déclaration d'applicabilité, ou AS (Applicability Statement). 3.1. Spécification technique (TS) Une spécification technique est la description d'un protocole, d'un service, d'une procédure, d'une convention ou d'un format. Elle peut décrire la totalité des aspects pertinents de son sujet ou laisser un ou plusieurs paramètres ou options non définis. Une spécification technique peut être entièrement autonome ou elle peut incorporer la substance d'autres spécifications par référence à d'autres documents (qui sont ou non des standards Internet). Une spécification technique devra comprendre une déclaration de sa portée (scope) et l'intention générale de son utilisation (champs d'application). Ainsi, une spécification technique spécifique par nature à un contexte particulier contiendra une déclaration dans ce sens. Par contre, une spécification technique ne définit pas les conditions de son utilisation au sein d'Internet : ces conditions, qui dépendent du contexte particulier dans lequel la spécification technique est incorporée par des configurations de systèmes différentes, sont définies par une déclaration d'applicabilité. 3.2. Déclaration d'applicabilité (AS) Une déclaration d'applicabilité définit comment et dans quelles circonstances une ou plusieurs spécifications techniques sont appliquées pour soutenir une capacité Internet particulière. Une déclaration d'applicabilité peut définir des utilisations pour des spécifications techniques qui ne sont pas des standards Internet, comme indiqué dans la section 7. Une déclaration d'applicabilité identifie les spécifications techniques pertinentes et la façon particulière de les combiner ; elle peut aussi définir les valeurs particulières ou intervalles de paramètres de spécifications techniques, ou les sous-fonctions d'une spécification technique de protocole à mettre en œuvre. Une déclaration d'applicabilité définit également les circonstances dans lesquelles l'utilisation d'une spécification technique est obligatoire, recommandée ou élective (cf. la section 3.3). Une déclaration d'applicabilité peut décrire les méthodes particulières d'utilisation d'une spécification technique dans un « domaine d'applicabilité » restreint tel que des routeurs Internet, des serveurs terminaux, des systèmes Internet en interface de réseaux Ethernet ou des serveurs de bases de données utilisant des datagrammes. Le type de déclaration d'applicabilité le plus large est représenté par une spécification de conformité exhaustive, appelée couramment un « document d'exigences » (requirements document), pour une classe particulière de systèmes Internet tels que des routeurs Internet ou des hôtes Internet. Une déclaration d'applicabilité dans le circuit des standards ne peut pas avoir un niveau de maturité supérieur à celui d'une spécification technique du circuit des standards dont elle dépend (cf. la section 4.1). Par exemple, une spécification technique au niveau de standard préliminaire (Draft Standard) peut être référencée par une déclaration d'applicabilité à un niveau de standard proposé (Proposed Standard) ou de standard préliminaire, mais pas par une déclaration d'applicabilité au niveau de standard (Standard). 3.3. Niveaux d'exigence Une déclaration d'applicabilité appliquera l'un des « niveaux d'exigence » (requirement levels) suivants à chaque spécification technique à laquelle elle se rapporte : (a) Obligatoire (Required) : une mise en œuvre de la spécification technique référencée, comme défini par la déclaration d'applicabilité, est tenue d'atteindre une conformité minimale. Par exemple, tous les systèmes Internet utilisant la suite de protocoles TCP/IP doivent mettre en œuvre les protocoles IP et ICMP. (b) Recommandé (Recommended) : une mise en œuvre de la spécification technique référencée n'est pas tenue à une conformité minimale, mais l'expérience ou une sagesse technique généralement acceptée suggèrent son utilisation dans le domaine d'application de la déclaration d'applicabilité. Les vendeurs sont vivement encouragés à inclure dans leurs produits les fonctions, les caractéristiques et les protocoles des spécifications techniques recommandées, et ils ne devraient les omettre que si cela est justifié par des circonstances particulières. Par exemple, tous les systèmes utilisant un accès distant devraient mettre en œuvre le protocole TELNET. (c) Électif (Elective) : une mise en œuvre de la spécification technique référencée est optionnelle dans le domaine d'application de la déclaration d'applicabilité, c'est-à-dire que la déclaration d'applicabilité n'établit aucune nécessité explicite d'appliquer la spécification technique. Toutefois, un vendeur particulier peut décider de la mettre en œuvre, ou un utilisateur particulier décider qu'elle est nécessaire dans un environnement spécifique. Par exemple, la base de données MIB DECNET pourrait se révéler précieuse dans un environnement où le protocole DECNET est utilisé. Comme indiqué dans la section 4.1, il y a des spécifications techniques qui sont hors du circuit des standards ou qui en ont été retirées, et qui ne sont donc pas obligatoires ni recommandées ni électives. Deux autres appellations de niveau d'exigence sont disponibles pour ces spécifications techniques : (d) Utilisation limitée (Limited Use) : l'utilisation de la spécification technique est considérée comme appropriée uniquement dans des circonstances limitées ou uniques. Par exemple, l'utilisation d'un protocole avec l'appellation Experimental devrait généralement se limiter à ceux impliqués activement dans l'expérience. (e) Non recommandé (Not Recommended) : une spécification technique considérée comme inappropriée pour une utilisation générale est étiquetée « Non recommandée ». Cela peut être à cause de sa fonctionnalité limitée, de sa nature spécialisée ou de son statut historique. Bien que les spécifications techniques (TS) et les déclarations d'applicabilité (AS) soient conceptuellement distinctes, en pratique, un document du circuit des standards peut combiner une déclaration d'applicabilité et une ou plusieurs spécifications techniques apparentées. Ainsi, les spécifications techniques développées spécialement et exclusivement pour un domaine d'application particulier, par exemple pour des serveurs de courrier électronique, contiennent souvent dans une seule spécification toutes les informations pertinentes de la déclaration d'applicabilité et des spécifications techniques. Pour ces cas, il ne serait d'aucune utilité de répartir délibérément les informations entre plusieurs documents juste pour conserver la distinction formelle AS/TS. En revanche, une spécification technique qui s'appliquera vraisemblablement à plusieurs domaines d'application devrait être développée de façon modulaire, pour faciliter son incorporation à de multiples déclarations d'applicabilité. Le RFC Official Protocol Standard (STD1) attribue un niveau d'exigence général à chaque spécification technique, en utilisant la nomenclature définie dans cette section. Ce RFC est mis à jour périodiquement. Dans beaucoup de cas, on trouvera dans les déclarations d'applicabilité appropriées des descriptions plus détaillées des niveaux d'exigence concernant des protocoles particuliers et leurs caractéristiques individuelles. 4. Le circuit des standards Internet Les spécifications destinées à devenir des standards Internet évoluent à travers un ensemble de niveaux de maturité connu sous le nom de « circuit des standards » (standards track). Ces niveaux de maturité, à savoir standard proposé (Proposed Standard), standard préliminaire (Draft Standard) et standard (Standard), sont définis et expliqués dans la section 4.1. La façon dont les spécifications se meuvent dans le circuit des standards est décrite dans la section 6. Même après qu'une spécification a été adoptée comme standard Internet, il y a souvent d'autres évolutions en fonction de l'expérience et de la reconnaissance de nouvelles exigences. La nomenclature et les procédures de standardisation Internet pourvoient au remplacement des vieux standards retirés.Un ensemble de niveaux de maturité est défini dans la section 4.2 pour couvrir à la fois ces cas et ceux des autres spécifications non censées faire partie du circuit des standards. 4.1. Les niveaux de maturité du circuit des standards Les spécifications Internet passent par des stades de développement, d'essai et d'acceptation. Dans le processus de standardisation Internet, ces stades s'intitulent formellement des « niveaux de maturité » (maturity levels). Cette section décrit les niveaux de maturité et les caractéristiques attendues des spécifications à chaque niveau. 4.1.1. Proposed Standard Le niveau de maturité d'entrée du circuit des standards est celui de standard proposé (Proposed Standard). Une action spécifique de l'IESG est nécessaire afin de placer une spécification sur le circuit des standards au niveau Proposed Standard. Une spécification au stade Proposed Standard est généralement stable, a tranché entre les différents choix de conception envisagés, est supposée bien comprise, a été examinée en profondeur par la communauté, et semble jouir d'un intérêt suffisant de la communauté pour être considérée comme valable. Toutefois, d'autres études pourraient aboutir au changement ou même à la rétractation de la spécification avant qu'elle ne progresse. Habituellement, ni une mise en œuvre ni une expérience d'exploitation ne sont nécessaires pour élever une spécification au rang de standard proposé. Quoi qu'il en soit, une telle expérience est très souhaitable et constituera généralement un argument fort en faveur de la désignation d'un standard proposé. L'IESG peut imposer une mise en œuvre ou une expérience d'exploitation avant d'accorder le statut de standard proposé à une spécification qui affecte structurellement le noyau des protocoles Internet ou qui définit un comportement susceptible d'avoir un impact important sur le fonctionnement d'Internet. Un standard proposé ne devrait pas avoir de lacunes techniques connues par rapport aux exigences placées sur lui. Toutefois, l'IESG peut renoncer à cette condition pour permettre à une spécification d'avancer au stade de standard proposé lorsque celle-ci est considérée comme utile et nécessaire (et opportune), même avec des lacunes techniques connues. Les développeurs devraient traiter les standards proposés comme des spécifications immatures. Il est souhaitable de les mettre en œuvre afin d'acquérir de l'expérience et de valider, tester et clarifier la spécification. Par contre, puisque le contenu des standards proposés peut changer si des problèmes sont découverts ou de meilleures solutions identifiées, il n'est pas recommandé de déployer des mises en œuvre fondées sur de tels standards dans un environnement sensible aux perturbations. 4.1.2. Draft Standard Une spécification d'après laquelle au moins deux mises en œuvre indépendantes et interopérables ont été développées, issues de bases de code différentes, et pour laquelle une expérience d'exploitation réussie suffisante a été obtenue, peut être élevée au niveau de standard préliminaire (Draft Standard). Pour les besoins de cette section, le terme « interopérable » désigne des composants fonctionnellement équivalents ou interchangeables du système ou du processus qui les utilise. Si une technologie brevetée ou contrôlée autrement est nécessaire pour la mise en œuvre, les mises en œuvre séparées doivent aussi provenir d'un exercice distinct du processus de licence. L'élévation au stade de standard préliminaire constitue une avancée majeure du statut, marquant une grande confiance en la maturité et l'utilité de la spécification. L'exigence d'au moins deux mises en œuvre indépendantes et interopérables s'applique à toutes les options et caractéristiques de la spécification. En cas de non-démonstration de l'une ou de plusieurs options ou caractéristiques dans au moins deux mises en œuvre interopérables, la spécification ne pourra avancer au niveau de standard préliminaire que si ces options ou caractéristiques sont supprimées. Le président du groupe de travail est chargé de la documentation des mises en œuvre spécifiques qui qualifient la spécification au statut de standard préliminaire ou de standard Internet, et de la documentation des essais d'interopérabilité de ces mises en œuvre. La documentation doit inclure les données concernant la gestion de chacune des options et caractéristiques individuelles. Cette documentation devrait être transmise au responsable de domaine (Area Director) selon la demande d'action de protocole (protocol action request), cf. la section 6. Un standard préliminaire doit être bien compris et connu comme suffisamment stable, à la fois dans sa sémantique et comme base de développement des mises en œuvre. Un standard préliminaire peut encore nécessiter une expérience de terrain supplémentaire ou plus étendue, puisqu'il est possible que des mises en œuvre fondées sur des spécifications au stade standard préliminaire présentent des comportements imprévus en utilisation intensive dans des environnements de production. Un standard préliminaire est normalement considéré comme une spécification finale, et des changements n'interviendront probablement que pour résoudre les problèmes spécifiques rencontrés. Dans la plupart des cas, les vendeurs peuvent raisonnablement déployer les mises en œuvre de standards préliminaires dans un environnement sensible aux perturbations. 4.1.3. Internet Standard Une spécification pour laquelle une mise en œuvre significative et une expérience d'exploitation réussie ont été obtenues peut être élevée au niveau de standard Internet (Internet Standard). Un standard Internet (appelé simplement un standard) est caractérisé par un haut degré de maturité technique et par l'opinion générale que le protocole ou le service définis apportent un avantage important à la communauté Internet. Une spécification obtenant le statut de standard reçoit un numéro dans la série des STD tout en conservant son numéro de RFC. 4.2. Les niveaux de maturité hors du circuit des standards Les spécifications ne sont pas toutes dans le circuit des standards. Une spécification n'est pas forcément destinée à devenir un standard Internet, ou elle peut rechercher une éventuelle standardisation mais n'est pas prête pour entrer dans le circuit des standards. Une spécification peut avoir été remplacée par un standard Internet plus récent, ou sinon être tombée en désuétude ou en défaveur. Les spécifications qui ne sont pas dans le circuit des standards sont étiquetées d'un des trois niveaux de maturité « hors circuit » : « Experimental », « Informational » ou « Historic ». Les documents portant ces étiquettes ne sont en aucune façon des standards. 4.2.1. Experimental L'appellation Experimental désigne typiquement une spécification qui fait partie d'un effort de recherche ou de développement. Une telle spécification est publiée pour l'information générale de la communauté technique Internet et comme document d'archives du travail, susceptible seulement de considérations éditoriales et de vérification de l'articulation adéquate avec le processus de standardisation (voir plus loin). Une spécification expérimentale peut être le produit d'un effort organisé de recherche Internet (par exemple, un groupe de recherche de l'IRTF), d'un groupe de travail IETF ou d'une contribution individuelle. 4.2.2. Informational Une spécification informationnelle est publiée pour l'information générale de la communauté Internet et elle ne représente pas un consensus ou une recommandation de la communauté Internet. L'appellation Informational pourvoit à la publication au bon moment d'un très large éventail de documents informationnels responsables issus de nombreuses sources, susceptible seulement de considérations éditoriales et de vérification de l'articulation adéquate avec le processus de standardisation (cf. la section 4.2.3). Les spécifications préparées hors de la communauté Internet et non incorporées au processus de standardisation Internet selon une des dispositions de la section 10 peuvent être publiées comme RFC informationnels, avec la permission de l'auteur et le concours de l'éditeur des RFC (RFC Editor). 4.2.3. Les procédures des RFC expérimentaux et informationnels ************************************************************************ À moins d'être le résultat d'une action d'un groupe de travail IETF, les documents à publier avec un statut Experimental ou Informational devraient être soumis directement à l'éditeur des RFC. L'éditeur des RFC publiera en tant que projets Internet (Internet-Drafts) ces documents qui n'auraient pas déjà été publiés comme tels. Pour différencier ces projets Internet, ils seront étiquetés ou regroupés dans le répertoire Internet-Drafts où ils seront aisément reconnaissables. L'éditeur des RFC recueillera les commentaires pendant 2 semaines suivant la publication, avant de poursuivre. L'éditeur des RFC est censé agir avec discernement concernant la recevabilité éditoriale d'un document à publier avec un statut Experimental ou Informational, et il peut refuser de publier un document qui, de l'avis expert de l'éditeur, est étranger à l'activité Internet ou qui est inférieur aux standards techniques ou éditoriaux pour un RFC. Afin d'empêcher que l'on abuse des appellations hors circuit des standards Experimental et Informational dans le but de contourner le processus de standardisation Internet, l'IESG et l'éditeur des RFC ont convenu que l'éditeur des RFC signalera à l'IESG tout document soumis à publication avec un statut Experimental ou Informational qui, de l'avis de l'éditeur, serait en rapport avec un travail en cours ou prévu d'être réalisé dans la communauté IETF. L'IESG examinera le document signalé dans un délai raisonnable et recommandera soit de le publier comme soumis au départ, soit de le renvoyer à l'IETF comme une contribution au processus de standardisation Internet. Si (a) l'IESG recommande de porter le document à l'IETF et de le poursuivre dans le contexte de l'IETF, et que l'auteur refuse de le faire, ou (b) si l'IESG considère que le propos du document entre en conflit avec, ou est réellement inamical envers, un effort IETF établi, le document peut toujours être publié comme RFC expérimental ou informationnel. Auquel cas, cependant, l'IESG peut insérer un « avis de non-responsabilité » approprié dans le RFC, soit dans la section « Statut de ce mémoire », soit immédiatement après, afin d'éclairer les circonstances de sa publication auprès des lecteurs. Les documents proposés comme RFC expérimentaux ou informationnels par les groupes de travail IETF sont examinés par l'IESG. La validation est lancée en fonction du processus décrit dans la section 6.1.1. 4.2.4. Historic Une spécification qui a été remplacée par une spécification plus récente, ou qui est pour toute autre raison considérée comme obsolète, est affectée du niveau Historic. (Des puristes ont suggéré « Historical » ; quoi qu'il en soit, de nos jours, l'utilisation d'Historic est historique.) Remarque : Normalement, les spécifications du circuit des standards ne doivent pas dépendre d'autres spécifications du circuit des standards à un niveau de maturité inférieur, ou d'autres spécifications hors du circuit des standards sauf référencées auprès d'autres instances de normalisation (standards bodies), cf. la section 7. 5. Les RFC de pratiques exemplaires courantes (BCP) La sous-série des BCP (Best Current Practice) de la série des RFC est conçue comme un moyen de standardiser les pratiques et les résultats de délibérations de la communauté. Un document BCP est soumis au même ensemble de procédures de base que les documents du circuit des standards, et c'est donc un vecteur par lequel la communauté IETF peut définir et ratifier les meilleures réflexions courantes sur une déclaration de principe ou sur ce qui est estimé la meilleure façon d'effectuer certaines opérations ou la meilleure façon de réaliser une fonction du processus de l'IETF. Historiquement, les standards Internet traitaient généralement des spécifications techniques pour les matériels et logiciels nécessaires à la communication informatique à travers des réseaux interconnectés. Néanmoins, puisque Internet même se compose de réseaux exploités par des organisations très variées, avec des buts et des règles différents, un bon service aux utilisateurs exige des opérateurs et des administrateurs de l'Internet qu'ils suivent des normes de guide et d'exploitation communes. Bien que ces normes soient généralement différentes dans leur portée et leur style des standards de protocoles, leur constitution a besoin d'un processus similaire pour la réalisation d'un consensus. De la même façon que des entités telles que l'IAB et l'IESG se composent d'individus pouvant participer à titre individuel au travail technique de l'IETF, les entités elles-mêmes ont également le rôle de guides dans la communauté. En tant que guides dans la communauté technique Internet, ces entités devraient disposer d'un canal d'information pour proposer des idées afin de stimuler les travaux dans un domaine particulier, pour éveiller la sensibilité de la communauté sur un certain problème, pour faire une déclaration de principe d'architecture ou pour communiquer leurs réflexions sur d'autres sujets. La sous-série des BCP permet à ces entités administratives (management entities) d'insérer de façon structurée et en douceur des propositions dans les rouages de la construction du consensus de l'IETF tout en jaugeant la vision de la communauté sur la question. Enfin, la série des BCP peut être utilisée pour documenter le fonctionnement de l'IETF même. Par exemple, ce document qui définit le processus de standardisation IETF est publié en tant que BCP. 5.1. Le processus de validation des BCP À la différence des documents du circuit des standards, les mécanismes décrits dans les BCP sont mal adaptés aux rappels par phase en trois stades du circuit des standards et n'ont en général plutôt de sens que pour une instanciation entière et immédiate. Le processus des BCP est similaire à celui des standards proposés. Le BCP est soumis à l'IESG pour examen (cf. la section 6.1.1) et le processus de validation existant s'applique, y compris un dernier appel (Last-Call) sur la liste de diffusion Announce de l'IETF. Par contre, une fois le document approuvé par l'IESG, le processus se termine et le document est publié. Le document final est présumé avoir l'approbation technique de l'IETF. Spécifiquement, pour recevoir le statut de BCP, un document doit suivre les procédures décrites dans les sections 6.1 et 6.4 de ce document. Le processus des BCP peut faire l'objet d'un appel conformément aux procédures de la section 6.5. Dans la mesure où les BCP sont censés exprimer un consensus de la communauté mais en y parvenant plus rapidement que les standards, ils nécessitent une attention particulière. Spécifiquement, les BCP ne devraient pas simplement être vus comme des RFC informationnels plus forts mais plutôt comme des documents adaptés à un contenu différent de celui des RFC informationnels. Une spécification (ou un groupe de spécifications) qui a été approuvée comme BCP reçoit un numéro dans la série des BCP tout en conservant son numéro (ou leurs numéros) de RFC. 6. Le processus de standardisation Internet La mécanique du processus de standardisation Internet implique des décisions de l'IESG concernant l'entrée d'une spécification dans le circuit des standards ou le mouvement d'une spécification du circuit des standards d'un niveau de maturité à l'autre. Bien que nombre de critères objectifs raisonnables (décrits ci-dessous et dans la section 4) soient disponibles pour guider l'IESG dans sa décision de placer, promouvoir ou sortir une spécification du circuit des standards, il n'y a aucune garantie d'entrée ou de progression automatique d'une spécification dans le circuit des standards. Le jugement collectif émérite de l'IESG sur la qualité technique d'une spécification proposée pour l'entrée ou la promotion dans le circuit des standards est un composant essentiel du processus de prise de décision. 6.1. Les actions de standardisation Une « action de standardisation » (standards action), à savoir l'entrée d'une spécification particulière dans le circuit des standards, sa promotion ou son retrait, doit être approuvée par l'IESG. 6.1.1. Le lancement d'une action Une spécification destinée à entrer ou à progresser dans le circuit des standards Internet devra d'abord être publiée comme projet Internet (cf. la section 2.2), à moins de n'avoir pas changé depuis sa publication comme RFC. Elle devra rester à l'état de projet Internet pendant une certaine période, 2 semaines au moins, permettant une revue utile par la communauté, à la suite de quoi une recommandation d'action peut être lancée. L'action de standardisation est lancée par la recommandation du groupe de travail IETF responsable de la spécification auprès de son responsable de domaine (Area Director), avec copie au secrétariat de l'IETF ou, dans le cas d'une spécification non associée à un groupe de travail, par la recommandation d'un individu auprès de l'IESG. 6.1.2. La validation et l'approbation de l'IESG L'IESG déterminera si une spécification qui lui est soumise conformément à la section 6.1.1 satisfait ou non aux critères applicables pour l'action recommandée (cf. les sections 4.1 et 4.2), et devra en plus déterminer si la qualité et la clarté techniques de la spécification sont compatibles ou non avec celles attendues pour le niveau de maturité auquel la spécification est recommandée. Afin d'obtenir tous les renseignements nécessaires à ces déterminations, l'IESG peut commanditer à sa discrétion une analyse technique indépendante de la spécification, surtout lorsque l'IESG considère la spécification extrêmement importante en ce qui concerne son impact potentiel sur Internet ou la suite des protocoles Internet. L'IESG avertira l'IETF de son évaluation en cours du (ou des) document(s) afin de permettre un examen final par la communauté Internet en général. Cette notification de dernier appel (Last-Call) aura lieu via un courrier électronique sur la liste de diffusion Announce de l'IETF. Les commentaires de tous sur un document de dernier appel seront acceptés et devraient être envoyés selon les instructions dans l'annonce de dernier appel. La période de dernier appel ne sera pas inférieure à 2 semaines, sauf si l'action de standardisation proposée n'était pas initiée par un groupe de travail IETF, auquel cas la période de dernier appel ne sera pas inférieure à 4 semaines. Si l'IESG estime qu'un délai supérieur est nécessaire pour les commentaires dans l'intérêt de la communauté, l'IESG peut décréter une période de dernier appel plus longue, ou la prolongation explicite de la période de dernier appel courante. L'IESG n'est pas contraint par l'action recommandée lors de la soumission de la spécification. Par exemple, l'IESG peut décider d'examiner la spécification pour publication dans une autre catégorie que celle demandée. Si l'IESG le détermine avant l'annonce de dernier appel, son point de vue devrait être reflété dans le dernier appel. L'IESG pourrait également décider de changer la catégorie de publication en fonction de la réponse à un dernier appel. Si cette décision se traduisait par la publication de la spécification à un niveau supérieur de celui du dernier appel initial, une nouvelle annonce de dernier appel devrait être faite pour indiquer la décision de l'IESG. En outre, l'IESG peut recommander la formation d'un nouveau groupe de travail en cas de controverse importante en réponse au dernier appel d'une spécification ne provenant pas d'un groupe de travail IETF. À l'expiration de la période de dernier appel et dans les meilleurs délais, l'IESG prendra sa décision finale d'approuver ou non l'action de standardisation et en avertira l'IETF par un courrier électronique sur la liste de diffusion Announce de l'IETF. 6.1.3. La publication Si l'action de standardisation est approuvée, une notification est envoyée à l'éditeur des RFC en copie à l'IETF avec instruction de publier la spécification comme RFC. La spécification sera retirée du répertoire Internet-Drafts à ce moment. Un résumé officiel des actions de standardisation terminées et en cours apparaîtra dans chaque numéro de la lettre de diffusion de l'Internet Society. Elle constituera la « publication des minutes » (publication of record) des actions de standardisation Internet. L'éditeur des RFC devra publier périodiquement un RFC intitulé Internet Official Protocol Standards [1], résumant le statut de toutes les spécifications de protocoles et de services. 6.2. La progression dans le circuit des standards La procédure décrite dans la section 6.1 est observée pour chaque action qui accompagne la progression d'une spécification au long du circuit des standards. Une spécification restera au niveau de standard proposé (Proposed Standard) pendant au moins 6 mois. Une spécification restera au niveau de standard préliminaire (Draft Standard) pendant au moins 4 mois, ou jusqu'à ce qu'au moins une réunion de l'IETF ait eu lieu, selon le dernier à survenir. Ces périodes minimales ont pour but d'assurer un délai d'examen suffisant par la communauté sans nuire à la ponctualité. Ces intervalles seront mesurés depuis la date de publication du (ou des) RFC correspondant(s), ou, si l'action n'aboutit pas à la publication d'un RFC, depuis la date de l'annonce d'approbation de l'action par l'IESG. Une spécification peut être révisée (en fait, ce sera probablement le cas) au cours de sa progression à travers le circuit des standards. À chaque stade, l'IESG déterminera la portée et l'importance de la révision pour la spécification et, si nécessaire et approprié, modifiera l'action recommandée. Des révisions mineures sont à prévoir mais une révision majeure peut nécessiter une expérimentation supplémentaire de la spécification à son niveau de maturité courant avant toute progression. Enfin, si la spécification a reçu beaucoup de modifications, l'IESG peut recommander de traiter la révision comme un nouveau document, en reprenant le circuit des standards au début. Un changement de statut se traduira par la republication de la spécification comme RFC, sauf dans le cas rare où il n'y aura eu aucune modification du tout depuis la dernière publication. En général, les modifications souhaitées seront différées et incorporées au niveau suivant dans le circuit des standards. Toutefois, le report des modifications de la spécification sur l'action de standardisation suivante ne sera pas toujours possible ou souhaitable. Par exemple, une erreur de typographie importante ou une erreur technique qui ne représentent pas un changement de la fonction d'ensemble de la spécification peuvent nécessiter une correction immédiate. Auquel cas, on peut demander à l'IESG ou à l'éditeur des RFC de republier le RFC (sous un nouveau numéro) avec les corrections, sans réinitialisation de la durée minimale à ce niveau. Lorsqu'une spécification du circuit des standards n'a pas atteint le niveau de standard Internet mais est restée au même niveau de maturité pendant 24 mois, et tous les 12 mois ensuite jusqu'à un changement de statut, l'IESG examinera la viabilité de l'effort de standardisation responsable de cette spécification et l'utilité de la technologie. À l'issue de chaque examen, l'IESG confirmera la dissolution ou la continuation de l'effort de développement, et décidera à cette occasion de maintenir la spécification au même niveau de maturité ou de lui affecter le statut d'historique (Historic). Cette décision sera communiquée à l'IETF par un courrier électronique sur la liste de diffusion Announce de l'IETF pour y être commentée par la communauté Internet. Cette disposition ne constitue pas une menace à l'encontre de l'effort d'un groupe de travail légitime et actif mais un mécanisme administratif pour terminer un effort moribond. 6.3. La révision d'un standard Une nouvelle version d'un standard Internet établi doit progresser à travers tout le processus de standardisation Internet comme s'il s'agissait d'une spécification entièrement nouvelle. Une fois le niveau de standard (Standard) atteint par la nouvelle version, elle remplacera généralement la précédente qui recevra le statut d'historique (Historic). Toutefois, dans certains cas les deux versions peuvent rester au statut de standard Internet (Internet Standard) pour honorer les exigences d'une base installée. Dans une telle situation, la relation entre la version précédente et la nouvelle doit être explicitement mentionnée dans le texte de la nouvelle version ou d'un autre document approprié (par exemple, une déclaration d'applicabilité, cf. la section 3.2). 6.4. Le retrait d'un standard Avec l'évolution et la maturité des technologies, il peut arriver qu'une nouvelle spécification de standard soit si manifestement supérieure techniquement qu'une ou plusieurs spécifications du circuit des standards de même fonction doivent être retirées. Auquel cas, ou si pour une autre raison il est estimé qu'une spécification du circuit des standards devrait être retirée, l'IESG approuvera le changement du statut de la spécification (ou des spécifications) existante(s) pour Historic. Cette recommandation devra être effectuée selon les mêmes procédures de dernier appel et de notification utilisées pour toute autre action de standardisation. La demande de retrait d'un standard existant peut provenir d'un groupe de travail, d'un responsable de domaine ou d'un autre tiers intéressé. 6.5. La résolution des conflits et les appels Des désaccords peuvent survenir à divers stades du processus IETF. Autant que possible, le processus est conçu de telle sorte que l'on puisse faire des compromis et parvenir à un véritable consensus, mais parfois même les personnes les plus raisonnables et les plus informées n'arrivent pas à se mettre d'accord. Pour respecter les objectifs d'ouverture et d'impartialité, ces conflits doivent être résolus par un processus de critique et de discussion transparentes. Cette section décrit les procédures à suivre pour traiter les problèmes des standards Internet non solutionnables par le processus habituel avec lequel les groupes de travail IETF et les autres intervenants du processus des standards Internet aboutissent normalement à un accord. 6.5.1. Les désaccords des groupes de travail Une personne (qu'elle participe ou non au groupe de travail concerné) peut être en désaccord avec la recommandation d'un groupe de travail, estimant que (a) ses propres positions n'ont pas été convenablement évaluées par le groupe de travail, ou bien (b) qu'un choix technique erroné met en grand péril la qualité ou l'intégrité des produits du groupe de travail. Le premier objet de litige est un problème de fonctionnement du groupe de travail, le dernier est l'affirmation d'une erreur technique. Bien que ces deux types de contentieux soient très différents, ils sont traités par un même processus d'examen. Une personne en désaccord avec la recommandation d'un groupe de travail devrait d'abord en faire part au président (ou aux présidents) du groupe de travail, lequel peut convier d'autres membres du groupe (ou le groupe de travail entier) à la discussion. Si le désaccord persiste, chacune des parties concernées peut le porter à l'attention du responsable (ou des responsables) de domaine (Area Director) du domaine auquel le groupe de travail est affecté. Le responsable (ou les responsables) de domaine essaiera de résoudre le litige. Si le désaccord ne peut être résolu par le responsable (ou les responsables) de domaine, chacune des parties concernées peut alors faire appel auprès de l'IESG dans son ensemble. Puis l'IESG examinera la situation et essaiera d'y remédier à sa convenance. Si la résolution au niveau de l'IESG ne satisfait pas les parties, chacune des parties concernées peut faire appel de la décision auprès de l'IAB. Puis l'IAB examinera la situation et essaiera d'y remédier à sa convenance. La décision de l'IAB est définitive en ce qui concerne la question du respect ou non des procédures de standardisation Internet et pour toutes les questions de nature technique. 6.5.2. Les faillites du processus Ce document établit les procédures extraordinaires nécessaires à observer pour assurer l'ouverture et l'impartialité du processus de standardisation Internet et la viabilité technique des standards créés. L'IESG est l'agent principal de l'IETF dans ce but, et c'est la tâche de l'IESG de s'assurer que les procédures édictées ont été observées et que les conditions d'une action de standardisation ont été respectées. Si une personne est en désaccord avec une action prise par l'IESG au cours de ce processus, elle devrait d'abord en faire part au président de l'IESG (IESG Chair). Si le président ne peut convaincre le plaignant, l'IESG dans son ensemble doit alors réexaminer l'action engagée, en même temps que l'avis du plaignant, et déterminer si une autre action est nécessaire. L'IESG informera l'IETF de son instruction de la plainte. Si le plaignant n'est pas satisfait des conclusions de l'IESG, un appel peut être formulé auprès de l'IAB. Puis l'IAB examinera la situation et essaiera d'y remédier à sa convenance, et informera l'IETF de ses conclusions. Si les circonstances le justifient, l'IAB peut ordonner l'annulation d'une décision de l'IESG, et la situation redeviendra alors celle qu'elle était avant la décision de l'IESG. L'IAB peut également recommander une action à l'IESG ou faire toutes autres recommandations en ce sens jugées nécessaires. Par contre, l'IAB ne peut pas empiéter sur le rôle de l'IESG en arrêtant une décision que seul l'IESG est habilité à prendre. La décision de l'IAB est définitive en ce qui concerne la question du respect ou non des procédures de standardisation Internet. 6.5.3. La pertinence des procédures Un recours de plus est prévu seulement pour les cas où les procédures elles-mêmes (c'est-à-dire les procédures décrites dans ce document) sont prétendues inadéquates ou insuffisantes à protéger les droits de toutes les parties dans un processus de standardisation Internet impartial et ouvert. Les réclamations de cette nature peuvent être déposées auprès du conseil d'administration (Board of Trustees) de l'Internet Society. Le président de l'Internet Society devra être informé de cet appel dans les 2 semaines, et lui-même devra aviser le requérant, dans un accusé de réception, des délais prévisibles de l'examen en appel par les administrateurs (Trustees). Les administrateurs examineront la situation à leur convenance et informeront l'IETF de leurs conclusions. La décision des administrateurs à l'issue de leur instruction sera définitive en ce qui concerne tous les aspects litigieux. 6.5.4. La procédure d'appel Tous les pourvois en appel doivent inclure une description détaillée et spécifique des faits du litige. Tous les pourvois en appel doivent être déposés dans les 2 mois suivant la publication de l'action ou de la décision contestées. À tous les stades du processus d'appel, les personnes ou les organismes responsables de la prise de décisions ont le loisir de définir les procédures spécifiques qu'ils suivront pour arriver à leur décision. Dans tous les cas, la décision concernant le traitement du litige et la communication de cette décision aux parties engagées doivent être accomplies dans un délai raisonnable. Remarque : Ces procédures, intentionnellement et explicitement, n'établissent pas de délai fixe maximal considéré comme « raisonnable » dans tous les cas. Le processus de standardisation Internet privilégie le consensus et les efforts pour y parvenir, et renonce délibérément à des procédures prédéterminées rapidement exécutées, en faveur d'une latitude où l'on parvient à des accords techniques plus authentiques. 7. Les normes et spécifications externes Hormis l'IETF, beaucoup de groupes de normalisation créent et publient des normes de protocoles de réseaux et de services. Lorsque ces spécifications externes jouent un rôle important dans Internet, il convient de trouver un terrain d'entente pour leur utilisation, c'est-à-dire d'établir des standards Internet concernant ces spécifications externes. Il y a deux catégories de spécifications externes : (1) Les normes ouvertes (Open Standards) Divers organismes de normalisation nationaux et internationaux, tels que l'ANSI, l'ISO, l'IEEE et l'ITU-T, développent une grande variété de spécifications de protocoles et de services similaires aux spécifications techniques définies ici. Certains groupes nationaux et internationaux publient également des « conventions de réalisation » (implementor agreements) qui sont analogues aux déclarations d'applicabilité (Applicability Statement), en capturant un corpus de détails spécifiques d'une mise en œuvre en rapport avec l'application pratique de leurs normes. Tous ces documents sont considérés comme des « normes ouvertes externes » pour le processus de standardisation Internet. (2) Les autres spécifications D'autres spécifications propriétaires dont l'utilisation s'est généralisée dans Internet peuvent être traitées par la communauté Internet comme des standards. Une spécification de ce genre n'est en général pas développée ouvertement, est typiquement brevetée (proprietary), et est contrôlée par le vendeur, les vendeurs ou l'organisation qui l'ont produite. 7.1. L'utilisation des spécifications externes Pour éviter les conflits entre des versions concurrentes d'une spécification, la communauté Internet ne normalisera pas une spécification qui est simplement une « version Internet » d'une spécification externe existante, à moins qu'un accord de coopération explicite ne soit pris en ce sens. Par contre, une spécification externe, importante pour le fonctionnement ou l'évolution d'Internet, peut être adoptée pour une utilisation Internet de plusieurs façons. 7.1.1. L'incorporation d'une norme ouverte Un standard Internet de type spécification technique ou déclaration d'applicabilité peut incorporer un standard ouvert externe par référence. Par exemple, beaucoup de standards Internet incorporent par référence le jeu de caractères normalisé "ASCII" [2] de l'ANSI. Autant que possible, la spécification référencée devra être disponible en ligne. 7.1.2. L'incorporation des autres spécifications D'autres spécifications propriétaires peuvent être incorporées par référence dans une version de la spécification tant que leurs détenteurs satisfont aux exigences de la section 10. Si l'autre spécification propriétaire n'est pas largement et immédiatement disponible, l'IESG peut demander qu'elle soit publiée comme RFC informationnel (Informational). L'IESG ne devrait généralement pas favoriser une spécification propriétaire particulière par rapport à une ou plusieurs spécifications concurrentes techniquement équivalentes en rendant obligatoire ou recommandée la spécification incorporée d'un vendeur. 7.1.3. La prise en charge Un groupe de travail IETF peut démarrer à partir d'une spécification externe et la développer en une spécification Internet. C'est acceptable si (1) la spécification est fournie au groupe de travail en conformité avec les exigences de la section 10, et (2) le développeur original de la spécification a passé le contrôle des modifications de la spécification ou des spécifications dérivées de l'originale à l'IETF. 8. Les annonces et la tenue des archives Chaque organisation impliquée dans le développement et la validation de standards Internet devra annoncer publiquement et tenir une liste accessible au public de chaque activité dans laquelle elle est engagée, dans la mesure où l'activité représente la continuation d'une partie du processus de standardisation Internet. Pour les besoins de cette section, les organisations impliquées dans le développement et la validation des standards Internet comprennent l'IETF, l'IESG, l'IAB, tous les groupes de travail IETF, et le conseil d'administration de l'Internet Society. Pour l'IETF et les réunions des groupes de travail, les annonces devront être faites par courrier électronique sur la liste de diffusion Announce de l'IETF, suffisamment en avance pour permettre à toutes les parties intéressées de participer. L'annonce devra contenir (ou pointer vers) toutes les informations nécessaires au soutien de la participation des intéressés. Dans le cas d'une réunion, par exemple, l'annonce devra inclure un calendrier des questions de standardisation qui seront abordées. L'enregistrement formel d'une activité de standardisation d'une organisation devra au moins inclure les renseignements suivants : la charte de l'organisation (ou un règlement équivalent d'une charte) ; les procès-verbaux complets et exacts des réunions ; les archives des courriers électroniques des listes de diffusion des groupes de travail ; toutes les contributions écrites des participants ayant un rapport avec l'activité de standardisation de l'organisation. Concrètement, les enregistrements formels de toutes les activités du processus de standardisation Internet sont conservés par le secrétariat de l'IETF, sauf que chaque groupe de travail IETF est censé tenir les archives de ses propres listes de diffusion et doit s'efforcer de capturer et inclure tous les échanges dans les archives. En outre, le président du groupe de travail est chargé de fournir au secrétariat de l'IETF les procès-verbaux complets et exacts de toutes les réunions du groupe de travail. Les projets Internet retirés du répertoire Internet-Drafts (quelle qu'en soit la raison) seront archivés par le secrétariat de l'IETF dans le seul but de conserver un document historique de l'activité de standardisation Internet, et ne sont donc pas récupérables sauf circonstances particulières. 9. La variation du processus Ce document, qui établit les règles et procédures selon lesquelles les standards Internet et documents apparentés sont fabriqués, est lui-même un produit du processus de standardisation Internet (en tant que BCP, comme décrit dans la section 5). Il remplace une version précédente et, avec le temps, sera probablement remplacé à son tour. Bien que ce document, lorsqu'il est publié, représente l'opinion de la communauté à propos du processus exact à suivre, et des conditions à réunir afin de produire les standards Internet et les BCP les meilleurs possibles, il n'est pas sûr que cela restera toujours le cas. De temps en temps, on voudra peut-être le mettre à jour, en le remplaçant par une nouvelle version. La mise à jour de ce document emprunte les mêmes procédures que celles utilisées pour n'importe quel autre BCP. Par ailleurs, des situations peuvent se présenter où l'observation des procédures mène à une impasse pour une spécification spécifique, et où les procédures n'offrent aucun guide. Dans ce cas, il faudra peut-être invoquer la procédure de dispense (variation procedure) décrite ci-dessous. 9.1. La procédure de dispense Sur la recommandation du groupe de travail IETF responsable (ou sur la recommandation d'un comité spécial, si aucun groupe de travail n'est constitué), l'IESG peut faire entrer une recommandation dans le circuit des standards, ou l'y faire progresser, même si certaines exigences de ce document ne sont pas respectées, ou ne le seront pas. L'IESG ne peut toutefois approuver un tel écart qu'en déterminant d'abord si les bénéfices potentiels pour la communauté Internet peuvent justifier les coûts induits par le non respect des exigences de ce document auprès de la communauté Internet. Dans l'exercice de ce pouvoir discrétionaire, l'IESG devra au minimum considérer (a) le mérite technique de la spécification, (b) la possibilité de réaliser les objectifs du processus de standardisation Internet sans accorder de dispense, (c) les alternatives au recours à une dispense, (d) les effets secondaires et de précédent du recours à une dispense et (e) la possibilité de créer une dispense aussi réduite que possible. Dans la détermination de la dispense, l'IESG a le droit d'en limiter la portée à des parties spécifiques de ce document et d'imposer les restrictions et limitations jugées nécessaires pour protéger les intérêts de la communauté Internet. La dispense proposée doit détailler le problème perçu, préciser la disposition de ce document justifiant son recours et indiquer les conclusions de l'IESG vis-à-vis des considérations des points (a) à (d) dans le paragraphe précédent. La dispense proposée sera publiée en tant que projet Internet. Puis l'IESG fera une annonce de dernier appel étendue, d'au moins 4 semaines, afin que la communauté puisse commenter la proposition. Rapidement après expiration de la période de dernier appel, l'IESG prendra sa décision finale d'approuver ou non la dispense proposée et en notifiera l'IETF par un courrier électronique sur la liste de diffusion Announce de l'IETF. Si la dispense est approuvée, elle sera transmise à l'éditeur des RFC avec instruction de la publier en tant que BCP. Cette procédure de dispense est à utiliser lorsque la modification ponctuelle d'une disposition de ce document semble nécessaire. Les changements permanents du document auront lieu au travers du processus BCP normal. Le processus d'appel de la section 6.5 s'applique à ce processus. 9.2. Les exclusions L'utilisation de cette procédure ne saurait en aucun cas réduire les délais indiqués, ni exempter une proposition quelconque des exigences d'ouverture, d'impartialité ou de consensus, ni de l'obligation de tenir des enregistrements corrects des discussions des réunions et des listes de diffusion. Spécifiquement, les sections suivantes de ce document ne peuvent pas faire l'objet d'une dispense : 5.1, 6.1, 6.1.1 (premier paragraphe), 6.1.2, 6.3 (première phrase), 6.5 et 9. 10. Les droits de propriété intellectuelle 10.1. La politique générale Dans toutes les questions de droits de propriété intellectuelle et de procédures, c'est le bénéfice de la communauté Internet et du public au sens large qui est visé, tout en respectant les droits légitimes des autres. 10.2. Les obligations de confidentialité Aucune contribution soumise à une quelconque condition de confidentialité ou restriction de diffusion n'est recevable dans une partie du processus de standardisation Internet, et il ne doit y avoir aucune présomption d'obligation de confidentialité en ce qui concerne une telle contribution. 10.3. Les droits et les permissions Au cours de la standardisation, l'IETF reçoit des contributions sous diverses formes et de nombreuses personnes. Pour faciliter la diffusion de ces contributions, il est nécessaire de comprendre quels sont les droits de propriété intellectuelle (IPR) se rapportant aux contributions. 10.3.1. Toutes les contributions En soumettant une contribution, chaque soumettant est censé accepter les termes et conditions suivants en son nom, au nom de l'organisation qu'il représente (le cas échéant) et au nom des détenteurs de droits de propriété dans la contribution. Lorsqu'une soumission identifie des contributeurs en plus du contributeur (ou des contributeurs) qui apporte effectivement la soumission, le soumettant effectif (ou les soumettants) fait valoir que chaque autre contributeur nommé a pris connaissance desdits termes et conditions et les a acceptés en son nom, au nom d'une organisation qu'il représente et de tout détenteur connu de droits de propriété (proprietary rights) dans la contribution. l. Certains travaux (par exemple, les travaux du gouvernement des États-Unis) ne sont pas soumis à des droits d'auteur. Toutefois, dans la mesure où la soumission est soumise à des droits d'auteur ou est susceptible de l'être, le contributeur, l'organisation qu'il représente (le cas échéant) et les détenteurs de droits de propriété dans la contribution concèdent une licence illimitée, perpétuelle, non exclusive, sans contrepartie, universelle à l'ISOC et l'IETF selon tous les droits d'auteur dans la contribution. Cette licence comprend le droit de copier, publier et distribuer la contribution sur tout support, et de préparer des œuvres dérivées qui se fondent sur ou incorporent tout ou partie de la contribution, la licence de ces œuvres dérivées étant du même ordre que celle de la contribution originale. 2. Le contributeur reconnaît que l'ISOC et l'IETF n'ont aucune obligation de publier ou sinon d'utiliser ou diffuser une quelconque contribution. 3. Le contributeur autorise la citation du nom et de l'adresse du contributeur (ou des contributeurs) et de l'organisation (ou des organisations) qu'il représente (le cas échéant). 4. Le contributeur fait valoir que la contribution cite correctement les contributeurs principaux. 5. Le contributeur, l'organisation qu'il représente (le cas échéant) et les détenteurs de droits de propriété dans la contribution font valoir qu'aucune information dans la contribution n'est confidentielle, et que l'ISOC et ses affiliés peuvent divulguer librement toute information qui y est contenue. 6. Le contributeur fait valoir qu'il a divulgué l'existence de tous les droits de propriété et droits de propriété intellectuelle dans la contribution, connus de lui raisonnablement et personnellement. Le contributeur ne fait pas valoir qu'il a connaissance personnelle de tous les droits de propriété et droits de propriété intellectuelle potentiellement afférents détenus ou revendiqués par l'organisation qu'il représente (le cas échéant) ou des tiers. 7. Le contributeur fait valoir qu'il n'existe pas de limitations de sa capacité à faire les concessions, acceptations et conventions précédentes, connues raisonnablement et personnellement du contributeur. En ratifiant cette description du processus IETF, l'Internet Society garantit de ne pas limiter l'accès traditionnellement libre et gratuit aux documents IETF auxquels une licence et un droit ont été rattachés conformément aux procédures présentées dans cette section, y compris les projets Internet et les RFC. Cette assurance est perpétuelle et ne sera pas révoquées par l'Internet Society, ou ses successeurs ou cessionnaires (assigns). 10.3.2. Les documents du circuit des standards (A) Lorsque des brevets, des demandes de brevets ou autres droits de propriété sont connus, ou revendiqués, par rapport à une spécification sur le circuit des standards, et portés à l'attention de l'IESG, l'IESG ne devra pas promouvoir la spécification sans y inclure une note signalant l'existence de ces droits ou ces droits revendiqués (claimed rights). Lorsque des mises en œuvre sont nécessaires avant la promotion d'une spécification, pour montrer l'adéquation de la spécification, seules seront prises en compte les mises en œuvre pour lesquelles les mesures adéquates d'observation de ces droits ou droits revendiqués auront été prises, selon la déclaration des développeurs. (B) L'IESG rejette toute responsabilité visant à établir l'existence ou à évaluer l'applicabilité des droits d'auteur, des brevets, des demandes de brevets ou d'autres droits revendiqués dans l'exercice de ses obligations selon la clause (A), et ne prendra pas position sur la validité ou la portée de ces droits. (C) Lorsque l'IESG a connaissance de droits ou de droits revendiqués, selon la clause (A), le directeur exécutif de l'IETF essaiera d'obtenir du bénéficiaire (claimant) de ces droits l'assurance écrite que, dès l'approbation par l'IESG de la spécification ou des spécifications pertinentes du circuit des standards Internet, chaque partie aura le droit de mettre en œuvre, d'utiliser et de distribuer la technologie ou les réalisations fondées sur ladite ou lesdites spécifications, en des termes clairs, raisonnables et non discriminatoires. Le groupe de travail qui propose l'utilisation de la technologie par rapport à laquelle des droits de propriété sont revendiqués peut assister le directeur exécutif de l'IETF dans cet effort. Les conclusions de cette procédure n'affecteront pas la progression d'une spécification le long du circuit des standards, excepté le fait que l'IESG peut retarder l'approbation si le délai permet de faciliter l'obtention d'une telle assurance. Quoi qu'il en soit, les conclusions seront enregistrées et mises à disposition par le directeur exécutif de l'IETF. L'IESG peut également ordonner d'inclure un résumé des conclusions dans tout RFC publié contenant la spécification. 10.3.3. La détermination des termes raisonnables et non discriminatoires Dans la pratique, l'IESG n'effectuera aucune détermination explicite de ce que la promesse de termes raisonnables et non discriminatoires pour l'utilisation d'une technologie est vérifiée. L'IESG recourra plutôt aux exigences normales de promotion des standards Internet pour vérifier que les termes d'utilisation sont raisonnables. Si les deux mises en œuvre indépendantes de la spécification requises pour avancer du statut de standard proposé (Proposed Standard) à celui de standard préliminaire (Draft Standard) ont été produites par des organisations ou des personnes différentes, ou si la « mise en œuvre significative et l'expérience d'exploitation réussie » exigées pour avancer de standard préliminaire à standard (Standard) ont été validées, on peut supposer que les termes doivent être raisonnables et jusqu'à un certain degré non discriminatoires. Cette supposition peut être constestée pendant la période de dernier appel (Last-Call). 10.4. Les mentions légales (A) Les documents du circuit des standards devront inclure la mention suivante : « The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. » (B) L'IETF invite tous les tiers intéressés à porter à son attention, le plus tôt possible, l'existence de tous les droits de propriété intellectuelle éventuels afférents aux standards Internet. Dans ce but, chaque document de standard devra inclure l'invitation suivante : « The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. » (C) La mention de droits d'auteur et la clause de non-responsabilité suivantes devront être incluses dans tous les documents liés aux standards de l'ISOC : « Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. » (D) Lorsque, au moment de la publication, l'IESG a connaissance de droits de propriétés revendiqués par rapport à un document du circuit des standards, ou à la technologie qui y est décrite ou référencée, ce document devra contenir la mention suivante : « The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. » 11. Remerciements Au cours des années, de nombreuses personnes ont participé au développement de ce document définissant le processus de standardisation IETF. Le processus a d'abord été décrit dans le RFC 1310 puis révisé dans le RFC 1602 avant le document courant (lequel s'inspire fortement de ses prédécesseurs). Des remerciements particuliers doivent être adressés à Lyman Chapin, Phill Gross et Christian Huitema, les rédacteurs des versions précédentes, à Jon Postel et Dave Crocker pour leurs contributions à ces versions, à Andy Ireland, Geoff Stewart, Jim Lampert et Dick Holleman pour leurs études des aspects légaux des procédures qui y sont décrites, et à John Stewart, Robert Elz et Steve Coya pour leur participation étendue dans la version finale. En outre, une grande partie du mérite de l'élaboration des rouages des processus de l'IETF revient aux nombreux membres des diverses incarnations du groupe de travail POISED. 12. Observations sur la sécurité Les questions de sécurité ne sont pas abordées dans ce mémoire. 13. Références [1] Postel, J., Internet Official Protocol Standards, STD 1, USC/Information Sciences Institute, mars 1996. [2] ANSI, Coded Character Set -- 7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986. [3] Reynolds, J., and J. Postel, Assigned Numbers, STD 2, USC/Information Sciences Institute, octobre 1994. [4] Postel, J., Introduction to the STD Notes, RFC 1311, USC/Information Sciences Institute, mars 1992. [5] Postel, J., Instructions to RFC Authors, RFC 1543, USC/Information Sciences Institute, octobre 1993. [6] Huitema, C., J. Postel, and S. Crocker Not All RFCs are Standards, RFC 1796, avril 1995. 14. Définitions de termes Domaine IETF (IETF Area) : Un secteur d'administration au sein de l'IETF. Un domaine (Area) se compose des groupes de travail en rapport avec un thème général tel que le routage. Un domaine est dirigé par un ou deux responsables de domaine (Area Director). Responsable de domaine (Area Director) : Le responsable d'un domaine IETF. Les responsables de domaines avec le président de l'IETF (IETF Chair) constituent l'IESG (Internet Engineering Steering Group). FTP (File Transfer Protocol) : Une application Internet servant à transférer des fichiers dans un réseau TCP/IP. gopher : Une application Internet utilisée pour sélectionner et récupérer de façon interactive des fichiers dans un réseau TCP/IP. IAB (Internet Architecture Board) : Un groupe désigné (par l'Internet Society) qui aide à gérer le processus de standardisation Internet. IESG (Internet Engineering Steering Group) : Un groupe composé des responsables de domaines IETF (Area Director) et du président de l'IETF (IETF Chair). L'IESG est chargé, avec l'IAB, de l'administration de l'IETF et constitue le conseil d'approbation des standards de l'IETF. interopérable : Pour les besoins de ce document, le terme « interopérable » signifie être capable de fonctionner en environnement hétérogène à travers un canal de communication de données. dernier appel (Last-Call) : Une période réservée aux commentaires du public servant à évaluer le degré de consensus autour de la justesse d'une action de standardisation proposée (cf. la section 6.1.2). en ligne : Se rapporte à une information mise à disposition sur l'Internet. Dans le contexte de ce document, une ressource est dite en ligne lorsqu'elle est récupérable sans restriction ni contrepartie indue en utilisant des applications Internet standards telles que FTP anonyme, gopher ou le web. groupe de travail (Working Group) : Un groupe nommé par l'IESG et l'IAB afin de travailler sur une spécification, un ensemble de spécifications ou un thème particuliers. 15. Coordonnées de l'auteur Scott O. Bradner Harvard University Holyoke Center, Room 813 1350 Mass. Ave. Cambridge, MA 02138 USA Phone: +1 617 495 3864 EMail: sob@harvard.edu Annexe A : Glossaire des abréviations ANSI American National Standards Institute ARPA Advanced Research Projects Agency (É.-U.) AS Applicability Statement FTP File Transfer Protocol ASCII American Standard Code for Information Interchange ITU-T Telecommunications Standardization sector of the International Telecommunication Union (ITU), une organisation du traité des Nations-Unies. L'ancienne appellation de l'ITU-T était CCITT. IAB Internet Architecture Board IANA Internet Assigned Numbers Authority IEEE Institute of Electrical and Electronics Engineers ICMP Internet Control Message Protocol IESG Internet Engineering Steering Group IETF Internet Engineering Task Force IP Internet Protocol IRSG Internet Research Steering Group IRTF Internet Research Task Force ISO International Organization for Standardization ISOC Internet Society MIB Management Information Base OSI Open Systems Interconnection RFC Request for Comments TCP Transmission Control Protocol TS Technical Specification WWW World Wide Web