RFC 3113: Cooperation Without Merged Authority

Summary

RFC 3113 asked 3GPP to use IETF standards unchanged where feasible and to bring needed changes back to the appropriate IETF working group or Area Director rather than fork the protocol privately.
The collaboration did not create a joint sovereign. Each organization retained its own rules for intellectual property, specification drafting, approval and maintenance; liaisons carried information but could not waive IETF procedure.

One network, two rulebooks

By 2001, a mobile system could no longer be designed as a private island. Its terminals, core network and services had to meet the Internet. Yet the organizations building those two worlds were not departments of one institution. 3GPP produced technical specifications for a mobile system. The IETF developed Internet protocols through its own working groups and process. A dependency could cross that border; jurisdiction could not be assumed to follow it.

RFC 3113 opened by stating the objective in practical terms: timely specifications and maximum interoperability with existing fixed and mobile Internet systems, devices and protocols. Then it placed a constitutional limit beside that ambition. Each organization would continue under its own rules and procedures, including its rules for intellectual-property policy, specification elaboration, approval and maintenance.

That sentence is the center of the document. Collaboration was not a merger. A 3GPP schedule did not become an IETF approval. An IETF liaison did not become a substitute working group. Technical dependence did not transfer ownership of the dependent specification. The institutions could coordinate a shared system precisely because the interface identified which decision remained on which side.

The historical temptation is to describe such arrangements as a diplomatic layer floating above engineering. RFC 3113 was more operational. It was about what happened when a release plan needed a protocol, when wireless constraints exposed a problem in that protocol, and when two publication clocks had to converge without either body silently rewriting the other's work.

Reuse first; route change to its owner

RFC 3113 recorded 3GPP's preferred approach: use Internet standards unchanged where feasible. It also said that 3GPP had no intention of duplicating work already performed in the IETF. The preference reduced two kinds of fragmentation. It avoided competing specifications for the same protocol, and it reduced the chance that fixed and mobile implementations would attach different meanings to a familiar Internet mechanism.

But “unchanged” was not absolute. Mobile systems brought constraints and expertise that an existing Internet specification might not have addressed. RFC 3113 therefore defined the exception path. If additions or modifications were needed to satisfy 3GPP requirements, 3GPP would take the concern directly to the appropriate IETF working group, or to an Area Director when no suitable group existed.

The important action was not asking permission from a generic coordinator. It was routing the proposed change to the body that controlled the protocol's development process. 3GPP retained authority over whether its specifications depended on the result. The IETF retained authority over what became IETF work and how that work was approved. A request could be urgent and well founded without becoming self-executing.

This was a thin interface, not a thick supervisory institution. It exposed the dependency, supplied the technical case and found the correct decision surface. It did not create a third body with power to overrule both parents.

Expertise moved in the opposite direction

The relationship was not simply 3GPP consuming finished RFCs. RFC 3113 mapped 3GPP's Technical Specification Groups so IETF participants could reach expertise in radio access, physical transport, mobility management, the core network, terminals, applications, architecture, security and operations.

That reciprocal path mattered because an open protocol can still be designed around incomplete environmental knowledge. A fixed-network assumption may become expensive, ambiguous or impossible over a radio link. A mobility mechanism can interact with state, timing or security in ways that are invisible from a desktop network. 3GPP could bring those constraints into the IETF discussion without acquiring the power to declare the IETF outcome.

Expertise and authority are different evidence classes. Expertise explains what a design will encounter. Authority determines which body may approve a change within a defined process. Conflating them punishes the expert twice: first by treating technical knowledge as political mandate, and then by blaming that person when an institution makes the final decision.

RFC 3113 kept the distinction usable. Working groups and technical groups did the substantive work. Contact points helped participants find the right room. The liaison existed for administrative problems that could not easily be handled through working groups or Area Directors. It was a route around confusion, not a route around procedure.

A liaison carried a message, not a mandate

The document encouraged informal working-level communication and participation on mailing lists. Formal communication remained available when needed, facilitated by relevant IETF Area Directors and 3GPP technical leadership. It proposed an IETF liaison as an initial contact for administrative aspects of the relationship.

Then it denied that role the most dangerous shortcut. The liaison was not expected to participate in 3GPP's administrative processes and had no ability to make exceptions or special provisions for IETF policies and procedures.

Later IETF process documents made the same boundary more explicit. RFC 4052 described liaison relationships as a way to prevent accidental duplication without obstructing either organization from pursuing its own mandate. Any work resulting for the IETF still had to use ordinary IETF procedures. A liaison manager could redirect a misplaced request, maintain communication, track a dependency and carry an authorized message. The person did not manufacture consensus by carrying it.

