Internet Architecture Board (IAB) L

Les documents de RFC contiennent un certain nombre d'éléments fixes comme l'en-tête de la page de titre, les mentions standard, et les déclarations de droits de reproduction/propriété intellectuelle. Le présent document les décrit et introduit des mises à jour pour refléter l'usage et les exigences actuelles de la publication de RFC. En particulier, cette mise à jour de la structure est destinée à communiquer clairement la source de la création et de la revue de RFC.

Le présent document n'est pas une spécification Internet en cours de normalisation ; il est publié à des fins d'information.

Le présent document est un produit du bureau d'architecture de l'Internet (IAB, Internet Architecture Board) et représente des informations dont l'IAB a estimé qu'il était utile d'en assurer la pérennité. Les documents dont la publication est approuvée par l'IAB ne sont candidats à aucun niveau de norme de l'Internet ; voir à la Section 2 de la RFC 5741.

Des informations sur le statut actuel du présent document, sur tout errata, et sur la façon de fournir des retours seront obtenues à http://www.rfc-editor.org/info/rfc5741 .

Le présent document est soumis au BCP 78 et aux dispositions légales de l'IETF Trust sur les documents de l'IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication du présent document. Prière de relire attentivement ces documents, car ils décrivent vos droits et obligations à l'égard du présent document.

Table des Matières

1. Introduction

2. Flux de RFC et norme de l'Internet 2

3. Éléments structurels des RFC

3.1 En-tête de la page de titre

3.2 Statut du présent mémoire

3.3 Notes supplémentaires

3.4 Autres informations structurelles dans les RFC

4. Considérations sur la sécurité

5. Considérations sur l'éditeur des RFC

6. Références

6.1 Références normatives

6.2 Références pour information

Appendice A Exemples de mentions communes de 'Statut de ce mémoire'

A.1 Voie de la normalisation de l'IETF

A.2 IETF expérimental, avec enquête de consensus

A.3 IETF expérimental, pas d'enquête de consensus

A.4 Information de l'IAB

A.5 IRTF expérimental, pas d'enquête de consensus

A.6 Information de soumission indépendante

Appendice B. Membres de l'IAB au moment de l'approbation

Appendice C. Remerciements

Adresses des auteurs

Précédemment, les RFC (par exemple, la [RFC4844]) contenaient un certain nombre d'éléments qui étaient là pour des raisons historiques, pratiques, et juridiques. Elles contenaient aussi des matériaux conventionnels pour indiquer clairement le statut du document et contenaient éventuellement des "Notes" pour indiquer comment le document interagit avec les documents en cours de normalisation de l'IETF.

Comme la série des RFC a évolué au fil des ans, on s'est de plus en plus soucié d'étiqueter de façon appropriée les publications pour marquer clairement le statut de chaque RFC et le statut du travail qu'elle décrit. Principalement, il y a l'exigence que les RFC publiées au titre du processus de revue de l'IETF ne soient pas facilement confondues avec les RFC qui peuvent avoir une revue et un processus d'approbation très différents. Divers ajustements ont été faits au fil des ans, incluant l'évolution du texte des "Notes" incluses dans les RFC publiées.

Avec la définition des différents flux de RFC [RFC4844], il est approprié de formaliser la définition des diverses pièces des mentions standard des RFC et d'introduire des ajustements pour assurer une meilleure clarté d'expression du statut du document, en ligne avec les processus de revue et d'approbation définis pour chaque flux.

Le présent mémoire identifie et décrit les éléments communs de la structure des mentions de RFC, et fournit une approche globale de la mise à jour et de l'utilisation de ces éléments pour communiquer clairement le statut du document et du contenu de la RFC. La plus grande partie des informations de structure historiques sont tirées de la [RFC2223].

Les changements introduits par le présent mémoire devraient être mis en œuvre aussitôt que possible en pratique après l'approbation de la publication du document.

Les utilisateurs des RFC devraient être conscients que, alors que tous les documents en rapport avec les normes de l'Internet sont publiés comme RFC, toutes les RFC ne sont pas des documents relatifs aux normes de l'Internet.

L'IETF est chargée de la maintenance du processus de normalisation de l'Internet, qui inclut les exigences du développement, de la revue, et de l'approbation des RFC en cours de normalisation et des bonnes pratiques actuelles (BCP). L'IETF produit aussi des documents qui ne sont pas en cours de normalisation (information, expérimentaux, et historiques). Tous les documents publiés au titre du flux de l'IETF sont revus par les organes appropriés de l'IETF.

