Summary

  • LACNIC binds Jose Luis Zurakouski and registrant handle AR-JLZM-LACNIC to AS263823, IPv4 allocation 138.219.216.0/22 and IPv6 allocation 2803:1a40::/32.
  • RIPEstat's 27 July 2026 snapshot showed AS263823 to 328 of 330 checked IPv4 peers and 323 of 324 checked IPv6 peers, a strong control-plane observation rather than an uptime or service-coverage measure.
  • The checked pairs AS263823 plus 138.219.218.0/23 and AS263823 plus 2803:1a40:2000::/36 were RPKI-valid at the captured snapshots, but those two checks do not establish universal route authorization.
  • Public evidence identifies a real regional ISP control surface while leaving physical plant, commercial relationships, capacity, customer reach, resilience and operational continuity unproved.

1. An Exact Name Creates a Defensible Starting Point

Network research often begins with a brand and then struggles to determine which legal person or company sits behind it. This case begins from the other direction. The public directory names Jose Luis Zurakouski together with the trading identity MIX SERVICIOS & COMUNICACIONES. LACNIC's registrant record uses the same personal name and associates it with handle AR-JLZM-LACNIC. That exact-name continuity is stronger than a similarity inferred from a logo, abbreviated business name or search result.

The distinction is especially important because the directory name contains both a person and a commercial presentation. Public routing systems usually attach resources to a registrant, organization or administrative contact; they do not explain every relationship between an individual, a trading name and a legal vehicle. The exact name supports the resource connection. It does not settle every corporate-law question about ownership, capitalization or authority to contract.

The directory route and its public API also present slightly different slug forms. One includes the conjunction and country suffix, while the other uses a shorter source-side form. That difference is a canonical-link question, not evidence of two networks. Readers should be taken to the existing directory identity, but the variation should not be silently converted into a claim that every naming layer is identical.

LACNIC's records supply the durable technical join. The same registrant handle appears on AS263823 and on the associated IPv4 and IPv6 allocations. A future brand change or website redesign would not erase that historical resource connection. Conversely, the connection does not prove that every customer-facing service, asset or contract uses the MIX name.

The resulting boundary is precise. Jose Luis Zurakouski is the named holder behind a specific autonomous system and two registered address-resource ranges. This provides a credible accountability anchor. It does not prove the legal form of the trading operation, the ownership of physical infrastructure or the scope of services offered to customers.

2. AS263823 Is a Routing Identity, Not a Coverage Claim

An autonomous-system number labels an administrative routing domain. AS263823 allows route collectors, counterparties and network operators to associate public prefix origins and paths with a stable identifier. It is therefore a meaningful part of the operating surface: routing changes can be observed over time, filters can be written against the origin and security metadata can refer to the same number.

That usefulness should not be expanded into a geographic claim. An ASN does not enumerate homes passed, municipalities served, business districts connected or towers operated. It does not state whether the access network is fibre, fixed wireless, leased transport, cable, another technology or a mixture. The number remains the same even if the underlying service footprint changes.

AS263823 also does not prove independence from other networks. A regional provider can control its public routing policy while buying transport, upstream connectivity, facilities, power, maintenance or customer access from third parties. Such arrangements can be economically sensible and operationally sound. They simply sit outside what the ASN itself reveals.

The number is best treated as a handle for disciplined questions. Which prefixes are expected to originate there? Which route-origin authorizations cover them? How are changes reviewed? Which external networks appear next to it in observed paths? What happens to public reachability if one dependency fails? Those questions attach to a real control point without pretending that the answers are already public.

Registration for AS263823 dates to 17 August 2015. That date marks the creation of the number-resource record, not the commercial launch of every service now associated with MIX SERVICIOS & COMUNICACIONES. A registered date should not be rewritten as an operating-history milestone unless additional business evidence supports it.

3. The IPv4 /22 Defines an Administrative Resource Boundary

LACNIC assigns 138.219.216.0/22 to AR-JLZM-LACNIC. The range runs from 138.219.216.0 through 138.219.219.255 and contains 1,024 IPv4 addresses. This is a direct registration fact. It identifies a bounded resource under the same name and handle as AS263823.

