Summary

  • RIPEstat identifies AS135206 with the holder string BLUWAVES-AS - Bluwaves Internet Services India P. Ltd, reports the autonomous system as announced, and lists six IPv4 /24 prefixes in the current two-week query window.
  • The evidence supports a narrow registry-and-routing analysis. It does not prove access routes, service geography, upstream diversity, customer scale, physical redundancy, capacity, power arrangements, outage behaviour or recovery capability.

Six public prefixes make the company inspectable

Bluwaves Internet Services India P. Ltd becomes visible as an infrastructure subject through a public number-resource surface rather than through an audited network map. The relevant control-plane entity is AS135206. RIPEstat's AS overview identifies the holder as BLUWAVES-AS - Bluwaves Internet Services India P. Ltd and reports the autonomous system as announced. The announced-prefixes response lists six IPv4 /24 prefixes: 103.215.168.0/24, 103.186.251.0/24, 103.215.171.0/24, 103.215.169.0/24, 103.186.250.0/24, and 103.215.170.0/24. Those six routes are the strongest public facts in the current evidence set.

The route evidence matters because it turns the company from a directory name into an inspectable Internet resource holder. A company can claim many services without leaving much public network evidence. An autonomous system with visible prefixes is different. It sits in a public coordination layer where route collectors, registry records and WHOIS entities can be compared. That comparison does not reveal the whole operating network, but it creates a durable starting point: AS135206 is named, announced and associated with six IPv4 /24 routes in the current RIPEstat view.

The same evidence has a clear limit. A BGP announcement does not show where fibre is buried, which towers or buildings are powered, which customers depend on the network, whether upstream paths are independent, or how restoration would work after a cut or equipment failure. The presence of six /24s does not prove residential coverage, enterprise service, data-centre reach, route-origin security, peering quality, outage history or commercial availability. It proves public route visibility, not physical delivery.

For that reason, Bluwaves is best treated as a routing-accountability case rather than a broad company profile. The exact company entity is the existing directory entity for Bluwaves Internet Services India P. Ltd. The public surface is AS135206. The evidence is APNIC-derived registry and RIPEstat route data. The unresolved question is the physical dependency chain behind the public AS: where the network actually reaches, what it relies on, and what fails first if the route surface is disturbed by upstream, power or local access problems.

This is a useful type of infrastructure coverage precisely because it does not pretend to see more than the public record shows. Route visibility is not a guarantee of service quality. Registry identity is not proof of operational resilience. Six public prefixes give analysts something real to monitor, but the delivery chain remains outside the record. The company is visible enough for scrutiny and not visible enough for confident claims about physical infrastructure.

The registry record names the public control surface

The first layer is administrative. RIPEstat's AS overview places AS135206 in an APNIC-assigned 32-bit autonomous-system number block and returns the holder string BLUWAVES-AS - Bluwaves Internet Services India P. Ltd. The WHOIS view records aut-num: 135206, as-name: BLUWAVES-AS, descr: Bluwaves Internet Services India P. Ltd, country: IN, admin contact TS956-AP, technical contact MT943-AP, maintainers MAINT-IN-BLUWAVES and MAINT-IN-IRINN, incident-response reference IRT-BLUWAVES-IN, route maintainer MAINT-IN-BLUWAVES, APNIC as source, and a last-modified timestamp of 2025-09-27T10:34:44Z.

Those fields do not operate the network, but they matter. Number resources require records that can be inspected, maintained and challenged. A public AS entity with named contacts and maintainers is part of that recordkeeping layer. It helps distinguish the named Bluwaves entity from a loose commercial label or a generic broadband claim. It also gives future monitoring a stable handle. If a route disappears, an origin changes, a maintainer shifts or a registry field stops matching public route evidence, the AS record is where that change can be anchored.

The WHOIS record should not be turned into stronger claims than it supports. A maintainer entity does not prove that engineers are available. An incident-response reference does not prove a response history. A country field does not show a service area. A last-modified timestamp does not show that the network is healthy. The registry surface is a ledger, not the physical network itself. It is a public layer that makes resource identity visible while leaving operating condition unresolved.