Les documents publiés dans des flux autres que le flux de l'IETF ne sont généralement pas revus par l'IETF pour les choses comme la sécurité, le contrôle d'encombrement, ou une interaction inappropriée avec les protocoles déployés. Ils n'ont pas non plus été soumis à l'approbation du groupe de pilotage de l'ingénierie de l'Internent (IESG, Internet Engineering Steering Group) incluant le dernier appel à remarques à l'échelle de l'ensemble de l'IETF. Donc, l'IETF décline toute responsabilité, pour tous les documents qui ne sont pas du flux de l'IETF, quant à l'adéquation de ces RFC à quelque fins que ce soit.

Se reporter aux [RFC2026], [RFC5742], et [RFC4844] et leurs successeurs pour les détails actuels du processus de l'IETF et les flux de RFC.

Cette section décrit les éléments qu'on trouve couramment dans les RFC publiées aujourd'hui. Pour être clair, le présent document spécifie les éléments précisément comme une spécification. Cependant, ceci n'est pas destiné à spécifier un seul format statique. Les détails du formatage sont décidés par l'éditeur des RFC. Des changements substantiels de la structure et du contenu de l'en-tête et des mentions communes peuvent être entrepris à l'avenir, et seront soumis à la supervision générale et la revue de l'IAB.

La colonne de droite contient le nom de l'auteur et ses informations d'affiliation ainsi que le mois de publication de la RFC. Les conventions et restrictions sur ces éléments sont décrites dans les normes de style de RFC et certaines définitions individuelles de flux.

Cette section est principalement concernée par les informations de la colonne de gauche :

Cela décrit la zone d'où a été généré le travail. Historiquement, toutes les RFC étaient étiquetées Groupe de travail Réseau. "Groupe de travail Réseau" se réfère à la version originale de l'IETF d'aujourd'hui lorsque les gens provenant de l'ensemble original de sites ARPANET et de tous les autres qui y étaient intéressés – les réunions étaient ouvertes – se réunissaient pour discuter, concevoir, et documenter les protocoles proposés [RFC0030]. Ici, on rend obsolète le terme "Groupe de travail Réseau" afin d'indiquer le flux d'origine.

La <Source du document> est le nom du flux de RFC, comme défini dans la [RFC4844] et ses successeurs. Au moment de la présente publication, les flux, et donc les entrées possibles sont :

* l'équipe d'ingénierie de l'Internet (IETF, Internet Engineering Task Force)

Cela indique le numéro de RFC, alloué par l'éditeur des RFC à la publication du document. Cet élément est inchangé.

Certaines catégories de documents sont aussi étiquetées comme sous série de RFC. Ces éléments apparaissent comme approprié pour de telles catégories, indiquant la sous série et le numéro du document au sein de cette série. Actuellement, il y a des sous séries pour les BCP [RFC2026], les STD [RFC1311], et les FYI [RFC1150]. Ces numéros de sous série peuvent apparaître dans plusieurs RFC. Par exemple, lorsque une nouvelle RFC rend obsolète ou met à jour une ancienne, le même numéro de sous série est utilisé. Aussi, plusieurs RFC peuvent recevoir le même numéro de sous série : une seule STD, par exemple, peut être composée de plusieurs RFC, chacune d'elles portant le même numéro de STD. Cet élément est inchangé.

Certaines relations entre des RFC dans la série sont explicitement notées dans l'en-tête de RFC. Par exemple, une nouvelle RFC peut mettre à jour une ou plusieurs RFC antérieures. Actuellement, deux relations sont définies : "Met à jour" et "Rend obsolète" [RFC2223]. D'autres formulations comme "Rendue obsolète par" sont aussi utilisées (par exemple, dans la [RFC5143]). D'autres types de relations peuvent être définis par l'éditeur des RFC et pourront apparaître dans de futures RFC.

Cela indique la catégorie du document initial de RFC à la publication. Elles sont définies dans la [RFC2026]. Actuellement, c'est toujours une des suivantes : En cours de normalisation, Bonnes pratiques actuelles, Expérimental, Information, ou Historique. Cet élément est inchangé.

Le "Statut du présent mémoire" décrit la catégorie de la RFC, incluant la déclaration de distribution. Ce texte est inclus sans considération du flux de source de la RFC.

Le "Statut du présent mémoire" commence par une seule phrase qui décrit le statut. Il va aussi comporter une déclaration qui décrit la revue spécifique du flux du matériel (qui dépend du flux). C'est une composante importante du statut, dans la mesure où elle précise la largeur et la profondeur de la revue, et donne au lecteur les moyens de comprendre comment considérer son contenu.

Le premier paragraphe de la section Statut du présent mémoire contient une seule phrase, clairement énoncée. Elle dépend de la catégorie du document.

"Le présent document n'est pas une spécification Internet en cours de normalisation ; <il est publié pour d'autres raisons>."