The allocation size is not a subscriber count. Addresses can support infrastructure, customer assignments, dynamic pools, shared translation, management systems, servers, reserves or other uses. A single customer may receive several addresses, while many users may share one public address. The registry does not disclose allocation policy inside the block.

Nor does the /22 reveal geography. IP geolocation can reflect registration data, an egress point, inferred measurements or commercial databases. Even an accurate city label for an address does not establish that the provider sells service throughout that city. No public route record turns the /22 into a serviceability map.

The block can still matter economically. Directly registered IPv4 space may reduce dependence on addresses supplied by an upstream provider and can make some network transitions less disruptive. Its practical value depends on routing, reputation, utilization, operational competence and contractual conditions. Those variables are not visible from the allocation alone.

The routing evidence adds an operational layer. RIPEstat saw IPv4 routes originated by AS263823 during the captured interval and reported broad peer visibility at the snapshot. This means the allocation was not merely an administrative entry in the checked view. It still does not show which addresses were in use, which products depended on them or what service a customer received.

4. The IPv6 /32 Signals Addressing Capacity, Not Market Scale

The same registrant holds 2803:1a40::/32. At the number-resource layer, this gives AS263823 a coherent dual-stack identity. IPv6 design intentionally provides large hierarchical spaces so networks can delegate prefixes without reproducing IPv4 scarcity. The presence of a /32 is therefore operationally significant but easy to misinterpret.

A /32 can be divided into many /48 or /56 customer and infrastructure networks. That mathematical possibility does not show that those delegations exist. It does not measure customer adoption, router readiness, application compatibility or help-desk capability. Address-space scale and commercial deployment scale are different quantities.

RIPEstat did observe IPv6 routes under AS263823, so the allocation has a visible control-plane expression in the captured data. The routing-status response summarized two visible IPv6 route records and broad visibility across checked peers. This is stronger evidence than registration alone because it reflects running routing state at a stated time.

Even a visible IPv6 origin leaves the delivery layer open. Customers may or may not receive native IPv6. Delegated prefix sizes, prefix stability, customer-premises equipment, firewall defaults, DNS behaviour and support policy determine whether IPv6 is useful in practice. None of those product details is supplied by the route table.

The most defensible statement is that MIX SERVICIOS & COMUNICACIONES has a registered IPv6 /32 with current public routing visibility through AS263823. Describing the business as universally IPv6-enabled, or inferring an extensive customer footprint from the allocation size, would move beyond the evidence.

5. A Dated Snapshot Shows Broad Dual-Stack Visibility

At the 27 July 2026 routing-status snapshot, RIPEstat reported AS263823 visible to 328 of 330 checked IPv4 RIS peers and 323 of 324 checked IPv6 peers. Those ratios show broad visibility from the collector set. They are a useful baseline for assessing whether the ASN and its routes were generally observable in the public control plane.

The numbers are not a service-level agreement. A collector peer can see a route while customer traffic fails because of access equipment, transport, power, congestion, DNS or application problems. The reverse can also occur: a route may be absent from selected collectors while a private or regional path continues to carry traffic for a limited set of users.

Collector scope matters. RIS offers extensive but finite observation. Its peers are not every network, and paths can change between queries. A result from one timestamp should travel with its date and vantage point. Calling the network globally reachable without qualification would be broader than the measurement.

The small gap from complete visibility is likewise not an incident report. Two checked IPv4 peers and one checked IPv6 peer did not see the ASN in the summarized result, but the response does not explain why. Filters, session state, topology, timing or collector-specific conditions can all influence visibility. No customer impact follows automatically.

What the snapshot provides is a repeatable monitoring reference. A later observation can be compared with 328/330 and 323/324. A large change would justify investigation; a stable result would show continuity at the control-plane layer. Neither outcome should be converted into a broader assurance about physical or commercial service without corroboration.

The visibility ratios can also help separate a route-origin problem from a narrower reachability complaint. If the same prefixes remain visible across almost all collector peers while one customer reports loss of service, investigators would still need to examine access, local transport, power, addressing, DNS and application state. If the routes disappear from a large part of the collector set, the public control plane becomes a more plausible part of the failure path. Neither pattern identifies the cause on its own, but the distinction prevents a local symptom from being described as an Internet-wide routing event.

