Summary

  • The BTW directory binds the exact company entity to AS135010 and AS149628.
  • APNIC's current RDAP records list both ASN entities as active and identify HONG KONG BRIDGE INFO-TECH LIMITED as registrant. “Active” describes the registry entity, not whether a route or customer service is live.
  • RIPEstat's Routing Status endpoint says it summarises BGP state as observed by RIPE Routing Information Service collectors. The data is a measured snapshot, not a complete map of a company's network.
  • At 8:00 UTC on 6 August 2026, the endpoint reported no announced IPv4 or IPv6 space and no RIS-peer visibility for AS135010. It reported one IPv4 prefix, 256 IPv4 addresses and visibility at 327 of 327 IPv4 full-table RIS peers for AS149628.
  • Those results do not prove that AS135010, the company or every company service was offline. They also do not prove that AS149628 was reachable from every user or resilient to failure.
  • Hong Kong's Office of the Communications Authority includes the company in its public List of Internet Service Providers, with a displayed date of 17 January 2020. That row does not disclose current customers, facilities, licence scope or performance.

Image note: The featured image is a synthetic editorial diagram explaining the difference between ASN registration and time-stamped public route observation. It is not a company topology or outage map and does not depict assets owned or operated by HONG KONG BRIDGE INFO-TECH LIMITED.

Two identifiers, two different questions

The public evidence begins with identity. BTW's directory has one published entity for HONG KONG BRIDGE INFO-TECH LIMITED and displays AS135010 and AS149628 as network resources associated with it. That binding prevents the analysis from drifting toward a similarly named company or a number held by somebody else.

APNIC's Registration Data Access Protocol, usually shortened to RDAP, provides the registry layer. The AS135010 record and the AS149628 record both use the name HKBIL-AS-AP, both list the administrative status as active, and both identify HONG KONG BRIDGE INFO-TECH LIMITED as the registrant.

That is useful and specific evidence. Autonomous system numbers must be unique enough for network operators to distinguish routing domains. A recorded holder and usable contacts help other operators investigate a route, report abuse or coordinate a change. The registry is therefore part of the internet's operational machinery, not mere paperwork.

The records do not say that both autonomous systems were announcing routes at the moment they were queried. They do not list customers, traffic volumes, physical routers, data-centre rooms, fibre paths or service-level results. An ASN can remain correctly registered during a period when collectors see no public route from it.

RIPEstat asks the second question. Its Routing Status documentation says the endpoint summarises the current Border Gateway Protocol routing state of a prefix or ASN as observed by RIPE Routing Information Service, or RIS, route collectors. It aligns observations to data points at 00:00, 08:00 and 16:00 UTC.

For the 08:00 UTC data point on 6 August, the AS135010 response showed zero announced IPv4 prefixes, zero announced IPv6 prefixes and no visibility among the 327 IPv4 or 322 IPv6 full-table RIS peers counted by the endpoint. It recorded 18 November 2025 at 00:00 UTC as the last time a route originated by AS135010 was seen.

At the same data point, the AS149628 response showed one announced IPv4 prefix covering 256 addresses. All 327 IPv4 full-table RIS peers in that snapshot saw the resource. The endpoint showed no announced IPv6 prefix and reported three observed BGP neighbours.

The important fact is not that one number is good and the other is bad. The important fact is that registry state and observed routing state are different fields produced by different systems.

What an ASN identifies

The internet is not operated as one network. It is a collection of networks run by telecommunications companies, cloud platforms, universities, governments, businesses and many other organisations. Each operator can set policies for how its network reaches other networks.

An autonomous system number, or ASN, is an identifier for one of those routing domains. Networks exchange reachability information using the Border Gateway Protocol, or BGP. A BGP announcement says, in effect, that a block of internet addresses can be reached through a particular autonomous system path. Other networks decide whether to accept that information and which route to prefer.

The ASN does not contain the network. It does not reveal the equipment carrying packets, the building where a router sits, the company supplying a circuit or the contract governing restoration after a failure. It does not show whether two apparent paths share one duct, power feed or control system.

This is why the word “autonomous” can mislead non-specialists. It describes a routing policy domain. It does not mean the operator is self-sufficient, politically sovereign or the owner of every component beneath the routing layer. An autonomous system can depend on leased transport, shared facilities, upstream providers, internet exchanges, electrical power and software operated by others.

