RadSec: RADIUS over Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
draft-ietf-radext-radiusdtls-bis-18

[Ballot comment]
# 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".

[Ballot comment]
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.

[Ballot comment]
## 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?

[Ballot discuss]
Thanks for providing this document. This is primarily a security document. It does explicitly refer to transport mechanisms, and the comments that I provide below relates to this part of the text, where I would like to learn more.

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### S 6.2.3 - DISCUSS
“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
  “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?

Gorry

[Ballot comment]
## 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.

[Ballot discuss]
# IESG review of draft-ietf-radext-radiusdtls-bis-15

CC @MikeBishop

## Discuss

### Section 6.5.1.1, paragraph 3

The prohibition of 5-tuple reuse makes total sense in the absence of
Connection IDs. However, DTLS Connection IDs (RFC9146 for DTLS 1.2,
natively in DTLS 1.3) would easily provide disambiguation between parallel
connections. Is there a reason to forbid 5-tuple reuse with differing
Connection IDs?

Even if so, I think there should be some discussion of CIDs here.

[Ballot comment]
## 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.

[Ballot discuss]
Thanks for providing this document. This is primarily a security document it does explicitly refer to transport mechanisms, and the comments that I provide below relates to this part of the text, and would like to learn more.

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### S 6.2.3 - DISCUSS
“In order to avoid congestive collapse, it is RECOMMENDED that...”
- I would like to discuss why this is only recommended, why its 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
  “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 varied, 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?

Gorry

[Ballot comment]
## Some non-blocking COMMENT points/nits:

### S 6.2.2 - Comment
“Due to the lossy nature of UDP,”
- I think 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 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

[Ballot comment]
Hi Jan-Frederik, Margaret, and Stefan,

Special thanks for the effort put into this important piece of work.

Thanks to Jürgen Schönwälder for the OPSDIR review and to Margaret for the follow-up.

The document is dense with a comprehensive list of implementation and operational considerations through the document. Some of these guidance would be better exposed to operators if clearly separated from the protocol machinery, but as Jürgen said let’s hope those who will deploy will tag all those.

Please find below some few comments, fwiw:

# Source port number selection

CURRENT (3.1):
  The client source port used for
  RadSec connections is not fixed -- it is typically an ephemeral port
  picked by the client Operating System. 

Can this also mention the mechanism in RFC6056?

If randomization is followed, then this would help with this:

Section 6.5.2

  RADIUS/DTLS clients SHOULD NOT send both RADIUS/UDP and RADIUS/DTLS
  packets to different servers from the same source socket. 

# keepalive

CURRENT:
  RadSec implementations MUST utilize the existence of a TCP, TLS or
  DTLS connection where applicable in addition to the application-layer
  watchdog defined in [RFC3539], Section 3.4 when determining the
  liveness of each connection.

I guess by “utilize the existence” you meant implement some heartbeat/keepalives.

For TCP, please note that rfc9293#3.8.4 says:

  Implementers MAY include "keep-alives" in their TCP implementations
  (MAY-5), although this practice is not universally accepted.

I don’t see an issue with the behavior in the spec given that 3539 requires anyway the following:

  AAA protocols MUST support
  an application layer watchdog message.

# Logging

Some events are better logged for operational needs. For example, the following events (and similar) should be logged

CURRENT:
  That is, the implementation SHOULD send a TLS close
  notification and, in the case of RADIUS/TLS, the underlying TCP
  connection MUST be closed if any of the following circumstances are
  seen:

# server IP?

OLD:
  *  server IP,

  *  server port.

NEW:
  *  server IP address,

  *  server port number.

OLD:
  Where a server accepts packets on multiple different 3-tuples
  (protocol, server IP, server port),

NEW:
  Where a server accepts packets on multiple different 3-tuples
  (protocol, server IP address, server port number),

# Same behavior

Section 3.1
  RadSec endpoints MUST NOT use the old RADIUS/UDP or RADIUS/TCP ports
  for RADIUS/DTLS or RADIUS/TLS.

Section 3.12
  Implementations MUST NOT exchange both insecure and secure traffic on
  the same UDP or TCP port.  It is RECOMMENDED that implementations
  make it impossible for such a configuration to be created.

These are covering the same points. May be consider having this discussion in one single place.

