RFC 1366 and the Moment Regional Allocation Became Thinkable

Summary

• RFC 1366 proposed distributing registration while preserving central IANA and Internet Registry coordination and grouping Class C space geographically to address service distance, classful scarcity and routing aggregation.
• The text and early European implementation show real regionalisation, but do not establish permanent territorial exclusivity, ownership, operator-wide consent, or a complete replacement and appeal mechanism.

The measured problem combined administrative load with architectural strain. In its June 1992 classful snapshot, RFC 1366 counted 49 allocated Class A network-number slots out of 126, 7,354 Class B slots out of 16,383, and 44,014 Class C slots out of 2,097,151. Medium-sized networks were difficult to serve efficiently: Class B numbers were scarce, yet issuing numerous unrelated Class C networks enlarged routing tables. RFC 1366 answered by distributing registration, reserving geographically organised Class C blocks, assigning contiguous groups against 24-month projections, and retaining IANA and the central Internet Registry as coordinating and default actors.

The strongest counterevidence to any account of open regional competition appears in the document itself. RFC 1366 described one regional registry per geographical region as important for efficient and fair sub-allocation. It coupled that preference with requirements for regional recognition, institutional standing, operational resources, compliance with central guidelines, and coordination over sub-allocation. At the same time, subscribers could still contact the central Internet Registry, which remained the root and promised service where necessary. The text therefore proposed concentration at the regional tier with a central fallback, but supplied no fixed regional boundaries, designation term, recurring accreditation procedure, comparative selection record, portability right, or published replacement mechanism.

European implementation proceeded through dated, non-simultaneous acts. RIPE documents place the Network Coordination Centre’s operational start on 1 April 1992, describe it as acting as a delegated registry from 1 May, record the central Internet Registry’s July request that it handle European applications, and date automatic forwarding of those applications from 1 August. By the March 1993 quarter-end, RIPE 87 reported 10,348 assigned network numbers and a partial workload log of 143 applications. RIPE 92 later described more than 10,000 network numbers during the first operating year, while RIPE 99 retrospectively claimed more than 14,000 for that year and separately reported, at its 25 October 1993 observation point after 18 months, more than 60 service-provider registries and 21 non-provider country registries. The reports do not expose a common frozen dataset with which to reconcile those totals.

The bounded finding is consequential but narrower than a constitutional origin story. RFC 1366 addressed an operational problem, added a one-provider preference at the regional layer, and was accompanied by observable block delegation, local reassignment, application forwarding, database exchange, request review, and reverse-DNS delegation in Europe. It was an Informational RFC, not an Internet Standard or an operator-wide vote. The available record identifies technical and coordinating constituencies that reviewed or implemented the design, but no complete affected-operator denominator, candidate comparison, objection ledger, designation appeal, replacement process, or evidence that the nominal central fallback was uniformly usable in practice.

October 1992: A Central Queue Meets a Scaling Network

RFC 1366, “Guidelines for Management of IP Address Space,” was written by Elise Gerich of Merit Computer Network and published in October 1992. It announced its status without ambiguity: the memo provided information for the Internet community and did not specify an Internet standard. That classification did not make the document trivial. An Informational RFC could coordinate institutions, define a practical plan and influence operating procedures. What it could not supply merely through publication was the approval procedure associated with a standard, much less a vote among every network that would later depend on the allocation system.

The institutional names around the document require care. RFC 1366’s abstract expands FEPG as “Federal Engineering Task Force”; its acknowledgements use “Federal Engineering Planning Group”; and RFC 1367 calls it the “FNC Engineering and Planning Group.” The source record is inconsistent, so no single expansion should be treated as unambiguously canonical. FEPG is the safer shorthand.

RFC 1366 said that FEPG reviewed the proposal on behalf of the Federal Networking Council, alongside the co-chairs of the International Engineering Planning Group and RIPE. It reported general consensus among those groups in support of the recommendations. The acknowledgements credited members of FEPG and IEPG with substantial contributions, traced concepts to an IETF Addressing Birds of a Feather session in Cambridge, Massachusetts, in July 1992, and named Jon Postel and Yakov Rekhter as reviewers and contributors.

That is a substantial creation setting, but each actor occupied a bounded role. Gerich was the author. FEPG and the federal council belonged to a federal networking structure. IEPG brought international engineering-planning participation. An IETF BOF offered a venue for developing and testing technical ideas. RIPE was both a coordinating constituency and an emerging implementer. IANA and the central Internet Registry were the actors expected to reserve space, maintain the root, recognise registries and coordinate delegation. Network providers, subscribers, local registries and applicants were affected populations, not interchangeable with the drafting and review groups.

The phrase “general consensus” consequently supports an attributed statement about the named reviewers. RFC 1366 gives no participant count, attendance list, vote, affiliation denominator or objection register from which to calculate broader support. Participation in discussion is not itself endorsement; implementation is not a retrospective ballot. Nothing in this limitation erases the expertise or influence of the groups involved. It prevents their review from being silently enlarged into universal operator authorisation.