That distinction is central to the infrastructure question. Bluwaves is not being examined here because a company description says it provides connectivity. It is being examined because a public AS and prefix set expose a running-code surface. The AS overview and WHOIS data give the named resource boundary. RIPEstat's route view shows that the autonomous system is not merely dormant in the public record. The combination is enough to ask what the route table reveals and what it cannot reveal.

The answer begins with a hierarchy. The exact directory company is Bluwaves Internet Services India P. Ltd. The public number-resource entity is AS135206. The registry source is APNIC through the WHOIS view exposed by RIPEstat. The current routing surface is six IPv4 /24 prefixes visible in the announced-prefixes response. Every further claim has to respect that hierarchy. The company can be tied to the AS holder string and the route evidence. It cannot, from this source set alone, be tied to a particular access network, customer dependency, powered site or restoration plan.

The six-prefix footprint is concrete but narrow

The six visible prefixes give the analysis its concrete base. RIPEstat announced-prefixes lists 103.215.168.0/24, 103.186.251.0/24, 103.215.171.0/24, 103.215.169.0/24, 103.186.250.0/24, and 103.215.170.0/24 over a two-week window ending 2026-07-29T16:00:00. Each prefix appears with a timeline starting 2026-07-15T16:00:00 and ending at the latest query time. That is a route-table fact, not a marketing assertion.

Visible prefixes have operational significance because they can be watched. They can show whether AS135206 continues to originate the same blocks, whether a prefix disappears, whether a different origin appears in another measurement, or whether the announced set expands or contracts. Public routing evidence is not enough to judge the whole company, but it is enough to create a monitoring baseline. For a small or less visible network operator, that baseline is often the most inspectable part of the infrastructure footprint.

The footprint is still narrow. Six /24 routes do not say how many customers exist, whether addresses are allocated to subscribers, whether the address space backs enterprise circuits, whether it is used for infrastructure, or whether it is parked behind an upstream arrangement. The route table does not reveal the physical plant that carries the traffic. It does not show buried fibre, wireless links, leased backhaul, exchange cross-connects, customer premises, routers, powered cabinets or repair spares. It also does not show the business status of service over the address space.

The addresses therefore support a visibility finding rather than a service-capability finding. They show that public IPv4 space is being originated under AS135206. They do not support claims that Bluwaves has a particular coverage area, capacity level, customer base, tower footprint, last-mile technology or backbone route. Those topics require independent operational, commercial or engineering sources. Without those sources, the safest conclusion is that Bluwaves has a visible routing surface and an unresolved physical delivery boundary.

This matters for redundancy. Some networks appear more resilient than they are because they use multiple labels: several prefixes, several upstream brands, or several administrative contacts. None of those labels proves physical diversity. Six /24s could traverse one concentrated dependency, several shared dependencies, or genuinely separate paths. The current evidence does not identify the paths. It only shows the prefixes. The resilience question can therefore be framed, but it cannot be answered from route visibility alone.

AS visibility is not a coverage map

A common mistake in infrastructure coverage is to treat a routing surface as a coverage map. AS135206 should not be read that way. The current public data does not map service districts, street routes, towers, customer clusters, exchange points, backbone paths or access technologies. It only ties a named company to an announced AS and six IPv4 /24 prefixes. The company may operate access infrastructure, lease capacity, use third-party transport, serve a limited customer set, or run a narrower network role. The current evidence does not choose among those possibilities.

The country: IN WHOIS field is useful for jurisdictional context, but it is not a local geography claim. It does not place routers in a specific city. It does not identify a cable landing point, data centre, metro ring, local exchange or district-level service area. It should not be converted into a map. The public directory route supplies the exact company entity, and the APNIC-derived record supplies resource context; neither supplies a plant survey.

This caution also applies to capacity. A /24 contains 256 IPv4 addresses at the numbering level, but the existence of six /24s is not a capacity metric for broadband service. Address count is not bandwidth. It is not lit capacity. It is not powered capacity. It is not sold capacity. It is not usable capacity under failure conditions. The address footprint can support questions about number-resource scale, but it cannot answer how much customer traffic the network can carry or how it behaves under stress.

