Zusammenfassung

  • RFC 1264 zerlegte Reife in reproduzierbare Spezifikation, Management, Sicherheitsarchitektur, unabhängige Implementierungen, vollständige Tests, Betriebserfahrung und Skalierungsgrenzen.
  • RFC 4794 hob 2006 die zusätzliche Pflicht für alle Routingdokumente aus Zeitgründen auf, ließ aber das Recht der IESG auf Erfahrungsnachweise und eigene Verfahren der Arbeitsgruppen bestehen.
  • Spätere Regeln trennten Status weiterhin von Ausführung: RFC 6410 verband Internet Standard mit unabhängiger Interoperabilität, breitem Einsatz und erfolgreichem Betrieb; RFC 7942 machte Implementierungsangaben nützlich, freiwillig und möglicherweise ungeprüft.

Im Prüfungsraum stand kein einzelner Stempel

RFC 1264 sah Routing als verteilten Echtzeitalgorithmus. Eine Implementierung konnte in einer Umgebung funktionieren und mit einem anderen Code oder jenseits einer unbekannten Größenordnung scheitern. Dokumentqualität allein fasste diese Risiken nicht zusammen.

Darum gab es eigene Fächer: Protokoll- und Nutzungsspezifikation, MIB für Fernverwaltung, Sicherheitsarchitektur, Herkunft des Codes, Testszenarien, Ergebnisse, Betriebsumgebung und Skalierungsanalyse. Eine verständliche Spezifikation zeigte mögliche Reproduzierbarkeit. Sie bewies weder Routenaustausch noch funktionierende Authentisierung.

Eine MIB definierte beobachtbaren Zustand, nicht dessen tatsächliche Überwachung. Ein Sicherheitsentwurf beschrieb Schutzabsicht, nicht die Ausführung zwischen zwei Produkten. Entwurf, Implementierung und Ergebnis blieben getrennt.

Unabhängigkeit war Herkunft

RFC 1264 verlangte im Allgemeinen mehrere interoperable Implementierungen, davon mindestens zwei unabhängig geschrieben. Zwei Produkte aus derselben Codebasis können denselben Irrtum teilen. Getrennte Ursprünge prüfen stärker, ob die Spezifikation ohne Privatwissen der Autoren koordiniert.

Die Implementierungsliste sollte daher die Codeherkunft nennen. Der Bericht brauchte Szenarien und Resultate. Für Draft Standard mussten alle Funktionen zwischen mindestens zwei Implementierungen laufen, einschließlich der Sicherheitsfunktionen und ihrer beabsichtigten Schutzwirkung.

Eine Produktzahl ersetzte keine Abdeckungsmatrix. Erfolgreiche Interoperabilität galt für bestimmte Versionen, Eingaben und Bedingungen; sie bewies nicht automatisch Mehranbieterbetrieb, jede Bedrohung oder einen Dienstnutzen.

Betriebserfahrung brauchte Koordinaten

Der Bericht sollte Topologie, Umgebung, Zeitpunkt, Dauer, beteiligte Implementierungen, Resultate und Schlussfolgerungen festhalten. Wesentliche Funktionen mussten ausgeübt werden. Ein EGP sollte den vollständigen Außenroutenbestand tragen; ein IGP Innen- und Außenrouten, sofern kein anderes Verfahren letztere übernahm.

Die Last stieg mit der Reifestufe. Proposed Standard verlangte eine Implementierung und Tests wichtiger Funktionen, aber keinen Betrieb. Draft Standard verlangte erhebliche Erfahrung mit mäßiger Routerzahl und Komplexität im operativen Internet. Standard verlangte viele Router, komplexe Topologie und Mehranbieterbetrieb.

Das waren Bedingungen, keine Feststellung, dass ein bestimmter Kandidat sie erfüllt hatte. Standardsentscheidung und Belegbericht mussten getrennt identifizierbar bleiben.

Der zweite Bericht fragte nach dem Bruch

Zusätzlich verlangte RFC 1264 eine Analyse von Algorithmen sowie Bandbreiten-, Speicher- und CPU-Bedarf. Das Wachstum in mindestens zehnmal größeren Umgebungen, Grenzen und ungeeignete Einsatzfelder sollten ausdrücklich benannt werden.

„Skalierbar“ wurde damit von einem Adjektiv zu einer Beziehung aus Annahmen, Ressourcen und Grenze. Der Vergleich mit bestehenden Protokollen machte Verbesserungen überprüfbar.

Ein Modell blieb dennoch keine Beobachtung. Prognostizierte, getestete und im Betrieb gefundene Grenzen konnten auseinanderliegen. Ihre Trennung verhinderte, dass eine Kurve als Einsatzquittung erschien.

2006 wechselte die Entscheidungsstelle

RFC 4794 erklärte RFC 1264 für Historic. Die Begründung war institutionell: Eine zusätzliche Regel für jede Routingspezifikation verzögerte Veröffentlichung, während das allgemeine Verfahren bereits Kontrollen bot. Routing wurde weder einfach noch Erfahrung wertlos.

Entfernt wurde die breite Pflicht. Routing Area Directors konnten unter RFC 2026 weiter Implementierungs- oder Betriebserfahrung verlangen. Arbeitsgruppen durften Verfahren nach RFC 1264 beibehalten. Management und Sicherheit blieben durch allgemeine Regeln erfasst.

Die Zuständigkeit wanderte von der Universalliste zum Urteil von IESG und Gruppen. Mehr Flexibilität erhöhte den Bedarf, festzuhalten, welches Risiko welche Evidenz verlangte und weshalb sie genügte.

Zwei Stufen bewahrten den materiellen Unterschied

RFC 2026 beschrieb Proposed Standard als noch unreife Stufe, die sich durch Erfahrung ändern konnte. Meist waren Implementierung und Betrieb nicht Voraussetzung, doch bei Kernprotokollen oder großem Betriebsrisiko durfte die IESG sie fordern.

RFC 6410 reduzierte später auf Proposed Standard und Internet Standard. Für die obere Stufe blieben mindestens zwei unabhängig interoperierende Implementierungen, breite Verbreitung und erfolgreiche Betriebserfahrung sowie Prüfungen zu Errata, ungenutzten Funktionen und Lizenzen.

Breite Verbreitung beschreibt trotzdem nicht den Zustand eines einzelnen Netzes. Ohne Version, Population, Zeitraum und Beobachtung beweist sie weder Aktivierung noch Ergebnis.

Der leichtere Eintrag erklärte seine Grenze

RFC 7942 führte einen freiwilligen Implementation-Status-Abschnitt für Internet-Drafts ein. Reife, Lizenz, Erfahrung, Kontakte und Interoperabilitätsberichte konnten frühes Feedback aus laufendem Code liefern.

Der Mustertext stellte klar: Angaben von Beitragenden waren keine IETF-Billigung, möglicherweise nicht unabhängig geprüft und kein vollständiger Katalog. Der Eintrag half einer Entscheidung, ersetzte aber keine Testartefakte, Betriebstelemetrie oder Einsatznachweise.

Quellen und Grenzen

Die Kriterien stammen aus RFC 1264, das allgemeine Verfahren aus RFC 2026, die Ausmusterung aus RFC 4794. Das Zweistufenmodell steht in RFC 6410, der freiwillige Status in RFC 7942.

Die Quellen belegen Regeln und Änderungsgründe. Sie belegen nicht, dass ein benanntes Protokoll alles erfüllte, eine Angabe verifiziert war, ein Betreiber einsetzte oder Nutzer ein Ergebnis erhielten. Historic löscht alte Evidenz nicht und macht alte Aussagen nicht automatisch falsch.