AS134773 exposes a broad route table, not a map of Guangzhou's delivery network

Summary

APNIC records AS134773 as ChinaNet-Guangdong-Guangzhou-MAN with active status, a Guangzhou MAN description, registry dates, administrative and technical contact details, and a published abuse role.
A dated RIPEstat routing-status view counts 36 IPv4 prefixes covering 145,664 addresses and nine IPv6 prefixes representing 86 /48 units; these are routing and address-space measurements, not customer, traffic or capacity figures.
All 328 sampled IPv4 peers and all 323 sampled IPv6 peers saw the origin in the captured view, but full sampled visibility is neither an uptime percentage nor proof of customer reachability.
RIPEstat observed five neighbours: AS4134 and AS4809 on the left side of captured paths, and AS146814, AS58828 and AS58834 on the right. Those labels do not establish commercial roles, physical interconnection, exclusivity or recovery design.
The public evidence supports a monitorable number-resource and route-origin identity. It does not prove citywide coverage, fibre or facility ownership, service quality, usable capacity, legal-company separateness, or the physical operating boundary behind Guangzhou delivery.

A large route table can create the illusion of a complete network

AS134773 looks substantial when approached through public routing data. The current announced-prefix response contains 45 entries across two address families. The routing-status summary counts 36 IPv4 prefixes and nine IPv6 prefixes, broad sampled visibility, and five observed neighbours. These are enough numbers to make a network appear mapped.

They do not make a map. A BGP table records reachability statements exchanged between autonomous systems. It tells an observer that an origin is announcing address space and that collectors can see paths involving other AS numbers. It does not reveal where a cable runs, which building contains an aggregation router, which power feed supports it, which customer uses a prefix, or which team is responsible when a local circuit fails.

That difference matters especially for an object whose name includes “Guangzhou MAN network.” A metropolitan-area label sounds like a physical footprint. It suggests a city, an operating area, and a layer of local delivery. The strongest public evidence available here is narrower: an APNIC registration and a current routing view associated with AS134773. The city label belongs to the recorded identity, not to a verified coverage polygon.

The article therefore begins with a restraint. The route table is not weak evidence. It is strong evidence about the things it was designed to show: origin identity, public announcements, sampled visibility, and observed path relationships. It becomes weak only when those facts are stretched into claims about service delivery. The useful question is not whether AS134773 is real. It is what remains unproved after its large public routing surface has been described accurately.

APNIC establishes the number-resource identity

APNIC's public RDAP response names the autonomous system ChinaNet-Guangdong-Guangzhou-MAN. It records country code CN, active status, and the description “CHINANET Guangdong province Guangzhou MAN network.” The BTW directory object uses the same descriptive identity and links it to AS134773. Together, those records provide a defensible technical binding between the existing directory entry and the autonomous-system resource.

The record also contains dates. Registration is recorded on 27 October 2015, and the captured data shows a last change on 15 June 2021. Those are registry events. They establish when a record was entered and last altered in the public registry view; they are not dates for construction, energisation, commissioning, commercial launch or continuous operation.

Administrative and technical roles point to Chinanet Hostmaster. An abuse role appears as IRT-CHINANET-CN. These details create public coordination surfaces. Another network can identify a contact associated with the resource rather than searching from a brand name alone. That is valuable for routing incidents, resource questions and abuse handling.

The contact fields do not answer who owns a particular router, which company signs a customer contract, or which operations team can dispatch a fibre repair crew in Guangzhou. A hostmaster role can span organisational levels. An abuse mailbox can route reports without exposing escalation authority or response performance. Contact publication improves discoverability; it does not certify the effectiveness of the response behind it.

Active status has the same bounded meaning. It supports the conclusion that AS134773 is a current recorded APNIC resource. It is not a telecommunications licence, an incorporation document, a service-level certificate, or proof that every route and product associated with the broader CHINANET name is operating normally.

The legal perimeter remains outside the ASN record

The directory name combines a national network brand, a province, a city and a MAN designation. That combination can be useful for technical identification while remaining ambiguous as a legal object. Autonomous-system descriptions often reflect operational administration or routing purpose rather than the exact name of a separately incorporated entity.

