Last Call Review of draft-ietf-radext-radiusv11-08
review-ietf-radext-radiusv11-08-genart-lc-holmberg-2024-06-27-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-radiusv11-08
Reviewer: Christer Holmberg
Review Date: 2024-06-27
IETF LC End Date: 2024-06-26
IESG Telechat date: Not scheduled for a telechat

Summary: Technically I have no comments on the specification, and I think the
text is fairly easy to read understand. However, it is unclear to me how this
impacts future work on RADIUS etc, as indicated by the issues/questions below.

Major issues:

Q_MAJ_01:

Section 7.3 says that future standards can "inherit" the RADIUS/1.1 procedures,
but they do not need to mention RADIUS/1.1 explicitly.

What exactly is meant by "inherit"? If RADIUS/1.1 is not mentioned, does that
mean that the future standards need to copy/paste the RADIUS/1.1 procedures?

----

Q_MAJ_02:

Section 7.3 specifies rules for defining RADIUS extensions.

Is this specification (especially since it is Experimental) the right place to
define such generic RADIUS extension procedures? Can the WG e.g. reject future
extension proposals purely because they do not comply to this specification?

----

Q_MAJ_03:

Section 9 says: "All the insecure uses of RADIUS have been removed".

I don't think that is true, as no changes are done to RADIUS/UDP and
RADIUS/TCP, i.e. they are still as unsecure as before.

Minor issues:

Q_MIN_01:

It is stated that RADIUS/1.1 is not a new protocol, but rather a transport
profile. In my opinion it is more than a transport profile, but I will respect
the decision of the community.

Nits/editorial comments:

Q_ED_1:

I think the Abstract is too long. Any explanations, clarifications and details
should be removed.