Zusammenfassung

  • Im heutigen IETF-Betrieb läuft ein Internet-Draft normalerweise 185 Tage nach Einstellung ins Repository ab, sofern kein formaler Bearbeitungsstatus dies verhindert. Das Label beschreibt den Lebenszyklus der aktiven Fassung, nicht eine Ablehnung durch ein Gremium.
  • Repository und Archive sind verschiedene Aufzeichnungen. Aktualisierung, Ersetzung, RFC-Veröffentlichung und Ablauf entfernen eine Fassung aus der aktiven Ansicht; die Versionen bleiben grundsätzlich im Archive erhalten.
  • Offizielle Historien trennen Uhr und Entscheidung. draft-iab-protocol-maintenance-05 lief ab, wurde weiterbearbeitet und erschien als RFC 9413. draft-ietf-netvc-testing lief mehrfach ab; der maßgebliche Abschluss war ein gesonderter IESG-Status Dead mit Begründung.
  • Sorgfalt verlangt einen Zustandsbeleg: exakter Name und Revision, Daten, Archiv- und Ersetzungskette, Gruppen- und Streamstatus, Adoption und Last Call, ausdrückliche Disposition, Implementierungsabhängigkeit und Verantwortlicher.

Wie eine Frist zum Urteil wurde

Ein Unternehmen bewertet eine Protokollerweiterung. Der Analyst sieht im Datatracker Expired und notiert „IETF hat abgelehnt“. Produktmanagement streicht die Funktion, der Sicherheitsbericht übernimmt den Satz. Monate später erscheint eine neue Revision; nun heißt es „IETF hat die Arbeit wieder genehmigt“.

Beobachtet wurden zwei Tatsachen: Ablauf und spätere Revision. Erfunden wurden zwei Entscheidungen. Zuerst wurde ein automatisches Datum zur Ablehnung, dann eine neue Datei zur Zustimmung.

Ablehnung braucht ein Subjekt. Hat die Arbeitsgruppe die Adoption verweigert? Stellte der Chair fehlenden rough consensus fest? Lehnte ein Area Director Sponsoring ab? Setzte die IESG einen Publikationsantrag auf Dead? Aktualisierten die Autoren nur nicht rechtzeitig? Ersetzte ein anderer Draft den Namen? Oder überschritt der Text die Frist, während die Arbeit weiterging?

Expired beantwortet das nicht. Es belegt ein Lebenszyklusereignis. Eine Governance-Aussage benötigt ein anderes Ereignis mit Akteur, Zuständigkeit, Revision, Datum und Gründen.

Repository, Archive und 185 Tage

Die aktuellen IETF Author Resources unterscheiden Repository und Archive. Im Repository liegen aktive Versionen. Eine Fassung wird durch Aktualisierung, Ersetzung, RFC-Veröffentlichung oder Ablauf inaktiv. Das Archive bewahrt die Fassungen und weiteren Darstellungen, abgesehen von Ausnahmefällen.

Die Frist beträgt normalerweise 185 Tage. Formale Zustände können den Ablauf verhindern, etwa IESG-Bearbeitung für den IETF Stream oder Prüfung durch den Independent Series Editor. Selbst die Uhr steht also in Beziehung zum Verfahrensdatensatz.

Archivierung macht einen Draft nicht zur archivischen Publikation. Er bleibt work in progress. Bewahrung beweist, welcher Text existierte; sie beweist keine IETF-Genehmigung.

RFC 2026 Abschnitt 2.2 zeigt die historische Entwicklung. 1996 diente das Verzeichnis der informellen Prüfung wandelbarer Texte. Nach mehr als sechs Monaten ohne Änderung oder IESG-Empfehlung zur Publikation wurde ein Draft entfernt; eine neue Version startete die Frist neu. Internet-Drafts hatten keinen formalen Status.

Heute nennt die Praxis 185 Tage und erhält Fassungen im Archive. Die institutionelle Grenze bleibt: Ein Draft ist kein RFC, sein Ablauf keine zurechenbare Entscheidung.

Vier Ebenen statt eines Ampellichts

