Zusammenfassung

  • draft-ietf-procon-2418bis-04 vom 17. August 2026 ergänzt, dass eine Arbeitsgruppe ein Internet-Draft wieder in einen nicht adoptierten Zustand versetzen kann, etwa bei nachlassendem Interesse. In -03 fehlt dieser Satz.
  • Der Text ist weiterhin ein WG Document mit IESG-Status I-D Exists. Er ist keine verabschiedete Best Current Practice und hat RFC 2418 nicht ersetzt.
  • Adoption wählt eine Arbeitsgrundlage und überträgt die Änderungskontrolle an die Gruppe; sie bestätigt weder jeden Inhalt noch garantiert sie einen RFC. Die Rücknahme betrifft daher zunächst die institutionelle Obhut, nicht die technische Richtigkeit.
  • Ein belastbarer Ausgang benötigt einen Entscheidungsbeleg: ursprüngliche Adoption, letzte WG-kontrollierte Fassung, Gründe und Konsensfeststellung, Zielstatus, Ende der Editorbefugnis, Nachfolger und externe Abhängigkeiten. Nicht adoptiert, geparkt, aufgegeben, abgelaufen und außer Betrieb sind verschiedene Aussagen.

Der Satz, der den Rückweg benennt

Abschnitt 8.2 von Fassung -04 beginnt mit der formellen Adoption eines Internet-Drafts als Grundlage für einen Arbeitsgegenstand. Direkt danach grenzt der Text die Wirkung ein: Die Inhalte besitzen dadurch noch keinen Konsens; Dokumenteditoren halten vielmehr die Ergebnisse der weiteren Beratungen fest. Der neue Schlusssatz erlaubt der Arbeitsgruppe, ein Internet-Draft wieder in den nicht adoptierten Zustand zu versetzen. Nachlassendes Interesse dient als Beispiel.

Die vorherige Fassung -03 trennte Adoption bereits von Zustimmung zu allen Bestandteilen. Sie enthielt jedoch keinen ausdrücklichen Ausgang. Das Änderungsprotokoll von -04 vermerkt eine weitere Bearbeitung des Adoptionstextes. Die Neuheit lässt sich somit an zwei aufeinanderfolgenden Primärdokumenten prüfen.

Der Satz liefert noch kein vollständiges Verfahren. Er setzt weder eine Beratungsfrist noch ein Quorum, einen Einspruchsweg oder ein messbares Mindestinteresse fest. Auch ordnet er den Ausdruck nicht abschließend jedem Datatracker-Status zu. Es wird kein realer Fall behauptet, in dem eine Gruppe die neue Formulierung bereits angewandt hätte. Der Vorschlag beseitigt zunächst nur eine begriffliche Schieflage: Wer kollektive Zuständigkeit beginnen kann, muss ihr Ende ebenso erkennbar machen können.

Das betrifft Außenstehende unmittelbar. Produktteams wählen Prototypen anhand von WG-Signalen, andere Entwürfe bauen Referenzen auf, Anbieter lesen einen draft-ietf-Namen als Hinweis auf institutionelle Richtung. Beim Ende der Obhut müssen sie unterscheiden können, ob nur die weitere WG-Arbeit endet, ob eine technische Position verworfen wurde oder ob reale Implementierungen verschwinden. Keine dieser Aussagen folgt automatisch aus einer anderen.

Noch ein Entwurf, keine neue Regel

Die PROCON-Dokumentliste führt draft-ietf-procon-2418bis-04 als neues WG Document vom 17. August 2026. Sein Datatracker-Eintrag nennt Best Current Practice als beabsichtigten Status. Bei einer späteren Annahme würde der Text RFC 2418 und RFC 3934 ablösen sowie mehrere weitere RFCs aktualisieren.

Am 27. August war der Stand jedoch I-D Exists. Es gab keinen Document Shepherd, keinen zuständigen Area Director und keinen Telechat-Termin. Ohne Aktualisierung oder Fortschritt sollte der Entwurf am 18. Februar 2027 ablaufen. Das benachbarte 2026bis-11 befand sich im Working Group Last Call; 2418bis nicht. Der Status einer Zeile ist kein Sammelstatus für das ganze Arbeitsprogramm.

Die PROCON-Charta beauftragt die Gruppe mit der Konsolidierung der verstreuten Prozessdokumente und erlaubt ausdrücklich nichtredaktionelle Änderungen an Richtlinien zur WG-Adoption. Das legitimiert die Beratung über den Gegenstand, nicht die aktuelle Formulierung.