The practical case began with growth and internationalisation. RFC 1366 said demand for network numbers had increased significantly during the preceding two years. A more diverse global population had to interact with a central registration service designed in an earlier and more geographically concentrated environment. Registries located closer to applicants might provide service in relevant languages and work more effectively with local administrative customs. Distribution, in this framing, first reduced organisational distance. It did not initially require a claim that geographic regions possessed number resources or political jurisdiction over them.

Classful addressing made the workload more than a service problem. RFC 1366’s Table 1 reported a June 1992 snapshot in units of network-number slots. For Class A, 49 allocated slots divided by a total of 126 equals 38.8889 percent, which rounds to 39 percent rather than the RFC’s printed 38 percent. For Class B, 7,354 divided by 16,383 equals 44.8892 percent, consistent with the printed 45 percent. For Class C, 44,014 divided by 2,097,151 equals 2.0988 percent, consistent with the printed 2 percent.

The first discrepancy should remain visible rather than being silently corrected. More important, the table’s unit was not applicants, organisations, requests, routed prefixes, refusals or utilised hosts. It measured allocated network-number slots in the three classes at one administrative snapshot. It contains no request denominator, no inventory of assignments later returned, and no measurement of how efficiently each assigned network was being used.

The imbalance still captured a real engineering problem. A Class C network provided a small host field; a Class B network provided far more capacity than many medium-sized organisations needed. Liberal Class B assignment consumed the comparatively scarce middle class. Substituting several independently advertised Class C networks conserved Class B slots but could add multiple routing entries. Registration policy, address conservation and routing-table growth had become coupled.

The routing concern had an empirical reference point. RFC 1338, published in June 1992, reproduced a Merit monthly advertised-route series containing 1,525 routes in April 1990 and 4,775 in February 1992. The difference was 4,775 minus 1,525, or 3,250 additional advertised routes. Relative to the April 1990 baseline, that was a 213.1 percent increase over 22 months.

RFC 1338 identified the source as Merit and related the figures to default-free routing information exemplified by the NSFNET routing database. This was not an all-router census. The observation unit was an advertised route in that monthly series at the two named observation dates, not an address request, applicant, subscriber, operator, allocated network or Internet user. Its value was to demonstrate pressure at an important routing vantage, not to provide a universal denominator.

Nor did contiguous allocation automatically reduce the observed table. RFC 1338 explained that aggregation benefits depended on inter-domain routing support for arbitrary network-and-mask pairs. Address administration could prepare aggregatable blocks before routers used them as single destinations. Multihoming, provider changes and exceptions could preserve or reintroduce more-specific routes. The administrative plan was therefore a prerequisite for aggregation, not proof that aggregation had already been deployed or that every router observed the same outcome.

RFC 1366 joined these pressures into one response. Registration would be distributed. Much of the Class C network-number space would be divided into broad geographic blocks. Assignments within those blocks would use contiguous powers of two sized against projected need. IANA and the central Internet Registry would retain coordinating functions, responsibility for the more tightly controlled classes and service where a regional registry did not exist.

The document also marked its horizon. Its recommendations professed to delay depletion rather than prevent it indefinitely. A large upper portion of the then mostly unassigned Class C range was to remain reserved until further notice. The plan sought to keep the existing architecture workable while addressing and routing technology evolved. Urgency drove the design; the text did not claim to have written a permanent settlement.

RFC 1174 Had Already Distributed Service Without Abolishing the Centre

The predecessor architecture appeared two years earlier in RFC 1174, authored by Vinton Cerf and published in August 1990. That document was also Informational and expressly presented recommendations rather than an Internet standard. It recorded the official view of the Internet Activities Board in recommendations to the Federal Networking Council.

RFC 1174 proposed retaining centralised IANA and Internet Registry functions. At the time, the IANA function was performed at the University of Southern California’s Information Sciences Institute, while SRI International’s DDN Network Information Center performed the Internet Registry function for network and autonomous-system numbers. The Internet Registry would remain the principal registry and the default where no delegated registration authority had been identified.

Distribution would occur through controlled delegation. The Internet Registry could allocate blocks of network and autonomous-system numbers to organisations approved by the Coordinating Committee for Intercontinental Research Networking and give them further assignment authority. Candidate registries were expected to meet with IANA and the Internet Registry, review operational requirements and document the proposed distributed mode of operation.

Database design reveals how bounded that distribution was. RFC 1174 recommended aggregate registration databases maintained by the Internet Registry, with copies provided to delegated registries for redundancy and access. Updates, however, would remain centralised at the Internet Registry; complete copies could then be redistributed by file transfer or another timely method. This was a replicated-read, central-update architecture. It offered plural service locations without assuming that several independent writers could safely alter the authoritative ledger at once.

The distinction matters for institutional analysis. Distribution did not mean that every delegated registry possessed a self-contained namespace or that central uniqueness control disappeared. A local or regional service could receive applications and exercise delegated assignment authority while authoritative updates were serialised centrally. The centre remained responsible for avoiding duplicate identifiers and maintaining a complete record.

RFC 1174 also recommended abandoning the old binary “connected” status. Registration had become entangled with permission to connect to federally sponsored Internet facilities. As commercial, academic, research, intermediary and non-US networks multiplied, that binary category no longer described the variety of access and transit arrangements. The document proposed collecting statements of acceptable-use, access and transit policy while permitting registered networks to enter the relevant naming database regardless of federally approved connectivity.

