[radext] Re: Mike Bishop's No Objection on draft-ietf-radext-radiusdtls-bis-17: (with COMMENT)

[Alan DeKok <[e-mail]>]

  My $0.02

On Jul 7, 2026, at 10:29 AM, Mike Bishop via Datatracker <[e-mail]> wrote:
> ### Section 3.6, paragraph 8
> ```
>     connection.  RadSec clients SHOULD use a separate pool of connections
>     on which to send accounting packets in the event the RadSec server
>     does not support sending Protocol-Error.
> ```
> How is the client intended to detect this case? Or do you mean clients SHOULD
> always do this, in case the server might not support Protocol-Error?

  The clients generally don't detect this case.  The administrator can configure separate pools of connections.

> ### Section 3.8, paragraph 8
> ```
>     Server packets.  This value was picked arbitrarily, as there is no
>     reason to choose any other value over another for this use.
> ```
> That the value is arbitrarily selected can be omitted, I think; you could just
> drop this last sentence. If the goal is to ensure servers accept more values than
> just zero, I'd make that an explicit MUST.

  This sentence is copied over from https://datatracker.ietf.org/doc/html/rfc6613#section-2.6.5

  The intention is to explain that one value needs to be reserved, but that there is no meaning to the value.

  There is no requirement on the servers to accept any specific value.  i.e. the 8-bit ID value is chosen by the client, and RFC 2865 forbids the server from interpreting its value.

> ### Section 4.2, paragraph 3
> ```
>     RADIUS clients MUST NOT perform retries by sending a packet on a
>     different protocol or connection (i.e., switching from TLS to DTLS or
>     vice versa).  However, when a connection fails, a RADIUS client MAY
>     send packets associated with that connection over a different
>     configured connection or server.  This requirement does not,
> ```
> I feel like bringing protocol into this just confuses matters. It sounds like
> the rule is "on retry, if original connection is still alive, MUST retry on same
> connection; if original connection has failed, MAY retry on a different
> connection."

  Yes.

> Other than the (already-stated) requirement that connections to the
> same IP:port over different protocols are indeed different connections, what
> does protocol have to do with this rule?

  Yes, we can remove "protocol".

  Alan DeKok.