Zusammenfassung

  • draft-sayre-gendispatch-derivative-06 ist ein aktiver individueller Internet-Draft. Er schlägt eine Beschränkung des No-Derivatives-Mechanismus auf im Standardisierungsprozess genutzte RFCs und Internet-Drafts vor; er ist weder RFC noch verabschiedete Regel.
  • RFC 5378 unterscheidet die weit gefasste IETF Contribution von dem engeren IETF Document. Die aktive IESG-Erklärung beschreibt den Umgang mit widersprechenden Hinweisen; IETF 126 verwies auf weitere IPR-WG-Diskussion und anschließende Rechtsprüfung.
  • Daniel Kade empfiehlt einen Beitragsstatusbeleg, der den Eingang bewahrt und Klassifikation, Regel, zuständige Rolle, Handlung und Überprüfung getrennt ausweist. Das ist keine Rechtsberatung und keine IETF-Pflicht.

Eine Signaturzeile ist keine Prozessautorität

Technische Arbeit beginnt oft als Nachricht. Jemand meldet einen Interoperabilitätsfehler, widerspricht einer Annahme, schlägt Text vor oder dokumentiert einen Einspruch. Dass die Nachricht in einer IETF-Umgebung erscheint, macht sie nicht automatisch zu einem Dokument, das nach denselben Regeln wie ein Standardsentwurf fortentwickelt wird. Und dass sie einen Firmenhinweis enthält, macht diesen Hinweis nicht zu einer Institution mit Entscheidungsgewalt.

RFC 5378 liefert die notwendige Trennung. Eine Contribution umfasst nicht nur Einreichungen für einen Internet-Draft oder RFC, sondern auch Äußerungen im Rahmen einer IETF-Aktivität—etwa schriftliche und elektronische Kommunikation an Arbeitsgruppen, Listen, BOFs, IESG, IAB oder Plenum. Ein IETF Document ist dagegen ein RFC oder Internet-Draft, der im IETF-Standardisierungsprozess benutzt wird. Beteiligung und Dokumentstatus sind deshalb keine austauschbaren Wörter.

Das schützt die Substanz einer Nachricht. Ein Beitrag kann für die technische Beurteilung unverzichtbar sein und trotzdem kein adoptierbarer Text sein. Ein Archiv kann das Eingegangene beweissicher halten, ohne darüber zu entscheiden, welche Rechte daraus folgen. Ein Autor kann einen Vorbehalt äußern, ohne damit die Befugnis zu erhalten, den Ablauf für andere festzulegen.

RFC 5378 erklärt, warum die IETF für die Weiterentwicklung und Veröffentlichung von Dokumenten bestimmte Rechte benötigt. Es nennt begrenzte Ausnahmen, etwa proprietäre Technologien, Wiederveröffentlichungen anderer Standardisierungsorganisationen und Beiträge, die vor einer Annahme noch unter Vorbehalt stehen. Gerade deshalb ist die Objektfrage entscheidend. Eine Ausnahme ist keine allgemeine E-Mail-Schablone.

Der Entwurf ist ein Vorschlag, kein erledigter Fall

Die Version -06 vom 13. August 2026 wird als aktiver individueller Internet-Draft geführt: ohne RFC-Stream, mit unbekanntem Konsenshinweis und IESG-Status I-D Exists. Ihr Vorschlag beschränkt den Mechanismus gegen abgeleitete Werke auf Contributions, die RFCs oder Internet-Drafts im Standardisierungsprozess sind. Andere nach RFC 5378 eingeräumte Rechte sollen unberührt bleiben.

Das ändert RFC 5378 nicht sofort. Es entscheidet nicht über eine einzelne Mail, beweist keine fehlerhafte Archivierung oder Bearbeitung und erteilt keinem Leser Rechtsentscheidungskompetenz. Das GENDISPATCH-Protokoll von IETF 126 hält einen vorsichtigeren nächsten Schritt fest: weitere Diskussion auf der IPR-WG-Liste, danach Prüfung durch Rechtsberatung. Verweisung ist keine Annahme; angekündigte Prüfung ist kein veröffentlichtes Ergebnis.

