Summary

  • RIPE records AS212237 with the as-name PXNET, ASSIGNED status and organisation reference ORG-PN126-RIPE. RIPE's organisation record associates ORG-PN126-RIPE with Changgong Zhang, country CN and the description Phoenix Network. APNIC separately records active AS141445 as PXNET-AS-AP under Phoenix Network, with Zhang Changgong in administrative and technical roles. These public registry fields connect the naming context, but AS212237 and AS141445 remain distinct routing entities whose routes, policies and observations must not be merged; the records do not establish legal-identity equivalence.

  • The strongest operational reading keeps every evidence layer within its authority. RIR records provide administrative registry entries, PeeringDB provides operator-contributed declarations, RIPEstat shows selected routing at specified times, the Internet Routing Registry records policy entities, and RPKI validates the origin of exact queried prefixes. Together they support disciplined questions about record accuracy and continuity, not claims about physical topology, traffic, reliability, commercial arrangements or the generated image.

Public records are useful when their limits stay visible

A network can have one name in a directory, another form of that name in a registry, several number-resource identifiers and many routes visible from different parts of the internet. To a non-specialist, the records can look like pieces of one definitive description. They are not. Each system was built for a particular coordination problem, and each sees only part of the operating environment. The practical task is to connect the records without flattening their differences.

RIPE records AS212237 with the as-name PXNET, ASSIGNED status and organisation reference ORG-PN126-RIPE. RIPE's organisation record associates ORG-PN126-RIPE with Changgong Zhang, country CN and the description Phoenix Network. APNIC separately records active AS141445 as PXNET-AS-AP under Phoenix Network, with Zhang Changgong in administrative and technical roles. Those facts create a traceable public connection among names and identifiers. They do not turn two autonomous systems into one routing entity, nor do they establish a complete legal or physical identity for everything that may use the PXNET name.

An autonomous system is a network identity used in inter-domain routing. The autonomous system number, or ASN, gives other networks and public coordination systems a stable reference for policy and reachability. An ASN does not identify every router, cable, server, employee or customer. It also does not establish that every route associated with a named operator is visible from every observation point. The identifier is important because it supports coordination; its importance does not make it a universal certificate.

The same principle applies to the other records. An operator-maintained profile can describe how the operator presents its network and interconnection policy. A routing collector can report what selected peers made visible at a particular moment. A routing registry can store declared policy. A Route Origin Authorization, usually shortened to ROA, can allow an ASN to originate a prefix within stated prefix-length limits. These records can be aligned, compared and monitored. None, by itself, proves what a customer experienced or how the physical network was built.

This layered method offers more decision value than either enthusiasm or suspicion. Promotional interpretation treats every positive-looking field as proof of a strong network. Adversarial interpretation treats every difference as proof of failure. Both shortcuts discard the actual authority of the records. A better approach asks four questions whenever a fact appears: who recorded it, what exact entity did the record describe, when was it current or observed, and what conclusion remains outside its scope?

For PXNET, that method keeps the inquiry operational. It supports a comparison between administrative records, operator declarations, selected observations and origin-validation state. It also reveals the missing evidence that would be needed for a service decision: measurements of traffic, latency and availability; a physical path and dependency map; commercial agreements; maintenance records; and service-specific recovery results. Missing evidence is not a negative verdict. It is a boundary around what the public record can responsibly support.

The central lesson is therefore about control rather than reputation. Accurate number-resource records help networks coordinate. Running routing systems show what is actually visible. Security metadata can constrain origin authorization. Directory entries can help operators discover possible interconnections. Operational continuity depends on these layers remaining accurate and reconcilable over time. The records matter most when they are read as distinct tools in that process.

Two autonomous systems require a strict identity boundary

The public registry material connects PXNET and Phoenix Network to two autonomous-system records, but it does so through different registries and different entities. RIPE records AS212237 with the as-name PXNET, ASSIGNED status and organisation ORG-PN126-RIPE. Its organisation record associates ORG-PN126-RIPE with Changgong Zhang, country CN and the description Phoenix Network. APNIC separately records active AS141445 as PXNET-AS-AP under Phoenix Network, with Zhang Changgong in administrative and technical roles.

The most important word in that description is “separately.” The records support a connection through the same named operator identity. They do not support combining the route sets, routing policies, address resources or observations of AS212237 and AS141445. A fact observed for AS212237 does not become a fact about AS141445 merely because both records contain PXNET or Phoenix Network language. Likewise, an administrative role in the AS141445 record does not prove ownership of the infrastructure associated with either identifier.

