Summary

  • LACNIC records AS52426 to I-SUR WISP S.R.L. and associates the network with the AR-FAPU-LACNIC registrant handle.
  • The reviewed LACNIC records bind 179.43.64.0/20 and 138.0.56.0/22 to the same organization, while the accepted evidence does not establish an IPv6 allocation for this exact identity.
  • RIPEstat observed 38 IPv4 route entries, including aggregates and more-specifics, and reported 8,192 announced IPv4 addresses with visibility from 329 of 330 reviewed IPv4 RIS peers.
  • The representative 138.0.56.0/22 aggregate was RPKI-valid for origin AS52426 with a maximum length of 24, a narrow authorization result rather than a service-availability guarantee.
  • I-SUR describes wireless Internet and fibre-optic connectivity, but the public evidence does not establish its physical footprint, asset ownership, upstream diversity, capacity, redundancy, outage history or restoration performance.

1. A Visible Network Identity Is Not a Physical Network Map

An autonomous system number is a durable public identifier for routing policy. It allows other networks and observers to distinguish one origin from another, to track which address blocks are announced, and to compare intended route authorization with the routes visible in the global table. For I-SUR, AS52426 provides that public handle. It is a concrete operational surface, not a marketing label.

The number does not describe the access network that connects a home or business. It does not show where a radio is mounted, which streets contain fibre, who owns a pole, whether a duct is shared, or how a customer circuit reaches an upstream handoff. Those are physical and contractual questions. BGP can expose dependency through route paths, but it cannot by itself identify the cable, tower, building, power feed or maintenance arrangement carrying the traffic.

That distinction matters most when service fails. A registry record may remain accurate during a fibre cut. An authorized route may remain visible while a local access segment is without power. Conversely, a route may be withdrawn during maintenance even though the company still owns its equipment and customer relationships. Each layer has its own failure modes and time scale.

The public evidence for I-SUR is strongest at the number-resource layer. The organization name appears consistently in the BTW directory, LACNIC RDAP and routing datasets. The same evidence becomes weaker as the question moves toward physical ownership, service geography and recovery design. A disciplined account should therefore preserve the transition from known to unknown instead of filling the gaps with assumptions.

This approach also avoids treating an ASN as a proxy for company size. A compact regional operator can run a visible autonomous system, while a much larger service business may rely on another network's ASN. The presence of AS52426 proves participation in interdomain routing under that identifier. It does not reveal subscriber count, revenue, market share or the number of field assets.

2. LACNIC Provides the Exact Registry Anchor

The LACNIC autonomous-system record names I-SUR WISP S.R.L. as the holder of AS52426. It uses the registrant handle AR-FAPU-LACNIC and records the ASN from 23 November 2012, with a last-change timestamp of 16 September 2025 in the captured response. The record also exposes administrative, technical and abuse-contact roles through the registry's contact structure.

These fields perform a ledger function. They associate a unique number resource with an organization and provide points of contact for changes, routing questions and abuse coordination. They help an outside network determine whom the registry expects to be responsible for the resource. They are particularly valuable when a route origin changes unexpectedly or when harmful traffic is traced to an address block.

The record is not a licence to infer everything about I-SUR. Registration does not prove that every listed contact is reachable at every hour. It does not show the internal team that operates routers, the vendors that maintain equipment, or the contracts that connect the network to upstream providers. A public contact role can be current while operational work is delegated elsewhere.

The last-change date deserves similar care. It shows that the registry entity changed, not which business or technical event caused the update. The modification could involve contact data, metadata or another field. It should not be described as a network expansion, ownership change or service launch without a separate record.

Still, the exact-name match is important. It connects the directory company to a real Internet number-resource identity and prevents the ASN from being treated as a free-floating technical entity. AS52426 is evidence about I-SUR's routing control surface because the authoritative registry binds the two. The company remains the subject; the ASN is one of the systems through which its operational responsibility becomes visible.

3. Two IPv4 Allocations Establish Address-Space Responsibility

