Zusammenfassung

  • draft-moonesamy-authorship-ietf-00 wurde am 9. September 2026 als aktiver individueller Internet-Draft veröffentlicht. Er ist weder angenommene IETF-Arbeit noch beschlossene Politik.
  • Der Text fragt nach Verfahrensleitlinien für generative KI bei Autorschaft und Redaktion. Als mögliche Prüfung des menschlichen Elements nennt er einen schnellen mündlichen Schlagabtausch.
  • Ein solches Gespräch kann Sachkenntnis zeigen. Es belegt nicht die Herkunft des Textes, Zustimmung, Rechteklärung, Werkzeugumfang oder Verantwortung für eine bestimmte Fassung.
  • Dafür schlage ich einen revisionsbezogenen Autorschaftsnachweis vor. Er ist Daniel Kades Governance-Analyse, keine Vorgabe der beiden aktiven Entwürfe.

Der neue Eintrag ist eine Frage, keine IETF-Entscheidung

Der Datatracker verzeichnet Fassung 00 von Reflections on IETF Authorship am 9. September um 11:19 UTC. Der individuelle Entwurf ist Active und trägt den Zustand I-D Exists; ein RFC-Stream, verantwortlicher Area Director oder IESG-Verfahren fehlen. Nach der öffentlichen IETF-Erklärung darf jede Person einen Internet-Draft einreichen. Aus der Aufnahme in das Repository folgt keine institutionelle Billigung.

Gerade bei einem Text über institutionelle Rollen muss dieser Status sichtbar bleiben. Der Draft zeichnet frühere Auseinandersetzungen über Autoren, Editoren, Mitwirkende und Danksagungen nach. Die RFC Series verbindet reale Namen mit Anerkennung und Verantwortung. Gleichzeitig soll ein Dokument des IETF-Streams einen viel breiteren Konsens ausdrücken als die Personenzeile auf der ersten Seite.

Generative KI verschärft damit eine alte Frage. Soll die Gemeinschaft Spezifikationen annehmen oder implementieren, die mit solchen Werkzeugen geschrieben wurden? Braucht es Verfahrensregeln, oder reicht die Entscheidung einzelner Autoren und Editoren? Fassung 00 setzt weder Offenlegungsschwelle noch Formular, Prüfstelle, Sanktion oder Beschwerdeweg. Auch die Erklärung, mehr -00-Einreichungen im Jahr 2026 könnten auf eine niedrigere Schreibschwelle zurückgehen, ist die Einschätzung des Draft-Autors und keine festgestellte IETF-Kausalität.

Am greifbarsten ist die Idee eines spontanen „cut and thrust“-Gesprächs. Ein Working Group könnte damit prüfen, ob hinter dem Manuskript ein Mensch steht, der die Argumente ohne umfassendes Skript vertreten kann. Das ist ein Vorschlag für die Begutachtung, noch kein Nachweisverfahren für Autorenschaft.

Beherrschung des Gegenstands beweist keine Textkette

Ein unvorbereitetes Fachgespräch liefert wertvolle Beobachtungen. Die Person muss Annahmen verbinden, Gegenbeispiele einordnen, Grenzen benennen und begründen, warum eine Alternative verworfen wurde. Dadurch kann eine Gruppe Unklarheiten erkennen, die im geglätteten Dokument verborgen bleiben.

Doch diese Beobachtung gilt für eine Fähigkeit in einem Moment. Man kann einen fremd verfassten Entwurf hervorragend verstehen. Ein Hauptautor kann mündlich weniger schnell sein. Eine Mitwirkende kennt ihren Abschnitt womöglich besser als der Editor des Gesamttexts. Sprache, Behinderung, Zeitzone und Sitzungsformat beeinflussen die spontane Leistung, ohne Beitrag oder Verantwortung zu messen.

Das Gespräch rekonstruiert auch nicht die Herkunft einzelner Sätze. Es zeigt nicht, was ein Mensch schrieb, was aus einem früheren RFC übernommen, von Software vorgeschlagen oder nach einem Review umgearbeitet wurde. Es belegt weder die Zustimmung aller Genannten noch korrekte Anerkennung übernommener Inhalte. Ebenso wenig beweist es die Grundlage für BCP-78- und BCP-79-Erklärungen oder eine unveränderte Arbeitsteilung in der nächsten Revision.

