RADIUS/1.1, Leveraging ALPN to remove MD5
draft-ietf-radext-radiusv11-11

# Internet AD comments for draft-ietf-radext-radiusv11-10
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S3.1

* "supports.." -> "supports."

### S3.3

* "capable performing" -> "capable of performing"

* "version string with MUST" -> "version string which MUST"

### S4.2.1

* "such changing" -> "such as changing"

Thanks to Claudio Allocchio for the ART ART Review.

Thank you to Christer Holmberg for the GENART review.

# Éric Vyncke, INT AD, comments for draft-ietf-radext-radiusv11-10

Thank you for the work put into this document. I really like the document and wish it will become standard ASAP but there are several (minor) issues, see below.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Jan-Frederik Rieckers for the shepherd's detailed write-up including the WG consensus and the justification of the intended status, which was very useful for the experimental status.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Abstract

Should version 1.1 be mentioned in the abstract and title ?

## Section 1

AFAIK, MD5 cannot be used to "sign" but only "authenticate", should `sign packets` be rewritten ?

s/those transport protocols still rel*ied* on MD5/those transport protocols still rel*y* on MD5/ ?

I feel uncomfortable about the mention of "FIPS-140", which is a US (AFAIK) specification albeit used worldwide, in an IETF document. At the bare minimum, add an informational reference to it and make it clear that FIPS-140 is "e.g.", i.e., just an example.

As in the other document, the use of the personal pronoun "we" is not really suitable in an IETF document... does it represent the author ? the WG ? the IETF community ? Rather use the passive voice (and I know that Alan does not like it ;-) ).

"RADIUS/1.1" is mentioned without being formally defined as "this specification" ? But can an experimental draft define a standard protocol version ?

Where is "home server" defined ?

`can remove all uses of MD4` but the title and abstract are about MD5 only...

## Section 3.1

`Implementations MUST NOT have an administrative flag which causes a connection to use "radius/1.1", but which does not signal that protocol via ALPN.` seems redundant with the previous sentence.

## Section 3.3

In my own understanding, flag means boolean variable and not a multiple 'enum' such as the four choices in this section. I.e., please s/flag/variable or enum/

I am also unsure whether local configuration is part of an IETF document (this comment can be ignored). Moreover, this section mixed normative BCP14 language about the features and one implementation syntax, this is rather confusing.

## Section 4.1

While the ALPN should differentiate between the packet format, I find it 'dangerous' to re-use the same packet format with different semantic, e.g., could the Code field be used to indicate RADIUS/1.1 ? E.g., by using the MSB of the field ? I sincerely wonder why the header was not fully redefined.

## Section 12

The first paragraph is not about acknowledgements, but it feels more like 'blaming', please remove it or move it to section 1.

# NITS (non-blocking / cosmetic)

## Section 3.1

s/protocols it supports../protocols it supports./

## Section 3.3

s/configuratiun/configuration/