The reviewed LACNIC address records associate 179.43.64.0/20 and 138.0.56.0/22 with I-SUR WISP S.R.L. A /20 contains 4,096 IPv4 addresses, while a /22 contains 1,024. Those mathematical sizes describe address-space boundaries. They do not reveal how many addresses are assigned, active, routed, sold, reserved, filtered or reachable.

Address allocation is an administrative control surface. The holder must maintain accurate registration data and coordinate routing and abuse handling for the space. It can divide an aggregate into smaller prefixes for operational reasons. It can announce an aggregate, selected more-specifics or neither at a particular time. The allocation therefore creates responsibility without describing one fixed routing pattern.

The two blocks also illustrate why address count is not a capacity metric. IPv4 addresses identify endpoints or translated service structures; they do not measure bandwidth. A /20 does not imply a larger fibre network than a /22. Network architecture, address conservation, carrier-grade NAT, customer products and historical allocation policy can all change the relationship between address space and users.

Nor does an allocation establish physical location. Registry country and organizational data give a legal or administrative context, but a routed packet can cross multiple regions and facilities. The public records reviewed here do not place I-SUR routers, radio sites, access nodes, cabinets or interconnection points. They do not prove that the company owns the media carrying the addresses.

The most defensible conclusion is narrow: I-SUR holds identifiable IPv4 resources that can be monitored as aggregates and more-specific routes. That makes later changes observable. A new origin, a long withdrawal, a different authorization state or a material change in visible prefixes can be compared with this baseline. The allocations support accountability because they define what to watch, not because they disclose the entire network.

4. Thirty-Eight Route Entries Are Not Thirty-Eight Networks

RIPEstat's announced-prefixes response contained 38 IPv4 route observations for AS52426 at capture time. The list includes aggregates and more-specific entries. Counting every row as an independent network, service area or physical system would therefore overstate what the data shows. An aggregate and its more-specifics can coexist for several reasons. Operators may use more-specific routes for traffic engineering, selective upstream announcements, mitigation or routing policy. A /20 can contain multiple /24s, and the table may expose several of them alongside the covering aggregate.

The route count describes entries in a routing view, not independent cables or customer markets.

The same caution applies to failure analysis. If an aggregate and several more-specifics disappear together, they may share an origin-side failure. If only one more-specific changes path, the cause could be policy, maintenance or a localized issue. Without time-series evidence and network context, a static list cannot identify the failure mechanism.

Route observations also depend on collection. RIPE RIS receives routes from participating peers, and the resulting data is broad rather than universal. A route may be visible to one collector peer and not another because of policy or session state. A captured list is a dated view of public control-plane propagation, not a complete inventory of every route available to every network.

For I-SUR, the 38 entries are still meaningful. They show that AS52426 is not merely reserved in a registry; it is used as an origin across a non-trivial set of public IPv4 announcements. The data can support questions about aggregation, authorization and change. It cannot support claims about 38 facilities, 38 customer groups, 38 access zones or 38 physically diverse paths. Maintaining this distinction is essential for infrastructure accuracy. Logical multiplicity can be created through configuration. Physical diversity requires separate evidence about ducts, poles, radio paths, buildings, power feeds and upstream handoffs.

The route table alone cannot supply it.

5. Broad Collector Visibility Demonstrates Running Code

The reviewed routing-status response reported 8,192 announced IPv4 addresses and visibility from 329 of 330 observed IPv4 RIS peers. This is a strong public-routing signal within the captured measurement system. Routers were propagating AS52426-originated reachability widely enough to appear across almost the entire reviewed peer set.

The numerator and denominator need a scope label. They refer to RIS peers participating in the observation, not to all autonomous systems, all I-SUR customers or all Internet users. Collector sessions, route filtering and feed types differ. A route's presence at a collector does not guarantee that every destination inside the prefix responds or that every access subscriber can reach the Internet. Likewise, the one peer without the route is not evidence of an outage. It could reflect ordinary policy, a partial feed, filtering, a session condition or a measurement timing difference.

Diagnosing the cause would require peer-specific and time-series information. The captured aggregate statistic cannot assign one.

What the measurement does establish is running-code participation. AS52426 was visible as an origin in the public control plane, and the visibility was broad in the reviewed snapshot. This is stronger operational evidence than an allocation record alone because it reflects configured routing behavior received by other networks.

