## COMMENTS (non-blocking)

### Section 3

s/Client implementations *SHOULD implement both, but* MUST implement at least one of RADIUS/TLS or RADIUS/DTLS./Client implementations MUST implement at least one of RADIUS/TLS or RADIUS/DTLS./ Clearer and avoiding a SHOULD.

### Section 3.1

The legend of table 1 is rather useless ;-) also use it in the text.

### Section 3.3.1 (and others)

A lot of "SHOULD" without any guidance... Why not "MUST" ? See also https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

What is a source IP address as opposed to "IP address" in `For clients configured by their source IP address` ? Please remove "source".

### Section 3.5

Again a "SHOULD" without guidance to the implementers in `RadSec clients and servers SHOULD implement session resumption.` ....

### Section 6.4

Unsure whether this section is required. Nice experience return by early implementers probably, but unsure whether it belongs to a PS.

### Section 6.5.1

s/IP address version (IPv4 or IPv6)/IP *protocol* version (IPv4 or IPv6)/

### Section 9

Please add a URI to the registry, e.g., https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

Also, it seems that the format of the bullet list is broken (at least on my browser).

## 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.

## Comments

### Section 1, paragraph 1

Should probably update from 8446 to 9846/I-D.ietf-tls-rfc8446bis. That
will be published by the time this is ready.

### Section 3.4, paragraph 4
```
     With TLS-X.509-PKIX, a client is uniquely identified by the tuple of
     the serial number of the presented client certificate and the issuer.
```
Assuming this means the issuer of the certificate, consider rewording to "the
issuer and serial number of the presented client certificate."

### 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.7, 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.

### Section 3.11, paragraph 4
```
     the connection".  That is, the implementation SHOULD send a TLS close
```
Is there a reason this wouldn't be true of DTLS? If not, should this be
"(D)TLS"?

### 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?

Regardless, why is this specific to TLS?

### Section 6.1.1, paragraph 0

General comment on this and similar sections; consider using the past
tense to refer to the now-obsoleted Experimental specification. "Recommended,"
etc.

### Section 7.7, paragraph 1
```
     risky.  We therefore recommend to migrate from RADIUS/UDP to RadSec.
```
Perhaps "The use of RadSec over RADIUS/UDP is RECOMMENDED."

### Section 7.7, paragraph 1
```
     be used with RadSec and (D)TLS-PSK.  We also strongly recommend
     implementers to not reuse the configuration option for the RADIUS/UDP
     shared secret in the existing user interfaces for the (D)TLS-PSK too.
```
"The RADIUS/UDP shared secret SHOULD NOT be reused as the (D)TLS-PSK."

### 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

#### Section 3.4, paragraph 7
```
-    Additionally, a server MAY restrict individual or groups of clients
+    Additionally, a server MAY restrict individual clients or groups of clients
+                                                   ++++++++
```

#### Section 7.4, paragraph 5
```
-    implementations SHOULD expose this timeout as configurable option to
+    implementations SHOULD expose this timeout as a configurable option to
+                                                  ++
```

### Section 3, paragraph 1
```
     This section defines the behavior of RadSec endpoints for the
     handling of establishment of a (D)TLS connection and sending and
     receiving RADIUS packets.
```
Is "handling of" necessary here?

### Section 3.8.2, paragraph 2
```
     For the following description, we use "retransmission" to mean the
```
"The following description uses..."

### Section 3.9, paragraph 1
```
     While RADIUS/UDP could be implemented mostly stateless (except for
```
Consider "implemented mostly statelessly" or "a RADIUS/UDP implementation could
be mostly stateless".

### Section 5.1, paragraph 2
```
     record must not span multiple UDP datagrams.  We note that a single
```
"Note that..." or simply "A single..."

### Section 6.1, paragraph 15
```
     We note that for RADIUS/DTLS the DTLS encapsulation of RADIUS means
```
"Note that..." or simply "DTLS encapsulation..."

### Section 6.5, paragraph 2
```
     We note that [RFC5080], Section 2.2.2, already mandates a duplicate
```
"Note that..." or simply "Section 2.2.2 of [RFC5080] mandates..."