Pour les catégories Information, Expérimental, Historique et futures de RFC, l'éditeur des RFC produira un texte approprié pour <il est publié pour d'autres raisons>. Des valeurs initiales suggérées sont :

Expérimental : "il est publié pour examen, mise en œuvre expérimentale, et évaluation."

Le second paragraphe du "Statut du présent mémoire" va maintenant inclure un paragraphe décrivant le type de revue et d'exposition qu'a reçu le document. Ceci est défini flux par flux, et soumis à une revue générale et la supervision de l'éditeur des RFC et de l'IAB. Une structure spécifique est définie ici pour s'assurer que les processus de revue et les types de document sont clairs. Ces paragraphes devront être définis et conservés au titre des définitions de flux de RFC. Le texte initial suggéré pour les flux actuels est donné ci-dessous.

Le paragraphe peut inclure du texte spécifique de la catégorie initiale du document ; lorsque un document est expérimental ou historique, le second paragraphe commence par :

Expérimental : "Le présent document définit un protocole expérimental pour la communauté de l'Internet."

Historique : "Le présent document définit un document historique pour la communauté de l'Internet."

Le texte qui suit dépend du flux – ce sont des valeurs initiales suggérées qui pourront être mises à jour par des documents de définition de flux.

"Le présent document a été produit par l'équipe d'ingénierie de l'Internent (IETF, Internet Engineering Task Force)."

Si il y a eu un appel au consensus de l'IETF selon les processus de l'IETF, une phrase supplémentaire devrait être ajoutée : "Il représente le consensus de la communauté de l'IETF. Il a subi une revue publique et sa publication a été approuvée par le groupe de pilotage de l'ingénierie de l'Internet (IESG, Internet Engineering Steering Group)."

"Sa publication a été approuvée par le groupe de pilotage de l'ingénierie de l'Internet (IESG, Internet Engineering Steering Group)."

"Le présent document a été produit par le bureau de l'architecture de l'Internet (IAB, Internet Architecture Board) et représente des informations dont l'IAB a estimé qu'il était utile d'en assurer la pérennité."

"Le présent document a été produit par l'équipe de recherches de l'Internet (IRTF, Internet Research Task Force). L'IRTF publie les résultats des activités de recherche et développement en rapport avec l'Internet. Ces résultats peuvent ne pas convenir pour déploiement."

En plus, on peut ajouter une phrase indiquant la base du consensus au sein de l'IRTF :

"La présente RFC représente le consensus du groupe de recherche <insérer_le_nom> de l'équipe de recherches de l'Internet (IRTF)."

"La présente RFC représente l'opinion individuelle d'un ou plusieurs membres du groupe de recherche <insérer_le_nom> de l'équipe de recherches de l'Internet (IRTF)."

"Ceci est une contribution à la série des RFC, indépendante de tout autre flux de RFC. L'éditeur des RFC a choisi de publier le présent document à sa discrétion et ne fait aucune déclaration quant à sa valeur de mise en œuvre ou de déploiement."

Pour les documents qui ne sont pas du flux de l'IETF, une référence à la Section 2 de la présente RFC est ajoutée avec la phrase suivante :

"Les documents dont la publication est approuvée par le [approbateur du flux -- actuellement, "IAB", "IRSG", ou "éditeur des RFC"] ne sont candidats à aucun niveau de norme de l'Internet ; voir la Section 2 de la RFC 5741."

Pour les documents du flux de l'IETF, une référence similaire est ajoutée pour les BCP et les documents en cours de normalisation :

"Plus d'informations sur les [BCP ou normes de l'Internet] sont disponibles à la Section 2 de la RFC 5741."

"Tous les documents approuvés par l'IESG ne sont pas candidats à un niveau de norme de l'Internet ; voir la Section 2 de la RFC 5741."

Les mentions communes se terminent par une référence à l'endroit où trouver d'autres informations pertinentes. Ces informations peuvent inclure, à la discrétion de l'éditeur des RFC, des informations sur si la RFC a été mise à jour ou rendue obsolète, l'origine de la RFC, une liste d'éventuels errata, des informations sur comment fournir des retours et suggestions, et des informations sur comment soumettre des errata comme décrit dans [RFC-ERRATA]. la formulation exacte et l'URL sont sujets à changement (à la discrétion de l'éditeur des RFC) mais le texte actuel est :

"Les informations sur le statut actuel du présent document, tous errata, et comment fournir des retours sur lui peuvent être obtenues à http://www.rfc-editor.org/info/rfc<numéro de la rfc>."

On notera que le texte des paragraphes 1 et 2 des mentions communes indique le statut initial d'un document. Pendant leur durée de vie, les documents peuvent changer de statut pour passer, par exemple, à Historique. Ceci ne peut pas être reflété dans le document lui-même et devra être reflété dans les informations auxquelles on se réfère au paragraphe 3.2.3.

Exceptionnellement, un processus de revue et de publication peut prescrire des notes supplémentaires qui vont apparaître comme des notes figurant après le "Statut du présent mémoire".

Bien que ceci ait été une caractéristique courante des RFC récentes, le but du présent document est de rendre la structure globale de la RFC suffisamment claire pour qu'on ait plus besoin de telles notes, ou au moins de rendre leur utilisation vraiment exceptionnelle.

Les RFC contiennent d'autres éléments d'information structurels. L'éditeur des RFC est chargé du positionnement et de la disposition de ces éléments structurels. Noter aussi que de nouveaux éléments peuvent être introduits ou rendus obsolètes en utilisant un processus cohérent avec la [RFC4844]. Ces ajouts peuvent exiger ou non une documentation dans une RFC.

Actuellement les informations structurelles suivantes sont disponibles ou on été envisagées pour être incluses dans les RFC :

Une notice de droits de reproduction avec référence au BCP 78 [RFC5378] et une déclaration de propriété intellectuelle se référant aux BCP 78 et BCP 79 [RFC3979]. Le contenu de ces déclarations est défini par ces BCP.

Numéro de série de norme internationale (ISSN, International Standard Serial Number) [ISO3297] : ISSN 2070-1721. L'ISSN identifie de façon univoque la série des RFC comme titre sans considération de la langue ou du pays dans lequel elle est publiée. L'ISSN par lui-même n'a pas de signification autre que l'identification univoque d'une publication en série.

Le présent document essaye de clarifier la descriptions du statut d'une RFC. La mauvaise compréhension du statut d'un mémoire pourrait causer des problèmes d'interopérabilité, donc des problèmes de sécurité et de stabilité.

L'éditeur des RFC est responsable de la conservation de la cohérence de la série des RFC. À cette fin,l'éditeur des RFC tient un manuel de style [RFC-style]. Dans le présent mémoire, on mentionne quelques éléments structurels explicites que l'éditeur des RFC doit conserver. Les conventions sur le contenu et l'utilisation de tous les éléments actuels et futurs sont à documenter dans le manuel de style.

Ajouter une référence au flux dans l'en-tête des RFC est seulement une des méthodes pour préciser de quel flux est originaire une RFC. L'éditeur des RFC est invité à ajouter une telle indication dans, par exemple, les indices et interfaces.

[RFC5742] H. Alvestrand, R. Housley, "Procédures de l'IESG pour le traitement des flux de soumissions indépendantes et de l'IRTF", BCP0092, décembre 2009. (Remplace la RFC3932)

[ISO3297] Technical Committee ISO/TC 46, Information and documentation, Subcommittee SC 9, Identification and description, "Information and documentation - International standard serial number (ISSN)", 09 2007.

[RFC1150] G. Malkin et J. Reynolds, "FAQ sur les FAQ : introduction aux notes sur les FAQ", mars 1990.

[RFC2223] J. Postel, J. Reynolds, "Instructions pour les auteurs de RFC", octobre 1997. (Information)

[RFC2629] M. Rose,"Écrire des I-D et des RFC en utilisant XML", juin 1999. (Information)

[RFC4879] T. Narten, "Précisions sur la procédure de divulgation à un tiers dans la RFC 3979", avril 2007. (MàJ RFC3979) (BCP0079)

[RFC5143] A. Malis et autres, "Encapsulation de service d'émulation de circuit en réseau optique synchrone/hiérarchie numérique synchrone (SONET/SDH) sur MPLS", février 2008. (Obsolète, voir RFC4842) (Historique)

[RFC5378] S. Bradner et autres, "Droits que les contributeurs fournissent à l'IETF Trust", novembre 2008. (BCP0078) (Remplace RFC3978, RFC4748, MàJ RFC2026)

[RFC-ERRATA] Hagens, A., Ginoza, S., and R. Braden, "RFC Editor Proposal for Handling RFC Errata", travail en cours, mai 2008.

Mentions communes pour un document en cours de normalisation qui (par définition) a été soumis à un appel à consensus de l'IETF.

Le présent document a été produit par l'équipe d'ingénierie de l'Internent (IETF, Internet Engineering Task Force). Il représente le consensus de la communauté de l'IETF. Il a subi une révision publique et sa publication a été approuvée par le groupe de pilotage de l’ingénierie de l’Internet (IESG, Internet Engineering Steering Group). Plus d'informations sur les normes de l'Internet sont disponibles à la Section 2 de la RFC 5741.