Summary
- The earliest published quantity table located in the reviewed RFC and RIPE materials is RFC 1366 from October 1992. RFC 1174 confirms that an Internet-Number-Template already existed by August 1990, and the pre-1990 address forms and manuals have not been exhaustively searched.
- Published rules and operational communications document increasingly knowable inputs, quantitative reference points, parser checks, correction procedures, confidential engineering plans, stated exceptions, and eventually a Right to Appeal. They describe procedural design and registry practice; the located records do not show how any identified request ended.
- The reviewed practice evidence consists of one partial request discussion and three operational or institutional observations, not four completed applicant cases. No complete identified chain joins an original application, contemporaneous criteria, corrections, reasons, final allocation, review, and outcome-changing remedy, so consistency and success or refusal rates remain unmeasured.
On 22 March 1994, Keith Mitchell of PIPEX asked a group of European local registries how to handle an awkward justification for address space. PIPEX had received what Mitchell called “a couple of registration requests” for an unspecified large number of Class C networks. Each proposed network would apparently contain only five or six hosts. PIPEX’s usual response in such circumstances was to assign perhaps one or two Class C networks and recommend subnetting.
The applicants’ stated obstacle was technical. According to Mitchell’s account, routing software for Novell servers or the company’s LAN WorkPlace product could not subnet Class C space. If that premise were sound, one network per physical segment might make the applicants’ systems easier to operate. It would also consume more network numbers than PIPEX’s normal approach. Mitchell asked whether the local registry should accommodate the limitation or treat it as a vendor problem.
The discussion quickly became a fact-check. Ian Harding pointed to the Novell NetWare Supervisor’s Guide, where a sample configuration suggested that subnetting was supported. Bob Day proposed a “reasonable” immediate allocation, coupled with warning that the same explanation should carry less weight in a later request. John Williams described an installation using subnetted Class C space and explained that proxy ARP addressed a related address-resolution problem. In another message, Day advised rejecting the stated reason while seeking a definitive answer through a Novell contact.
This was peer scrutiny of an asserted software limitation, not a completed allocation case. The archive lacks the applications, applicants’ identities, precise requested quantities, software versions, network diagrams, growth forecasts, later amendments and any assessment of the effect on global route aggregation. The correspondence ends before a reasoned disposition, allocation, refusal, review or remedy.
Even so, the exchange captures a significant administrative moment. A local registry did not accept a technical justification merely because an applicant supplied it. Operators compared the claim with documentation and deployed experience. They explored an interim accommodation and considered whether the equipment vendor should bear some of the adjustment cost. Technical judgment was being exercised in view of peers rather than through an entirely private conversation.
The missing ending prevents the fragment from carrying more weight. Advice to allocate a “reasonable” quantity supplies neither a quantity nor an outcome. A successful configuration elsewhere may weaken a broad claim about product capability while leaving open the costs of changing a particular installation. Advice to reject a reason is not a refusal of the request. The applicants may have revised their plans, supplied further evidence, accepted a smaller block or abandoned the issue; the opened record cannot choose among those paths.
That boundary frames the historical question. During the period examined here, public forms and numerical guidance plainly changed what an applicant was expected to disclose. Some clerical stages became machine-readable and correctable. Tables created reference points against which departures could be recognised. The harder issue is whether those instruments regularly controlled final judgment. Answering it requires transactions, not guidance documents alone.
What this inquiry covers
The public corpus reviewed for this article includes assigned-number records; RFCs on identifier policy, address-management criteria, implementation schedules, registration processing and registry practice; RIPE request forms and version announcements; selected RIPE meeting minutes; and four operational or institutional artifacts examined in detail.
The RFC sequence runs from the 1988 assigned-number record through RFC 1174, RFC 1366, RFC 1367, RFC 1400, RFC 1466, RFC 1467 and RFC 2050. The principal applicant-facing forms are RIPE-095 and its immediate successor, RIPE-098. The four practice artifacts are the PIPEX discussion, a 19 March 1993 notice about assignment and update controls, Daniel Karrenberg’s May 1993 description of conservative allocation practice, and the RIPE-18 minutes.
This is a bounded public-source inquiry. Earlier address-specific manuals, templates, memoranda and correspondence have not been searched exhaustively. The Computer History Museum’s guide to the SRI ARC/NIC records identifies 281 boxes covering a much wider institutional history, with bulk dates extending through the early 1990s. The guide is a map of possible holdings rather than evidence about the contents or use of an unexamined form.
“First” in the headline is therefore a question under audit. RFC 1174 establishes that an Internet-Number-Template was already current in August 1990. The earliest published quantity table located in the reviewed RFC and RIPE materials appears in RFC 1366 in October 1992. That finding leaves room for an earlier form, manual or instruction to change the chronology.
The practice denominator needs the same restraint. The four artifacts are not four completed cases. One is a partial discussion concerning an unspecified “couple” of requests; the others are an operational control notice, an official’s illustrative account and a meeting record of unidentified reports. The wider population of applications, corrections, grants, refusals and restricted files has no reliable count in the reviewed material.
Eleven stages inside an address request
A single word such as “processing” conceals several administratively distinct events. The documents disclose eleven stages, and the evidence needed for one stage cannot simply be borrowed from another.
Submission begins with routing the request to the responsible office. The correct destination varied by date, region, network affiliation, resource type and the presence of a delegated registry. A message sent to the wrong mailbox could be forwarded or returned before anyone considered technical need.
Syntax concerns the representation of the request. A machine or clerk had to recognise the template and parse its contents. An obsolete form or malformed field could interrupt the transaction even when the underlying network plan was sound.
Completeness asks whether the submission contains the inputs needed for assessment. Depending on the instrument, those inputs included current and projected machines, subnet counts, existing holdings, connection plans, topology, routing arrangements and responsible contacts. A request for additional information leaves the substantive question open.
Technical need addresses the network design itself. Officials had to judge whether every proposed machine needed a globally unique address, whether a block of Class C networks could replace a Class B, whether subnetting was practical and whether forecasts rested on credible plans.
Global routing or aggregation concern belongs to a different level from an applicant’s internal routing problem. Fragmented announcements placed costs on routers and operators across the Internet. The alleged Novell limitation in the PIPEX discussion concerned the applicants’ own configuration; the surviving thread contains no global aggregation assessment.
Exception is a departure from an ordinary criterion. A dispersed topology could require more network numbers than a host total alone implied. An equipment constraint might also be offered, although an official could challenge its premise. A published exception category narrows the relevant grounds for discretion even when the resulting case is not public.
Reason explains why the request moved as it did. A parser error, a missing forecast and a judgment that Class C space could meet the need are different explanations. A reasons record would connect the accepted facts and applicable version to a procedural or substantive response.
Correction lets the requester repair, clarify or supplement the submission. It may involve fixing a parser’s interpretation, supplying an engineering plan or updating a forecast. Correction occurs within the initial process and may leave the eventual allocation question untouched.
Outcome is the administrative disposition: grant as requested, grant in another quantity or form, referral, delay for information, withdrawal, refusal or unresolved status. A later entry showing an assigned block reveals only part of that history.
Review is reconsideration by the assigning registry, a parent registry or another authorised level. Its evidence would include the decision being challenged, the file supplied to the reviewer and the reviewer’s assessment.
Remedy records what review accomplished. A decision might be upheld, changed, remanded for further work or replaced with another disposition. The existence of review says nothing by itself about whether the result moved.
The PIPEX thread reaches submission, technical-need assessment, an asserted exception and peer fact-checking. Describing its exact reach is more useful than calling it an incomplete case and mentally supplying the missing stages.
Before a public quantity table
The earliest material in the reviewed sequence shows an operating number registry before it reveals a public allocation formula.
RFC 1062, Internet Numbers, appeared in August 1988 as an official status report. It identified the Hostmaster at the DDN Network Information Center, operated by SRI International, as the source of current network-number information. The document listed assigned network numbers, autonomous-system numbers and responsible contacts. It distinguished research, defence, government and commercial environments, while noting that an independently numbered network had to seek interconnection permission separately.
That separation is easy to overlook. Registration supplied uniqueness and contact information; it did not automatically grant connectivity. The assigned-number list also shows the visibility imbalance that would persist through the period. Completed assignments entered durable public records, whereas a request that was withdrawn, redirected or refused might leave no corresponding entry. The register cannot reconstruct the amount originally requested, the evidence supplied or the reasoning behind the selected address class.
By August 1990, RFC 1174 referred explicitly to the “current Internet-Number-Template.” Vinton Cerf authored the Informational document, which represented the official view of the Internet Activities Board and transmitted recommendations to the Federal Networking Council.
RFC 1174 described IANA as a function performed by the University of Southern California’s Information Sciences Institute. It said IANA had lodged responsibility for numeric network and autonomous-system identifiers with an Internet Registry operated by SRI International at the DDN-NIC. The recommended architecture retained central IANA and Internet Registry functions while permitting approved organisations to receive blocks and make further assignments.
A second recommendation addressed the increasingly awkward concept of “connected” status. RFC 1174 proposed removing connected-status references from registration forms, adding information about acceptable use, access and transit policy, and admitting registered networks to the Domain Name System without making that status the decisive condition. Country and traffic-policy fields were among the proposed changes to the existing template.
These recommendations clarified the difference between identifier registration and enforcement of network-access policy. They also show that form design was already an instrument of institutional policy. The RFC neither reproduces the exact template version then in circulation nor dates the operational adoption of its proposed changes. Its fields were qualitative and jurisdictional rather than a schedule mapping demand to a quantity of addresses.
October 1992: a numerical reference point
RFC 1366, Guidelines for Management of IP Address Space, was published in October 1992 by Elise Gerich of Merit. It was Informational, did not specify an Internet standard, proposed a plan for address management and was later obsoleted by RFC 1466.
The proposed regional structure was tied to institutional qualifications. Networking authorities in a geographic area were to legitimate a candidate registry. The organisation should be well established and possess legitimacy outside the registry function. It needed resources sufficient for stable, timely and reliable service, a commitment to follow IANA and Internet Registry guidelines, and willingness to coordinate with the Internet Registry on qualifications and strategies for suballocation. The Internet Registry remained the root and the default for regions without a recognised delegate.
Those provisions connected technical delegation to regional standing and organisational capacity. A block of numbers alone did not make an office a qualified regional registry. At the same time, the criteria were stated prospectively; RFC 1366 contains no continuing assessment of how each candidate satisfied them.
The document placed strong restrictions on Class B consideration. An organisation was expected to satisfy two conjunctive conditions: a subnetting plan documenting more than 32 subnets and more than 4,096 hosts. RFC 1366 did not attach the later 24-month language to both Class B thresholds. It also acknowledged circumstances in which Class C blocks could not practically replace a Class B and allowed those circumstances to be considered case by case.
For Class C space, the RFC mapped a subscriber’s projection of required unique IP addresses over 24 months to contiguous blocks:
- fewer than 256 addresses mapped to one Class C network;
- fewer than 512 mapped to two contiguous Class C networks;
- fewer than 1,024 mapped to four;
- fewer than 2,048 mapped to eight;
- fewer than 4,096 mapped to sixteen.
The unit was projected unique IP addresses. It was not the number of employees, customers, physical subnets or conventional usable host slots. A Class C network contained 256 numerical address values, although ordinary host configurations reserved network and broadcast values.
The literal wording has an unresolved edge. Every row says “fewer than,” leaving exact powers of two such as 256, 512, 1,024, 2,048 and 4,096 outside the rows as written. Examples elsewhere in the document help reveal the intended scale but do not rewrite the table. Calling it a public reference point is more precise than calling it a complete algorithm.
Within a row, applicants and officials could now refer to the same demand horizon and block size. If an accepted projection fell below 1,024 addresses, the published row pointed to four contiguous Class C networks. A different quantity would depart from that row. RFC 1366 imposed no general duty to publish a case-specific explanation for such a departure, and the accepted projection might remain private. Still, the table narrowed the vocabulary of decision: quantity could be compared with an articulated baseline.
Much of the remaining work lay in deciding which input was credible. A two-year projection could be carefully derived or aspirational. Some machines might use private or non-unique space. A physical topology might make the ordinary block awkward. Officials still had to evaluate technical evidence, but their judgment now operated around a visible numerical schedule.
The companion RFC 1367, authored by C. Topolcic in October 1992, proposed an implementation schedule. It called for continuation of the procedures from 31 October 1992, a review on 14 February 1993, and allocation under the addressing plan in appropriately sized Class C blocks from 15 April 1993.
A later status report, RFC 1467, replaced that schedule in August 1993. Topolcic reported that most administrative milestones had been implemented on time, apart from delivery and installation of CIDR software. The report said RIPE NCC had received a regional block and that the Internet Registry began making allocations under the plan in appropriately sized Class C blocks on 15 April.
RFC 1467 is meaningful contemporaneous evidence from within the programme. Its account supports the attributed finding that major administrative milestones were reached. It remains an institutional self-report rather than an inspection of application files, but that source boundary should not erase the operational developments it records.
Clerical regularity at the InterNIC boundary
In March 1993, RFC 1400, Transition and Modernization of the Internet Registration Service, described a different kind of procedure. Scott Williamson of Network Solutions authored the Informational document during the transfer of non-DDN registration services following the National Science Foundation’s information-services award.
The institutional boundary was specific. RFC 1400 used “InterNIC” to mean its Registration Services component. DDN users continued to receive registration support from the DDN-NIC through a separate route and approved forms. For non-DDN users, existing DDN-NIC templates could be submitted during March 1993. New InterNIC templates became effective on 1 April. An old form sent to the automated mailbox would be returned with parsing-error messages and the new template attached, while the human Hostmaster route temporarily accepted old formats through 30 June.
The automated sequence brought several administrative events into view. A requester sent a completed template to the automated mailbox. The mail server parsed it and made quick checks of verifiable information, with domain-name conflict given as an example. It returned either a verification or a rejection carrying an error message.
The requester then reviewed how the information had been interpreted. Incorrect data could be corrected before the verification was returned. Following a rejection, the requester could adjust the registration request and resubmit it. A corrected verification was checked again. Once Registration Services received a satisfactory verification, the request moved to staff for final processing. An unanswered verification expired after seven days, requiring resubmission. A trouble-ticket number supported status inquiries.
These mechanisms constrained clerical handling in concrete ways. They disclosed which form the system accepted, exposed parsing problems, invited confirmation of interpreted information and gave the requester a reference for tracking status. An obsolete form could not silently disappear into a queue. A machine-readable error could be repaired without presenting it as a final judgment about scarcity.
The scope of automation was equally concrete. The parser handled representation and verifiable information; staff retained final processing. RFC 1400 did not assign the machine responsibility for evaluating a two-year forecast, choosing a block size or deciding whether a topology justified an exception. A count of automated “rejections” would therefore mix clerical events with anything a modern reader might call a denial unless the underlying transactions were classified.
As a Network Solutions process description, RFC 1400 records the contractor’s designed sequence rather than an independently sampled performance measure. Its contribution to procedural history is nevertheless substantial. By 1993, important parts of the registration path had been standardised enough to parse, verify, correct, time and track.
Engineering plans and structured departure
RFC 1466, published by Elise Gerich of Merit in May 1993, explicitly obsoleted RFC 1366. The Informational successor retained the distributed-registry framework and made the evidence expected from applicants more specific.
Class B consideration still required more than 32 subnets and more than 4,096 hosts. In addition, an applicant had to submit an engineering plan explaining why it was unreasonable to build the network with a block of Class C networks. The plan was to state how many hosts the network would have during the next 24 months and how many hosts would appear on each subnet over the same horizon.
The engineering plan was to be held in strict confidence and used only to judge whether the application was justified. Where the host and subnet evidence failed to warrant a Class B, the applicant would receive a block of Class C addresses. The rule therefore described an alternative allocation path rather than a simple grant-or-refusal choice.
The Class C table expanded upward. Fewer than 8,192 addresses mapped to 32 Class C networks, while fewer than 16,384 mapped to 64. The same exact-boundary ambiguity remained because the rows continued to use “fewer than.”
RFC 1466 also supplied a topology example. Six hundred hosts distributed equally across ten Ethernets could receive ten Class C networks, one for each Ethernet, if an engineering plan supported departure from the default table. A registry could request a plan where failure to subnet would create extravagant waste. Exceptions were to be determined case by case.
This combination is a recognisable architecture of structured discretion. The table stated the ordinary relationship between accepted demand and quantity. The example identified topology as a relevant ground for departure. The engineering plan gave officials evidence with which to test that ground. Confidentiality protected the applicant’s internal design.
The audit language operated inside a defined hierarchy. The Internet Registry could allocate small Class B blocks to regional registries, require accounting for assignments from those blocks, receive the applicants’ engineering plans and audit those plans for consistency with the guidelines. The text establishes authority and an evidentiary route; it does not identify an audit that altered a named allocation.
Taken together, the 1992 and 1993 guidelines made several substantive choices more contestable. An applicant could point to a default row, explain why topology displaced it and know that a Class B claim required more than organisational scale. The most sensitive evidence, however, was designed to remain outside public comparison.
A form current for fourteen days
The RIPE-095 European IP Network Number Application Form and Supporting Notes converted much of this policy into fields an applicant could complete. Anne Lord and Daniel Karrenberg authored the document, published on 1 October 1993 as an update to RIPE-088.
The form printed an expiry date of 30 December 1993. That date did not determine how long it remained the latest version. A 15 October document announcement for RIPE-098 stated that the revised form obsoleted RIPE-095 and added a recommendation that local registries consult RIPE NCC on applications for 32 or more Class C networks. RIPE-095 was therefore the newest published form for fourteen days.
Its four-part structure separated different kinds of evidence.
Part A collected the network name, an organisation description, country, administrative and technical contacts, change information and person records. Those data, together with assigned network numbers, were intended for a publicly accessible registry.
Part B gathered confidential technical information: the request type; current, one-year and two-year machine counts; current, one-year and two-year subnet counts; the Internet connection plan; existing IP network holdings; and the countries in which the network would operate.
Part C required a network description from applicants seeking more than two Class C networks. The applicant was to describe the current layout and plans for the following two years, including subnet sizes and relevant network components. Larger requests invited greater detail.
Part D identified a representative acting on behalf of another organisation. This mattered because the person filling out the form, the service provider, the applicant organisation and the eventual user of the addresses could occupy different roles.
The form’s numerical examples used conventional usable-host quantities. One Class C was associated with a maximum of 254 hosts, two with 508, four with 1,016, eight with 2,032, sixteen with 4,064 and thirty-two with 8,128. These figures differ from RFC 1366’s thresholds expressed as 256, 512, 1,024 and related quantities of raw addresses. “Machines,” “usable hosts” and “addresses” must remain separate when reconstructing an application against the relevant version.
RIPE-095 also distinguished an initial request from an application for more space. An organisation seeking additional address space was asked to describe previously assigned networks, used and unused numbers, installed subnets, connected hosts and structural details. The stated objectives included better use of the available address pool and preservation of contiguous blocks where possible for aggregation.
Institutional routing appeared on the face of the form. Applicants normally approached a local registry first. Class B addresses were assigned at the regional level, so a local registry that considered a Class B request justified forwarded it to RIPE NCC for review. Technical information remained confidential rather than entering the public network-management register.
For an applicant, this was a considerable gain in notice. The expected evidence could be assembled before submission. More demanding requests visibly triggered more demanding descriptions. The rapid RIPE-095-to-RIPE-098 change also demonstrates active maintenance and the importance of identifying the version in force on a particular date.
A completed blank form still differs from a decision file. The form names inputs and routes; it does not reveal which forecast an examiner accepted, how competing considerations were weighted or which quantity was finally assigned. Those facts would have to be joined to the form through the transaction record.
BCP 12 and a published appeal route
By November 1996, the public framework had become classless and more elaborate. RFC 2050, Internet Registry IP Allocation Guidelines, was published as Best Current Practice 12 and replaced RFC 1466. Its authors were Kim Hubbard, Mark Kosters, David Conrad, Daniel Karrenberg and Jon Postel, with affiliations spanning InterNIC Registration Services, APNIC, RIPE NCC and USC/ISI.
The IESG’s note carefully bounded the document’s status. Approval as a Best Current Practice expressed the IESG’s belief that the policy accurately represented then-current registry practice. It expressly withheld endorsement or recommendation. RFC 2050 is thus stronger than a proposed timetable as an institutional account of operative practice, while remaining different from a case audit.
The document described a hierarchy of IANA, regional registries and local registries. It named InterNIC for North America, RIPE NCC for Europe and APNIC for the Asia-Pacific region. It also distinguished allocations to providers from assignments to end enterprises. That distinction governed both the time horizons and the denominators used in later rules.
For Internet service providers, “slow start” meant a minimal initial allocation based on immediate demonstrated need. Subsequent allocations could grow after utilisation verification. An additional allocation was intended to provide about three months of assignment capacity before the provider returned to its parent registry. A projected customer base alone carried little weight.
The three-month period belonged to provider replenishment. It was not the 24-month projection in RFC 1366 and did not govern the same population. One concerned how much capacity a provider received from a parent registry; the other mapped a subscriber’s projected need to classful blocks.
Reassignment information formed another provider-level control. Sub-registries were expected to record assignments promptly so operational contacts could be found, utilisation could be checked and address studies could be conducted. A regional registry or upstream provider was not to make another CIDR allocation until approximately 80 per cent of all reassignment information had been submitted. The percentage measured documentation coverage across the relevant assignments, not host utilisation.
End-site assignments used different guidance. The basic thresholds were 25 per cent immediate utilisation and 50 per cent within one year. RFC 2050 defined expected utilisation as the number of hosts connected to the network divided by the total number of hosts possible on that network. Connected hosts supplied the numerator; total possible hosts supplied the denominator. Employees, customers and reassignment records were outside that calculation.
Engineering plans were expected to include subnet masks, the number of hosts on each subnet, topology and routing arrangements. Previous holdings could be considered across divisions or subsidiaries under a common parent. Deployment plans and confidence in projections also mattered. Organisations with fewer than 128 hosts would not ordinarily receive space directly from a regional registry, although longer prefixes could be issued under specified circumstances.
Provider-based addressing carried a renumbering expectation. Addresses were treated as loans for the duration of connectivity. When a customer changed providers, the recommendation was to return the existing addresses and renumber into the new provider’s space, with sufficient time allowed before the old addresses were reused. The goal was aggregation, not recognition of a permanently portable entitlement.
RFC 2050 openly acknowledged tensions among conservation, routability and registration. Careful judgment was necessary in individual cases. Regional registries could audit and verify requests by means they considered appropriate, and assignments based on false information could be invalidated. Transit providers might filter routes even when a registry had assigned the underlying addresses. A registry assignment therefore did not guarantee global routability.
Confidentiality acquired a defined parent-registry path. An assigning registry had to protect information the requester specifically identified as sensitive. If the applicant lacked assurance that the local registry could provide adequate privacy, the parent could handle the assessment and communicate the appropriate quantity downward.
The document’s section title was explicit: Right to Appeal. An organisation that believed an assigning registry had failed to perform its task in the requisite manner could appeal to the parent registry. The assigning registry was to provide the relevant documentation. Further appeal could proceed up the hierarchy, with IANA available for a final decision after other avenues were exhausted. Each registry had to state how an assignment decision could be appealed.
That language separated correction from review more clearly than the earlier instruments. A parser correction repaired information before final processing. An appeal challenged an assignment decision. Review was the parent’s examination of that challenge. Remedy would be the resulting disposition—upholding, changing, remanding or replacing the original decision.
The reviewed practice materials contain no identified appeal file. RFC 2050 nevertheless placed a review route, document-transfer duty and escalation path into public view. By the end of the period, an applicant could cite more than an informal opportunity to ask a senior official for another look.
Four artifacts of practice
The operational record examined here is small but varied. Its value depends on classifying each item for what it actually records.
The PIPEX correspondence is the sole partial request discussion. It begins with an unspecified “couple” of requests and shows technical fact-checking before decision. It preserves neither an exact requested quantity nor an applicant response or disposition.
The second artifact is Marten Terpstra’s 19 March 1993 notice, “Typos in assignments”. Terpstra wrote that typographical errors in assignments and registry updates were “increasing,” particularly confusion between numbers beginning with 192 and 193. He also described assignments and ordinary updates being sent to the wrong mailboxes.
RIPE NCC introduced stricter checks on material sent to the assignment address. If a network already appeared in the relevant records, the item would initially be rejected and an error sent to NCC staff. Staff would determine whether the issue was probably a typographical mistake or use of the wrong submission channel. An update sent to the wrong mailbox could be forwarded for processing; a suspected mistyped number could prompt contact with the sender.
This is an operational control for assignment notices and updates. It shows an announced division between channel errors and probable data errors. “Increasing” has no baseline, observation period or count, and the message includes no completed correction linked to an original address application. It belongs in the history of clerical safeguards rather than in a denominator of applicant outcomes.
The third artifact is Daniel Karrenberg’s 14 May 1993 message on “Supernet block sizes”. Karrenberg described a conservative approach to a large, weakly substantiated Class C request. The registry could release less than the amount sought while reserving contiguous space for later need. A requester could return with evidence showing use of the initial allocation. Reserved space was expected to be recycled after 12 to 18 months.
That interval referred to retention of reserved contiguous space before recycling. It was neither a decision time nor a general projection horizon. Karrenberg’s numerical illustration involved a request for 64 Class C networks that lacked strong substantiation, followed in the example by an allocation of 16 or 32 and reservation of the same amount.
The passage is an official’s description of recommended practice, not an observed reduction. It names no applicant, submitted form, allocation record or final result. Karrenberg also wrote that after about a year only a “small part” came back for more space. “Small part” remains unquantified: the message supplies neither numerator nor denominator.
The policy logic is still informative. Releasing an initial portion reduced the cost of a weak forecast. Reserving adjacent space protected a route-aggregation option if later demand materialised. Recycling after a stated interval limited the cost of keeping that option open indefinitely. The communication reveals how one registry official described balancing conservation and aggregation under uncertainty.
The fourth artifact is the RIPE-18 meeting record. Participants reported incidents in which applications rejected in Europe were accepted after reapplication to other regional registries. The group expressed concern about disparity between RIPE and InterNIC criteria and assigned Daniel Karrenberg an action to convey that concern to InterNIC.
Participants also agreed that a revised form should ask about parent organisations, existing address holdings, prior applications and requests previously turned down. The institutional response was therefore concrete: a reported problem produced an action item and proposed changes to the information collected from later applicants.
The minutes do not supply the applications behind those reports. They identify no applicant, date, quantity, decision notice, changed fact, later allocation or reviewer. “Incidents” carries no count. The record establishes what participants reported and how the group responded, while leaving equivalence between the first and later applications untested.
Taken together, the artifacts show open technical consultation, an assignment-update control, an official account of conservative allocation and a governance response to reported regional disparity. None yields a success, refusal, correction, reduction, exception or reversal rate.
Confidentiality and the shape of survival
The private half of an address request could contain the facts most relevant to its outcome. Engineering plans exposed internal topology, projected expansion, equipment limitations, network segmentation, host distribution and sometimes commercial intentions. Publishing them automatically could discourage candid forecasting.
The instruments responded by separating public identity data from sensitive technical evidence. RIPE-095 placed administrative contacts and assigned numbers in the public register while reserving technical details for internal use. RFC 1466 required strict confidence for Class B engineering plans. RFC 2050 protected information specifically designated as sensitive and offered parent-registry handling when the assigning registry could not provide adequate assurance.
Confidentiality could improve decision quality. An official trying to distinguish operational need from speculative stockpiling required details that an organisation might reasonably withhold from competitors or the general public. Protected submission created space for a fuller account.
It also shaped what later observers can measure. An allocation entry might identify an organisation, date and address block while withholding the forecast or topology that justified the quantity. Conversely, a surviving blank form shows the expected inputs while saying nothing about how an examiner treated them.
Preservation is likely to favour visible results. Successful assignments generated public records and later operational dependencies. An abandoned or unsuccessful request might end in private correspondence, a telephone call or no durable entry. Amendments may have replaced earlier drafts rather than remaining beside them. Restricted engineering files may survive under access conditions that prevent public comparison.
These forces explain why an allocation register cannot serve as a representative sample of original applications. They do not establish the size or direction of missing outcomes. Confidentiality is compatible with careful, consistent examination and with unexplained variation; the public evidence alone cannot select between those possibilities.
Where automation stopped
The contrast between RFC 1400 and the substantive address guidelines clarifies what written procedure could readily control.
Template choice, machine parsing, verification, resubmission, expiry and ticket status were comparatively determinate. The process could identify an obsolete form, return an error, invite correction and record whether verification arrived within seven days. Terpstra’s assignment notice likewise specified how staff should distinguish a wrong mailbox from a likely mistyped number.
Substantive scarcity judgments involved less observable variables. Forecasts depended on planned procurement, organisational growth and applications not yet deployed. A topology could make the default quantity inefficient. Equipment limitations might be genuine, version-specific, temporary or misunderstood. Aggregation costs fell partly on other network operators rather than on the applicant.
The written rules still shaped these decisions. RFC 1366 provided a demand-to-block baseline. RFC 1466 identified the contents of a Class B engineering plan and published a topology-based departure. RIPE-095 told applicants which machine counts, subnets, holdings and plans mattered. RFC 2050 defined end-site utilisation and exposed the conflict between conservation and routability.
What remained difficult to see was the bridge from accepted evidence to final quantity. Confidentiality hid many decisive inputs. Published exception clauses revealed relevant categories without creating a public register of their use. A review route specified an escalation path without showing the resulting remedy.
The evidence is therefore strongest at the clerical boundary. Forms and automation demonstrably structured how information entered the system. Tables and engineering-plan requirements made parts of substantive judgment contestable. Measuring their influence on final decisions requires applicant-level records joined across those stages.
Authority moved as the registry system changed
The period cannot be described as one office gradually adopting more paperwork. Different organisations performed different functions, and those functions shifted.
In 1990, RFC 1174 described IANA as a function performed by USC/ISI and the Internet Registry for network and autonomous-system identifiers as a function operated by SRI International at the DDN-NIC. The Internet Activities Board recommended policy. It did not itself process each number request.
The DDN-NIC also served a defence-network environment. RFC 1400 preserved a distinct route for DDN users while transferring non-DDN registration services to the InterNIC Registration Service operated by Network Solutions. “InterNIC” was a broader label, but the RFC’s procedural claims concerned Registration Services specifically.
RFC 1366 and RFC 1466 proposed and described regional delegation under IANA and Internet Registry authority. RIPE NCC received blocks for Europe and coordinated local registries. A local service provider could simultaneously be the applicant’s connectivity supplier, adviser and first examiner. RIPE NCC retained regional functions, including examination of Class B matters under the published structure.
By 1996, RFC 2050 presented the hierarchy as IANA, regional registries and local registries, naming InterNIC, RIPE NCC and APNIC. The account came from authors affiliated with those institutions and described the registry practices they said were current.
Authority was layered rather than singular. Global uniqueness depended on technical coordination. Delegated blocks gave regional and local offices operational control. Government awards and contracts supported particular service arrangements. Regional recognition and community participation contributed institutional legitimacy. Provider relationships affected routing and renumbering. Public documents supplied notice and a shared technical vocabulary.
Projecting the later regional-registry model backward would obscure those transitions. Treating technical coordination as an unlimited legal mandate would create a different distortion. At each date, the relevant inquiry is which office performed the function, how that role arose and which procedure applied to the request before it.
Why judgment remained operationally defensible
A wholly mechanical allocation system would have performed poorly against the uncertainty of early Internet growth.
Current machines could be counted, but two-year forecasts depended on procurement, organisational expansion, network architecture and services still being planned. Applicants had incentives to avoid repeated applications and disruptive renumbering. Registries had incentives to resist stockpiling. Neither side possessed complete information.
Topology weakened any simple host-count rule. Six hundred hosts on one campus could present a different engineering problem from 600 hosts spread across ten physical networks. RFC 1466’s ten-Ethernet example recognised that an identical total might support a different quantity of network numbers.
Routing added an externality. An applicant bore the local inconvenience of subnetting or renumbering. Other network operators bore the memory, processing and coordination burden associated with additional routes. Releasing a smaller initial block while reserving adjacent space could preserve aggregation, yet the reservation itself consumed an option on scarce address space.
Evidence quality also varied. A vendor limitation might reflect a real installed constraint, an obsolete version, incomplete documentation or misunderstanding. The PIPEX exchange shows the value of comparing an applicant’s premise with several kinds of expertise. It also warns against assuming that a general product capability resolved the costs of a particular deployment.
Meanwhile, the available technologies were moving. Classful address assumptions, CIDR, provider aggregation, private address space and variable-length subnet masks changed feasible network designs. RIPE-095’s fourteen-day tenure as the latest form illustrates the maintenance pressure around even a relatively modest procedural instrument.
Discretion was therefore not merely an institutional residue waiting to be eliminated. It was a response to forecasts, topologies and external costs that did not fit a single table. The governance question is whether officials used that judgment within published grounds, documented material departures and exposed final decisions to meaningful review.
What an applicant could know by 1996
Across the period, an applicant’s view of the process became markedly clearer.
Public numerical reference points arrived in RFC 1366 and expanded in RFC 1466. The applicant could see the conjunctive Class B thresholds, the 24-month Class C schedule and a topology example that could justify departure.
RIPE forms then translated those principles into questions. An organisation knew that machines, subnets, existing holdings, connection plans, network layout and future growth would enter the assessment. It knew which information would become public and which technical material would remain confidential. The distinction between applying directly and proceeding through a local registry was described on the form.
RFC 1400 exposed a correction path for machine-processed submissions. The requester could inspect the parsed information, fix mistakes, respond to an error, resubmit and use a trouble-ticket number to check status. Terpstra’s notice similarly made some assignment-update handling visible to local registries.
Exceptions were also disclosed. RFC 1366 allowed case-by-case treatment where Class C blocks were impractical. RFC 1466 identified topology as a recognised ground and required an engineering plan. RFC 2050 continued to acknowledge exceptions while expecting VLSM and detailed justification for equipment-based claims.
By November 1996, the applicant could invoke a named Right to Appeal, document transfer to a parent registry and possible escalation to IANA. That textual architecture was more specific than asking the same office informally to reconsider.
The least visible element was the final evidentiary bridge: which fact controlled the quantity assigned in a particular transaction. Public instruments rarely produced a public decision narrative that joined accepted inputs, deviations and result. Protected engineering plans further limited comparison among applicants. The architecture of review became knowable before its outcome-changing force became measurable in the located record.
The transaction audit still needed
A persuasive test of substantive constraint must use the transaction as its unit.
Each observation would begin with the original application and the exact form and guideline version in force on the submission date. It would record the resource and quantity requested, current and projected hosts, subnet plan, topology, existing holdings, provider relationship and routing circumstances.
The administrative side would identify the responsible registry, examiner, requests for more information, corrections, accepted forecast, reason for each substantive change, final disposition and any invoked exception. Where review occurred, the record would add the grounds of challenge, documents transferred, reviewer, decision and remedy.
Cases near a published threshold would be especially informative. Comparable requests under the same version could show whether accepted forecasts on the same side of a boundary produced comparable results. Documented topology departures could reveal whether discretion followed the stated exception rather than an unstated preference.
A version change offers another test. Similar applications before and after the October 1992 table, or around a documented form revision, could reveal whether outcomes shifted with the instrument. Changes in routing conditions, institutional responsibility and available technology would need to be considered rather than treated as background noise.
Clerical performance should be measured separately. A study of RFC 1400-style processing could count parsing responses, corrected verifications, expiries, resubmissions and abandonment without labelling every machine rejection a refused address application. That would test whether information handling became more regular even if the allocation judgment remained largely discretionary.
Appeal requires its own chain. A valid observation would join the original decision, grounds, transferred file, parent-registry review and resulting disposition. An upheld decision would still demonstrate review. A remedy with outcome-changing force would require a changed allocation, remand or substituted result attributable to the appeal. Reapplication with new facts belongs to a different category.
Sampling should start with office boundaries, dates and record series rather than a list of successful address holders. Public allocation registers disproportionately expose completed assignments. Restricted, missing and destroyed files would need to be recorded under a declared method. Confidential material could be analysed under protected conditions while publishing only variables necessary to evaluate the decision.
Such a study could estimate reductions, delays, corrections, exceptions, appeals and remedies. It might also examine forecast error, later returns for more space and differences among registries. The guidance documents and four practice artifacts reviewed here are enough to design that audit, but not to calculate its results.
More knowable procedure, final constraint still unmeasured
Between 1988 and 1996, address administration acquired a more public and intelligible structure. Applicants gained clearer routes into the system, advance notice of required evidence, quantitative reference points, correction mechanisms, stated grounds for departure, protection for sensitive plans and eventually a published appeal path. RFC 1400 placed real discipline around clerical handling. RFC 1366 and RFC 1466 made some substantive departures recognisable. RIPE maintained and revised its forms. RFC 1467 recorded an institutional account of administrative implementation, and RFC 2050 described a mature hierarchy with document-transfer and review duties.
Those changes moved the system away from dependence on an entirely unstructured exchange with a Hostmaster. They also helped registries compare forecasts, topology and existing holdings across a rapidly expanding network. The operational case for retaining judgment remained strong because address conservation, routing aggregation, applicant costs and uncertain growth could point in different directions.
The opened transaction evidence has a narrower reach. It consists of one partial request discussion and three operational or institutional observations. The PIPEX correspondence shows peer testing of a software claim but stops before disposition. Terpstra’s notice concerns assignment and update controls. Karrenberg’s numerical example describes conservative practice without identifying an applicant outcome. RIPE-18 records participant reports and an institutional response without the underlying applications.
No complete identified chain in the reviewed set joins original application, applicable version, correction, contemporaneous reason, final allocation, review and remedy. As a result, the consistency of substantive decisions and the rates of success or refusal remain unmeasured. Earlier address forms may also revise the chronology of the earliest written criteria once they are searched directly.
The historical result is therefore bounded but consequential. Public forms and tables made applicant inputs, clerical treatment and some departures more knowable. They created the conditions for scrutiny. The surviving public record has yet to supply the transaction sample needed to determine how consistently those criteria governed final judgment.