Nothing in the captured RDAP response resolves the corporate boundary among China Telecom, CHINANET, Guangdong provincial operations and the Guangzhou MAN label. The record does not identify an incorporation number, a local operating subsidiary, asset ownership, or the entity that bears customer-service obligations. It should not be used to assign every China Telecom asset in Guangzhou to the directory object.

This limitation changes the grammar of a responsible profile. APNIC records AS134773 under the Guangzhou MAN name. The directory contains an existing network-identity object with the corresponding label. Those are supported statements. It would be stronger than the evidence to say that the directory object is an independent company, owns a metropolitan network, or controls all physical infrastructure associated with the brand.

The uncertainty is not a reason to discard the object. Network operations frequently leave a clearer number-resource trail than a public corporate narrative. The ASN is still a meaningful accountability surface because it identifies the origin and the contacts attached to it. The missing legal perimeter should be named rather than silently filled.

Future evidence could close the gap: current corporate filings, telecommunications licences, operator disclosures, procurement records, or contracts that link specific assets and responsibilities to a legal entity. Until such evidence is available, the article remains a technical study of an exact directory identity and its public routing surface.

Thirty-six IPv4 prefixes show breadth, not service scale

The current routing-status summary counts 36 IPv4 prefixes and calculates 145,664 IPv4 addresses across the announced space. The announced-prefix response includes large aggregates, smaller blocks and more-specific routes. Representative entries include 124.29.0.0/18, 124.29.64.0/18, 119.34.128.0/17, 59.107.0.0/18, 59.107.64.0/18, 203.88.192.0/20 and 203.88.208.0/20.

This is a broad public IPv4 origin surface. It gives an external monitor many exact prefixes to watch for withdrawals, origin changes, unexpected more-specific announcements or changes in visibility. It does not disclose how the addresses are assigned. A routed block may support infrastructure, enterprise services, customer delegations, shared access, internal functions, or a mixture that the public BGP view cannot separate.

The figure of 145,664 addresses is routing arithmetic, not a census. It cannot be divided by an assumed address-per-customer ratio. Carrier-grade address sharing, dedicated addressing, reservation, sparse use and infrastructure assignments all break such a calculation. A large public address footprint can support many users or relatively few; the route table alone does not say.

Nor is the total a bandwidth measure. Address space does not reveal port speeds, optical channels, installed switching capacity, traffic volumes, oversubscription or usable headroom. An origin can announce a large range through a constrained link, while a small set of routes can carry very high traffic. Prefix count and packet capacity belong to different measurement systems.

The correct conclusion is still economically relevant. AS134773 exposes a non-trivial public IPv4 footprint whose continuity can be monitored. What it does not expose is the commercial or physical system that gives those addresses useful service.

Overlapping announcements make simple prefix counts misleading

Some visible routes sit inside larger visible routes. The response includes 210.76.64.0/19 as well as 210.76.64.0/20 and 210.76.80.0/20. It also contains neighbouring aggregates and smaller blocks across several address ranges. Counting every row is legitimate as a description of announcements, but it is not the same as counting unique address space or independent network segments.

More-specific announcements can serve many purposes. They may support routing policy, traffic engineering, operational separation, customer arrangements, migration or temporary control. The frozen source set does not provide configuration intent, so the article cannot safely assign a purpose to any one prefix length.

This is why the routing-status summary is useful alongside the raw list. The service calculates unique announced address space rather than asking readers to add every prefix naively. Even that calculation remains an address measure. It does not tell an observer how routes map to interfaces, sites or customers.

Overlaps also warn against turning a route table into a visual topology. Two prefixes may share the same routers and physical circuit. One aggregate and its more-specific may follow different external policies while converging on the same internal dependency. The table describes control-plane objects, not independent physical paths.

For monitoring, each row still matters. A more-specific can become visible while its covering aggregate remains stable, or an aggregate can disappear while selected more-specifics continue. Those patterns can narrow an investigation. They cannot, without operator or facility evidence, establish why the change occurred or which users were affected.