Name order also needs restraint. The RIPE organisation record uses Changgong Zhang, while the APNIC material identifies Zhang Changgong. The safe treatment is to preserve the source-specific Romanized forms. Public registry records can link those forms to their respective entities, but they do not provide a basis for inventing Chinese characters or making a broader legal-identity assertion. That may seem like a small editorial choice, yet name normalization can create a false precision that then spreads into entity and ownership claims.

Keeping the two ASNs distinct is not mere recordkeeping. Routing analysis is indexed by the autonomous system that originates a prefix or appears in a path. If an observer asks which prefixes were visible, which neighbours appeared or whether an origin was valid under a ROA, the answer is tied to the exact ASN in the query. Substituting another ASN changes the subject. It can produce a confident statement whose numbers came from the wrong network entity.

This risk grows when several databases are placed side by side. A search interface may show related names, and an analyst may be tempted to treat every result as corroboration of one network-wide fact. In reality, repeated names can help resolve an identity while the surrounding fields remain entity-specific. Identity resolution and operational aggregation are different tasks. The first asks whether records plausibly refer to the same named operator context. The second asks whether their technical contents can be combined. The public material supports the first only within recorded fields and rejects the second for these two routing entities.

For business readers, the distinction clarifies responsibility questions. A prospective partner could ask which ASN would be used for a particular service, which registry and routing contacts apply, which prefixes are involved, and which interconnection policy governs the traffic. An answer naming PXNET without naming the relevant ASN may still be too broad for an operational decision. The service path, route authorization and escalation point need to be attached to the actual routing entity.

The boundary also protects against overstating scale. Two ASNs do not necessarily mean two independent networks, two facilities, two teams or two failure domains. They are two distinct routing identifiers in the public records. Independence would require evidence about physical paths, equipment, power, upstreams, operations and management systems. Conversely, the presence of shared names does not show that one identifier is redundant or inactive. Current operational state must be examined through observations tied to each entity.

That is why the analysis that follows is deliberately scoped to AS212237 whenever it discusses RIPEstat routing observations, the PeeringDB profile or the queried RPKI results. AS141445 remains relevant as a separate registry identity linked by public naming fields. It is not used as a substitute source for AS212237, and no AS212237 count is attributed to it.

A registry is an operational ledger, not a property deed

The RIPE Database aut-num entity records AS212237, the as-name PXNET, ASSIGNED status and organisation ORG-PN126-RIPE. The organisation record associates ORG-PN126-RIPE with Changgong Zhang, country CN and the description Phoenix Network. These are registry facts. They establish what the public ledger records and help other operators find the identifiers and contacts attached to the entity. They do not establish a corporate charter, an ownership certificate, a workforce, revenue, physical facilities, equipment or a service guarantee.

Treating the registry as a ledger makes its importance easier to understand. Internet number resources must remain unique enough for global coordination. Operators need a stable way to identify the network responsible for an ASN or prefix, publish contacts and document policy. When records are accurate, another network can investigate an unexpected route, build a filter, report abuse or coordinate a change with less ambiguity. When they are stale, response becomes slower and misattribution becomes more likely.

The ledger does not make packets move. Routers implement policy, establish Border Gateway Protocol sessions and exchange reachability. Cables, power, software and people sustain that operation. The public registry describes intended associations and policy-related data; running systems create the current operational state. Comparing the two can reveal useful questions. It cannot turn the registry into a sovereign authority over geography or into proof of every physical and commercial fact.

APNIC's separate record for active AS141445 illustrates the same role. It identifies PXNET-AS-AP under Phoenix Network and records Zhang Changgong in administrative and technical roles. Its registration date, 1 December 2020 at 22:43:23 UTC, and last-changed time, 7 November 2023 at 05:49:56 UTC, belong to that AS141445 record. They are not creation or update times for AS212237, an article publication date or evidence of a network event.

Dates in registry systems are particularly easy to overread. A creation field can show when an entity entered the ledger. A last-modified field can show when the record changed. Neither establishes when a service began, when a physical network was built or whether every field stayed operationally accurate between updates. The appropriate inference is administrative: a record existed and was maintained at the stated times. Operational continuity requires additional evidence that the record continues to match running arrangements.