The same boundary applies to customers. Prefix visibility can be customer-facing, infrastructure-facing or internally assigned. The current public record does not identify subscribers, enterprises, public services, cloud dependencies, content providers or wholesale customers. It does not show whether any town, business district, institution or public service depends on Bluwaves for continuity. Customer dependency is often the most important practical question in a network failure. It remains unproved here.

Treating the AS as a map would therefore overstate the record. Treating it as a monitoring surface is more useful. The AS record can be revisited. The prefix list can be compared over time. WHOIS maintainers and incident-response references can be checked against later changes. If future sources disclose service geography, upstream relationships, peering, route-origin authorization, outages, customer contracts or access technologies, those facts can be added without changing the core boundary: AS135206 is visible, but the delivery layer needs separate proof.

The useful dependency question sits behind the public route surface

The infrastructure question is not only whether routes are visible. It is what has to keep working for those routes to remain useful. At the minimum, AS135206 depends on registry accuracy, route origination, transport to upstream or peer networks, powered routing equipment, a working incident-response chain and whatever local access or service layer sits behind the public prefixes. The current evidence proves the first public surface and leaves most of the rest outside view.

That boundary is not a weakness in the analysis. It is the point of the analysis. Many smaller network operators are publicly visible through number resources long before their physical dependencies are well documented. A route collector can show that an AS is announced. WHOIS can show holder and maintainer fields. Neither can prove how field repair, power restoration, spare equipment, upstream diversity or customer migration would work during a failure. The unanswered questions are operational, not cosmetic.

One failure path is route withdrawal. If AS135206 stops announcing one or more of the six prefixes, the public symptom would be visible in route data. The cause could be administrative, upstream, router, configuration, power, fibre, commercial or measurement-related. The current evidence does not assign a cause. It only provides the baseline that would make a withdrawal noticeable. The practical dependency question would then move from route state to the physical or contractual layer that caused the state to change.

Another failure path is an upstream or transport concentration. The current data does not identify upstream carriers or physical paths. If all traffic relies on one upstream, one exchange, one powered room, one fibre corridor or one leased transport provider, six visible prefixes would still share the same weakness. If there are multiple independent paths, the route surface might have more resilience than the current evidence proves. Both scenarios are possible from the data available here. Neither should be claimed.

Power is another hidden dependency. A network can have valid registry records and visible prefixes while still depending on a small number of powered sites. The current evidence does not identify utility supply, backup generation, battery duration, fuel access or site-level electrical design. It does not prove whether routers and access equipment can stay online during grid failure. For a broadband or regional ISP subject, power continuity is often as important as routing continuity. It remains outside the evidence set.

Maintenance and restoration are also invisible. The WHOIS record names contacts and maintainers, but that is not the same as proving field repair. It does not show where spares are stored, who can access sites, how quickly a cut link is found, whether local permits are required, or whether a third-party transport provider controls the actual repair window. Route visibility shows the public symptom. It does not show the recovery machinery behind the symptom.

Recordkeeping is necessary, not sufficient

The Heng.lu-style surface in this case is the recordkeeping layer around ASNs, prefixes and public routing state. That layer has real value. Internet number resources need uniqueness, accuracy, transfer recording, security metadata and operational continuity. A company named in public AS and WHOIS records is easier to inspect than one that appears only in marketing copy. The registry is the place where a public resource identity can be checked.

But recordkeeping is not sovereignty over reality. A registry field can say who is named around a resource; it cannot guarantee that the resource is used well, used safely, routed securely or backed by resilient infrastructure. A maintainer entity can be stale. An incident-response reference can be present without public evidence of incident handling. A route can be visible without exposing its path. The public ledger is necessary for accountability but limited public evidence for full operational judgment.

Running-code primacy gives the route data extra weight. AS135206 is not only named in WHOIS; RIPEstat also reports it as announced and lists six prefixes. That running-route observation makes the public record more than a dormant entry. It says the AS is currently visible to the measurement system used here. The fact is still bounded by the measurement. It does not reveal packet delivery, customer experience, traffic levels or physical geography.

