Summary

  • The IESG approved charter-ietf-radext-08 on 21 September 2026 after removing language that could have made needs expressed by outside organisations—or even another IETF working group—look like automatically privileged work.
  • The final charter still makes room for roaming deployments, historical interoperability and multi-hop RADIUS. It does not approve any particular external request, draft, milestone, protocol change or deployment.
  • A scope-to-consensus receipt would show how an operational request moves from its origin and evidence, through a charter hook and RADEXT rough consensus, into the correct standards, informational or BCP track.

Approval with a deleted premise

An April text of the proposed charter named the Wireless Broadband Alliance and eduroam among the communities with which RADEXT coordinated. It also said the group would publish extensions or guidance as needed to support such organisations, and would define extensions needed by outside organisations or other IETF working groups.

Those clauses did not survive intact. During IESG review, Mahesh Jethanandani argued that “supporting” outside organisations inverted the relationship: a request might appear able to acquire IETF force without first winning IETF consensus. Roman Danyliw asked whether the wording gave outside bodies special standing, and noted that even a request from another IETF working group still required RADEXT to agree. His proposed remedy was direct—remove the two clauses.

The approved version does that. It no longer names WBA or eduroam and no longer makes an external organisation’s need a category of work in itself. This is not a finding that their deployment problems are unimportant. It is a decision about where authority resides.

The distinction is easy to miss because the approval is real. The IESG did approve a new RADEXT charter, and the Datatracker marks version 08 as Approved. But a working-group charter defines scope, goals and the classes of output the group may pursue. It does not pre-approve the contents of a future contribution. There is no basis in the approval record for saying that a WBA request, an eduroam requirement, a new attribute, a named draft or a deployment plan has been endorsed.

Three tracks replace an open-ended customer relationship

The final charter gives prospective work a more useful classification. Minor extensions to RADIUS normally belong on the Proposed Standard track. Guidance about roaming deployments and interoperability with historical implementations may become Informational or Best Current Practice. Protocol clarifications belong in Informational documents.

These tracks do two jobs. They tell authors what sort of claim a document may eventually carry, and they prevent operational urgency from silently choosing a status. A roaming problem may be urgent and well evidenced, yet the proper result could be implementation guidance rather than a normative protocol extension. A small extension may fit the standards track, but its external sponsor does not settle the technical design.

The charter also preserves hard constraints. RADEXT is to consider interoperability with legacy implementations. A proposal that is not backwards compatible must justify that break. Work on multi-hop RADIUS remains in scope, including clarifying architecture and requirements, but the goal is not itself a chosen solution.

That combination is the actual bargain: broader permission to address lived deployment problems, paired with a more legible route for turning them into IETF work.

Input is not a delegated vote

The IETF’s liaison procedures already describe a relationship more disciplined than customer and supplier. RFC 4053 says liaison statements deserve appropriate consideration; the IETF may do the requested work, decline it or explain another course. The sender still has to make a technical case much as an Internet-Draft author would. RFC 4691 is equally clear from the other direction: a liaison conveys IETF consensus after it exists. It is not delegated power to create an IETF position.

This does not diminish multistakeholder participation. Operators, roaming consortia, universities and vendors often possess the failure data that a protocol group needs. They can reveal scale, deployment constraints and forms of incompatibility that are invisible in an abstract design discussion. Their standing comes from participation, reproducible evidence and the quality of the technical argument—not from turning an organisational name into a priority token.

RFC 2418 supplies the missing institutional step. A charter frames the problem, goals and milestones, while the working group conducts its work through rough consensus. RFC 7282 explains why that is not a vote count: the relevant question is whether technical objections have been understood and addressed. Neither a large outside constituency nor a familiar institution can substitute for that record.

The scope-to-consensus receipt

RADEXT can make this boundary operational by attaching a compact receipt to work motivated by an external request.

The first section should identify the request: its origin, whether the speaker acts personally or for an organisation, the precise operational failure, the affected implementations and reproducible evidence. The second should identify the charter hook: the paragraph of version 08, the intended Proposed Standard, Informational or BCP track, and the consequences for legacy interoperability and backwards compatibility.

The third should show the IETF work: the draft and editors, responsible milestone, substantial objections, their disposition and the working group’s consensus record. The last should keep deployment claims separate: a vendor commitment, shipped code, an observed deployment and tested interoperability are four different facts.

Unknown fields should stay unknown. “Requested by an important organisation” cannot fill a missing packet trace. “Within the charter” cannot fill a missing consensus record. “Published by the IETF” cannot prove that a particular implementation has deployed it.

What the approval did—and did not—decide

The approval resolved a governance question before it became a technical shortcut. RADEXT may continue to hear external operational communities and may write documents that help roaming and legacy deployments. The group is not required to behave as their standards contractor, and external provenance does not move a request ahead of an internally raised one.

That is narrower than a rejection of outside influence and stronger than a drafting cleanup. It leaves the door open, but makes every request cross the same threshold: scope, evidence, technical judgment and rough consensus.

Sources