Zusammenfassung

  • RFC 1550 lud alle Interessierten ein, Anforderungen an IPng zu benennen, nahm vorerst aber keine Bewertungen einzelner Protokollvorschläge an.
  • Prüfungen auf Klarheit und technische Machbarkeit machten Texte nutzbar, ohne aus Prüfung oder Veröffentlichung eine Zustimmung zu machen.
  • Einundzwanzig Whitepaper flossen später in technische Kriterien ein; Empfehlung, Implementierung und tatsächliche Einführung blieben eigene Entscheidungen.

Der Anwendungsfall kam vor dem Kandidaten

Scott Bradner und Allison Mankin veröffentlichten RFC 1550 im Dezember 1993. Der RFC-Editor-Eintrag und der IETF-Datensatz kennzeichnen das Dokument als Informational. Es setzte keinen Internetstandard. Es baute eine Eingangsseite für eine noch offene Wahl.

Alle Interessierten konnten Anforderungen nennen, die IPng erfüllen müsse, oder Faktoren beschreiben, die die Auswahl beeinflussen könnten. Die ersten Beispiele verließen bewusst die Protokollzeichnung. Ein Vertreter eines Versorgers könnte erklären, welche Skalierung und Adressierung vernetzte Stromzähler benötigen. Ein anderer Beitrag könnte untersuchen, was drahtlose Netze vom künftigen IP verlangen.

Damit wurden Folgen vor Lösungen gestellt. Die Entwickler eines Formats kennen dessen Mechanik. Betreiber, Unternehmen und Branchen kennen Migrationskosten, Betriebszwänge und Ausfallbilder, die ein Header nicht zeigt. Erreichen diese Erfahrungen den Prozess erst nach der Favoritenbildung, lassen sie sich leicht als Randfall behandeln.

Noch durfte kein Entwurf für sich werben

Die Ausschreibung nahm zu diesem Zeitpunkt keine Texte an, die bestimmte IPng-Vorschläge bewerteten. Erst wenn die Vorschlagsdokumente klar und vollständig waren, sollte diese Phase beginnen.

Die Verzögerung schützte die Problemdefinition. Ein benannter Kandidat zieht Anforderungen in sein eigenes Vokabular: Mobilität wird zum Verkaufsargument eines Mechanismus, ein Sicherheitsproblem zur später lösbaren Schwäche, schwierige Migration zum vorübergehenden Preis des erwarteten Gewinners. RFC 1550 ließ zunächst den Satz „Diese Umgebung hat dieses Problem“ zu, ohne den Zusatz „deshalb muss mein Protokoll gewinnen“ zu verlangen.

Aus heutiger Sicht ist IPv6 bekannt. Daraus folgt nicht, dass das Ergebnis bereits in den Fragen von 1993 lag. Die Ausschreibung hält gerade den Moment fest, in dem die Antwort noch keinen rückwirkenden Vorrang besaß.

Prüfen hieß nicht billigen

Zunächst prüften Mitglieder des IPng Directorate und eines externen Review Board die Verständlichkeit. Sie konnten unklare Stellen benennen und Änderungen anregen. Danach bewertete eine getrennte technische Prüfung die Machbarkeit im Kontext des jeweiligen Textes, ausdrücklich ohne Werturteil.

Ob geändert wurde, entschied der Autor. Nach der Prüfung sollte der Beitrag als Internet-Draft und später als Informational RFC erscheinen, sofern der Autor ihn nicht zurückzog. So wurde er Teil des historischen Archivs.

Verständlich, machbar, veröffentlicht und angenommen waren vier verschiedene Zustände. RFC 1667, RFC 1669, RFC 1675 und RFC 1678 wiederholten, dass ihre Veröffentlichung keine Annahme durch den IPng-Bereich bedeutete.

Auch eine Branchenbezeichnung erteilte kein Mandat. RFC 1674 sprach aus Sicht der Mobilfunkbranche, band aber weder die ganze Branche noch das CDPD-Konsortium oder seine Firmen. RFC 1686 zog für die Kabelbranche eine ähnliche Grenze. Ein institutioneller Standort machte Sachwissen zuordenbar, nicht allgemein verbindlich.

Ein knappes Format für ungleiche Belege

Die Zusammenfassung durfte höchstens eine halbe Seite umfassen, der gesamte Beitrag zehn Seiten. Die Referenzfassung musste ASCII verwenden und der RFC-Form folgen. Behauptungen sollten fokussiert sein und konkrete Datenquellen nennen. Wer mehrere getrennte Probleme ausführlich behandeln wollte, durfte mehrere Whitepaper einreichen.

Die Form machte eine Marktprognose, eine Bedrohung und eine Leistungsanforderung nicht gleichwertig. Sie machte sie vergleichbar lesbar: kurze Hauptaussage, verantwortlicher Autor, sichtbare Belege, klarer Arbeitsauftrag. Die Seitenbegrenzung erschwerte es ressourcenstarken Teilnehmern, Aufmerksamkeit allein durch Masse zu besetzen.

Sie heilte keine Abwesenheit. Wer die Ausschreibung nicht kannte, bis zum 1. Februar 1994 nicht antworten konnte oder seine Erfahrung nicht in dieses Format brachte, blieb außerhalb der Akte. Ordnung des Eingangs ist kein Beweis vollständiger Repräsentation.

Sechzehn Fragen ohne Rangfolge