The breadth of AS134773 is therefore best described in two layers: 45 visible announcement rows across both families, and routing-status arithmetic covering 145,664 IPv4 addresses plus 86 IPv6 /48 units. Neither layer is a physical network inventory.

Nine IPv6 announcements provide a second control surface

The IPv6 side of the record is smaller in route count but still concrete. The announced-prefix response lists nine IPv6 routes, including 2402:f8c0::/42, 2402:f8c0:2::/48, 240e:6b0:3000::/44 and several additional /48 announcements under 240e:: space. The routing-status response represents the combined space as 86 /48 units.

That normalisation is useful for routing analysis. It is not a count of customer sites or deployed networks. IPv6 allocations are intentionally spacious, and a /48 is commonly an addressing unit rather than a statement about utilisation. Eighty-six possible /48 units can be lightly used, reserved, assigned internally or delivered in ways that public routing cannot distinguish.

The coexistence of IPv4 and IPv6 announcements does establish a dual-stack origin surface. An external observer can compare whether both families remain visible, whether one family changes origin, and whether their prefix structures evolve differently. These are meaningful control-plane signals.

They do not prove that a Guangzhou residential or enterprise customer receives both protocols. IPv6 can be present in backbone infrastructure, selected products, test environments or customer services. The source set contains no product documentation, endpoint measurements or customer configuration that resolves the question.

The two families may also share failure points. Separate route sets can still depend on the same router, facility, power supply or access network. Conversely, they may diverge through policies or sessions not visible in the source. A dual-stack table is not redundancy evidence.

AS134773's IPv6 routes should therefore be treated as a second inspectable ledger of running announcements. Their presence improves observability. It does not prove delivered dual-stack service, traffic share, customer adoption or physical independence.

Full sampled visibility is not 100 per cent availability

At the captured query time, RIPEstat reported 328 of 328 sampled IPv4 peers and 323 of 323 sampled IPv6 peers seeing AS134773. Within the RIS collector population represented by the response, the origin had full visibility in both address families.

That is a strong observation. It shows that AS134773 was not merely present in the registry; its routes propagated broadly through the sampled control plane. It also provides a baseline against which a later visibility decline can be compared.

The ratios are not uptime percentages. Availability requires a defined service, observation interval, endpoint, success condition and sampling method. A single control-plane snapshot cannot establish whether customer traffic reached its destination over an hour, a month or a year. “328 of 328” describes peers in one response, not a contractual service level.

Collector coverage is not identical to every network on the Internet. RIPE RIS provides a broad and valuable view, but some paths, policies and regions remain outside any one collector set. A route that is fully visible to the sample can still encounter filtering or reachability problems elsewhere.

More importantly, BGP visibility can survive a customer-impacting failure. An origin route may remain stable while an access circuit, aggregation switch, DNS resolver, authentication system or power feed fails. Packets can be discarded beyond the point that the public route table can see. The opposite can occur too: a control-plane change may not disrupt every local service.

The exact supported statement is narrow and useful: all sampled IPv4 and IPv6 RIS peers in the captured response saw the origin. The evidence does not support historical uptime, universal reachability, latency, service quality or resilience.

Five observed neighbours describe paths, not contracts

The neighbour response contains five AS numbers. AS4134 and AS4809 appear on the left side of captured paths. AS146814, AS58828 and AS58834 appear on the right. The dataset therefore offers a richer public relationship surface than a single-neighbour origin.

The words “left” and “right” are properties of observed AS paths in the response. They are not legal or commercial roles. A left-side neighbour is not automatically an upstream transit provider, and a right-side neighbour is not automatically a customer. Collector position, route selection and policy affect how a relationship appears.

The data does not disclose payment, contract duration, service level, capacity, physical interconnection site or ownership. It cannot prove that AS4134 or AS4809 is an exclusive upstream. It cannot prove that AS146814, AS58828 or AS58834 buys service from the Guangzhou network. Those interpretations require independent evidence.

Five visible neighbours also do not establish diversity. Multiple sessions can share one building, conduit, power system or router. Conversely, an adjacency represented once in BGP can be delivered over multiple circuits. Logical plurality and physical independence are different claims.

