Summary

  • RFC 1550 invited requirements and concerns from anyone with a stake in IPng, while temporarily refusing papers that evaluated particular candidate protocols.
  • A common format, clarity review and separate feasibility review made submissions usable without turning review or publication into endorsement.
  • Twenty-one papers later fed a technical-criteria document; the recommendation remained a separate act, and deployment remained another question again.

The first witnesses were a meter and a radio

The first page of RFC 1550 did not begin with the size of an address field. It imagined a utility representative explaining what scale and addressing would be needed if meters joined the network. Then it imagined someone explaining what wireless connectivity might demand of the next Internet Protocol.

Those examples were a choice about evidence. The IETF's IP: Next Generation area knew that a successor to IPv4 would be evaluated as an engineering object, but it also knew that the requirements could not be recovered from a protocol diagram alone. A meter fleet, a radio network, a corporate operator and a security engineer would encounter different costs. If those costs appeared only after a favorite design had hardened, each could be dismissed as an inconvenient edge case.

RFC 1550 therefore asked all interested parties for white papers on requirements an IPng had to fulfill and factors that might sway selection. The document was published in December 1993 by Scott Bradner and Allison Mankin. Its RFC Editor record and IETF record classify it as Informational. It specified no Internet standard.

That modest status was not a defect. The memo's job was to construct an input surface for a decision that had not yet been made.

The candidates had to wait outside

The solicitation drew a hard sequence boundary. At that moment it would not accept papers evaluating specific IPng proposals. Such evaluations could arrive after the proposal documents were considered clear and complete.

This delay protected the problem statement from the sales pitch. Once a named candidate enters a discussion, requirements acquire a gravitational field. A concern about mobile hosts can become an argument for one header. A transition problem can become a defense of one tunneling scheme. An operating cost can be reframed as a temporary inconvenience on the road to an assumed winner.

RFC 1550 did not prevent advocacy forever. It required an earlier evidentiary phase in which the claim was “this environment imposes this constraint,” not “therefore choose my protocol.” The distinction is easily lost in later histories because the winner is known. In December 1993 it was not.

Nor did the invitation itself select who counted as a legitimate future user. It said all interested parties could submit. That widened the aperture, but it did not turn the resulting papers into votes or their authors into representatives of everyone absent.

Review was not a hidden ballot

The review path was unusually explicit. Members of the IPng directorate and an external review board would first examine a paper for clarity. They could point to confusing passages and urge the author to reconsider them. A separate technical review would assess feasibility within the context of the paper, without making value judgments.

The author retained the next move. Revisions were optional. After review and any changes the author chose to make, a paper would become an Internet-Draft and later an Informational RFC unless the author withdrew it. The documents were meant to become part of the historical record.

Each verb matters. A reviewer could clarify; a technical reader could test feasibility; an author could revise or withdraw; the publication system could preserve. None of those acts meant the IETF accepted the idea. The response papers repeated this limit. RFC 1667, RFC 1669, RFC 1675 and RFC 1678 all stated that publication did not imply acceptance by the IPng area.

Two industry papers were even more careful. The cellular response in RFC 1674 said its statements were input to technical discussion, not an endorsement or commitment by the cellular industry, its consortium or constituent companies. The cable response in RFC 1686 carried a parallel disclaimer. A paper could be attributable without pretending to bind the industry named in its title.

Ten pages made evidence comparable, not identical

RFC 1550 imposed a small documentary machine. The reference copy had to be ASCII and follow RFC formatting. A white paper could not exceed ten pages. Its executive summary could not exceed half a page. It had to stay focused and provide specific references to data supporting its claims. An author with separate concerns could submit more than one paper.

The limits did not make different experiences commensurable. A security threat, a router performance target and a utility deployment forecast cannot be reduced to one unit. The common form did something more practical: it gave later readers a bounded object with a short claim, an attributable author and an inspectable evidence trail.

Formatting also allocated attention. Ten pages made it harder for a well-funded constituency to occupy the entire record by volume. A half-page summary forced the requested action into view. Specific data references made unsupported forecasts easier to distinguish from measured constraints. These are design effects, not guarantees. A concise paper can still be wrong, and an absent group cannot be recovered by excellent formatting.

Sixteen questions, deliberately without rank

The solicitation offered sixteen engineering areas in no particular order. Scaling and timescale sat beside transition and deployment. Security sat beside configuration, administration and day-to-day operation. Mobile hosts, flows and resource reservation, policy-based routing and topological flexibility widened the architectural surface. Applicability and markets, the datagram service, accounting and support for different communications media brought commercial and physical surroundings into view. Robustness and fault tolerance, technology pull and explicit action items completed the list.

The operator appeared directly. What should IPng include—or avoid—to minimize effects on people running increasingly large and complex networks? The robustness prompt was equally cautious. IPv4 networks might continue working despite flaws not yet understood, so a successor could accidentally remove resilience while improving something easier to count.

This was not a requirements checklist with sixteen equal weights. It was a map of possible blind spots. Submitters could address any of the areas or introduce another germane subject. Timescale papers would be sent to one working group; transition papers to another. The call routed evidence toward the people able to use it without claiming that the routing settled the decision.

