Reverse Change-of-Authorization (CoA) in RADIUS/(D)TLS
draft-ietf-radext-reverse-coa-08

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

Thanks to the authors (especially Alan) for taking care of my previous discussion points.

[Ballot comment]
Thank you for your updates in -07. This addresses my DISCUSS and many of my COMMENTs as well. I particularly like the expanded Introduction, which explains how we got here.

In the Introduction while describing the history of this mechanism, RFC6614 does not update any previous RFC, so please be careful using that term. RFC5176 notes the lack of transport security as an issue in RFC2865 and recommends the use of IPsec. RFC6614 defines an experimental encrypted transport for RADIUS, which addresses this lack.

Thank you for expanding the term NAS in the abstract. I would still consider definitions of the terms "NAS" and "home server" in the terminology section, presumably by pointing to one of the documents you already normatively reference. (I note the general reference to RFC 5176, which includes NAS, but a reader searching the document for that term wouldn't find the reference.)

I note that the blanket replacement of RADIUS/TLS => RADIUS/(D)TLS has made this statement read somewhat oddly: "While this document specifically mentions RADIUS/(D)TLS, it should be possible to use the same mechanisms on RADIUS/DTLS [RFC7360]. However at the time of writing this specification, no implementations exist for "reverse CoA" over RADIUS/DTLS."

Perhaps: "While this document addresses RADIUS over both TLS [RFC6614] and DTLS [RFC7360], at the time of writing this specification, no implementations exist for "reverse CoA" over RADIUS/DTLS." Or just remove it, since implementation status info doesn't generally survive to the final RFC.

=== NITS FOLLOW ===

- Section 6.1: destinaion => destination

[Ballot comment]
Thanks to Donald Eastlake for their secdir review.  I hope the authors consider his suggestions.

I support Ketan's discuss.

I found this short draft difficult to understand.  I hope that those that use this specification are more 'in the know' than I.

[Ballot discuss]
I second Ketan's DISCUSS regarding RFC5176 as a normative reference. It appears that RFC5176 was an Informational document describing proprietary behaviors in the original UDP-based RADIUS, so this would be a downref, but RFC5176 does appear necessary background for implementing this protocol.

But beyond that, it seems unclear that an extension to an Informational document (so classed "because of problems that cannot be fixed without creating incompatibilities") should be Standards Track anyway. Is this the appropriate status for this document?

[Ballot comment]
In the Introduction while describing the history of this mechanism, RFC6614 does not update any previous RFC, so please be careful using that term. RFC5176 notes the lack of transport security as an issue in RFC2865 and recommends the use of IPsec. RFC6614 defines an experimental encrypted transport for RADIUS, which addresses this lack.

(As an aside, RFC6614 says "It has yet to be decided whether this approach is to be chosen for Standards Track." Thirteen years later, have we decided yet?)

I agree with Éric that the abstract could be clearer. Perhaps something like:

"RFC5176 defines Change of Authorization (CoA) packets, which are sent over UDP to a Network Access Server (NAS), typically by a RADIUS server. In many deployments, NAS cannot receive unsolicited traffic due to firewalls. This document extends RFC5176 to enable CoA packets to be sent over a persistent RADIUS/TLS connection maintained between the NAS and the RADIUS server."

I didn't find an expansion/definition of the terms "NAS" or "home server" anywhere in the document, including the terminology section. Please add references appropriately.

=== NITS FOLLOW ===

Section 1:

- "a users" => "a user's"

- Consider making "Section 2.5" a link to the relevant section

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-radext-reverse-coa-06
CC @evyncke

Thank you for the work put into this document. It seems useful but the language used is often vague or ambiguous or using overloaded terms (e.g., "home")

Please find below one blocking DISCUSS points (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

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

Possibly due to my lack of understanding correctly this section (see my COMMENT points below), but I have the following discuss point that need some explanations.

Is `This mechanism is not needed for RADIUS/UDP` true ? I would assume that NAT/firewall will time-out the UDP states after 30 seconds or so, i.e., no way to send a COA message from RADIUS server on the Internet side to a home RADIUS client as a NAS. The does DTLS suffer from the same NAT/firewall issues as plain UDP (NAT time-out ?).

[Ballot comment]

## COMMENTS (non-blocking)

### Abstract

To be honest, I failed to understand the abstract, i.e., the introduction is much better. Unsure how to fix it though. Notably `"reverse" down` has no meaning to me.

Perhaps s/home server/home RADIUS server/ ? does this mean that the RADIUS server is located in the home/residential server (as written above, I failed to understand the abstract) or is the NAS in the home/residential network ? Or does "home" mean something different than "residential". If so, then please provide a definition of home.

s/NAS which is behind/NAS *that* is behind/

### Section 1

What is a `CoA client` ? Suggest using 'COA initiator' as the NAS is actually the consumer of the COA data.

s/reachable by a NAS/reachable by a RADIUS client, e.g., a NAS/ ?

A figure would also help a lot as well as a clear definition of `home server`, at first reading is smells like a "server located in the home/residential network" but I am *guessing* that this is rather a RADIUS server on the public Internet.

s/that the NAS is not publicly accessible/that a residential NAS is not accessible from the Internet/ ?

Should there be informative references to `Eduroam or OpenRoaming` ?

Unsure how to understand `the same private network (private IP space or IPsec)` especially the link between "private IP space" and "IPsec". Also, there is no such thing as "private IP space" or was the intent to write "networks using non-global IP addresses (RFC 1918 or RFC 4193).

Who is the "we" in `we note`? The authors ? The RADEXT WG ? The IETF as a whole (after the IETF Last Call) ? Please do not use "we" in an IETF document.

I also wonder about the paragraph about DTLS vs. TLS... Why not always using "RADIUS/(D)TLS" even in the absence of implementations.

### Section 2

Should there be a normative reference to `Disconnect-Request` and other packets ? A short sentence before the list of terms would be enough.

### Section 4

What is a `the next hop server` ?

As the COA support of the other remote party is locally configured in the absence of dynamic negotiation, what is the operational impact when the configuration is incorrect ? Should there be more text than simply `In both of those situations, reverse CoA packets will not flow, but there will be no other issues with this misconfiguration.` ?

### Section 5

Should this section title include "RADIUS proxies" ?

Should this I-D formally update RFC 8559 based on `This specification extends the [RFC8559], Section 2.1 ` ?

### Section 6

Should all URL rather be https ? Anyway, this section will be removed ;-)

## NITS (non-blocking / cosmetic)

### Section 1

s/a user*s* authorization/a user authorization/

Is there a reason to have a ":" at the end of the 2nd paragraph ?

From now on, I will stop trying to fix typos, but please use a spell/grammar checker.

[Ballot discuss]
Thanks to the authors and the WG for this important document.

I have a couple of points that I would like to discuss/cross-check related to normative references being marked as informative:

a) Isn't RFC5176 a required pre-requisite to support this extension?