The useful balance is to hold both points together. Bluwaves has enough public routing evidence to justify infrastructure scrutiny. Bluwaves does not have enough public evidence in this compact source set to justify claims about service footprint, resilience or physical assets. The recordkeeping layer makes the company inspectable. It does not make the delivery chain known.

This balance is especially important for smaller AS-based infrastructure subjects. Writing only about large facilities, hyperscale campuses or well-documented cable systems misses many smaller control surfaces that keep regional connectivity working. At the same time, smaller route footprints can invite overclaiming because evidence is sparse. The remedy is not silence. The remedy is precise scope: report the route surface, preserve the uncertainty, and avoid converting administrative facts into physical claims.

What a stronger proof package would need to show

The current evidence would become much stronger if it were paired with public sources that identify the network's physical and commercial role. Service-area documentation could show where Bluwaves actually provides connectivity. Telecom licence records could clarify regulatory status. Upstream or peering information could show how AS135206 reaches the rest of the Internet. Route-origin authorization records could add a routing-security layer. Outage reports or maintenance notices could show how the network behaves under stress.

Physical infrastructure evidence would matter even more. Maps, permits, tower records, fibre route disclosures, exchange-point records, data-centre or point-of-presence references, power arrangements and repair contracts would all shift the analysis from number-resource visibility to operating-system dependency. Without them, the public record cannot show where a customer-facing failure would begin or how it would propagate. With them, the six-prefix baseline could be connected to a real delivery chain.

Customer evidence would also change the analysis. If public records identified enterprises, public institutions, wholesale customers, residential markets or local services that depend on Bluwaves, the failure question would become more concrete. A prefix withdrawal or upstream outage would then be tied to named dependency groups. The current evidence does not identify those groups. It supports only the more general question of what the public route footprint can tell observers.

Capacity evidence would be separate again. A future source could identify bandwidth, ports, circuits, access technologies, installed equipment, sold service tiers or failover capacity. Until that appears, the six /24s should not be treated as capacity. They are address and route facts. They do not measure throughput. They do not prove that a service can absorb growth or withstand a failed path. Capacity has to be measured by the relevant physical or commercial unit, not inferred from prefix count.

Recovery evidence would be the hardest to obtain and the most important for resilience. Public statements about redundancy are less useful than documented failure behaviour. A record of an outage, a repair notice, an upstream incident, a power event or a customer migration would show more than an abstract resilience claim. Without such evidence, redundancy remains an open question. The route surface can be monitored, but it cannot confirm failover.

Why the unresolved boundary matters

The unresolved boundary matters because a route table can create a false sense of clarity. AS135206 and six prefixes are visible, so the company feels inspectable. In one sense, it is. In another, the most important dependencies remain hidden. Public routing data sees the top of the network stack. Physical infrastructure risk often sits below it: power, fibre, access sites, upstream contracts, field repair, equipment spares and commercial prioritisation.

If a prefix disappears, users may experience degraded service, complete loss, no visible change, or a routing-only event with little customer impact. The current evidence does not tell which. If all six prefixes remain announced, the underlying access network could still have local failures or customer outages. Route visibility can be a necessary condition for reachability, but it is not a complete condition for service. That is why infrastructure analysis should avoid equating control-plane visibility with user-facing continuity.

This also affects ownership and control. The exact company name appears in the AS holder and WHOIS records, but the physical network could still involve leased circuits, third-party facilities, upstream providers, utility companies, contractors and customer equipment. The current evidence does not identify those parties. It does not show who can authorize repairs, reroute traffic, add capacity, restore power, terminate service or prioritize customers during an incident. Public number-resource ownership and practical operational control can diverge.

The same problem appears in outage consequence. A failure in a small routing footprint can be minor or highly localised. It can also be critical if the network serves a hard-to-replace community, institution or wholesale function. The current evidence does not identify the affected population or service group. It only shows that six public prefixes are originated by a named AS. Consequence analysis therefore has to stay conditional. It can name the kinds of evidence that would matter, but it cannot invent victims, customers or regions.