RFC 1550 nannte sechzehn technische Felder und erklärte sie ausdrücklich für ungeordnet: Skalierung; Zeitbedarf für Auswahl, Entwicklung und Einführung; Übergang; Sicherheit; Konfiguration, Verwaltung und Betrieb; mobile Hosts; Flows und Ressourcenreservierung; Policy-Routing; topologische Flexibilität; Anwendungsumfeld und Markt; Datagrammdienst; Abrechnung; Unterstützung verschiedener Kommunikationsmedien; Robustheit und Fehlertoleranz; technologischer Sog; sowie konkrete Arbeitsaufträge.

Beim Betrieb fragte das Dokument, was IPng enthalten oder vermeiden müsse, um die tägliche Belastung der Netzbetreiber zu begrenzen. Bei Robustheit gestand es Nichtwissen ein: IPv4 könne trotz Fehlern funktionieren, die noch nicht verstanden waren. Eine neue Architektur durfte diese verborgene Widerstandskraft nicht versehentlich entfernen.

Das war keine Tabelle mit sechzehn gleichen Punktwerten. Autoren konnten auswählen und weitere einschlägige Themen nennen. Beiträge über Zeitplanung gingen an ALE, Übergangstexte an TACIT. Die Weiterleitung wies Belege einer Arbeitsfläche zu, ohne ihr Ergebnis vorwegzunehmen.

Einundzwanzig Antworten, kein einheitliches Publikum

Die spätere RFC 1752 verzeichnete 21 Whitepaper. Die Ausschreibung sollte ausdrücklich auch außerhalb der traditionellen IETF-Teilnehmerschaft wirken.

RFC 1667 brachte Echtzeit-, Multicast- und Reservierungsanforderungen verteilter militärischer Simulation ein. RFC 1669 behandelte Marktfähigkeit und widersprach damit der Annahme, technische Qualität erzwinge Einführung. RFC 1673 lieferte die Sicht der Stromwirtschaft, die RFC 1550 bereits als Beispiel genannt hatte.

RFC 1674 verlangte Raum für Mobilität und zeitweise verbundene Geräte. RFC 1675 setzte eine Sicherheitsuntergrenze: Der Nachfolger durfte die Lage nicht verschlechtern. RFC 1678 trennte Anforderungen großer Unternehmensnetze von konkreten Lösungen. RFC 1686 prüfte die Themen aus der Kabelnetzpraxis.

Beim Übergang wurde die lokale Entscheidung sichtbar. RFC 1671 erwartete einen mehrjährigen Prozess und einen gestuften Plan für jeden Standort; nur sehr kleine Standorte könnten an einen einzigen Umschalttag denken. Das SIPP-Whitepaper RFC 1710 erklärte, ein gutes Protokoll ohne praktikablen Weg für die installierte IPv4-Basis genüge nicht; das Internet sei für einen kontrollierten Rollout zu groß.

Die Zahl 21 besitzt keinen Nenner. Sie beweist weder Vollständigkeit noch gleichen Einfluss. Sie zeigt, dass unterschiedliche Lebenswelten als zuordenbare, bestreitbare und zitierbare Aussagen im Archiv lagen.

Von der Eingabe zum Kriterium

RFC 1752 führte die Whitepaper zusammen mit einem Requirements-BOF, dem IPng Directorate und der big-internet-Mailingliste als Grundlagen der Überarbeitung an, die zu RFC 1726 wurde. Dessen Informationsseite markiert eine eigene Dokumentstufe.

RFC 1726 vergab keine Gewichte. Das Dokument wollte Ziele statt bestimmter Mechanismen formulieren: Skalierbares Routing war die Anforderung; Route Aggregation nur ein möglicher Lösungsbaustein. Es räumte zudem ein, dass Kriterien ernsthafte Kandidaten erkennen, aber nicht jeden Tausch zwischen Leistung und Funktion automatisch entscheiden konnten.

Verantwortung blieb nötig. RFC 1719 gab der IESG die Aufgabe, eine IPng-Empfehlung zu entwickeln, verlangte ein früh veröffentlichtes offenes Verfahren und reichlich Gelegenheit zur Stellungnahme. Beiträge prüften die Entscheidung; das Wort „community“ ersetzte nicht den Entscheider.

Der Eintrag für RFC 1752 steht für den späteren Akt. Dort wurden CATNIP, SIPP und TUBA bewertet und überarbeitetes SIPP als IPng-Grundlage empfohlen. RFC 1550 traf diese Wahl nicht.

Gehört, gewählt, betrieben

Heng Lus Kritik an der Multi-Stakeholder-Fata-Morgana trennt Teilnahme als Beleg, Fachwissen, Warnung und Einspruch von der Macht, den Träger des Verlusts zu binden. RFC 1550 ist unter dieser Grenze stark: Es öffnete den Eingang, ohne die Eingeladenen zu Souveränen zu erklären.

Minimum Initial Specification, Localized Future Decision and Voluntary Adoption trennt Veröffentlichung von Betriebswirklichkeit. Running-Code Primacy verlangt Implementierung und Nutzung; die Lehre der Reality Layers hält Anfrage, Empfehlung, Einführung und Beobachtung auseinander.

Diese Begriffe sind jünger und beweisen keine persönliche Theorie der Autoren von 1993. Sie benennen eine dokumentarisch sichtbare Grenze.

Gehört zu werden ist nicht gewählt zu werden. Gewählt zu werden ist nicht betrieben zu werden. Der Stromzähler stimmte nicht für IPv6; die Funkverbindung erteilte kein Mandat. Beide zwangen das künftige Protokoll, fremde Folgen zu beantworten, bevor seine Befürworter die Fragen allein festlegen konnten.

Sources