Zusammenfassung

  • RFC 9997 reserviert zwei private Großbereiche. Berechtigte PEN-Inhaber können daraus ohne Einzelantrag einen Block von 100.000 SIDs ableiten; für kleinere PENs kommt ein Block von 10.000 hinzu. Der Mechanismus verteilt Zahlenraum, nicht Vertrauen.
  • Der RFC sagt ausdrücklich, dass ein im SID sichtbarer PEN kein Herkunftsindikator ist. RFC 9595 verlangt autoritative Quellen für .sid-Dateien, weil eine falsche Zuordnung von Ganzzahl zu Schemaelement die Semantik kompakter Daten verändert.
  • Daniel Kade schlägt einen datensparsamen Herkunftsbindungsbeleg vor, der Registerstand, Bereichsrechnung, autoritatives Repository, Modul- und SID-Datei-Digests, Zuordnungslebenszyklus, Integritätsprüfung, YANG-Library-Kontext und Annahmeentscheidung getrennt verbindet.

Ordnung im Zahlenraum ist noch keine Ordnung in der Lieferkette

Ein Gerätehersteller liefert ein YANG-Modul samt SID-Datei. Die Zahlen liegen sämtlich im Block, der sich aus dem PEN des genannten Unternehmens errechnet. Der Parser akzeptiert beide Dateien. Ein Testpaket lässt sich dekodieren und ergibt plausible Namen. Für ein automatisiertes Onboarding sieht das nach drei unabhängigen Bestätigungen aus.

Tatsächlich beruhen sie auf derselben unbewiesenen Voraussetzung. Die Formel ist öffentlich. Ein Dritter kann den Block ebenfalls berechnen, Zahlen daraus wählen, Namen kopieren und zwei zueinander passende Dateien erstellen. Ein erfolgreicher Test bestätigt interne Konsistenz. Er weist weder Repository-Kontrolle noch Veröffentlichungsrecht oder genehmigte Bytes nach.

RFC 9997 erschien im Juli 2026 als Proposed Standard des IETF-Standards-Track. Er nutzt Private Enterprise Numbers, um private Bereiche für YANG Schema Item iDentifiers herzuleiten. Interne, experimentelle und proprietäre Modelle erhalten damit kollisionsarmen Zahlenraum, ohne für jeden Block einen weiteren zentralen Antrag zu stellen.

YANG-SIDs sind global eindeutige vorzeichenlose 63-Bit-Ganzzahlen. Sie stehen für Module, Identitäten, Knoten und andere YANG-Schemaelemente. Im YANG-CBOR-Kontext von RFC 9254 ersetzen sie längere Namen und Pfade. Die Kompaktheit funktioniert nur, wenn Sender und Empfänger dieselbe Zuordnung zwischen Zahl und Bedeutung verwenden.

Eindeutigkeit verhindert eine Art Verwaltungsfehler: Zwei ordnungsgemäße Zuteiler geraten nicht versehentlich auf dieselbe Zahl. Sie verhindert keine Fälschung. Eine weltweit eindeutige Seriennummer kann auf dem falschen Bauteil stehen. Ebenso kann ein SID korrekt im delegierten Intervall liegen und durch eine nicht autorisierte Datei die falsche Bedeutung erhalten.

Zwei Großbereiche ersetzen Rückfragen durch Arithmetik

Das IANA-Register der YANG-SIDs führt zwei von RFC 9997 definierte Bereiche mit der Policy Private: 3.000.000.000 bis 3.999.999.999 sowie 300.000.000.000 bis 399.999.999.999. Private bezeichnet die Zuteilungspolitik, nicht die Vertraulichkeit der Zahlen.

Ein PEN unter 1.000.000 erhält rechnerisch einen Block mit 100.000 SIDs im größeren Bereich. Ein PEN unter 100.000 kann zusätzlich einen 10.000er-Block im kleineren Bereich ableiten. Der Startwert ergibt sich deterministisch aus der Unternehmensnummer. Nach der PEN-Registrierung braucht der Inhaber für diese Blöcke keine gesonderte IANA-Interaktion.

Die Arbeitsteilung ist sauber. Das zentrale Register verwaltet die Gesamtbereiche und Enterprise Numbers. Die Formel trennt die Teilbereiche. Der PEN-Inhaber verwaltet die privaten Zuweisungen darin. Wenden zwei Inhaber dieselbe Regel auf verschiedene Nummern an, landen sie in verschiedenen Blöcken.