The response may not show every relationship. Private interconnections, paths not selected by collectors, sessions used only under particular conditions and internal arrangements can remain invisible. The neighbour list is a bounded public observation, not a complete graph.

Its practical value lies in change detection. If one observed neighbour disappears while prefixes or visibility change, the coincidence can guide further investigation. If a new neighbour appears, the public routing surface has changed. Neither event explains itself; it creates a question for operators and evidence gathering.

Route direction cannot assign upstream and downstream responsibility

Network diagrams often place providers above and customers below. The left/right structure in RIPEstat can look similar enough to invite the same reading. That shortcut is unsafe.

BGP path data shows how selected announcements reached observers. Relationship inference usually requires additional methods and still carries uncertainty. A path position does not reveal contract terms, traffic direction, settlement, operational authority or who must act first during an incident.

This matters for accountability. If AS134773 loses visibility after a change involving AS4809, the public record alone cannot determine which network caused the problem or which contract assigns repair responsibility. The event could involve policy, maintenance, route selection, filtering, a shared physical fault or a measurement change.

Likewise, a right-side AS may originate traffic or prefixes through arrangements that do not fit a simple retail-customer model. It may be an affiliated network, a peer, a customer, or appear through a policy that the public response does not describe. Naming the AS number is factual; naming the commercial relationship would be speculative.

A responsible incident record would combine route observations with operator notices, timestamps, facility evidence and customer measurements. It would separate what changed in BGP from what failed in forwarding and from what the parties reported.

The neighbour list is therefore best treated as an accountability index. It identifies networks whose public paths intersect the origin in the captured view. It does not allocate blame, ownership or contractual responsibility.

Guangzhou in the name does not create a coverage boundary

Guangzhou appears in the APNIC name and the directory object. The postal detail in the registry description includes 510000, a Guangzhou postal code. These facts support a geographic association in the recorded identity.

They do not establish where every announced address is used. IP addresses can serve infrastructure, customers or systems outside a registry label's city. Routing policy can aggregate resources across operating areas. The source set contains no verified endpoint inventory or service-qualification database.

A citywide coverage claim would require evidence of the access layer: service maps, address qualification, licensed service areas, facility records, measured endpoints or operator documentation. None of those appears in the six frozen sources. A map drawn from the ASN and city name would supply precision that the evidence lacks.

The distinction is important in a large metropolitan market. Different districts, industrial zones and customer classes can depend on different access systems and repair organisations. A broad routing origin can sit above fragmented local delivery. Conversely, a network can deliver local service through resources originated elsewhere.

The correct geographic statement is that the public registry and directory associate AS134773 with the Guangzhou MAN identity in Guangdong, China. The article cannot say that all visible prefixes terminate in Guangzhou or that the network covers the municipality.

Treating the city as part of an identity rather than a polygon keeps future evidence open. A facility disclosure or verified service map could later add physical geography. Until then, the route table remains a control-plane surface with a city label, not proof of citywide delivery.

The physical MAN is the principal missing system

A metropolitan-area network is ultimately physical. It depends on fibre or other access media, aggregation equipment, interconnection points, power, cooling, field maintenance and customer handoffs. None of those assets is identified in the frozen source set.

The absence prevents a statement about ownership. AS134773 can originate routes without owning every conduit, facility or access segment used to deliver service. Infrastructure may be leased, shared, delegated or operated through organisational boundaries that the ASN record cannot show.

It also prevents a topology claim. Thirty-six IPv4 routes and nine IPv6 routes may converge on a small number of routers or facilities. Five observed neighbours may connect through the same physical location. The public graph cannot show whether supposed alternatives are actually independent.

Power is similarly invisible. A routing origin can remain visible through some sessions while a local aggregation site loses power. Backup generation, battery duration, fuel logistics and restoration procedures do not appear in BGP. No resilience claim can be made without evidence from those layers.

The customer handoff is another missing boundary. The source set does not say whether services reach homes, enterprises, government networks, other operators or internal systems. It does not disclose demarcation points, access technologies or who maintains the last segment.