Outgoing liaison statements also had an approval chain. A statement claiming to represent a working group required working-group discussion and chair agreement. An Area statement required the Area Director; an IETF-wide statement required the IETF Chair; an IAB statement required the IAB Chair. RFC 4053's plainer description is useful: a liaison statement is a business letter. It can request information, make a comment or ask for action. Delivery is not approval, and a deadline is not command authority.

This is where the history meets a wider doctrine of Internet governance. Participation can be evidence, warning and expertise. It does not automatically become authorization. A permanent channel can be valuable without becoming a principal. The message and the mandate must remain separately attributable.

Open documents made disagreement inspectable

RFC 3113 encouraged both organizations to share draft documents of mutual interest. Its 2001 account emphasized public web access and contact points that could explain unfamiliar document structures. That sounds mundane only after open archives became ordinary.

Document access changed the quality of the interface. A dependency could be identified by exact artifact rather than paraphrased from a meeting. A proposed change could be discussed against text. A schedule risk could be tied to the state of a draft. An observer could distinguish what one body had published from what the other hoped it would publish.

The record still needed careful interpretation. An Internet-Draft is not an RFC. A reference to a draft may identify a stable version, yet the draft can later change or expire. A 3GPP Technical Report is not the same artifact as a Technical Specification. A liaison statement can report a dependency without proving that the receiving body accepted the requested action.

RFC 4691 later described a practical mechanism: 3GPP, 3GPP2 and OMA sent updated dependency lists, and liaison managers tracked them and conveyed requests for expedited RFC-number assignment to the appropriate Area Director when necessary. The manager could expose timing pressure. The Area Director and the IETF process still determined what could happen.

The boundary survived; the details aged

The IETF still lists 3GPP as an active liaison relationship and still points to RFC 3113. A March 2026 Internet-Draft proposes to replace the old document because organization names, document-access mechanisms and coordination practices have changed. Crucially, that draft says the high-level principles remain intact: reuse Internet standards unchanged where feasible, avoid duplicating IETF work, and bring required changes to the appropriate IETF venue.

The distinction between status and evidence matters. The 2026 document is work in progress. It has not, on that evidence, obsoleted RFC 3113. It can show what its authors and current coordination group are trying to preserve; it cannot be cited as an approved successor.

Minutes from a March 2026 IETF–3GPP coordination meeting show why the interface still has work to do. Participants discussed long-running exchanges, missing feedback, dependencies on unfinished drafts, 3GPP's preference for RFCs as normative references and cases where the IETF did not plan to update a document. In one item, 3GPP would handle the issue itself; in another, an IETF group was expected to send a further liaison statement. Coordination did not collapse the outcomes into one rule.

That contemporary record does not prove every problem was solved, or that RFC 3113 caused later interoperability. It proves something narrower: dependency, timing and ownership remain real operational variables, and the old interface is still recognizable enough to be updated rather than discarded.

The durable design was divided custody

The collaboration assigned different evidence and actions to different custodians. 3GPP knew its mobile architecture, release needs and technical specifications. IETF working groups knew the protocol work and operated the IETF change process. The IAB managed the liaison relationship. Liaison managers maintained routes and dependency awareness. Editors identified concrete artifacts. Implementers chose versions and converted text into behavior. Operators and users experienced whether the pieces interoperated.

No one layer proved the whole result. A 3GPP reference showed dependence, not IETF approval of the surrounding mobile specification. An RFC showed publication, not field deployment. A liaison statement showed a request, not acceptance. Meeting minutes showed discussion, not protocol conformance. An implementation proved behavior in one system, not authority to redefine the shared standard.

This divided custody was not a weakness to be eliminated. It was the safety property. If a coordinator could waive IETF procedure to meet a release date, the channel would become an unreviewable gate. If the IETF could dictate 3GPP's entire mobile architecture because it owned one protocol, dependency would become jurisdictional expansion. If either side privately forked the other's work, the cost would appear later in incompatible systems.

RFC 3113 offered a more disciplined answer. Share drafts. Name dependencies. Put experts into the relevant technical discussion. Escalate to the responsible body. Preserve each organization's approval chain. Record the version on which a release actually depends.

The two institutions shared a system, but they did not merge authority. That was not an awkward compromise around the engineering. It was the engineering of the boundary.

They Shared a System. They Did Not Merge Authority: RFC 3113

Why it matters

Summary

One network, two rulebooks

Reuse first; route change to its owner

Expertise moved in the opposite direction

A liaison carried a message, not a mandate

Open documents made disagreement inspectable

The boundary survived; the details aged

The durable design was divided custody

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing