Summary

  • ParminCloud-AnyCast is anchored by AS197330, a RIPE-assigned autonomous system registered with the as-name ParminCloud-AnyCast and linked to PARMIN CLOUD COMPUTING LLC.
  • The strongest service-proof record is a RIPE route object for 217.18.48.0/24 with origin AS197330, but RIPEstat showed no current announcement for the ASN or prefix at its July 15, 2026 query time.
  • Public accountability signals exist through RIPE organisation, technical, and abuse contact records, including an abuse mailbox at the parmin.cloud domain, but those records do not by themselves prove uptime, route diversity, customer support performance, or anycast reach.

The name is specific, but the public proof is narrower

ParminCloud-AnyCast is not an empty label. The BTW directory profile points readers to a concrete network identifier: AS197330. RIPE registry data then connects that autonomous system to the as-name ParminCloud-AnyCast and to organisation ORG-PCCL4-RIPE, listed as PARMIN CLOUD COMPUTING LLC. That chain matters because it gives analysts a stable way to separate a searchable brand name from a registered network resource.

The identity record also gives the company a local anchor. The RIPE organisation entity lists country IR, an address in Qom at Qom Science and Technology Park, and an organisation type of LIR. The same organisation was created in RIPE records on December 23, 2024, while the AS197330 aut-num entity was created on May 22, 2026 and last modified on June 18, 2026. In other words, this looks like a recently formalised network-resource footprint tied to an existing registered organisation, not a long-running public anycast platform with years of externally visible operational history.

That distinction is the useful reading. A registered ASN is a foundation for network operations; it is not the same thing as a service assurance statement. For a buyer, partner, or incident responder, the phrase "AnyCast" should trigger follow-up questions about points of presence, upstream diversity, route monitoring, failover testing, DDoS handling, customer notification, and local support coverage. The public record proves only part of that stack.

The route evidence supports a small operating surface

The clearest route-level record is 217.18.48.0/24. RIPE records show a route object for that prefix with the description ParminCloud AnyCast, origin AS197330, and maintainer parmin-cloud-mnt. The route object was created on May 23, 2026, the day after the aut-num entity, which makes it a natural companion record for the new ASN.

PEER.AS also describes AS197330 as originating one IPv4 prefix, no IPv6 prefixes, and being seen with one peer in the global BGP routing table. Its prefix listing for the ASN points to 217.18.48.0/24 and marks the prefix under Iran. That aligns with the RIPE organisation country field and with the directory's choice to treat the entity as a network operator associated with ASN and IP resources.

RIPEstat adds an important qualification. Its announced-prefixes data for AS197330 recorded 217.18.48.0/24 in a visible timeline from July 1, 2026 to July 4, 2026, but its AS overview for July 15, 2026 marked AS197330 as not announced. RIPEstat's prefix overview also marked 217.18.48.0/24 as not announced at the July 15 query time, and its routing-status view reported zero of 326 IPv4 RIS peers seeing the prefix then. The last-seen origin for the prefix was AS197330 on July 4, 2026.

That does not prove the network is abandoned or non-operational. BGP views are measurement systems, and RIPEstat itself notes that some outputs exclude routes with very low visibility. But it does mean the publicly observed footprint is small and, at the checked timestamp, not globally visible through RIPEstat's RIS view. A reader should treat the evidence as proof of a registered and recently active route identity, not as proof of resilient global anycast deployment.

Declared upstream policy is not the same as observed reach

The AS197330 aut-num entity declares import and export policy with three ASNs: AS42337, AS48147, and AS24940. In registry terms, these entries say what routing relationships the operator has declared for the entity. They are useful clues because they show which upstream or adjacent networks the maintainer intended to announce through.

They should not be overread. The live measurement evidence captured for this article did not show AS197330 announced at the RIPEstat query instant. PEER.AS showed one peer, while the RIPE aut-num entity declared policy toward three ASNs. The gap is not necessarily a contradiction, but it is exactly the sort of gap that matters in network due diligence: registered policy, third-party BGP views, and the current route table can disagree in timing and visibility.