Für Beispiele nutzt der Text PEN 32473. RFC 5612 reserviert ihn ausschließlich für Dokumentation. RFC 9997 reserviert konsequent auch dessen beide abgeleiteten SID-Bereiche für Dokumentationszwecke. So lässt sich die Rechnung reproduzieren, ohne einen realen Unternehmensraum als Muster zu vereinnahmen.

Der RFC beschreibt den Zugang als besonders niedrigschwellig und nach Erhalt des PEN als interaktionsfrei. Das ist gewollt. Gerade deshalb taugt der Vorgang nicht als hoch belastbare Identitätsprüfung. Ein Verfahren, das wiederholte Kontrolle vermeiden soll, kann nicht stillschweigend deren Beweiskraft übernehmen.

Bereichshoheit begleitet nicht jede Datei

RFC 9997 überträgt dem jeweiligen PEN-Inhaber die Verwaltung des abgeleiteten Blocks. Damit ist geklärt, wer nach Registerpolitik darin zuteilen darf. Nicht geklärt ist, ob eine konkrete Datei von einem Kanal stammt, den dieser Inhaber anerkennt.

Die Security Considerations ziehen diese Grenze ausdrücklich. Die Anwesenheit eines bestimmten PEN in einem SID ist kein Herkunftsindikator. Sie garantiert weder, dass der SID selbst noch dass das zugrunde liegende YANG-Modell vom PEN-Inhaber stammt. Der Standard verhindert damit eine naheliegende, aber falsche Identitätslesart der Zahl.

Mindestens vier Gegenstände müssen auseinanderbleiben. Das IANA-Register der Private Enterprise Numbers dokumentiert eine Nummernzuteilung. Das SID-Register dokumentiert Bereiche und Policies. Ein Repository verteilt Modul und Zuordnungsdatei. Ein laufender Server erklärt, welche Schemata er derzeit verwendet. Die Richtigkeit eines Gegenstands heilt keinen Fehler in einem anderen.

Eine PEN-Registrierung ist keine Markenprüfung, kein Software-Signaturzertifikat und kein Beleg über die heutige Kontrolle eines Hosting-Kontos. Ein Bereichseintrag ist keine Modulliste. Ein bekannter Namespace fixiert keine Bytes. Ein identisches Revisionsetikett kann neben unterschiedlichen SID-Zuordnungen stehen.

RFC 9595 macht die semantische Gefahr greifbar. Eine .sid-Datei verknüpft Begriffe mit Ganzzahlen. Wird eine unzuverlässige Tabelle importiert, kann das Managementsystem empfangene Werte einem anderen Zustand, Befehl oder Objekt zuschreiben. Entwickler sollen SID-Dateien deshalb nur aus autoritativen Quellen übernehmen; Managementsysteme brauchen dafür eine Quelle, die ebenso autoritativ ist wie jene für die YANG-Module.

Eine Grenzprüfung beantwortet: Könnte der PEN-Inhaber diese Zahl zuteilen? Eine Herkunftsprüfung beantwortet: Hat die berechtigte Instanz diese konkrete Zuordnung tatsächlich veröffentlicht? Für die erste genügen Register und Formel. Für die zweite braucht es Mandat, Artefaktidentität und Integrität.

Auffindbarkeit schafft noch keinen Vertrauensanker

RFC 9997 definiert keine weltweite Infrastruktur, die jeden PEN-abgeleiteten SID zu einem authentifizierten Modul auflöst. Wenn keine Geheimhaltung beabsichtigt ist, empfiehlt er ein öffentliches Repository mit YANG-Modellen und passenden SID-Dateien und/oder YANG Library in den Implementierungen.

Ein öffentliches Repository beantwortet zunächst nur, wo etwas liegt. Wer hat diesen Ort als offiziell bestätigt? Welches Release wurde genehmigt? Welcher Digest gehört zu den geprüften Bytes? Wie wird ein Kontrollwechsel oder eine Kompromittierung behandelt? Suchbarkeit und Namensähnlichkeit beantworten keine dieser Fragen.

RFC 8525 macht YANG Library zu einer starken Quelle für den Betriebszustand. Ein Server kann Module, Revisionen, Namespaces, Features, Abweichungen, Schemata und Datastores angeben. Seine serverbezogene content-id muss sich ändern, wenn sich die Bibliotheksinformation ändert. Identische Information muss aber weder über Server noch über Zeitpunkte hinweg denselben Wert erzeugen.

Die content-id ist somit ein lokales Änderungssignal, kein universeller Inhalts-Hash. YANG Library kann zeigen, welchen Schemakontext ein Server zu einem Beobachtungszeitpunkt erklärte. Sie authentifiziert nicht rückwirkend das Quell-Repository und beweist nicht den unveränderten Transport.

