Re: RFC3576bis and Session State

[Alan DeKok <aland@nitros9.org>]

Bernard Aboba wrote:
...
> To something like this:
>
> "A NAS implementing this specification SHOULD send an Acct-Session-Id or 
> Acct-Multi-Session-Id Attribute within an Access-Request.  However, 
> where the Acct-Session-Id or Acct-Multi-Session-Id is not included 
> within an Access-Request,

 the Dynamic Authorization Client will not know the Acct-Session-Id or
Acct-Multi-Session-Id of the session it is attempting to target, unless
it also has access to the accounting data for that session.

> Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not 
> present in a CoA-Request or Disconnect-Request,

 the User-Name or Chargeable-User-Identity attributes may be
sufficient to uniquely identify the session.  However, if the same user
has multiple sessions on the NAS, or if the privacy NAI is used, that 
information may be insufficient to uniquely identify a session.  Session 
identification MAY be performed by using one or more of the 
Called-Station-Id, Calling-Station-Id,  NAS-Port and
NAS-Port-Id attributes.

  ? The question now becomes how does the client determine which 
attributes to send if there's no session ID attribute?  Maybe recommend: 
CUI or else User-Name (unless it's anonymous) or Calling-Station-Id, etc.

> I can add a sentence to Section saying "A NAS implementing this 
> specification SHOULD send
> an Acct-Session-Id or Acct-Multi-Session-Id Attribute within an 
> Access-Request."

  Yes.  Also note that doing so makes the CoA network much simpler and 
more robust.  I would prefer it to be a MUST, but that's probably too 
strong.  Maybe a strong recommendation in addition to SHOULD.

  Alan DeKok.

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