The unresolved boundary is not an argument against coverage. It is the coverage. The visible AS lets BTW mark a company as present in the public Internet resource layer. The unresolved delivery chain tells readers what remains unverified before anyone can make a stronger claim about access, resilience or regional dependence. That is a more useful finding than either promotional certainty or silence.

Watchpoints for AS135206

The first watchpoint is prefix continuity. The six /24s listed in RIPEstat's current response provide a baseline. If later measurements show withdrawal, origin change, unexpected more-specific announcements, or a materially different prefix set, the change would deserve inspection. It would not immediately prove an outage, but it would identify a public routing change that can be compared with maintenance notices, customer reports or registry updates.

The second watchpoint is registry alignment. The AS holder, as-name, description, maintainers, IRT reference and route maintainer should remain coherent with the directory identity. If registry fields change, the change may indicate administrative cleanup, resource transfer, operator restructuring or routine maintenance. The current evidence does not predict such a change. It only establishes the current alignment around Bluwaves Internet Services India P. Ltd.

The third watchpoint is routing-security evidence. The current source set does not establish RPKI status or route-origin authorization. If future records show validated ROAs, invalid announcements, missing authorizations or routing-security changes, that would add a security-metadata layer to the number-resource analysis. Until then, the record should not be used to claim anything about RPKI posture.

The fourth watchpoint is upstream and path diversity. If public BGP neighbour data, peering records or exchange membership later identify upstream relationships, the resilience question can become sharper. Multiple logical upstreams would still not prove physical diversity, but they would be more informative than the current AS-and-prefix baseline. If only one dependency appears, the single-path question would become more urgent.

The fifth watchpoint is physical service evidence. Licence records, access maps, customer disclosures, maintenance notices, outage reports, job postings, contractor records or local reporting could show where the network operates and how it is maintained. Those sources would be needed before writing about coverage areas, field repair, powered sites or customer consequences. Until they appear, the physical delivery chain remains open.

The safest conclusion is visibility with unresolved dependency

Bluwaves Internet Services India P. Ltd is not invisible. The exact directory entity has a public route gate, AS135206 is named with the Bluwaves holder string, and six IPv4 /24 prefixes are currently visible in RIPEstat's announced-prefixes response. The WHOIS view adds APNIC-derived administrative structure through contacts, maintainers, route maintainer and incident-response reference. That is a meaningful public Internet infrastructure record.

The record is also incomplete. It does not establish physical routes, last-mile technology, site locations, upstream diversity, customer dependency, power continuity, capacity, outage history, recovery paths or commercial operating scale. Those omissions are not minor details. They are the difference between seeing a number-resource surface and understanding a delivery system.

The public-interest value of the evidence is therefore narrow and practical. AS135206 gives Bluwaves a visible place in the routing layer. The six /24s give monitoring a baseline. The registry fields give recordkeeping anchors. Together they justify scrutiny of the company as a number-resource and routing subject. They do not justify a broader claim that the company controls a proven resilient access network.

That is the boundary a good infrastructure analysis must preserve. It should not turn route visibility into coverage. It should not turn a maintainer field into repair capability. It should not turn a country field into a service map. It should not turn address count into capacity. It should say what the public Internet record makes visible and what remains physically unproved.

For Bluwaves, the visible layer is enough to matter. Six public routes, a named AS, and APNIC-derived WHOIS fields create a real accountability surface. The physical layer behind that surface still needs proof. Until that proof appears, the most accurate finding is restrained: AS135206 makes Bluwaves visible in public routing data, while the access boundary, dependency chain and resilience case remain open.

Capacity cannot be inferred from address visibility

The six /24s also show why capacity language has to stay disciplined. Address resources are not a substitute for usable network capacity. A prefix can support many possible uses, and none of those uses can be measured from the prefix alone. It may sit behind customer access, infrastructure interfaces, management systems, enterprise links or another internal allocation pattern. RIPEstat shows origination, not traffic. It does not expose ports, optics, committed information rates, radio sectors, fibre pairs, upstream contracts or customer contention.