Running code remains a narrow kind of truth. It shows that routing policy was being executed. It does not show how customer traffic entered the network, where packets crossed a physical boundary, or whether the access layer was healthy. A route can be visible while a local segment is congested or disconnected. A customer can have service trouble while global BGP remains unchanged.

The visibility figure is therefore best used as a baseline. Future observations can show whether the ASN remains broadly visible, whether prefixes change, and whether path diversity shifts. The snapshot should not be converted into an uptime percentage or a promise of continuous reachability.

6. RPKI Validity Answers One Security Question

The representative 138.0.56.0/22 aggregate validated as RPKI-valid for origin AS52426. The relevant route-origin authorization permits more-specific announcements through a maximum length of 24. That configuration can cover the /22 and authorized /23 or /24 announcements under the same origin, while excluding longer prefixes under that authorization. This is a valuable security result. RPKI gives networks a cryptographically verifiable statement about which ASN is authorized to originate a prefix at a permitted length. A validating operator can use the result to reject routes that conflict with the authorization. The mechanism reduces ambiguity around accidental or unauthorized origin changes.

Validity does not mean that the route is continuously available. A valid ROA can exist while the prefix is withdrawn, filtered or unreachable. RPKI does not test latency, packet loss, access equipment, DNS, customer authentication or power. It says nothing about whether every network performs route-origin validation or applies identical policy.

The representative result also should not be generalized to every I-SUR route. The checked aggregate is valid for AS52426 under the observed authorization. Other prefixes and more-specifics require their own origin, length and authorization comparison. A single clean result demonstrates an aligned control surface, not universal routing hygiene. Maximum length deserves attention because it encodes policy. An authorization for only the /22 would not validate a /24. Allowing through /24 records a deliberate range of acceptable announcement lengths.

That flexibility can support operational routing, but it also increases the set of announcements that count as authorized. Neither choice reveals why particular routes are used.

For the reviewed aggregate, three layers align: LACNIC identifies the holder, RPKI authorizes the origin-prefix relationship, and routing collectors see AS52426 in active announcements. That alignment is evidence of coherent number-resource control. It remains separate from physical ownership, customer service and resilience.

7. No Reviewed IPv6 Evidence Is Not a Verdict on IPv6

The accepted evidence did not establish a current IPv6 allocation or visible IPv6 route for this exact company identity. RIPEstat's captured routing status reported no visible IPv6 prefix for AS52426. Those are limitations of the reviewed public record, not proof that I-SUR has no IPv6 resources, private deployment or customer service.

Absence claims require special caution in network research. A resource might appear under a different organization record, a related network or a later registration. An announcement might be private, narrowly propagated, newly created or temporarily withdrawn. Collector data can show what it received; it cannot prove that no configuration exists outside the observation.

The safe baseline is therefore asymmetric. Public IPv4 evidence is strong: allocations are identified, routes are visible and a representative authorization is valid. The same reviewed set does not provide an equivalent IPv6 chain. That difference can be monitored without assigning a cause. If AS52426 later announces IPv6 publicly, the transition will create several testable questions. Which prefix is originated? Which registry entity holds it? Is there a matching route-origin authorization? How broadly is it visible? Does the first-party service description change? None of those future facts should be presumed today.

An IPv6 gap also cannot be translated into a service-quality judgment. Customers may receive IPv4-only service, dual-stack service through another arrangement, or no service from the company at all; the public records do not resolve the question. Active measurements and explicit operator documentation would be needed for a customer-facing conclusion.

Keeping the baseline precise makes future change more informative. "No visible IPv6 in the reviewed snapshot" can be tested again. "I-SUR has no IPv6" is a broader claim the evidence cannot support.

8. PeeringDB Is Useful Because It Disagrees with Current Routing

The captured PeeringDB record maps AS52426 to I-SUR WISP S.R.L., but its last update was in July 2022. It reports zero IPv4 and zero IPv6 prefixes, gives no traffic level or geographic scope, marks the general peering policy as open, and lists no captured exchange or facility attachment. Those fields are self-reported and stale relative to the RIPEstat observations. Current collector data clearly shows IPv4 routes from AS52426, so a zero-prefix PeeringDB field cannot be treated as a current routing inventory. The mismatch is not necessarily an error in routing. It may simply reflect a profile that was never refreshed.

