Das Schild ist neu, das Nummernverzeichnis blieb stehen: die fehlende Seite im Datensatz zu ATOM Myanmar

Zusammenfassung

• Die am 31. Oktober 2026 gerenderte Verzeichnisansicht führt ATOM Myanmar als Unternehmen in Myanmar mit 2 Domainangaben, 1 Website-Angabe und „8 öffentlichen Belegen“; im selben Bild stehen 0 ASNs, 0 Präfixe, 0 ausgewertete RPKI-Zeilen und 0 IXP-Präsenzen.
• Diese Nullenfolge beweist keine fehlenden Ressourcen. Die Ansicht selbst markiert den Abschnitt network als fehlend, alle observed_at-, valid_from- und valid_to-Felder der Angaben sind leer, und der einzige Zeitstempel ist der der Darstellung: Das Datum beschreibt die Ansicht, nicht das Netz.
• Was fehlt, ist die Brücke: eine datierte Tabelle, die alten und aktuellen Rechtsträger mit ASN, Präfix, BGP-Origin, RPKI-Autorisierung und Betriebspostfach verbindet. Ohne sie entscheidet die Vermutung – und die Kosten der Vermutung trägt nicht, wer vermutet hat.

1. Die Ansicht vom 31. Oktober 2026

Gerendert wurde die Ansicht am 31. Oktober 2026, 12:03:27 UTC. Im BTW-Verzeichnis steht sie als Eintrag zu ATOM Myanmar Nur für den Strategischen Kreis. Die Anordnung ist ordentlich: Name ATOM Myanmar, Slug atom-myanmar, externe Kennung 395779, Entitätstyp COMPANY, Region MM, Rechtsträger eingetragen als ATOM Myanmar, Rechtsform eingetragen als unknown, Sitzland und Registergerichtsbarkeit beide „Myanmar (Burma)“, Ersterfassung am 17. Juni 2026, Gesamtkonfidenz 0,78.

Das Feld website auf oberster Ebene ist leer. Darunter hängt eine Website-Angabe mit dem Wert https://www.atom.com.mm/en. Domainangaben gibt es zwei: atom.com.mm und www.atom.com.mm. In der Aliasliste stehen „Myanmar“, atom.com.mm und www.atom.com.mm – der Ländername in derselben Zeile wie zwei Marken-Domains. Das ist ein Geruch von Entitätsauflösung, kein Beleg über das Unternehmen.

Die Zähler sagen: 10 Angaben, 9 Quellen, 3 Kontakteinträge, 2 Domainangaben, 1 Website-Angabe, 2 Dienstangaben, 2 Konfliktangaben, 16 Angabensätze in der Projektion, 9 Quellenbeobachtungen. Der Importvertrag spricht dagegen von 49 Angaben. Die beiden Dienstangaben heißen nur managed_network und peering_ixp, beide mit state unknown und Konfidenz null. Beide Konfliktangaben tragen denselben Wert: duplicate_domain. Unter den Lebenszyklus-Zuständen steht identity_conflict.

Der Netzwerkabschnitt ist leer, und zwar gründlich: 0 ASNs, 0 Präfixe, 0 ausgewertete RPKI-Zeilen (Abdeckung null), 0 IXP-Präsenzen, 0 Einrichtungen, 0 Peering-Beziehungen, 0 Upstream, 0 Downstream, 0 Peer-Zahl, 0 Personen, 0 Kontrollbeziehungen, 0 Rechtsangaben, 0 Ereignisangaben, 0 Mitgliedschaftsangaben. Die Netzwerkhistorie hat first_seen und last_seen gleich null, und Präfix-Zeitleiste, Allokationshistorie und Beziehungshistorie sind leere Listen.

Die Ansicht gibt das selbst zu. Sie benennt sechs Lücken: legal, control, people, network, event, evidence. Die Vollständigkeitsnoten lauten identity 1.0, geography 1.0, contact 1.0, service 1.0, und null in den übrigen sechs. Im Unternehmensdossier stehen Finanzen und Governance beide auf identity_unresolved.

Zuletzt das Datum. Der 31. Oktober 2026 markiert den Moment, in dem diese Ansicht gerendert wurde, nicht den Moment, in dem das Netz beobachtet wurde. Alle Beobachtungs-, Gültigkeits- und Enddaten der Angaben sind leer; der einzige gefüllte Zeitstempel ist der der Erzeugung. Das ist kein Detail: Ein Datensatz ohne Beobachtungsdatum taugt nicht zum Beweis, dass etwas „nicht existiert“.

