Summary
- Growing networks needed distinct address ranges and manageable routes; RIPE’s 1992 example shows why grouping blocks mattered.
- In 1993, 83 local registries assigned 16,871 network numbers; 157,004 database updates counted separate record work.
As European networks expanded, the Internet faced a shared engineering problem: give each network a distinct address range and keep the directions to it manageable for routers carrying traffic. RIPE’s 1992 report makes the routing trade-off concrete. A hypothetical Organisation A needs eight Class C numbers, the small network blocks of the era’s class-based system. If the numbers are consecutive, one route can cover them; if scattered, more route-table entries are needed. A route-table entry is a direction a router consults to forward packets. Grouping neighboring blocks meant fewer separate directions to maintain and use.
The 1993 system divided the work: local providers made ordinary assignments, while the NCC delegated larger blocks and coordinated exceptions. The documents show the design response to growth; they do not establish that it prevented a particular failure or congestion event.
The annual report’s two totals count different tasks. Local registries assigned 16,871 network numbers. Separately, the NCC processed 157,004 database updates. An assignment granted address space to a network; an update changed an operational record about a network, route, DNS domain or contact. Operators could consult those records to coordinate networks. The report does not map updates one-to-one to assignments, so the larger update total is not a count of networks or organizations receiving addresses.
Two jobs, one system
Providers acted as the first assignment desk for ordinary requests. The NCC delegated address blocks to their local registries, supported them and handled large requests or places without an appropriate local registry. Providers could judge requests from the networks they served; the NCC controlled the upstream blocks and kept exceptions coordinated. RFC 1366 argued that regional registries could better serve communities across geography and language. RFC 1466 updated that framework in 1993.
An earlier quarterly report makes the referral path more concrete. In 1992, the NCC said it supplied numbers to service providers and network information centres, which then reassigned them to organisations. Individual applicants were generally directed to their service provider; the NCC could act directly in exceptional cases. RFC 1366 had set out the broader rationale: regional registries could serve communities across language and geographic boundaries, while the Internet Registry remained a root and default for places without a delegated registry. RFC 1466 updated that design in 1993.
The record was wider than the allocation queue
The same 1993 report says the RIPE network-management database held information about IP networks, DNS domains, routing policies and appropriate contacts. Its entry count had accelerated after the European registry system became fully operational in September 1992. During 1993, the NCC redesigned the database update process and made it fully automatic for almost all updates. It processed 157,004 updates during the year.
That number is not a count of address assignments. Nor does the report define an update as one object, one person, one request or one automated decision. The distinction matters: 16,871 network numbers describe the year’s assignment activity; 157,004 describes database-update activity. The database supported more than number allocation, and automated updates do not tell us whether an assignment request was assessed by a person. The report gives a volume, not the workflow’s error rate, labour cost or review burden.
Why the local layer mattered
The system put assignment work near the providers that served networks, but kept a central NCC for delegated blocks, support, exceptional cases and coordination. That structure offered a way to handle more requests without requiring one office to make every local assignment. It also made local providers part of the registration mechanism, not merely consumers of a central service.
The report presents this as an arrangement that pursued fairness and regularity, but it is the NCC’s own description. It does not establish equal treatment across the 83 registries, how many requests were refused, or how consistently local procedures worked. Nor does the count tell us how many Europeans were online. It documents an operating model and its workload, not adoption.
The early lesson is narrower than a claim that registries were “just databases.” The public record depended on a distribution of authority and service: providers assigned locally, the NCC delegated and coordinated, and a database retained several kinds of operational information. By 1993, the record system was being automated at scale, but the allocation system still depended on people and institutions deciding where a request belonged.
Sources: RIPE NCC Annual Report 1993 (RIPE-113); RIPE NCC Quarterly Report, Issue 1, June 1992 (RIPE-062); RFC 1366; RFC 1466.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