Alternatively, consider linking both such as:

NEW
  RadSec endpoints MUST NOT use the old RADIUS/UDP or RADIUS/TCP ports
  for RADIUS/DTLS or RADIUS/TLS. See also Section 3.12.

# packets, records, and datagrams

CURRENT:
  RADIUS/DTLS endpoints MUST send exactly one RADIUS packet per DTLS
  record.  This ensures that the RADIUS packets do not get fragmented
  at a point where a re-ordering of UDP packets would result in
  decoding failures.  The DTLS specification mandates that a DTLS
  record must not span multiple UDP datagrams.  We note that a single
  UDP datagram may, however, contain multiple DTLS records.  RADIUS/
  DTLS endpoints MAY use this behavior to send multiple RADIUS packets
  in one UDP packet.

Maybe add a pointer to rfc9147#section-4.3?

I would delete “we note”.

Cheers,
Med

[Ballot comment]
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

[Ballot discuss]

# Éric Vyncke INT AD comments for draft-ietf-radext-radiusdtls-bis-15
CC @evyncke

Thank you for the work put into this document.

Please find below some blocking DISCUSS points (super easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Valery Smyslov for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Section 3.2

`RadSec clients MUST establish a (D)TLS session immediately upon connecting to a new server.` why "immediately" ? Does it mean that they should first try with plain RADIUS ? The subsequent paragraphs give some hints, but a PS must be crystal clear.

### Section 3.12

What is `server IP` ? Please avoid readers guessing that it is "server IP address", especially in a PS. Also occuring in other places.

[Ballot comment]

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

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-radext-radiusdtls-bis-14. If any part of this review is inaccurate, please let us know.

The IANA understands that, upon approval of this document, there is a single action which we must complete.

In the Service Name and Transport Protocol Port Number Registry located at:

https://www.iana.org/assignments/service-names-port-numbers/

The entry for Service Name: radsec and Port Number: 2083 is to be revised as follows:

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. [ RFC-to-be ] updates RFC 6614 (RADIUS/TLS).
Reference: [ RFC-to-be ]

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. [ RFC-to-be ] updates RFC 7360 (RADIUS/DTLS).
Reference: [ RFC-to-be ]

As this document requests updates to registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated an advisory expert review via a separate request.

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2026-02-23):

From: The IESG
To: IETF-Announce
CC: draft-ietf-radext-radiusdtls-bis@ietf.org, mrcullen42@gmail.com, paul.wouters@aiven.io, radext-chairs@ietf.org, radext@ietf.org, valery@smyslov.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (RadSec: RADIUS over Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)) to Proposed Standard


The IESG has received a request from the RADIUS EXTensions WG (radext) to
consider the following document: - 'RadSec: RADIUS over Transport Layer
Security (TLS) and Datagram
  Transport Layer Security (DTLS)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-02-23. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.


AD Note: There is one issue that came up during WGLC that I would hope to hear
more opinions about related to the Event-Timestamp attribute vs Acct-Time-Delay
attribute, see https://mailarchive.ietf.org/arch/msg/radext/b-Xu-VLvHDfeZljGQNKNayPgiWk/


Abstract


  This document defines transport profiles for running RADIUS over
  Transport Layer Security (TLS) and Datagram Transport Layer Security
  (DTLS), allowing the secure and reliable transport of RADIUS
  messages.  RADIUS/TLS and RADIUS/DTLS are collectively referred to as
  RadSec.

  This document obsoletes RFC6614 and RFC7360, which specified
  experimental versions of RADIUS over TLS and DTLS.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-radext-radiusdtls-bis/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc2866: RADIUS Accounting (Informational - Internet Engineering Task Force (IETF) stream)
    rfc5176: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) (Informational - Internet Engineering Task Force (IETF) stream)
    rfc7585: Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI) (Experimental - Internet Engineering Task Force (IETF) stream)
    rfc7930: Larger Packets for RADIUS over TCP (Experimental - Internet Engineering Task Force (IETF) stream)
    rfc5997: Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol (Informational - Internet Engineering Task Force (IETF) stream)

1.  Does the working group (WG) consensus represent the strong concurrence of a
    few individuals, with others being silent, or did it reach broad agreement?

  The consensus is solid, the draft has been actively discussed in the WG and all
  active WG members participated in this discussion. The draft has been reviewed
  several times during its development by a number of WG members.

