RE: minneapolis

[Bernard Aboba <aboba@internaut.com>]

> You can assign Session-Timeout a portion of X but then the NAS would boot
> the user off.  Terminate-Action is not usable since it is sent after the NAS
> kicks the user off.
>
> If the Value is set to RADIUS-Request, upon termination of the
> specified service the NAS MAY send a new Access-Request to the
> RADIUS server, including the State attribute if any."
>
>
> In WLAN its different.

How is it different?  The above paragraph in RFC 2865 refers to
re-authentication.

> In other words, it appears that in WLAN there is a reauthentication
> mechanism that we can use to get another quota.

This is just the mechanism described in RFC 2865.

> If what is meant by simple prepaid solution is a solution that works with
> existing deployements then this is not a simple prepaid solution that works
> without changes.

Actually, it sounds like you've just shown that a prepaid solution can be
implemented based on RFC 2865 with no changes at all -- and no revenue
leakage, without even requiring a dependency on RFC 3576.

> Hope this clears things up.

Actually, this makes things even more unclear.  Not only does the prepaid
draft invent a new RADIUS attribute format for "sub-attributes" but now it
appears that it is also reinventing functionality already supported in RFC
2865.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>