This is precisely why multiple public systems should be compared. A directory record helps bind identity. RDAP records number-resource administration. BGP collectors expose running routes. RPKI records origin authorization. PeeringDB provides operator-supplied interconnection context. None should silently overwrite the others.

The open-policy field also needs restraint. It expresses a stated general posture, not a guarantee that any applicant will receive a session. Technical requirements, traffic ratios, port availability, location and commercial terms can still matter. The captured record does not provide a current agreement or active session list. The absence of listed facilities or exchanges should not become a claim that I-SUR has none. The record may be incomplete, stale or intentionally sparse. Conversely, a listed facility would not by itself prove an active physical port or independent path. Facility and exchange fields require current confirmation.

For operational continuity, stale interconnection metadata is itself a signal. Networks trying to coordinate may find the routing system active while the voluntary profile lacks current scope. The remedy is accurate metadata and direct verification, not an invented topology. The discrepancy supports a narrow question about observability: which public layer should a peer trust for which purpose?

9. First-Party Service Language Establishes a Customer Context

I-SUR's privacy notice names the legal entity as I - SUR WISP S.R.L. and provides an operating address in Monte Grande. It describes services that include wireless Internet and fibre-optic connectivity. It also refers to installation data, maintenance communications, customer support and regulatory obligations.

This first-party text supports a bounded present-day service identity. It shows that the organization presents itself as handling customer relationships around Internet access and connectivity. References to installation and maintenance indicate an operational service context rather than a registry-only shell. The notice does not provide a network map. It does not identify every service area, radio site, fibre route, upstream handoff or customer-premises device. It does not distinguish owned infrastructure from leased, shared or contracted infrastructure. Privacy language is written to explain data handling, not to prove physical topology.

Nor does the service description establish performance. Words such as wireless and fibre identify access technologies, but they do not disclose speed, contention, capacity, availability or restoration targets. A fibre product can depend on shared backhaul and power. A wireless link can depend on site access, spectrum conditions and line of sight. The page does not quantify those dependencies.

The operating address should be treated as a contact or business location, not automatically as a network facility. An address can host administration, support or another function without containing core routing equipment. No accepted evidence establishes a data centre, tower, exchange or fibre node at that location.

The page is most useful when paired with the routing record. The company describes a customer-access business, while AS52426 supplies a visible public routing identity. The connection makes a legitimate infrastructure question possible: how does the documented number-resource surface relate to the access service customers experience? The public record answers only the first half.

10. Argentina's Framework Separates Service Authorization from Asset Ownership

ENACOM Resolution 2483/2016 describes Internet access service in terms broad enough to include fixed or mobile, wired or wireless, national or international provision. Crucially, the framework states that service may be provided with or without the provider's own infrastructure. That distinction prevents a common leap from regulatory status to physical ownership. Authorization to provide a service is not evidence that I-SUR owns poles, towers, ducts, fibre, backhaul, upstream circuits or customer equipment. A provider can combine owned, leased, wholesale and shared components. Each asset boundary requires separate evidence.

The framework also distinguishes a general service registration from other permissions that may be needed for spectrum or numbering. A broad Internet access authorization should not be used to claim rights over a particular frequency, route, site or number resource. Those controls live in their own records and procedures. The reviewed resolution supplies a legal boundary rather than a current company-specific licence determination. It explains what the regulatory category can encompass. It does not by itself prove I-SUR's present standing, the exact scope of any authorization, or compliance at a particular date.

A current licence claim would require a specific company record.

This separation mirrors the technical evidence. The ASN and prefixes show a number-resource and routing role. The first-party page shows a customer-service identity. The regulation explains that service can exist without ownership of all physical infrastructure. Together they make it unsafe to draw a company-owned network map from those facts. For dependency analysis, the implication is practical. If some infrastructure is leased or supplied by another operator, failures and restoration authority may cross company boundaries. If infrastructure is owned, power, spares and field access still matter.