This separated number administration from network-policy enforcement. A registry could record a globally unique number without deciding every question about routing, interconnection, transit or acceptable use. Network administrators would continue making those decisions under their own policies. The registry ledger was essential coordination infrastructure, but control of the ledger did not automatically include comprehensive control over network operation.

The recommendation verbs remain important. RFC 1174 proposed, suggested and anticipated. It did not publish an audited list showing that every delegation, replication process or policy separation had been completed. Its approval route through CCIRN, IANA and the Internet Registry was a defined institutional channel, not a denominator of all operators who might be affected.

RFC 1366 inherited this architecture rather than replacing it with autonomous territorial registries. It called the Internet Registry the root, preserved it as the default in uncovered regions, placed distributed registries under IANA and Internet Registry guidelines, and retained direct contact as a stated option. Regionalisation involved genuine delegation and regional responsibility, but it remained nested within central coordination.

That structure resists two opposite simplifications. One reduces regionalisation to cosmetic decentralisation because the centre survived. Yet regional registries were expected to exercise real responsibility for service and sub-allocation. The other treats geographic blocks as transfers of sovereignty or ownership. RFC 1366 described reservation, allocation, assignment, registration and delegation. It did not define an ownership conveyance.

The Difficult Word Was “One”

RFC 1366’s strongest provision for concentration should be read directly: it described “just a single regional registry per geographical region at this level” as important to efficient and fair sub-allocation. “One” opposed peer regional registries operating at the same tier over the same geographic area. “At this level” left room for numerous service-provider, country or other local registries below the regional organisation. The central Internet Registry also remained above it and could receive direct approaches. Singularity at the regional layer was therefore real, but it was not equivalent to one office processing every application or to the disappearance of central service.

The remaining words supplied rationale without a complete accountability design. “Regional” named an administrative layer, not a legislature or sovereign people. “Geographical” associated service and allocation blocks with broad world areas while leaving boundary-setting and transregional networks unresolved. “Efficient” plausibly referred to coherent sub-allocation, reduced duplication, lower central workload and aggregation-friendly blocks, but the RFC contained no comparative cost study. “Fair” was a declared objective without a published equality metric, decision audit, service benchmark or appeal route. The sentence strongly establishes a one-provider preference. It cannot, without further evidence, fix the duration of a designation, prove permanent exclusivity, establish ownership or demonstrate consent from every operator in the service area.

The direct-service provision is equally important. RFC 1366 said subscribers could contact the Internet Registry, might be referred to the regional registry depending on circumstances, and could be served centrally if necessary. This preserved a root and a nominal fallback. The document did not define “necessary,” specify when referral could be resisted, publish a response obligation for the centre, or establish whether direct service would provide a review of the regional registry’s decision. A fallback within the delegating hierarchy is not automatically portability between peer providers, and a textual option is not proof of practical usability.

The one-registry clause deserves that counterweight, but not dilution. Treating the central fallback as proof that exclusivity was absent would misread the proposed tiering. Treating the regional preference as an irrevocable territorial grant would go beyond the operative language. RFC 1366 designed concentration at one layer inside a centrally coordinated hierarchy.

Selection Criteria Without a Reproducible Selection Record

RFC 1366 tried to define what a regional registry should be rather than simply naming an available organisation. It offered five criteria. Together they show that the author understood delegation as an institutional decision, not merely a technical configuration. They also expose how much of the decision procedure remained unstated.

First, “networking authorities” within the geographic area were to legitimise the candidate. The term had no supplied denominator. A national research network, ministry, carrier, service provider, academic consortium, standards participant and network-operations forum could each claim a different kind of authority. The RFC did not identify mandatory categories, determine how many endorsements were enough, explain whether objections carried weight, or say how conflicting claims would be resolved.

The surrounding text also required the registry to be unbiased and widely recognised by network providers and subscribers in its region. “Widely” was not converted into a test. It might have meant recognition across countries, among leading backbones, within a technical coordination forum or among organisations already known to the reviewers. No list of providers and subscribers was attached, so no reader can reproduce the recognition ratio or identify which affected organisations were absent.

Second, a candidate had to be well established and possess legitimacy outside the registry function. This reduced the risk of entrusting critical coordination to an organisation whose only standing came from its selection. Existing technical work, financial continuity, organisational maturity and a recognised coordination role could all support the criterion. Yet the RFC offered no standard financial disclosure, governance examination, conflict assessment or comparative scorecard.

Third, the organisation had to commit adequate resources for stable, timely and reliable service. This was the criterion most capable of measurement through staffing, budgets, response times, database accuracy, availability and continuity arrangements. The document specified no thresholds and no consequence if performance later deteriorated.

Fourth, the registry had to allocate numbers according to IANA and Internet Registry guidelines. Fifth, it had to coordinate with the central Internet Registry on qualifications and sub-allocation strategies. These conditions restrained regional autonomy. A delegated registry was not authorised to construct an incompatible numbering system or disregard the root ledger.

Language and local custom appeared in the rationale for distribution, not in the five formal criteria. RFC 1366 suggested that geographically situated registries might serve communities more effectively in those respects. It did not require a particular set of languages, translated forms, local offices or measurable service coverage. The rationale was plausible, especially in a rapidly internationalising network, but it was not operationalised as an accreditation test.