### Section 7.3, paragraph 2
```
     traffic, we suggest using different approaches, like exporting the
     key material from TLS libraries according to
     [I-D.ietf-tls-keylogfile].
```
"we suggest using different approaches" => "alternate approaches... SHOULD be
used."

### Section 7.4, paragraph 5
```
     open (D)TLS connections.  We recommend a limit of a few seconds,
```
"N to M seconds is a commonly chosen value;"

### Section 7.6, paragraph 3
```
     On the other hand, we want to avoid situations in which a third party
```
"...a third party should not be able to..."

### Section 7.8, paragraph 2
```
     We therefore recommend in these situations the client use a local
     proxy that arbitrates all RADIUS traffic between the client and all
```
"In these situations, use of a local proxy that... is RECOMMENDED."

### Section 8.1, paragraph 1
```
     client.  As of the time writing, RADIUS/TLS is widely adapted for
```
Should this be "adopted"?

### Section 9, paragraph 3
```
     For TCP: * Service Name: radsec * Port Number: 2083 * Transport
     Protocol: tcp * Description: Secure RADIUS Service * Assignment
     notes: The TCP port 2083 was already previously assigned by IANA for
     "RadSec", an early implementation of RADIUS/TLS, prior to issuance of
     the experimental RFC 6614.  [RFCXXXX] updates RFC 6614 (RADIUS/TLS).
     * Reference: [RFCXXXX] (this document)
  
     For UDP: * Service Name: radsec * Port Number: 2083 * Transport
     Protocol: udp * Description: Secure RADIUS Service * Assignment
     notes: The UDP port 2083 was already previously assigned by IANA for
     "RadSec", an early implementation of RADIUS/DTLS, prior to issuance
     of the experimental RFC 7360.  [RFCXXXX] updates RFC 7360 (RADIUS/
     DTLS). * Reference: [RFCXXXX] (this document)
```
Please fix the bulleted lists.

### Grammar/style

#### Section 3.1, paragraph 2
```
r considerations regarding the multi-purpose use of one port for authenticat
                               ^^^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 3.3.1, paragraph 3
```
RadSec endpoints SHOULD NOT be pre-configured with a set of trusted CAs by th
                               ^^^^^^^^^^^^^^
```
Do not mix variants of the same word ("pre-configure" and "preconfigure")
within a single text.

#### Section 3.5, paragraph 4
```
 time out before reusing the request id, leading to resource exhaustion of t
                                     ^^
```
This abbreviation for "identification" is spelled all-uppercase.

#### Section 3.5, paragraph 4
```
to resource exhaustion of the limited id space. A server MAY therefore respon
                                      ^^
```
This abbreviation for "identification" is spelled all-uppercase.

#### Section 3.6, paragraph 5
```
y also be seen on home servers that uses different credential backends for e
                                    ^^^^
```
Possible subject-verb agreement error detected.

#### Section 3.8.2, paragraph 6
```
ne but may be in the range of 10 to 15min, depending on the available resourc
                                    ^^^^^
```
It appears that a space is missing between the number and word (or unit).

#### 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".

#### Section 5.2, paragraph 2
```
n of RADIUS/TLS in [RFC6614] recommends to send a reply to unwanted RADIUS p
                             ^^^^^^^^^^^^^^^^^^
```
The verb "recommends" is used with the gerund form ("sending").

#### Section 6.1, paragraph 1
```
kets with an unknown packet type. Therefore these [RFC6614] recommended reply
                                  ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### Section 6.1, paragraph 15
```
buffer them, and hope that they can be be sent outbound before the client giv
                                    ^^^^^
```
Possible typo: you repeated a word.

#### Section 6.2.3, paragraph 3
```
ring of packets. If a packet sent by a endpoint is lost, that loss has no ef
                                     ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 7.4, paragraph 2
```
OMMENT: risky. We therefore recommend to migrate from RADIUS/UDP to RadSec. P
                            ^^^^^^^^^^^^^^^^^^^^
```
The verb "recommend" is used with the gerund form.