The public evidence does not choose between these models, so resilience cannot be scored from ownership assumptions.

11. The Physical Access Layer Remains the Largest Unknown

Wireless Internet and fibre connectivity both depend on physical systems. A wireless access network may require powered sites, backhaul, mounting rights, spectrum coordination and customer equipment. Fibre service may require ducts or aerial routes, splitters, cabinets, optical line terminals, splicing capacity and rights of way. None of those components is identified in the accepted evidence.

The absence matters because the access layer often determines customer experience. Global routes can remain stable while a local power failure disables a radio or cabinet. A backhaul cut can isolate an area without changing the origin ASN. A damaged drop can affect one customer while every monitoring collector still sees the aggregate route.

Capacity also cannot be inferred. Address space does not reveal bandwidth. Prefix count does not reveal port utilization. A fibre service description does not reveal whether capacity is designed, installed, lit, sold or usable at a congested hour. A wireless service description does not reveal channel width, sector load or backhaul constraints.

Ownership is equally unresolved. I-SUR may own some assets, lease others, buy wholesale connectivity or share infrastructure. The regulatory framework explicitly allows provision without wholly owned infrastructure. A correct dependency map would need contracts, permits, asset records or precise first-party disclosures that are not present here.

Physical diversity cannot be derived from logical routes. Multiple prefixes can leave through one cable. Multiple upstream AS paths can converge on one building or power feed. Conversely, one visible path can ride resilient infrastructure. Redundancy becomes credible only when failure domains and independent recovery routes are documented.

The public record therefore supports a real network identity while leaving the access system opaque. That is not a reason to dismiss the routing evidence. It is a reason to state exactly what the routing evidence can and cannot protect when a physical fault occurs.

12. A Single Observed Neighbour Does Not Prove a Single Uplink

The captured routing-status data reported one observed neighbour for AS52426. An observer might be tempted to convert that number into a claim that I-SUR has only one upstream. The dataset does not support that conclusion. Observed neighbour counts depend on the routes and collector views available at the captured time. Private interconnection, routes not propagated to the collector set, backup sessions, Internet exchanges and selective policies may be absent from the observation. A commercial relationship can also exist without appearing as a distinct public path in one snapshot.

The inverse is also true. Multiple visible neighbours would not automatically prove physical redundancy. Sessions can share a facility, duct, power source or upstream parent. Logical diversity is useful, but resilience requires evidence that the paths do not fail together.

For I-SUR, the one-neighbour observation is best treated as a monitoring question. Future snapshots can show whether additional adjacencies appear, whether path structure changes, and whether route visibility depends heavily on one visible relationship. Direct technical documentation would still be needed to describe primary and backup arrangements. Contracts remain hidden. A BGP adjacency does not reveal price, committed capacity, service-level terms or restoration priority. It also does not identify who owns the circuit between networks. Public path data exposes interdependence without disclosing its commercial or physical implementation.

This is where cautious infrastructure analysis becomes more useful than a simple topology label. The evidence shows that AS52426's public routes reach collectors through a limited visible control-plane context. It does not show that the customer service has one failure path, nor does it prove an independent alternative. Both resilience and fragility remain unverified.

13. Contact Metadata Is Part of Network Continuity

The LACNIC records expose administrative, technical and abuse-contact roles associated with the network resources. Those roles matter when another operator needs to coordinate a route correction, investigate harmful traffic or confirm a legitimate change. Accurate contact metadata can shorten the time between detection and action.

Registry contacts do not guarantee response. A mailbox can be stale, a person can change role, and an organization can route requests through internal systems not visible publicly. The record establishes a formal escalation surface, not an around-the-clock support commitment. The distinction is important during an origin incident. If a prefix appears under an unexpected ASN, networks may examine RDAP and RPKI before deciding how to filter or whom to contact. A valid authorization can resolve part of the ambiguity. A responsive technical contact can resolve operational questions that the cryptographic entity cannot.

Abuse contacts carry a different workload. They receive reports that may range from actionable evidence to automated noise. Effective handling requires triage, context and authority. Public registration makes coordination possible, but it does not expose staffing, response time or enforcement quality.

