Zusammenfassung

  • Die RFC Series ist ein gemeinsames, dauerhaftes Archiv mit vier Zuflüssen: IETF, IAB, IRTF und Independent Submission. Eine einheitliche Nummerierung macht aus vier Genehmigungswegen keine Behörde.
  • Stream und Kategorie beantworten verschiedene Fragen. Nur der IETF-Stream kann Standards-Track- und BCP-RFCs hervorbringen; er veröffentlicht aber auch Informational-, Experimental- und Historic-Dokumente.
  • Die IESG-Prüfung von IRTF- und Independent-Dokumenten sucht vor allem nach Konflikten mit IETF-Arbeiten. „Kein Konflikt“ ist weder technische Billigung noch Sicherheitszertifikat oder Eignungsnachweis für den Einsatz.
  • Wer eine RFC in Beschaffung, Audit, Architektur oder Politik verwendet, braucht einen Veröffentlichungsbeleg mit Stream, Kategorie, Genehmiger, Prüfumfang, aktuellem Status, Dokumentfolge, Geltungsbereich, Implementierungsnachweis und tatsächlichem Entscheider.

Das Gütesiegel, das nur ein Aktenzeichen war

Vier technische Anforderungen stehen in einer Prüfliste. Hinter jeder findet sich eine RFC-Nummer, darüber die Überschrift „IETF-Standard“. Das erste Dokument stammt tatsächlich aus dem Standards Track des IETF-Streams. Das zweite hält einen Konsens des IAB fest. Das dritte wurde im IRTF-Stream durch das IRSG zur Veröffentlichung freigegeben. Das vierte gelangte als Independent Submission in die Reihe.

Die vier Nummern sind korrekt, die gemeinsame Überschrift ist falsch. Sie verwandelt die Adresse eines Dokuments in die Behauptung, eine Institution habe viermal nach demselben Verfahren entschieden.

Ein Aktenzeichen sorgt dafür, dass alle Beteiligten dieselbe, unveränderliche Veröffentlichung meinen. Ein Gütesiegel müsste zusätzlich sagen, wer nach welchen Kriterien welchen Gegenstand für welchen Zweck geprüft hat. Diese Angaben stecken nicht magisch in der Ziffernfolge.

Der Irrtum wird durch eine Stärke der RFC Series begünstigt. Einheitliche Gestaltung, stabile URLs und eine bekannte Nummerierung schaffen Ordnung. Gerade diese Ordnung kann die unterschiedliche Herkunft verdecken, wenn der Leser den Umschlag mit dem Genehmigungsakt verwechselt.

Ein Archiv mit vier Eingängen

RFC 8729 beschreibt die RFC Series als Archiv für technische Spezifikationen des Internets. Dazu gehören Standardisierungsdokumente ebenso wie allgemeinere Beiträge aus Forschung und Technik. IETF-Dokumente bilden einen großen Teil, aber nicht die Gesamtheit.

Der IETF-Stream umfasst Arbeitsgruppendokumente und bestimmte, von einem IESG Area Director geförderte Einreichungen. Im IAB-Stream entscheidet das Internet Architecture Board nach seinem Verfahren. Der IRTF-Stream veröffentlicht Arbeiten von Research Groups nach Prüfung durch das IRSG. Der Independent-Submission-Stream nimmt Material auf, das außerhalb der anderen drei Wege liegt.

Der RFC Editor bearbeitet, publiziert, indexiert und bewahrt alle diese Texte in einer gemeinsamen Reihe. Gemeinsame Verwahrung ändert aber nicht die institutionelle Herkunft. Das IRSG wird durch die Vergabe einer Nummer nicht zum IESG; ein IAB-Dokument wird nicht nachträglich zum Ergebnis einer IETF-Arbeitsgruppe.

Die Mehrzahl der Eingänge ist ein Vorteil. Forschung, Standards, Architekturpositionen, herstellerspezifische Protokolle, Kritik und historische Zeugnisse können dauerhaft zugänglich sein, ohne denselben Anspruch erheben zu müssen.

Stream und Kategorie sind zwei Koordinaten

Auch die Feststellung „IETF-Stream“ reicht nicht für die Bezeichnung „Internetstandard“. RFC 7841 nennt Standards Track, Best Current Practice, Experimental, Informational und Historic als Kategorien.

Nur der IETF-Stream darf Standards-Track- oder BCP-RFCs genehmigen. Umgekehrt ist nicht jedes IETF-Dokument Standards Track oder BCP. Der Stream veröffentlicht auch informative, experimentelle und historische Texte. Selbst eine Genehmigung durch das IESG macht daher nicht jedes Dokument zu einem Kandidaten für einen Internet Standard.