That distinction is important because capacity mistakes are easy to make in small-network coverage. A visible IPv4 footprint can look like a service footprint. It is not. The address block can be counted at the numbering layer, but the service layer depends on equipment, access media, power, backhaul, aggregation, upstream transport and customer contracts. The current evidence does not identify any of those capacity-bearing parts. It therefore cannot support claims about available bandwidth, installed throughput, sold access, business service, residential service, peak congestion or spare headroom.

The safest capacity statement is negative and precise. The current route record proves that six IPv4 /24s are visible under AS135206; it does not prove design capacity, installed capacity, lit capacity, powered capacity, sold capacity, available capacity or usable capacity under failure conditions. If later sources identify service packages, upstream links, port speeds, wireless spectrum, fibre routes, aggregation sites or customer volumes, those facts can be added to the operating layer. Until then, capacity remains unmeasured.

This matters under stress. A network can appear normal in route data while running close to physical or commercial limits. Another can withdraw a route without materially affecting end users if the prefix was not tied to critical service. Route visibility is necessary evidence for public Internet reachability, but it does not reveal margin. In resilience terms, margin is the difference between nominal route origination and a network that can absorb failure. The current evidence only supports the first part.

The current record therefore cannot praise or criticise Bluwaves for capacity. It can only show that the public route surface is visible and bounded. A future source showing upstream diversity, router capacity, access network design or measured congestion would change the quality of the analysis. The six-prefix baseline would then become one piece of a larger capacity picture. At present it remains a numbering and routing baseline, not an engineering capacity audit.

Customer dependency remains unidentified

Customer dependency is the other major missing layer. The current source set does not identify residential subscribers, enterprise customers, public-sector users, wholesale customers, content networks, cloud customers, tower sites, institutions or communities that rely on Bluwaves. It does not show whether the six prefixes support customer access, internal systems, business circuits, infrastructure services or another role. Without that information, the consequence of failure cannot be localised.

That limit should be visible in the narrative because customer dependency is the reason infrastructure failures matter. If a route disappears and nobody depends on it for live service, the operational effect may be narrow. If the same route supports a local access network, business district or public service, the consequence can be more serious. The public AS record does not tell which case applies. It gives a control-plane signal and leaves the dependency chain open.

The absence of named customers also limits ownership interpretation. The company name in WHOIS and the directory route gives the entity boundary, but service dependency can cross many other contracts. A broadband-facing company might rely on leased upstream transport, third-party facilities, tower or rooftop access, local utility supply, field contractors, address allocations and customer-premise equipment. Customers may see one retail name while the actual failure path crosses several other operators. None of those relationships is documented in the current source set.

The consequence analysis must therefore stay conditional. If Bluwaves uses AS135206 for customer-facing access, failure of upstream transport, routing equipment, power or local access plant could affect the customers behind those prefixes. If the prefixes serve a narrower infrastructure or internal role, the impact would be different. If a third party carries the physical path, Bluwaves' public routing identity might sit above a dependency it does not fully control. Each possibility is plausible enough to watch and unsupported enough to avoid presenting as fact.

This is a more honest way to use sparse public evidence. The exact company and AS are known. The announced prefixes are known. The dependency population is not. A future customer disclosure, outage notice, local service map, regulator record or operator statement would be needed before the first affected group could be identified. Until then, the public interest lies in marking the blind spot.

Failure paths begin below the route table

The current route surface can support a set of failure questions even though it cannot answer them. The first question is route origination. If AS135206 stops originating one of the listed prefixes, the public symptom would be visible in route data. That symptom would not identify the cause. The cause could be a router outage, an upstream withdrawal, a configuration change, a power event, a commercial change, a measurement artifact or planned maintenance. The route table shows the symptom, not the root failure.

The second question is transport concentration. If all six prefixes depend on one upstream, one physical handoff, one exchange, one aggregation site or one leased transport path, then several public routes can still share one point of failure. The current evidence does not identify neighbours or physical handoffs. It therefore cannot prove whether the six prefixes diversify risk or simply expose the same dependency through multiple numbered blocks. This is one of the central unresolved points.

The third question is power and site continuity. Registry and route evidence can remain coherent until a physical site loses power. If the equipment originating or aggregating AS135206 depends on a single utility feed, limited battery duration, constrained generator fuel or a facility without redundant cooling, a power event could interrupt service without any warning in the registry record. The current evidence gives no site-level power data. It does not show where routers are housed or how they are kept online.

