Re: [radext] New WGLC for RADIUSv11

[Matthew Newton <[e-mail]>]

On 27/02/2024 20:31, Margaret Cullen wrote:> The latest version of the 
document (draft-ietf-radext-radiusv11-04) can
> be found here:
> 
> https://datatracker.ietf.org/doc/draft-ietf-radext-radiusv11/ 
> <https://datatracker.ietf.org/doc/draft-ietf-radext-radiusv11/>
> 
> Please read the new version, and respond to this message clearly 
>   indicating that you SUPPORT publication of this draft as an 
> Experimental RFC, or that you DO NOT SUPPORT publication.  If you do not 
> support publication, please list any outstanding issues that you would 
> like to see resolved before publication.

I have read the latest version.


Two very minor nits, and one paragraph that is not clear:



Introduction, (Page 6 paragraph 1):

"A major benefit of this extensions is that a home server which 
implement it can also be more easily verified for FIPS-140 compliance."

   -> (extensions -> extension, implement -> implements)

"A major benefit of this extension is that a home server which 
implements it can also be more easily verified for FIPS-140 compliance."



Section 3.5, (Page 18 paragraph 8):

"Similarly, when a server does resumption for a session which had 
previously negotiated "radius/1.1", If the client attempts to resume the 
sessions without signaling the use of RADIUS/1.1, the server MUST close 
the connection."

    ", If" -> ", if"

("signaling" rather than "signalling" throughout the document grates 
rather, but I suspect those over the pond would disagree!)



Section 4.2.1, (Page 21 paragraph 4):

"In contrast, the Token field MUST be managed on a per-connection basis, 
and MUST NOT be managed for individual packet Codes.  That is, if a 
system sends multiple packet Codes over the same connection, the Token 
field MUST be managed independent of any packet Code.  For An 
implementation which sends both (for example) Access-Request and 
Accounting-Requests on the same connection is not compliant with this 
specification."

    "independent of any packet Code" -> "independently of any packet
Code" (or "independent to any packet Code")

    "For An implementation"... - remove "For", but...

This paragraph is not clear to me. I think it is trying to say that 
multiple Codes are permitted per connection, but the Token is unique on 
that connection connection (e.g. you can NOT have an Access-Request with 
Token A and an Accounting-Request with the same Token A). However the 
last sentence seems to say that an implementation sending both 
Access-Requests and Accounting-Requests on the same connection is not 
permitted.

If my understanding is correct, I think this paragraph should read:

"In contrast, the Token field MUST be managed on a per-connection basis, 
and MUST NOT be managed for individual packet Codes.  That is, if a 
system sends multiple packet Codes over the same connection, the Token 
field MUST be managed independently of any packet Code. An 
implementation which, for example, can have an Access-Request and an 
Accounting-Request simultaneously ongoing using the same Token on the 
same connection is not compliant with this specification."


Thanks,

-- 
Matthew