Der Stream bezeichnet Ursprung und Veröffentlichungsverfahren. Die Kategorie bezeichnet Art oder anfänglichen Status des Dokuments. Ob eine Anforderung für ein bestimmtes System passt, verlangt weitere Angaben: Version, Optionen, aktueller Stand, Einsatzumgebung, Implementierung und Tests.

Status of This Memo ist kein überlesbarer Formulartext. Dieser Abschnitt nennt stream-spezifischen Status und Art der Prüfung. Wer ihn auslässt, zitiert ein Urteil ohne Gericht und Verfahrensstand.

„Genehmigt“ braucht ein Subjekt

Ein Dokument im IAB-Stream kann den Konsens des IAB wiedergeben und eine gewichtige Architekturposition dauerhaft festhalten. Das ist eine echte institutionelle Aussage. Ihr Subjekt bleibt jedoch das IAB. Die RFC-Nummer macht daraus weder IETF-Konsens noch ein politisches Mandat aller Internetnutzer.

Der IRTF-Stream zwingt zu einer feineren Beschreibung der Unterstützung. Nach RFC 5743 soll eine Research Group erklären, ob ein Text ihren Konsens darstellt, nur begrenzt getragen wird oder trotz Kontroverse als veröffentlichungswürdig gilt. Auch die Breite der Prüfung muss erkennbar sein.

Das IRSG wirkt ähnlich einem Redaktionsbeirat. Es prüft technische Klarheit, redaktionelle Qualität und ob die angemessene Begutachtung in der Gruppe stattgefunden hat. Zugleich muss deutlich bleiben, dass der Text kein IETF-Produkt und kein Standard ist.

Diese Kennzeichnung mindert den Forschungswert nicht. Sie verhindert, dass ein sauber benannter Forschungsbefund zu einer fremden Standardisierungsentscheidung hochgestuft wird.

Auch Independent Submissions sind keine ungeprüften Ablagen. RFC 4846 beschreibt einen Weg, dessen Tradition älter als die IETF ist. Er dient Ideen außerhalb der IETF-Agenda, Brücken zwischen Wissenschaft und Engineering, herstellerspezifischen Protokollen, Kritik an Standards, historischen Berichten und anderem Material. Im dort beschriebenen älteren Verfahren holt der RFC Editor Gutachten ein. RFC 8729 verweist auf das heutige Modell des Independent Submission Editor, der die Eignung für diesen Stream beurteilt; die gemeinsame Veröffentlichung durch den RFC Editor macht daraus keine IETF-Entscheidung.

„Independent“ bezeichnet die Unabhängigkeit des Entscheidungswegs, nicht die Abwesenheit fachlichen Urteils.

Aus Konfliktfreiheit wird Zustimmung

IRTF- und Independent-Dokumente werden dem IESG zur Prüfung vorgelegt. Im ersten Protokoll steht „vom IESG geprüft“. Die Managementfolie schreibt „vom IESG validiert“. Im Angebot heißt es schließlich „von der IETF genehmigt“.

RFC 5742 beschreibt eine andere Aufgabe. Das IESG prüft, ob die Veröffentlichung mit laufenden oder erwarteten Standardisierungsarbeiten der IETF kollidiert. Es kann einen Hinweis verlangen, der das Verhältnis erläutert.

Findet das IESG keinen Konflikt, bleibt die Beurteilung des technischen Werts einer Independent Submission beim Independent Submission Editor. Beim IRTF-Dokument verbleibt sie beim IRSG. Das IESG übernimmt nicht die Sachentscheidung dieser Streams.

„Kein Konflikt“ ist ein nützliches, enges Ergebnis. Es hält die Grenzen zur Standardisierungsarbeit klar. Es bedeutet nicht, dass die IETF das Design empfiehlt, eine vollständige Sicherheitsprüfung durchgeführt wurde oder ein Einsatz in einer bestimmten Umgebung gelingen wird.

Die Grenze ist ebenso wenig ein Qualitätsurteil nach unten. Ein Nicht-IETF-Dokument kann hervorragende Forschung oder entscheidende Betriebserfahrung enthalten. Provenienz ist keine Rangliste, sondern eine korrekte Zuordnung von Entscheidungen.

Was die Nummer tatsächlich gewährleistet

Eine RFC-Nummer hat einen starken eigenen Aussagewert. Sie identifiziert ein Dokument in einer redigierten, indexierten und dauerhaften Reihe. Autor, Datum, Stream und anfängliche Kategorie sind nachvollziehbar; der aktuelle Datensatz verweist auf Errata, Aktualisierungen, Nachfolger und spätere Statusänderungen.

