Résumé

  • draft-sayre-gendispatch-derivative-06 est un Internet-Draft individuel actif. Il proposerait de réserver le mécanisme de non-dérivation aux RFC et Internet-Drafts utilisés dans le processus IETF; ce n’est ni un RFC ni une règle déjà adoptée.
  • RFC 5378 sépare une Contribution IETF, définie largement, d’un Document IETF, défini plus étroitement. La déclaration active de l’IESG indique comment traiter les mentions contraires à la politique; le compte rendu d’IETF 126 prévoit encore discussion IPR-WG puis avis juridique.
  • Daniel Kade recommande un reçu de statut qui garde la soumission et sa mention, mais enregistre à part la qualification, la version de règle, l’autorité de procédure, l’action et le recours. Cette recommandation n’est ni un avis juridique ni une exigence IETF.

Une formule de messagerie ne tranche pas la procédure

Une norme ouverte dépend de messages ordinaires : objection, correctif, question de déploiement, note de réunion, recours, première idée de texte. Un courrier peut porter un avertissement ajouté par son auteur ou par le système de messagerie de son employeur. Lire cet avertissement comme une réponse complète est séduisant. On éviterait ainsi de déterminer le type de texte, le droit nécessaire à une future spécification et le responsable d’une éventuelle action.

Les documents publics de l’IETF refusent précisément ce raccourci. RFC 5378 définit une Contribution comme une soumission destinée à un Internet-Draft ou à un RFC, mais aussi comme une déclaration faite dans le cadre d’une activité IETF. Les communications écrites et électroniques destinées à un groupe de travail, à une liste, à l’IESG, à l’IAB, à un BOF ou à la plénière peuvent donc entrer dans cette catégorie. Un Document IETF est autre chose : un RFC ou un Internet-Draft utilisé dans le processus de normalisation.

Cette différence ne retire pas de valeur à un message. Elle empêche au contraire qu’un message soit chargé de pouvoirs qu’il ne possède pas. Une contribution peut apporter une information technique indispensable sans être une spécification que le groupe peut formellement adopter. Une archive peut conserver le texte sans décider de sa portée. Un participant peut expliquer un risque sans acquérir l’autorité d’interpréter les droits de tous les autres participants.

RFC 5378 expose pourquoi des droits déterminés sont nécessaires lorsque l’IETF développe et publie des documents. Il reconnaît également des cas étroits : technologie propriétaire, republication du travail d’une autre organisation de normalisation, ou contribution dont l’auteur attend encore de savoir si elle sera retenue pour le développement IETF. Ces exceptions ne sont pas un modèle de signature applicable à toute conversation. Elles rendent la qualification plus importante.

Le projet propose une frontière; il ne clôt pas un dossier

La version -06 date du 13 août 2026. Le Datatracker la présente comme un Internet-Draft individuel actif, sans flux RFC, avec une déclaration de consensus inconnue et l’état IESG I-D Exists. Sa proposition est ciblée : le mécanisme de non-dérivation serait limité aux Contributions qui sont des Internet-Drafts et des RFC employés dans le processus de normalisation. Les autres droits prévus par RFC 5378 resteraient inchangés.

Il faut lire ce statut au pied de la lettre. Le texte n’est pas encore une modification de RFC 5378. Il ne statue sur aucun courriel particulier. Il ne démontre pas qu’un message a été perdu, édité, retiré, mal archivé ou mal compris. Il ne fait pas d’un lecteur du projet un conseiller juridique et ne transforme pas une conclusion de droit en adoption technique.

Le chemin suivi à IETF 126 confirme cette prudence. GENDISPATCH a orienté le sujet vers une discussion supplémentaire sur la liste IPR-WG, suivie d’un examen par un conseil juridique. Un renvoi est un choix de lieu de discussion; ce n’est pas l’adoption d’une politique. Un examen à venir n’est pas une conclusion publiée. Ce sont des états distincts, dont aucun ne doit être résumé en disant que « l’IETF a déjà décidé ».

La déclaration de l’IESG publiée en octobre 2025 est une autre pièce, également limitée. Elle soutient que les droits de dérivation d’une Contribution ne peuvent être retenus que lorsqu’il s’agit d’un Document IETF et dans des circonstances restreintes. Elle indique qu’une mention incompatible avec les politiques doit être ignorée dans une Contribution et qu’un responsable de processus peut en demander le retrait.

Cette déclaration donne une position de politique sur l’effet de la mention; elle n’efface pas le message qui la portait, ne désigne pas à l’avance le responsable de chaque cas et ne remplace ni le projet actuel ni l’avis juridique annoncé.

Conserver la pièce reçue, rendre l’acte lisible

Deux erreurs opposées sont possibles. La première donne à chaque pied de mail un droit de veto opaque sur une discussion. La seconde lit « ignorer » comme l’autorisation de faire disparaître le texte, son contexte et la raison de l’action. Une procédure fiable n’a besoin ni de l’une ni de l’autre.

