Summary
- AS139620, registered to MYANMAR TELECOMMUNICATION NETWORK PUBLIC COMPANY L, announced 103.142.144.0/24, 103.142.145.0/24 and 2001:df1:4780::/48 on 26 October 2026 — 512 IPv4 addresses and one /48, with complete IPv4 and IPv6 peer visibility and seven observed neighbours.
- The holder's registered name declares a public company while the directory record files its legal type as private_company, and no incorporation document reviewed here settles which string is correct.
- For anyone deciding whether to peer with, buy from or simply trust this holder, the measured routing is real and small, and the corporate facts are asserted rather than documented.
The measurement is the easy part
Routing data is a good place to start an argument because nobody has to take your word for it. On 26 October 2026 the vantage points feeding RIPEstat attributed three prefixes to origin AS139620: 103.142.144.0/24, 103.142.145.0/24 and 2001:df1:4780::/48 (announced prefixes). Each carries a continuous timeline from 12 October 2026 to the 26th. The response also carries a caveat worth repeating verbatim in spirit: routes seen by fewer than ten full-feed RIS peers are excluded. A prefix missing from that list is not a prefix that never existed; it is a prefix almost nobody saw.
The same day's routing-status record gives the totals: two IPv4 prefixes, 512 addresses, one IPv6 /48, seven observed neighbours (routing status). Visibility is the number I would underline. 269 of 269 IPv4 peers and 257 of 257 IPv6 peers reported seeing the origin. This is not a route that flickers at the edge of the global table; every collector contributing to that measurement saw it.
512 addresses. Two /24s and a /48. For a national operator that is small enough to be a single customer edge, a single service block, or the transit-facing sliver of something much larger. Whatever MYANMAR TELECOMMUNICATION NETWORK PUBLIC COMPANY L is, this number is one edge of it. Nothing in the data says what else it runs.
The /23 that became two /24s
One historical detail deserves more attention than it usually gets. The routing-status record's first_seen field names 103.142.144.0/23, origin 139620, at 2019-09-04T16:00:00 (routing status). Its last_seen names 103.142.145.0/24 at 2026-10-26T08:00:00, and the current announced set contains both halves as separate /24s (announced prefixes).
The arithmetic does the rest. A /23 is 512 addresses. The two /24s are that exact block cut down the middle. Seven years ago the observation was one aggregate; today it is two more specifics, announcing the same 512 addresses.
I will not tell you why. Deaggregation can be traffic engineering, a filter that accepts only /24s, a downstream taking one half, or a spreadsheet. What the record supports is narrower and still worth having: the number has been visible without a gap since at least September 2019, and the granularity of what it announces changed while the total address count did not move at all.
Seven neighbours, two of them above
The neighbours record lists seven (neighbours). Two sit on the left: AS4651 with power 1109, 1,230 IPv4 peers and 499 IPv6 peers, and AS38082 with power 568, 1,007 IPv4 peers and no IPv6 peers at all. Five sit on the right: AS139595, AS139692, AS139719, AS151482 and AS154481, with IPv4 peer counts between 162 and 562 and IPv6 peers attached to only one of them.
"Left" and "right" are positional. RIPEstat derives them from where an AS appears in observed paths, and that is topology, not contract. A right-hand neighbour is a network for which AS139620 appeared upstream in paths the collectors saw. Calling those networks customers turns a path into a commercial relationship, which is exactly the kind of quiet leap this article is trying not to make. They could be customers. They could be siblings behind a shared upstream. They could be downstreams of a downstream.
The two left-hand neighbours matter for a different reason: they are bigger, on every measured dimension, and this is the shape you expect from a network buying transit rather than selling it. I do not know who holds AS4651 or AS38082 beyond their numbers. I did not establish that from retained source text in this run, and I am not going to supply a name I did not verify. The measurements are the claim. The names are not mine to add.
What the registry actually renders
The registry side is refreshingly plain. APNIC's WHOIS for the number returns aut-num AS139620, as-name MTNPCL-AS-AP, descr MYANMAR TELECOMMUNICATION NETWORK PUBLIC COMPANY LIMITED, country MM (APNIC WHOIS). The organisation handle on that holder is ORG-MTNP1-AP (APNIC query). RIPEstat's overview agrees and adds the block: 139578-140601, described "Assigned by APNIC", under the IANA 32-bit Autonomous System Numbers Registry, holder "MTNPCL-AS-AP - MYANMAR TELECOMMUNICATION NETWORK PUBLIC COMPANY LIMITED", announced true for the 08:00 window on 26 October (AS overview).
Now note what is absent. No allocation date. No registration date. No object status beyond the block's "Assigned by APNIC". No remarks. If you want to know when this company received the number, the documents I could read do not say.
That absence grew teeth, because two documents I wanted did not answer at all. APNIC's own RDAP autnum object for 139620 returned no readable record in this run (APNIC RDAP), and the rdap.org copy — a different service, and one of the two documents the directory record names as its evidence — did not resolve either (rdap.org). Both are cited here as documents that were attempted and did not answer. A failed URL is not evidence. It is a hole with an address.
Two documents, one score
This is where the article began.
The directory entry for this holder displays a confidence_score of 0.95. Its evidence_basis array holds two entries, each at confidence 0.82: the rdap.org autnum document and the RIPEstat AS overview. The record was last updated on 17 June 2026 and is filed as queued_for_profile_article (directory entry Only for Strategic Circle).
A reader sees 0.95. The inputs are 0.82, 0.82, and one of those two could not be opened. That is not a scandal. It is a scoring artefact, and scoring artefacts are everywhere. It is, however, a precise reminder of what a confidence number is: a claim about a claim. 0.95 describes the record's belief in its own contents. It does not mean that 95 percent of the paragraphs above have been independently confirmed, and no reader should carry it away as if it did.
The record's own data_gaps line is more candid than its headline number: verify the legal entity country, current services, visible assets, parent or subsidiary links, and responsible public leadership contacts. Five things to verify, listed inside a record that displays 0.95.
The name says public. The field says private.
Now the collision.
The record's legal_name is MYANMAR TELECOMMUNICATION NETWORK PUBLIC COMPANY L. Its single alias is TELECOMMUNICATION NETWORK PUBLIC COMPANY L — the same string with the country removed. Its legal_type is private_company.
A name that declares a public company, filed under a private-company legal type. Two explanations fit, and from here I cannot choose between them. Either the legal_type field is wrong, or the name is a trading style that does not mirror the registered form. Both happen. Neither is established by anything I retrieved.
What I can state is what did not arrive: no incorporation document, no company-register extract, no legal-form filing. The mismatch therefore stands as a mismatch between two strings in one record, not as a finding that either string is false. Anyone who needs the legal form has to go and buy the certificate.
A second, smaller seam runs alongside it. The record truncates the name to a trailing bare "L". The registry writes "LIMITED". One holder, two renderings, and nothing here says which matches the incorporation papers.
A third seam is the most telling. hq_country and registration_jurisdiction both read "Myanmar (Burma)", country code MM — while the same record's data_gaps still asks for the legal entity country to be verified. The object asserts a jurisdiction and, in the same breath, admits it has not confirmed one.
One ASN, classed virtual
The record lists exactly one resource: AS139620, resource_type asn, status observed, service ip_transit, country "Myanmar (Burma)". Its resource_class is virtual.
That word is a classification, not a fact about the company. In this record's grammar a virtual resource is a number attributed to an organisation without a corresponding registered address block in the same row: the ASN exists, the announcement exists, the space behind it is not attested here. It is a filing convention. It is also, quietly, the most useful thing in the record, because it tells you precisely what is being asserted — a routing identity, not an address-space holder.
Service coverage reads ip_transit and managed_network for MM with roles provider, and the array repeats the role twice. Two gated contact facets exist, both scoped to MM with the same two services, and neither carries a name beyond the organisation's own. Nothing to write to. Nobody to attribute.
Empty rooms
Four collections are empty: relationships, leadership_contacts, related_events, contextual_references. Three fields are null: external_id, source_system, first_seen_at.
Read together, that set says something specific. The record cannot tell you who owns the company, who runs it, what it did last year, who else it is connected to, or when it first appeared. It can tell you that a number exists, who the registry says holds it, and that the routing system has watched it announce without a gap since at least September 2019.
For an incumbent national telecom, that is a striking amount of silence. For a directory row that ingests registries and routing data and little else, it is exactly the silence you should expect. The distinction matters, because the two readings lead to different decisions.
What a reader deciding something actually needs
Suppose you are weighing whether to peer with this holder, buy transit from it, or sign something. Here is the honest split.
Verified, reproducible, same-day: the number exists; APNIC assigns it inside block 139578-140601; the holder string is as quoted; and on 26 October 2026 the origin announced 512 IPv4 addresses and one /48 with full peer visibility and seven observed neighbours.
Not verified here: the legal form, the incorporation jurisdiction as a documented fact, the allocation date, the ownership chain, the named responsible officers, the customer base behind those five right-hand neighbours, and any part of the company's physical network beyond this one AS.
The gap between those two lists is the article. A registry row is a pointer to a set of documents. It is not the documents. A routing announcement is a claim about reachability on one day. It is not a description of a business.
What would change the picture
I would rather be corrected than consistent, so here are the falsifiers. The strongest available fact would be the APNIC autnum allocation date, or an incorporation certificate, or the peering agreements behind those seven neighbour relationships. Any one of them moves a paragraph from unresolved to resolved.
The second strongest would be movement in the numbers: 512 addresses becoming 1,024, the two /24s collapsing back into the original /23, or the neighbour set losing a left-hand entry. Each is dated and checkable, which is more than can be said for the corporate facts.
The bounded consequence
MYANMAR TELECOMMUNICATION NETWORK PUBLIC COMPANY L holds one AS number announcing 512 IPv4 addresses and one IPv6 /48 from behind two larger networks, continuously visible since September 2019. Its directory record calls it public in the name and private in the field, gives it 0.95 built on two 0.82 inputs one of which could not be opened, and lists nothing at all about who owns or runs it.
This is not a story about a company being imaginary. The number is real, the addresses are real, and the peers are real. It is a story about how much a registry row can carry and where the carrying stops — and about a legal-form string that nobody in the chain is currently paid to reconcile.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance





