Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this Internet-Draft. 

The Operational Directorate reviews all operational and management-related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in IETF Specifications"_ can be found at https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.

While these comments are primarily for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received.

- Document: [draft-ietf-radext-radiusdtls-bis-15]

- Reviewer: [Juergen Schoenwaelder]

- Review Date: [2026-02-23]

- Intended Status: [Standards Track] 
 
---

## Summary 

Choose one: 

- Ready: No issues found. This document is ready for publication. 

## General Operational Comments

The document is detailed and presented in a concise style, much to my
liking. There are many technical details concerning corner cases, this
is nice to see. Some further observations / comments:

- I wonder why the shared secrets defined in Table 1 diverge, the
  table says radius/dtls for RADIUS/DTLS but radsec for RADIUS/TLS,
  why is this not radius/tls? I read at the beginning that the term
  radsec is an acronym for both RADIUS/DTLS and RADIUS/TLS, this does
  not appear to be applied consistently here.

- I appreciate that CA trust anchors are required to be configured
  using an explicit action.

- I wonder whether there will be YANG data models for the
  configuration of RadSec implementations and more specifically
  whether the generic TLS client server models will work.

- The security considerations have important information, I hope they
  will be read by operators deploying this technology.

- Editorial:

  - s/can be be sent/can be sent/

  - The rendering of the IANA section (in the reviewed .txt rendering)
    looks a bit odd, not sure whether this was intended.

---