2. Die „8 öffentlichen Belege“ einmal nachzählen

Die Zusammenfassung des Datensatzes behauptet, das Unternehmen habe „8 öffentliche Belege“. Zählt man nach, ändert die Aussage ihre Größe.

Das Evidenz-Array enthält tatsächlich 8 Einträge. Aber nur 5 tragen eine URL; 3 tragen überhaupt keinen Link. Und die 5 mit URL verweisen auf lediglich 3 verschiedene Adressen: den öffentlichen Mitgliederexport einer Börse in Bangkok (BKNIX-Mitgliederexport), die englische Seite des Betreibers und dessen nackte Domain. Der BKNIX-Export erscheint zweimal, die englische Seite ebenfalls. Also: 8 Belege, nach Deduplizierung 3 Quellen – und eine davon ist dieselbe Seite unter einem anderen Pfad.

Der Rest der Rechnung stimmt ebenso wenig. Ein Zähler sagt 10 Angaben, der Importvertrag sagt 49. Ein Zähler sagt 6 Kontakteinträge, die Projektion hat 3. Ein Zähler sagt 1 Datenlücke, die Ansicht benennt 6, und die Prosaliste kommt auf 7. Der Objektstatus lautet identity_conflict, während der Beobachtbarkeitszähler 0 Identitätskonflikte meldet. Der Dienstabschnitt erhält 1.0 und liest sich als „vollständig“, obwohl beide Dienstangaben auf unknown stehen und Konfidenz null tragen: vollständig ist die Tabelle, nicht der Sachverhalt. Das Feld website auf oberster Ebene ist null, und es gibt eine Website-Angabe mit Wert.

Nichts davon ist der Vorwurf der Böswilligkeit. Es ist etwas Schlichteres und Unangenehmeres: Wer diesen Datensatz liest, kann Null nicht von Leerstelle unterscheiden und „gibt es nicht“ nicht von „wurde nicht erhoben“. Der Datensatz hilft nicht.

3. Der einzige brauchbare Betriebshinweis zeigt auf eine Domain, die der Datensatz nicht kennt

Im ganzen Datensatz existiert genau ein Hinweis mit betrieblicher Bedeutung: ein Netzbetriebspostfach, maskiert als p•••@aml.mobi, Rolle noc, Konfidenz 0,78, Herkunft jener öffentliche BKNIX-Mitgliederexport.

Das Problem heißt aml.mobi. Die Domain steht nicht unter den zwei Domainangaben, sie ist nicht die Website-Angabe und sie fehlt in der Aliasliste. Der Datensatz sagt also einerseits, der Peering-Kontakt dieses Betreibers liege auf dieser Domain, und erkennt diese Domain andererseits nirgends in seiner eigenen Liste.

Die beiden übrigen Kontakteinträge sind schwächer. Eine Telefonnummer, maskiert als ••••1946, Konfidenz 0,6. Eine als Kontakt eingetragene URL, Konfidenz 0,6, Wert https://www.atom.com.mm/en. Beide stammen aus einem lokalen Dateipfad, nicht aus einem öffentlich prüfbaren Dokument. Zwei von drei Kontakten stehen auf diesem Fundament.

Wem gehört aml.mobi? Vielleicht einem verbundenen Unternehmen, vielleicht einem Dienstleister, vielleicht einem alten Kontakt, vielleicht einem Datenrest, den nach einem Export niemand aktualisiert hat. Alle vier Erklärungen tragen, und der Datensatz stützt keine davon. Der Wert dieses Hinweises liegt nicht in der Antwort, sondern in der Richtung: Wenn schon die Zuständigkeit für das Betriebspostfach unklar ist, kommt die Zuständigkeit für Nummern aus diesem Datensatz erst recht nicht heraus.

4. Über die „Umbenennung“ haben wir keinen Originaltext

Die Erzählung zur Herkunft der Marke stammt von einer „Über uns“-Seite des Betreibers, die eine Netzesuche gefunden hat. Die zurückgegebene Zusammenfassung lautet: ATOM Myanmar sei der Markenname, unter dem die früher als Telenor Myanmar bekannte Telekommunikationseinheit operiere; nach dem Rückzug der Telenor-Gruppe aus dem Markt in Myanmar seien die Geschäfte übernommen und umbenannt worden.

