[radext] Re: Éric Vyncke's Discuss on draft-ietf-radext-radiusdtls-bis-15: (with DISCUSS and COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Janfred,

Thanks for your message.

I am currently on PTO, so, I may not be able to review a -16 with the fixes before the telechat but it seems that we are converging to a solution.

For the first point, I now understand what you mean, but as the current text is really not clear, please rephrase it (e.g., by including "without any non-protected negotiations such as done by SMTP STARTTTLS)

Regards

-éric

On 02/03/2026, 17:44, "Jan-Frederik Rieckers" <[e-mail]> wrote:

Hi Éric,

thanks from me too for your review.

Comments inline.

Cheers,
Janfred


On 2/26/26 14:30, Éric Vyncke via Datatracker wrote:
> ### Section 3.2
>
> `RadSec clients MUST establish a (D)TLS session immediately upon connecting to
> a new server.` why "immediately" ? Does it mean that they should first try with
> plain RADIUS ? The subsequent paragraphs give some hints, but a PS must be
> crystal clear.

The idea here is that there should be nothing else than TLS/DTLS, so no
STARTTLS-like behavior, no signalling of capabilities, ...
I'm unsure how to describe this other than how we put it there.

> ### Section 3.12
>
> What is `server IP` ? Please avoid readers guessing that it is "server IP
> address", especially in a PS. Also occuring in other places.

I'm so sorry, usually I'm the one nitpicking on others when they say
"IP" but mean "IP address".
I've found some other occurrences and fixed it there too, hopefully I
caught all of them.


> ## COMMENTS (non-blocking)
>
> ### Section 3
>
> s/Client implementations *SHOULD implement both, but* MUST implement at least
> one of RADIUS/TLS or RADIUS/DTLS./Client implementations MUST implement at
> least one of RADIUS/TLS or RADIUS/DTLS./ Clearer and avoiding a SHOULD.

The suggestion removes the recommendation that clients should implement
both.
Maybe it would be clearer to read to say:

Client implementations MUST implement at least one of RADIUS/TLS or
RADIUS/DTLS, and SHOULD implement both.


> ### Section 3.1
>
> The legend of table 1 is rather useless ;-) also use it in the text.

I've fixed this and added a title to the table as well as a reference in
the text.

> ### Section 3.3.1 (and others)
>
> A lot of "SHOULD" without any guidance... Why not "MUST" ? See also
> https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

I'll look over each SHOULD and see if a reasoning can be added.

>
> What is a source IP address as opposed to "IP address" in `For clients
> configured by their source IP address` ? Please remove "source".

What we mean is "The IP address the client connects from" as opposed to
"the IP address on the current host the client connects to". It should
be clear from context what we mean if we remove "source" and only write
"configured by their IP address".


> ### Section 3.5
>
> Again a "SHOULD" without guidance to the implementers in `RadSec clients and
> servers SHOULD implement session resumption.` ....

In this case specifically, the context is given before. (reduced effort
for new connections when the connection closed when idle).

Personally, I find it hard not to over-explain (and have a too long
document) but still giving enough context for people who haven't been
deploying this protocol for years/decades.

> ### Section 6.4
>
> Unsure whether this section is required. Nice experience return by early
> implementers probably, but unsure whether it belongs to a PS.

This is not just deployment experience, but has also implications.
Especially the possibility of network delay changes the meaning of
attributes.
Acct-Delay-Time was updated on each retransmission in RADIUS/UDP, so any
network delay (due to packet loss and retransmission) was visible with
an increase of Acct-Delay-Time.
With RADIUS/TLS based on TCP, this has now been removed, and we felt it
was important to note this.

>
> ### Section 6.5.1
>
> s/IP address version (IPv4 or IPv6)/IP *protocol* version (IPv4 or IPv6)/

fixed.

> ### Section 9
>
> Please add a URI to the registry, e.g.,
> https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
>
> Also, it seems that the format of the bullet list is broken (at least on my
> browser).

Both fixed.

--
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: [e-mail]<mailto:[e-mail]> | Fon: [phone] | Fax: [phone]
Pronomen: er/sein | Pronouns: he/him
__________________________________________________________________________________

DFN - Deutsches Forschungsnetz | German National Research and Education
Network
Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
https://www.dfn.de

Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser |
Christian Zens
Geschäftsführung: Dr. Christian Grimm | Alina Hain
VR AG Charlottenburg 7729B | USt.-ID. DE 136623822