[radext] draft-ietf-radext-radiusdtls-bis-02.txt

["[e-mail]" <[e-mail]>]

After reading the most recent draft, I have the following comments/edits:

(Section 4.2.1) “... the configured IP address is matched against the presented addresses in the subjectAltName:iPAddr extension; if no such exist, …” 
I think “if no such addresses exist” or “if no such extension is present” would flow better.

(Section 4.5.1) “In both situation, the proxy is left with a difficult choice about what to do with the incoming packets.”
“situation” should be “situations” plural.

(Section 4.5.1) “… which originate Accounting-Request packets (i.e. not proxies) do not include Acct-elay-Time in those packets.”
“Acct-elay-Time” I believe should be “Acct-Delay-Time”.

(Section 7.4) “Any non-RADIUS traffic on that session means the other party is misbehaving and is a potentially security risk.”
“is a potentially” should be changed to “is a potential security risk” or “is potentially a security risk”.

(Section 7.4) "Similarly, any RADIUS traffic failing authentication vector or Message-Authenticator validation means that two parties do not have a common shared secret. Since the shared secret is static, this again means the other party is misbehaving.”
The other party may also just be misconfigured.

(Section 8.2) "As with the supported transports, the assumption is that RADIUS servers are generally believed to be less constrained that RADIUS clients.”
This sentence should read “… less constrained than RADIUS clients”.

(Section 8.2) "Since some client implementations already support using certificates for mutual authentication and there are several use cases, where Pre-shared keys are not usable …”
This sentence should be “… where pre-shared keys …” (lowercase “p”).

(Appendix A.1) "Lifetime: PKIX certificates have an expiry date, and need administrator attention and expertise for their renewal”
But isn’t that exactly what the ACME protocol (RFC 8555) solved? Though I admit, perhaps this is not the place to discuss this.

Ethan Thompson