Die Beschaffenheit dieser Erzählung muss benannt werden. Wir halten die vom Suchdienst geschriebene Zusammenfassung, nicht den Seitentext: kein Titel, kein Herausgeber, kein Veröffentlichungsdatum, kein zitierfähiger Absatz. Diese Zusammenfassung nennt keinen Käufer, kein Abschlussdatum, keinen Preis und keine Beteiligungskette. Sie lässt sich als „eine Suchzusammenfassung behauptet dies“ zitieren. Sie lässt sich nicht als Wort des Betreibers zitieren, und erst recht nicht als geprüfte Tatsache behandeln.

Die zweite externe Erzählung stammt von der Suchseite eines BGP-Werkzeugs. Die Zusammenfassung behauptet, die Registrierung der Netzinfrastruktur von ATOM Myanmar – einschließlich ASN und IPv4/IPv6-Präfixen – werde von APNIC geführt. Das klingt nach einer Antwort und liefert nichts: keinen ASN, kein Präfix, keinen Halternamen. Es ist weder Beleg dafür, dass das Unternehmen Ressourcen hält, noch dafür, dass es keine hält.

Zusammengenommen stützen beide Erzählungen genau einen Satz: Die Marke hat den Namen gewechselt, und die Zuständigkeit für die Nummern wurde dazu nicht veröffentlicht. Alles Weitere braucht andere Belege.

5. Markenkontinuität ist keine Nummernkontinuität

Ein neues Kundenschild schreibt kein Halterfeld im Register um, keine ASN, kein Präfix, keinen Route-Origin, keine RPKI-Autorisierung und kein Betriebspostfach. Marke ist Sache des Marktes, Nummer ist Sache des Registers. Zwischen beiden gibt es keine automatische Leitung.

Deshalb sind „Markenkontinuität“ und „Nummernkontinuität“ zwei verschiedene Aussagen, die getrennt bewiesen werden müssen. Sie zu verbinden, dafür gibt es genau einen Weg: eine datierte Tabelle zu veröffentlichen, die alten und aktuellen Rechtsträger mit ASN, Präfix, BGP-Origin, RPKI-Autorisierung, Betriebskontakt und dem Nachweis verbindet, wer das Routing tatsächlich steuert.

Fehlt diese Tabelle, betreibt jeder Leser stromabwärts Zuschreibung per Vermutung: Der Peer entscheidet, wessen Routen er annimmt, der Käufer entscheidet, was er eigentlich erwirbt, der Regulierer entscheidet, wen er verantwortlich macht. Vermutung ist kein Vergehen. Der Fehler der Vermutung bleibt nur nicht bei dem, der vermutet hat.

Unser Datensatz dokumentiert die Marke und dokumentiert die Kontakte. Er dokumentiert nur die Tabelle nicht. Diese Lücke ist der Befund. Und sie ist billig zu schließen: eine datierte öffentliche Seite plus ehrliche Etiketten, die Null, unbekannt und nicht erhoben auseinanderhalten.

Eine Versuchung sollte man dabei vermeiden: zu schreiben, der Betreiber verstecke sein Netz. Die näherliegende Erklärung ist banaler – niemand hat diese Tabelle je verlangt, also hat sie niemand veröffentlicht.

6. Was in einer datierten Tabelle stehen müsste

Wenn ich das Blatt aufsetzte, hätte es sieben Zeilen. Jede Zeile bräuchte ein Datum und eine Quelle, die ein Fremder selbst öffnen kann.

1. Der alte Rechtsträger und der zugehörige Registereintrag des Halters.
2. Der aktuelle Rechtsträger und der zugehörige Registereintrag des Halters.
3. Die Autonomous System Number, eine oder mehrere, mit ausdrücklicher Zuordnung.
4. Die Präfixe mit Länge und der Angabe, ob Allokation oder Suballokation.
5. Der Origin-AS jedes Präfixes im BGP.
6. Der RPKI-Autorisierungsstatus dieses Origins.
7. Der Betriebskontakt und die Angabe, wer diese Person oder dieses Postfach verwaltet.

Sind die sieben Zeilen gefüllt, entfällt die Vermutung aus Abschnitt 5. Bleiben sie leer, ist jede Aussage, die Nummern folgten der Marke, weiterhin eine Vermutung – so eingängig sie auch klingt.