Twenty-one answers changed the record

The later recommendation in RFC 1752 reported 21 responses. It said the call sought views both inside and outside the traditional IETF constituency. The resulting archive shows why.

RFC 1667 described real-time, multicast and reservation needs from defense modeling and simulation. RFC 1669 treated market viability as a criterion rather than assuming technical merit would compel adoption. RFC 1673 brought the electric-power industry into the record. RFC 1674 asked that mobility and occasionally connected hosts not be designed out of the future network.

RFC 1675 argued that the successor at least must not make security worse. RFC 1678 described large corporate networks carrying mission-critical applications and deliberately framed capabilities as requirements rather than solutions. RFC 1686 walked through the question set from the perspective of cable networks.

Transition had its own local reality. RFC 1671 argued that migration would take years and that each site would need a staged plan; only the smallest sites could imagine a single flag day. The later SIPP white paper, RFC 1710, made the adoption test blunt: a good new protocol without a practical route for the installed IPv4 base would not be enough, and an Internet-wide controlled rollout was unrealistic.

These documents did not prove that the archive was complete. Twenty-one is a count of papers, not a denominator for the affected world. The papers differed in evidence, scope and institutional relationship. Their value was that future constraints became named claims that later reasoning could cite, challenge or ignore visibly.

Inputs became criteria, not arithmetic

RFC 1752 later traced the white papers, a requirements BOF, discussions inside the IPng directorate and the big-internet mailing list into the revision of the criteria document published as RFC 1726. The RFC Editor entry records that document separately.

RFC 1726 resisted two seductive simplifications. Its criteria were presented without weights, and it tried to state requirements rather than prescribe mechanisms. Routing scalability was a goal; route aggregation was one possible part of a solution. The authors also warned that criteria could identify serious contenders without mechanically answering every trade-off between performance and function.

That limit preserved responsibility. A scorecard can hide judgment inside weights, then pretend the winner emerged from arithmetic. A list of goals exposes more of the decision: which evidence was admitted, how conflicting objectives were treated and who accepted the consequences of a trade-off.

RFC 1719 made the authority boundary clearer. It placed responsibility for an IPng recommendation with the IESG, required the procedure to be open and published in advance, and called for ample community comment. Input could discipline the decision; it did not make responsibility evaporate into “the community.”

The recommendation needed its own document

RFC 1752 is a later act, not the hidden ending of RFC 1550. It recorded evaluation of CATNIP, SIPP and TUBA as described in their white papers and recommended a revised SIPP basis for IPng. Its information page identifies the recommendation as its own record.

The separation gives the history an auditable chain:

  1. a solicitation defined the questions and delayed candidate advocacy;
  2. identifiable authors supplied claims and evidence;
  3. reviewers tested clarity and feasibility without conferring acceptance;
  4. criteria authors synthesized requirements without pretending to remove trade-offs;
  5. the IESG owned a later recommendation;
  6. implementers and operators still had to turn a document into running systems.

The chain is not proof that every stage worked perfectly. RFC 1752 does not report equal influence for every paper. The source set does not reveal every absent view, every private conversation or every reason a criterion changed. It does show that request, submission, preservation, synthesis and recommendation were separate artifacts. That is more accountable than a story in which “consensus chose IPv6” and all intermediate receipts disappear.

Being invited was not a mandate

Heng Lu's essay on the multi-stakeholder mirage supplies a sharp contemporary test: participation can provide evidence, expertise, warning and objection without granting authority to bind the party bearing the loss.

RFC 1550 looks strongest through that narrow lens. It invited input widely, attached claims to authors, preserved disclaimers and kept final responsibility elsewhere. It did not call the 21 papers an electorate. It did not make an industry paper bind an industry. It did not treat a feasibility review as a transfer of mandate.

The same caution applies to documents and deployment. Minimum Initial Specification, Localized Future Decision and Voluntary Adoption distinguishes publication from operational adoption. Running-Code Primacy asks whether coordination artifacts survive contact with implementation. The reality-layer discipline requires different receipts for what was requested, recommended, installed and observed.

Those are later concepts. They do not prove that Bradner, Mankin or the IESG held Heng Lu's theory. They help name a distinction already visible in the documents: a published concern was real as evidence, not automatically real as code.

Three receipts should never be collapsed

RFC 1550's deepest contribution was not one of its sixteen questions. It was the order in which questions, candidates and authority appeared.

First came the people and environments that would have to live with the protocol. Next came an organized record of their claims. Criteria were constructed from that wider record. Candidate evaluation and recommendation came later. Adoption remained beyond the power of the page.

A participant can be heard without becoming the decision-maker. A proposal can be selected without becoming deployed. A protocol can be implemented without being universally adopted. The historical record needs a separate receipt for each transition.

The utility meter on the first page never voted for IPv6. The wireless link did not confer a mandate. They did something more useful: they forced the future protocol to answer for consequences that its own advocates might not have thought to ask about.

Sources