Groupe de travail Réseau	J. Klensin, éditeur	
Request for Comments : 4846	D. Thaler, éditeur	
Catégorie : Information	juillet 2007	
Traduction Claude Brière de L'Isle

Soumissions indépendantes à l'éditeur des RFC

Statut de ce mémoire
Le présent mémoire apporte des informations pour la communauté de l'Internet. Il ne spécifie aucune sorte de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.

Notice de copyright
Copyright (C) The IETF Trust (2007).

Résumé
Il y a une tradition bien établie dans la communauté de l’Internet, qui empiète depuis de nombreuses années sur les prérogatives de l’équipe d’ingénierie de l’Internet (IETF) d’utiliser la série des RFC pour publier du matériel qui ne prend pas sa source dans le processus de normalisation de l’IETF et ses mécanismes de révision et d’approbation. Ces documents, connus sous le nom de "soumissions indépendantes", servent un certain nombre d’importantes fonctions pour la communauté de l’Internet, aussi bien à l’intérieur qu’à l’extérieur de la communauté des participants actif à l’IETF. Le présent document discute du modèle des soumissions indépendantes et de quelques unes des raisons pour lesquelles elles sont importantes. Il décrit aussi les normes rédactionnelles et de traitement qui peuvent être utilisées pour les soumissions indépendantes alors que la communauté franchit un cap vers de nouvelles relations entre la communauté de l’IETF et son principal éditeur technique.
Table des matières
1. Introduction	1
1.1 Note de terminologie	2
1.2 Contexte et hypothèses philosophiques	2
2. Rôle des soumissions indépendantes	2
3. Soumission de document	3
4. Processus de revue	4
4.1 Envoi d'un projet	4
4.2 Demande de publication	4
4.3 Relecture initiale de l'éditeur des RFC	4
4.4 Révision et évaluation	4
4.5 Relectures supplémentaires	4
4.6 Rejet de document	5
4.7 Décision finale et notification	5
4.8 Édition finale et publication	5
5. Revue formelle de l'IESG	5
6. Bureau de révision éditoriale	6
7. Statut et disponibilité des revues	6
7.1 Révisions envoyées	6
7.2 Documents rejetés	7
7.3 Documents approuvés pour publication	7
8. Droits de propriété intellectuelle	7
9. Considérations sur la sécurité	8
10. Remerciements	8
11. Références	8
11.1 Références normatives	8
11.2 Références pour information	8
Déclaration complète des droits de reproduction	9
 	1.	Introduction

Il y a une tradition bien établie dans la communauté de l'Internet, qui empiète sur les prérogatives de l'IETF depuis de nombreuses années, d'utiliser la série des RFC pour publier des matériaux qui ne prennent pas leur source dans le processus de normalisation de l'IETF et ses mécanismes de relecture et d'approbation. Ces documents, connus comme "soumissions indépendantes", servent un certain nombre d'importantes fonctions pour la communauté de l'Internet, à la fois à l'intérieur et à l'extérieur de la communauté des participants actifs à l'IETF. Le présent document discute le modèle des soumissions indépendantes et de quelques raisons pour lesquelles il est important. Il décrit ensuite les normes rédactionnelles et de traitement qui peuvent être utilisées pour les soumissions indépendantes alors que la communauté va vers de nouvelles relations avec son principal éditeur technique.

Pour comprendre la perspective du présent document, il est important de se souvenir que la fonction d'éditeur des RFC précède la création de l'IETF. Au moment de la présente rédaction, la série des RFC remonte à 38 ans [RFC2555], tandis que l'IETF célèbre son 21ème anniversaire. Tous les documents qui ont été publiés avant la création de l'IETF, et pendant quelques années après, auraient été considérées aujourd'hui comme des soumissions indépendantes. Avec l'évolution de l'IETF, le bureau de l'architecture de l'Internet (IAB, Internet Architecture Board) puis l'IETF elle-même ont choisi de publier des documents de l'IETF comme des RFC tout en comprenant parfaitement que la fonction d'éditeur des RFC était un mécanisme de publication indépendant. D'autres décisions étaient possibles : par exemple, l'IETF aurait pu décider de créer sa propre série de publications. Il a été estimé qu'il y avait une valeur considérable à continuer de publier le travail de l'IETF dans la même série que celle utilisée pour publier les protocoles de base de l'Internet.