AS135010 and AS149628 therefore identify two routing-domain records tied by APNIC to the same registrant. The current observations say that the two identifiers presented different public BGP states at the stated snapshot. They do not reveal why.

An active registry record is not an uptime signal

RDAP is designed to make registration data available in a structured form. It can tell a user which resource was queried, which organisation is recorded, which contacts and roles are attached, and which events the registry exposes. Its status field belongs to that administrative system.

Treating active as an uptime label would collapse several layers into one. The record may be active while no route is being originated. A route may be visible while a customer application is unavailable. A customer may reach one service while a different access product is affected. A registry query can succeed even when equipment elsewhere has failed.

The reverse mistake is equally risky. Zero route visibility at a set of collectors does not cancel the registry record. It does not prove that the holder has ceased trading. It does not show that private routes, internal systems or services using a different ASN are unavailable. In this case, the same registrant also has AS149628, which was broadly visible in the same RIS snapshot.

The correct verbs remain narrow. APNIC records the company as registrant. RDAP labels the entities active. RIS collectors observed or did not observe routes at the timestamp. Customers experience service through systems that require separate evidence.

Accurate wording is operationally useful. If a registry contact is stale, that is a registration-quality problem. If an expected public route disappears, that is a routing signal. If users cannot reach an application while routes remain visible, investigation may need to move toward access, internal transport, name resolution, filtering, congestion or the application itself.

What the AS135010 snapshot does and does not show

The zero counts for AS135010 are meaningful within the observation boundary. At 08:00 UTC, the Routing Status endpoint did not include any currently announced address space from that ASN and none of its counted full-table RIS peers saw the resource. The endpoint also supplied a historical last-seen point.

That supports a careful statement: AS135010 was not publicly visible in that RIPE RIS snapshot under the endpoint's observation method. It does not support a declaration that the company suffered an outage on 6 August. An ASN can be retained for future use, migration, policy separation or another reason that is not disclosed in these sources. A company can use more than one ASN. Some communications can occur outside the public BGP view represented by the endpoint.

Even the word “offline” would be too broad. Offline for whom, through which resource and at what layer? A registry entity can be online as a record. A public route can be absent. A web service can be delivered through another network. An internal system can remain available. The source set does not connect AS135010 to any named customer product, so it cannot establish a customer impact.

The historical last-seen value also needs restraint. It identifies the last route observation returned by the endpoint, not the date of a business decision or the cause of the change. It does not tell readers whether the route was withdrawn deliberately, moved to another ASN, replaced, filtered or affected by an incident.

For operational due diligence, the result should trigger questions, not a verdict. Was AS135010 expected to originate a public route at that time? Is it still assigned to a production service? Were route objects, route-origin authorisations or monitoring expectations updated? Only the operator and more specific evidence can answer those questions.

What the AS149628 snapshot does and does not show

AS149628 presents the opposite public signal. One IPv4 prefix was announced, the endpoint counted 256 IPv4 addresses, and all 327 IPv4 full-table RIS peers in the snapshot saw the resource. This is strong evidence of broad visibility within those collectors at that moment.

Broad visibility is valuable because a route that reaches many full-table observers is less likely to be confined to a small local view. It can help an operator confirm that routing information is propagating and help an investigator distinguish a route-origin problem from other failures.

It still is not a universal reachability test. RIS peers are observation points, not every access network or every user. A prefix can appear in BGP while packets are filtered, misdirected or dropped later. A service can fail because of a problem behind the routed address. Capacity can be limited public evidence even when a route is visible. The route can also depend on physical systems that share a failure risk the BGP table does not disclose.

The three observed neighbours are similarly bounded. RIPEstat documents observed neighbours as autonomous systems visible next to the queried ASN in collector data. The operator may have relationships that the collectors do not observe. The count does not describe contracts, traffic volumes, capacity or physical diversity.

No IPv6 prefix appeared for AS149628 in the snapshot. That supports a statement about the observed route data, not a claim that the company has no IPv6 anywhere. A service may use another network, private addressing, delegated resources or systems beyond the selected evidence.

The correct conclusion is that AS149628 supplied a current, broadly observed IPv4 routing signal. Service and resilience conclusions still require their own tests.

The public ISP list adds context, not an operating certificate

Hong Kong's Office of the Communications Authority list includes HONG KONG BRIDGE INFO-TECH LIMITED at row 1815 with the displayed date 17 January 2020. This connects the company name to an official public ISP directory beyond the number-resource registry.

