Zusammenfassung

  • In RFC 2020 belegte ein Konfigurationsschreibvorgang nur die Absicht; zwischen Wunsch und tatsächlich angenommenem Modus lag das Training des Links.
  • Die Trennung wirkte unmittelbar: Das aktuelle Rahmenformat setzte die MTU auf 1.500 oder 4.464 Oktette, und nur dot12Status=opened machte ifOperStatus zu up.

Der Schreibvorgang schloss die Änderung nicht ab

dot12DesiredFramingType wählte für das nächste Training ein IEEE-802.3-kompatibles, ein IEEE-802.5-kompatibles oder eines von beiden Formaten. dot12CurrentFramingType beantwortete eine andere Frage: Welches Format läuft jetzt? Selbst ein offener Wunsch musste sich in einem tatsächlichen Format auflösen.

Daran hing ifMtu: 1.500 Oktette bei aktuellem 802.3-Format, 4.464 bei 802.5. Eine Änderung des Wunschwerts konnte die MTU nach dem nächsten Training verändern. Ein angenommenes SET belegte also weder den Wechsel noch die resultierende MTU.

Auch die Rahmenform identifizierte nicht das Zugriffsverfahren. IEEE 802.12 konnte Ethernet- oder Token-Ring-Formate verwenden, nutzte aber die eigene Demand Priority Access Method. Deshalb sollten die MAC-MIBs für Ethernet oder Token Ring nicht allein wegen der äußeren Ähnlichkeit eingesetzt werden. Nur Token-Ring-Framing zusammen mit tatsächlichem Source-Routing-Support eröffnete die engere RFC-1749-Ausnahme.

Training schuf den Nachweis

Trainingsrahmen dienten ausschließlich der Linkinitialisierung. Der Slave am unteren Ende begann, der Master am oberen Ende antwortete. RFC 2020 verlangte 24 aufeinanderfolgende fehlerfreie Trainingsrahmen, damit grenzwertige Links das Training nicht abschließen konnten.

dot12Status unterschied geschlossen, öffnend, geöffnet, Öffnungsfehler und Linkfehler. ifOperStatus war nur im geöffneten Zustand up. Öffnen, Zurücksetzen sowie Änderungen an Framingwunsch, Promiscuous-Wunsch oder Kontrollmodus konnten ein neues Training auslösen; der Auslöser war nicht das Ergebnis.

Beim Promiscuous-Modus trug dot12DesiredPromiscStatus den Wunsch in das nächste Trainingspaket, doch der Master musste ihn nicht gewähren. Ein Schreiben auf ifPromiscuousMode änderte den Wunsch und löste einen Versuch aus. Danach musste das Objekt den verwendeten, nicht den verlangten Modus anzeigen. dot12LastTrainingConfig bewahrte die Bits des letzten fehlerfreien Trainingsrahmens.

„Master“ blieb ebenfalls eine begrenzte Protokollrolle: der Teilnehmer, der sendewilligen Knoten Übertragungsrechte zuteilte. Das Wort belegte weder Eigentum noch institutionelle Autorität oder Datenzustellung.

Eine Formel war kein Leistungsnachweis

Normale Sendezähler fehlten, weil sie sich aus Gesamtsendungen minus hoher Priorität ableiten ließen. Empfangsfehler und unlesbare Oktette verlangten andere Beobachtungen. Die Formeln verbanden Messwerte, bewiesen aber keine Zustellung, Anwendungsfertigstellung oder Vertragserfüllung.

Die Sicherheitsgrenze war offen benannt: Sicherheitsfragen wurden nicht erörtert. Ein geöffneter Link oder eine angenommene Konfiguration bedeutete weder Authentisierung noch Vertraulichkeit oder sicheren Betrieb.

Zwei Dokumentlebensläufe

RFC Editor und IETF führen RFC 2020 weiterhin als Proposed Standard und nennen kein ablösendes RFC. Die Errata-Suche ergab am 11. September 2026 keinen Treffer; das beschreibt den damaligen Datenbankstand.

IEEE führt IEEE 802.12-1995 heute als Inactive-Withdrawn und datiert die Zurückziehung auf den 15. Januar 2001. Die Demand Priority Working Group steht unter den aufgelösten Gruppen. Diese spätere Dokumentgeschichte misst weder Verbreitung, Leistung noch Markterfolg. Sie zum Betriebsbeleg zu machen, wäre genau die Verwechslung, die RFC 2020 verhindert.

Quellen