The decision chain remained incomplete. IANA and the Internet Registry would empower the registry; regional networking authorities would legitimise it; and the candidate would accept central rules. The text leaves open who verified resources, how candidates were compared, whether the central actors could select one over regional objections, whether either possessed a veto, and what happened if recognition later declined.

There was also no published designation appeal. A disappointed candidate received no stated process for inspecting the assessment or seeking reconsideration. A subscriber could contact the central Internet Registry, but that operational path did not necessarily review the status of the regional organisation. Service correction and institutional replacement were separate problems, and only the former received even a general fallback.

The criteria therefore made regional delegation more disciplined than informal convenience. They did not create a reproducible accreditation and renewal regime. The creation record supports selection by identifiable coordinating institutions under stated principles; it leaves the breadth, duration and contestability of the mandate unresolved.

Geographic Blocks Were an Allocation Technique, Not Territory

RFC 1366 proposed dividing part of the Class C range into eight equal blocks. After observing that prefixes 192 and 193 were already in use while much of 194 through 223 remained unassigned, it reserved 208 through 223 until further notice and arranged 192 through 207 into pairs of /8 blocks.

The RFC described each pair as containing 131,072 “addresses,” but the operative classful unit was 131,072 Class C network-number slots. Each such slot corresponded nominally to a /24-sized range of 256 raw IPv4 values. Multiplying 131,072 by 256 produces 33,554,432 raw values in each two-/8 block. Against RFC 1366’s Class C denominator of 2,097,151 network-number slots, 131,072 slots represented approximately 6.25 percent, consistent with the document’s rounded description of about 6 percent.

The labels were provisional and broad: 192-193 was multi-regional; 194-195 was Europe; 196-197 was “Others”; 198-199 was North America; 200-201 was Central and South America; 202-203 was Pacific Rim; and 204-207 supplied two further “Others” blocks. This was not a mature map of five permanent institutions. It contained four named geographic areas, one multi-regional range and three flexible ranges.

Where a qualifying regional registry existed, primary allocation responsibility within the relevant block could be delegated to it. Where none existed, the central Internet Registry would continue assignments while following the geographic divisions. Geography could therefore shape allocation before a regional institution had been selected. The block plan and the institutional coverage map were related but not identical.

Assignments within a block were to use contiguous powers of two based on a subscriber’s projected need over 24 months. The ordinary sequence was one Class C network for fewer than 256 addresses, two contiguous networks for fewer than 512, four for fewer than 1,024, eight for fewer than 2,048 and sixteen for fewer than 4,096. These were sizing rules for an assignment under the plan, not counts of requests, applicants or successful decisions.

Raw addresses and usable hosts must be kept separate. A /24 contains 256 raw IPv4 values. Under period-conventional treatment, the all-zero and all-one host identifiers were not available to ordinary hosts, leaving 254 usable host identifiers. Sixteen contiguous /24s therefore contain 4,096 raw values but 4,064 conventionally usable hosts. RFC 1366’s normal contiguous Class C example stopped at sixteen networks and directed requirements above 4,096 unique addresses toward likely Class B consideration.

The European form later published as RIPE 83 displayed an example extending to 32 Class C networks. In that form’s host convention, 32 multiplied by 254 yielded 8,128 usable hosts; the same 32 /24s contained 8,192 raw values. The comparison shows continuity in power-of-two block sizing but not an identical upper threshold. A form used in regional practice could extend the displayed Class C option beyond RFC 1366’s ordinary sixteen-network example.

Class B remained centrally controlled in RFC 1366. The document’s baseline required more than 32 subnets and more than 4,096 hosts, with case-by-case consideration where Class C blocks were impractical. A regional registry could assist with evaluation, but IANA and the Internet Registry retained responsibility for the class. Regionalisation was consequently substantial without being comprehensive across all address categories.

The geographic plan also had routing limits. Aggregation works most cleanly when allocation hierarchy and routing topology align. Providers can cross borders, organisations can be multihomed, customers can change providers, and international networks can span broad regions. RFC 1338 acknowledged that multihoming and provider changes could require exceptions or renumbering. RFC 1366’s own multi-regional and “Others” categories recognised that a tidy political map could not contain every network arrangement.

Nothing in the operative text granted ownership of a block to a registry or population. A geographical label organised administrative responsibility and prepared address space for aggregation. It was neither a title deed nor a legal boundary. The practical consequences could still be considerable: once registries, applicants, databases and blocks were arranged regionally, future choices would occur inside that structure. Institutional influence, however, is analytically distinct from property.

RFC 1367 Put Proposed Dates Beside the Plan

RFC 1366’s companion schedule, RFC 1367, was authored by Claudio Topolcic and published in October 1992. It too was Informational. Its language was unusually clear about status: it suggested a schedule, called that schedule a draft, and said it had been assembled from the July 1992 IETF addressing session and discussions with a number—but not all—knowledgeable and interested parties, including IANA and the Internet Registry.

The first target, 31 October 1992, called for initial regional-registry criteria to be in place and for IANA to accept requests from prospective registries. Class A numbers were described as practically impossible to obtain. Class B numbers would require reasonable justification, with Class C blocks preferred where possible. Class C allocation would follow the addressing plan, with the central Internet Registry acting where no regional registry had been designated.