The route-origin layer remains useful because it provides the outer control surface of that hidden system. It tells researchers what can be observed from outside. The physical MAN must remain unproved until asset, facility or operator evidence connects those routes to real delivery dependencies.

Capacity words require different evidence

Infrastructure descriptions often slide between designed, installed, lit, powered, sold and usable capacity. None of those concepts can be derived from AS134773's prefix list.

Designed capacity describes an engineering intention. Installed capacity refers to equipment or fibre actually deployed. Lit capacity requires active optical or electronic systems. Powered capacity depends on electrical and cooling support. Sold capacity is a commercial commitment. Usable capacity accounts for bottlenecks, reserves, failures and operating policy.

Address-space arithmetic belongs to none of these categories. The 145,664 IPv4 addresses and 86 IPv6 /48 units describe the unique space represented in current routing. They reveal no port speed, wavelength count, spectrum, throughput, oversubscription or headroom.

Neighbour count is not capacity either. Five observed AS relationships can be carried over small or large links, shared or independent facilities, and diverse or common conduits. BGP does not publish the physical rate of a session.

Even a future equipment list would require care. A chassis specification is design potential, not proof that cards are installed, ports are lit, power is available, traffic can be carried after a failure, or customers have bought the service. Capacity reporting must follow the physical dependency chain.

For AS134773, the supported language is about routing breadth and observability. The article must not convert that breadth into claims about speed, scale, market share or spare capacity. Those questions remain open for evidence that directly measures the relevant layer.

Registry and routing dates run on different clocks

The source set contains several dates that can be placed in order but not merged into one service history. APNIC records registration in October 2015 and a last change in June 2021. RIPEstat reports a first-seen route in December 2020 and a latest observation at the July 2026 query time.

Registration does not prove construction or commercial launch. A resource can be registered before use, after an operational decision, or as part of administrative reorganisation. The first-seen timestamp reflects the routing dataset and its visibility rules, not the first customer packet.

The last registry change may involve contact or descriptive maintenance rather than a network redesign. The latest route observation shows that a route under the origin was visible at that moment; it does not prove uninterrupted service since first visibility.

The gap between 2015 registration and 2020 first-seen routing cannot be labelled a five-year build period. The sources do not explain it. Historical collector coverage, routing policy, reassignment, delayed use and other possibilities remain open.

Separating the clocks helps future analysis. A registry change can be compared with route changes without assuming causation. A documented incident can be added as a third evidence class. Customer and physical-system dates can be introduced only when independently verified.

The current record supports a dated baseline, not a complete chronology. That baseline is still valuable because it preserves what each public system said and when it said it.

Public contacts expose coordination, not recovery performance

Chinanet Hostmaster and IRT-CHINANET-CN give AS134773 identifiable contact surfaces. That matters because Internet incidents cross organisational boundaries. An operator seeing a route leak, abuse issue or resource inconsistency needs a place to send evidence.

The value is practical and limited. A published address reduces the first step of coordination. It does not show whether the mailbox is monitored around the clock, which team receives the message, who can change routing policy, or how quickly an issue is resolved.

Abuse-contact economics can be significant. Poorly handled abuse can increase filtering, reputation costs and operational friction for an address range. A functioning contact path can reduce those costs. The frozen evidence does not measure response rates or outcomes, so it cannot score AS134773's performance.

The same contact may serve a much larger organisational domain than the Guangzhou MAN label. That broad scope can be efficient or can create handoff delays; the record does not say. It also does not establish that the contact owns the physical network or customer relationship.

A stronger accountability record would include dated examples: notices received, actions taken, route corrections, restoration times and communications during incidents. No such cases appear in the source set.

The accurate conclusion is that APNIC publishes administrative, technical and abuse coordination metadata for the ASN. The article may treat that as a real accountability surface. It may not treat it as proof of support quality, response time or operational continuity.

Failure can occur below a stable route

The most important operational boundary is the space beneath BGP. A route can remain fully visible while packets fail later in the path. An access fibre cut, aggregation error, DNS failure, authentication outage, power loss or customer-premises problem may never remove the public announcement.