The phrase ASSIGNED also needs its registry scope. In the RIPE entity, it is a status field attached to AS212237. It does not say that every address, route, facility or interconnection under discussion belongs to the same party. Nor does it certify performance. Registry terminology should be preserved rather than translated into familiar but stronger business language such as owner, operator of all assets or licensed service provider.

This reality-based interpretation is not an argument against registries. It is an argument for using them well. A ledger is valuable because it preserves coordination facts while allowing those facts to be checked against running code and observations. If a route appears with an unexpected origin, a maintained record helps determine what should be investigated. If policy entities and observed adjacencies differ, the comparison can prompt an update or a technical explanation. The registry enables the inquiry without predetermining its answer.

For PXNET, the public ledger creates a stable starting point around AS212237 and ORG-PN126-RIPE. It lets readers distinguish the RIPE entity from the separately recorded AS141445 in APNIC. It also provides the identity against which PeeringDB declarations, RIPEstat observations and exact RPKI queries can be examined. The result is a stronger chain of evidence precisely because the registry is not asked to prove what it cannot see.

PeeringDB records an operator's interconnection description

The operator-maintained PeeringDB profile describes AS212237 as Phoenix Network/PXNET, classifies it as an educational or research network and states that it is a personal network for learning and research. The same profile lists an open peering policy and exchange rows for 4b42, EVIX, HamroIX-Amsterdam, OpenSwitch-IX, PyramIX, TOHU IX and ZXIX Hangzhou at retrieval time. These are useful directory declarations. They are not an independent certification that PXNET is a commercial carrier, occupies a particular facility or exchanges a measured volume of traffic.

PeeringDB helps networks discover one another and publish information that may support interconnection. That declared posture can signal willingness to consider peering under the operator's stated approach. A directory row can indicate a declared operational attachment. For another operator, these fields can narrow the work of finding technical contacts and possible meeting points. They do not show whether a session with a particular entity exists, which routes are exchanged or how traffic behaves.

The operator-contributed nature of the profile matters. PeeringDB provides the directory system, but the network is responsible for its profile fields. The correct attribution is therefore that the profile lists or declares the information. Saying simply that PXNET “has” every listed relationship can erase the difference between a directory entry and an independently observed session. It can also make a stale field sound current after the underlying arrangement changes.

Exchange names can invite another error: inferring physical presence or geographic ownership from the label alone. A listed exchange row does not prove which device, port, building, cross-connect or transport arrangement supports the connection. It does not show whether the path shares a facility, carrier or power dependency with another row. It certainly does not make the entity an owner of the exchange or of connectivity in the named place.

That declared posture is similarly bounded. It is not an obligation to peer with every network. Technical compatibility, traffic patterns, route policy, capacity, security practices and operational readiness may still matter. The posture also does not establish commercial terms. Peering, paid transit and other interconnection arrangements can produce similar-looking routing paths while resting on different agreements that the public directory does not reveal.

For a buyer or partner, the exchange rows are best treated as a question set. Which entries are currently active? Which sessions are direct and which use a route server? Which prefixes are accepted? Are there capacity or maintenance constraints? Which physical dependencies are shared? How are incidents escalated? The profile can help locate the conversation, but measured answers require current operational evidence.

The educational or research classification and personal learning description deserve equal care. They are the operator's description of the network's type and purpose in the profile. They should not be transformed into praise, dismissal or an assumption about competence. Nor should they be rewritten as proof of a conventional commercial-carrier business. The facts support a network-operations briefing because they explain the context in which the public records exist. They do not support a generic corporate profile or a market-ranking story.

This distinction also affects how directory changes should be monitored. A new exchange row could reflect an intended or completed interconnection, a profile cleanup or another administrative change. A removed row could reflect disconnection, consolidation or maintenance of stale data. The profile alone does not identify the cause. Correlation with observed routing and direct operator confirmation would be needed before attaching an operational consequence.

PeeringDB therefore adds a valuable declaration layer to PXNET's record. It tells readers how the operator presents AS212237, its declared interconnection approach and its directory footprint. Its contribution is strongest when that scope remains explicit. Once directory declarations are separated from measurement, they can be compared intelligently with RIPEstat rather than mistaken for a live topology diagram.

RIPEstat supplies a time-bound view of visible routing

