[radext] Re: Final update to RADIUS/(D)TLS-bis

[Alan DeKok <[e-mail]>]

On Aug 1, 2026, at 4:43 AM, Jan-Frederik Rieckers <[e-mail]> wrote:
> I've put them in this PR:
> https://github.com/radext-wg/draft-ietf-radext-radiusdtls-bis/pull/172
> 
> The changes are:
> 
> * Explicitly state that a connection attempt must be rejected if the peer certificate is not accepted. (for the client side we reference RFC9525, Section 6.6)
> * Servers should send a TLS alert of access denied in this case.
> * A connection is treated as "failed" if it has not received valid packets within the reconnect window (e.g., closed immediately after the TLS handshake)
> * Remove paragraph about retries on different protocol/connection. (This most likely is an artifact from the old "Server Identity" discussion, I've clarified things more in the retransmit/retry section)

 That looks good, thanks.

> The following non-editorial changes have been made:
> 
> * Clients MAY open multiple connections, servers MUST be able to accept multiple connections per client
> * Forbid usage of 0-RTT
> * Implementations MUST reassess validity if the trusted CAs/revocation information changes (previously SHOULD)
> * Added ALPN of "radius/1.0" as SHOULD (with a whole paragraph)
> * Add (short) discussion of Connection IDs for DTLS
> * Remove text around Path-MTU Discovery
> * Add ALPN "radius/1.0" to IANA section
> * Add Appendix explaining the congestive collapse for Acct-Delay-Time vs. Event-Timestamp

  That looks good too, thanks.

  Alan DeKok.