RE: Question on draft-ietf-radext-management-authorization-04.txt

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

> So I think we're talking about trying to dis-ambiguate a situation
> where there is a valid User-Name attribute, but perhaps multiple
> sessions associated with that.  It might be worth quoting some
> text from RFC 5176 regarding the recommended NAS and session 
> identification attributes, since it might not necessarily be 
> obvious that an Access-Request for a management session should
> necessarily have a NAS-Port/NAS-Port-Id + Acct-Session-Id 
> associated with it.

I can remove the Framed-Management-Protocol and
Management-Transport-Protection Attributes from usage as "session
identifiers" for Dynamic Authorization and quote chapter and verse from RFC
5176 as to what SHOULD be used as "session identifiers".

I think that will cover the "80% problem" without introducing too many
opportunities for odd behaviors and wild-card usages.

The only reason that I could see for a NAS to not include the appropriate
session identifier attributes in an Access-Request message would be if the
NAS implementation didn't assign identifiers until it processed the
Access-Accept message, i.e. didn't want to assign IDs to sessions that may
never materialize, or the NAS implementation didn't support RADIUS
accounting, and thus had no notion of session identifiers.

Do we need to add some wiggle room to cover those corner cases?



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