At RIPEstat's 11 August 2026, 00:00 UTC routing-status snapshot, AS212237 had five visible IPv4 prefixes covering 1,024 IPv4 addresses and five visible IPv6 prefixes covering 20 IPv6 /48 equivalents. The same snapshot reported five observed BGP neighbours and full visibility among the returned peer sets for both address families. These numbers belong to a visibility-filtered collector view at a specified time. They are not a permanent allocation, a utilization figure, a customer count, a capacity measure or a complete roster of commercial peers.

The Border Gateway Protocol, or BGP, is the system through which independently administered networks exchange reachability. A routing collector receives routes from a set of peers and makes those observations available for analysis. That creates a powerful window into running operation, but it is still a window. A route that is private, localized, filtered or below the endpoint's visibility criteria may not appear. A visible route can also change after the snapshot.

In RIPEstat's 11 August 2026, 00:00 UTC snapshot, “five visible IPv4 prefixes” for AS212237 is a compound fact. The number five, the IPv4 family, the word visible, the AS212237 origin and the snapshot time all define its meaning. Removing any of those elements makes the statement broader. The accompanying 1,024 IPv4 addresses remain within the same RIPEstat observation scope. They do not become a measure of address holdings, active customers or usable service capacity.

The IPv6 figures require the same precision. At its 11 August 2026, 00:00 UTC snapshot, RIPEstat returned five visible IPv6 prefixes and 20 IPv6 /48 equivalents for AS212237. A /48 equivalent is a normalization unit for IPv6 address space in the observation. It should not be shortened to “20 IPv6 addresses” or treated as twenty physical networks. IPv6 prefix length is part of the fact, and the normalized count remains an observation rather than an inventory.

The returned adjacency indicator is also method-bound. A collector-visible adjacency may help an analyst understand the reported context. It does not enumerate every private, backup or commercial relationship. It also does not explain whether a visible adjacency is a paid transit provider, a settlement-free peer, a customer or another arrangement. Those labels require evidence beyond the endpoint result.

The endpoint's reachability indicator can sound comprehensive, but its scope is the peer sets returned by that query. It does not mean every network on the internet saw every prefix, every user reached every service or all paths performed equally. Routing visibility is a reachability signal. Application availability depends on DNS, transport, servers, software and many other components. Performance depends on path quality, congestion, distance and endpoints. A strong collector result cannot substitute for those measurements.

RIPEstat's announced-prefixes endpoint adds a bounded history. For the 28 July 2026 through 11 August 2026 query window, it listed ten visible origin announcements for AS212237: five IPv4 and five IPv6 prefixes. The window and the two family subtotals must remain attached to the number ten. It is not a timeless statement, and it is not a basis for summing overlapping more-specific IPv4 announcements as separate holdings.

Why can a bounded list matter if it is not complete? It creates a repeatable reference. An analyst can compare later observations using the same definitions, look for additions or withdrawals and ask whether a change corresponds to registry maintenance, policy, an incident or collector visibility. Repetition over time can turn one snapshot into a change history. Even then, the history would describe visible routing, not application performance or physical infrastructure.

For operational continuity, that distinction is useful. A registry may remain unchanged while running routes move. A route may remain visible while a service behind it fails. A directory row may change without any customer effect. Monitoring should therefore keep the evidence streams separate and correlate them only when time and scope align. RIPEstat provides the running-routing layer that registry and directory records cannot, while leaving service outcomes for other evidence.

BGP and IRR comparisons reveal questions, not misconduct

RIPEstat's consistency view compared routing observations with Internet Routing Registry records for AS212237. At the query snapshot, the returned comparison showed the five visible IPv4 announcements in both BGP and IRR records. It also showed five visible IPv6 announcements without matching IRR entries in that returned comparison, alongside multiple recorded IPv6 entries that were not visible in BGP. Those are record-layer differences within the endpoint's definitions. They are not proof of malicious routing, invalid authorization, negligence or a permanent defect.

An Internet Routing Registry, or IRR, stores routing-policy entities published by network operators and maintainers. These entities can help other networks generate filters and understand declared policy. BGP observations show which routes appeared in the running system from selected vantage points. The two layers can align, but they are created differently. One records declaration; the other records selected visibility.

The IPv4 result is narrow. Five visible IPv4 announcements appeared in both BGP and IRR records in the returned comparison. Presence in both can support a statement that the observation and registry data aligned for those entries under the query. It does not establish ownership, origin authorization or operational correctness. IRR databases can contain stale or differently scoped entities, and BGP visibility alone does not validate the authority behind a route.