A review and possible readjustment was scheduled for 14 February 1993. For 15 April, the Internet Registry was expected to begin allocating all networks under the addressing plan in appropriately sized Class C blocks, while Class B numbers would become more difficult to obtain. The final listed date, 6 June 1993, was the expected availability of an address-aggregation mechanism in the Internet.

These dates describe intended sequence and administrative level: criteria and candidate intake at IANA, continued central allocation where coverage was absent, tighter Class B review, wider use of contiguous Class C blocks, and anticipated routing support. RFC 1367 did not contain completion reports for any of those stages. Its invitation to open discussion, incomplete consultation and explicit readjustment point all resist treatment as a self-executing mandate.

Implementation has to be established elsewhere and function by function. A delegated block, a forwarded application, a database update, a local reassignment, a reverse-DNS delegation, a request evaluation and an aggregated route were different acts. They did not necessarily occur on the same date or prove the completion of every scheduled milestone.

Europe Was Implementing in Pieces

Europe provides the clearest immediate evidence because regional practice was developing before RFC 1366 appeared. The record is not a simple chain in which an RFC was published and a previously inactive region obeyed. Operating procedures, central-registry decisions, RIPE coordination and the RFC work overlapped.

RIPE 65, version 0.6 dated 1 July 1992, said that the RIPE Network Coordination Centre had acted as a delegated registry for European IP network numbers since 1 May. It described a policy of allocating to service providers, network information centres and network operations centres rather than directly to individual organisations. Those intermediaries would reassign numbers to applicants.

The October 1993 retrospective review supplies a distinct sequence. RIPE 99, dated 25 October 1993 and examining the NCC’s first 18 months, placed its operational start on 1 April 1992. It said that the central Internet Registry asked RIPE NCC in July 1992 to handle all applications from European organisations. After consultation with the RIPE chair and relevant working groups, the NCC accepted despite incomplete procedures. From 1 August, European requests received centrally by email or letter were forwarded to RIPE NCC.

These dates can describe different functions without contradiction. Operations began in April; some delegated registry work was reported from May; a central request for comprehensive European handling came in July; systematic forwarding began in August. “Delegation” could encompass receipt of blocks, local reassignment, review of certain applications, database duties or becoming the normal intake destination. The documents do not reduce those acts to one universal transfer date.

RIPE 72, version 0.7 dated 16 October 1992, again described delegated-registry activity from 1 May. It documented complete Class C blocks moving to service providers and local network centres, return of unused space when requested, reporting of reassignments into the RIPE database, avoidance of stockpiling, and contiguous power-of-two allocations aligned on suitable bit boundaries. The procedure anticipated aggregation but also said supernetting had not yet been formally adopted. Procedural compatibility was present before universal routing deployment.

The hierarchy visible to an applicant was documented in RIPE 83, dated 23 March 1993. The form said that Europe’s formerly centralised process had been replaced by a distributed system: the global registry delegated blocks to RIPE NCC, RIPE NCC delegated to local registries, and applicants generally approached their service provider or a non-provider local registry. Class B applications began locally but were forwarded to RIPE NCC for review if the local registry found them justified.

The form asked for current machine and subnet counts and projections one and two years ahead. It requested information about connectivity, existing IP numbers, planned countries of operation and network structure. Administrative registration data would enter the public RIPE database, while technical information used in evaluation was described as confidential. This is strong evidence of a live administrative path. A form, however, records required inputs and stated procedure rather than the distribution of outcomes.

RIPE 83 also makes the allocation unit visible. Its examples used usable-host calculations of 254, 508, 1,016, 2,032, 4,064 and 8,128 across one, two, four, eight, sixteen and 32 Class C networks. That sequence differs from raw-address totals of 256 through 8,192. The largest displayed Class C example exceeded RFC 1366’s ordinary sixteen-network ceiling, showing that early implementation could preserve the binary mechanism while adjusting its practical range.

The most detailed bounded workload evidence comes from RIPE 87, the March 1993 quarterly report. For the reporting quarter, it stated that 143 applications were received. Its printed intake channels were 51 from the global Internet Registry, 86 sent directly to RIPE NCC and 5 received from local registries. Those subtotals add to 142, not 143. The report provides no fourth category or correction that reconciles the one-application difference.

RIPE 87 expressly excluded simple referrals in which an applicant was merely directed to the appropriate local registry without RIPE NCC receiving an application. The 143 total is therefore not a denominator for every European address inquiry, every local-registry request or every organisation seeking numbers during the quarter. Nor can the 86 direct submissions establish successful bypass of the regional system: they were applications received by the regional centre, not evidence that an applicant avoided regional administration or obtained service centrally.

The same quarterly log reported response-time measures for its recorded request population. It said 82.5 percent of requests were answered—not merely acknowledged—on the day received, and 97.9 percent were answered within seven calendar days of receipt by RIPE NCC. It separately reported average elapsed times of just under five days for a Class C allocation handled through the NCC and just under ten days for a Class B allocation.

