Re: [Isms] Next steps for Extended VACM?

[Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de>]

On Wed, Jul 29, 2009 at 03:34:00PM +0200, Dave Nelson wrote:
> I wanted to parrot back some thoughts I took away from Monday's ISMS WG
> meeting on the direction for the RADIUS-aware Extended VACM draft, to see if
> others remember the discussion the same way.  I also have some questions.
> 
> (1) We don't want to specify _how_ the NAS moves the access policy
> information from the RADIUS client to the Extended VACM "manager", just that
> it predictably and reliably do so, and that it pay heed to session timeout
> limits, session disconnects, multiple sessions using the same policy, and so
> forth.  Is that about right?

I think this is fair statement.
 
> (2) We don't want to suggest using the tmStateReference, even though this
> seems a likely container which already has similarly TM-session-scoped state
> information.

Storing something in the tmStateReference has no value since it is
never passed to the ACM and it is not needed since we do (1).

> (3) We don't want the Extended VACM "manager" to modify the existing VACM
> securityName-to-group MIB table, but rather to maintain a new Extended VACM
> securityName-to-group MIB table.  This new table will look a lot like the
> old table, but will have a couple extra columns, one for "can RADIUS change
> this" and one that's an index of the corresponding row in the existing
> table.

Not quite right. The VACM security to group mapping table remains the
only table that does security to group mappings. A device supporting
the radius extension will provide an augmenting table indicating which
entries in the VACM security to group mapping table belong to the
RADIUS client - and if needed providing any additional information we
need to make visible.

> Would it be useful to count the number to times that the VACM "manger"
> attempted to add a new row but couldn't because of a name collision?

It is common practice to have counters when the processing in elements
of procedures stops due to such error situation. So I guess the answer
is yes.

/js (writing as technical contributor)

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>