This means a monitoring dashboard based only on AS visibility can report normal conditions during a severe local event. The route table answers whether reachability is being advertised, not whether every forwarding, service and access dependency is working.

The five observed neighbours do not solve the problem. Multiple logical paths can converge on one facility or conduit. A shared power or configuration dependency can defeat apparent routing diversity. The source set contains no failover test or physical-diversity evidence.

The opposite error is also possible. A route change can look alarming while customer service continues through alternate paths or local systems. A withdrawal seen by one collector population may reflect policy or measurement rather than an outage.

Useful incident analysis must correlate layers. Route visibility, endpoint tests, DNS behaviour, facility status, operator notices, power conditions and customer reports should be time-aligned. Each piece answers a different question.

AS134773 gives observers a strong control-plane anchor for such work. It does not remove the need for service and physical evidence. The broad route table is a place to begin a failure investigation, not a substitute for one.

A useful monitoring baseline is exact and modest

The frozen response can support a practical baseline. Record the ASN name and status, the exact prefix set, the unique announced-space arithmetic, peer visibility and the five observed neighbours. Preserve the query times and raw responses so later comparisons use the same evidence class.

A future change can then be described precisely. A prefix may be added or withdrawn. An origin may change. A more-specific may appear. Visibility may fall in one address family. A neighbour may disappear or be joined by another observed path.

The baseline cannot explain a change automatically. Planned engineering, policy, measurement, transfer, misconfiguration and outage can produce similar public signals. Each event requires additional evidence before it is given an operational or commercial meaning.

Comparison also needs to account for the measurement system. Peer populations and collector views can change. A difference between snapshots may come from the network, the observation platform or both. Raw dates and counters help separate those possibilities.

The narrowness of the baseline is a strength. It avoids turning external data into an internal topology. It provides repeatable facts that another researcher can verify. It leaves missing layers visible rather than filling them with brand assumptions.

For procurement and risk work, this baseline can trigger questions. It cannot answer whether a service should be bought, how resilient it is, or which party bears loss during failure. Those decisions need contract, facility and service evidence.

Procurement should ask for the missing operating map

A buyer evaluating service associated with the Guangzhou MAN identity should not treat the route table as sufficient diligence. The public data proves a routing object and broad visibility. The procurement question is how that object connects to the service being offered.

The first request should identify the contracting legal entity and the operational demarcation. Which company signs the agreement? Which team controls routing? Who owns or leases the access segment? Where does responsibility transfer to another operator or the customer?

The second request should follow physical dependencies. Which facilities and conduits carry the service? Are alternate paths physically separate? What power arrangements support aggregation and interconnection? Which elements are shared even when BGP paths appear different?

The third request should distinguish capacity categories. What is installed, lit, powered, sold and usable under normal and degraded conditions? Prefix size and neighbour count cannot answer. Evidence should include current configurations, tested limits and failure reserves rather than only design claims.

The fourth request should cover recovery. What failures have been tested? How are routes, circuits and customer handoffs restored? Which contacts have authority to act? What incident evidence supports the promised restoration time?

These questions do not diminish the value of AS134773. They use its public surface as an index into the missing operating system. A strong supplier should be able to connect the registry and routing identity to documented delivery responsibilities without asking the buyer to infer them.

Physical dependency claims need evidence of operating state

Infrastructure evidence becomes misleading when it collapses different operating states into one word such as “built” or “available.” A metropolitan route can be designed, equipment can be installed, fibre can be present, ports can be lit, systems can be powered, capacity can be sold, and service can be usable at different times. None of those states follows automatically from an announced prefix.

The same discipline applies to projects and facilities. “Under construction” is not energised. Energised is not commissioned. Commissioned is not commercially operating. A public route may appear before or after any one of those milestones, and the source set does not connect AS134773's announcements to a specific physical deployment timeline.

An operating-state claim should therefore name its evidence. A dated commissioning notice can support one milestone. A live endpoint test can support a limited service observation. A facility record can support location and equipment presence. An incident report can support a failure and recovery sequence. BGP can support the origin and visibility layer.