Time resolution deserves equal care. A snapshot records one checked state, while short withdrawals and reconvergence can occur between observations. Continuous telemetry, operator logs and active measurements would be needed to establish duration. The public result is therefore strongest as a dated anchor: it shows broad dual-stack visibility at one moment and creates a benchmark for future comparisons without pretending to be a complete availability history.

6. Overlapping Routes Must Not Be Counted as Extra Networks

The announced-prefix response contains multiple IPv4 and IPv6 route records associated with AS263823. Several are more-specific routes inside the registered allocations. The IPv4 list includes /23 and /24 records within 138.219.216.0/22, while the IPv6 list includes /36 records within 2803:1a40::/32.

These entries overlap. Adding the nominal address count of every record would count the same registered space more than once. A /24 inside a /23 does not create another independent allocation, and a /36 inside a /32 does not add a new pool outside the parent. The registry boundaries remain the /22 and /32.

More-specific routes can serve many legitimate purposes. Operators may use them for routing policy, traffic engineering, segmentation, supplier constraints, mitigation or staged changes. The route table does not disclose which purpose applies here. Assigning intent from prefix length alone would be speculation.

Route count also has no direct conversion to physical scale. Six visible IPv4 route records do not prove six sites, six access areas or six redundant paths. Two visible IPv6 records do not establish two regions or two independent networks. A single router can originate several records, while one route can represent traffic connected through multiple physical locations.

The safe use of this data is observational. The exact prefixes, origin and dates can be recorded, monitored and compared. A covering route withdrawal or origin change may matter. Its operational meaning still requires information about topology, contracts, facilities and customer dependencies that BGP does not contain.

7. Visible Address Space Is Not Utilized Address Space

RIPEstat summarized the visible IPv4 routes as covering 1,024 addresses, which matches the size of the registered /22 after overlapping routes are treated correctly. For IPv6 it expressed the visible footprint as 8,192 /48 equivalents. These figures describe routed address-space scope in the selected view.

They do not show utilization. An announced IPv4 address may be unused, reserved, dynamically assigned or shared across many users. An IPv6 /48 equivalent can remain unassigned or support a single site. Public BGP does not reveal endpoint counts or allocation efficiency.

The distinction matters in market analysis. Resource holdings can create operating options, but they do not prove revenue, subscribers or network growth. A provider with a modest customer base may hold a large address resource for orderly design, while a larger provider may rely heavily on shared addressing or supplier resources.

Visible scope also does not identify the product mix. Residential access, business connectivity, infrastructure addresses and hosted services can share the same origin. No route record labels which addresses support which commercial use. Product claims need attributable service material or direct measurement.

For diligence, the address-space figures are useful as upper-level boundaries. They establish what is publicly originated under AS263823 at the captured time. Any claim about deployment inside those boundaries should be supported independently rather than inferred from the size of the routed space.

8. Two Checked RPKI Results Add Narrow Security Evidence

Two origin-prefix pairs were checked against RIPEstat's RPKI validation service. AS263823 plus 138.219.218.0/23 returned valid. AS263823 plus 2803:1a40:2000::/36 also returned valid. These results show that the selected origins were consistent with published route-origin authorizations at the captured snapshots.

The IPv4 result was supported by an exact authorization for the /23 and by a parent authorization covering 138.219.216.0/22 with a maximum length of /24. The IPv6 result was supported by an authorization for 2803:1a40::/32 with a maximum length of /48. Those parameters explain why the checked more-specifics could validate.

RPKI validation addresses one part of routing security: whether an announced origin and prefix length match authorization metadata. It does not verify the AS path, protect router sessions, prove traffic delivery or prevent operational mistakes. A valid route can still encounter leaks, configuration errors, congestion or physical failures.

The checks are also not an exhaustive audit of every visible route. The data supports two exact results. It should not be generalized into a claim that every current and future route under AS263823 is authorized. A complete assessment would enumerate all observed origins and more-specifics at the relevant time.