For a cloud or infrastructure buyer, that gap changes the question. The question is not "does ParminCloud-AnyCast exist?" The evidence says it does as a registered network identity. The better question is "which parts of the service are live, monitored, redundant, and supportable today?" Public records cannot answer that without more operational disclosure.

Support accountability is visible, but still limited

ParminCloud's public accountability is strongest in RIPE contact data. The organisation entity names admin and technical contact handle IA7464-RIPE, and it links to abuse contact AR77453-RIPE. The abuse role publishes [email protected], which is the most direct public support signal in the frozen evidence pack. The contact roles also tie back to the Qom address already present in the organisation record.

That is a useful minimum. It gives counterparties an abuse route, a registered maintainer trail, and a jurisdictional clue. It also makes the parmin.cloud domain relevant to identity verification, because the abuse mailbox uses that domain while the RIPE organisation name points to PARMIN CLOUD COMPUTING LLC.

Still, an abuse mailbox is not a customer support model. It says where unwanted traffic reports should go; it does not say whether enterprise incidents receive round-the-clock coverage, whether English-language escalation exists, whether the company offers service-level commitments, or who is accountable when routing drops out of public view. The public evidence supports accountability at the registry layer, not assurance at the customer operations layer.

Locality is part of the risk question

The locality evidence is straightforward: RIPE lists the organisation country as Iran and the address in Qom. The route prefix was also marked under Iran by PEER.AS. For some customers, that may be commercially ordinary. For others, especially teams with cross-border data, sanctions, procurement, or latency-sensitive requirements, it is a diligence trigger.

The issue is not simply where the company is based. It is where control, logs, support labour, routing authority, and customer data handling sit. A cloud-facing network identity can touch operational metadata even when it is not hosting the application itself. If ParminCloud-AnyCast is used for DNS, CDN-like delivery, DDoS filtering, proxying, or edge routing, the customer needs to know which jurisdictions touch the service path and which staff can act during incidents.

The public record does not answer those questions. It gives a location, a registered organisation, an ASN, a route object, and an abuse channel. That is enough to start a responsible vendor file. It is not enough to close one.

The practical reading

ParminCloud-AnyCast should be read as a recently established, RIPE-anchored network identity with one visible IPv4 route record and limited public routing visibility at the July 15, 2026 measurement point. That is a meaningful status. It is more substantial than a bare website claim, because the evidence reaches into registry and routing systems. It is also less substantial than a mature service profile, because the evidence does not show current broad route visibility, IPv6 coverage, a public interconnection profile, published service architecture, customer documentation, or operational performance history.

That makes the evidence useful for monitoring, not for reliance without questions. A network buyer, cloud customer, or security team can use AS197330, ORG-PCCL4-RIPE, 217.18.48.0/24, the RIPE role records, and the PEER.AS view as a compact evidence file. The file says where to start: verify whether the route is currently announced, ask which of the declared upstream policies is active, request current route collectors or looking-glass output, and confirm whether the parmin.cloud abuse contact is staffed for operational incidents or only registry compliance.

The same file says what not to assume. It does not show a global anycast mesh, multiple live points of presence, customer-facing service terms, traffic-engineering practice, mitigation capacity, or a history of stable announcements. Those may exist outside the public record, but they are not proved here. For a name that includes "AnyCast", that gap is material, because anycast assurance depends on distribution, withdrawal behaviour, health checks, and incident coordination. A single recent prefix entity can establish intent and identity; it cannot prove that user traffic will fail over cleanly under pressure.

The operator can close that gap with current evidence rather than broader claims: live announcement data, route collector views, a maintained looking glass, published support channels, and a clear explanation of which services use AS197330.

The safest conclusion is therefore balanced. ParminCloud-AnyCast has enough evidence-led identity to belong in an infrastructure directory. Its name, however, should not be treated as a promise of anycast resilience until the operator supplies current route health, upstream diversity, point-of-presence evidence, support escalation terms, and locality controls that match the risk its customers are asking it to carry.