Summary

  • RIPE NCC's Q3 2026 RIPEstat plan says AS names have been added and proposes community contributions for better network names; it also records demand for data showing which ASNs form one logical entity.
  • A preferred network name is a display claim about one ASN. A logical-entity grouping is an analytical claim about an ASN set. The second can change measures of network count, scale and concentration even when no registry right changes.
  • RIPEstat should keep the official WHOIS holder, preferred name and logical grouping as separate, source-labelled assertions with definitions, evidence, time, conflicts, corrections and downstream projection history.

Two useful ideas share one paragraph

RIPE NCC's quarterly plan contains the kind of product language that is easy to approve on first reading. RIPEstat has added AS names. It intends to add descriptions of BGP communities. A future contribution feature would collect better names for networks, acknowledging that a legal name may not be the name used in daily work. Then the same item notes demand for data about which ASNs form one logical entity. The information would be used in RIPEstat and to improve the public asn.txt file.

Nothing about that sequence is inherently suspect. Operators routinely know a network by a name that is absent from, or awkwardly represented in, a legal registration. A merger may leave old company names attached to operational systems. A holding company may possess resources used by a more familiar service brand. A university, public body or carrier may advertise several autonomous systems that engineers reasonably discuss as one network. A contribution route can make discovery faster and incident conversations clearer.

Yet the move from a better name to a logical group is not merely the next column in a contact list. The name answers, “What should a person call this network?” The group answers, “Which autonomous systems should a particular analysis treat as one unit?” The first improves recognition. The second changes a calculation.

That distinction matters most when the interface feels effortless. A user may search for a brand and expect RIPEstat to find the corresponding ASN. That is a good product outcome. The same user may download a grouping and count networks, rank their footprint, estimate concentration or combine observations across autonomous systems. If both values arrive as one unqualified identity, an editorial convenience has acquired analytical authority without ever saying what kind of authority it is.

The current holder has a stated source

RIPEstat already supplies a useful boundary. Its AS Overview documentation describes the holder field as the resource holder name according to WHOIS. The service's data-source documentation also makes clear that RIPEstat combines internal RIPE NCC sources with external ones. In other words, the product is not a single database pretending that every value has the same origin. It is a presentation and API layer over different evidence surfaces.

The frozen AS3333 example shows the current path without suggesting a defect. In the captured asn.txt file, the row reads 3333 RIPE-NCC-AS Reseaux IP Europeens Network Coordination Centre (RIPE NCC), NL. The captured AS Overview response gives the corresponding holder label without the country suffix and says the ASN is announced. The example is mundane by design. It shows that a label can travel from registry evidence into a compact file and an API response.

The frozen asn.txt object is also large enough to matter as infrastructure: 6,195,825 bytes and 122,241 lines at capture. It has no header that can explain a field's authority on each row. Its virtue is precisely that it is simple to download and parse. That simplicity creates a design constraint. If a future row blends an official holder, a contributed preferred name and membership in a contributed ASN group, consumers need another machine-readable place to discover which assertion they received.

RIPEstat's Data API is not incidental plumbing. Its documentation calls it the public interface to RIPEstat data and the sole source for the service's own UI and widgets. A source decision made at the API can therefore propagate into RIPEstat's visible pages and into third-party software. Provenance is not an optional paragraph for specialists; it is part of the value's type.

A name claim can be modest

Consider the strongest case for a preferred network name. An official holder may be “Example Infrastructure Holdings Limited,” while operators use “ExampleNet.” Showing the familiar name beside the holder can save time. It can improve search, make an outage discussion intelligible and reduce mistaken matches with similarly named legal entities. A well-grounded contribution may be more current than a field maintained for a different legal purpose.

That assertion can remain modest. It can say: for AS X, contributors or maintainers propose label Y for operational display, based on these public references, reviewed on this date. It need not say that Y owns the ASN, controls every route originated by it, holds the corresponding certificates or speaks for the legal entity. The official holder can remain visible as a separate registry-derived value.

There can also be more than one useful name. A network can have a legal holder, an operational brand, an historic name and a local-language name. The right interface might select one for search while preserving the alternatives. Treating preferred name as an assertion rather than a canonical replacement makes disagreement manageable: another contributor can challenge the evidence, the holder can respond, and a later name can supersede rather than erase the earlier one.

This is where community contribution is especially strong. The cost of correcting a display label can be low, the benefit immediate and the claim reversible. If the source and date travel with the value, a consumer can decide how much weight to give it.

A grouping claim changes the unit

“Which ASNs form one logical entity” is harder because the noun is undefined in the checked plan. Logical for what purpose? Two ASNs can share a brand but not a legal owner. They can share a parent company but have separate operating teams. They can use the same routing policy during a migration and later separate. One ASN can serve several brands. A network can acquire another company without immediately combining its autonomous systems. A research group may want an organizational group, an operational group or an economic-control group; those are not necessarily identical.

The checked source does not say that RIPE NCC intends to collapse these cases. It does not publish a grouping schema, contributor rules or a definition. That is exactly why the distinction belongs in the design before the data becomes convenient.