Even with that limit, the valid results improve the evidence. They show that selected IPv4 and IPv6 announcements had corresponding security metadata rather than being treated as valid merely because collectors saw them. The correct language is narrow: two checked pairs were RPKI-valid at the captured time.

The selected pairs are useful because they test more-specific routes rather than only the parent allocations. The IPv4 /23 sits within the registered /22, and the IPv6 /36 sits within the registered /32. A valid result confirms that the published maximum-length rules allowed those more-specific origins at the captured time. It does not establish why the operator chose those prefix lengths or whether every other visible more-specific had the same state. That remaining inventory question should stay explicit rather than being hidden behind a network-wide label.

9. Valid RPKI Does Not Equal End-to-End Security

It is tempting to turn a valid RPKI result into a general security endorsement. That would collapse several separate layers. Route-origin authorization helps networks reject announcements whose origin or prefix length conflicts with published metadata. It does not assess the company, its access network or its overall security posture.

An attacker or operator error can affect systems beyond origin validation. Compromised customer credentials, DNS manipulation, route leaks with an authorized origin, equipment failure, software defects and physical cable damage sit outside the narrow ROA check. Security claims need evidence matched to the mechanism being discussed.

Operational continuity also depends on whether other networks perform route-origin validation and how they handle invalid routes. A valid authorization is useful metadata, but its protective effect emerges through deployed policy across many autonomous systems. The public query does not describe each counterparty's filtering behaviour.

Authorization records require maintenance. Prefix plans and origins can change; stale or overly broad records may reduce clarity. The captured result cannot establish the quality of the operator's change-management process. It only shows that the selected current pair matched available authorization data.

For customers and partners, this still creates a concrete question set. Which routes are covered? Who owns updates? How are planned origin changes coordinated? What monitoring detects invalid or unexpected announcements? Public data makes those questions more informed without pretending that their operational answers are known.

10. Observed Neighbours Are Clues, Not Contracts

RIPEstat's path observations placed AS263774, AS265828 and AS266668 immediately to the left of AS263823 in sampled routes. The observation identifies autonomous systems that appeared adjacent in the collector data. It does not identify the commercial terms or physical arrangements behind those adjacencies.

An adjacent ASN may represent transit, peering, a customer relationship, a route-server effect or another topology. The same path position can arise from different agreements. Public BGP does not reveal price, committed capacity, contract duration, exclusivity, support obligations or the legal parties to a service.

Adjacency also says little about physical diversity. Several autonomous systems can interconnect in one building or depend on one conduit and power domain. One commercial relationship can use multiple independent handoffs. AS-path diversity and physical-path diversity should never be treated as equivalent without facility and transport evidence.

The three observations are therefore monitoring leads. Future path changes could show one neighbour disappearing, another appearing or a different origin pattern. Such changes might justify questions about routing policy or dependency, but they would not by themselves explain cause or customer impact.

Calling any of the observed neighbours a confirmed upstream, resilience provider or commercial peer would exceed the evidence. The bounded statement is sufficient: three left-side adjacencies appeared in sampled paths, and their business and physical meanings remain unproved.

11. PeeringDB Adds Operator-Maintained Context

PeeringDB maps ASN 263823 to MIX SERVICIOS & COMUNICACIONES and classifies the network as Cable/DSL/ISP. It also supplies self-reported policy and regional fields. This is useful because it connects the routing identifier to an operator-maintained description rather than relying only on third-party inference.

Self-reported data needs the right weight. PeeringDB entries are designed to help networks coordinate interconnection, but they are not independent audits of traffic, customers, facilities or quality. A classification can clarify intended operating context without proving the current commercial footprint.

An open peering-policy field, for example, does not guarantee that every request is accepted or that a physical interconnection exists in a particular location. Technical, traffic, contractual and facility requirements can still apply. The record should not be transformed into a promise of universal interconnection.

Likewise, prefix counts in an operator-maintained record can differ from a dated collector view because each source serves a different purpose and may update at a different time. The authoritative registry, current routing observations and operator-maintained profile are best kept as separate layers.

PeeringDB strengthens the identity and ISP-context story. It does not supply a service map, an independent capacity measurement, exchange participation proof, facility inventory or market-size estimate. Those absent facts remain absent.

