RE: Issue 226: RFC 3576bis and Renumbering

["David B. Nelson" <dnelson@elbrysnetworks.com>]

Bernard Aboba writes...

> [BA]  RFC 3576 Section 3 says:
>   The ability to use NAS or session identification
>   attributes to map to unique/multiple sessions is beyond the scope
>   of this document.  
>
> Therefore it isn't clear that sending a Disconnect-Request with a 
> User-Name/CUI attribute will necessarily terminate *all* the user's
> sessions if there are more than one.

Right. The sentence you quote is troubling, IMHO.  We've been having a
discussion on the list that leads me to believe that implementers expect
some predictable, deterministic behavior from NASes in this area, i.e. when
the set of session identifier attributes can match more than one session.  I
believe some description of such behavior does need to be in RFC3576bis, and
that the "beyond the scope" statement no longer serves us well.
 
> Do we need to say something like "all sessions matching the NAS & 
> session identification attributes are affected by CoA/Disconnect-
> Requests?"

Something like that.

In another message, you touch on the need for atomicity of action, and the
requirement to report an error of any one of the matching sessions can?t be
affected.  This probably doesn?t happen often, but what is the Dynamic
RADIUS Client supposed to do in this case?   It can't know which matching
session is causing the failure at the NAS.  Does it try successively more
specific sets of session identification attributes until the request is
honored?


--
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/>