Bis ein Nachfolger das vorgeschriebene Verfahren abgeschlossen hat, bleibt RFC 2418 Teil der veröffentlichten BCP 25. Ein Governance-Register sollte daher gleichzeitig die geltende Grundlage und den vorgeschlagenen Ersatz mit eigener Version und eigenem Status führen. -04 als belanglose Skizze zu behandeln unterschätzt den Vorgang; ihn als geltendes Recht zu führen erfindet eine Entscheidung.

Adoption überträgt Obhut, nicht Wahrheit

RFC 7221 beschreibt den üblichen Übergang. Die bisherigen Inhaber werden auf die Übertragung der Änderungskontrolle an die IETF hingewiesen. Chairs prüfen bekannte Schutzrechte, stellen rough consensus fest, bestimmen Editoren, veranlassen die WG-Fassung und erhalten die Verweise zwischen individuellem und ersetzendem Entwurf.

Entscheidend ist, ob das Dokument eine tragfähige Grundlage für weitere Arbeit bietet. RFC 7221 nennt die Adoption „initial, not final“ sowie „adoption, not approval“. Der Text muss noch keine vollständige Lösung enthalten, und seine Adoption garantiert keine Veröffentlichung als RFC. Danach besitzt die Arbeitsgruppe die Dokumentkontrolle und kann den Inhalt im Rahmen von Charta und IETF-Verfahren ändern. Ohne ausdrückliche Feststellung besteht keine Zustimmung zu jedem übernommenen Detail.

Die Übertragung ist also keineswegs symbolisch. Ursprüngliche Autoren dürfen persönliche Änderungen nicht als WG-Entscheidungen ausgeben. Editoren schreiben im Auftrag der festgestellten Gruppenergebnisse. Zugleich übernimmt die Gruppe Kosten und Verantwortung für Review, Versionierung und nachvollziehbare Entscheidungen. Adoption ist die Aufnahme eines Vorgangs in die gemeinsame Werkstatt, kein dauerhaftes Qualitätssiegel.

Der Rückweg wirkt auf dieselbe Beziehung. Endet die WG-Obhut, endet oder ändert sich ihr Versprechen, den Text kollektiv zu entwickeln. Frühere Gründe, technische Erkenntnisse, Urheberschaft und zulässige Fortsetzungen werden dadurch nicht ausgelöscht.

Das ältere Zustandsmodell hatte bereits Seitenausgänge

RFC 6174 zeichnet keine ausschließlich aufsteigende Leiter. Ein Adoptionsaufruf bedeutet, dass ein Entwurf geprüft, aber noch nicht ausgewählt wurde. Scheitert die Auswahl, fällt er in einen Zustand ohne stream-spezifische Zuordnung zurück; das Verlaufsprotokoll bewahrt dennoch den Aufruf. Adopted by a WG erfasst die Übergangszeit vor der ersten draft-ietf-Fassung, WG Document ein adoptiertes und aktiv entwickeltes Dokument.

Daneben stehen Parked WG Document und Dead WG Document. Parked kann einen fehlenden Editor, ein ausstehendes Dokument oder einen Review-Stau kennzeichnen; eine Anmerkung kann die Bedingung für die Wiederaufnahme nennen. Dead bedeutet aufgegeben, ist laut RFC aber nicht zwingend endgültig. Ein nicht abgelaufenes Dokument kann wiederbelebt oder mit den notwendigen Zustimmungen in eine andere Gruppe übertragen werden. Fehlende Pfeile im Diagramm schließen sachgerechte Übergänge nicht aus.

Die Bezeichnungen beantworten verschiedene Fragen. Parked bedeutet Pause bei fortbestehender Obhut. Dead bedeutet Aufgabe innerhalb der Gruppe bei erhaltener Historie. Expired ist ein Fristereignis im Repository. Non-adopted besagt, dass das Dokument nicht mehr Grundlage eines WG-Arbeitsgegenstands ist; wer danach Änderungen kontrolliert, muss zusätzlich vermerkt werden.

Wie der neue Ausdruck aus 2418bis-04 auf jeden bestehenden Datatracker-Status abzubilden wäre, lässt der Entwurf offen. Das ist eine echte Beobachtungsaufgabe für spätere Fassungen und Werkzeuge. Eine voreilige Gleichsetzung würde die gewonnene Präzision wieder verlieren.

RFC 7221 nennt zudem eine mögliche Fortsetzung: Eine Arbeitsgruppe muss ein adoptiertes Dokument nicht behalten. Lässt sie es fallen, darf es unter Beachtung der Urheberrechtsbedingungen als Individual oder Independent Submission weiterverfolgt werden. Das Ende der WG-Zuständigkeit kann somit ein Wechsel von Forum und Autorität sein, nicht das Ende der technischen Idee.