1.1	Note de terminologie
Le présent document décrit ce qui a historiquement été appelé des "soumissions indépendantes". Ce terme se distingue de ceux des documents des communautés IETF et IAB qui ont pour origine des groupes formels – les groupes de travail de l'IAB, de l'IRTF, et de l'IETF -- et des soumissions soumises au groupe de pilotage de l'ingénierie de l'Internet (IESG, Internet Engineering Steering Group) pour les traitements sur la voie de la normalisation (Standards-Track), d'information, ou expérimentale. Les documents produits par des individus, plutôt que par des groupes de travail de l'IETF ou autres groupes affiliés à l'IETF, mais soumis pour publication via l'IESG sous le patronnage d'un directeur de zone, sont connus comme des "soumissions individuelles".

Pour des raisons pratiques et historiques évidentes, l'éditeur et publieur des documents qui ne sont pas traités par l'IETF est appelé ci-dessous "éditeur des RFC". L'éditeur des RFC va normalement être une organisation d'une ou plusieurs personnes d'expérience et du personnel d'exécution associé, et le terme est utilisé ci dessous pour les désigner de façon collective. Ce terme n'est pas destiné à prédire comment ils seront appelés à l'avenir, ni en termes de qui fait le travail, ni de qui ils sont, ni la série des documents.

1.2	Contexte et hypothèses philosophiques
Le présent document complète la discussion et les lignes directrices de la [RFC4714], qui se concentre sur les documents sur la voie de la normalisation. Il prend un point de vue un peu plus fort que les discussions qui y ont conduit, commençant par la croyance que les soumissions indépendantes sont très précieuses si elles sont, en fait, indépendantes des processus de l'IETF. Dans la perspective de l'IETF, les soumissions indépendantes sont particulièrement importantes comme vérification des processus de l'IETF même si ces vérifications ne sont pas les seules raisons, ou même une raison commune, pour elles. Ce rôle est compromis si les entités relatives à l'IETF sont capables de bloquer ou déconseiller de tels documents à un niveau au delà de ce qui est nécessaire pour éviter des difficultés avec le processus de normalisation.

 	2.	Rôle des soumissions indépendantes

Quand la série des RFC était encore toute nouvelle, les RFC étaient utilisées pour publier des articles généraux sur le réseautage ainsi que des types de documents qu'on décrirait aujourd'hui comme des normes. Ces rôles se sont aussi développés au titre des premières conceptions et développement de l'ARPANET, longtemps avant que quiconque ne rève de l'IETF et quand la distinction entre, par exemple, les documents de normes et d'information était tracée de façon moins précise. Dans les années plus récentes, les soumissions indépendantes sont devenues importantes pour plusieurs raisons, dont certaines sont relativement nouvelles. Elles incluent :

o	La discussion des technologies relatives à l'Internet qui ne font pas partie de l'agenda de l'IETF.

o	L'introduction de nouvelles idées importantes comme un pont entre le monde universitaire et l'ingénierie de l'IETF.

o	La discussion pour information des technologies, options, ou de l'expérience des protocoles.

o	La publication pour information de protocoles spécifiques de fabricants.

o	La critique et la discussion de solutions de remplacement aux protocoles sur la voie de la normalisation de l'IETF. Le potentiel de telles critiques procure un mécanisme important de vérification des processus de normalisation de l'IETF et devrait être vu à cette lumière.

o	Des documents examinés par des groupes de travail de l'IETF mais non normalisés. Alors que de nombreux documents de ce type sont déjà publiés par le flux de documents de l'IETF (voir le paragraphe 5.1.1 de la [RFC4844]) comme des RFC pour information ou expérimentales, le chemin de la soumission indépendante leur a traditionnellement été aussi ouvert. Cependant, à cause de leur connexion intime avec le processus de normalisation de l'IETF et les activités des groupes de travail et la sensibilité conséquente à des déclarations exactes de relations et de temps, il y a des raisons de croire que de tels documents devraient normalement être publiés via le flux des documents de l'IETF. En tous cas, ces documents sont publiés pour en garder une trace historique.

o	Du matériel satirique.

o	Des notes et rapports de réunion (la [RFC0021] est la première ; la [RFC1109] est probablement la plus importante).

o	Des éditoriaux (le meilleur exemple est l'[IEN137], qui n'est pas une RFC).

o	Des éloges funêbres [RFC2441].

o	Des contributions techniques (par exemple, la [RFC1810]).

o	Historiquement, l'éditeur des RFC et, au moins avant le passage de main de l'institut des sciences de l'information (ISI, Informational Sciences Institute) à la corporation Internet pour l'allocation des nom et des numéros (ICANN, Internet Corporation for Assigned Names and Numbers) et le memorandum d'accord de juin 2000 [RFC2860], les déclarations de politique de l'autorité d'allocation des numéros de l'Internet (IANA, Internet Assigned Numbers Authority) (par exemple, la [RFC2223] et la [RFC1591]).

Il devrait être clair d'après la liste ci-dessus que, pour être efficace, le processus de revue et d'approbation pour les soumissions indépendantes devrait être largement indépendant de l'IETF. Comme important principe qui a été appliqué historiquement, l'éditeur des RFC recherche l'avis de l'IESG sur de possibles relations et conflits avec le travail de l'IETF. Toute soumission qui constitue une solution de remplacement, ou est en conflit avec, une norme de l'IETF ou une proposition d'adoption sur la voie de la normalisation doit clairement indiquer cette relation. L'IESG peut identifier de tels conflits au titre de sa revue.

Les procédures spécifiques à suivre pour la revue sont décrites dans la Section 4 et la Section 5.

 	3.	Soumission de document

Les soumissions indépendantes sont soumises directement à l'éditeur des RFC. Elles doivent d'abord être postées comme des projets Internet (I-D, Internet-Draft) de sorte que la soumission est normalementt simplement une note demandant que l'éditeur des RFC envisage la publication d'un projet Internet particulier. Le processus est décrit dans la [RFC2223]. Plus d'informations peuvent être trouvées dans le projet de mise à jour de ce document [RFC7322].

Tout document qui satisfait aux exigences de la présente spécification, de la [RFC2223] et ses successeurs, et de toutes les conditions de propriété intellectuelle ou autres qui peuvent être établies de temps en temps, peut être soumis à l'éditeur des RFC pour être considéré comme soumission indépendante. Cependant, l'éditeur des RFC préfère que les documents créés par les processus de l'IETF (par exemple, résultat d'un groupe de travail) soient examinés par l'IESG et soumis en utilisant cette voie seulement si un groupe de travail ou l'IESG refuse de le publier. Dans les premiers cas, le processus de revue va être plus efficace si les auteurs fournissent un historique des considérations et revues du document au moment de la soumission.

 	4.	Processus de revue

En général, les étapes du processus de revue sont identifiées dans les paragraphes qui suivent. Toutes peuvent faire l'objet d'une itération et, à la discrétion de l'éditeur des RFC, les étapes après la première peuvent être prises dans le désordre. De plus, la revue de l'IESG, comme expliqué à la Section 5, doit avoir lieu avant la décision finale sur la publication du document.

 	4.1	Envoi d'un projet
Le ou les auteurs ou éditeurs d'un document l'envoient comme projet Internet.

4.2	Demande de publication
Après le délai normal de revue par la communauté et les réactions fournies par la soumission du I-D et l'annonce qui en découle dans le répertoire des I-D, l'auteur ou éditeur envoie une demande de prise en considération pour la publication à l'éditeur des RFC à rfc-editor@rfc-editor.org. Cette demande devrait noter toutes les discussions ou revues du document par la communauté qui se sont produites avant la soumission, ainsi que la catégorie désirée pour le document (information ou expérimentale, comme expliqué dans la [RFC2026], paragraphe 4.2).

