Ballot for charter-ietf-radext

Block

Mahesh Jethanandani
Roman Danyliw

Yes

Christopher Inacio
Mohamed Boucadair

No Objection

Andy Newton
Charles Eckel
Deb Cooley
Éric Vyncke
Ketan Talaulikar

No Record

Gorry Fairhurst
Gunter Van de Velde
Jim Guichard
Mike Bishop
Tommy Jensen

  • Ready for external review (04-04)
  • Ready for external review (05-00)
  • Ready for external review (06-01)
  • Approve (06-03)
  • Ready for external review (07-00)

Summary: Has 2 BLOCKs. Has enough positions to pass once BLOCK positions are resolved.

Ballot question: "Is this charter ready for external review?"

Mahesh Jethanandani
Block
Block (2026-04-14 for -07-00) Sent
I support Roman's block here for the reasons he states.

The statement "support the work of those organizations":

- Inverts the normal relationship between the IETF and external bodies 
(the IETF produces standards; others may choose to adopt them)

- Could be used to justify work items that lack genuine IETF community 
consensus by claiming external demand

- Is inconsistent with RFC 2026 and BCP 9 principles of individual participation

Secondly, none of the work items specifies an intended publication type
(PS, BCP, Informational, or Experimental). Eric noted he was about to
block on this issue. You could say I am enabling that.

Finally, the four multi-hop work items, the roaming best-practices document, and the minor extensions 
work all require different tracks (likely PS for protocol extensions, BCP for best practices).
Comment (2026-04-14 for -07-00) Sent
Paragraph 1
> To ensure backward compatibility with existing RADIUS implementations, 
> as well as compatibility between RADIUS and Diameter, all documents produced must specify 
> means of interoperation with legacy RADIUS. Any non-backwards compatibility changes 
> with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673, 
> 4675, 5080, 5090, 5176, 6158, 6929, 8044 and the RadSec RFC (when published) must be justified. 

The existing RADIUS/TLS RFC (RFC 6614) and RADIUS/DTLS RFC (RFC 7360) are absent from the backward-compatibility 
list — if the bis supersedes them, the list should be updated to reflect that.
Roman Danyliw
Block
Block (2026-04-14 for -07-00) Sent
** Working on behalf of other organizations.  The charter says:

“The radext WG will publish minor RADIUS extensions,
best-practices documents and clarifications, as needed to support the work of those organizations.”

“Define and publish minor extensions to RADIUS, such as new attribute definitions, needed by external organizations or other IETF WGs.”

I’m not sure what the inclusion of these statements is intended to do regarding scope or process, but it was unexpected and seems to suggest an alternative to the current standards process of consensus and participation as individuals.

-- The introductory text says that this WG will focus on maintenance of RADIUS.  The above text caveats working on extensions on behalf of others in the first clause.  Is this suggesting that WG couldn’t self-initiate extension work?

-- How is the standards process guiding the WG changed at all by the fact that an outside group needs an extension?  

-- How are these organizations given standing to ask for extension (e.g., who gets to ask since this is a scope criteria)?  Typically, a decision to do work (e.g., an extension) and publish is done via WG (and then later IETF) consensus.  What’s the alternative being proposed here?  Even if the request came from another IETF WG, the same procedures would apply (i.e., there would need to be consensus in RADEXT to do the work).

Could the intended scope of work be written as follows:

OLD
“The radext WG will publish minor RADIUS extensions,
best-practices documents and clarifications, as needed to support the work of those organizations.”

NEW
The radext WG will publish minor RADIUS extensions,
best-practices documents and clarifications.

OLD
“Define and publish minor extensions to RADIUS, such as new attribute definitions, needed by external organizations or other IETF WGs.”

NEW
Define and publish minor extensions to RADIUS.
Comment (2026-04-14 for -07-00) Sent
* In what way is this text providing scoping: “Information from operators shows that anywhere from 20% to 90% of authentications are for accounts which are always rejected.”?  Is this a target that the future solution from need to improve upon directly written into the charter text?  What, if anything, would be lost if it was removed?

* Significant new scope has been added.  What are the associated milestones?
Christopher Inacio
Yes
Mohamed Boucadair
Yes
Comment (2026-04-09 for -07-00) Sent
Hi all, 

Thanks for the charter refresh to keep maintenance of this important technology for many operations.

Please find some few comments below:

# Not all RADIUS attributes are/will be defined in RADEXT

CURRENT:
  Define and publish minor extensions to RADIUS, such as new attribute definitions,
  needed by external organizations or other IETF WGs.

I think that we need some text that says (and which actually reflects the practice so far), that RADIUS attributes can be defined in the WGs that own the technololgy. RADEXT will be responsible for reviewing those. 

# (nit) As this is a long-life maintenance, I would make this change:

OLD:
  The immediate goals of the RADEXT working group are to:

NEW:
  The goals of the RADEXT working group are to:

For example, defining new attributes defines that there is actually a need for it. Which is not "immediate".

# (nit) The formatting of sub-bullet is broken.

# Not sure I would keep the following in the charter

CURRENT:
  Information from operators shows
  that anywhere from 20% to 90% of authentications are for accounts which are always rejected.

Cheers,
Med
Andy Newton
No Objection
Charles Eckel
No Objection
Comment (2026-04-14 for -07-00) Sent
I agree with Eric's comment on stating the intended publication status of all work items.
Deb Cooley
No Objection
Comment (2026-04-14 for -07-00) Sent
Just a couple of easy suggestions: 

Para 2:  Spell out WBA, and remove 'as needed to support the work of those organizations'.

Para 3: I think the sentence that starts, 'Any non-backwards compatibility...' could be streamlined by removing the long list of RFCs, leaving 'Any non-backwards compatibility changes with existing RADIUS RFCs, including the RadSec RFC (when published) must be justified.'

Work items:  Some of these could be turned into milestones.

I have no earthly idea what a 'roaming consortia' is, hopefully the working group knows.
Éric Vyncke
No Objection
Comment (2026-04-09 for -07-00) Sent
Thanks for doing the rechartering as RADIUS is important.

Some minor comment though:
- introduce the WG acronym at the beginning
- expand WBA (and provide a reference ?)
- the 2nd level bullet list is wrongly formatted as it appears as first level
- s/The immediate goals of the RADEXT working group/The goals of the WG/
- unsure whether `Information from operators shows that anywhere from 20% to 90% of authentications are for accounts which are always rejected.` belongs to a charter rather than in a draft introduction/justification

*I am trusting the responsible AD to formally state the intended publication status of all work items (I was about to BLOCK on this issue).*
Ketan Talaulikar
No Objection
Gorry Fairhurst
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
Mike Bishop
No Record
Tommy Jensen
No Record