Summary

  • Datatracker identifies charter-ietf-radext-07-08 as a proposed recharter in External Review, last updated on 6 August 2026. The page says version 07 remains the approved charter.
  • The proposal contains two milestones dated May 2026, five dated August 2026 and one dated December 2026. None of its eight Associated documents cells contains a link.
  • The two most plausible May deliverables are active RADEXT working-group drafts, but both still show I-D Exists, not submission to the IESG. One draft header says Informational while the proposed milestone says Proposed Standard.
  • The five August rows appear to map to three expired individual drafts, one expired adoption candidate and one active adoption candidate. Connect-Info is the active candidate; its header also says Informational where the proposed milestone says Proposed Standard.
  • These states do not prove that seven deliverables failed. The dates may be retrospective, contingent on recharter approval, or already in need of rebasing. The public table does not say which.
  • IETF should publish a versioned milestone baseline joining the charter state, exact document identity, intended track, adoption and IESG state, measured transition, actual date and rebase reason.

One proposal, two clocks

RADEXT maintains and extends RADIUS, the protocol used to carry authentication, authorization and accounting information across network-access systems. Its current Datatracker page presents a recharter numbered 07-08. The page is explicit about the boundary: this is a proposed recharter, while the approved charter is version 07.

That distinction matters because Datatracker also shows the proposal in External Review (Message to Community, Selected by Secretariat). The charter-state glossary treats External Review, IESG Review and Approved as separate states. Clearing a ballot objection or publishing a new revision can move the proposal forward without making it the approved charter.

The history records substantial movement. Eight milestones were added on 12 May. On 22 July, the proposal moved from internal chartering review to External Review and an Approve ballot was created. Late-July and early-August ballot positions raised questions about congestion-control coordination, milestone placement and the publication status of work items. By 6 August, versions 07-05 through 07-08 had been posted and the recorded Blocks had moved to No Objection.

The latest page still says External Review at the evidence cutoff. That is not evidence that the proposal was rejected, nor does the record explain why the state has not advanced. It simply means the approval clock has not reached the state that Datatracker calls Approved.

The second clock is inside the proposal. It lists two Proposed Standard submissions to the IESG in May, five submissions in August—four Proposed Standards and one Informational—and one Proposed Standard submission in December. Every Associated documents cell is blank. A reader can see a month and a deliverable label, but not the object whose state should be checked.

The May rows are active, but not at the named transition

The first May row is PS Review of RADIUS Security and Privacy draft to IESG. The clearest title match is draft-ietf-radext-review-radius-02, updated on 10 August. It is an active RADEXT working-group document and its IESG state is I-D Exists. Its own header says the intended status is Informational.

That record supplies two important limits. The draft is not dormant: it was revised in August. It is also not shown as submitted to the IESG, which is the transition named in the milestone. And the charter’s PS label does not match the document header’s Informational track.

The second May row is PS Deprecating Insecure Practices in RADIUS draft to IESG. draft-ietf-radext-deprecating-radius-10 is an active working-group document, updated on 3 July, with a document shepherd and a Standards Track header. It too remains at I-D Exists. Its document page still displays an associated January 2024 milestone from the approved charter, while the proposed recharter gives the work a May 2026 target.

The IETF 126 minutes help explain the state without converting it into an excuse. On 22 July, the chair said the two drafts had not yet passed Working Group Last Call and should be moved there promptly. The drafts can be real, active work while the proposed “to IESG” transition remains unrecorded. A truthful baseline should show both facts.

The August rows span four different kinds of state

The proposed congestion-control milestone most plausibly points to draft-janfred-radext-radius-congestion-control-01. That record is an expired individual draft with no stream defined. Its latest revision was posted in October 2025 and it expired in April 2026. The charter history also records that congestion-control coordination was discussed during review. But because the milestone cell has no link, the document identity remains an editorial match, not an official association.

The same caution applies to proxy load balancing. draft-dekok-radext-proxy-load-00 is an expired individual draft with no stream. Its abstract says the operational methods described had, at that revision, insufficient experience for Standards Track or BCP publication. The proposed milestone nevertheless names a Proposed Standard submission in August. That may reflect an intended future rewrite, a different document, or a publication-track decision made after the expired revision. The public row does not say.

draft-grayson-5580uncertainty-00 exactly matches the location-uncertainty title. It is also an expired individual draft with no stream. The proposal labels this one Informational, which is internally plausible, but still provides no official document link or transition record.

The emergency-preparedness work is closer to the group boundary. draft-gundavelli-radepcs-02 appears under RADEXT and is marked Candidate for WG Adoption, but it expired in July. Candidate status is not adoption; expiry is not abandonment. Both distinctions matter if August is supposed to mean submission to IESG.

Connect-Info is the only one of the five likely August documents currently active. draft-grayson-connectinfo-10 is marked Candidate for WG Adoption and I-D Exists. Its header says Informational. The proposed milestone says Proposed Standard. In the IETF 126 minutes, the chair said a pre-adoption call had already found consensus and the document would be adopted once the recharter completed.

That is precisely the kind of dependency a useful milestone table should expose. The work has an active draft and an adoption signal, but its institutional transition depends on a charter that remains under review. A bare August date collapses those stages into one cell.

December is a warning signal, not a missed date

The last proposed row is a December submission for Status-Realm and loop prevention. The most plausible document, draft-ietf-radext-status-realm-01, is an expired RADEXT working-group draft whose latest revision dates from March 2025.

December has not arrived at the cutoff, so this is not a missed milestone. The expired state is a monitoring signal: a new revision, replacement document, scope change or rebase will be needed if that document family is to reach the transition named by the proposal. Treating the signal as a verdict would repeat the problem this Article is trying to solve.

Make the milestone table a state ledger

RFC 2418 explains why the dates matter. A charter lists goals and time frames; milestone dates help an Area Director track progress and help potential participants identify critical moments for input. The list is expected to be updated periodically. A timetable is useful because it directs attention.

But attention requires an object. Each RADEXT row should carry a stable milestone identifier, the charter version and state, the exact document family, whether it is individual, candidate, adopted or with the IESG, and the intended publication track in both the charter and current draft. It should name the transition the date measures: adoption, Working Group Last Call, or submission to IESG are not interchangeable.

The row should then record an actual transition date or one of a small number of states: planned, active, achieved, rebased, superseded or blocked. A rebase should preserve the old target and identify the reason, actor and dependency. If a May date was retrospective when added on 12 May, say so. If an August date was contingent on approval, say so. If the track changed from Proposed Standard to Informational, record the decision rather than forcing readers to compare headers.

Heng Lu’s ledger principle applies here only in a narrow sense. The institutional record should describe the state it coordinates. This is not an argument that IETF charters are sovereign instruments or that RADEXT’s process is illegitimate. It is a request that a public timetable not acquire meaning by ambiguity. The charter can set direction; the ledger should show what actually happened.

Sources

  1. Heng Lu, The Policy Mirror
  2. RADEXT proposed recharter
  3. RADEXT charter history
  4. Datatracker charter-state definitions
  5. RADEXT group page
  6. RADEXT group documents
  7. IETF 126 RADEXT minutes
  8. RFC 2418
  9. Review of RADIUS Security and Privacy
  10. Deprecating Insecure Practices in RADIUS
  11. RADIUS congestion-control draft
  12. RADIUS proxy-load draft
  13. Location uncertainty draft
  14. Emergency-preparedness attributes draft
  15. Connect-Info draft
  16. Status-Realm draft