Summary
- RFC 790 directly establishes that several number series were maintained as a current operational reference and that developers were instructed to contact Jon Postel for assignments, but it publishes no general network eligibility rule or division of allocation authority.
- RFC 820 adds research, defense and commercial categories, a recommended distribution of network-number space, a proposed gateway-readiness condition for research applicants and a prospective division of responsibilities among institutions.
- RFC 820 also states that its recommendation had not been fully implemented and that Postel was still coordinating all assignments, so agreement, proposed policy and working practice cannot be treated as the same institutional state.
- The published tables reveal assignments, transitions and internal inconsistencies, not the population of applicants. Without request, refusal, withdrawal, utilisation and contemporaneous correspondence records, they cannot establish applicant treatment, distributive motive or an intention to conceal decision-making.
Put the first page of two monospaced documents under the same reading lamp. On page 1 of RFC 790, dated September 1981, the introductory paragraph says that current information can be obtained from Jon Postel and then adds: “The assignment of numbers is also handled by Jon.” The corresponding paragraph in the examined text of RFC 820 retains the personal grammar but inserts a qualification: the assignments are handled by the same coordinator subject to an agreement between DARPA/IPTO and DDN/PMO documented in Appendix A.
The added clause is small enough to disappear inside a document dominated by columns of numbers. Appendix A is not small. It reports agreements reached at a September 1982 meeting, recommends dividing network-number space among research and development, Department of Defense and commercial uses, names prospective institutional responsibilities, proposes an eligibility condition for research networks and ends by acknowledging that the arrangement has not yet been fully implemented.
The juxtaposition poses a precise question. Did the later document expose authority that had been invisible in the earlier inventory? Did it announce a new allocation policy, document an arrangement already developing in practice, manage the transition to a different network architecture, or simply provide a fuller editorial account of work that had always required coordination? The pages permit some of those possibilities to be tested. They do not permit a choice among them to be made solely from layout.
This is therefore not a claim that a technical table secretly legislated for the Internet. It is an inquiry into what had to happen before an entry could become part of a shared operational record. The answer varies by number series. Selecting an unused protocol code is not the same operation as deciding which class and administrative category should contain a network. Recording a port is not equivalent to deciding whether an experimental network has become operational. Publishing a contact does not identify the applicant, adjudicator or beneficiary. The central task is to separate those functions before asking what institutional assumptions the documents support.
Two artefacts, one catalog discrepancy
RFC 790 is a 15-page Network Working Group document attributed to J. Postel at the University of Southern California’s Information Sciences Institute and dated September 1981. It says that it records currently assigned values from several series used in network protocol implementations. A developer needing a link, socket, port, protocol or network number is instructed to contact Postel to receive an assignment.
The document proceeds through assigned network numbers, Internet version numbers, Internet protocol numbers, port or socket numbers and ARPANET link numbers. References and a directory of responsible people follow. Bracketed codes beside entries point to documents or named contacts. The form serves at least three immediate purposes: avoiding numeric collisions, telling implementers what a value denotes and providing someone to contact when the terse row is insufficient.
RFC 790 also declares that it will be updated periodically. That promise is fundamental to its status. It was not designed to remain the final word. It superseded earlier Assigned Numbers documents and would itself be superseded. Its claim to be current concerned a particular operational moment, not permanent authority or immutable historical truth.
The network-number section occupies pages 2 through 4. It explains the three address classes and prints their bit layouts. Class A uses a leading zero, seven network-number bits and a 24-bit local field. Class B uses the high-order pattern 10, fourteen network-number bits and a 16-bit local field. Class C uses 110, twenty-one network-number bits and an eight-bit local field. These were technical categories with radically different capacities, but the existence of different capacities does not by itself establish how applications were assessed or whether conservation was the reason for any assignment.
The named Class A rows form a mixed and incomplete snapshot. They include research networks, packet-radio experiments, military facilities, public-data networks, universities, contractors and commercial operators in several countries. The table does not identify the universe from which these entries emerged. It is not a census of networks that wanted identifiers, a list of applicants or a record of applications that did not result in published assignments.
The examined RFC 820 artefact is longer, at 22 pages. Its text header displays J. Postel and J. Vernon and says January 1983. The current RFC Editor catalog entry instead labels RFC 820 “Assigned numbers, August 1982” and lists J. Postel alone. This analysis identifies passages by the header and page numbers of the examined text while preserving the catalog discrepancy. The available sources do not justify silently choosing one date-and-authorship convention as the correction of the other.
RFC 820 retains the earlier inventory function but expands its scope. It refers to the transition from the ARPANET environment to the ARPA Internet, adds autonomous system numbers, includes Ethernet numbers and public-data-network mappings, and substantially enlarges the network tables. Most importantly here, page 1 subjects number allocation to the DARPA/IPTO–DDN/PMO agreement, while pages 19 through 22 reproduce the resulting recommendations and implementation note.
Both RFCs are now classified as Historic in the Legacy stream. RFC 790 was obsoleted by RFC 820, and RFC 820 was obsoleted by RFC 870. Those current classifications do not imply that the documents were invalid or irrelevant when used. A recurring registry publication becomes outdated because assignments and practices change. Later obsolescence is part of that documentary lifecycle, not a retrospective cancellation of the earlier snapshot.
A later comparison helps define the limit. RFC 943, published in April 1985, explicitly describes itself as an official status report for numbers used in protocols in the ARPA-Internet community. It also distinguishes networks connected to the ARPA or DDN Internets from independent networks using the Internet protocols. That later articulation cannot be imported into RFC 790. It shows that the language and classification apparatus continued to develop.
The decisive differences between the two principal artefacts can be compressed without pretending that each difference has one cause:
| Feature | RFC 790, September 1981 | Examined RFC 820 text, January 1983 | Supported finding |
|---|---|---|---|
| Assignment contact | Page 1 says assignments are handled by Jon Postel. | Page 1 retains Postel but makes allocation subject to a DARPA/IPTO–DDN/PMO agreement. | Both present assignment as an organised function; the later text acknowledges an agency arrangement. |
| Network classification | Pages 2–4 use technical address classes without administrative-use codes. | Pages 2–6 add R, D and C for research and development, DoD and commercial. |
The later network table records an administrative category as well as an address class. |
| Transition | No equivalent transition notation is explained. | Page 2 explains that old network numbers are retained with T marks during changeovers. |
Continuity could require old and new identifiers to coexist in the published record. |
| Prospective allocation authority | No multi-institution allocation scheme is printed. | Appendix A, pages 19–21, recommends responsibilities for different use categories. | A shared tracking function was conceptually separable from all substantive assignment decisions. |
| Eligibility | No general network-applicant criterion is printed. | Page 20 recommends gateway-related evidence for research applicants. | The proposed research policy involved more than collision checking. |
| Implementation | No comparable appendix appears. | Page 22 says the recommendation is not fully implemented and Postel currently coordinates all assignments. | Recommendation, agreement and working practice remained distinct. |
| Decision record | No request totals, reasons or exception records are published. | The expanded policy still does not publish them. | The documents show successful or surviving entries, not the complete decision population. |
The comparison establishes documentary change. The next question is what kind of administration each word and table required.
“Assigned,” “registered,” “current” and “official” were not synonyms
The opening instruction in RFC 790 does more than invite a developer to report a self-selected value. It says to contact Postel “to receive a number assignment.” Before a new value could appear safely in a shared list, someone had to learn of the request, check for collision, choose or confirm a value, communicate the result and update the record. That minimum sequence is coordinated administration.
It does not follow that every series involved an equally consequential decision. For many protocol or port requests, the essential act may have been finding an unused code point and maintaining interoperability. The text supplies no basis for claiming that every developer’s institutional merits were evaluated. The word “assignment” denotes an operation, but its presence alone does not disclose the criteria or depth of judgment behind it.
Network numbers are different because RFC 820 connects them to administrative-use categories and a recommended eligibility condition. Appendix A says that, within the research and development community, network identifiers will be granted only to applicants who show evidence that they are acquiring standard BBN gateway software or have implemented or are acquiring a gateway meeting Exterior Gateway Protocol requirements. It adds that acquiring Berkeley BSD 4.2 UNIX software might count as evidence of the latter.
The wording is stronger than a mere uniqueness check. It conditions a recommended grant on evidence of technical readiness. But it remains part of the recommended policy, not proof of an already universal operating rule. The appendix does not specify a complete evidentiary standard, an adjudication method, an appeal process or a record of applications assessed under the condition. The final page explicitly says that the recommendation has not yet been fully implemented.
“Current” performs another function. Both documents claim to describe currently assigned values and tell readers where current information can be obtained. In this setting, currentness is a claim about synchronisation: implementers should be able to consult a maintained reference rather than rely on incompatible private lists. It does not mean that each entry’s original rationale, institutional history or present holder is fully documented.
RFC 820 uses “registered” in its autonomous system section. The Exterior Gateway Protocol provides a 16-bit field identifying autonomous systems, and the values are registered in the document. The initial table is nearly empty: zero is reserved, one identifies the BBN gateways, values two through 65,534 are unassigned and 65,535 is reserved. Here registration describes common recording of an identifier series at an early stage. It cannot be applied indiscriminately to the network appendix, where classification and recommended applicant evidence add different considerations.
“Official” becomes explicit in RFC 943, not in the opening status language of RFC 790 or RFC 820. That later formulation describes recognition within the ARPA-Internet community. It does not make every earlier act of list maintenance equivalent to a formal governmental decision, nor does it establish that an entry had the same significance outside the community for which the report operated.
The words therefore identify overlapping but separable functions. Assignment can include selection or confirmation. Registration records a value. Currentness expresses maintenance. Official status identifies recognised standing in a defined operational community. Their proximity in the Assigned Numbers lineage does not collapse them into one universal authority.
One publication contained several unlike registries
The title “Assigned Numbers” gathers multiple series into one document, but their collision problems and institutional stakes were not interchangeable.
An Internet protocol number occupied an eight-bit field in the IP header and identified the next-level protocol carried by a packet. Coordinating that number allowed different implementations to interpret the field consistently. RFC 820’s Appendix A proposed reserving portions of the protocol-number space for DoD standards, research uses and commercial, national or international standards. That was coordination over protocol identifiers, not an allocation of host-address capacity to an organisation.
A port number identified a service contact point at the end of a logical connection. RFC 790 still discussed both AHHP sockets and TCP ports, while RFC 820 presented a port list centred on TCP and reuse with UDP where possible. Assigning a well-known port could make a service interoperable across implementations. It did not make the named protocol author or service contact the holder of a network block.
Network numbers performed a different role. They identified networks in the Internet addressing architecture. The class selected determined the width of the local-address field: 24 bits for Class A, sixteen for Class B and eight for Class C. Network assignments therefore differed not only as labels but also in address capacity and routing treatment. The category code, transition mark and gateway-readiness recommendation in RFC 820 applied to this more institutionally differentiated operation.
Autonomous system numbers were another distinct series. Their purpose was to identify groups of gateways for the Exterior Gateway Protocol. Their appearance in RFC 820 records the early development of interdomain coordination; it does not supply a general doctrine for network-number eligibility.
ARPANET link numbers belonged to the Host/IMP interface environment. RFC 820’s appendix recommended eliminating unnecessary uses and studying interoperability questions among interfaces. That task concerned another protocol field and another set of operational dependencies.
Name registration should not be inferred merely because the port tables contain name-related services. RFC 790 assigns port 42 to a name server and port 43 to Whois. RFC 820 contains those service contacts and adds host-name or mailbox name-server ports. These are entries for reaching services, not a registry of host names or domains. The people section is likewise a directory of responsible contacts, not a name registry or applicant ledger.
The Computer History Museum finding aid for the SRI ARC/NIC records reinforces the institutional distinction. It describes the SRI Network Information Center’s maintenance of the ARPANET Host Table and later naming transitions as a separate activity. It also states that administration of Assigned Numbers and global address allocation transferred from USC-ISI to the SRI NIC contract in 1987. The finding aid is later archival context, not evidence that SRI operated the 1981–1983 assignment function described in the two RFCs.
Grouping the series in one reference publication made operational sense. Developers could find related constants and contacts in one place. Yet the common format did not make every listed number a grant of the same kind. Governance conclusions drawn from the network-number appendix must remain attached to that appendix unless another section supplies its own evidence.
Administrative categories did not replace technical classes
RFC 820 overlays two different classifications. The first is architectural: Class A, B and C define address formats. The second is administrative: R, D and C identify research and development, DoD and commercial uses. Confusing them creates false comparisons.
On page 2, the examined RFC 820 text correctly describes Class A as having a leading zero and Class B as having the leading pattern 10. Its prose describes Class C’s three highest-order bits as 1-0-0, but the adjacent diagram shows 1 1 0, and its Class C range begins at 192, whose high-order bits are 110. RFC 790 also prints the Class C pattern as 110. The 1-0-0 phrase in RFC 820 is therefore an internal textual error, not evidence of a different address architecture.
The three technical classes contained 128, 16,384 and 2,097,152 possible network-number values respectively before reserved endpoints and other exclusions. Their local fields contained (2^{24}), (2^{16}) and (2^8) numerical address values per network. Those differences made the choice of class consequential, but neither RFC provides host-utilisation measurements for its listed networks.
The administrative codes answer a separate question: which use category the document associated with an assigned identifier. A research code does not imply a small or large class. A commercial organisation could participate in a research project, while a contractor’s network could be classified by the use of the network rather than the legal character of the institution. A contact’s employer, the network description and the category code cannot be treated as interchangeable evidence.
Appendix A recommends dividing the available class spaces among the three uses. For Class A, it gives eight networks to research and development, 24 to DoD and 94 to commercial use. For Class B, it gives 1,024, 3,072 and 12,286. For Class C, the appendix prints 65,536 for research, 458,725 for DoD and 1,572,862 for commercial use.
Those are proposed allocations, not a description of a completed distribution. The working table on page 6 reports 26 assigned research Class A identifiers, four defense and one commercial. The 26 research entries are 3.25 times the appendix’s recommended allocation of eight. Several entries are marked as old transition numbers. The mismatch is consistent with the document’s explicit statement that implementation remains incomplete.
The document also contains a numerical inconsistency. The page 6 “Maximum Allowed” summary gives the Class C defense allocation as 458,752, while Appendix A on page 20 prints 458,725. The difference is 27 identifiers.
Using the page 6 figure, the proposed Class C categories sum to:
- 65,536 research identifiers;
- 458,752 defense identifiers; and
- 1,572,862 commercial identifiers;
for a total of 2,097,150. That matches the 2,097,152-value Class C network-number space after the first and last values are reserved.
Using Appendix A’s printed 458,725 instead produces 2,097,123, which is 27 short of the page 6 total. The document supplies no explanation. A reconstruction should preserve both printed claims rather than silently repairing one.
Appendix A further recommends that experimental networks becoming operational need not be renumbered when renumbering would cause hardship. Their identifiers could instead move from research to defense or commercial status. The overall category allocations were supposed to remain constant while specific identifiers changed state. The appendix therefore advises against allocating the categories as simple contiguous partitions and recommends specific assignments tracked across the responsible bodies.
This is a policy recommendation about classification, continuity and coordination. It does not prove how any particular network obtained its existing row. A category code records the result printed in the table; it is not a surviving statement of reasons.
Recommendation, agreement and working practice occupied the same appendix
Appendix A begins by saying that it summarises agreements reached by DDN/PMO and DARPA at a September 1982 meeting. It then repeatedly uses the language of recommendation.
For network identifiers, the narrative recommends that assignments for research, defense and commercial uses become the responsibility of DARPA, DCA PCCO/DDN and the National Bureau of Standards respectively. The numerical tables, however, name ARPA as the research assigner and print TBD for the defense and commercial assigners.
Three institutional states are therefore visible. The agencies had reached an agreement sufficient to be summarised. The document recommended a future distribution of responsibilities. Important office-level responsibilities remained unresolved in the tables.
A fourth state appears on page 22: working practice. The implementation note says that the policy recommendation has not been fully implemented and that Postel is currently acting as coordinator for all number assignments. Whatever institutional division the appendix anticipated, applicants and implementers still encountered a central coordinating point.
The gateway-readiness language must be located within this sequence. It states what “will be the policy” inside the research community under the recommended arrangement. It is direct evidence of a proposed eligibility condition. It is not direct evidence that every earlier entry in RFC 790, every entry in RFC 820 or every type of number request had already been processed under that condition.
Similarly, the hardship provision is a recommended transition rule. It shows that the policy designers recognised the operational cost of renumbering. It does not identify which T-marked changes were voluntary, required, negotiated or made for reasons unrelated to the new category allocation.
The appendix nevertheless supports a significant institutional finding. Its authors could distinguish substantive assignment from central tracking. Different bodies could make assignments in different categories, while DDN/PMO or a designee kept track of the combined record to ensure that allocation remained within the recommendation. The common recordkeeper did not have to be the sole source of every decision.
That architecture also carried unresolved problems. If a network changed category, someone had to update the category balances. If an allocator exceeded its amount, a correction or exception procedure would be necessary. If two bodies treated the same request as falling within their jurisdiction, the system would need a way to resolve the overlap. RFC 820 recommends tracking but does not publish a complete jurisdictional code.
The document thus contains an administrative theory in partial form: differentiated pools, multiple possible allocators, central coordination, continuity protection and technical eligibility for one category. It also contains evidence that the theory and the actual assignment interface had not yet converged.
Counting the inventory without turning rows into applicants
The network tables can test how the documentary change appeared in published assignments, but only if three observation units remain separate.
A printed row is a line or range entry as it appears in the document. It may describe one identifier, hundreds of identifiers or an old number retained during transition. Duplicate rows remain printed rows.
An expanded network identifier is one classful network number represented after a printed range is expanded. The RFC 820 range 192.001.xxx through 192.004.xxx, for example, represents four values of the second octet multiplied by 256 values of the third octet, or 1,024 Class C identifiers.
A unique literal identifier string is an expanded identifier after identical printed address strings are deduplicated, without guessing what an apparent sequence was intended to say. This unit preserves transcription conflicts instead of correcting them invisibly.
None of these units is an applicant, recipient, organisation, active route, host or property interest.
RFC 790’s Class A table prints named assignment rows for values 001 through 044 except that 013 is explicitly unassigned. That produces 43 named assignment rows. It does not produce 43 uncontested assigned identifiers. The row for 044 names AMPRNET, but the immediately following unassigned range also begins at 044 and continues through 126. The document therefore supplies 42 unambiguous named identifiers plus one internally conflicting identifier, 044.
Class B contains no named assignment in RFC 790, and neither does Class C. That statement describes the table, not the absence of every smaller network in the world. The listed Class A networks include multiple experiments, related facilities and test networks. A named row is not evidence of one legally independent beneficiary.
RFC 820 supplies a printed “Network Totals” summary on page 6:
| RFC 820 printed summary | Class A | Class B | Class C | Total |
|---|---|---|---|---|
| Research | 26 | 19 | 1,033 | 1,078 |
| Defense | 4 | 5 | 7 | 16 |
| Commercial | 1 | 0 | 2 | 3 |
| Total | 31 | 24 | 1,042 | 1,097 |
Using that printed summary, research accounts for (1,078 / 1,097), or 98.267 per cent, rounded to 98.3 per cent. This is a printed-summary result, not a finding that 98.3 per cent of applicants or organisations were research institutions.
The dominant contribution comes from a single range associated with BBN local networks. Expanding 192.001.xxx through 192.004.xxx yields (4 \times 256 = 1,024) Class C identifiers. Those 1,024 identifiers make up (1,024 / 1,097), or 93.345 per cent, rounded to 93.3 per cent, of the RFC’s printed assigned total.
That denominator is explicit: 1,097 expanded assignments as represented by the printed summary. The ratio does not mean that BBN made 1,024 separate applications, received 1,024 independent decisions or used every network as an externally routed unit. The document associates a range with “BBN local networks” but does not explain the request history or operating topology behind it.
Literal deduplication produces a different result. In the Class C table, 192.005.022 is printed for BRLNET2, BRLNET3, BRLNET4 and BRLNET5. The names suggest an intended sequence, and the next unassigned range begins at 192.005.026, but a literal reconstruction cannot substitute 023, 024 and 025 without marking that as a correction.
Deduplicating the four occurrences of 192.005.022 removes three duplicate occurrences from the printed Class C total:
| Reconstruction | Class A | Class B | Class C | Total |
|---|---|---|---|---|
| RFC 820 printed summary | 31 | 24 | 1,042 | 1,097 |
| Unique literal identifiers | 31 | 24 | 1,039 | 1,094 |
Because the repeated BRL rows are defense-coded, the unique literal category totals become 1,078 research, thirteen defense and three commercial, for 1,094 overall. The research count remains 1,078; the defense count falls from sixteen to thirteen.
The difference is small relative to the BBN range but decisive for method. A printed summary can be reproduced as the source’s claim. A unique-string count can be reproduced as a separate literal reading. Neither should be presented as the other.
Transition entries add another complication. RFC 820 explains that old numbers may remain listed with a T to ease changes. A network can therefore appear under an old Class A identifier and a newer Class B identifier without representing two independently situated recipients. Counting both can be correct for operational recognition and wrong for recipient analysis.
The movement between the documents is still visible. RFC 790 contains named rows only in the Class A table. RFC 820 contains a mixture of 31 Class A, 24 Class B and 1,042 Class C assignments according to its summary, alongside explicit transition marks. Some large earlier identifiers had been replaced, relinquished or retained temporarily while smaller-class identifiers appeared.
That change is consistent with more differentiated assignment sizes. It is not proof that scarcity caused each change. The tables contain no host-utilisation series, forecasts, application forms or decision reasons. A Class A identifier’s capacity says what the address format allowed, not how many addresses the named network used or why administrators selected that class at the relevant time.
The BBN range is important counterevidence against a simple story of uniform preference for the largest available class. One major participant appears through 1,024 small Class C identifiers as well as other entries. The tables do not explain whether this arrangement reflected experiments, local segmentation, routing practice, administrative convenience or another purpose. They do show that institutional prominence did not mechanically produce one address class in every case.
The printed commercial count is also easy to misread. Only three assignments are commercial-coded in the page 6 summary, while Appendix A proposes a large prospective commercial allocation. That contrast may reflect an early-stage policy transition, the limited scope of the working Internet, coding practice, the composition of demand or incomplete implementation. Without applications and correspondence, it cannot establish exclusion or preferential treatment.
What later allocation data can and cannot repair
CAIDA’s visual history of IPv4 allocation offers a useful reconstruction of address-space movement. It also demonstrates why later visualisations cannot supply the missing applicant denominator.
CAIDA explains that the early portion of the visualisation derives from Assigned Numbers RFCs, while later periods use IANA data. The representation operates at /8 granularity, placing smaller allocations inside the larger address blocks that contain them. It notes that allocated address space fell between RFC 790 and RFC 820 partly because some organisations exchanged large blocks for smaller assignments.
That account is compatible with RFC 820’s transition marks and the decline in named Class A entries. It is not independent recipient-level corroboration because its early reconstruction relies on the RFC series under examination. The public date sequence moves from November 1977 to January 1983, and the associated Sankey data aggregate flows by /8. They cannot independently reconstruct each request, assignment decision or recipient transition between RFC 790 and RFC 820.
Later registry records introduce other problems. CAIDA’s separate account of IPv4 consumption methodology notes that a 1993 update assigned many legacy allocations an August 1993 date where precise earlier dates were unavailable. Subsequent records can also inherit organisational renamings, transfers of administrative responsibility, corrections and status changes.
A present registry entry is therefore evidence of a surviving administrative state, not an untouched record of what an applicant requested in 1981. It may help trace later continuity, but it cannot by itself restore the reason, date or decision unit that produced an early row.
The tables can support several empirical findings without overreach:
- RFC 790 prints 43 named Class A assignment rows, of which 42 are unambiguous and one conflicts with the following unassigned range.
- RFC 820’s printed summary reports 1,097 assignments, but literal deduplication yields 1,094 unique address strings.
- Research represents 98.3 per cent of the printed total, largely because one BBN range expands to 1,024 research-coded Class C identifiers.
- The BBN range alone represents 93.3 per cent of the 1,097 printed-summary total.
- Old and new identifiers can coexist because transition rows preserve operational continuity.
- The working table does not yet match Appendix A’s recommended category allocations.
- The documents contain no direct denominator for requests, refusals, withdrawals or discouraged applications.
These findings show that the inventory was administratively produced. Categories, changes, reservations and transitions had to be recorded. They do not reveal whether similarly situated applicants were treated similarly, because the relevant population and decision files are absent.
Four explanations survive the textual delta
The movement from RFC 790 to RFC 820 has at least four period-feasible explanations.
The first is policy development. The September 1982 meeting may have produced a more explicit response to a growing and diversifying Internet. The new category codes, recommended pool sizes, gateway-readiness condition and proposed division of institutional responsibilities support this reading. Appendix A directly presents them as recommended policy connected to an agency agreement.
The second is implementation management. The transition from the ARPANET environment to the ARPA Internet, the development of MILNET and the renumbering or reclassification of networks may have required a more elaborate operational document even without a wholly new distribution philosophy. The T marks, smaller-class assignments and hardship provision fit that explanation.
The third is documentation cleanup. Practices that had previously been understood through correspondence or working relationships may have been written down more clearly. Totals, administrative codes and implementation notes could reflect a better publication rather than the beginning of every practice they describe.
The fourth is drafting preference. The examined RFC 820 header displays an additional name, J. Vernon, even though the current catalog lists Postel alone. A different drafting process could have produced more explicit institutional prose without a proportional change in daily decisions. The catalog/header discrepancy makes authorship and editorial transmission part of the uncertainty rather than a basis for attributing a particular policy role.
These alternatives are not mutually exclusive. The appendix could simultaneously record an agreement, guide a transition, formalise existing expectations and reflect a more expansive editorial style.
Contemporaneous correspondence could distinguish among them. The Computer History Museum finding aid identifies meeting notebooks, NIC progress reports, naming-and-addressing files, chronological email, working-group records and Internet monthly reports collected from contractors. It indicates that potentially relevant communication among NIC staff, network users, working groups and federal agencies survives in archival collections.
The finding aid does not disclose the contents of a specific RFC 790 request, the September 1982 meeting record or the drafting correspondence for Appendix A. It proves the existence and scope of collections, not what unopened records would establish.
A focused archival examination would ask who drafted the appendix, whether the category codes were already used internally, how gateway evidence was assessed, why some assignment authorities remained TBD and whether particular renumberings were proposed by networks or by administrators. Until the underlying records answer those questions, the textual delta supports multiple explanations.
Contacts exposed responsibility without defining the decision chain
Both RFCs devote substantial space to responsible people. A bracketed code beside a protocol or network points to a name, affiliation and mailbox in the people section. This made terse entries operationally usable. A developer could ask someone what an undocumented protocol meant or whom to contact about a named network.
The word “responsible” is nevertheless elastic. The person might be a protocol author, implementer, site contact, engineer, documentation source or registry maintainer. The column does not say whether that person applied for the number, approved it, controlled the network or merely knew enough to answer technical questions.
The ambiguity is visible in the use of JBP, Postel’s code. It appears beside reserved and unassigned ranges as well as assigned protocol values. In those positions it cannot denote a beneficiary. It marks responsibility for the registry state or technical definition. Other codes point toward people associated with named networks. One notation therefore represents several relationships.
The contact apparatus supports a bounded institutional claim: early coordination depended on identifiable experts and reachable mailboxes. It does not support a claim that personal reputation was an allocation criterion. Nor does it show whether preliminary discussions occurred by electronic mail, telephone, paper correspondence or meetings.
Publication in the shared list gave an assignment operational visibility. Implementers relying on the reference could avoid duplication and identify the relevant contact. That practical importance does not establish that the list created every network’s technical existence or conferred a property entitlement. Appendix A’s proposed multi-allocator model instead suggests that assignment decisions could originate in several institutions and be consolidated for tracking.
A fuller ledger was feasible, but not costless
Imagine that the network-number portion of RFC 820 had preserved five additional kinds of information: the applicable eligibility criteria, a short reason code, the provenance of each revision, aggregate request dispositions and the office authorised to decide exceptions.
This need not have required a modern public application system. A period-feasible design could have used a separate fixed-width appendix, paper forms, electronic-mail templates and aggregate monthly totals. Reason codes might have distinguished gateway readiness, experiment, transition, category change and correction. A revision column could have recorded the previous identifier and effective date. Sensitive details could have remained in restricted files while the public list carried a minimal code.
Such records would make several historical questions testable. Researchers could compare completed assignments with withdrawals or refusals, distinguish applicant-requested renumbering from administrative initiation and determine whether the gateway criterion was applied consistently. A named exception authority would show where the proposed division of responsibilities stopped.
The additional record would also impose burdens. Staff would need to preserve intake data consistently, maintain reason vocabularies and reconcile revisions across successive publications. Experimental or defense-related requests could contain details unsuitable for public release. Redaction rules would create further decisions. The TBD entries in RFC 820 show that identifying an exception authority was itself unfinished.
The SRI NIC finding aid describes media incompatibilities, print-production difficulties and rapidly obsolete reference publications in the broader period. Because Assigned Numbers administration remained at USC-ISI until 1987, that evidence cannot establish the precise production process or costs of RFC 790 and RFC 820. It is period context showing that richer documentation would have interacted with real technical and publication constraints.
The counterfactual therefore changes the surviving evidence, not necessarily the legitimacy of the institution. Criteria can be poorly designed, reasons can be formulaic and aggregate counts can omit people who never learned how to apply. Even so, the difference between a successful-entry list and a reasoned decision record would have made later claims about treatment substantially easier to test.
Now reverse the design. Could uniqueness have been coordinated without one central office deciding every assignment?
RFC 820’s own recommendation answers yes in principle. Research, defense and commercial identifiers could be assigned by different bodies while a designated coordinator tracked the combined record. The period already supported electronic mail, telephone coordination and periodically updated documents. Several workable arrangements were conceivable.
One option was specific assignments reported to a common tracker, which Appendix A preferred because identifiers could change category. Another was partitioned pools in which each allocator controlled a defined range and periodically published updates. A third was a distributed set of accountable lists reconciled on a schedule, with temporary reservation messages preventing collisions between editions.
Each alternative had costs. Simple partitions made category changes harder and could strand unused identifiers in one pool. Periodic reconciliation introduced delay. Distributed lists risked conflicting states. Specific assignment through a common tracker reduced some collision risk but made the tracker operationally important.
The point is not that decentralisation would necessarily have been superior. It is that collision control, substantive eligibility and publication could be divided. Common tracking was operationally valuable and explicitly recommended within RFC 820’s architecture, but a single universal inventory was not the only logically possible design.
This distinction matters when interpreting the coordinator’s role. If the designated category allocators were unresolved or unavailable, the person maintaining the common record might continue to process requests in practice. That expansion could result from incomplete implementation rather than a claim to exclusive authority. RFC 820 documents precisely such a gap: distributed responsibility is recommended while one coordinator still handles all assignments.
Federal support explains capacity, not every rule
The government setting can be added only after the two documents have established their own terms.
A 2016 Government Accountability Office legal opinion states that functions later grouped under the IANA name began in work led by Postel at UCLA and moved with him to USC-ISI in 1977. GAO describes the work as performed under United States Department of Defense-funded research projects and continued through later DARPA contracts.
That later account is consistent with RFC 820’s direct references to DARPA/IPTO, DDN/PMO and the September 1982 meeting. It helps explain why a global technical inventory had a United States administrative centre and why the proposed policy distinguished research, defense and commercial uses.
GAO also says that it could not obtain the relevant DARPA contracts from the 1970s through the 1990s. Its more detailed contractual evidence concerns later periods, and its legal question arose decades after RFC 790 and RFC 820.
The opinion therefore cannot establish the clause of a missing 1981 contract, the criteria applied to a particular request or the scope of authority understood by every participant. Federal sponsorship explains institutional capacity and context. It does not, by itself, prove ownership of identifiers, universal consent or the legitimacy of each administrative choice.
The primary evidence remains narrower. RFC 790 names a coordinator for assignments. RFC 820 adds an agency agreement, a recommended division of number space, prospective institutional responsibilities, a proposed research eligibility condition and an incomplete-implementation note. The later government history corroborates the environment but does not turn those statements into a comprehensive charter.
What the columns ultimately support
The politics in an address list do not appear merely because the list distributes identifiers with different technical capacities. They become visible when the document shows classification, eligibility, transition, institutional responsibility and the consequences of relying on a maintained common record.
RFC 790 establishes a concentrated coordinating interface. Several number series were published together, developers were directed to a named assignment contact and the resulting values were presented as current operational information. Its network table records a mixed set of research, government, military, public-data and commercial networks but gives no general applicant criterion or division of allocation responsibility.
RFC 820 adds a more articulated administrative layer. It classifies network identifiers by use, preserves old numbers during transitions, prints assignment totals and sets out recommended category allocations. It proposes gateway-related evidence for research applicants, allows a network to change category without renumbering when hardship would result and imagines assignments made by several institutions under a shared tracking arrangement.
The same document prevents those recommendations from being mistaken for completed practice. Defense and commercial assigners remain TBD in the numerical tables. The working assignments do not match the recommended Class A distribution. The final implementation note says that Postel is still coordinating all assignments.
The tables also resist a simple distributive narrative. RFC 790’s value 044 is internally conflicted. RFC 820 repeats one literal Class C address four times and prints incompatible defense Class C allocation totals. Its 1,097-assignment summary is dominated by a 1,024-identifier BBN range. Transition entries can count the same network under old and new numbers. These are operational records with identifiable editorial and counting problems, not a clean dataset of applicants.
The documents consequently support the inference that network-number coordination involved more than passive transcription. Technical uniqueness had to be protected, but category assignment, transition handling and the proposed readiness condition required administrative judgment. That judgment operated within a federally supported institutional setting and, in the examined RFC 820 text, still passed through one working coordinator.
They also support a less centralising inference. RFC 820 did not equate shared tracking with exclusive substantive allocation authority. Its recommended architecture allowed decisions to originate in several institutions while one body monitored the combined allocation. The design was incomplete, but the conceptual distinction is present.
The remaining uncertainty is not a minor qualification. The public lists contain no application population, rejection count, withdrawal history, utilisation series or reason for each assignment. The available finding aid identifies potentially relevant correspondence but does not reveal its contents. The documents cannot show whether the compact format resulted from convenience, publication limits, inherited convention, deliberate minimalism or another cause.
Nor do the tables establish a mature scarcity doctrine. They show finite class spaces, reserved values, category allocations and movement among address sizes. They do not show that scarcity motivated a particular assignment or that an applicant was refused because of it. Later address exhaustion increased the consequences of early distributions without reconstructing their original motives.
What survives is a documented administrative capacity with real operational effects. The lists coordinated values, made certain assignments visible, classified networks and helped preserve continuity during change. Dependence on that record could make its maintenance consequential even if the recordkeeper did not claim to author the legitimacy of every network.
Under the reading lamp, the significant difference between the two documents is therefore not that politics suddenly entered the table in 1983. It is that RFC 820 made more of the administrative machinery legible: an agreement, use categories, prospective allocators, an eligibility recommendation, transition rules and an admission that implementation lagged behind design.
That machinery can be described without attributing hidden motives to its operators. Its distributive consequences can be measured without turning ranges into applicants. Its authority can be examined without assuming that a clean column is proof of either legitimacy or concealment. The most durable lesson of the two-document archaeology is that a technical inventory may be indispensable evidence of what a coordinating system recognised while remaining incomplete evidence of how, why and by whom recognition was decided.