Si le document requiert des allocations de la part de l'IANA, les auteurs devrait prendre soin de vérifier la politique d'allocations pour l'espace de noms pertinent, car certaines politiques d'allocation (par exemple, "Consensus de l'IETF") ne peuvent pas être utilisées par les soumissions indépendantes. Voir plus d'informations dans la [RFC2434].

4.3	Relecture initiale de l'éditeur des RFC
Le personnel de l'éditeur des RFC effectue une vérification initiale du document pour déterminer si il y a des problèmes ou questions évidents et pour décider sur la suite des autres étapes.

À tout moment durant le processus, l'éditeur des RFC peut faire des suggestions générales et/ou spécifiques à l'auteur sur la façon d'améliorer la qualité rédactionnelle du document et noter toutes violations spécifiques des règles. L'auteur est supposé faire les mises à jour suggérées, soumettre une nouvelle version, et informer l'éditeur des RFC. Ceci peut être répété aussi souvent que nécessaire pour obtenir une quatité éditoriale acceptable.

4.4	Révision et évaluation
L'éditeur des RFC s'arrange pour que soient effectuées une ou plusieurs revuesoriginal  du document. Cela peut inclure des revues par le bureau d'édition (voir la Section 6) ou des revues par d'autres. Les revues non sollicitées par des parties indépendantes de l'auteur sont bienvenues à tout moment.

Au minimum, l'auteur de tout document devra recevoir un sommaire écrit de la ou des revues. L'anonymat des relecteurs est discuté à la Section 7. L'éditeur des RFC peut aussi partager la relecture avec le bureau d'édition.

La réfutation par l'auteur de certains aspects d'une revue, suivi par un sain dialogue technique entre l'auteur et le ou les réviseurs, est parfaitement approprié. Le consensus sur la révision du document est le résultat désiré.

L'éditeur des RFC est supposé prendre soigneusement en compte toutes les relectures compétentes, et en l'absence de circonstance inhabituelle, une prépondérance de revues favorables devrait conduire à la publication.

4.5	Relectures supplémentaires
Si l'auteur n'est pas satisfait d'une ou plusieurs revues, il peut demander que l'éditeur des RFC sollicite des revues supplémentaires. Dans des circonstances exceptionnelles, l'auteur peut demander que l'IAB revoit le document. De telles demandes à l'IAB, et toutes relectures que l'IAB choisirait d'effectuer, vont se faire selon des procédures du choix de l'IAB.  L'IAB n'est pas obligé d'initier une revue ou d'obtempérer à une telle demande : une demande de revue à l'IAB n'est pas un processus d'appel.

4.6	Rejet de document
Si une étape du processus de revue qu'on vient de décrire conduit à la conclusion que le document n'est pas publiable, l'éditeur des RFC peut rejeter le document. Un tel rejet va normalement être fondé sur la conclusion que la soumission ne satisfait pas aux standards techniques ou rédactionels de la série des RFC ou n'est pas pertinent pour les domaines que couvre la série.

Si un document est rejeté par l'éditeur des RFC, l'auteur peut demander une revue supplémentaire de l'IAB, comme décrit ci-dessous, mais l'IAB n'est pas obligé d'effectuer cette revue, ni n'est l'éditeur des RFC obligé de le publier, même avec une revue favorable de l'IAB.

4.7	Décision finale et notification
Dans tous les cas, la décision ultime de publier ou non, et sur quel texte, appartient à l'éditeur des RFC.

L'éditeur des RFC va communiquer la décision finale à l'auteur et au bureau d'édition. Pour un rejet, il y aura un résumé de la ou des raisons de l'action.

Les informations sur tout délai de publication demandée à l'IESG ou demande de ne pas publier un document vont être envoyées au site de la Toile de l'éditeur des RFC pour compléter les informations sur le statut du document.

4.8	Édition finale et publication
Une fois qu'un document est approuvé pour publication, il est traité de façon similaire à celle des autres RFC, aves les principes sur les priorités élaborées avec l'IAB comme approprié.

 	5.	Revue formelle de l'IESG