Erstens gibt es die Dokumentidentität. draft-example-foo-04 ist eine konkrete Fassung mit Datum und Bytes. Revision 05 kann Sicherheitsbedingungen oder Geltungsbereich ändern. Ohne Suffix ist unklar, was geprüft wurde.

Zweitens gibt es den Repository-Lebenszyklus. Active, updated, replaced, published und expired erklären, warum eine Fassung aktiv ist oder nicht. Sie messen weder Qualität noch Konsens.

Drittens gibt es den Verfahrensstatus. Individual Draft, Adoptionskandidat, adoptiertes WG-Dokument, Working Group Last Call und IESG-Evaluation sind unterschiedliche Positionen. RFC 2418 Abschnitt 7.2 behandelt Drafts als Arbeitsdokumente; 7.4 beschreibt den Last Call; 7.5 trennt rough consensus und Vorlage an die IESG.

Viertens folgt die Disposition. Ein zuständiger Akteur dokumentiert Adoption, Ersetzung, Rückzug, Ablehnung, Genehmigung, Veröffentlichung oder Abschluss, gegebenenfalls mit Gründen. Eine negative Schlussfolgerung gehört hierher, nicht in die Uhrschicht.

Die Ebenen bewegen sich unabhängig. Ein WG-Dokument kann während geplanter Überarbeitung ablaufen. Ein aktiver Individual Draft kann ohne Sponsor sein. Implementierter Text kann im Publikationsprozess scheitern. Einer abgelaufenen Revision kann eine neue folgen. Ein Badge kann diese Kombinationen nicht tragen.

Ablauf vor RFC 9413

Die Historie von Maintaining Robust Protocols widerlegt die Gleichsetzung. Revision 05 erschien am 12. Juli 2021 und lief am 13. Januar 2022 ab. Revision 06 folgte am 10. Mai; weitere Versionen bis 12 schlossen sich an. Die IAB führte Community Review und IAB Review durch, vermerkte Konsens und Genehmigung und gab den Text im Februar 2023 an den RFC Editor.

Im Juni 2023 erschien RFC 9413. Der frühere Ablauf bleibt wahr. Ihn als Ablehnung durch IAB oder IETF zu beschreiben wäre dennoch falsch. Die Uhr verhinderte und entschied den späteren Weg nicht.

Das Beispiel verspricht keine Rückkehr jedes Drafts. Es beweist nur: Ablauf und Ablehnung sind nicht identisch. Ein Register, das „abgelehnt“ später mit „genehmigt“ überschreibt, verliert die eigentliche Ereigniskette.

Der wirkliche Abschluss hatte einen Grund

Die Historie von Video Codec Testing and Quality Measurement zeigt die andere Seite. Revision 05 lief im September 2017 ab, 06 kam im Folgemonat. 06 lief im Mai 2018 ab; 07 erschien im Juli und ging in den WG Last Call. Im Januar 2019 lief 07 ab, obwohl der WG-Status Konsens und ausstehendes Write-up auswies. Revision 08 ging anschließend in Publikationsverfahren und IETF Last Call.

Die relevante negative Disposition kam am 25. März 2020. Der IESG-Status wechselte zu Dead. Der Area Director erklärte, nach wiederholten Versuchen zur Bearbeitung von Evaluationskommentaren fehle der NETVC-Arbeitsgruppe der nötige Impuls. Ein weiterer automatischer Ablauf folgte erst im August.

Damit gibt es einen belegbaren Abschluss: Datum, Instanz und Grund. Der Grund betrifft fehlenden Fortschritt und offene Kommentare, nicht die technische Wertlosigkeit der Methoden. Das Shepherd Write-up erwähnte sogar Nutzung durch AV1-Implementierer. Implementierung, Publikationsentscheidung und Ablauf waren getrennte Fakten.

Nur den letzten Ablauf „Ablehnung“ zu nennen, verdeckt die bessere Evidenz. Frühere Abläufe so zu nennen, widerspricht der dokumentierten Fortsetzung.

Neue Revision ist keine Genehmigung

