Re: [Isms] Moving into some design /architectureissuesofExtendedVACM

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

Randy Presuhn writes...

> I think the disadvantage is that of introducing yet another special case.
> There is no way to tell the difference between "useless," "eroneous,"
> and "I got there before the configuration updated was pushed to that
> particular node."  (Operationally, the user-group mapping will go out
> before there is any guarantee that all nodes for which that policy will
> be relevant have been updated to include that policy in their repertoire.)
> 
> If we distinguish this case with special handling and counters, do we want
> to propagate an error back to RADIUS-land?  (We have no mechanism for
> delivering any special indication to the SNMP conversation partner.) What
> is the recovery strategy upon receipt of this error, and is it any
> different from any other access-denied situation?

All good questions.  We do need to define behavior for all the corner cases
as part of this effort.

If there is a mismatch in policy/group names between the RADIUS server and
the network devices, users will get authenticated, an SNMP session will
start, e.g. over SSH, but the VACM will not provide any access to MIB
objects.  Is there an SNMP-level error message that will inform the user
where the problem lies?