Summary

  • The Internet Architecture Board establishes and oversees formal IETF liaison relationships and appoints their IETF-side managers. Appointment assigns a communication and coordination responsibility; it does not transfer the authority of a Working Group, Area, the IETF as a whole or the IAB.
  • RFC 4691 limits a liaison manager to conveying the relevant IETF consensus and bars independent initiation of statements on the IETF's behalf. The manager may supply expertise and shepherd delivery, but is not the person who determines consensus merely by holding the role.
  • An incoming statement marked For action asks the addressee to do something, usually by a deadline. RFC 4053 allows an authoritative reply to complete, defer, qualify, decline, answer or otherwise dispose of the request. The obligation to respond is therefore not an obligation to agree.
  • Datatracker liaison 2141 and its linked reply 2152 show why status and substance must remain joined. Action Taken proves that the tracked request moved to a disposition; the response text reveals the actual technical position. A mandate-and-disposition receipt would make that chain legible without publishing private deliberations.

Two cards, not one verdict

On 18 March 2026, ITU-T Study Group 13 sent the IETF TLS group a liaison statement about a proposed framework for combining quantum key distribution with TLS 1.3. The public record identifies the sender and addressee, lists contacts and an action holder, marks the purpose For action, and gives a deadline of 29 May. It now displays Action Taken and links to a reply.

That compact surface is operationally useful. Someone scanning outstanding correspondence can see that the request did not remain unattended. But it is too compact to carry the conclusion. For action belongs to the sender: it tells the addressee what kind of response the sender seeks. Action Taken belongs to the tracking workflow: it tells the reader that the item reached a later state. Neither label says, by itself, that the IETF accepted every premise in the attached work, agreed to change TLS or committed anyone to deploy QKD.

The TLS reply, submitted on 23 April, supplies the missing substance. It says that using QKD with TLS should be arranged so that failure of the QKD component does not reduce TLS security. It then names concrete key-exchange conditions and relevant post-quantum mechanisms. A reader need not decide the merits of QKD to understand the governance fact: the reply is a technical disposition, not an echo of the incoming status.

The pair also prevents a subtler mistake. The contacts and liaison machinery carried the exchange, but the cards do not make a liaison manager the author of TLS consensus. The addressee, the people responsible for the reply and the technical forum remain visible. Communication has an operator; institutional authority has a source.

“Manager” is a custody role

The IETF's current liaison page says that the IAB appoints liaison managers for relationships with other standards-development and Internet-governance organizations. A formal relationship can help the organizations avoid accidental duplication while preserving their separate mandates, and it can provide authoritative information about dependencies between their work. The IAB's own coordination page says the IAB establishes and oversees those relationships and appoints the IETF-side point of contact. Most exchanges move through the manager and the Datatracker tool; the IAB normally remains in oversight.

Those are important powers of attention. The manager watches work in another institution, routes information to the correct place inside the IETF, explains IETF positions, keeps deadlines visible, helps prepare correspondence and maintains a contact network. A failed liaison can produce duplicated specifications, conflicting assumptions or a late discovery that another organization depends on an IETF document. Competent relationship management is not ceremonial.

It is still not standards command. RFC 4052 keeps substantive work in each organization's usual procedures. It expects the manager to report material developments and to carry messages when specifically instructed. The title does not place the manager above a Working Group chair, Area Director or entity. Nor does access to another organization's meetings create a private route around an open IETF discussion.

RFC 4691 makes the boundary unusually direct. The mandate is limited to conveying relevant IETF consensus. A manager must not originate a statement on behalf of the IETF, an Area or a Working Group on personal initiative. The role is representative, not an independent voice. The manager must understand the relevant consensus and may contribute expertise to the process that develops it, but is not responsible for determining consensus.

This is not a demotion. It is what makes the role credible. A courier who can change the message is no longer a reliable courier. A representative who can manufacture the represented body's position is no longer accountable to that body. The tighter the mandate, the more confidently a peer organization can treat a properly authorized statement as institutional rather than personal.

The authority travels from a named body

Outgoing IETF correspondence does not have one undifferentiated approval path. RFC 4052 ties the message to the body whose view it claims to express.

A Working Group statement begins with appropriate discussion in that Working Group. Its chair or chairs establish the relevant consensus, create or agree to the statement and notify the responsible Area Directors. An Area statement requires the Area Director or Directors to generate or approve it. An IETF-wide statement requires the IETF Chair's prior agreement. An IAB statement requires the IAB Chair's agreement. The liaison manager may help draft, clarify, transmit and follow through, but those functions do not replace the approver.

The differences matter because “IETF position” can otherwise expand silently. A factual notice that an IETF Last Call has started may rely on a public process fact and require little new deliberation. A request that another standards body stop work or change direction is much more consequential and, as RFC 4053 explains, calls for the clearest available consensus in the relevant IETF body. A statement from one Working Group is not automatically a position of every Area. An IAB view is not automatically an IETF standards action. Delivery under an IETF letterhead does not erase scope.

The right public question is therefore not only “Who sent this?” It is a sequence:

  1. Which institutional body is the sender?
  2. Who initiated the message for that body?
  3. Is the basis a public fact, collected comments, Working Group consensus, Area consensus, an IETF-wide position or an IAB view?
  4. Who had to approve the transmission?
  5. What did the liaison manager do—drafting assistance, routing, transmission, deadline shepherding or all of these?

The same individual can sometimes occupy more than one role. That does not make the roles interchangeable. A sound record states each capacity rather than asking a job title to carry the entire authority chain.

A request for action is not a command