b) Since this extension is focused on RADIUS/TLS (and also applies to RADIUS/DTLS), doesn't that make RFCs 6614 and 7360 required based specs?

If yes, please move them from informative to normative.

[Ballot comment]
Hi Alan and Vadim,

Thank you for the effort put into this specification. I’m balloting "Yes" as this is a specification I would sponsor myself.

Also, thanks to Niclas Comstedt for the OPSDIR review.

# Overall

The procedure is well-described, including required configuration actions to signal and make use of the new capability. Reverse CoA inherits operational considerations of existing mechanisms it leverages, however there are some missing operational considerations such as: do we need to put some rate-limits in place, what are required logging to help troubleshooting, are there implications on required keepalive messages, implications of address renumbering, whether an intermediate proxy can make use of the feature if that proxy has not both sides of the connection does not support the capability, etc.

BTW, having a figure early in the document with involved entities and typical flow would be helpful.

# "Operator identifier" mentioned in Section 5

CURRENT:
  It also associates both a reverse CoA
  capability, and one or more operator identifiers with each
  connection.

I don’t see that "operator identifier" is defined in RFC 5580 or RFC 8559, which only has the following:

  This attribute carries the operator namespace identifier and the
  operator name.  The operator name is combined with the namespace
  identifier to uniquely identify the owner of an access network.

Please clarify and fix accordingly.

# Causality effect

CURRENT:
  A server MUST support associating one operator identifier with
  multiple connections.  A server MUST support associating multiple
  operator identifiers with one connection.  That is, the "operator
  identifier to connection" mapping is not one-to-one, or 1:N, or M:1,
  it is N:M or many-to-many.

I don’t understand the causality effect here: The first two ones are bout "support" while he last sentence is more about "actual use" restriction.

# Unexpected reverse CoA + Logging

CURRENT:
  When the server receives a reverse CoA packet, but cannot forward it,
  the server MUST return a NAK packet that contains an Error-Cause
  Attribute having value 502 ("Request Not Routable").

I guess before a server got to that step, the server should check if a reverse CoA is expected for that connection. I guess the behavior is to silently discard such messages with an event logged locally.

Idem, to ease troubleshooting, forwarding failure should be logged (of course, subject to a rate limit).

# Please find below some additional minor comments:

## Abstract: nits

OLD:
  This document defines a "reverse Change of Authorization (CoA)" path
  for RADIUS packets.  This specification allows a home server to send
  CoA packets in "reverse" down a RADIUS/TLS connection.  Without this
  capability, it is impossible for a home server to send CoA packets to
  a NAS which is behind a firewall or NAT gateway

NEW:
  This document defines a "reverse Change-of-Authorization (CoA)" path
  for RADIUS packets.  This specification allows a home server to send
  CoA packets in "reverse" down a RADIUS/TLS connection.  Without this
  capability, it is impossible for a home server to send CoA packets to
  a Network Access Server (NAS) which is behind a firewall or NAT

The changes are mainly:
* Use consistent Change-of-Authorization term as RFC5176. Please apply that change through the document.
* Expand NAS
* Delete “gateway” as a NAT can be a standalone device, a function embedded in a router, be a virtual instance, etc.

## Introduction

### Missing term

OLD:
  This term refers to either of the
  RADIUS packet types CoA-Request or Disconnect-Request.  The initial
  transport protocol for all RADIUS was the User Datagram Protocol
                          ^^^^^^^^^^^^
  (UDP).

NEW:
  This term refers to either of the
  RADIUS packet types CoA-Request or Disconnect-Request.  The initial
  transport protocol for all RADIUS messages was the User Datagram Protocol
  (UDP).

### Ambiguous reference

CURRENT:
  Due to the use of one single TCP port for all packet types, it is
  required that a RADIUS/TLS server signal which types of packets are
  supported on a server to a connecting peer.  See also Section 3.4 for
  a discussion of signaling.

Please s/Section 3.4/Section 3.4 of [RFC6614]

As I’m there, s/TCP port/TCP port number

### There are many clients

OLD:
  However, it is not always possible for
  the RADIUS server to send CoA packets to the RADIUS client.
                                            ^^^^ 

NEW:
  However, it is not always possible for
  the RADIUS server to send CoA packets to a RADIUS client.

### Generalize to be applicable to any stateful on-path function

OLD:
  If a
  RADIUS server wishes to act as a CoA client, and send CoA packets to
  the NAS (CoA server), the "reverse" path can be blocked by a
  firewall, NAT gateway, etc.

NEW:
  If a
  RADIUS server wishes to act as a CoA client, and send CoA packets to
  the NAS (CoA server), the "reverse" path can be blocked by an on-path
  stateful function (e.g., firewall or NAT).

### Missing references

CURRENT:
  This scenario is most evident in a roaming / federated environment
  such as Eduroam or OpenRoaming.
          ^^^^^^^^^^^^^^^^^^^^^^

Please consider adding refs for these two.

### Publicly addressible

CURRENT:
  There is no
  direct reverse path from the home server to the NAS, as the NAS is
  not publicly addressible.

I guess we meant here “not reachable with a public address”? I would reword.

### No any random proxy + fix nit

OLD:
  Even if there was a public reverse path,
  it would generally be unknowable, as intermediate proxies can (and^
                                        ^^^^^^^^^^^^^^^^^^^^
  do) attribute rewriting to hide NAS identies.
                                      ^^^^^^^^

NEW:
  Even if there was a public reverse path,
  it would generally be unknowable, as intermediate RADIUS proxies can (and
  do) attribute rewriting to hide NAS identities.


### an online user?! I would simplify

OLD:
  These limitations can result in business losses and security
  problems, such as the inability to disconnect an online user when
  their account has been terminated.

NEW:
  These limitations can result in business losses and security
  problems, such as the inability to disconnect a user when
  their account has been terminated.


### Generalize + other minor fixes

OLD:
  As the reverse path is usally blocked, it means that it is in general
                          ^^^^^^
  possible only to send CoA packets to a NAS when the NAS and RADIUS
  server share the same private network (private IP space or IPsec).
                ^^^^^^^^^^^^^^^^^^^^^^^^          ^^^^

NEW:
  As the reverse path is usually blocked, it means that it is in general
  possible only to send CoA packets to a NAS when the NAS and RADIUS
  server are in the same administrative domain (private IP address space or IPsec).

