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 Olivier Miakinen.
Network Working Group (errata) S. Bradner Document RFC : 2026 Harvard University Document BCP : 9 Octobre 1996 Remplace : 1602 Catégorie : Best Current Practice
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.
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.
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).
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.
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 :
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.
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.
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.
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.
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.
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).
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é.
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).
Une déclaration d'applicabilité appliquera l'un des « niveaux d'exigence » (requirement levels) suivants à chaque spécification technique à laquelle elle se rapporte :
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 :
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.
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.
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.
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.
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.
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.
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.
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.
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).
À 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.
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.
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.
À 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.
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.
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.
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.
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.
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.
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.
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).
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é.
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.
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.
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.
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.
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.
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 :
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.
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.
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.
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.
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.
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.
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 :
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.
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.
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.
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.
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.
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.
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.
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.
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).
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).
« 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. »
« 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. »
« 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. »
« 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. »
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.
Les questions de sécurité ne sont pas abordées dans ce mémoire.