2.  Was there controversy about particular points, or were there decisions where
    the consensus was particularly rough?

  No controversy, the eventual consensus is strong. That said, there was a hot discussion
  in the middle of document development about retransmission behaviour of RADIUS proxies utilizing
  different transports and the use of Acct-Delay-Time and Event-Timestamp
  attributes for RADIUS accounting in this situation, where one WG participant
  disagreed with the majority of the WG members, insisting on a different text.

3.  Has anyone threatened an appeal or otherwise indicated extreme discontent? If
    so, please summarize the areas of conflict in separate email messages to the
    responsible Area Director. (It should be in a separate email because this
    questionnaire is publicly available.)

  One person objected to publishing the draft in its current form.
  A separate e-mail is sent to the AD.

4.  For protocol documents, are there existing implementations of the contents of
    the document? Have a significant number of potential implementers indicated
    plans to implement? Are any existing implementations reported somewhere,
    either in the document itself (as RFC 7942 recommends) or elsewhere
    (where)?

  There are several implementations following the recommendations given in the document,
  based on the information shared on the mailing list. For example, radsecproxy
  implements most of the recommendations given in the draft.

5.  Do the contents of this document closely interact with technologies in other
    IETF working groups or external organizations, and would it therefore benefit
    from their review? Have those reviews occurred? If yes, describe which
    reviews took place.

  The content of the document closely relates to UTA WG. One of the RADEXT co-chairs
  and a key RADEXT participant, who contributed a lot to this document, are also
  together UTA co-chairs. I believe that they provided the needed expertise.
  The early version of the document was also distributed in the UTA WG for review,
  but no reviews were received.

6.  Describe how the document meets any required formal expert review criteria,
    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  Not applicable.

7.  If the document contains a YANG module, has the final version of the module
    been checked with any of the recommended validation tools for syntax and
    formatting validation? If there are any resulting errors or warnings, what is
    the justification for not fixing them at this time? Does the YANG module
    comply with the Network Management Datastore Architecture (NMDA) as specified
    in RFC 8342?

  The document contains no YANG module.

8.  Describe reviews and automated checks performed to validate sections of the
    final version of the document written in a formal language, such as XML code,
    BNF rules, MIB definitions, CBOR's CDDL, etc.

  Not applicable.

9.  Based on the shepherd's review of the document, is it their opinion that this
    document is needed, clearly written, complete, correctly designed, and ready
    to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled lists of common issues that their
    reviewers encounter. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

  No issues were identified.

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard,
    Informational, Experimental or Historic)? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

  Proposed Standard, as indicated in the text of the document and in the datatracker.
  This type is appropriate because the document defines interoperable behavior
  in the situation when RADIUS servers need to contact RADIUS clients over (D)TLS.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in BCP 79? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

  All authors and contributors have confirmed that they are unaware of any IPR related to this draft:
  https://mailarchive.ietf.org/arch/msg/radext/w7tiHZ5ZUkCSCar-dSCcdDHjLXw/
  https://mailarchive.ietf.org/arch/msg/radext/Pl3FTjIjCGg2T_ZiRJwr33ckITI/
  https://mailarchive.ietf.org/arch/msg/radext/jvkxAzSpAZYrmoSbN_I_jicEia4/
  https://mailarchive.ietf.org/arch/msg/radext/KHD5QwKqjCOFQpSAAXEEPOtfePA/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

  The document has three authors. All agreed to be listed as such.

14. Document any remaining I-D nits in this document. Simply running the idnits
    tool is not enough; please review the "Content Guidelines" on
    authors.ietf.org. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

  idnits reports several issues, all of them seem false positive to me
  or can be handled by the RFC Editor. In particular:

  1. Three is one line that exceeds 72 characters in length - this is the name of one
  of the authors employer. For some reason xml2rfc doesn't split this line into two -
  it seems that the RFC Editor should handle this:
  "Deutsches Forschungsnetz | German National Research and Education Network"

  2. idnits complaints that the draft obsoletes RFC 7360, but this is not mentioned
  in the Abstract. In fact it is mentioned.

  3. idnits complaints that reference to RFCXXXX is not defined. In fact this is
  a placeholder in the IANA notes text to refer to this document.

  4. idnits found a number of downrefs. See 17) below.

  5. idnits complaints about references to obsoleted RFCs:
  Normative reference: RFC 5246 (Obsoleted by RFC 8446)
  Normative reference: RFC 6347 (Obsoleted by RFC 9147)

  These references are normative since the draft contains recommendations
  for TLS 1.2 (RFC5246) and DTLS 1.2 (RFC6347).