Die IESG-Erklärung von Oktober 2025 hat einen anderen, gegenwärtigen Status. Sie vertritt die Auffassung, dass Bearbeitungsrechte für eine Contribution nur dann und nur eng zurückbehalten werden können, wenn diese Contribution ein IETF Document ist. Sie sagt, mit den IETF-Regeln kollidierende Hinweise seien in einer Contribution zu ignorieren, und ein Process Owner könne ihre Entfernung verlangen. Das bestimmt den Richtlinieneffekt eines Hinweises. Es erlaubt weder, das Original umzuschreiben, noch legt es die zuständige Rolle jedes künftigen Konflikts fest.

Beweis erhalten, Statushandlung offenlegen

Es gibt zwei schlechte Abkürzungen. Die eine behandelt jeden Footer als verdecktes Vetorecht. Die andere liest „ignorieren“ als Berechtigung, Footer und Begründung aus dem Verlauf zu löschen. Ein Beitragsstatusbeleg braucht keine dieser Abkürzungen.

Er bewahrt zunächst das empfangene Objekt: stabile Kennung, Kanal, Zeitpunkt, Integritätshash und Verweis auf den Hinweis im Eingangszustand. Danach benennt er den Klassifikationsgegenstand: Nachricht, bestimmter Draft, RFC-Text, Einspruch, Protokoll oder Kommentar. Er weist die tatsächlich herangezogene Regel samt Version und Geltungsstatus aus. Schließlich hält er die Handlung einer zuständigen Rolle fest: als nicht anwendbar behandelt, Entfernung verlangt, zur Prüfung verwiesen, Neueinreichung verlangt oder keine Prozesshandlung vorgenommen.

Daniel Kade nennt diese Verbindung Beitragsstatusbeleg. Öffentlich reichen eine Kennung und ein Digest, Zeitpunkt und Kanal, der konservierte Hinweis, Klassifikation, Regelversion, verantwortliche Rolle, Handlungsstatus, Überprüfungsweg und eine etwaige Ablöseentscheidung. Geschützte Korrespondenz kann geschützt bleiben. Schutzbedürftigkeit darf aber nicht verhindern, dass der Umfang einer Entscheidung, ihr Urheber und ihr aktueller Status sichtbar sind.

Die Begriffe müssen diszipliniert bleiben: „Hinweis eingegangen“ heißt nicht „Hinweis wirksam“. „Contribution“ heißt nicht „Dokument angenommen“. „Regel angewandt“ heißt nicht „Rechtsgutachten“. „Entfernung verlangt“ heißt nicht „Original verändert“. „Zur Prüfung verwiesen“ heißt nicht „Prüfung abgeschlossen“.

Offenheit ohne Aktenzwang

Nicht jede Mail benötigt einen Beleg. Die Schwelle liegt bei einem materiellen Statuskonflikt: wenn ein Vorbehalt die Behandlung eines Dokuments beeinflusst, ein Prozessverantwortlicher handelt, ein Einspruch erfolgt oder eine Handlung umstritten ist. Der Beleg darf kein Identitätsregister, keine Eintrittsbedingung und kein Lizenzgericht für gewöhnliche Listenbeiträge werden.

So können Rollen getrennt kooperieren. Andere Teilnehmende können auf eine Idee reagieren, ohne den Ursprungswortlaut als eigenen Text auszugeben. Ein Chair kann einen Schritt steuern, ohne zum Rechtsgericht zu werden. Eine Rechtsprüfung kann eine Regel bewerten, ohne den technischen Entwurf auszuwählen. Eine Arbeitsgruppe kann eine neue Fassung beraten, ohne eine frühere Nachricht zum Mandat umzudeuten.

Heng Lus Unterscheidung ist hier ein hilfreicher Maßstab: Teilnahme und Sachkunde sind Beleg, nicht Mandat. Ein Absender regiert nicht durch seine Signatur. Ein Archiv regiert nicht durch seine Speicherfunktion. Die Rechtefrage begrenzt eine konkrete Prozesshandlung; sie verteilt nicht sämtliche institutionelle Macht neu.

Evidenzgrenzen

Die geprüften Quellen zeigen weder die Annahme von -06 noch eine RFC-Aktualisierung, IETF-Konsensfeststellung oder ein abgeschlossenes Rechtsgutachten. Sie belegen kein Fehlverhalten eines Autors, Unternehmens oder Archivs. Der Beitragsstatusbeleg ist Daniel Kades Empfehlung, kein IETF-Protokoll und keine Anweisung, Korrespondenz zu verändern.

Quellen

  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