À un moment approprié du processus de revue, normalement après que l'éditeur des RFC a fait une tentative de décision de publication, le document est transmis à l'IESG pour une évaluation avec un délai relativement court. Si la nature du document persuade l'éditeur des RFC ou l'IESG que les intérêts de la communauté ou l'efficacité du processus de publication seraient mieux servis par une programmation différente, alors ce programme devrait être suivi. Par exemple, si il apparaît à l'éditeur des RFC qu'il est probable que l'IESG va souhaiter reprendre le document et l'allouer à un groupe de travail, il peut valoir mieux demander que la revue de l'IESG se fasse avant de subir les délais associés aux autres revues ou d'un travail rédactionel significatif.

L'évaluation de l'IESG n'est pas technique. Elle couvre plutôt les problèmes mentionnés dans la [RFC3932] ou ses successeurs, vraisemblablement dans la perspective mentionnée au paragraphe 1.2. C'est-à-dire que l'évaluation devrait se concentrer exclusivement sur des conflits ou une confusion avec les processus de l'IETF et une tentative de subvertir ("cours final") les activités d'un groupe de travail.

Au moment où le document est transmis à l'IESG, l'éditeur des RFC publie une indication sur son site de la Toile que le document est soumis à la revue de l'IESG et que des commentaires sur les conflits peuvent être envoyés à l'IESG avec copie à l'éditeur des RFC. Des mécanismes supplémentaires peuvent être développés de temps en temps pour informer une communauté qu'un document entre dans une revue formelle avant publication. Les commentaires non directement reliés aux procédures de l'IETF ou à des conflits peuvent être envoyés directement à l'auteur et à l'éditeur des RFC.

En plus de la revue de l'IESG sur des conflits avec le travail de l'IETF, des individus dans l'IESG ou dans la plus large communauté de l'IETF sont libres de revoir un projet et, si ils ont des commentaires de quelque sorte que ce soit – incluant le cas extrême de croire que la proposition est dommageable pour l'Internet dans son ensemble -- ces commentaires devraient être adressés à l'auteur et à l'éditeur des RFC.

Si l'IESG, après avoir achevé sa revue, identifie des problèmes, il peut recommander un texte explicatif ou qualificatif pour que l'éditeur des RFC l'inclut dans le document si il est publié.

Si l'IESG conclut que la publication du document devrait être retardée d'un délai raisonnable parce que sa publication immédiate pourrait causer de la confusion ou d'autres dommages avec des propositions en cours d'examen pour la normalisation, l'éditeur des RFC va satisfaire cette demande. L'accord actuel entre l'éditeur des RFC et l'IESG sur des demandes de délais est supposé se continuer. Cet accord permet à l'IESG de demander un délai de jusqu'à six mois et, si nécessaire, de renouveler deux fois cette demande, pour un délai total possible de 18 mois.

Si l'IESG conclut que le document ne devrait pas être publié comme RFC, il va demander que l'éditeur des RFC ne publie pas et fournisse des justifications appropriées pour cette demande. L'éditeur des RFC va prendre en considération la demande de ne pas publier le document.

L'éditeur des RFC ou l'auteur peut demander que l'IAB revoit la demande de l'IESG de retarder ou ne pas publier le document et demander que l'IAB fournisse une opinion supplémentaire. Une telle demande va être rendue publique via le site de la Toile de l'éditeur des RFC. Comme avec la revue de l'IESG elle-même, l'opinion de l'IAB, si il en est une, va être pour avis. Et, comme avec les demandes de l'auteur pour une revue technique de l'IAB (voir le paragraphe 4.5) l'IAB n'est pas obligé d'effectuer ce type de revue et peut refuser la demande.

 	6.	Bureau de révision éditoriale

L'éditeur des RFC appointe et maintient un bureau de révision éditoriale, qui, un peu comme les bureau éditoriaux des journaux et éditeurs professionnels, fournit à l'éditeur des RFC des avis et relectures des publications particulières proposées et un avis de politique générale et stratégique. La liste des membres du bureau de révision éditoriale est publique et peut être trouvée à http://www.rfc-editor.org/edboard.html.

