IETF Last Call Review of draft-ietf-radext-radiusdtls-bis-15
review-ietf-radext-radiusdtls-bis-15-genart-lc-knodel-2026-02-23-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-radext-radiusdtls-bis-??
Reviewer: Mallory Knodel
Review Date: 2026-02-23
IETF LC End Date: 2026-02-23
IESG Telechat date: Not scheduled for a telechat

Summary: RadSec specification for RADIUS over TLS and DTLS.

Major issues:

None. As a general review this document is ready.

Minor issues:

None. All of my comments are to help improve what is already an excellent
document and are in no way blocking, so I've placed them below.

Nits/editorial comments:

 * In the introduction you might add a final sentence that briefly states that
 the intention of RadSec is to address the shortcomings explained in the second
 paragraph so that anyone reading this specification is given some hope as they
 embark on the subsequent 45 pages.

 * The line, "Whenever "(D)TLS", "RADIUS/(D)TLS" or "RadSec" is mentioned,
 the... might be better placed at the top of the conventions and terminology
 section since it bears upon the content of that section somewhat.

 * I expected a colon to end this sentence in 3.4. "Depending on the trust
 model used, the RadSec client identity is determined as follows." and for the
 following two items to be bullet points. If this is not correct, it would be
 good to define "what follows" specifically refers to.

 * Finally I just want to appreciate the security considerations section for
 its thoroughness. The information there is exceedingly clear and presented in
 an accessible way.

 * I am not sure I have reviewed a draft with a "Design Decisions" section. If
 there is a convention for this section, then my comment can be ignored. I only
 wonder if it shouldn't be above security considerations given how crucial that
 section is to this specification and that most readers look for it at the end
 of the document. I should think IANA > security > design decisions are roughly
 in that order of importance and so their placement in the draft might reflect
 that prioritization.

Thank you for the hard work on this document!