Summary
- RFC 3356 let an ITU-T Study Group authorize a delegate to speak officially, but required the IETF to give that opinion the same weight as any other Working Group participant’s contribution.
- Approval, delivery, archiving and response ownership made a liaison traceable; they did not make the receiving body agree, publish, implement or surrender its own revision process.
Imagine a delegate arriving at an IETF meeting with a letter whose institutional pedigree is beyond dispute. The Study Group chair authorized the trip. The relevant officials received the list of delegates. The speaker can accurately say, “This is the position of our group.”
What happens next is the interesting part. Nothing in that authorization lets the delegate decide for the IETF Working Group. RFC 3356 made the boundary unusually explicit: opinions expressed by an official ITU-T delegate were to receive equal weight with those of any other Working Group participant.
That sentence did more than protect meeting etiquette. It separated two questions that institutional systems constantly collapse. The first is whether a statement genuinely comes from the organization named on it. The second is whether another organization accepts the statement. Authorization can answer the first. It cannot answer the second.
Published in August 2002, RFC 3356 described collaboration between the IETF and the Telecommunication Standardization Sector of the International Telecommunication Union. It updated and obsoleted RFC 2436. Most of its text was shared with ITU-T A-Series Supplement 3, approved by the Telecommunication Standardization Advisory Group in November 2001.
The setting mattered. Internet protocols increasingly touched signaling, numbering, security, routing, management and access questions familiar to the telecommunications world. The IETF and ITU-T could not usefully pretend that their work programmes never overlapped. Nor could either body safely treat overlap as permission to absorb the other’s authority.
RFC 3356 began by acknowledging that the institutions were built differently. IETF work took place in Working Groups, mostly on open public mailing lists, within Areas managed by Area Directors and the IESG. ITU-T work was organized as study Questions, Working Parties and Study Groups, with rapporteurs and chairs and a stronger role for meetings. Collaboration therefore could not mean running one common procedure under two letterheads.
The first control was discovery. An ITU-T Study Group that found an Internet-related topic was expected to examine relevant IETF work and state the goal and expected outcome of collaboration in its work plan. An IETF Working Group was likewise expected to identify related ITU-T activity in its charter.
This sounds administrative, but it narrowed the claim being made. “We know the other body is working nearby” is not the same as “we jointly own the work.” A written collaboration goal creates an inspectable scope. It can show whether the parties sought review, compatible terminology, a reference, a complementary specification or something else.
RFC 3356 also built an early-warning mechanism. The IETF sent new and revised Working Group charters and Birds of a Feather announcements to the NewWork mailing list; an ITU-T exploder subscribed to it. Study Groups were advised to monitor continuously because the IETF could turn around a new charter in two weeks. ITU-T work-programme updates were meant to travel in the other direction.
NewWork was an attention channel. A notice could reveal overlap soon enough to respond. It did not reserve a topic, grant jurisdiction or pause the other body. Monitoring changed the time available for coordination, not the allocation of decision rights.
Representation required a more formal receipt. IETF participants could attend ITU-T meetings as ISOC delegates when the appropriate Working Group or Area approved their attendance, with the IAB chair communicating registration to the ITU’s Telecommunication Standardization Bureau. In the other direction, an ITU-T Study Group chair could authorize members to speak officially about the activities of a Study Group or Rapporteur Group.
The authorization established capacity. It told listeners that the person was not merely improvising a personal opinion. But RFC 3356 refused to let source authority become recipient authority. At the IETF, the delegate entered the Working Group’s existing process. Institutional pedigree did not create an extra vote, a veto or automatic consensus.
That design fits the IETF’s use of open mailing lists as the primary vehicle for discussion and decision-making. An official intervention could be important, technically persuasive and accurately attributed. It still had to survive the same public argument as other contributions. The receiving group controlled its conclusion.
Communication outside meetings used the same split. Informal exchanges among experts and contact points were encouraged. Formal communication, however, had to be explicitly approved and identified as coming from the relevant Study Group, Working Party, Rapporteur Group, Working Group or Area.
For an ITU-T communication entering the IETF, RFC 3356 specified addressees, a copy to a dedicated IETF liaison-statements intake address, placement on a liaison-statements page and assignment to a named IETF person responsible for handling it. Those are valuable records. They answer what was received, where it was exposed and who owned the next action.
They do not answer whether the recipient agreed. A posted liaison statement can be pending, answered, rejected in substance, overtaken by later work or merely informative. A named handler is a responsibility marker, not a decision receipt. The archive proves that a message entered the process; the Working Group record must show what the process did with it.
The symmetry was deliberate. A formal IETF communication sent to ITU-T also needed explicit approval and identification. Copying the appropriate chairs and Area Directors signaled that approval. Neither side could turn one expert’s email into an institutional position simply because it crossed an organizational boundary.
The asymmetry of participation remained visible. IETF Working Group lists were open to subscribers and served as the main decision forum. Formal ITU-T lists commonly required affiliation with a member, although other unrestricted lists could exist. Collaboration therefore had to account for different access conditions rather than pretending that a mailing list meant the same thing in both systems.
Document sharing raised a second authority problem. An IETF draft could be sent to an ITU-T Study Group as an ISOC contribution only after the Working Group agreed it was of mutual interest, beneficial to forward and accurately described. Area Directors then reviewed and approved the request.
That chain did not approve the draft as a standard. It approved a particular transfer for review, comment and possible use. The status label travelled with the document precisely because transport could otherwise look like endorsement.
The reverse path was equally careful. A Study Group or Working Party could send draft Recommendation text to the IETF after deciding that transfer was useful. The contribution had to identify its development status and contacts and say that it was a working document of the named ITU-T Study Group. In the 2002 process, presenting it as an Internet-Draft also meant accepting that it was temporary and expired after six months.
Formatting did not naturalize the document. ASCII syntax and an Internet-Draft filename did not make ITU-T text an IETF consensus product. A public URL did not make a Word document eligible to become an RFC. The wrapper could improve access while the provenance remained intact.
RFC 3356’s preference on joint text followed from this logic. It expected that one body would normally document the result in full and the other would reference it. Common or joint text was discouraged because the institutions had different approval and revision procedures.
That recommendation is striking because RFC 3356 itself had substantial common text with an ITU-T supplement. The lesson was not that shared wording was impossible. It was that identical words could sit inside different custodial systems. Future changes, replacement rules, approval records and publication status still belonged to the body maintaining each artifact.
Cross-reference was therefore a governance tool. ITU-T Recommendation A.5 supplied one path for referencing external work; RFC 2026 supplied the IETF’s rules for normative references to other open standards. A reference connected specifications without silently copying their authority or change control.
Later documents made the liaison machinery more explicit. RFC 4052 described IAB management of liaison relationships. RFC 4053 detailed receipt and handling of liaison statements. RFC 4691 clarified the conduct of IETF liaison representatives: they communicated and explained; they were not independent negotiators empowered to bind the IETF. RFC 6756 updated RFC 3356 in 2012 while retaining the equal-weight rule and the preference for separate documentation and reference.
None of this proves that every real liaison was clean, timely or free of politics. The documents describe a control surface, not a universal performance result. Nor does RFC 3356 report a particular dispute in which the boundary decided the outcome. Its security section found no direct security issue.
Its historical value lies elsewhere. RFC 3356 treated institutional legitimacy as something that needed more than a logo and a job title. A reliable record had to separate the authority to appoint a speaker, the authority to approve a message, the fact of delivery, the duty to respond, the recipient’s own consensus, the status of the resulting document and any later implementation.
That chain remains useful well beyond standards organizations. A representative can be genuine without being sovereign. A message can be official without being accepted. A response can be assigned without being decided. Shared prose can be authentic in two systems without giving either system control over the other.
The delegate spoke for an institution. The Working Group still had to decide.
Sources
- RFC 3356 HTML
- RFC 3356 text
- RFC Editor record for RFC 3356
- RFC 3356 errata record
- IETF Datatracker record for RFC 3356
- IETF Datatracker history for RFC 3356
- RFC 2436: Collaboration between ISOC/IETF and ITU-T
- RFC 2418: IETF Working Group Guidelines and Procedures
- RFC 6756: Updated IETF and ITU-T Collaboration Guidelines
- RFC 2026: The Internet Standards Process
- RFC 4052: IAB Management of IETF Liaison Relationships
- RFC 4053: Handling Liaison Statements
- RFC 4691: Guidelines for an IETF Liaison
- ITU-T A-Series Supplement 3, 2001 record
- Lu Heng: Running-Code Primacy
- Lu Heng: Minimum Initial Specification
- Lu Heng: Reality Layers
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
