Summary

  • The BTW directory, APNIC and PeeringDB each associate Bayan-related names with a distinct company or network record, but none of those records alone establishes present ownership, parentage or exclusive operational control.
  • RIPEstat observed 265 announced prefixes for AS6648 at its stated snapshot time, subject to a visibility threshold; that observation describes routing visibility rather than legal title, capacity, coverage, performance, uptime or a service commitment.

Start with the question each record answers

A familiar company name can appear across several kinds of infrastructure record. To a non-specialist reader, that repetition can look like a single chain of ownership and control. In practice, the records answer narrower questions. A company directory identifies the entity used by the publisher. A regional Internet registry records number-resource and contact data. An interconnection directory helps networks coordinate. A routing-observation service reports what participating collectors can see. None of these functions should be mistaken for all of the others.

The distinction is especially important for connectivity due diligence. A contracting team may need to identify a legal counterparty. A network team may need to recognize an autonomous system number, or ASN, which identifies a routing domain in interdomain routing. A continuity team may need current evidence about routes and service behavior. A photograph may provide visual context for a site. Each question calls for evidence that is suited to it.

At 2026-08-09T07:55:54+08:00, the BTW directory contained exactly one published company entry named Bayan Telecommunications Inc., with entity identifier cmqh4rbx500in1o6b544z9mhw. This establishes the directory identity used for the article. It does not establish an external corporate relationship, show that the company owns AS6648, or prove that it operates the ASN exclusively. The directory entry and the network records must therefore remain separate analytical objects.

That restraint does not make the directory unhelpful. It fixes the subject of the company research and prevents similarly named organizations from being blended together. It simply limits the conclusion to what the directory can support: one current BTW company identity, not a universal identity key for every corporate, registry, routing or physical object carrying a Bayan-related label.

What the APNIC autonomous-system record says

APNIC is the regional Internet registry serving the Asia-Pacific region. Its RDAP service presents structured registration data for Internet number resources. The current autnum record for AS6648 returns the exact name BAYAN-TELECOMMUNICATIONS, country code PH and the description Bayan Telecommunications, Inc. The record gives 2021-01-08T04:01:31Z as the time at which the autnum record was last changed.

Those fields are precise registry facts. The number 6648 is the ASN in the record; the name and description are labels stored with it. The last-changed timestamp describes the registry record rather than a corporate transaction or a network event. A registry entry of this kind does not demonstrate who is currently sending traffic, who has legal title to every related resource, whether a parent company changed, or whether one operator has exclusive control.

The same APNIC material adds another layer that must be handled carefully. It identifies the registrant entity ORG-SI1-AP as Sky Internet and records 2023-09-05T02:14:45Z as that entity's last-changed time. It also retains Bayan-labelled administrative and technical contacts. These are distinct roles within the registry data. They do not establish that Sky Internet is the current parent, owner or successor of Bayan Telecommunications Inc.; they do not establish legal control; and they do not turn an administrative or technical contact into proof of exclusive network operation.

The apparent tension between a Bayan description and a Sky Internet registrant role is precisely why role labels should be read literally. Registry data is a coordination ledger. Its value lies in uniqueness, accurate identifiers, recorded roles and useful contact metadata. A role can be operationally important without resolving the current corporate relationship among every named party. Any conclusion about parentage, merger, ownership or succession would require a separate current official company or regulatory record.

Registry identity is not running-code evidence

The practical dividing line is between a recorded identifier and observable operation. RDAP can show how AS6648 is described and which roles are attached to the record. It cannot by itself show which routers are announcing a prefix at a given moment, which path traffic follows, whether a network is available, or whether a service meets a contractual target.

This is the running-code principle in plain language: records help people coordinate around a network, while operational observations help show what the network is doing. Good analysis needs both, but it should not use one as a substitute for the other. A registry description is neither a deed of title nor a live measurement. A live route observation is neither a corporate register nor proof of exclusive control.