15. Should any informative references be normative or vice-versa? See the IESG
    Statement on Normative and Informative References.

  No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

  All normative references are freely available.

17. Are there any normative downward references (see RFC 3967 and BCP
    97) that are not already listed in the DOWNREF registry? If so,
    list them.

  Normative reference to an Informational RFC: RFC 2866
  This RFC defines RADIUS accounting. The consensus in the WG is that it should be normatively referenced.

  Normative reference to an Informational RFC: RFC 5176
  This RFC defines Dynamic Authorization Extensions for RADIUS. The consensus in the WG is that it should be normatively referenced.

  Normative reference to an Informational RFC: RFC 5997
  This RFC defines Use of Status-Server Packets in RADIUS. The consensus in the WG is that it should be normatively referenced.

  Normative reference to an Experimental RFC: RFC 7585
  This RFC defines Dynamic Peer Discovery for RADIUS/(T)LS. The consensus in the WG is that it should be normatively referenced.

  Normative reference to an Experimental RFC: RFC 7930
  This RFC defines Larger Packets for RADIUS over TCP. In addition it defines the Protocol-Error Code.
  The consensus in the WG is that it should be normatively referenced.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

  All normative references are published RFCs.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

  This document obsoletes RFC6614 and RFC7360, as inidicated in the header,
  in the Abstract, and in the body of the document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see RFC 8126).

  The document updates the Reference and the Assignment Notes for the already
  allocated "radsec" service name (port number 2083 for TCP and UDP)
  in the Service Name and Transport Protocol Port Number Registry.
  The request to IANA is clear.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

  Not applicable.

1.  Does the working group (WG) consensus represent the strong concurrence of a
    few individuals, with others being silent, or did it reach broad agreement?

  The consensus is solid, the draft has been actively discussed in the WG and all
  active WG members participated in this discussion. The draft has been reviewed
  several times during its development by a number of WG members.

2.  Was there controversy about particular points, or were there decisions where
    the consensus was particularly rough?

  No controversy, the eventual consensus is strong. That said, there was a hot discussion
  in the middle of document development about retransmission behaviour of RADIUS proxies utilizing
  different transports and the use of Acct-Delay-Time and Event-Timestamp
  attributes for RADIUS accounting in this situation, where one WG participant
  disagreed with the majority of the WG members, insisting on a different text.

3.  Has anyone threatened an appeal or otherwise indicated extreme discontent? If
    so, please summarize the areas of conflict in separate email messages to the
    responsible Area Director. (It should be in a separate email because this
    questionnaire is publicly available.)

  One person objected to publishing the draft in its current form.
  A separate e-mail is sent to the AD.

4.  For protocol documents, are there existing implementations of the contents of
    the document? Have a significant number of potential implementers indicated
    plans to implement? Are any existing implementations reported somewhere,
    either in the document itself (as RFC 7942 recommends) or elsewhere
    (where)?

  There are several implementations following the recommendations given in the document,
  based on the information shared on the mailing list. For example, radsecproxy
  implements most of the recommendations given in the draft.

5.  Do the contents of this document closely interact with technologies in other
    IETF working groups or external organizations, and would it therefore benefit
    from their review? Have those reviews occurred? If yes, describe which
    reviews took place.

  The content of the document closely relates to UTA WG. One of the RADEXT co-chairs
  and a key RADEXT participant, who contributed a lot to this document, are also
  together UTA co-chairs. I believe that they provided the needed expertise.
  The early version of the document was also distributed in the UTA WG for review,
  but no reviews were received.

6.  Describe how the document meets any required formal expert review criteria,
    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  Not applicable.

7.  If the document contains a YANG module, has the final version of the module
    been checked with any of the recommended validation tools for syntax and
    formatting validation? If there are any resulting errors or warnings, what is
    the justification for not fixing them at this time? Does the YANG module
    comply with the Network Management Datastore Architecture (NMDA) as specified
    in RFC 8342?

  The document contains no YANG module.