Operator-maintained records can nevertheless improve accountability when treated as declarations rather than measurements. They provide a place where the network can state its identity and interconnection posture in terms familiar to technical counterparties. If those fields change, the change can be compared with routing and registry observations. Agreement across the three sources raises confidence in the public identity; disagreement would identify a specific item to verify. This comparative use is more defensible than treating any single profile as comprehensive.

12. The Timed-Out Website Cannot Carry Factual Weight

The website listed in the operator-maintained record did not return usable content during the bounded check. A timeout is not evidence that the business is inactive, and it is not proof of an outage affecting customers. It is simply a failed attempt to retrieve one public page.

The site therefore contributes no claims about products, coverage, access technology, published contact points or operating history. Repeating cached search snippets or inferring services from a domain name would weaken the evidence. The network-resource thesis does not require that rescue because LACNIC and routing data already establish the technical identity.

Website reachability and network reachability are different layers. A company site may be hosted by a third party, misconfigured or temporarily unavailable while the ASN continues to originate routes. Conversely, a functioning marketing site says little about customer connectivity. Neither state should stand in for the other.

The missing page does leave practical questions. Customers may need a verified service description, support route, legal notice or contact method. A later company-controlled page could clarify the trading identity and products, but it would still require separate verification for physical and performance claims.

Excluding the timeout keeps the record honest. The evidence remains strong where public systems are authoritative or observable and explicitly incomplete where the company-controlled presentation could not be read.

13. Registration and Running Code Answer Different Questions

LACNIC records tell observers who is named on an ASN and address resources. RIPEstat shows what selected collectors observed in BGP at defined times. RPKI validation shows whether selected origin-prefix pairs matched published authorization metadata. Each system answers a different question.

The registration layer establishes administrative identity and resource boundaries. It does not prove that a route is currently announced. The routing layer reflects operating state, but it does not establish legal ownership of every asset or explain commercial service. Security metadata adds authorization context without proving delivery or resilience.

Keeping those layers distinct prevents both false confidence and false suspicion. A registered resource can be temporarily unannounced without becoming illegitimate. A visible route can be technically real without proving every business claim made around it. A valid ROA can improve origin assurance without turning the network into a fully audited system.

Here the layers align on an important core. The exact name appears in LACNIC, AS263823 is announced, registered IPv4 and IPv6 resources are visible, and two checked pairs validate. That alignment provides a substantial reality layer for the public network identity.

The alignment ends before customer delivery. No source in the bounded set proves the last-mile medium, service footprint, capacity, uptime, support model or recovery plan. Those gaps are not defects in the registries; they are questions that require different evidence.

14. Number Resources Create Options, Not Guaranteed Independence

Holding an ASN and directly registered address space can give a regional provider more control over public identity. It may support consistent addressing across supplier changes, independent routing policy and clearer counterparty configuration. These are meaningful strategic options in an industry where renumbering and provider lock-in can be costly.

Options require execution. Using them depends on routing expertise, equipment, interconnection, transport, facilities, monitoring and change management. A provider can possess portable resources yet remain highly dependent on one physical path or one commercial supplier. Public resource ownership does not disclose that dependency.

IPv4 and IPv6 also create different operational burdens. IPv4 scarcity can make address conservation and reputation management important. IPv6 creates abundant hierarchy but requires customer equipment, support and application readiness. The existence of both resources says little about how effectively either is delivered.

Portability is not instant continuity. Moving connectivity can require new sessions, filters, authorization updates, testing, customer communication and coordinated maintenance. The ASN and allocations may reduce one class of dependency while leaving power, facilities, transport and people as critical constraints.

The economic value of AS263823 therefore sits in the control surface it makes possible. Public routing shows that the control surface is being used. Whether that use produces bargaining power, lower costs or greater resilience remains an open operational and commercial question.

15. The Physical Dependency Chain Remains Largely Invisible

Every public route ultimately depends on physical systems. Customer access reaches aggregation equipment; transport connects sites; routers exchange traffic; power supports active devices; facilities provide space and environmental conditions; people maintain the chain. BGP exposes the logical edge, not the complete dependency path.