Elle doit d’abord conserver l’objet reçu : une référence stable, la date, le canal, une empreinte d’intégrité et le texte tel qu’il est arrivé. Cette conservation est un fait documentaire; elle ne valide pas la mention ajoutée.

Elle doit ensuite exposer l’objet de qualification. Est-ce le message, un Internet-Draft nommé, le texte d’un RFC, un recours, un procès-verbal ou une observation à propos d’un document? L’apparence d’un courriel et l’identité de son expéditeur ne suffisent pas. Une qualification doit pouvoir être contestée et relue.

Vient la règle appliquée. Le dossier doit nommer la disposition de RFC 5378, la déclaration IESG, l’instruction de l’IETF Trust ou une mise à jour effectivement adoptée, avec sa version et son état. Une proposition de modification ne doit jamais être étiquetée comme une règle déjà en vigueur.

Enfin, il faut l’acte. Un rôle autorisé a-t-il traité la mention comme inapplicable? En a-t-il demandé le retrait? A-t-il orienté l’affaire vers un examen? A-t-il demandé une nouvelle soumission avant une étape documentaire? N’a-t-il rien fait, car il s’agissait seulement d’une discussion? Un état sans acte responsable devient une incantation administrative.

Daniel Kade appelle cet assemblage un reçu de statut de contribution. Sa partie visible peut rester concise : identifiant et empreinte du message, canal et date, référence vers la mention reçue, objet qualifié, version de règle, rôle responsable, action, voie de recours et état de remplacement éventuel. Les échanges qui doivent rester confidentiels peuvent avoir une annexe protégée. La confidentialité ne devrait pas rendre impossible de savoir qu’une décision existe, qui l’a prise et quelle en est la portée.

Les libellés doivent être sobres. « Mention reçue » n’est pas « mention valable ». « Contribution » n’est pas « texte adopté ». « Règle appliquée » n’est pas « avis juridique ». « Retrait demandé » n’est pas « message réécrit ». « Renvoyé à un conseil » n’est pas « conseil déjà prononcé ». Ces séparations protègent autant le contributeur que le responsable du processus.

Une transparence proportionnée protège la participation

Il serait déraisonnable de créer un dossier juridique pour chaque message d’une liste. La réception ordinaire d’une contribution doit rester légère. Le reçu est pertinent lorsqu’une question de statut devient matériellement importante : une restriction qui affecte le traitement d’un document, une demande d’un responsable, un recours ou une action contestée. Il doit être court, réutilisable et attaché au différend précis, non à l’identité entière du participant.

Le bénéfice est de conserver une collaboration praticable. Un autre participant peut répondre à une idée sans prétendre rééditer le texte d’origine. Un président peut accomplir une étape de processus sans devenir juge de droits. Un conseiller peut examiner la règle sans choisir le mérite technique d’une solution. Un groupe peut considérer une soumission ultérieure sans imaginer qu’un échange antérieur a créé un mandat.

La leçon de Heng Lu s’applique ici avec retenue : participation et compétence peuvent être de vraies preuves, mais elles ne sont pas un mandat. Le déposant d’un message ne gouverne pas l’IETF par une formule de bas de page. L’archive ou l’outil qui stocke ce message ne gouverne pas davantage l’histoire du dossier. La règle des droits borne un acte précis; elle ne redistribue pas toute autorité de procédure.

Le reçu doit montrer la limite, non créer une porte nouvelle

Un bon reçu comporte au minimum sept dimensions : la preuve reçue; l’objet auquel s’applique la qualification; la règle et sa version; le rôle compétent; l’action effectivement réalisée; le recours ou l’examen restant; et l’état actuel avec ses décisions de remplacement. Il ne doit pas devenir une condition d’entrée, un tribunal de licences pour une liste de discussion, ni une machine à exclure des voix ordinaires.

Son utilité est plus modeste et plus solide. Lorsqu’une mention devient pertinente, il empêche qu’un automatisme d’entreprise obtienne par accident le pouvoir de bloquer un processus, ou qu’une consigne de l’ignorer devienne une histoire sans auteur. L’ouverture durable dépend de cette possibilité de voir comment un texte est passé de message à acte de procédure.

Limites de l’évidence

Les sources examinées ne démontrent ni l’adoption du projet -06, ni une mise à jour RFC, ni un consensus IETF, ni un avis juridique final. Elles ne démontrent pas qu’une personne, une entreprise ou une archive a mal agi. Elles ne créent aucune obligation de construire le reçu proposé.

La recommandation de Daniel Kade est une discipline de gouvernance. Elle n’est pas un avis sur le droit d’auteur, un protocole IETF, une condition de publication ou une instruction de modifier une correspondance.

Sources

  1. RFC 5378 — Rights Contributors Provide to the IETF Trust
  2. IESG Statement on Clarifying Derivative Works Rights
  3. draft-sayre-gendispatch-derivative-06 — Clarification of Derivative Works Restrictions
  4. Minutes: IETF 126 GENDISPATCH
  5. RFC 7282 — On Consensus and Humming in the IETF
  6. Heng Lu — The Multi-Stakeholder Mirage