Diese Stabilität schafft technisches Gedächtnis. Alte Implementierungsentscheidungen lassen sich gegen den damaligen Text prüfen. Forschung und Minderheitspositionen bleiben zitierbar, ohne Standards werden zu müssen. Eine veränderliche Webseite kann nicht unbemerkt an die Stelle des publizierten Wortlauts treten.

Weil der veröffentlichte Text feststeht, muss der heutige Zustand zusätzlich geprüft werden. Wird eine RFC später Historic, ändert sich der alte Wortlaut nicht. Wird sie aktualisiert oder ersetzt, steht das im aktuellen Datensatz. Eine belastbare Referenz nennt außerdem den einschlägigen Abschnitt und unterscheidet normative Forderung, Erklärung, Beispiel und bedingte Empfehlung.

Publikation ist auch kein Laufzeitnachweis. Eine Standards-Track-Anforderung kann in einer konkreten Flotte fehlen; eine Informational RFC kann eine weit verbreitete Praxis korrekt dokumentieren. Code, Konfiguration, Interoperabilitätstests und Beobachtung zeigen, was wirklich geschieht.

Die Lieferkette geliehener Autorität

Die nackte Nummer lässt sich leicht weiterreichen. Die Beschaffung setzt sie in eine Ausschreibung. Das Audit macht daraus eine binäre Kontrolle. Eine Behörde übernimmt die Kontrolle in einen Leitfaden. Der Anbieter wirbt mit „RFC-konform“, ohne Abschnitte, Optionen oder Testergebnisse zu nennen.

Mit jeder Übergabe wächst der Anschein von Autorität, während der Geltungsbereich schrumpft. Forschung wird Marktzugangsvoraussetzung. Ein Experiment wird etablierte Praxis. Konfliktprüfung wird Sicherheitszertifizierung. Eine Protokollbeschreibung wird zum Nachweis der Produktqualität.

Auch die Repräsentationsbehauptung wächst. Offene Teilnahme verbessert technische Arbeit, macht Teilnehmende aber nicht zu politischen Vertretern aller Betroffenen. Rough Consensus ist eine technische Disziplin zur Herstellung von Interoperabilität, keine weltweite Abstimmung über ein Mandat.

Beschaffer oder Regulierer dürfen eine RFC aus guten Gründen übernehmen. Sie müssen den Grund und ihre eigene Zuständigkeit offenlegen. Die Nummer darf keine Vollmacht vortäuschen, die niemand erteilt hat.

Ein Veröffentlichungsbeleg für jede Anforderung

Eine überprüfbare Referenz braucht keinen langen Ritus, sondern einen vollständigen Kurzbeleg.

Zuerst das Dokument festhalten: Nummer, Titel, Datum und genutzter Abschnitt. Dann Stream, Genehmigungsorgan und genaue Aussage zu Unterstützung oder Konsens. Kategorie und Prüfumfang aus Status of This Memo ergänzen. Bei IRTF und Independent Submission die IESG-Konfliktprüfung ausdrücklich von der Sachentscheidung im jeweiligen Stream trennen.

Danach die Aktualität prüfen: heutiger Status, Errata, Updates und Nachfolger. Den Anwendungsbereich eingrenzen: Version, Umgebung, Optionen und Ausnahmen. Implementierungsbelege anfügen: identifizierte Produkte und Konfigurationen, Interoperabilitätstests, Beobachtungen und bekannte Grenzen.

Schließlich die Übernahmeinstanz nennen. War es der Betreiber, ein Vertrag, eine interne Richtlinie oder eine Rechtsnorm? Wer aus einer technischen Veröffentlichung eine lokale Pflicht macht, muss als Entscheider sichtbar sein.

Vor der Nummer den Stream lesen

Die RFC Series ist eher eine technische Bibliothek mit vier Aufnahmeverfahren als ein einziges Parlament. Die gemeinsame Nummerierung bewahrt Wissen; die Streams bewahren Verantwortlichkeit.

Fünf Fragen stellen die Ordnung wieder her: Welcher Stream? Welche Kategorie? Wer genehmigte die Veröffentlichung und zu welchem Zweck? Was wurde tatsächlich geprüft? Wer entschied, dass der Text hier gilt?

Fehlen die Antworten, gibt sich das Aktenzeichen als Institution aus. Sind sie vorhanden, erfüllt die Nummer ihre richtige Aufgabe: eine genaue Adresse für Evidenz, keine gefälschte Vollmacht.

Sources