Continuity also includes organizational change. An ASN and address block can persist while personnel, vendors or ownership arrangements evolve. Registry records should continue to point to responsible parties. The 2025 last-change timestamp shows that the AS entity was updated, but the public response does not explain whether every operational dependency was reviewed at the same time.

For a regional provider, contact quality can be as consequential as configuration quality when failures cross company boundaries. Yet it should remain a separate claim. The evidence shows recorded roles. It does not prove that escalation is immediate, that restoration authority is concentrated in one team, or that every published contact points is currently monitored.

14. Route Authorization and Service Availability Can Diverge

RPKI, BGP and customer service operate on different clocks. A route-origin authorization may remain unchanged for months or years. BGP paths can change in seconds. A local access failure can begin and end without any public route change. Treating one layer as a health check for all the others creates false confidence. Consider a power loss at an access node. If the core and upstream edge remain active, AS52426's routes may continue to look normal to collectors. Customers behind the failed node may still lose service. The public route table would not identify the affected streets, customers or equipment.

An upstream event can produce the opposite pattern. A broad route withdrawal may make the ASN disappear from many views even though local access equipment remains powered. Customers may retain local connectivity but lose external reachability. Restoration then depends on the upstream relationship, routing configuration and available alternatives. A route leak or unauthorized origin has another signature. RPKI can help networks identify conflicting authorization, but filtering adoption and policy determine the real effect. A valid ROA does not prevent every mistake. It gives participating networks better data for automated decisions.

Congestion can occur with all routes present and authorized. Nothing in the checked data measures throughput, queueing, packet loss or peak-hour headroom. The route table says where prefixes are reachable in policy terms, not how well traffic flows.

The practical lesson is that resilience claims need failure-path evidence. I-SUR's visible routes and valid representative authorization are positive control-plane facts. They should not be used to assert power resilience, access diversity, spare capacity or restoration speed. Those properties require records tied to the physical and organizational systems that would respond.

15. Customers Depend on Boundaries the Public Record Does Not Show

I-SUR's first-party language places customers inside the operational picture. Installation data, maintenance communications and support obligations imply a service relationship with endpoints beyond the public routing edge. The path from those endpoints to AS52426 is the critical missing layer.

A customer connection can cross several boundaries: premises equipment, a wireless or fibre access segment, aggregation, backhaul, an edge router and one or more upstream networks. Power and maintenance authority may change at each step. A failure can be local, shared across a neighbourhood, or broad enough to affect the origin routes. The public evidence does not identify which parts I-SUR controls directly. It does not show whether access plant is owned, leased or shared, whether field work is internal or contracted, or whether upstream capacity has a physically independent backup. Those unknowns limit any prediction about failure impact.

They also limit geographic claims. An operating address in Monte Grande and a service description do not define a coverage polygon. Wireless signals and fibre routes cannot be reconstructed from a privacy notice. A directory country field does not prove that every routed address serves users in one place.

For customers, the most useful unanswered questions are concrete. Which failure domains can disconnect multiple access areas at once? Which sites require backup power? Where does traffic cross into another operator's control? What restoration targets exist? Are alternative paths physically separate? The reviewed sources do not answer them.

The route baseline still helps during an incident. If AS52426 remains visible, investigation can focus below or beside the public edge. If the routes disappear broadly, the origin or upstream layer becomes a stronger suspect. That diagnostic value is real, even though it does not replace access-network telemetry.

16. What Can Be Monitored Without Inventing Topology

Several public indicators can be tracked over time. The set of AS52426-originated prefixes can change. Collector visibility can rise or fall. A new neighbour can appear in public paths. RPKI states can change if authorizations are added, removed or given different maximum lengths. RDAP contacts and last-change timestamps can be compared. Each indicator needs a baseline and timestamp. A route list from one day should not be described as permanent. A peer count should retain its measurement scope. A PeeringDB profile should retain its update date. A first-party page should be archived or checked again before its language is treated as current.

Changes also need interpretation. A new more-specific route can be traffic engineering rather than expansion. A withdrawn aggregate can be maintenance rather than collapse. A new ROA can improve authorization hygiene without changing customer service. A different contact can be administrative housekeeping rather than a change in network control.