Die Grenze gilt symmetrisch. Ablauf beweist keine Ablehnung; Revision beweist keine Annahme. Berechtigte Personen können Internet-Drafts einreichen. Eine neue Version kann Kommentare beantworten, Sichtbarkeit erneuern oder nur die Fortsetzung offenhalten.

Auch draft-ietf-... ersetzt die Historie nicht. Der Name spiegelt üblicherweise WG-Adoption, beweist aber weder aktuellen Konsens über jeden Satz noch IESG-Zustimmung. Last Call eröffnet Prüfung, ist nicht Publikation.

Running code schafft ebenfalls keinen institutionellen Status. Implementierung liefert wichtige Evidenz über Interoperabilität und Kosten. Heng Lus Running-Code Primacy begrenzt reine Papierautorität. Betriebserfahrung ist aber kein Konsensprotokoll. Beide Aufzeichnungen müssen getrennt bleiben.

Externe Nutzer tragen ihre Entscheidung. Ein Beschaffer kann vor RFC-Veröffentlichung bewusst eine Revision vertraglich wählen. Die Pflicht stammt dann aus dem Vertrag. Version, Änderungsregel, Tests und Ausstieg müssen genannt sein.

Der Vorschlag gegen Ablauf bleibt ein Draft

Removing Expiration Notices from Internet-Drafts argumentiert, automatische Fristen hätten durch dauerhafte Archive an Nutzen verloren. Abgelaufene Drafts würden weiter zitiert; manche Systeme änderten nur ihre Darstellung. Das belegt Debatte, nicht Konsens.

Die letzte Revision des Vorschlags ist selbst abgelaufen. Diese Ironie macht ihn weder lächerlich noch autoritativ. Er wurde nicht als IETF-Regel angenommen. Seine Existenz bedeutet nicht, die IETF habe den Ablauf abgeschafft.

Ein Draft kann gut argumentieren, ohne formalen Status zu besitzen. Ein Label kann korrekt sein, ohne den Inhalt zu beurteilen. Erst der nachweisbare Akt des zuständigen Akteurs verbindet beide.

Der Draft-Zustandsbeleg

Feld Nachweis
Exakter Name und Revision Konkret geprüfter Text
Inhaltsfingerabdruck Übereinstimmung der geprüften Bytes
Einstell- und Ablaufdatum Uhrereignis und Regelversion
Repository-Status Aktivität und Austrittsgrund
Archive-Adresse Erhaltener Text und Darstellungen
Revisionskette Frühere und spätere Fassungen
Ersetzungsbeziehungen Fortsetzung unter anderem Namen
Stream, Sponsor, WG Zuständigkeit für den nächsten Schritt
Adoption Übernahme als WG-Arbeit und Beleg
Konsens und Last Call Geprüfte Revision und offene Einwände
IESG- oder Stream-Disposition Entscheidung, Akteur, Datum und Gründe
Publikation RFC-Nummer, Stream und Kategorie
Implementierungsabhängigkeit Code, Tests und Betrieb
Externes Instrument Vertrag oder Policy mit gewählter Revision
Verantwortlicher Korrektur und nächster Prüftermin

Der Beleg verhindert Gegenfehler. Active, adopted oder Last Call als „IETF genehmigt“ bläht Autorität auf. Expired als „IETF abgelehnt“ erfindet negative Autorität. Das erste braucht einen positiven Akt, das zweite eine negative Disposition. Die Uhr liefert beides nicht.

Quellen

Schluss

Expired ist eine nützliche Warnung. Die aktive Fassung hat eine Aktualitätsgrenze überschritten; Abhängigkeit muss neu geprüft werden. Das Label erklärt weder Stillstand noch technische Bewertung oder institutionelle Entscheidung.

Die Regel lautet: Ablauf als Uhrbeleg, Disposition als Autoritätsbeleg speichern. Bei Abschluss sind Akteur, Verfahren, Version, Datum und Gründe zu nennen. Bei Wiederaufnahme wird die neue Revision ohne erfundene Genehmigung erfasst. Wer weiter implementiert oder beschafft, dokumentiert seine eigene Entscheidung. Ein Kalender kann Dokumente altern lassen; abstimmen kann er nicht.