7. Wer diesen Datensatz liest, und was passiert, wenn er falsch liest

Der Peer liest ihn, um zu entscheiden, mit wem er eine Sitzung aufbaut und wessen Routen er annimmt. Ohne Origin-Angabe im Datensatz fragt er nach, oder er rät anhand der Marke, oder er schaltet gar nicht.

Käufer und Investor lesen ihn, um zu klären, was sie genau erwerben: Kundenstamm, Lizenz, Marke oder ein vollständiges Nummern-Identitätspaket. Der Wert dieser vier Dinge ist sehr verschieden, und zum vierten sagt der Datensatz nichts.

Der Regulierer liest ihn, um bei Route-Hijacking, Missbrauchsbeschwerde oder Zusammenschaltungsstreit den Verantwortlichen zu finden. Ein Zustand identity_conflict plus ein Betriebspostfach auf einer fremden Domain tragen diese Entscheidung nicht.

Der gewöhnliche Leser liest „0 ASNs“ und versteht – vernünftigerweise –, das Unternehmen habe keine ASN. Dieses Verständnis kann falsch sein, und nichts im Datensatz warnt davor. Darin liegt das eigentliche Versagen: Der Datensatz liefert keine falsche Antwort, er liefert eine Leerstelle mit dem Gesicht einer Antwort.

8. Was diesen Befund widerlegen würde

Ein datierter APNIC-Delegationseintrag, der ATOM Myanmar oder einen benannten Vorgänger als Halter von ASN und Präfixen nennt, widerlegt „die Brücke fehlt“ und schreibt es um in „die Brücke existiert, ist aber nicht unter der Marke indexiert“.

Ein datierter Registereintrag, der die Ressourcen weiterhin unter dem Rechtsträger aus Telenor-Zeiten zeigt, belegt eine Namensverzögerung, keine Nummernlücke.

Ein datierter Eintrag, der die Ressourcen bei einem unabhängigen Dritten zeigt, bedeutet: Die Marke hat Kundenstamm und Lizenz erworben, keine Nummernidentität.

Wer die widersprüchlichen Zähler zusammenführt und die Beobachtungsdaten füllt, stuft den Befund von „unlesbar“ auf „dünn, aber lesbar“ herab.

Der Nachweis, dass das Betriebspostfach einem benannten verbundenen Unternehmen, Dienstleister oder Nachfolger gehört, schließt die aml.mobi-Frage – ohne den Nummernbefund zu verändern.

9. Schlussfolgerung

Genau gesagt: In der am 31. Oktober 2026 gerenderten Ansicht ist die Abbildung zwischen der Kontinuität der Marke ATOM Myanmar und der Nummernidentität des Netzes noch nicht hergestellt. Das ist nicht die Schlussfolgerung, ATOM Myanmar halte keine Nummernressourcen, und auch nicht die, das Register kenne das Unternehmen nicht. Es ist die Schlussfolgerung, dass dieser Datensatz die beiden Enden nicht verbindet – und dass die strukturellen Mängel des Datensatzes den Leser daran hindern, die Verbindung selbst herzustellen.

Sechs Dinge gehören neben diese Schlussfolgerung. Erstens: Ob ATOM Myanmar ein eigenes autonomes Netz betreibt, Ressourcen unter altem oder verbundenem Namen nutzt oder Transit bei Dritten kauft, ist offen. Zweitens: Ob die Nullen die Wirklichkeit beschreiben oder eine gescheiterte Erhebung, ebenfalls. Drittens: Der 31. Oktober 2026 datiert die Ansicht, nicht das Netz. Viertens: Das Verhältnis zwischen der Domain des Betriebspostfachs und dem Betreiber ist unbekannt. Fünftens: Die Umbenennung selbst stützt sich auf eine Suchzusammenfassung, nicht auf erhaltenen Seitentext. Sechstens: Die Summen des Datensatzes stimmen untereinander nicht.

BTW hat bislang 18 Artikel mit Myanmar-Bezug veröffentlicht, zu Registereinträgen, Routing, Glasfaserökonomie und Rechenzentren. Keiner behandelt ATOM Myanmar als Subjekt von Nummernressourcen. Dieser Text besetzt diese Stelle – mit einem Datensatz, dessen Datum eindeutig ist und dessen Mängel es ebenso sind. Denn zuzugeben, dass der Datensatz nicht lesbar ist, hilft mehr, als zu tun, als wäre er es.