The fourth question is repair control. If a physical link fails, the repair path depends on who owns the route, who owns the fibre or wireless segment, who can enter the site, who holds spares, who controls upstream contracts and who can authorise changes. WHOIS maintainers are not the same as field repair control. A maintainer can update a record or route object, but the physical fix may belong to another party. The current evidence does not show where those responsibilities sit.

The fifth question is customer migration. If a failure affects customer-facing service, customers may have alternate providers, secondary circuits, mobile backup, manual reroute procedures or no practical substitute. The current evidence does not identify customers, so it cannot assess migration options. It can only show that, if customers do depend on the AS135206 delivery chain, the public route table alone will not reveal the full recovery path.

These questions are useful because they keep analysis focused on the physical dependency behind a public control-plane entity. The analysis does not need to fabricate a failure. It needs to show why the route table is an incomplete failure model. The visible prefixes are the signal. The unseen power, transport, field access, repair and customer layers are the unresolved risk surface.

Ownership and operator control need separate proof

The AS holder string names Bluwaves, but operational control should not be inferred beyond the record. A company can be named around an AS while relying on upstream carriers, facility owners, equipment vendors, utility providers, contractors and customers with their own control points. The registry identifies the administrative side of number-resource responsibility. It does not document the economic owner of every underlying asset, the operator of every physical link or the party with practical control during an incident.

Control matters because infrastructure failures are not solved only by ownership labels. The party named in an AS record may not be able to repair a leased fibre route. A retail-facing operator may not control a utility outage. A network with a public AS may still depend on another provider for upstream reachability. A route maintainer may be able to alter route objects but not enter a site, replace a radio, energise a cabinet or change a customer access path. The current evidence does not identify those layers for Bluwaves.

That is why the analysis separates resource identity from operational authority. Bluwaves is the exact company entity and the AS holder string. AS135206 is the visible number-resource surface. The six prefixes are visible originated blocks. The operator of any physical route, site, power path, upstream handoff, customer access medium or repair process is not established. Stronger ownership language would need documents outside the current source set.

The distinction also affects accountability. Public records make it possible to ask questions of the named holder, but they do not resolve every responsibility. If a future outage affected the prefixes, a first read might point to AS135206. The practical resolution might require an upstream carrier, utility provider, contractor, facility owner or customer-side operator. Without evidence about those relationships, the public record should avoid assigning operational blame or credit.

This restrained approach still leaves Bluwaves with a meaningful public footprint. A named AS holder and six visible prefixes are not trivial. They create a resource identity that can be monitored and compared with later records. The absence of physical-control evidence does not erase the AS; it defines the next evidence layer needed before stronger claims can be made.

The current record supports monitoring, not promotion

The strongest use of the evidence is continuing monitoring. RIPEstat's current response gives a baseline prefix set and a current announced state. WHOIS gives maintainer and contact fields. The public directory route gives the exact company entity. Together those records allow future changes to be framed precisely. A route withdrawal, a changed holder string, a different maintainer, a new prefix, a route-origin security update or a public outage notice would all have a baseline for comparison.

The record does not support promotional language. It should not be used to describe Bluwaves as resilient, high-capacity, strategically redundant, regionally critical, fully operational or physically diverse. Those labels require proof that is not in the current source set. The route surface is real, but it is not enough to certify performance or importance. A measured public record is stronger when it keeps its boundaries visible.

The same restraint applies to image and presentation. A generic network-control or routing-visibility image can support the coverage as an editorial illustration, but it must not be represented as a Bluwaves facility, tower, route map, outage, data centre or customer network. The image should support the abstract control-plane theme without adding false physical evidence. Visual restraint is part of factual restraint.

This leaves a clear public finding. Bluwaves Internet Services India P. Ltd is visible enough to inspect through AS135206 and six announced IPv4 /24 prefixes. The public record is not enough to describe the access network behind that visibility. That gap is not a failure of the evidence. It is the central infrastructure point: number-resource visibility creates accountability, while physical dependency still requires evidence.

Sources