8.  Describe reviews and automated checks performed to validate sections of the
    final version of the document written in a formal language, such as XML code,
    BNF rules, MIB definitions, CBOR's CDDL, etc.

  Not applicable.

9.  Based on the shepherd's review of the document, is it their opinion that this
    document is needed, clearly written, complete, correctly designed, and ready
    to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled lists of common issues that their
    reviewers encounter. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

  No issues were identified.

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard,
    Informational, Experimental or Historic)? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

  Proposed Standard, as indicated in the text of the document and in the datatracker.
  This type is appropriate because the document defines interoperable behavior
  in the situation when RADIUS servers need to contact RADIUS clients over (D)TLS.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in BCP 79? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

  All authors and contributors have confirmed that they are unaware of any IPR related to this draft:
  https://mailarchive.ietf.org/arch/msg/radext/w7tiHZ5ZUkCSCar-dSCcdDHjLXw/
  https://mailarchive.ietf.org/arch/msg/radext/Pl3FTjIjCGg2T_ZiRJwr33ckITI/
  https://mailarchive.ietf.org/arch/msg/radext/jvkxAzSpAZYrmoSbN_I_jicEia4/
  https://mailarchive.ietf.org/arch/msg/radext/KHD5QwKqjCOFQpSAAXEEPOtfePA/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

  The document has three authors. All agreed to be listed as such.

14. Document any remaining I-D nits in this document. Simply running the idnits
    tool is not enough; please review the "Content Guidelines" on
    authors.ietf.org. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

  idnits reports several issues, all of them seem false positive to me
  or can be handled by the RFC Editor. In particular:

  1. Three is one line that exceeds 72 characters in length - this is the name of one
  of the authors employer. For some reason xml2rfc doesn't split this line into two -
  it seems that the RFC Editor should handle this:
  "Deutsches Forschungsnetz | German National Research and Education Network"

  2. idnits complaints that the draft obsoletes RFC 7360, but this is not mentioned
  in the Abstract. In fact it is mentioned.

  3. idnits complaints that reference to RFCXXXX is not defined. In fact this is
  a placeholder in the IANA notes text to refer to this document.

  4. idnits found a number of downrefs. See 17) below.

  5. idnits complaints about references to obsoleted RFCs:
  Normative reference: RFC 5246 (Obsoleted by RFC 8446)
  Normative reference: RFC 6347 (Obsoleted by RFC 9147)

  These references are normative since the draft contains recommendations
  for TLS 1.2 (RFC5246) and DTLS 1.2 (RFC6347).

15. Should any informative references be normative or vice-versa? See the IESG
    Statement on Normative and Informative References.

  No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

  All normative references are freely available.

17. Are there any normative downward references (see RFC 3967 and BCP
    97) that are not already listed in the DOWNREF registry? If so,
    list them.

  Normative reference to an Informational RFC: RFC 2866
  This RFC defines RADIUS accounting. The consensus in the WG is that it should be normatively referenced.

  Normative reference to an Informational RFC: RFC 5176
  This RFC defines Dynamic Authorization Extensions for RADIUS. The consensus in the WG is that it should be normatively referenced.

  Normative reference to an Informational RFC: RFC 5997
  This RFC defines Use of Status-Server Packets in RADIUS. The consensus in the WG is that it should be normatively referenced.

  Normative reference to an Experimental RFC: RFC 7585
  This RFC defines Dynamic Peer Discovery for RADIUS/(T)LS. The consensus in the WG is that it should be normatively referenced.

  Normative reference to an Experimental RFC: RFC 7930
  This RFC defines Larger Packets for RADIUS over TCP. In addition it defines the Protocol-Error Code.
  The consensus in the WG is that it should be normatively referenced.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

  All normative references are published RFCs.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

  This document obsoletes RFC6614 and RFC7360, as inidicated in the header,
  in the Abstract, and in the body of the document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see RFC 8126).

  The document updates the Reference and the Assignment Notes for the already
  allocated "radsec" service name (port number 2083 for TCP and UDP)
  in the Service Name and Transport Protocol Port Number Registry.
  The request to IANA is clear.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

  Not applicable.