Those timings belong to the March 1993 reporting quarter and the populations described by RIPE 87. The report did not publish the underlying counts for each timing category, distinguish every outcome type, include simple referrals, or measure applications completed entirely by local registries. A response is not necessarily an allocation, and a quarterly service statistic is not a comparative measure of every possible registry arrangement.

RIPE 87 also said that more than 90 percent of evaluated Class B cases were found unjustified under criteria agreed with the global registry and IANA. It did not state how many Class B cases were evaluated, so the numerator cannot be recovered from the percentage. In the described procedure, such cases were forwarded to the appropriate local registry for Class C assignment. “Unjustified” under the Class B criteria should not be converted into a complete ledger of refusals, applicant harm, appeals or final failure to obtain address space.

The address-space section of RIPE 87 reported that, during the quarter, RIPE NCC assigned 14 Class B network numbers, delegated 32 blocks of Class C network numbers and reserved 15 Class C blocks. It said European registries assigned 3,235 Class C networks during the quarter, bringing the reported total to 10,348 assigned network numbers at the March 1993 quarter-end. These are administrative units at different levels: individual Class B network numbers, delegated or reserved blocks, and assigned Class C network numbers. None is an applicant count.

RIPE 87 also records a distinct implementation act in the naming system. It said the 193.in-addr.arpa reverse-DNS zone was delegated to RIPE NCC on 16 March 1993 and that 11 subdomains had subsequently been delegated to local registries holding Class C blocks by the report’s observation point. The unit was reverse-DNS subdomains under that zone, not address applications or allocation decisions. This demonstrates operational hierarchy beyond the assignment ledger without proving the completion of RFC 1367’s routing milestone.

The annual and retrospective totals require separate treatment. RIPE 92, published on 3 September 1993 as “The First Year of the RIPE NCC,” described the April 1992 through March 1993 operating year and said more than 10,000 IP network numbers had been assigned. The unit was network numbers assigned through the European registry system, not raw IPv4 values or applicant organisations. Its rounded statement is broadly compatible with RIPE 87’s 10,348 at the March quarter-end.

RIPE 99 later said that after one year of operation the European registry system had assigned more than 14,000 IP network numbers. That is also a retrospective claim about the first year, but it is materially higher than RIPE 87’s 10,348 and RIPE 92’s “more than 10,000.” The available reports do not expose a common frozen dataset, cutoff, treatment of historical entries, retrospective compilation rule or exact numerator sufficient to reconcile the three figures. The safe account preserves each source, date, window and unit rather than manufacturing a combined total.

RIPE 99’s registry counts refer to a different observation point. At 25 October 1993, after 18 months of NCC operation, it said the distributed system was then in place with more than 60 service-provider registries and 21 non-service-provider country registries. Those are registries reported as existing at the October review date. They should not be moved backward and labelled first-year counts.

RIPE 99 was written by a RIPE review panel and approved as representing RIPE’s views. It praised the NCC’s accuracy and timeliness and described the registry function as extremely well handled. That is valuable contemporaneous evidence from an institution close to the work. It is not an independent survey of every European operator. The report’s references to consent within RIPE concern the RIPE constituency and its internal processes; they do not supply a denominator for all providers, subscribers or applicants affected by the registry hierarchy.

The review also documented improvisation. The May 1991 NCC activity plan had not explicitly included the European IP registry role. According to RIPE 99, activities beyond the original plan were proposed, discussed within RIPE and implemented where a positive conclusion was reached. The July 1992 central request accelerated the registry function before every procedure was settled. This is evidence of adaptation through an active coordination body rather than proof of a pre-existing, comprehensive regional mandate.

At the top-block level, the current IANA IPv4 Address Space Registry, in the version last updated 2025-10-10, lists 193/8, 194/8 and 195/8 under RIPE NCC with 1993-05 dates. Those are month-level dates in a current registry. They are not a contemporaneous May 1993 snapshot, exact sub-allocation dates, transfer records, request files or evidence of motive.

The current row for 193/8 is nevertheless relevant to the published map. RFC 1366 had placed 192-193 in a multi-regional block while identifying 194-195 for Europe. The later registry’s treatment of 193/8 under RIPE NCC shows that the October 1992 map was not applied as an immutable partition. It cannot by itself explain the decision process or date each lower-level delegation.

Taken together, the European record shows implementation as a chain of separate acts: operating a coordination centre, receiving blocks, reassigning through local registries, forwarding applications, evaluating requests, exchanging registration data, delegating reverse-DNS responsibility and recording top-level address administration. The chain was real, but neither simultaneous nor reducible to a single mandate date.

What the Operating Record Establishes

The strongest implementation evidence concerns distributed service. RFC 1174 recommended delegation; RFC 1366 supplied regional qualifications and a geographic block plan; RIPE 65 and RIPE 72 documented working allocation procedures; RIPE 83 directed applicants through a global-regional-local hierarchy; and RIPE 87 measured part of the resulting workload. That is more than institutional aspiration.

The central fallback has a different evidentiary profile. RFC 1366 promised that the Internet Registry would remain prepared to serve subscribers where necessary. RIPE 99 said European applications arriving centrally were forwarded to RIPE NCC from 1 August 1992. RIPE 87 then recorded 51 quarterly applications received from the global registry, but those were forwarded into the regional process. The reviewed record lacks a complete log of applicants served directly by the centre, referred regionally, permitted an exception or allowed to insist on central handling.