Combining the layers creates stronger questions. If routes change but RDAP and RPKI do not, what operational policy changed? If a new allocation appears without a route, is deployment pending? If PeeringDB remains stale while BGP grows, is coordination metadata lagging? The evidence can frame inquiry without supplying an unsupported answer. Physical and service monitoring would require additional data. Facility records, permits, network diagrams, outage notices, active measurements and direct operator confirmation could narrow the unknowns. None should be inferred from the ASN alone.

This restrained monitoring model follows the systems that actually run. Registries record responsibility. RPKI records authorized origin policy. BGP exposes propagated routes. Customer service depends on physical and organizational layers beyond them. Keeping those roles distinct makes every later change easier to evaluate.

17. The Strongest Finding Is the Boundary

AS52426 gives I-SUR WISP S.R.L. a verifiable public routing identity. LACNIC binds the organization to the ASN and IPv4 resources. RIPEstat shows active IPv4 announcements and broad collector visibility. The representative 138.0.56.0/22 authorization is valid for origin AS52426 through /24. These are specific, testable facts. The company also describes wireless Internet and fibre-optic connectivity. That connects the routing identity to a customer-access context, but it does not disclose the network between them. Argentina's regulatory framework reinforces the uncertainty by allowing Internet access provision with or without the provider's own infrastructure.

The boundary is therefore not a weakness in the analysis. It is the central result. Number-resource control is visible; physical access ownership is not. Route authorization is visible; usable capacity is not. Broad BGP visibility is visible; customer availability is not. Service language is visible; redundancy and recovery design are not. This separation protects against two opposite errors. The first is to dismiss registry and routing evidence as merely administrative, even when routers are actively originating the resources. The second is to turn that evidence into an imagined physical network with unverified assets and performance.

I-SUR can be monitored responsibly without either error. Future public routes, authorizations and registry changes can be compared with the captured baseline. More precise infrastructure claims should wait for evidence about assets, handoffs, power, maintenance and failure paths.

For peers and responders, the current record identifies a number-resource holder and a routing origin. For customers, it leaves the access system largely opaque. The most accurate conclusion is not that the network is resilient or fragile. It is that the public control plane is observable while the physical delivery boundary still needs proof.

18. Evidence That Would Close the Delivery Gap

The next useful evidence would identify control boundaries rather than add more general service language. A current network diagram with a clear scope could show where I-SUR's responsibility begins and ends, provided that logical links are not mistaken for physically independent routes. Facility and circuit records could then test whether apparent path diversity survives a common duct, building or power dependency.

Asset ownership records would answer a different question. They could distinguish company-owned fibre or radio equipment from leased access, wholesale capacity and shared infrastructure. That distinction affects who can authorize repairs, who holds spares, and which organization sets restoration priorities. It should be documented asset by asset rather than inferred from the provider's name.

Power evidence would make resilience claims more concrete. A list of critical powered sites, backup duration, refuelling arrangements and alarm coverage could reveal whether routing equipment and access nodes fail together. Even that would need a date and operating scope. Installed batteries or generators are not equivalent to tested autonomy under load.

Upstream and interconnection evidence could clarify the one-neighbour snapshot. Current session records, exchange ports, circuit diversity and physically separate entrances would help distinguish policy diversity from shared failure domains. Commercial details need not be public for the physical and operational boundary to be verified, but a route path alone cannot supply it.

Outage notices and restoration records would provide the strongest test of continuity. They could show which components failed, what customers experienced, whether global routes changed, which organization performed the repair, and how long restoration took. Repeated events would be more informative than a single availability claim because they expose the system's actual recovery behavior.

Customer-facing measurements could close another part of the gap. Dated latency, loss, throughput and reachability tests across defined service areas would reveal conditions that BGP collectors cannot see. They would still need careful sampling and should not be generalized beyond the tested connections.

Until such evidence appears, the public number-resource record remains the reliable baseline. It identifies I-SUR, AS52426, the reviewed IPv4 allocations, observed routes and a valid representative origin authorization. Every stronger physical or service claim should be tied to a source that directly observes the relevant asset, contract, measurement or failure path.

Sources