The IPv6 result is also directional. The returned comparison showed five visible IPv6 announcements without matching IRR entries, while multiple recorded IPv6 entries were not visible in BGP. The first direction begins with observed announcements and asks whether the comparison found matching registry entries. The second begins with recorded entries and asks whether they appeared in the selected observations. Collapsing both into “the records did not match” loses information needed for diagnosis.

Several benign explanations could be investigated, but the public evidence does not select among them. A policy entity could be missing, stale, differently aggregated or stored in a place outside the returned comparison. A recorded route could be inactive, used only under particular conditions or invisible to the collectors. A visible route could be legitimate even when an IRR object is absent, because IRR presence is not the same as RPKI origin authorization. These are possibilities to test, not facts to assert about PXNET.

The consistency endpoint also distinguished observed and registered adjacencies. Some relationships listed in RPSL policy were not seen by RIPE Routing Information Service collectors, while AS917 was observed but not listed in the returned RIPE policy comparison. This again describes a difference between declared and observed layers. It does not establish the commercial type of the AS917 relationship, whether a contract existed, whether policy was wrong or whether anyone was at fault.

Routing Policy Specification Language, or RPSL, is a structured way to express routing policy in registry entities. An import or export statement can document intended relationships and help build filters. The statement does not guarantee that a session is active, that every route follows it or that the other network would describe the relationship in the same commercial terms. Running configuration may also change faster than records are updated.

For an operator, the right response to a difference is reconciliation. First confirm the exact prefixes, entities, databases, query time and collector threshold. Then determine whether the observed route is intended and authorized. Check whether the appropriate policy entity exists and whether its maintainers can update it. Compare RPKI state separately, because a ROA answers a different authorization question. Finally, examine whether the operational and administrative records should change.

For an external reader, the difference becomes a diligence prompt. How frequently are IRR objects reviewed? Which database is authoritative for the operator's filtering practice? Are route filters generated from IRR data, RPKI data or both? How are emergency announcements recorded? What is the expected delay between a routing change and a registry update? These questions connect public evidence to operational controls without treating a discrepancy as an accusation.

The distinction also reflects a broader principle: running code has primacy for current operation, while a registry remains essential for coordination. If BGP shows a route, packets may be using it regardless of whether a matching policy entity appears in the comparison. That does not make the route legitimate; it means legitimacy and operational state must be evaluated with the right evidence. Conversely, a perfect policy entity does not create a live route. The two layers should inform each other rather than being mistaken for substitutes.

PXNET's returned comparison is valuable because it preserves the direction of each difference. Its precision comes from retaining attribution, direction and time. Once those qualifiers disappear, the same data can be turned into a misleading claim of either complete consistency or serious failure.

RPKI-valid origins answer one exact security question

RIPEstat marked AS212237's origin of 103.31.236.0/23 RPKI-valid under a covering 103.31.236.0/22 ROA with maxLength 24 at retrieval time. For a separate IPv6 query, RIPEstat marked AS212237's origin of 2403:6380:60::/44 RPKI-valid under matching and covering ROAs with maxLength 48 at retrieval time. These results establish origin authorization for the exact queried origin-prefix combinations within the stated ROA limits. They do not validate the complete path, guarantee availability, establish ownership or prove service security.

Resource Public Key Infrastructure, or RPKI, lets number-resource holders publish cryptographically verifiable statements about which ASN may originate a prefix and how specific the announced prefix may be. A ROA contains the authorized origin and a prefix scope. The maxLength field can permit more-specific announcements down to a stated length. Origin validation compares a route's origin and prefix length with the visible ROAs.

The IPv4 result contains several facts that must travel together. The observed origin is AS212237. The queried prefix is 103.31.236.0/23. The covering ROA uses 103.31.236.0/22 and permits maxLength 24. RIPEstat's routinator-backed result marked that exact origin-prefix combination valid at retrieval time. Saying only that “PXNET is RPKI-valid” would broaden one query into a network-wide and timeless statement.

The IPv6 result has the same constraint. It concerns AS212237 and 2403:6380:60::/44 under matching and covering ROAs with maxLength 48 at retrieval time. It does not validate every IPv6 prefix associated with PXNET, every more-specific announcement or every future change. IPv6 punctuation and prefix length are part of the identifier; shortening or reformatting the prefix can change the technical entity being discussed.

Origin validity is one layer of routing security. It can help networks reject announcements whose origins conflict with the visible authorization. It does not verify every ASN in the path or show that the path is physically safe, uncongested or free from policy mistakes. A valid origin could still be attached to a poorly performing service. An invalid or not-found result would also require diagnosis rather than an immediate conclusion about intent.

