Zusammenfassung

  • draft-fedyk-netmod-yang-normal-form-00 will die ursprüngliche lexikalische Darstellung erhalten, aber für Gleichheit, Listenschlüssel und konfigurierbare Leaf-Lists eine deterministische Normalform ableiten.
  • Im MAC-Beispiel führen Doppelpunkt oder Bindestrich sowie Groß- oder Kleinschreibung zum selben zwölfstelligen Vergleichswert. Ein pattern prüft die zulässige Syntax; es erklärt zwei gültige Strings nicht für gleich.
  • Datatracker führt das Dokument als aktiven individuellen Internet-Draft ohne angestrebten RFC-Status und mit IESG-Status I-D Exists. Im Dokumentkopf steht dagegen Intended status: Standards Track. Eine NETMOD-Übernahme oder IETF-Billigung ist damit nicht belegt.

Die Schreibweise bleibt, der Maßstab ändert sich

Zwei Managementsysteme können dieselbe 48-Bit-Adresse unterschiedlich schreiben. Der gemeinsame IETF-YANG-Typ in RFC 6991 und seiner aktuellen Fassung RFC 9911 verwendet sechs durch Doppelpunkte getrennte Oktette und beschreibt Kleinschreibung als kanonisch. Der in IETF-Unterlagen gezeigte IEEE-Typ nutzt Bindestriche und beschreibt Großschreibung. Für Menschen ist es dieselbe Adresse; ein String-Schlüssel sieht weiterhin andere Zeichen.

Revision 00 trennt Darstellung und Vergleich. Der empfangene lexikalische Wert bleibt für Kodierung und Abruf erhalten. Eine optionale Erweiterung normalized-form benennt einen deterministischen Algorithmus für = und !=, die Eindeutigkeit von Listenschlüsseln und jene konfigurierbarer Leaf-Lists.

Bei mac-48 wird die Eingabe zunächst nach ihrem eigenen Typ validiert. Danach entfernt der Algorithmus Trennzeichen, wandelt Hexadezimalziffern in Großbuchstaben um und verwendet die verbleibenden zwölf Stellen. aa:bb:cc:dd:ee:ff, AA:BB:CC:DD:EE:FF, aa-bb-cc-dd-ee-ff und AA-BB-CC-DD-EE-FF ergeben AABBCCDDEEFF. Der Entwurf zeigt 0xAABBCCDDEEFF; die zwölfstellige Identität ist der Teil ohne Präfix.

Ein breiterer regulärer Ausdruck löst das Problem nicht. RFC 7950 definiert pattern als Einschränkung zulässiger Strings. Die kanonische Form des eingebauten String-Typs ist seine lexikalische Darstellung; Unicode-Normalisierung findet nicht statt. Zwei Schreibweisen zuzulassen erteilt daher keinen Gleichheitsbefehl.

Unterstützte und nicht unterstützte Erweiterung, zwei Ergebnisse

Die Erweiterung ist opt-in. Eine Implementierung, die Unterstützung erklärt, muss die Normalform verwenden. Eine andere verarbeitet weiterhin den lexikalischen Typ. Das entspricht YANG 1.1: Eine unbekannte Erweiterung darf vollständig ignoriert werden; eine unterstützte muss ihrer Spezifikation folgen.

Existiert aa:bb:cc:dd:ee:ff bereits und kommt AA-BB-CC-DD-EE-FF an einem Knoten hinzu, dessen Typ diese Schreibweise erlaubt, kann die unterstützende Engine den Eintrag als denselben normalisierten Schlüssel ablehnen. Die andere kann zwei Strings erkennen. Das betrifft XPath-Gleichheit, Keyed Lists und Konfigurations-Leaf-Lists.

Ein belastbarer Duplikatbeleg muss deshalb Modulrevision, Schemaknoten und Basistyp, Normalisierungsidentität, Produkt und Version, Supportnachweis und berechneten Wert enthalten. Zwei Ausgangsstrings plus Fehlermeldung erklären nicht, welche Regel entschieden hat.

Drei Statusangaben gehören zusammen

Die Datatracker-Seite nennt einen aktiven individuellen Internet-Draft, keinen RFC stream, keinen intended RFC status und I-D Exists. Sie weist ausdrücklich darauf hin, dass jeder ein I-D einreichen kann und dieses Dokument weder IETF-Endorsement noch formale Stellung besitzt. Der feste Textkopf nennt Intended status: Standards Track und den 2. Januar 2027 als Ablaufdatum.

Der Kopf hält die Absicht der Autoren fest; Datatracker beschreibt den tatsächlichen Verfahrensstand. Auch der organization-Eintrag „IETF NETMOD Working Group“ im eingebetteten Modul ist kein Nachweis einer WG-Adoption.

Autoren sind Don Fedyk von LabN Consulting und Scott Mansfield von Ericsson. Fedyks Profil verzeichnet 24 RFCs, Mansfields Profil fünf sowie IETF–ITU-T-Liaisonrollen. Erfahrung begründet Aufmerksamkeit, nicht institutionelle Zustimmung.

Die NETMOD-Folien vom IETF 124 zeigen die Vorgeschichte: eine einzige Schreibweise, breitere patterns, ein Äquivalenzmechanismus, andere Speicherung oder keine Änderung standen zur Wahl. Revision 00 entscheidet sich für eine getrennte Vergleichsidentität und bewahrt die Eingabeform.

Gleichheit ist kein Gerätenachweis

Dieselbe Normalform beweist, dass zwei zulässige Eingaben dieselbe deklarierte Transformation durchliefen. Ein XPath-Ergebnis belegt die Auswertung dieser Implementierung im jeweiligen Schemakontext. Eine Ablehnung belegt das Auslösen einer lokalen Konfigurationsregel.

Nicht belegt sind dasselbe physische Gerät, Kollisionsfreiheit anderer Algorithmen, identische Implementierungen, beidseitiger Support, gleiches Schema oder derselbe sichtbare XPath-Baum. Ebenso fehlen Aussagen zu Datastore-Migration, Absicht, Autorisierung, Forwarding-Deduplizierung oder Netzwirkung.

Das unterscheidet den Vorschlag von gewöhnlicher Kanonisierung. XDR erzeugt eine einzige externe Bytedarstellung. Hier bleiben mehrere lexikalische Formen erhalten; nur ausgewählte Vergleiche nutzen eine parallele Identität. Richtige Moduldatei oder Schema-Diff beweisen nicht, dass der Algorithmus lief.

Die Kontrollfrage lautet daher: Welcher Beleg zeigt, dass die Engine den deklarierten Wert statt der Typografie verglich?