Les membres du bureau de révision éditoriale servent à la discrétion de l'éditeur des RFC. De temps en temps, l'éditeur des RFC va solliciter l'IAB et d'autres sources pour des suggestions sur de nouvelles affectations et va rechercher des commentaires de l'IAB sur les personnes à appointer. L'éditeur des RFC va aussi solliciter des commentaires de l'IAB sur l'efficacité du processus de revue et la qualité des documents publiés et les critères appliqués. Cependant, pour assurer l'indépendance du processus de soumission indépendante, la décision finale d'appointer (ou non) les membres du bureau éditorial appartient à l'éditeur des RFC.

 	7.	Statut et disponibilité des revues

L'éditeur des RFC va conduire les revues discutées ci-dessus avec l'intention d'équilibrer l'équité pour les auteurs, la transparence du processus de revue pour la communauté générale, la protection des réviseurs contre de possibles mesures de rétorsion ou des pressions indues, et l'intérêt de la communauté, en rendant disponibles à la communauté tout désaccord significatif sur les documents publiés avec le même degré de minutie que celui des documents originaux reçus. À cette fin, les revues et les informations sur les réviseurs vont être rendues publiques dans les circonstances suivantes. Dans des cas où d'autres considérations s'appliquent, l'éditeur des RFC peut adopter des dispositions particulières après avoir revu les circonstances et l'action proposée avec l'IAB.

Tout réviseur qui participe au processus mentionné dans le présent document le fait à condition de donner son consentement au traitement des revues comme mentionné dans cette Section. Dans les cas particuliers, des arrangements individuels peuvent être préparés à l'avance avec l'éditeur des RFC.

Comme décrit au paragraphe 4.4, toutes les revues vont être effectuées en collaboration avec les auteurs du document (avec de possibles corrections rédactionnelles pour supprimer les expressions outrées). Les noms des réviseurs accompagnent normalement ces révisions, mais les réviseurs ont leur anonymat garanti sur demande de l'éditeur des RFC. L'éditeur des RFC va dans tous les cas transmettre tous les messages de dénégation de l'auteur au réviseur.

Rien dans cette section ou les paragraphes qui suivent n'empêche des communications privées entre les réviseurs, le bureau éditorial, et l'éditeur des RFC ; de telles communications vont rester confidentielles.

 	7.1	Révisions envoyées
Une fois qu'une décision finale d'acceptation ou de rejet a été prise sur un document, l'éditeur des RFC peut choisir d'envoyer l'ensemble complet des revues (et les dénégations de l'auteur, si il y en a) associées à un document, si le faire serait dans le meilleur intérêt de la communauté. L'auteur peut demander un envoi précoce des remarques de révision et des dénégations, pour inspirer des révisions non sollicitées supplémentaires, par exemple. Les noms des réviseurs vont accompagner leurs remarques, sauf pour un réviseur qui a demandé l'anonymat.

L'intention d'envoyer les remarques de révision finale sera notifée à l'auteur à l'avance. L'auteur peut alors demander que le document soit retiré et que les revues restent confidenteilles. Cependant, une telle demande d'un auteur doit être faite en temps utile, généralement dans les 14 jours de la notification de l'intention d'envoyer.

 	7.2	Documents rejetés
Si l'éditeur des RFC rejette un document, l'auteur a les options de recours suivantes :
o	demander une ou plusieurs revues supplémentaires (paragraphe 4.5) suivies par une reconsidération,
o	demander une revue de l'IAB (paragraphes 4.5 et 4.6) suivie par une reconsidération?
o	demander que les revues soient publiées sur le site de la Toile de l'éditeur des RFC.

 	7.3	Documents approuvés pour publication
En considérant si il va rendre public les matériaux de revue pour les documents acceptés pour publication, l'éditeur des RFC est supposé noter que le meilleur moyen de faire des commentaires ou faire part de son désaccord sur une RFC est généralement de faire une autre RFC ; ces revues critiques d'un document ne sont pas elles-mêmes l'objet d'une revue ; que le processus de revue et de réfutation est nécessairement fragmentaire ; et qu'un reviseur qui a des positions fortes sur un sujet sur lequel une revue a déjà été écrite n'a souvent pas besoin de faire un travail supplémentaire significatif pour produire un document en format de RFC à partir de cette revue.

 	8.	Droits de propriété intellectuelle