Contiguous allocation likewise moved from proposal into procedure. RIPE documents used powers of two, aligned blocks and projected demand. Yet administrative readiness and routing effect remained separate. The allocation reports do not measure whether an aggregate was announced, accepted at a particular router, split by multihoming or displaced by more-specific routes. The Merit series described routing pressure at an identified vantage; the registry records described allocation activity.

Operational competence gained some retrospective support. RIPE 87 published response times and workload measures, while RIPE 99 praised accuracy and timeliness. These observations concern RIPE NCC’s early performance. RFC 1366 had not set pre-selection numerical benchmarks, so later success cannot reconstruct the candidate evaluation or establish which alternatives were considered.

Recognition is less reproducible. RIPE had an established coordination role, participating organisations and a formal framework through RARE. Those facts fit RFC 1366’s preference for standing outside the registry function. Missing are a complete list of regional providers and subscribers, a record of endorsements and objections, competing candidate submissions and a documented test for “widely recognised.”

Europe also shows how one regional registry could coexist with substantial plurality. Service-provider and country registries handled applicants below RIPE NCC. The centre coordinated blocks, procedures and database relationships at the regional layer. The one-registry provision therefore concentrated authority at a particular tier rather than centralising every customer interaction.

What the operating record cannot settle is the term and remedy attached to that concentration. The reviewed documents reveal no fixed designation period, periodic accreditation, applicant portability between peer regional providers, automatic replacement trigger or transparent procedure for establishing a second registry at the same level. Continued reliance can strengthen practical legitimacy over time, but it does not recreate an omitted authorisation process at the moment of selection.

Actors, Authority and the Missing Remedy

Authority in this history was functional before it was general. IANA coordinated numeric identifiers. The Internet Registry maintained central registration and assignment functions. Federal and international planning groups reviewed proposals. IETF participants developed technical mechanisms. RIPE coordinated participating European networks. RIPE NCC and local registries processed administrative work. Operators determined routing and interconnection; applicants sought resources under the resulting procedures.

IANA and the Internet Registry possessed the practical capacity to reserve blocks, recognise a registry, maintain the root record and route applications through a chosen service path. That capacity is evidence of operative authority inside the system then in use. It is not a record that every present or future operator granted an unlimited institutional mandate.

FEPG review connected the proposal to federal networking coordination. IEPG and the IETF addressing discussion broadened the technical setting. RIPE added regional expertise and implementation experience. Each was meaningful; none, on the reviewed evidence, represented an enumerated worldwide electorate.

RIPE’s dual role deserves neither dismissal nor inflation. It contributed to review while its coordination centre was becoming the European registry. Institutions closest to implementation often possess the most relevant expertise. They can also become beneficiaries of the architecture they help shape. RIPE’s reports are primary evidence of its procedures, activity and institutional view, not independent proof of consent across an undefined region.

Applications show reliance on a service path, but submitting a request does not necessarily endorse every feature of the institutional structure. An operator may comply because the process is useful, recognised or practically unavoidable. Database reporting, routing cooperation and local-registry participation can build legitimacy through practice. They still answer a different question from who could designate, audit or replace the regional organisation.

The record reviewed here contains no complete author drafting archive, FEPG or IEPG correspondence set, IETF Addressing BOF transcript, candidate-registry comparison, regional endorsement denominator, objection ledger or designation appeal file. That gap should not be converted into hidden opposition. It equally prevents silence from becoming measured consensus.

A stronger authorisation history would require evidence connecting the named institutions to the constituencies for which they purported to act: candidate submissions, evaluation records, correspondence with providers and subscribers, documented objections, central-service exceptions, replacement discussions, and decisions explaining how recognition was assessed. Without such material, the early record establishes a technically reasoned and operationally implemented arrangement while leaving its comprehensive mandate incomplete.

The Period-Feasible Alternative Was Not a Modern Shared Ledger

A useful counterfactual starts by accepting the need for distribution. By 1992, a purely central intake service was increasingly difficult to reconcile with international growth, language, local procedure and administrative scale. The sharper question is whether distributed service required a single provider at the regional tier.

One period-feasible alternative followed RFC 1174’s actual database architecture. Several accredited intake or assignment services could have handled applicants within a broad region while the central Internet Registry serialised authoritative updates. Delegated services might receive distinct address pools, apply common criteria and submit changes to one central update queue. Replicated copies could then be redistributed for access and redundancy.

This was not true multi-writer replication. The central Internet Registry would remain the authority ordering changes and preventing duplicate assignments. Such a design could offer multiple service interfaces without requiring several institutions to edit the same authoritative state concurrently. Its bottleneck would be the central update path: latency, outage recovery and reconciliation after delayed submissions would still require explicit procedures.

Collision prevention would depend on either strict pool partitioning or central confirmation before assignment. With partitioned blocks, each service could act within its range without colliding with a peer, but unused capacity might become stranded and rebalancing would require coordinated transfers. With central confirmation, pools could be more flexible, but applicants and registries would experience update latency and vulnerability to central interruption.

