Guide & FAQ

From RFC.Wiki
Revision as of 12:50, 4 December 2020 by Sysop (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Ce site utilise au départ le logiciel Médiawiki, Mailman et les réflexions engagées autour des concepts de cyberagora. Il devrait évoluer en fonction des attentes exprimées par ses utilisateurs.

qu'est-ce qu'une RFC 
Les requests for comments (RFC), sont des « demandes de commentaires ». Ce sont des documents officiels, du moins reconnus par les communautés Internet, et aident à standardiser des protocoles, des formats, des organisations, ou aident à implémenter des matériels, des fonctionnalités logicielles, etc. Par exemple la suite de protocoles TCP/IP sont des normes RFC établies par l'Internet Engineering Task Force (IETF). Dans ce dernier type de cas, les RFC (communautaires) sont elles-mêmes devenues des normes (source Framalibre)

Soumissions indépendantes

Le flux de soumission indépendant permet la publication RFC pour certains documents qui ne relèvent pas du processus officiel IETF / IAB / IRTF mais qui sont pertinents pour la communauté Internet et qui atteignent des niveaux raisonnables de qualité technique et éditoriale.

Soumission

Chaque document à publier en tant que RFC doit d'abord être mis en ligne en tant que brouillon Internet avec un format conforme aux directives de l'IETF. (L'exception est un document qui est soumis pour examen en tant que RFC du 1er avril.) Pour publier un projet Internet, utilisez l'outil de soumission de projet Internet. Si vous ne parvenez pas à utiliser l'outil, envoyez votre brouillon à internet-drafts@ietf.org.

Pour une soumission indépendante, l'auteur doit envoyer un message électronique à l'éditeur indépendant des soumissions: rfc-ise@rfc-editor.org. Ce message doit inclure les informations suivantes:

  • Le nom de fichier du brouillon Internet publié qui est soumis.
  • La catégorie souhaitée (informationnelle ou expérimentale) de la RFC.
  • Un résumé de la discussion connexe de ce document, le cas échéant, qui a eu lieu dans un groupe de travail de l'IETF ou dans l'IESG.
  • Une affirmation selon laquelle aucune allocation IANA dans le document ne nécessite une révision de l'IETF ou une action de normalisation. Voir RFC 8126 pour une définition de ces termes et RFC 8792 pour plus d'informations sur la façon dont les demandes IANA sont traitées dans les documents Independent Stream. Si le document ne peut pas être publié sur l'Independent Stream, il doit être envoyé à l'IESG.
  • Facultativement, une déclaration sur l'objectif de la publication de ce document, son public cible, ses mérites et sa signification.
  • Facultativement, des noms et des coordonnées suggérés pour un ou plusieurs examinateurs potentiels compétents et indépendants pour le document. Cela peut accélérer le processus d'examen et d'approbation.
  • L'éditeur indépendant des soumissions (ISE) utilise l'IETF Datatracker à toutes les étapes de la gestion des documents Independent Stream. La page Datatracker pour un brouillon donné montre son état ISE. De plus, une liste complète montrant l'état ISE pour tous les documents du flux indépendant est disponible ici.

Veuillez noter que les procédures et exigences relatives au traitement des droits (y compris les droits d'auteur et les droits de propriété intellectuelle) dans le flux de soumission indépendant sont documentées dans la RFC 5744 .

Examens de documents

L'éditeur RFC peut faire des suggestions générales et / ou spécifiques à l'auteur ou aux auteurs sur les améliorations de la qualité éditoriale du document ou les violations des règles de format et de contenu. Les auteurs devront effectuer les mises à jour suggérées, soumettre une nouvelle version et informer l'éditeur RFC.

Chaque soumission indépendante fera l'objet d'au moins un examen, conformément aux lignes directrices des examinateurs. Les réviseurs peuvent être membres du comité de rédaction indépendant des soumissions (ISEB) ou une personne connue de l'éditeur de la RFC ou de l'ISEB pour être compétente dans le sujet du document. Les résultats des révisions, y compris les problèmes de rédaction et de contenu, seront renvoyés aux auteurs du document et éventuellement partagés avec l'ISEB.

Une soumission indépendante dont le matériel est en dehors de la portée (assez large) de la série RFC (par exemple, elle doit être en quelque sorte liée à Internet) ou qui contient une écriture excessivement mauvaise sera rejetée. L'éditeur RFC applique généralement une norme libérale si un document est pertinent et intéressant pour certains lecteurs potentiels. Dans la plupart des cas, l'éditeur RFC demandera aux auteurs de réviser et de soumettre à nouveau leur document.

Les règles générales pour les soumissions indépendantes se trouvent dans la RFC 4846 . Les détails des procédures d'examen dans ce document sont approximativement définis par le diagramme d'états et une explication détaillée des états pour le processus d'examen préalable à la publication.

Examen du processus IESG

Une fois qu'un document a été accepté par l'éditeur RFC, l'IESG examinera s'il entre en conflit avec le processus de normes de l'IETF; voir RFC 5742 pour plus de détails. L'IESG fait une recommandation à l'éditeur RFC.

Les documents soumis indépendamment sont parfois renvoyés à un groupe de travail de l'IETF qui travaille déjà sur le même sujet; dans ces cas, l'auteur sera invité à travailler au sein de l'IETF pour développer le document, et il sera retiré du flux de soumission indépendant.

L'IESG peut recommander que le document ne soit pas publié ou que la publication soit retardée ( RFC 5742 ). Bien que la décision de publication finale soit prise par l'éditeur RFC, il est très peu probable qu'une telle demande IESG ne soit pas honorée. Si l'IESG n'a pas d'objection, le document entre dans la file d'attente de publication. Il sera publié avec une «Note IESG» qui est une décharge de responsabilité de l'IETF pour le document.

Independent Submissions

The independent submission stream allows RFC publication for some documents that are outside the official IETF/IAB/IRTF process but are relevant to the Internet community and achieve reasonable levels of technical and editorial quality.

Submission

Every document to be published as an RFC must first be posted online as an Internet-Draft with a format following IETF guidelines. (The exception is a document that is submitted for consideration as an April 1st RFC.) To post an Internet-Draft, use the Internet-Draft Submission Tool. If you are unable to use the tool, then send your draft to internet-drafts@ietf.org.

For an independent submission, the author should send an email message to the Independent Submissions Editor: rfc-ise@rfc-editor.org. This message should include the following information:

  • The file name of the published Internet-Draft that is being submitted.
  • The desired category (Informational or Experimental) of the RFC.
  • A summary of related discussion of this document, if any, that has occurred in an IETF working group or in the IESG.
  • An assertion that no IANA allocation in the document requires IETF Review or Standards Action. See RFC 8126 for a definition of these terms, and RFC 8792 for more information about how IANA requests are handled in Independent Stream documents. If the document cannot be published on the Independent Stream it should be sent to the IESG.
  • Optionally, a statement of the purpose of publishing this document, its intended audience, its merits and significance.
  • Optionally, suggested names and contact information for one or more competent and independent potential reviewers for the document. This can speed the review and approval process.
  • The Independent Submissions Editor (ISE) uses the IETF Datatracker through all stages of Independent Stream document handling. The Datatracker page for a given draft shows its ISE State. As well, a complete list showing the ISE state for all documents in the Independent Stream is available here.

Please note that procedures and requirements for handling rights (including copyright and IPR) in the Independent Submission Stream are documented in RFC 5744.

Document Reviews

The RFC Editor may make general and/or specific suggestions to the author(s) about improvements in the editorial quality of the document or violations of the format and content rules. The author(s) will be expected to make the suggested updates, submit a new version, and inform the RFC Editor.

Each independent submission will receive at least one review, under the reviewer guidelines. Reviewers may be members of the Independent Submissions Editorial Board (ISEB) or some person known to the RFC Editor or the ISEB to be competent in the subject of the document. Results of the review(s), including editorial and content problems, will be returned to the document author(s) and perhaps shared with the ISEB.

An independent submission whose the material is outside the (rather broad) scope of the RFC series (for example, it must be somehow related to the Internet) or that contains excessively bad writing will be rejected. The RFC Editor generally applies a liberal standard if a document is at all relevant and interesting to some potential readers. In most cases the RFC Editor will request that the author(s) revise and resubmit their document.

General rules for independent submissions are found in RFC 4846. The details of the review procedures in that document are approximately defined by the state diagram and a detailed explanation of states for the pre-publication review process.

IESG Process Review

Once a document has been accepted by the RFC Editor, the IESG will consider whether it conflict with the IETF standards process; see RFC 5742 for details. The IESG makes a recommendation to the RFC Editor.

Documents submitted independently are sometimes remanded to an IETF Working Group that is already working on the same subject; in these cases the author will be asked to work within the IETF to develop the document, and it will be removed from the independent submission stream.

The IESG may recommend that the document not be published, or that publication be delayed (RFC 5742). Although the final publication decision is made by the RFC Editor, it is very unlikely that such IESG request will not be honored. If the IESG has no objection, the document enters the publication queue. It will be published with an “IESG Note” that is a disclaimer of IETF responsibility for the document.