Le matériel suivant a été extrait des paragraphes pertinents du BCP 78 [RFC3978], [RFC4748] afin de rassembler toutes  les informations de soumission indépendante pour les publications techniques produites sous les auspices de l'IETF, de l'activité de soutien administratif de l'IETF (IASA, IETF Administrative Support Activity) ou de l'IETF Trust, ou de la Internet Society (ISOC) en un seul endroit et d'initialiser le processus de séparation des discussions des soumissions indépendantes de celles des documents sur la voie de la normalisation ou autres de l'IETF. Noter que le texte qui suit utilise le terme de "contribution de l'éditeur des RFC" pour décrire le même type de document appelé ailleurs dans ce document une "soumission indépendante". L'éditeur des RFC peut changer ces dispositions de temps en temps après avoir obtenu l'avis et le consentement de l'IETF Trust dans la capacité de l'éditeur des RFC d'organe formel de publication des RFC.

En soumettant une contribution de l'éditeur des RFC, chaque personne qui soumet réellement la contribution de l'éditeur des RFC, et chaque co-contributeur désigné, est réputé accepter les termes et conditions suivants, et accorder les droits suivants, en son nom et au nom de l'organisation que le contributeur représente ou par laquelle il est soutenu (si il en est) quand il soumet la contribution de l'éditeur des RFC.

a.	Pour les projets Internet qui sont supposés être soumis comme contributions de l'éditeur des RFC : dans la mesure où une contribution de l'éditeur des RFC ou toute portion de celle-ci est protégée par des droits de reproduction et autres droits d'auteur, le contributeur, et chaque co-contributeur désigné, et l'organisation qu'il représente ou qui le soutient (si il en est) accorde un droit irrévocable, non exclusif, sans redevance, valable dans le monde entier, et licence à l'IETF Trust et à l'IETF sur tous les droits de propriété intellectuelle de la contribution de l'éditeur des RFC pour au moins la durée de vie du projet Internet, de copier, publier, afficher, et distribuer la contribution de l'éditeur des RFC comme un projet Internet.

b.	Pour une contribution de l'éditeur des RFC soumise pour publication comme RFC, et dans la mesure décrite ci-dessus, le contributeur, chaque co-contributeur désigné, et les organisations représentées ci-dessus accordent la même licence à ces organisations et à la communauté comme un tout, de copier, publier, afficher, et distribuer la contribution de l'éditeur des RFC irrévocablement et à perpétuité et, aussi irrévocablement et à perpétuité, accordent les droits mentionnés ci-dessous à ces organisations et entités et à la communauté :

A.	de préparer ou permettre la préparation de traductions de la RFC dans des langages autres que l'anglais,

B.	sauf explicitement interdit dans les notices contenues dans une contribution de l'éditeur des RFC, de préparer des travaux dérivés (autres que des traductions) qui sont fondés sur, ou incorporent tout ou partie de, la contribution de l'éditeur des RFC, ou la commentent. La licence sur de tels travaux dérivés ne donnera pas à l'IETF Trust, l'IETF, ou autre partie préparant un travail dérivé, plus de droits que la licence sur la contribution originale de l'éditeur des RFC, et

C.	de reproduire toutes marques commerciales, marques de service, ou noms commerciaux qui sont inclus dans la contribution de l'éditeur des RFC seulement en connexion avec la reproduction, distribution, ou publication de la contribution de l'éditeur des RFC et de ses travaux dérivés comme permis dans ce paragraphe. Toute entité reproduisant les contributions de l'éditeur des RFC devra, comme condition de la permission d'une telle reproduction, préserver les identifiants de marques commerciales et marques de service utilisés par le contributeur de la contribution de l'éditeur des RFC, incluant les (TM) et (R) lorsque approprié.

D.	le contributeur accorde à l'IETF Trust et à l'IETF, la permission de faire référence au ou aux noms et adresses du ou des contributeurs et des organisations qu'il représente ou qui le soutiennent (si il en est).

 	9.	Considérations sur la sécurité