RPKI and IRR should therefore not be merged. An IRR object records routing-policy information and is often used to construct filters. A ROA provides cryptographically verifiable origin authorization. A route can have one kind of record without the other. The RIPEstat consistency comparison and the RPKI validation results answer different questions, even when they concern the same ASN and prefix family.

For business users, origin validation is best understood as a control with measurable scope. A buyer can ask whether the operator maintains ROAs for relevant prefixes, monitors validation state, tests changes before announcing more-specific routes and coordinates with upstreams that enforce Route Origin Validation. The public results for the two queried prefixes are useful starting evidence. They do not show the operator's complete process or the enforcement choices made by every neighbouring network.

Change management matters because authorizations and announcements can evolve. A new prefix, a change in origin ASN or a more-specific announcement may require updated ROA coverage. A maxLength that is too permissive can allow more-specific announcements within the authorization, while one that is too restrictive can make an intended route invalid. The public record does not describe PXNET's internal change process. It shows two exact valid results that can be monitored for change.

The strongest conclusion is consequently precise rather than sweeping. At retrieval time, RIPEstat found the AS212237 origin valid for 103.31.236.0/23 under the covering 103.31.236.0/22 ROA with maxLength 24, and valid for 2403:6380:60::/44 under matching and covering ROAs with maxLength 48. That is meaningful evidence of origin authorization for those queries. Everything beyond that boundary needs separate proof.

The layers form a method for operational accountability

PXNET's public record becomes most useful when the evidence systems are treated as a sequence of questions. The RIPE and APNIC records answer what their administrative ledgers contain. The operator-maintained PeeringDB profile answers how AS212237 is described for network discovery and interconnection. RIPEstat's routing endpoints answer what selected collectors returned at specified times. The consistency view compares observed and registered routing data. RPKI validation answers whether exact queried origins comply with visible ROAs.

No single layer is the whole truth, but the layers are not equal or interchangeable. A registry is authoritative about its own record. It is not a measurement platform. PeeringDB is useful for operator-contributed declarations. It is not an independent topology assessment. RIPEstat provides observation with a method and time. It does not see every route or business arrangement. RPKI validates origin authorization. It does not validate service performance or the full path.

This structure creates accountability because differences can be named precisely. If an operator declaration changes, the old and new profile fields can be compared. If routing visibility changes, the observation time and collector scope can be recorded. If an IRR object does not match an observed announcement, the direction of the difference can be examined. If a prefix becomes RPKI-invalid, the origin, prefix length and ROA can be checked. Precision makes repair possible.

It also prevents political or ownership narratives from replacing operation. Number resources need unique identifiers, accurate records, transfer history, security metadata and continuity. Those functions support the internet's coordination. They do not make a registry sovereign over a geography, and they do not make a community label or permission claim proof of operational legitimacy. What matters to the network is whether identifiers are accurate, routes function as intended and changes remain observable and reversible.

For a prospective interconnection partner, the public evidence can support a focused discussion. The partner can confirm the relevant ASN, validate contacts, examine the open-policy declaration, identify listed exchange contexts, compare visible routes and check the origin-validation state of intended prefixes. It can then seek direct confirmation of session parameters, accepted routes, traffic expectations, maintenance communication and escalation. Public records reduce ambiguity; bilateral operational evidence completes the decision.

For a customer, the same records have a more limited role. They can show that a traceable network identity and selected routing controls exist. They cannot establish the performance of a purchased service. The customer would still need service boundaries, measurement locations, objectives, incident procedures and restoration evidence. Route visibility may support reachability while an application fails. Conversely, an application can remain available through paths not fully represented in one public view.

For researchers, PXNET is a reminder to preserve definitions before comparing similarly numbered outputs. A snapshot inventory, a bounded announcement history and a routing-registry comparison may refer to overlapping entities, but they arise from different endpoints and questions. They should not be added together. Their agreement can be described only after confirming that the exact prefixes and scopes align.

The same discipline applies to absence. A route not visible to selected collectors is not necessarily inactive everywhere. A policy relationship not observed by RIPE Routing Information Service collectors is not necessarily nonexistent. In RIPEstat's returned consistency comparison, an AS917 adjacency observed by RIPE Routing Information Service collectors but not listed in the returned RPSL policy data does not reveal its contract or indicate fault. Absence in one layer is evidence about that layer's result, not a universal negative.

