[Isms] Next steps for Extended VACM?

["Dave Nelson" <d.b.nelson at comcast.net>]

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?

(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.

(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.

There are parts of this that I don't understand.  Should the new table
contain all entries from the old table, but with the "RADIUS can't change
this" flag set?

Internally, what should VACM do in following its EOP?  Look only at the new
table, with the old table being some form of "backing store"?  Otherwise we
need some sort of precedence relation between the two tables, and I didn't
hear that being advocated.

Do we need something to enable the VACM "extended mode"?

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?