Le présent document spécifie une procédure aministrative et de publication pour l'éditeur des RFC (et, indirectement, pour l'IETF). Il n'a pas d'implications spécifiques sur la sécurité.

 	10.	Remerciements

Des remerciements tout particuliers sont dus à Bob Hinden et à Craig Partridge, qui ont fait plusieurs suggestions pour améliorer le texte dans des versions antérieures du présent document, et à Stewart Bryant, Scott Bradner, Brian Carpenter, Vint Cerf, Leslie Daigle et Olaf Kolkman, qui ont fait nombre de suggestions utiles sur l'organisation et le contenu des versions ultérieures. Nous exprimons aussi tous nos remerciements à l'IETF et à Scott Bradner, éditeur, pour les matériaux extraits du BCP 78 [RFC3978] et utilisés dans la Section 8.

 	11.	Références
 	11.1	Références normatives

[RFC2026]	S. Bradner, "Le processus de normalisation de l'Internet -- Révision 3", (BCP0009) octobre 1996. (Remplace RFC1602, RFC1871) (MàJ par RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378)

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

[RFC3932]	H. Alvestrand, "Procédures des documents de l'IESG et de l'éditeur de RFC", octobre 2004. (BCP0092)  (Obsolète, voir RFC5742) 

[RFC3978]	S. Bradner, éd., "Droits de l'IETF dans les contributions", mars 2005. (MàJ par RFC4748 ; RFC5378)

[RFC4748]	S. Bradner, éd., "Mise à jour de la RFC 3978 pour tenir compte de l'IETF Trust". (MàJ RFC3978 ; Obsolète, voir RFC5378)

 	11.2	Références pour information

[IEN137]	D. Cohen, "Sur les guerres saintes, plaidoyer pour la paix", IEN 137, avril 1980, <ftp://ftp.rfc-editor.org/in-notes/ien/ien137.txt >.

[RFC0021]	V. Cerf, "Réunion sur le réseau", octobre 1969.

[RFC1109]	V. Cerf, "Rapport du second groupe ad hoc de révision de la gestion de réseau", août 1989.

[RFC1591]	J. Postel, "Structure et délégation du système de noms de domaine", mars 1994. (Information)

[RFC1810]	J. Touch, "Rapport sur les performances de MD5", juin 1995. (Information)

[RFC2434]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre, 1998. (Rendue obsolète par la RFC 5226)

[RFC2441]	D. Cohen, "Travailler avec Jon Postel, hommage rendu à l'UCLA, 30 octobre 1998", novembre 1998. (Information)

[RFC2555]	Éditeur des RFC, et autres, "30 ans de RFC", avril 1999. (Information)

[RFC2860]	B. Carpenter et autres, "Mémorandum d'accord sur le travail de l'IANA", juin 2000. (Information)

[RFC4714]	A. Mankin, S. Hayes, "Exigences pour le service des publications techniques de l'IETF", octobre 2006. (Information)

[RFC4844]	L. Daigle, éd., Internet Architecture Board, "La série des RFC et l'éditeur des RFC", juillet 2007. (Info.)

[RFC7322]	H. Flanagan, S. Ginoza, "Guide de style des RFC", septembre 2014. (Remplace RFC2223, (Information)

Appendice A.	Membres de l'IAB au moment de l'approbation de ce document

Bernard Aboba
Loa Andersson
Brian Carpenter
Leslie Daigle
Elwyn Davies
Kevin Fall
Olaf Kolkman
Kurtis Lindqvist
David Meyer
David Oran
Eric Rescorla
Dave Thaler
Lixia Zhang

Adresse des auteurs

John C Klensin (éditeur)	Dave Thaler (éditeur)	
1770 Massachusetts Ave, #322	One Microsoft Way	
Cambridge, MA  02140	Redmond, WA  98052	
USA	USA	
téléphone : +1 617 491 5735	téléphone : +1 425 703 8835	
mél : john-ietf@jck.com 	mél : dthaler@microsoft.com 	

 	Déclaration complète des droits de reproduction

Copyright (C) The IETF Trust (2007).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org .

Remerciement 
Le financement de la fonction d’édition des RFC est actuellement fourni par la Internet Society.