Summary

  • The RIPE NCC member directory entry for Orange Espagne SA records two areas serviced, ES – SPAIN and PT – PORTUGAL, which is a statement about an administrative filing and not about network operations.
  • Routing authority is settled by a different class of record altogether: registry authorisation objects, resource certification state, and independent observation of what was actually announced.

A registry page that answers a narrow question looks, at a glance, like it answers a broad one. The entry for Orange Espagne SA on the RIPE NCC's public list of members carries an "Areas serviced" block containing two items: ES – SPAIN and PT – PORTUGAL. Those two country names are what the section holds. It offers no autonomous system number and no address prefix, because recording them is not what the section is for.

That is worth stating plainly before anything else, because the block is easy to misread when you arrive at it with an operational question in hand. What the entry certifies is enrolment: that a registry which publishes and maintains a member list organised by country lists this company as a member, and that the registry's own service-area taxonomy places the company in two countries. The unit of the record is the country. Countries describe a declared service area. They are a coarse administrative instrument, and a network's actual reach is measured in prefixes and peerings that pay no attention to the borders in a service-area list.

The page's own address on the ripe.net site ends in a short segment that bears no relation to the company's present name. Small as it is, that detail is instructive: these entries are maintained across years by administrators, through reorganisations and rebrandings, and the address outlives the naming. A record like this is a continuity of paperwork. It is not a snapshot of a network.

The question people bring to the page

Almost nobody reads a member listing for its own sake. They arrive with a name and need something operational: does this company run network infrastructure, what does it announce, is it the entity behind a particular route or a particular incident? The membership entry is often the first authoritative-looking page that comes back, published by a registry, with the company's name and a country beside it.

It is tempting to read presence as capacity, and existence on a registry page as evidence of authority over the numbers on that page. The two propositions are logically independent. An enrolled member can announce nothing at all. An announcement that carries a company's name can originate from infrastructure the registry never recorded against it. Enrolment says the organisation is known to the registry. It says nothing about what the organisation's routers say to the internet, and it cannot be used to settle that question in either direction.

This is not a pedantic distinction. It fails in both directions, which is what makes it dangerous. A membership entry can change for reasons that have nothing to do with routing — a merger, a billing address, a sales team that now covers a third country — and a routing event can occur with no change whatsoever to the entry, because the listing does not participate in routing. Anyone who screens suppliers, runs due diligence, triages an incident or verifies a claim for publication on the strength of one page will get confident wrong answers at precisely the moment accuracy carries a cost.

What would actually settle it

Authorisation questions are answered by records built for authorisation. Three classes do the work, and they are worth distinguishing because their failure modes differ.

The first is the Internet Routing Registry, or IRR: route and route6 objects, and aut-num objects, that record intended routing and the party who maintains the record. These are distributed, member-maintained databases. They carry maintainer identities and modification times, and they state intent as recorded rather than behaviour as observed. Their characteristic weakness is staleness — an object nobody has touched for years will still answer a query with complete confidence.

The second is resource certification, RPKI: certificates and Route Origin Authorisations that bind address space to a key holder, from which a validator returns one of three states for a given prefix and origin pair. This is the strongest machine-checkable statement of authorisation available today. It is also a statement about a key rather than about a person, and about authorisation rather than about action. A cryptographically valid authorisation can coexist with an announcement that never used it, and an invalid one can reflect a misconfiguration just as easily as an attack.

The third is observation: BGP data collected by parties other than the network being described, carrying timestamps and vantage points. This class is the least authoritative in the abstract and the most decisive in practice, because it is the only one that reports what happened rather than what was intended or permitted.

Put together, the division of labour is clean. Authorisation lives in the first two. Behaviour lives in the third. A membership listing lives in neither. When the three disagree with each other, the disagreement is the finding, and it is far more interesting than any single record read alone.

Why the register still matters

None of this makes the member list worthless; it makes it precise. The entry tells a reader that the company is enrolled, which registry holds the relationship, and which countries the registry associates with the organisation's service area. That is a real fact about a real filing, and it is the correct starting point for a line of enquiry: it identifies an organisation and the administrative universe it sits in.

The mistake is stopping there and calling the enquiry finished. A register of presence maintained for administrative purposes answers administrative questions with high reliability. Asking it to certify what a network may originate is asking a filing clerk to sign off on a routing table. The record is not defective. The inference is.

On 21 October 2026 I retained a section-level extract of the entry's serviced-area block from the RIPE NCC member directory page for Orange Espagne SA. The extract covers that section rather than the whole page, so nothing here asserts what else the page does or does not contain. The claim is narrower, and I think more useful: the part of the entry that answers the question readers actually bring to it holds two country names and no routing identifiers, and every operational question therefore has to be taken to the records that were built to answer it.