Re: [Isms] Next steps for Extended VACM?

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

Juergen Schoenwaelder writes...

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

Well, since (1) -- elided in this reply -- is completely unspecified, it
*could* be implemented by passing a pointer to tmStateReference.  How we
pass information is opaque to the document, so one pointer is just as good
as another, right?  I'm going to think about whether it might be useful for
the Extended VACM "manager" to have access to the tmStateRefeence for other
reasons.  That fact that it isn't passed to VACM in an ASI doesn't, IMHO,
prevent it from being passed in an implementation-dependent fashion.  After
all, a "sneak path" is a "sneak path".  :-)

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

Ah, I see.  An augmenting table, without use of the AUGMENTS keyword, using
a common indexing scheme to tie back to the original table.  Gotcha.

I'm sure a first draft of the SMI will bring out more specific comments...