Nicht adoptiert ist kein technisches Urteil

Nachlassendes Interesse kann viele Ursachen haben. Die Fragestellung ist weniger dringlich, ein Editor fehlt, Review-Kapazität ist knapp, ein anderer Entwurf übernimmt die brauchbaren Teile, eine Abhängigkeit blockiert, Implementierer gehen einen anderen Weg oder erhebliche Einwände bleiben offen. Jede Ursache kann eine Portfoliokorrektur stützen; sie besagt nicht dasselbe über technische Qualität.

RFC 7282 erklärt, warum rough consensus keine bloße Stimmenzahl ist. Maßgeblich sind die Gründe, Einwände und ihre Behandlung. Für den Ausgang gilt derselbe Maßstab. Wenige Mailinglistenbeiträge beweisen nicht von selbst fehlendes Interesse. Eine Chair-Mitteilung bleibt unvollständig, wenn sie Frage, Zeitraum, Argumente und Konsensbewertung auslässt.

Auch der Betrieb folgt nicht direkt dem Dokumentstatus. Code nach einem aufgegebenen Entwurf kann in Produkten oder Experimenten fortbestehen. Ein aktives WG Document kann ohne jede Produktionseinführung sein. Der institutionelle Status beantwortet, wer den Text in wessen Namen verwaltet. Nutzung erfordert eigene Belege aus Implementierung, Messung, Produktpflege und Betreiberpraxis.

Heng Lus Modell von minimaler Ausgangsspezifikation, lokalisierter Zukunftsentscheidung und freiwilliger Adoption bietet dafür eine redaktionelle Grenze. Ein Koordinationsartefakt kann einen gemeinsamen Bezug schaffen, ohne universelle Umsetzung anzuordnen. Es ist keine Quelle für IETF-Verfahrensrecht. Es verhindert nur den falschen Schluss, Adoption sei ein Rollout-Befehl und ihre Rücknahme ein Abschaltsignal.

Was ein sauberer Ausgang erhalten muss

Zuerst kommt die Identitätskette. Individueller Entwurf, ersetzende draft-ietf-Fassung, relevante Revisionen und Hashes müssen zusammengeführt werden. Adoptionsaufruf und Konsensmitteilung markieren den ersten Kontrollwechsel. Ohne diese Belege kann eine spätere individuelle Fortsetzung als unverbundene Dublette oder eine fremde Fassung als offizielle WG-Fortsetzung erscheinen.

Danach folgt die Ausgangsentscheidung: Antragsteller, Beratungszeitraum, Gründe für Fortsetzung und Beendigung, offene Einwände und Bewertung der Chairs. Wird sinkendes Interesse angeführt, sollten konkrete Beobachtungen wie erfolglose Editorsuche, unbeantwortete Review-Aufrufe oder ein klarer Nachfolger den Begriff tragen.

Der Zielstatus muss genau bezeichnet werden: kein stream-spezifischer Status, Parked, Dead, ersetzt, übertragen, abgelaufen oder individuell fortgesetzt. Ebenso wichtig sind die letzte WG-kontrollierte Revision, das Ende der Editorbefugnis und der neue Träger der Änderungskontrolle.

Schließlich bleibt das technische Wissenskonto erhalten. Offene Designfragen, Sicherheitsanalysen, Implementierungsberichte und unbeantwortete Einwände können einem Nachfolger dienen. Die Entscheidung, keine künftige WG-Zeit mehr einzusetzen, ist keine Erlaubnis, vergangene Erkenntnisse zu vernichten.

Der Reversionsbeleg

Ein kompakter Beleg enthält Namen, Revisionen und Hashes der Adoptionskette; Aufruf und ursprüngliche Entscheidung; letzte WG-kontrollierte Fassung; Ausgangsvorschlag und Debatte; datierte Konsensfeststellung; genauen Zielstatus; Ende der WG-Editorbefugnis; Nachfolge-, Ersetzungs- und Transferverweise; erhaltene technische Fragen; bekannte Implementierungen und Abhängigkeiten; Folgen für Charta oder Meilensteine; sowie eine ausdrückliche Nichtaussage darüber, was der Übergang nicht entschieden hat.

Nur den Eingang zu speichern, lässt veraltete Autorität am inaktiven Text haften. Beim Ausgang den Eingang zu löschen, schreibt Geschichte um. Der vollständige Beleg macht die Obhut reversibel und die Herkunft dauerhaft.

Quellen