Re: [radext] New Version Notification for draft-dekok-radext-reverse-coa-01.txt

[Alan DeKok <[e-mail]>]

On Aug 8, 2023, at 7:21 PM, Alexander Clouter <[e-mail]> wrote:
> Section 4:
> 
> Any reason why the server could not just send a CoA and record if it was accepted? This could be extended to pre-emptively send CoA's for sessions that cannot exist to capture if there is a response.

  That's one way, I guess.  It seems fragile to me, though.  It would be better to have some kind of positive signalling that this path supports the reverse CoA functionality.

  Barring general agreement on what that looks like, the only approach is to say "It can be used when administratively configured".

> An observed ACK/NAK would be indicative that reverse CoA is supported whilst no response (the client would drop the packet, right?) is "no support".
> 
> This sort of is what happens for traditional forward proxying of CoA as you do not know if the visited site supports CoA.

  That also tends to be administratively configured. :(

> I would not be too surprised if a number of embedded clients just processed the CoA on whatever socket it appeared on.

  I would hope so!  That would make things much easier.

> Of course NASs are strange things and I yield to your experience, but I figure if it is going to barf on a reverse CoA there is a chance it would barf on the Status-Server too...right?

  Yes.

> Section 5:
> 
> I think this "It is not one-to-one, or 1-N, or M-1." is easier to read as " It is not one-to-one, or 1:N, or M:1. It is many-to-many." (ratio style).
> 
> I personally read '1-N' and 'M-1' as a calculation.

  OK.  I'll fix that.

  Alan DeKok.