Suppose an analyst counts each ASN as one network. A grouping may reduce double-counting by joining ASNs used by one operational organization. That is a legitimate improvement. Suppose another analyst is measuring routing-policy diversity. Combining the same ASNs could hide real separation. A competition researcher might interpret one group as common ownership; a security team might infer common control; a sanctions screen might infer a common legal subject. None of those stronger meanings follows merely from the phrase “logical entity.”

Grouping therefore needs a declared purpose and scope. “Treat these ASNs as one operator group for this RIPEstat view as of date D” is a different claim from “these ASNs share ultimate beneficial ownership.” A data model should be able to represent the first without appearing to certify the second.

The risk is not only a false positive. A flat group can become stale. Companies split, brands are sold, operations migrate and ASNs change hands or purpose. If the group has no valid-from time, supersession history or correction record, later users cannot tell whether an old analysis reflected the state then known or today's rewritten classification.

Three identities, three labels

The minimum safe model begins by refusing to put three claims in one slot.

The official holder answers a registry question: which holder name does the WHOIS/RIR record provide for the resource? It should be labelled with that source and an observation time. It is not a complete map of branding, beneficial ownership or operational control.

The preferred network name answers a usability question: which name best helps people find and discuss this network? It should identify who proposed or maintained it, what evidence supports it, when it was reviewed and whether the holder confirmed or challenged it. It should not silently replace the holder.

The logical grouping answers an analytical question: which explicit ASN set should be treated as one unit under a stated definition, scope and time? It needs more than a name. It needs membership, evidence, the intended analytical purpose, conflict handling and history. It should not silently become a legal or routing-authority relationship.

The display can still be clean. RIPEstat might show a familiar name prominently, place the holder below it and offer a clearly labelled group view. The complexity belongs behind the interface in a record that machines can inspect. Hiding the distinctions does not remove complexity; it transfers it to every consumer, who will invent a private interpretation.

A contribution needs a claim type

A useful contribution object could be small. Its first field, claim_type, should state whether the assertion is preferred_network_name or logical_asn_group. The subject would be one ASN for a name, or an explicit ASN set for a group. The record would carry the proposed label or a stable group identifier, the contributor's identity and authority class, cited evidence, the contributor's declared basis, valid-from or as-of time, and the review state.

The authority class matters because not all knowledge is the same. A holder-maintained assertion, an operator contribution, an external researcher classification and an automated inference may all be useful. They should not appear interchangeable. Nor should a “verified” badge imply official registry authority unless that is exactly what was verified.

Conflicts should be data, not an embarrassment removed from view. Two credible contributors may propose different operational names. A holder may dispute a group assembled from public routing evidence. A merger may produce a temporary interval during which more than one classification is reasonable. The record should preserve competing assertions, responses and the rule used by a particular projection.

Corrections need links. If one assertion supersedes another, the new record should name the old one and explain whether the change corrects an error, reflects a later event or applies a different grouping definition. Historical snapshots must remain reconstructable. Otherwise a downloaded dataset can change meaning while retaining the same apparently simple value.

Finally, the record should show where it travels. A value displayed only in a search suggestion has different consequences from a group emitted through the Data API or encoded into asn.txt. Downstream projection is part of the claim's governance because reuse magnifies both utility and ambiguity.

Preserve the small file by adding a companion

The flat asn.txt format has real value. It is easy to fetch, grep and join. The answer is not necessarily to turn every line into a large JSON document. RIPE NCC could preserve the file and provide a versioned companion manifest or API endpoint that explains the selected label, its claim type, source, observation time and supersession record.

If the file continues to contain one human-readable name per ASN, its documentation should say which projection rule selected that name. Was it the official holder, an approved preferred name, or a fallback? If group data is published separately, the group record should carry an explicit definition and membership time rather than being inferred from identical labels.

This approach protects compatibility. Existing scripts continue to receive a compact lookup. More careful consumers gain a route to the provenance they need. RIPEstat's own UI can show a simple answer while allowing a reader to inspect its basis. Corrections can change a projection without pretending the earlier value never existed.

The alternative is a single canonical identity assembled from unlike evidence. That may look easier at launch. It becomes difficult once users ask why two ASNs were joined, why a familiar brand replaced a holder, or which historic value a published analysis consumed. Provenance added after the fact cannot always reconstruct those answers.

What the plan does not yet tell us

The public material checked for this article does not establish who will be allowed to contribute, which evidence will be required, how “logical entity” will be defined, whether holders can confirm or challenge assertions, how conflicts will be displayed, how long claims remain valid, whether confidence will be exposed, or how corrections will propagate. It does not show a deployed contribution interface, schema, group dataset or rollout result.

Those absences are questions, not findings of misconduct. A quarterly plan is expected to be shorter than a finished data contract. The constructive point is temporal: publish the claim boundaries before the data is adopted, because users will otherwise infer meaning from placement and product authority.

Nor does the evidence show that a current RIPEstat name is wrong, that the AS3333 record is disputed, or that analysts are already making erroneous decisions from the planned group data. The proposal is preventive. It aims to preserve a useful contribution path without letting convenience rewrite the difference between registry fact, community description and analytical classification.

Sources