Die belastbare Aussage lautet deshalb nur: Diese Person konnte den Vorschlag zu diesem Zeitpunkt erläutern und verteidigen. Autorenschaft ist dagegen eine fortlaufende Aussage über Beitrag, Zustimmung und Verantwortung. Wer beides gleichsetzt, macht aus einem nützlichen Review-Instrument eine Abkürzung ohne Provenienz.

Bestehende Regeln halten Namen und Konsens auseinander

Das aktive IESG Statement von 2021 verbietet „surprised authorship“. Niemand darf ohne Zustimmung und wesentlichen Beitrag als Autor oder Mitwirkender aufgeführt werden. Namen sollen keine Unterstützung vortäuschen; fehlende Zustimmung gefährdet zudem die Aussagen des Einreichers zu BCP 78 und BCP 79.

RFC 7322 überlässt die Autoren- und Editorenliste dem jeweiligen Stream. Auf der ersten Seite stehen üblicherweise höchstens fünf Personen. Bei mehr Namen soll die genehmigende Stelle prüfen, ob verantwortliche Editoren und getrennte Contributors oder Acknowledgements die Arbeit besser abbilden. Die Genannten müssen in AUTH48 zustimmen und später auf Anfragen wie Errata reagieren. Ein IESG Statement von 2024 unterscheidet zusätzlich Autor, Mitwirkenden und Danksagung nach Gewicht des Beitrags.

Diese Zuordnung ersetzt keinen Konsens. RFC 8789 fordert für IETF-Stream-Dokumente rough consensus. Wer schreibt, wer genannt wird, wer zustimmt, wer als Stream genehmigt und wer implementiert, kann sich überschneiden; die institutionellen Behauptungen bleiben verschieden.

Daneben existiert der aktive individuelle Draft Principles and Guidelines for Assignment of RFC Authorship. Fassung 06 hält Autoren und Editoren für Inhalt und geistiges Eigentum verantwortlich und schließt ein KI-Werkzeug als Autor aus. Die erwartete Offenlegung substanzieller KI-Erzeugung ist ausdrücklich noch eine offene Frage. Das belegt laufende Policy-Arbeit, nicht bereits geltendes Ergebnis.

Ein Revisionsbeleg beantwortet die fehlenden Fragen

Sitzungen müssen nicht zu mündlichen Prüfungen werden. Stattdessen sollte jeder Nachweis eine begrenzte Aussage tragen. Das Gespräch prüft Verständnis. Die Änderungshistorie ordnet Textbeiträge zu. Ausdrückliche Zustimmung bestätigt Name und Rolle. Rechteunterlagen bewahren Contribution-Erklärungen. Issues, Protokolle und Beschlüsse zeigen die Annahme des Textes durch Gruppe oder Stream.

Ein knapper Beleg für jede wesentliche Revision könnte verantwortliche Autoren und Editoren samt Zustimmung nennen; wichtige menschliche Beiträge und wiederverwendeten Text ausweisen; den erklärten Softwareeinsatz auf Abschnitte oder Changesets beziehen; menschliche Prüfungen und offene Unsicherheiten festhalten; die Prozessentscheidung zur Annahme des Textes verlinken; und beim Eintritt in den Stream-Review sowie bei AUTH48 die Verantwortung erneut bestätigen.

Das wäre kein KI-Detektor. Der Stil würde nicht als Täuschungsbeweis dienen, und Rechtschreibprüfung würde nicht mit der Erzeugung eines technischen Kapitels gleichgesetzt. Erfasst würden Handlungen, die Menschen bestätigen können, während jeder RFC-Stream seine Zuständigkeit für Liste und Verfahren behält.

Auch legitime Werkzeuge würden dadurch fairer behandelt. Übersetzung, Grammatikprüfung und substanzielle Generierung können nach ihrem wirklichen Umfang beschrieben werden. Menschen können Ergebnisse prüfen und Verantwortung übernehmen, ohne das Werkzeug zum Autor zu erklären. Die Gemeinschaft diskutiert dann einen dokumentierten Prozess statt vermuteter Merkmale von Text oder Auftritt.

Quellen