RFC 4053 calls a liaison statement a business letter between organizations. That comparison is deliberately modest. The form identifies a sender and addressee, response and technical contacts, a purpose, a body and possible attachments. Its standard purposes distinguish information, comment, action and response.

For action means the sender asks the addressee to do something, normally within a stated period. It does not convert the sender into the addressee's principal. The IETF owes a properly routed request serious consideration and, where the liaison relationship applies, a courteous and authoritative response by the deadline. The available response can say that an action is complete, will be completed later, will not be done for a stated reason, or that another answer or route is appropriate.

This is how institutional respect and technical independence coexist. Ignoring a peer body's deadline can damage coordination and deprive it of a chance to adjust its work. Answering on time does not require the IETF to suspend its own process. RFC 4691 expressly separates the commitment to respond from uncritical acceptance of incoming requirements: proposals affecting IETF technology are assessed on technical merit.

The distinction is especially important when the incoming letter addresses a Working Group. The outside organization may possess deep domain knowledge and may disclose a dependency that the WG needs to understand. Its statement becomes evidence and a request for attention. It does not arrive with a higher rank than an Internet-Draft, an implementation report or a technically reasoned objection from another entity.

If the discussion produces clear consensus, the chairs can summarize that consensus in the reply. If it does not, RFC 4053 permits a response that transmits collected comments, including contradictory comments, without labelling them consensus. Silence or disagreement does not excuse the response; neither may it be laundered into agreement.

The risk is status compression

Public workflow systems need short states. A list cannot reproduce every mailing-list thread, draft and approval path. Action Needed and Action Taken help action holders and readers identify correspondence that remains open. The governance risk begins when that operational shorthand leaves the tool and enters a board paper, procurement memo, regulatory filing or product roadmap as a substantive verdict.

Three compressions are common.

First, appointment becomes authority: a person named “liaison manager” is described as leading joint standardization or controlling the IETF side. The actual role may be influential, technically demanding and central to communication, but its influence is not delegated power to manufacture a position.

Second, purpose becomes obligation: a peer's For action label is reported as an IETF commitment. The label records the requester's intention, not the recipient's decision.

Third, closure becomes acceptance: Action Taken is copied without the linked reply. That loses precisely the distinctions RFC 4053 preserves—done, delayed, declined, answered, redirected, qualified or otherwise disposed of.

No bad faith is required. Dashboards reward compactness; announcements reward a positive verb; organizations prefer to show collaboration rather than unresolved boundaries. Over time, however, repeated shorthand can create a false institutional memory. Later authors cite the summary rather than the response, and a narrow exchange starts to look like a shared standardization commitment.

A mandate-and-disposition receipt

The IETF already publishes much of the necessary evidence. Daniel Kade's proposal is to join it into a thin receipt for consequential statements, not to replace the Datatracker or publish private deliberation.

The first block would describe the envelope: stable statement identifier, relationship scope, sending body, addressee, declared purpose, submission date, deadline and linked attachments. These fields largely exist.

The second would expose mandate provenance. It would name the initiating body and the accountable approval role; identify the basis as a factual notification, collected comments, WG consensus, Area consensus, IETF-wide consensus or IAB position; and link to the public record that supports that characterization where one exists. It would identify the liaison manager's contribution with bounded verbs such as routed, assisted drafting, transmitted or shepherded response. It would never substitute “manager approved” for the authority that RFC 4052 assigns elsewhere.

The third would record disposition: assignee, response date, reply identifier, a compact code such as information supplied, accepted, accepted with conditions, scheduled, declined with reason, redirected, no consensus—comments returned or alternative proposed, plus a short reason and any link to the later formal IETF process. Action Taken could remain the workload state; the disposition field would stop readers from asking it to carry more meaning than it can.

Finally, the receipt would preserve corrections. If an approver, scope description or response link changes, the earlier state should remain timestamped. A revised statement should not silently overwrite the authority that readers relied on.

This record need not publish private draft authors, personal views, confidential contacts or every entity in a discussion. Public accountability here concerns institutional capacity: which body spoke, through which process, with whose accountable approval, and how the recipient disposed of the request.

The channel is strongest when it cannot become a shortcut

Liaison work is useful because standards bodies are interdependent and separately governed. TLS, radio systems, transport networks, security architectures and identifier systems do not fit neatly within one institution. A responsible person who understands both sides can discover incompatible assumptions early and bring the right experts together.

That usefulness disappears if coordination is mistaken for joint command. The peer organization remains free to pursue its mandate. The IETF remains free to judge protocol requirements through its own technical process. A manager can speed information without accelerating a decision beyond the body entitled to make it.

The 2026 QKD/TLS pair is a good outcome record precisely because it remains a pair. The incoming card identifies a request and deadline. The outgoing card states a technical answer. The link joins them without collapsing them. The missing improvement is a compact statement of the mandate behind the answer and the disposition represented by the workflow state.

A liaison manager should have a microphone clear enough that another organization can hear the IETF accurately. The microphone is not the lever that creates the position. That lever remains with the documented process, chair or other accountable body that can answer for the message.

Sources

  1. IETF liaison relationships
  2. IAB liaison coordination
  3. RFC 4052: IAB Processes for Management of IETF Liaison Relationships
  4. RFC 4053: Procedures for Handling Liaison Statements to and from the IETF
  5. RFC 4691: Guidelines for Acting as an IETF Liaison to Another Organization
  6. IETF Datatracker liaison-statement register
  7. ITU-T SG13 statement on QKD and TLS integration, liaison 2141
  8. TLS group reply, liaison 2152
  9. RFC 7282: On Consensus and Humming in the IETF