This is the practical meaning of evidence-bounded analysis. Registry accuracy, visible announcements, exchange-directory entries and RPKI state can be compared. Physical topology, traffic, reliability and commercial arrangements remain unproven by the public records used here. That boundary makes the supported observations more credible, not less. It tells readers exactly where direct operator evidence or measurement must begin.

What decision-makers should watch next

The first monitoring task is identity hygiene. Confirm that AS212237, ORG-PN126-RIPE and the relevant contacts remain current in RIPE, while preserving AS141445 as a separate APNIC routing entity. A name match should never be used to transfer routes or observations between them. If a service uses one ASN rather than the other, the contract, support path and technical documentation should identify which entity applies.

The second task is directory freshness. PeeringDB's educational or research classification, personal-learning description, open policy and, at retrieval time, listed exchange rows for 4b42, EVIX, HamroIX-Amsterdam, OpenSwitch-IX, PyramIX, TOHU IX and ZXIX Hangzhou are operator-maintained declarations. A decision-maker should ask when a row was last verified, whether a listed attachment is active and which dependencies support it. Directory presence is a starting point for operational confirmation, not evidence of measured traffic, a commercial relationship, performance, physical presence or independent fault-domain diversity.

The third task is repeated routing observation. At RIPEstat's 11 August 2026, 00:00 UTC snapshot, AS212237 had five visible IPv4 prefixes covering 1,024 IPv4 addresses, five visible IPv6 prefixes covering 20 IPv6 /48 equivalents and five observed BGP neighbours with full visibility among the returned peer sets for both address families. RIPEstat's 28 July through 11 August 2026 query window listed ten visible origin announcements for AS212237, split into five IPv4 and five IPv6 prefixes. These are visibility-filtered observations, not permanent allocations, utilisation, customers, capacity or a complete commercial roster.

The fourth task is record reconciliation. At the RIPEstat query snapshot, the returned consistency view showed the five visible IPv4 announcements in both BGP and IRR, five visible IPv6 announcements without matching IRR entries in that comparison, multiple recorded IPv6 entries not visible in BGP, and an AS917 adjacency observed by RIPE Routing Information Service collectors but not listed in the returned RPSL policy data. These directional differences should be tracked by exact prefix or adjacency. They do not establish authorization, ownership, correctness, malicious routing, negligence, commercial relationship, contract status or fault.

The fifth task is origin-authorization monitoring. The exact IPv4 query for AS212237 and 103.31.236.0/23 was RPKI-valid under a covering 103.31.236.0/22 ROA with maxLength 24 at retrieval time. The exact IPv6 query for AS212237 and 2403:6380:60::/44 was RPKI-valid under matching and covering ROAs with maxLength 48 at retrieval time. Future checks should preserve the origin, prefix, covering authorization, maxLength and time rather than reducing the result to a network-wide label.

Decision-makers should also distinguish administrative freshness from operational health. A registry update can improve contact accuracy without changing routing. A new route can appear without a registry entity's timestamp changing. An RPKI authorization can be correct while an application remains unavailable. Monitoring becomes useful when each signal has an owner, a defined scope and an escalation path appropriate to the question it answers.

Service-specific evidence remains necessary. A partner can ask how route changes are approved, how IRR and ROA updates are coordinated, how invalid or unexpected origins are detected, and how exchange sessions are monitored. A customer can ask how reachability, latency, packet loss and application availability are measured from relevant regions. These questions move from public identity to actual operating outcomes without demanding disclosure of sensitive topology.

The accompanying image is generated realistic editorial context illustrating generic network operations, routing observation and infrastructure monitoring. It does not depict PXNET, Phoenix Network, a named facility, real equipment, real people, AS212237, AS141445, actual prefixes, exchange connections, capacity, performance, resilience, security or an incident. It contributes no factual evidence about the network.

Keep the two ASNs separate. Give RIPE and APNIC administrative registry records, PeeringDB operator-contributed declarations, RIPEstat selected routing observations, the IRR comparison and RPKI origin validation credit only for their own records. Preserve dates, numbers, units, attribution and uncertainty. Physical topology, traffic, reliability and commercial arrangements remain unproven. Then use the remaining gaps to ask for direct operational evidence. That approach turns scattered public data into a defensible inquiry while leaving unsupported praise, criticism and ownership claims outside the conclusion.