Summary
Founding boundary. RIPE’s 1989 terms reserved executive authority over each collaborating network to its own organisation. RIPE-019 subsequently proposed a small service bureau with three task classes: registry work, network information management and general RIPE support.
Recorded authority and measured conclusion. By 1992, the NCC maintained the central database and acted as a delegated number registry. RIPE-065 documented a rule under which Class B requests would carry justification for NCC review. European NICs and NOCs accepting Class C blocks assumed reporting, anti-stockpiling and unused-number return duties. Later internal review and management reporting described limited delegated operation at significant scale. The records establish consequential administration within a defined registry channel, alongside continued operator control of networks. Any broader later authority would require a new instrument.
The coordination problem
RIPE-001 begins in Amsterdam on 29 November 1989, before the NCC existed. Its six authors were Rob Blokzijl, Mats Brunel, Francois Fluckiger, Daniel Karrenberg, Olivier Martin and Enzo Valente. RIPE expanded its name as “Réseaux IP Européens” and identified Europe as its area of relevance. The terms responded to wide-area IP systems extending beyond local networks across national and international links. They described European IP networking as a collection of national and international systems managed by separate organisations.
RIPE’s objective was the administrative and technical coordination required for the operation and expansion of a pan-European IP network. It encouraged every party operating a wide-area IP network to participate and promoted interconnection within Europe and with other continents. The practical challenge arose between independently run systems: operators needed reliable contacts, exchanged technical information and a forum for agreeing common practices. “Pan-European” named the reach of that coordination problem. The component networks retained their separate management lines, constituencies and operating responsibilities.
The terms assigned RIPE three connected roles. It was a forum for exchanging technical information and experience, a focal point for activities of common interest and a place to establish agreement on network-management practices and the operational management of interconnected networks. All RIPE documents were to be publicly available. Publication gave operators a common written record that could circulate beyond a meeting, yet implementation still passed through the organisation running each network. RIPE could convene discussion, preserve conclusions and organise shared work without absorbing the facilities or staff of its participants.
Its immediate institutional product was coordination among operators: a common arena in which separately managed networks could address the points where their systems met.
One sentence supplied the decisive boundary. RIPE was not a network service provider, and every collaborating IP network remained under the executive authority of its respective organisation. Routers, personnel and operating decisions therefore stayed with the network organisations. That allocation also frames the later NCC. A specialised office could perform important regional functions and exercise judgment inside a delegated procedure without inheriting executive command over participating networks.
The historical question has two dimensions: how much consequence attached to an entrusted task, and how far the instrument carrying that task extended. Technical interdependence may make consistent records and shared procedures indispensable, but interdependence alone leaves managerial boundaries intact.
RIPE-019, dated 16 September 1990 and written by R. Blokzijl, Y. Devillers, D. Karrenberg and R. Volk, addressed a practical weakness in the cooperative model. RIPE meetings and voluntary groups could start projects, but repetitive administrative work required attention every working day. The proposal called for dedicated technical staff and a known office where records, exchanges and requests could become assigned responsibilities. RIPE-019 also presented the centre as a building block in the developing global Internet administrative framework, with a reference to RFC 1174.
Its stated main objective was support for networking organisations cooperating in RIPE, including coordination that would enable their own NOC staffs to provide services. It presented permanence as an answer to irregular execution, not as a constitutional transformation. Paid staff could maintain common services between RIPE meetings, allowing volunteers to concentrate on development work and participating organisations to continue operating their own systems. The proposed centre was therefore a service bureau in the literal sense: a compact office created to give recurring regional tasks a stable home.
The proposed resources matched that purpose. RIPE-019 specified 1.0 full-time equivalent for a manager, 1.0 for technical work and 1.5 for administration. It contemplated X-window workstations, a minicomputer capable of housing databases, strong IP and mail connectivity, OSI connectivity, two offices and normal supporting services. Travel assumptions covered all RIPE meetings, six other European meetings and four meetings outside Europe each year. RIPE-035 later asked for minimum willingness periods of three years for the manager, one year for the technical officer and two years for an administrative officer.
It also treated proximity to an operating NOC and other RIPE activities as essential. The manager specification combined large-scale Internet technology, management and international work; the technical post required large-scale network and international experience. Administrative staff were expected to use advanced computing equipment as well as handle office work. Together, these proposals described the skills, equipment, location and continuity expected of a small technical office.
Small scale did not make the proposed work trivial. A maintained register could become a shared reference; an office handling number requests could occupy a consequential point in an allocation chain. RIPE-019 anticipated routine maintenance alongside bounded judgment, but its centre would receive functions from RIPE, work with participating organisations and coordinate with an upstream Internet Registry. Its proposed support list named global status gathering, performance monitoring, European DNS distribution, operational-tool documentation and management of the RIPE information server.
That structure places the NCC between two misleading caricatures. It was more than a copying desk because some entrusted transactions could affect access to recognised registration channels. It was less than a regional sovereign because the surrounding operators, registries and coordination bodies retained their own functions. Each claimed power must therefore be traced to the specific act, instrument and actor that supplied it.
Chronology matters as much as wording. RIPE-001 set terms for a cooperative forum. RIPE-019 proposed a centre. RIPE-035 supplied an activity plan. These documents record successive designs, not a single moment of execution. Operating procedures and status reports later show selected functions moving into practice, and they sometimes reveal a portfolio different from the one planners imagined. The founding history is consequently a sequence of institutional states: coordination principles in 1989, a service-centre proposal in 1990, a detailed work programme in 1991 and documented operations during 1992 and 1993.
Following that sequence keeps the proposed office, the planned programme and the observed registry service analytically distinct.
The entrusted task
RIPE-019 named exactly three task classes: the registry function, network information management and the general RIPE support function. End-user support and network operations remained with the network-operation staffs of participating organisations. The proposal also divided labour between centralised tasks performed by NCC employees and distributed tasks carried out by participating organisations under NCC coordination. Four relationships tied the office to RIPE: RIPE would define the centre’s tasks and functions; the NCC would report to RIPE; RIPE organisations would participate in its work; and RIPE would review its operations regularly.
Periodic RIPE evaluation accompanied the distributed programme. In this design, the centre received its field of work from RIPE and combined its own staff activity with contributions from the wider community.
The proposed registry function placed the centre between European local registries and the Internet Registry. It would maintain a register of IP network numbers and autonomous-system numbers, obtain blocks for allocation through local registries, collect information supplied locally and make the compiled material globally available. It would also handle requests beyond local capability and coordinate closely with the Internet Registry.
Local registries remained responsible for allocation from their blocks; the regional centre maintained the common register and took cases that moved beyond local capacity; the upstream registry remained part of the arrangement. The proposal thus created an administrative junction where information and exceptional requests could travel between local and global levels.
Network information management formed the second task class. RIPE-019 identified information about IP network numbers, autonomous-system numbers, DNS domains and associated people. It described movement in four directions: from European organisations to the centre, from the centre back to those organisations, between the centre and coordination bodies outside Europe, and from the centre to the wider community. Databases and interrogation tools would make this information available through services associated with IP and OSI. The proposal called the centre an authoritative source for information concerning the RIPE community.
That authority attached to maintenance and presentation of a shared dataset whose underlying facts often originated with organisations closest to the networks.
The proposal also drew a purpose boundary around personal information. Its database was not intended as a general white-pages service. The authors called for privacy to be studied in light of European law and identified individual permission as the minimum condition for including personal information in a publicly accessible database. The proposal therefore distinguished operational contact data from a general directory of people. Its treatment of consent was a design statement: contact information connected to network administration belonged within the proposed information service only under the stated minimum condition.
RIPE-019 placed the privacy question beside the centre’s technical requirements before any later status report described the database in operation.
General RIPE support was the third class, but the detailed assignments came in RIPE-035, dated 5 May 1991. That activity plan directed the NCC to keep the RIPE document store online and readily accessible, provide technical and clerical support for RIPE studies and task forces, and assist with the organisation of RIPE meetings. It expected meeting attendance of about 40 people in the near future. Study support was meant to carry work between meetings; clerical assistance would help organisers prepare productive sessions.
These tasks converted RIPE-019’s broad support category into a set of recurring responsibilities attached to documents, working groups and meetings.
RIPE-035 called itself a technical annex to RIPE-019. It said the relevant tasks had proved extremely difficult to execute regularly through voluntary effort and expected centralised execution to improve efficiency. For the database, it listed six initial object classes: networks, responsible persons, domains, routers, international lines and name servers. Planned work included collecting entries, checking individual entries and testing the database’s consistency and integrity. Secondary copies could be installed on request, with the NCC tracking those copies and maintaining consistency.
Exchange with centres outside Europe was supposed to give database users a uniform global information set. For secondary copies, the NCC was to maintain an online record of sites and keep their contents consistent. The exchange assignment covered both coordination and execution with NCCs outside Europe. Monthly maps were planned as PostScript files available online for remote retrieval and reproduction. The plan translated the earlier information mandate into individual duties that later reports could compare with actual activity.
The technical programme reached beyond database custody. RIPE-035 planned records of connectivity within Europe, between Europe and other continents, and inside countries or networks, with domestic and internal mapping dependent on NOC cooperation. The centre would keep operational contacts for network and security incidents, maintain recommended DNS software and known-bug information, test name-server interworking, and gather selected traffic and performance data. Development work covered database management and query tools, statistics and performance tools, DNS quality-control utilities and tools for drawing network diagrams.
The whois utility was to be maintained as a file-server program for remote database interrogation. Specialised tools would come with basic support, not a promise of full support for every installation. Operators remained central to supplying observations and acting on network conditions. The operational-contact list would serve NOCs during network and security incidents, with a weekly update subscription. DNS change and known-bug reports had their own subscription service; detected name-server errors were to be reported to responsible people and followed through corrective action.
RIPE-035 also proposed a specific reporting design. Weekly reports would cover database changes and entry statistics. Monthly output would include connectivity maps. Quarterly reports on activities and outstanding problems would go to participating RIPE organisations and the RARE CoA. The NCC would report to RIPE meetings, which were then held three times a year, and an annual report would be produced by 31 January following the reported year. This was a planned weekly, monthly, quarterly, meeting-based and annual cadence.
The plan further stated that regular progress reporting—weekly, monthly and yearly—was foreseen across all work items, while the quarterly administrative reports had participating RIPE organisations and the RARE CoA as named recipients. It made recurring disclosure part of the proposed work programme and placed unresolved problems before named institutional audiences. Later quarterly reports became inputs to RIPE-099, but that observed use belongs to the review period, two years after RIPE-035 set out the wider design.
RIPE-052 provides a compact operating scene. Daniel Karrenberg’s database status report, published on 24 April 1992, covered 25 March through 24 April. It recorded 4,574 queries to the RIPE NCC whois server, including 169 originating within the NCC, an average of one query every ten minutes. Karrenberg called that volume astonishing for a service he described as not widely publicised. The unit was a query, not a person or an outcome. The report also said central maintenance had moved from volunteers to the NCC, requested NOC cooperation, preferred pre-checked bulk updates and stated that information from any source would be accepted. By April 1992, a named custodian was maintaining the central database and recording a month of server transactions. The report directed updates to auto-dbm@ripe.net, with current templates available by anonymous FTP from archive.ripe.net or by email from the NCC. It said a new database-software distribution was almost ready and invited sites to test it. Karrenberg’s predicted improvements in update frequency and consistency remained prospective, separate from the measured query total.
The entrusted programme consequently combined three different institutional intensities. General support kept documents, studies and meetings moving. Information management maintained a shared reference assembled through distributed contributions. Registry work placed the centre inside a resource-distribution chain where a request or inventory instruction could carry direct administrative consequence. Participating organisations still operated their networks, supplied local information and performed distributed work; RIPE defined and reviewed the programme.
Central custody mattered because many actors consulted or updated the same records, yet the described systems remained under their respective operators. The transition from shared information to delegated registration is where service work began to acquire bounded operational power.
Operational power
RIPE-065 supplies the clearest period evidence of registry authority entering operation. Published on 1 July 1992 and later obsoleted by RIPE-072, it stated that from 1 May 1992 the RIPE NCC was acting as a delegated registry for IP network numbers to European NICs and NOCs. The procedure favoured giving numbers to service providers and NICs over making assignments directly to individual organisations. NICs and NOCs would reassign the actual numbers to requesting organisations. “Delegated” identified authority received within an existing registration system.
The NCC occupied a regional point, intermediaries carried out reassignments and organisations received numbers downstream. RIPE-065 records the operating arrangement applicable from May 1992. RIPE-099 later placed a broader transition around this procedure. Its internal panel said the Internet Registry asked in July 1992 that the NCC handle all IP network-number applications from European organisations. After rapid consultation with the RIPE chair and relevant working groups, the NCC complied, although the panel said every necessary procedure had not yet been fully established.
From 1 August, the Internet Registry forwarded European email and letter applications to the NCC.
For Class B space, RIPE-065 documented a prospective procedure. A service provider could submit a request carrying justification about the requesting organisation, and the RIPE NCC would review that justification. The provider was the intermediary making the submission; the organisation was the subject described; the centre held the documented review function. This language establishes a rule for how such requests were to be presented and considered. It supplies neither a completed application nor a completed NCC determination.
Its significance lies in the allocation of a prospective administrative role: the procedure placed review of the required justification at the regional office within the number-registration chain.
Class C blocks brought continuing duties for one precisely identified group: European NICs and NOCs that accepted those blocks. They had to report full reassignment information promptly to both the RIPE NCC and the US NIC. Individual reassignments had to be entered because the RIPE database then lacked support for block entries. The intermediaries were instructed to avoid reassigning numbers ending in 0 or 255, prevent stockpiling and return numbers that remained unassigned upon the RIPE NCC’s first request. Those NICs and NOCs retained responsibility for assigning actual numbers to organisations.
RIPE-065 attached its reporting, anti-stockpiling and unused-number return obligations to intermediaries holding delegated Class C inventory.
This arrangement gave the centre a consequential position without turning it into a general regulator. The Class B rule assigned it a prospective review function concerning submitted justification. The Class C procedure made it the recipient of reassignment information and the actor entitled to request the return of numbers still unassigned. Each power had a defined object: justification accompanying a request, registry information, or unused inventory held by a participating intermediary. The procedure said nothing about the block holder’s routers, employees, customer contracts or routing policy.
Its administrative force arose from placement inside the allocation mechanism, where a narrow instruction could shape the handling of recognised number resources.
RFC 1366, dated October 1992, provides external context rather than an NCC charter. It described the Internet Registry as the default wherever no delegated registry had been identified. IANA and the Internet Registry could empower a regional body specifically to provide the network-number registration function for a geographic area, and the RFC presented one registry per region as important to efficient and fair sub-allocation. Direct subscriber access to the Internet Registry remained available when necessary, even where referral to a regional body was possible.
Responsibility for Class A and Class B space also remained with IANA and the Internet Registry at that time. The RFC proposed a distributed registration architecture with regional bodies performing a specialised function.
The transactions visible in these documents should remain separate. A whois query interrogated existing records. A database update changed information supplied to the common repository. The Class B rule assigned prospective NCC review of justification carried with a request. A Class C reassignment report entered a downstream transaction into the registry, and a return request concerned numbers still held without reassignment. These activities shared an informational infrastructure but involved different actors, objects and consequences.
RIPE-052’s 4,574 queries measure server transactions during one month; they provide no proxy for allocation activity. RIPE-065 identifies the registry procedure, including the duties assigned to European NICs and NOCs.
Regional language described a service area and division of registration labour, not a public-law territory. The NCC handled European information and number requests within a system containing local registries, service providers, country registries, the Internet Registry and IANA. RFC 1366’s direct-registry fallback placed another path alongside the regional body. By mid-1992 the NCC had moved beyond proposal: it maintained the database and acted as a delegated registry under a stated procedure. Its influence attached to recognised administrative transactions, with independent operators and other registry layers still present around it.
That is substantial bounded authority—more consequential than passive recordkeeping and narrower than command over the European networks the records described. By the panel’s one-year count, the distributed system comprised more than 60 service-provider registries and 21 non-service-provider country registries, with more than 14,000 network numbers assigned by the European registry system. Those figures describe the system reported in RIPE-099 rather than an applicant or decision denominator.
RIPE-099 also described the route for work absent from RIPE-035: a working group or the NCC submitted a proposal to RIPE; RIPE discussed it; and the NCC implemented it after a positive conclusion. At the 13th RIPE meeting in September 1992, RIPE decided to coordinate technical development activities with RARE. The panel linked that decision to the European Route Server and Generic Internet Service Description projects, executed at the NCC with additional staff and independently funded resources.
Its statements that both projects concluded successfully and that the route-server work led to Policy Based Routing Implementation and Deployment in Europe were panel assessments. The documented actor chain ran from proposal and RIPE discussion to NCC implementation and, for those projects, to the September 1992 coordination decision.
The accountability gap
RIPE-099, issued on 25 October 1993 by R. Blokzijl, M. Sterba and W. Woeber, reviewed the NCC’s first 18 months from inside RIPE. The panel used RIPE-035 and the NCC’s quarterly progress reports as inputs. It recorded that operations began on 1 April 1992 with three permanent staff members. In the reviewers’ account, most planned goals had been met, though some activities had not begun or lacked sufficient progress; management had reported those shortfalls in due course. The panel also said activities absent from RIPE-035 had started with prior RIPE-community consent.
Its principal recommendation was that RIPE agree a new activity plan by January 1994, bringing the formal programme into line with the office’s changed portfolio. The review document said it had been approved as representing RIPE’s views. Its background counted more than 60 participating organisations and more than 450,000 reachable European hosts in September 1993, against a worldwide estimate close to two million. The panel’s service inventory included the database, delegated registry, coordinated statistics, DNS coordination, maps, software repository, document store and interactive information service.
For work outside the inherited plan, RIPE-099 described an adoption path. A RIPE working group or the NCC would put a proposal to RIPE, RIPE would discuss it, and the NCC would implement the proposal after a positive conclusion. This was the sequence the panel expected for adding work. Its account shows how RIPE discussion was meant to connect proposals with implementation, and it gives content to the reviewers’ reference to community consent. The panel also recorded a faster transition for registry applications in 1992, where consultation with the RIPE chair and relevant working groups preceded action under time pressure.
The two scenes reveal how the reviewers described ordinary programme adoption and an urgent expansion of registration work.
The review examined the database programme line by line. It said activity followed RIPE-035, that agreed objects and attributes had been added, and that new checking, maintenance and distribution tools were being implemented. Database distribution was possible and had taken place in a few cases. The panel attributed limited demand for copies to what it regarded as an extremely reliable central server. It also said an exchange format had been defined with InterNIC and Merit, locating delays in actual exchange outside the NCC.
Connectivity-record work was moving slowly, and the reviewers suggested that the more distributed approach pursued by the RIPE Connectivity Working Group might prove appropriate. The comparison separated delivered database functions, limited uptake and work still in development. It also said infrastructure not yet interconnected was recorded through the database only from the point when the NCC began registering European networks. Database-management tools were defined with the Routing, Local-IR and Database working groups, while improved client software was reportedly in wide use and integrated with common information-retrieval tools.
Several planned activities received a colder assessment. RIPE-099 reported essentially no progress in gathering traffic statistics and network-performance data. The panel regarded those activities as belonging primarily to network operators, though it allowed that the NCC might offer neutral storage for data supplied by providers. RIPE still needed to discuss the centre’s role in collecting quality-of-service information. The reviewers also found little progress on tools for network statistics and performance presentation and asked for a clearer definition of the NCC’s role and resources.
A repository and common naming scheme for network maps existed, but further development had stopped. The panel suggested that the map work might fit better as a special project, shifting attention from delay to the proper institutional home for the task. DNS quality-control tools were available from the NCC server, while the map programme had produced a repository and common naming scheme before further development stopped. The quality-of-service role still awaited RIPE discussion, separating operator-supplied measurements from a centrally assigned collection function.
Other services had become routine enough for the panel to describe concrete outputs. RIPE-099 reported operational contact lists implemented through mailing lists, an NCC archive holding DNS software and documentation, and monthly analysis of the European DNS space that produced host counts and error reports. It praised the document store, technical and secretarial assistance, meeting support and quarterly reporting. According to the reviewers, the quarterly reports described accomplishments and outstanding problems, supplied overviews of the European Internet and were presented at every RIPE meeting.
Here the quarterly reports were observed inputs and recurring presentations, distinct from the broader weekly, monthly, meeting and annual design proposed in RIPE-035. The panel said the first annual report had just been produced. It also described presentations of ongoing work and outstanding problems at every RIPE meeting, where many unresolved matters required RIPE participation and decision in the reviewers’ account.
Registry work was the largest activity missing from the original plan. RIPE-099 said the Internet Registry asked in July 1992 for the NCC to handle all IP network-number applications from European organisations. The NCC quickly consulted the RIPE chair and relevant working groups, then complied even though time had been insufficient to establish every necessary procedure fully. The panel stated the purpose as relieving the Internet Registry and improving response times for European organisations as early as possible. From 1 August 1992, it reported, the Internet Registry forwarded European applications arriving by email and letter to the NCC.
The panel’s account fixes the request, consultation, transition and forwarding arrangement to July and August 1992.
The panel said the NCC pursued a distributed registry from the outset. It sought to identify as many service providers as possible and delegate Class C blocks to them for reassignment. Country registries were invited to identify themselves so they could serve organisations lacking an IP service provider. After one year, RIPE-099 reported more than 60 service-provider registries, 21 non-service-provider country registries and more than 14,000 IP network numbers assigned by the European registry system.
The reviewers called the registry work extremely well handled and attributed the system’s organised growth to timely and accurate daily operation. Those appraisals belonged to the panel; the counts record the scale it reported for the first year.
A second expansion followed the 13th RIPE meeting in September 1992. RIPE-099 said RIPE decided there to coordinate technical development activities with RARE. The European Route Server and Generic Internet Service Description projects were then defined and executed at the NCC as part of the RARE technical programme. Additional staff and resources, funded independently from other NCC activities, carried out the projects, with the NCC contributing resources for their start and management. The panel reported both projects successfully concluded and said the Route Server work led to Policy Based Routing Implementation and Deployment in Europe.
It regarded the collaboration as beneficial and said core daily work had suffered no negative effect from the two projects.
Formal separation still left practical contact between project and core resources. In its conclusion, RIPE-099 said that hosting special projects automatically consumed some NCC management and technical attention, even though their staff and funding were separate. The panel characterised this contribution as intentional and outside RIPE-035. It used the point to support a revised activity plan that would recognise the office’s actual portfolio. The observation concerned classification and planning: separately financed projects could still call on the centre that housed and managed them.
By January 1994, the reviewers wanted the baseline to include the work the NCC had actually taken on. The review also said registry work had consumed much more resource than originally foreseen and noted that the activity itself was not explicit in RIPE-035.
The review also described smaller unplanned services. When prospective customers asked about Internet service, the NCC avoided choosing a provider. It resent the enquiry and requester’s contact details to a mailing list of service providers, whose members could contact the requester if they wished. The panel characterised this method as impartial and well received. It also reported regular requests for presentations about NCC work and European Internet procedures, interpreting their recurrence as appreciation.
The forwarding arrangement and presentations show the office acting as a neutral information junction in the reviewers’ account, with service providers making any subsequent approach. The panel said the NCC honoured many presentation requests from service providers and conferences to disseminate information about its work and European Internet procedures.
RIPE-113, Daniel Karrenberg’s Annual Report 1993, provides management’s year-end account. It described the NCC as supporting European Internet service providers, funded by those providers through a formal framework supplied by RARE. Management said the number of European Internet hosts registered in the domain-name system roughly doubled across 1992 and 1993. For registration, the report described 83 local registries operated by service providers and said the NCC delegated address space to them. It recorded 16,871 network numbers assigned by the European Internet registries during 1993.
The NCC also handled large requests and requests from enterprises lacking an appropriate local registry. These figures belong to the annual report’s stated populations and reporting period. Karrenberg identified himself as RIPE NCC Manager. RIPE-099 supplied an earlier funding picture: RARE provided the formal framework, while EARN, RARE’s national members, Israel and EUnet funded the first operating year. That account and RIPE-113’s provider-funding description belong to different reporting moments.
Likewise, RIPE-099’s 60-plus provider and 21 country registries and RIPE-113’s 83 local provider registries use distinct periods and populations.
The same report gave a detailed database account. RIPE-113 said the database held information on IP networks, DNS domains, routing policies and relevant contact people. Entry growth accelerated after the European Internet registry system became fully operational in September 1992, in management’s terminology. During 1993 the NCC completely redesigned and reimplemented the update process, making it fully automatic for almost all updates, and processed 157,004 updates. The document store held RIPE documents and related information and could be reached through classical Internet services, common resource-discovery tools and public X.25 networks.
Management thus reported both a large update workload and multiple access routes to the centre’s documentary services.
RIPE-113 listed three special projects operating at the NCC under the RARE technical programme in 1993. Management said the European Route Server and Generic Internet Service Description projects concluded successfully. Their results included a European route server deployed at the GIX. PRIDE—Policy-Based Routing Implementation and Deployment in Europe—had begun, produced a well-populated European routing registry and delivered a first set of tools using information from that registry; the project was scheduled to continue in 1994. The annual report said interested parties funded all special projects separately from core NCC services.
Its account carries the sequence from RIPE’s September 1992 coordination decision to the GIX deployment and PRIDE’s routing registry.
The expenditure table in RIPE-113 was denominated in kECU. It reported a total 1993 budget of 216 against actual expenditure of 181; staff, 140 against 133; computing equipment, 20 against 15; travel, 25 against 9; rent and services, 29 against 22; and recruitment, 2 against 2. Management attributed lower travel expenditure to major IETF and RIPE meetings being held in Amsterdam. It said staffing had remained constant since operations began in April 1992 and projected that growing workload from European Internet expansion would require more staff in 1994.
The table, travel explanation, staffing statement and projection together formed management’s accounting narrative for 1993. The resulting reported variances were 35 kECU in total, 7 for staff, 5 for computing equipment, 16 for travel, 7 for rent and services, and zero for recruitment. They are arithmetic differences between the annual report’s budget and actual rows.
The surviving record has a concentrated set of evidentiary boundaries. It contains no executed hosting or funding agreement allocating responsibilities among RIPE, RARE, providers and the NCC, and it supplies no employment instruments behind the reported staffing. RIPE-113 is management reporting, not an independent audit. Neither the Class B procedure nor the later reviews provide a denominator for requests and decisions, an observed request population, or a record of refusals and appeals. The documents assign administrative functions concerning number resources without establishing property title in networks or address space.
Europe defines a service region, but the instruments furnish no territorial jurisdiction or general network command. References to participation and community consent leave the quality and representativeness of that consent unresolved. Programme review may revise the office’s work, yet the record identifies no outcome-changing remedy for an individual registration decision. These boundaries mark what a broader authority claim would have to establish beyond the documented service and registry functions.
RIPE-099 and RIPE-113 nevertheless illuminate two real forms of accountability. The panel compared quarterly progress descriptions with RIPE-035, identified completed, stalled and added work, and recommended a new plan. Management classified expenditure, stated staffing continuity, described projects and reported service volumes. Programme review could reshape priorities; annual reporting could place operations and expenditure before institutional audiences. An individual remedy serves a different purpose because it tests whether a particular administrative outcome can be reconsidered and changed.
The early documents show the first two mechanisms in operation at an institutional level and leave the third as an observable question for evaluating any later enlargement of power.
A later independent countercase sharpens the distinction between consequence and sovereignty. In analysis prepared in 1996 and published in 1997, Sharon Eisner Gillett and Mitchell Kapor compared decentralised organisation with systems in which routine mechanisms handle 99 percent of daily activity and multiple authorities address an exceptional one percent. The ratio was an analogy, not a measurement. They placed address distribution among exceptional coordination questions, distinguished providers, regional registries and IANA, and described RIPE NCC and APNIC as service organisations operated and funded by provider consortia.
Their multi-authority model showed how consequential registration could coexist with decentralised routing control. It offers a later independent test of the sovereign metaphor: specialised authority at one registry point can remain part of a distributed institutional order.
Judgment
The reports documented limited delegated operation at the stated scale. The NCC combined recurring service work with consequential functions inside number registration, yet executive control of networks remained with their organisations. Administrative centrality created material influence within a defined channel; it did not itself confer sovereign authority.
Any broader later-authority claim requires a new instrument. Remedy availability is one observable indicator for evaluating that claim, not a legal prerequisite. The founding evidence supports a reviewable service bureau with bounded registry power, not property control, territorial jurisdiction or general command of European networks.