Skip to main content

Telechat Review of draft-ietf-radext-radiusdtls-bis-15
review-ietf-radext-radiusdtls-bis-15-secdir-telechat-housley-2026-02-26-00

Request Review of draft-ietf-radext-radiusdtls-bis
Requested revision No specific revision (document currently at 15)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2026-03-03
Requested 2026-02-24
Authors Jan-Frederik Rieckers , Margaret Cullen , Stefan Winter
I-D last updated 2026-03-18 (Latest revision 2026-02-23)
Completed reviews Secdir Early review of -02 by Russ Housley (diff)
Dnsdir IETF Last Call review of -14 by R. (Miek) Gieben (diff)
Genart IETF Last Call review of -15 by Mallory Knodel
Secdir IETF Last Call review of -14 by Russ Housley (diff)
Opsdir IETF Last Call review of -15 by Jürgen Schönwälder
Secdir Telechat review of -15 by Russ Housley
Assignment Reviewer Russ Housley
State Completed
Request Telechat review on draft-ietf-radext-radiusdtls-bis by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/Vj-kfbMteHlm3MuwFk5z3pUWGm8
Reviewed revision 15
Result Has issues
Completed 2026-02-26
review-ietf-radext-radiusdtls-bis-15-secdir-telechat-housley-2026-02-26-00
I reviewed this document as part of the Security Directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Security Area
Directors.  Document authors, document editors, and WG chairs should
treat these comments just like any other IETF Last Call comments.

Document: draft-ietf-radext-radiusdtls-bis-15
Reviewer: Russ Housley
Review Date: 2026-02-25
IETF LC End Date: 2026-02-23
IESG Telechat date: 2026-03-05

Summary: Has Issues


Major Concerns: None


Minor Concerns:

Section 3.2: The "must" in the second sentence seems to be a consequence
of the "MUST" in the first sentence.  I suggest rewording to avoid
implementers wondering whether this ought to be upper case.  Perhaps
the second sentece could start with: "as a result, all data ...".

Section 3.3.1: The term "configured trust base" is not defined. I
suggest that this term be avoided altogether. I understand changes to
the set of configured trust anchors, but fresh CRLs are issued all the
time.  These two should probably not be talked about in the same bullet
since a fresh CRL does not impact every certification path that might be
active at a RADIUIS server.

Section 3.4: The second paragraphe ends with "determined as follows."  I
was expecting this to end with a colon, and then there to be a list of
bullets or some numbered items.


Nits: None