Thanks to Russ Housley for their secdir reviews.

General:  TLS 1.2, is there a reason to allow this?  While RFC9325 mandates TLS1.2, draft-ietf-uta-require-tls13 (in AUTH48-done state, also will be under BCP 195) updates this to deprecate TLS 1.2.   Perhaps one could ref BCP195 and remove the references to TLS 1.2 (or at least reference both 9325 and the uta draft)?

Section 7.3:  This appears to be an ideal place for a MUST NOT vs 'forbids'.  Both are normative, but one is more visible in the text.

Nits: 
Section 7.1, para 1:  s/downbidding/downgrade

Thanks for the work  done in this document and for addressing my previous [blocking DISCUSS ballot](https://mailarchive.ietf.org/arch/msg/radext/Dxm1VG3KWgYzDTpfEmWBhU2i2ns/).

Alas, a lot of the SHOULD are still without the guidance required by [IESG statement](https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/) and are important for interoperation. This includes the whole new text of section 3.6.

## Some non-blocking COMMENT points/nits: 

### S 6.2.2 - Comment
“Due to the lossy nature of UDP,”
- I think this statement is wrong. UDP is not “lossy”! It seems more accurate to say that “UDP datagrams can be lost/reordered”. 

### S 6.2.2 - Comment
“but MUST NOT forward those
retransmissions across the reliable transport.”
- To be clear, it would be helpful to say which retransmissions were being discussed:
/retransmissions/retransmissions over unreliable transports/

### S 6.2.3 - Comment
  “In order to avoid congestive collapse, it is RECOMMENDED that RadSec
   clients which originate Accounting-Request packets (i.e., not
   proxies) do not include Acct-Delay-Time ([RFC2866], Section 5.2) in
   those packets.”
- I expect this point is important, but I do not think the text is currently correct: this does not *avoid* congestion collapse, maybe the intention is to say this reduces the probability of collapse?

### S 6.2.3 - Comment
  “this duplication contributes to congestive collapse of the
   network, if one or more RADIUS proxies performs retransmission to the
   next hop for each of those packets independently.”
- I expect the described effect is important, but I also do not think the text is correct: i.e.: I cannot see that *automatically* results in congestion, nor in congestion collapse! I would suggest that this “contributes to traffic and can induce congestion, which could contribute to congestion collapse”, or something similar?

### S 6.4 (TCP Applications Are Not UDP Applications) - Comment
  “Implementers should be aware that programming a robust TCP-based
   application can be very different from programming a robust UDP-based
   application.”
- Please can this text refer to the requirement in RFC8085 that provides guidelines for using UDP?

### S 6.4 - Comment
“ RADIUS/DTLS clients MAY use PMTU discovery [RFC6520] to determine the
   PMTU between the client and server.”
- Given this also refers to UDP, please also consider including please a reference to RFC 8899, aka DPLPMTUD for UDP, as specified in QUIC, etc.

### S 6.4 - Comment
  “While a RADIUS client has
   limited to no possibilities to reduce the size of an outgoing RADIUS
   packet without unwanted side effects, it gives the RADIUS client the
   possibility to determine whether or not the RADIUS packet can even be
   sent over the connection.” 
- This may be related to my “DISCUSS” (sorry), but I do not yet see what that would be an issue when the proxy connects onward over TCP, QUIC, or a similar transport.

### S 6.4 - Comment
  “Sending RADIUS packets that exceed the
   PMTU between the client and the server will result in IP
   fragmentation.  IP fragmentation may not be functioning, “
- This seems an odd statement without reference. Can this please refer to an RFC, such as RFC 8900?
- Also there is no mention of the TCP Sender MSS, which also limits the maximum packet size sent by a TCP sender, this seems like it would be a useful thing to note.


Gorry Fairhurst
Sorry - I fixed typos 5 Mar 2026.

My former discuss topics are included here for completeness:

### S 6.2.3 - DISCUSS - now addressed.
“In order to avoid congestive collapse, it is RECOMMENDED that...”
- I would like to discuss why this is only recommended, why is this not required if it contributes to congestion? At least, I expected some careful explanation of why this “SHOULD” might be deviated from in specific usage.

### S 6.4 - DISCUSS - now reworded and no longer the case.
  “Note that PMTU
   discovery can only discover the PMTU of the current RADIUS hop and a
   RADIUS client has no reliable way to discover the PMTU across the
   whole RADIUS proxy chain.  Further discussion of this topic is
   outside of the scope of this document.”
- I am trying to figure out what the above text really means, and why this is an issue: I wonder if this is more of a concern when there is a proxy from a TCP to UDP, or one from UDP to TCP. When a large packet is sent from UDP to TCP? - presumably a proxy from a TCP stream will simply segment to the Min(PMTU,SMSS) and hence the larger TLS record can be carried, whereas from TCP to UDP the proxy might be limited by the UDP datagram size. Of course, a proxy between two UDP “connections” would need some way of determining a useful PMTU across both paths. ... I think I do not understand what actually the issue?

# IESG review of draft-ietf-radext-radiusdtls-bis-17

Thank you for your updates to address my previous DISCUSS! I've trimmed the
ballot to things I still see in -17, but nothing is blocking.

CC @MikeBishop

## Comments

### Section 3.6, paragraph 8
```
     connection.  RadSec clients SHOULD use a separate pool of connections
     on which to send accounting packets in the event the RadSec server
     does not support sending Protocol-Error.
```
How is the client intended to detect this case? Or do you mean clients SHOULD
always do this, in case the server might not support Protocol-Error?

### Section 3.8, paragraph 8
```
     Server packets.  This value was picked arbitrarily, as there is no
     reason to choose any other value over another for this use.
```
That the value is arbitrarily selected can be omitted, I think; you could just
drop this last sentence. If the goal is to ensure servers accept more values than
just zero, I'd make that an explicit MUST.

### Section 4.2, paragraph 3
```
     RADIUS clients MUST NOT perform retries by sending a packet on a
     different protocol or connection (i.e., switching from TLS to DTLS or
     vice versa).  However, when a connection fails, a RADIUS client MAY
     send packets associated with that connection over a different
     configured connection or server.  This requirement does not,
```
I feel like bringing protocol into this just confuses matters. It sounds like
the rule is "on retry, if original connection is still alive, MUST retry on same
connection; if original connection has failed, MAY retry on a different
connection." Other than the (already-stated) requirement that connections to the
same IP:port over different protocols are indeed different connections, what
does protocol have to do with this rule?

### Section 8, paragraph 2

This really feels like an Appendix. It's not normative, is it?

### Section 8.2, paragraph 1
```
     dealing with certificates can create a lot of issues, both for
     implementers and administrators, for the re-specification we wanted
     to create an alternative to insecure RADIUS transports like RADIUS/
     UDP that can be deployed easily without much additional
     administrative overhead.
```
"...can be complex, this specification offers an alternative..."

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `traditional`; alternatives might be `classic`, `classical`, `common`,
   `conventional`, `customary`, `fixed`, `habitual`, `historic`,
   `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
   `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

### Grammar/style

#### Section 4.1, paragraph 3
```
ing The DTLS encryption adds an additional overhead to each packet sent. RAD
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
This phrase might be redundant. Consider either removing or replacing the
adjective "additional" or removing the article "an".

Thank you to Mallory Knodel for the GENART review.