Aggregation introduced another trade-off. Assigning each service a distinct contiguous pool could preserve broad aggregates. Allowing an applicant to switch providers while retaining addresses might punch holes in those aggregates or require more-specific routing. Requiring renumbering during a switch would protect aggregation at the cost of transition work for the applicant. The alternative therefore needed a rule for address continuity, not merely an extra front desk.

Local-language service could improve through specialised providers, especially across a region too diverse for one centre to serve equally. It could also become uneven: profitable or well-connected communities might attract several registries while others received little coverage. Accreditation would need to assess geographic and linguistic reach, not assume competition would distribute itself fairly.

Common criteria would create their own governance problem. Multiple providers might interpret projected need or Class B justification differently, encouraging applicants to choose the most permissive service. Preventing such forum shopping would require audits, shared guidance, review of divergent outcomes and a power to correct or suspend providers. Plurality reduces dependence on one registry only if the accrediting and auditing layer is credible.

The central fallback would also need definition. If the root accepted applications whenever a regional provider was slow or restrictive, it could become a competing service and undermine regional planning. If it automatically referred applicants back, it would offer little practical redundancy. A workable alternative had to specify when the centre would intervene, whether it could override a regional decision, and whether direct service was an operational exception or a genuine review path.

Failure recovery is equally concrete. A regional service could lose staff, funding, connectivity or database integrity. Under a multi-service model, another accredited provider might take over intake, but authoritative records, pending applications and unused pools would have to be transferred safely. Under the one-registry model, the centre or local registries might provide continuity, yet RFC 1366 did not describe a tested handover process. Neither structure made institutional failure costless.

Replacement and appeal should be separated. An applicant might challenge an individual allocation decision without seeking removal of the registry. A provider or regional constituency might contest the registry’s performance or recognition without disputing a particular request. The first problem calls for review of criteria and evidence; the second calls for accreditation, audit and replacement rules. RFC 1366’s direct central contact provision only partially addressed the first and did not define the second.

A second, more ambitious alternative would have allowed true multi-writer replication: several registries updating authoritative state with later reconciliation. The reviewed period documents do not establish that as the intended architecture. It would have required conflict-free allocation partitions or robust transaction ordering, authenticated update exchange, detection of divergent records, recovery after network partitions and a rule determining which writer prevailed. Treating a modern-sounding shared ledger as an effortless 1992 option would erase the technical reason RFC 1174 retained central updates.

The one-registry regional design reduced several coordination costs. One organisation could manage a coherent block, maintain a single relationship with IANA and the Internet Registry, apply one regional procedure and coordinate the lower registry hierarchy. Its local registries could still provide provider-specific, country-level and linguistic service. This made singularity at the regional tier compatible with distribution below it.

The cost was concentrated dependency. If the regional organisation became slow, inconsistent, under-resourced or insufficiently representative, applicants lacked a stated peer alternative. Central service offered potential redundancy, but referral could send the applicant back to the same regional layer. The design therefore needed continuing review and replaceability at least as much as it needed entry criteria.

RFC 1366 articulated the coordination advantage more fully than the accountability mechanism. It identified stability, timeliness, reliability and recognition as desirable qualities but did not define how they would be monitored, whose evidence would count, when a designation would expire, or how a new registry could replace an incumbent.

The counterfactual does not prove that several providers would have produced better outcomes. Multiple accredited services would have carried real costs in update ordering, pool management, aggregation, renumbering, auditing and transition. What the comparison reveals is narrower: regional service, central uniqueness and one-provider concentration were three separable choices. The operational need for the first two did not by itself establish the permanent necessity of the third.

The Moment Regional Allocation Became Thinkable

RFC 1366 made regional allocation concrete by connecting problems that could no longer be treated independently. International growth strained a single service interface. Language and administrative proximity favoured distribution. Class B scarcity made the old sizing habits unsustainable. Multiple Class C assignments threatened routing growth unless blocks were contiguous and compatible with aggregation.

RFC 1174 had supplied the underlying architecture: retain IANA and the central Internet Registry, delegate assignment functions through approved organisations, distribute database copies while centralising updates, and separate registration from network-policy enforcement. RFC 1366 added regional qualifications, a geographic Class C plan, sizing thresholds and an express preference for one registry at the regional tier. RFC 1367 placed proposed dates beside that plan without proving that every milestone occurred.

Europe supplies the strongest evidence of practice. Between April 1992 and October 1993, the public record documents an operating coordination centre, delegated registry procedures, central forwarding of applications, service-provider and country registries, Class C block delegation, applicant forms, request evaluation, database coordination, reverse-DNS delegation and substantial reported assignment volumes. The acts occurred on different dates and at different administrative levels. Their statistics cannot be collapsed into a single request, applicant or authorisation ledger.

The one-registry clause belongs inside that operational achievement, not outside it. It offered a way to coordinate blocks and procedures while permitting many local service points. It also concentrated dependency at the regional layer. RFC 1366 preserved a central root and fallback but left the practical conditions of central review uncertain.

The resulting record ends at a clear boundary. An operational problem was addressed. Institutional concentration was added. Dated implementation can be observed. What remains missing is a complete account of authorisation across the affected population, a reproducible measure of recognition, and an established process for appeal, replacement and continuity if the designated regional registry ceased to meet the qualities on which its selection depended.