The narrowness of that fact matters. A directory row does not show which services were offered, whether the same offer exists now, how many customers were served, which facilities were used or what licence terms applied. It does not certify the current routing state of either ASN and does not measure availability.

Regulatory and registry records are still important because they locate responsibility. If a customer, another operator or an authority needs to ask about a resource, accurate names and contacts reduce ambiguity. But an accountability system works best when administrative records lead to operational evidence rather than substitute for it.

Who is affected by the distinction

Other network operators need accurate registry data and current route observations for different parts of incident handling. RDAP can help identify the recorded holder and contact roles. BGP monitoring can show whether an expected announcement is present from several viewpoints. Neither tells a remote operator what happened inside a private network, but together they narrow the investigation.

Customers need service-specific evidence. A business buying connectivity should ask which ASN and prefixes support its product, but it should also ask what happens if that route, access circuit, facility or power source fails. A second ASN does not automatically provide backup. Two identifiers can still depend on one physical system, while one ASN can be supported by several independent paths.

Security and abuse teams depend on clear records because reports need a responsible destination. An accurate abuse contact is valuable even when routing state changes. Conversely, a route that remains visible does not prove that an abuse report will be answered or that the underlying customer assignment is current.

Researchers and journalists need the distinction to avoid dramatic but unsupported conclusions. A registry label should not be described as live traffic. A collector gap should not be presented as company closure. A visible route should not become a claim about customers or infrastructure ownership.

The company itself benefits from precise boundaries. The evidence should neither award unsupported credit for resilience nor assign unsupported blame for an outage. It should state what the public systems show and what they leave unknown.

Questions that turn records into useful checks

A responsible review begins with expectation. Was AS135010 expected to originate public routes at 08:00 UTC on 6 August? If not, zero visibility may be entirely consistent with the operator's plan. If it was expected, the result is a reason to compare internal monitoring, route policy and other external collectors.

For AS149628, which prefix and services were expected to be reachable? Did application and packet-level tests agree with the BGP observation? A visible route is a prerequisite for many public services, but it is not the final service test.

For both resources, are the registrant and operational contacts current? Can an external network reach the responsible team during an incident? Are changes to resource stewardship reviewed and recorded?

Customers can ask whether different services use different autonomous systems and whether those systems are physically independent. They can ask which risks remain shared: the same router, building, cable, power supply, upstream, control plane or support team. A useful continuity claim identifies the failure it is designed to survive.

Operators can also define evidence in advance. Which collectors should normally see the route? How quickly should an unexpected withdrawal raise an alert? Which internal signal distinguishes maintenance from a fault? Who verifies restoration, and does restoration mean that the route returned or that the customer service passed an end-to-end test?

None of these questions requires publication of a sensitive network blueprint. A dated assurance statement can describe expected route visibility, monitoring coverage, failure-independent paths and recent test results without exposing exploitable details.

What to watch next

The current comparison is a snapshot, so the first thing to watch is change. Future RIPEstat observations may show AS135010 visible again, AS149628 with a different announced-space count, or another state entirely. Any update should preserve the timestamp and collector boundary instead of replacing them with a timeless label.

The second item is registry maintenance. APNIC's records should continue to identify the correct holder and usable contacts. A change in registration would alter the identity evidence but would still need separate routing observation.

The third item is service evidence. If HONG KONG BRIDGE INFO-TECH LIMITED makes a public claim about availability, coverage, resilience or migration between the two ASNs, the claim should be assessed against route history, service tests and physical dependency information appropriate to that claim.

The fourth item is the official context. OFCA's list can change. Its current row should be rechecked before using it in a later decision, and any licence or compliance claim should come from the specific authoritative record rather than an inference from list membership.

Records and running systems belong in the same account

The internet needs reliable ledgers. Unique ASNs, accurate registrants and reachable contacts make routing coordination possible. The internet also needs running systems whose behaviour can be observed and tested. BGP collectors, service probes and operator telemetry reveal different parts of that behaviour.

HONG KONG BRIDGE INFO-TECH LIMITED's two ASN records make the distinction unusually clear. At one timestamp, APNIC recorded both entities as active while RIPE RIS observed no public route from AS135010 and broad IPv4 visibility from AS149628. The registry and the collectors were not disagreeing. They were answering different questions.

Accountability improves when those answers remain separate and connected. Start with the holder record. Check the expected route. Test the purchased service. Then ask what physical and organisational dependencies determine continuity. That sequence respects the registry without asking it to prove what only a running network can show.

Sources