BTW, I don’t understand the mention of IPsec here.

## Section 2

### Maybe point to rfc5176#section-1.3 as well.

### Consider adding entries for "home network" and "visited network"

### The document insists that the mechanism applies for both TLS/DTLS. For example, the doc says:

  We note that while this document specifically mentions RADIUS/TLS, it
  should be possible to use the same mechanisms on RADIUS/DTLS
  [RFC7360]. 

  Or

  Therefore for practial
  purposes, "reverse CoA" means RADIUS/TLS and RADIUS/DTLS.

(s/practial/practical)

I think this can be better reflected in the document but adopting a more explicit terminology

OLD:
  *  TLS

      Either RADIUS/TLS or RADIUS/DTLS.

NEW:
  *  (D)TLS

      Either RADIUS/TLS or RADIUS/DTLS.

## Section 5

### Cascaded Proxies

OLD:
  This process occurs for all RADIUS proxies, except for the final one
  which sends the CoA packet to the client. 

NEW:
  This process occurs for all on-path RADIUS proxies, except for the final one
                          ^^^^^^^^^^^^^^
  which sends the CoA packet to the client.

Cheers,
Med

[Ballot comment]
# Internet AD comments for draft-ietf-radext-reverse-coa-06
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S5.1

* "The server simply chooses one connection..."

  Should the server perhaps choose from among the set of connections that
  support reverse CoA?

## Nits

### S5.1

* "choice more than one" -> "choice of more than one"

[Ballot comment]
It is useful to define abreviations on first use, e.g.
Please expand NAS, I’m assuming this is a Network Access Server?
Please expand RADIUS as Remote Authentication Dial In User Service, with a REF to 2865.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-radext-reverse-coa-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

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 2025-06-10):

From: The IESG
To: IETF-Announce
CC: draft-ietf-radext-reverse-coa@ietf.org, paul.wouters@aiven.io, radext-chairs@ietf.org, radext@ietf.org, valery@smyslov.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Reverse Change of Authorization (CoA) in RADIUS/TLS) to Proposed Standard


The IESG has received a request from the RADIUS EXTensions WG (radext) to
consider the following document: - 'Reverse Change of Authorization (CoA) in
RADIUS/TLS'
  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 2025-06-10. 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.

Abstract


  This document defines a "reverse Change of Authorization (CoA)" path
  for RADIUS packets.  This specification allows a home server to send
  CoA packets in "reverse" down a RADIUS/TLS connection.  Without this
  capability, it is impossible for a home server to send CoA packets to
  a NAS which is behind a firewall or NAT gateway.  The reverse CoA
  functionality extends the available transport methods for CoA
  packets, but it does not change anything else about how CoA packets
  are handled.




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



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

Just needs minor changes to the Implementation Status section to tell the RFC Editor to remove it.
(ok and also a typo fix IPSec -> ipsec)

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, however the draft has received very little discussion in the WG.
While it has been reviewed by few active participants, it happened only during WGLC.
I wish more reviews took place, but it didn't happen.

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

No controversy, the consensus is strong.

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

No.

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 of the described technology (some using vendor-specific attributes):
  - FreeRADIUS
  - Cisco
  - Aruba

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.

No.

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 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 have confirmed that they are unaware of any IPR related to this draft:
https://mailarchive.ietf.org/arch/msg/radext/VAuRcVvxdljE0aRLTm_qvD660kY/
https://mailarchive.ietf.org/arch/msg/radext/vTRMMfUsvxm8LHRAVKBxAfh8kgw/

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 two authors. Both 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 no errors or warnings.

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.

No.

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.

No.

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 contains no IANA considerations.

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, however the draft has received very little discussion in the WG.
While it has been reviewed by few active participants, it happened only during WGLC.
I wish more reviews took place, but it didn't happen.

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

No controversy, the consensus is strong.

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

No.

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 of the described technology (some using vendor-specific attributes):
  - FreeRADIUS
  - Cisco
  - Aruba

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.

No.

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 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 have confirmed that they are unaware of any IPR related to this draft:
https://mailarchive.ietf.org/arch/msg/radext/VAuRcVvxdljE0aRLTm_qvD660kY/
https://mailarchive.ietf.org/arch/msg/radext/vTRMMfUsvxm8LHRAVKBxAfh8kgw/

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 two authors. Both 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 no errors or warnings.

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.

No.

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.

No.

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 contains no IANA considerations.

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.