The current evidence does not identify owned fibre, leased circuits, radio links, towers, ducts, street cabinets, data centres or exchange ports. It does not show where the network hands traffic to other autonomous systems. Assigning any of those assets to MIX SERVICIOS & COMUNICACIONES would be invention.

Power is similarly absent. A route can stay visible while one local access segment loses power, or disappear even though most physical plant remains intact. Battery autonomy, generator coverage, fuel arrangements and restoration priorities require direct operational evidence.

Redundancy cannot be inferred from three observed AS neighbours or from multiple route records. Real redundancy depends on shared failure domains: two logical paths may converge on one cable, building, power feed or supplier. Public control-plane diversity is at most a reason for deeper diligence.

Customer premises add another dependency layer. The provider may deliver a usable handoff while a local router, optical terminal, power supply or building network becomes the failure point. Public route visibility cannot distinguish that condition from a healthy end-to-end service. A serious continuity assessment needs responsibility boundaries: who owns each device, who monitors it, which spare is available, who can enter the site and which restoration commitment applies. None of those facts should be inferred from the ASN.

Human capability belongs in the chain as well. Routing changes, fibre repairs, supplier escalation and customer communication depend on people and procedures. A small regional operation may be highly responsive yet concentrated around a few specialists; a larger one may have more staff but slower coordination. The public number-resource record cannot support either conclusion. Staffing resilience, escalation coverage and documented change control require direct operational evidence.

The physical gap should shape how the network is evaluated. Registry and routing facts support accountability at the public edge. Continuity claims need diagrams, facility evidence, supplier disclosures, measurements or incident records that expose the deeper chain.

16. Procurement Should Separate Identity from Service Assurance

A buyer can use the public evidence to verify that a real network identity exists. The legal-resource name, ASN, registered ranges, current route visibility and selected RPKI results are concrete. They reduce the risk of treating a generic brand presentation as the entire technical record.

Service assurance requires a second set of questions. Which access technology reaches the site? Which address family is delivered natively? What handoff and customer equipment apply? Which support route operates during an incident? What restoration targets are contractual rather than aspirational?

Dependency questions belong beside them. Where are upstream handoffs? Which transport and facilities are shared? Does a backup path leave the same physical risk domain? How are routing changes authorized and tested? The three observed AS adjacencies do not answer those questions, but they make the need for answers more visible.

Customers needing stable public addressing should ask how IPv4 assignments, IPv6 delegation and reverse DNS work. A registered /22 and /32 do not specify product terms. Stability, delegation size, filtering and portability need explicit documentation.

This layered approach avoids two errors. It does not dismiss a smaller operator merely because every physical fact is not public, and it does not grant assurance because an ASN is visible. Identity can be verified while service and continuity remain matters for contract, measurement and operational review.

17. Incident Interpretation Needs More Than a Route Change

Future monitoring may show a withdrawal, a new more-specific, a changed neighbour or a different RPKI state. Each is a useful signal. None automatically describes what customers experienced. The control plane and delivery plane can diverge.

A widespread route withdrawal could indicate maintenance, a configuration problem, an upstream event or a deliberate policy change. A single more-specific could reflect traffic engineering or mitigation. An origin change could be authorized or accidental. Public data rarely supplies the operator's reason.

Customer impact requires complementary evidence such as reachability measurements, service notices, direct reports, DNS behaviour or application tests. Even those signals need timing and geographic context. One observation should not be inflated into a general outage narrative.

Recovery also has layers. A route can reappear before all access services recover, or customer connectivity can return through an alternative arrangement before collectors converge. Restoration timestamps should identify which layer they describe.

AS263823 gives incident analysis a stable reference point. Its value lies in enabling exact, dated observations and better questions. It does not make causal claims safe without corroboration.

18. The Regional-ISP Economics Lie in the Unseen Dependencies

Number resources and routing control can reduce some forms of dependency, but regional access economics are shaped by costs that do not appear in BGP. Transport, pole or tower access, field maintenance, power, equipment replacement, support and supplier terms can dominate operating decisions.

Direct address resources may improve flexibility. They can support a stable public identity and reduce renumbering pressure when a commercial relationship changes. Yet switching suppliers still requires compatible handoffs, available alternatives, technical staff and careful execution. The resource is an option, not a guarantee.