The layers should then be connected carefully. If an operator says a new path is live, route observations can test whether a control-plane change appeared. They still cannot show whether traffic used the path, whether capacity was available under load, or whether customer handoffs moved successfully.

AS134773 currently supplies the routing layer of such a dependency record. It does not supply evidence for design ownership, construction, energisation, commissioning or commercial operation of a particular Guangzhou asset. Those states remain separate research questions.

Five neighbours do not answer the redundancy question

A list of five observed neighbours can look like a ready-made resilience argument. It is not. Resilience depends on whether supposedly alternate elements fail independently, not merely on how many AS numbers appear in a path dataset.

Two sessions can terminate on the same router. Two routers can share a room, a power feed, a cross-connect tray or a conduit. Separate facilities can depend on one upstream cable corridor. Different AS relationships can still be operated by teams that share a change process or configuration system. None of these common-mode risks is visible in the neighbour count.

The reverse is also possible. One observed AS relationship may be implemented over multiple circuits, facilities or paths. Public BGP may compress physical diversity into one logical adjacency. A count of one would then understate physical alternatives, just as a count of five can overstate them.

Evidence of redundancy requires more than a topology diagram. It should identify independent components, show that they are active, document which failures they are intended to survive, and provide a test or incident in which traffic moved as designed. Capacity under degraded conditions matters because a backup path that exists but cannot carry the load is not full operational redundancy.

The current source set provides none of those proofs. AS134773's five observed neighbours are useful monitoring points and possible dependencies. They are not a resilience score, a failover test, or evidence of physical diversity.

A better public disclosure would connect the layers

The uncertainty around AS134773 is not inevitable. A concise operator disclosure could connect the public routing identity to delivery without revealing sensitive internal detail.

It could begin with the legal and operating boundary: the entity responsible for the ASN, the entity contracting with customers, and the teams responsible for routing, access and incident response. It could distinguish owned infrastructure from leased or partner-delivered components.

A second section could describe the service dependency chain at a level useful for risk review. Named facilities are not always necessary, but the operator could state whether major interconnections are geographically and electrically separate, whether access and core systems share common points, and what level of customer service depends on each layer.

A third section could distinguish capacity states. Installed and powered systems should not be presented as sold or usable capacity. Backup capacity should be described under the failure condition it is intended to support. Current tests should be dated.

A fourth section could provide operational evidence: route-change procedures, contact escalation, failover tests, significant incidents and restoration outcomes. Public summaries can preserve security while showing that recovery claims have been exercised.

Such disclosure would not replace APNIC or RIPEstat. It would complement them. The registry would remain the number-resource ledger, and routing observations would remain the running public control surface. Operator evidence would supply the legal, physical and recovery layers that the public protocols were never designed to carry.

The route table supports accountability when its limits stay visible

AS134773 is not an empty directory shell. APNIC identifies the resource, RIPEstat sees it announced, both address families are visible, and five routing neighbours appear in the captured dataset. The number-resource and control-plane surface is real.

The public record is also incomplete in predictable ways. It does not define the legal company, physical MAN, customer footprint, facility dependencies, capacity, service quality or recovery design. Those gaps are not defects in BGP or RDAP. They are consequences of using systems built for routing coordination and resource records to answer broader operational questions.

The disciplined interpretation preserves both sides. Registry data is authoritative for the recorded identity and contact metadata. Routing data is useful for dated announcements, visibility and observed paths. Neither becomes sovereign proof of physical service.

That distinction is the reality layer behind the article. Infrastructure exists through running systems and dependencies, not through names alone. A public ledger can make a network accountable enough to observe while still leaving the crucial delivery boundary unproved.

The broad table therefore changes the next question rather than ending the inquiry. Researchers can monitor the 45 announcements and five observed relationships. Buyers can demand the legal and physical map. Operators can publish clearer evidence about responsibility, diversity and recovery.

Until that evidence exists, the supported conclusion remains exact: AS134773 exposes a broad dual-stack routing surface associated with the Guangzhou MAN identity. It does not expose a complete map of Guangzhou's delivery network.