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

[Mike Bishop via Datatracker <[e-mail]>]

Mike Bishop has entered the following ballot position for
draft-ietf-radext-radiusdtls-bis-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-radext-radiusdtls-bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# IESG review of draft-ietf-radext-radiusdtls-bis-17

Thank you for your updates to address my previous DISCUSS! I've trimmed the
ballot to things I still see in -17, but nothing is blocking.

CC @MikeBishop

## Comments

### 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?

### 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.

### 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." 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?

### Section 8, paragraph 2

This really feels like an Appendix. It's not normative, is it?

### Section 8.2, paragraph 1
```
     dealing with certificates can create a lot of issues, both for
     implementers and administrators, for the re-specification we wanted
     to create an alternative to insecure RADIUS transports like RADIUS/
     UDP that can be deployed easily without much additional
     administrative overhead.
```
"...can be complex, this specification offers an alternative..."

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `traditional`; alternatives might be `classic`, `classical`, `common`,
   `conventional`, `customary`, `fixed`, `habitual`, `historic`,
   `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
   `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool) so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

### Grammar/style

#### Section 4.1, paragraph 3
```
ing The DTLS encryption adds an additional overhead to each packet sent. RAD
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
This phrase might be redundant. Consider either removing or replacing the
adjective "additional" or removing the article "an".