The visible neighbours show that AS263823 participates in a broader routing environment. They do not reveal prices or bargaining power. A path that looks diverse at the AS level can share expensive or fragile physical infrastructure. Cost and resilience need evidence from the commercial and physical layers.

IPv6 may lower long-term address constraints, but deployment can add near-term support and equipment work. IPv4 remains scarce and operationally valuable. The balance between them affects network design without disclosing the provider's margins or customer mix.

The public record therefore supports an economic thesis about control surfaces rather than financial performance. MIX SERVICIOS & COMUNICACIONES holds resources that can support operational choice. The extent to which those choices reduce cost, improve continuity or strengthen service remains unmeasured.

There is also a cost to maintaining public autonomy. Address resources require accurate contacts and security metadata. Routing policy needs monitoring, testing and coordination with other networks. Equipment, software and staff must support both address families. These obligations can be worthwhile because they preserve options, but the registry cannot reveal whether the organization performs them efficiently. Resource control should therefore be viewed as an operational capability with continuing costs, not a free signal of strength.

19. A Practical Monitoring Agenda Starts with Exact Baselines

The strongest baseline records the exact holder, ASN, registered prefixes, observed route set, peer visibility and checked RPKI results with dates. Future checks can then identify changes without rewriting old observations. A new state does not make the previous snapshot false.

For IPv4, monitoring can compare the covering /22 and visible more-specifics, origins and peer visibility. For IPv6, it can track the /32, observed /36s and any additional announcements. Overlap should remain explicit so changes are not mistaken for new resource holdings.

RPKI monitoring should enumerate the exact pair being tested and preserve the result time. If a route becomes invalid or unknown, the affected origin, prefix and authorization should be identified. A general label such as “RPKI enabled” is too imprecise for incident or diligence work.

Neighbour observations can be tracked without naming commercial roles. If AS263774, AS265828 or AS266668 disappears or a new adjacency emerges, the change can trigger a question. Contract, capacity and physical diversity still require direct confirmation.

The company-controlled layer should also be revisited cautiously. A reachable official site or attributable service document could clarify products and geography. It should supplement, not overwrite, the registry and routing record. Claims should retain dates and source boundaries.

This agenda turns public data into continuing accountability rather than a one-time profile. It rewards exactness: what changed, when, at which layer and with which evidence? That is more useful than a static claim that the network is simply present or absent.

A useful record should also preserve negative findings without turning them into permanent labels. The website timeout belongs to the date of the check. The observed neighbour set belongs to the sampled paths. RPKI validity belongs to the exact origin-prefix pairs. If later evidence changes any of those states, the new observation can be added without rewriting the old one. This discipline makes trends auditable and reduces the temptation to convert a transient result into a company-wide judgment.

20. AS263823 Is a Strong Anchor with a Clear Outer Boundary

Jose Luis Zurakouski and MIX SERVICIOS & COMUNICACIONES can be tied to a real, active public network identity. LACNIC provides the name, handle, ASN and address-resource registrations. RIPEstat shows current dual-stack routing visibility. Two checked RPKI pairs add narrow origin-authorization evidence. PeeringDB adds operator-maintained ISP context.

The alignment is meaningful. It makes the network more than a business-description entry and provides durable reference points for counterparties, customers and researchers. Registration, running routing state and selected security metadata can be examined independently and compared over time.

The same evidence defines where confidence must stop. It does not prove a facility, access method, coverage map, installed or lit capacity, customer count, transit contract, physical diversity, uptime, resilience, outage history, ownership structure, revenue or market share. The timed-out website adds nothing that closes those gaps.

The result is not a promotional score and not a verdict on service quality. It is a reality-layer account of what the public technical systems establish: a registered operator identity, visible routes and selected valid authorization metadata. The delivery and continuity layers remain open for direct evidence.

That outer boundary is commercially useful. It tells a buyer what can already be verified and what still belongs in procurement, measurement and contract review. AS263823 makes MIX SERVICIOS & COMUNICACIONES observable at the Internet's public routing edge, while leaving the customer-delivery path deliberately unclaimed.

Sources