Belastbare Governance baut deshalb eine Kette. Der Registerstand begrenzt den Zahlenraum. Eine unabhängige Autoritätserklärung benennt den offiziellen Kanal. Digests identifizieren Modul und SID-Datei. Signatur oder Integritätsprüfung verbindet Release und akzeptierte Identität. YANG Library beschreibt die Ausführung. Der Betreiber dokumentiert Annahme, Ablehnung oder Ablösung.

Auch stabile Zuordnungen brauchen ein Gedächtnis

RFC 9595 unterscheidet instabile, stabile und obsolete SID-Zuordnungen. In der Entwicklung kann eine instabile Nummer wechseln. Eine stabile Zuteilung soll Kontinuität gewinnen. Wird sie obsolet, bleibt sie dokumentiert und darf nicht für eine andere Bedeutung wiederverwendet werden.

Diese Regel schützt alte Daten vor semantischer Umdeutung. Sie wirkt aber nur, wenn die Historie erhalten bleibt. Eine aktuelle Datei ohne frühere Zuordnungen kann ein altes Paket möglicherweise nicht erklären. Eine echte alte Datei kann umgekehrt für den heutigen Server unpassend sein.

Herkunft und zeitliche Eignung sind zwei Prüfungen. Ein Artefakt kann autoritativ veröffentlicht und inzwischen abgelöst worden sein. Ein angeblich aktuelles Artefakt kann ohne Herkunftsnachweis vorliegen. Die Annahme muss daher Digest, Lebenszyklusstatus, Zeitpunkt und Verwendungszweck binden.

Kompakte Kodierung verschärft das Problem. Ein ausgeschriebener Pfad kann einem Menschen einen inhaltlichen Widerspruch verraten. Eine Ganzzahl erklärt sich nicht selbst. Verwenden zwei Systeme dieselbe manipulierte Tabelle, können sie syntaktisch erfolgreich kommunizieren und trotzdem die falsche Semantik automatisieren.

Acht Belegebenen statt einer Kopie des Betriebs

Die Lösung ist kein zentrales Archiv für Gerätekonfigurationen, private Module oder dekodierten Verkehr. Solche Daten wären sensibel und für die Herkunftsfrage unnötig. Daniel Kade schlägt einen schlanken, manipulationssichtbaren Herkunftsbindungsbeleg mit acht getrennten Ebenen vor.

Erstens hält er den verwendeten IANA-Registerstand fest. Zweitens dokumentiert er PEN, Grenzwert und genaue Bereichsrechnung. Diese Ebenen begründen die numerische Einordnung, ohne Herkunft zu behaupten.

Drittens nennt er das akzeptierte Repository oder die Distributionswurzel samt Mandatsnachweis. Viertens bindet er Modulname, Namespace, Revision und kryptografischen Digest. Fünftens bindet er den Digest der .sid-Datei sowie Status und relevante Geschichte der Zuordnungen.

Sechstens protokolliert er Integritäts- oder Signaturprüfung, vertrauenswürdige Identität, Zeitpunkt und Ergebnis. Siebtens ergänzt er den beobachteten YANG-Library-Kontext mit Serverumfang, Modulen, Features, Abweichungen, Schema, Datastore und content-id, ohne diese als globalen Hash auszugeben. Achtens folgt das Ergebnis: angenommen, abgelehnt, ersetzt oder stillgelegt, mit Grund, Verantwortlichem und Geltungsbereich.

Die Ebenen behalten ihre jeweiligen Sprecher. IANA bürgt nicht für ein Repository. Ein Repository bezeugt nicht den aktiven Zustand jedes Servers. Eine Servererklärung authentifiziert keine historische Lieferkette. Ein erfolgreicher Decode erzeugt rückwirkend keine Publikationsberechtigung.

Dieser Beleg ist ein redaktioneller Vorschlag von Daniel Kade, kein Feld und keine Pflicht aus RFC 9997, RFC 9595 oder RFC 8525. Er speichert weder Konfigurationsdaten noch Zugangsdaten, private Modultexte, Gerätegeheimnisse oder fremde Aktivitäten. Er bewahrt nur die Verbindungen, die eine Vertrauensentscheidung nachvollziehbar machen.

Warum BTW Media existiert fordert, beobachtbare Realität nicht durch eine gefällige Erzählung zu ersetzen. Beobachtbar sind Bereich, Digest, Prüfergebnis, Serverdeklaration und Annahme. Die behauptete Urheberschaft braucht einen eigenen Beleg.

Quellen