Re: [Isms] Moving into some design /architectureissuesofExtendedVACM

["Randy Presuhn" <randy_presuhn at mindspring.com>]

Hi -

> From: "Juergen Schoenwaelder" <j.schoenwaelder at jacobs-university.de>
> To: "Dave Nelson" <d.b.nelson at comcast.net>
> Cc: <isms at ietf.org>
> Sent: Thursday, June 11, 2009 7:05 AM
> Subject: Re: [Isms] Moving into some design /architectureissuesofExtendedVACM
....
> But more important: SNMP has defined ways to handle this situation,
> which can occur due to manual mis-configuration of VACM tables. It
> should not make any difference whether the "broken" group name was
> manually configured or installed by a RADIUS client.

Adopting this philosophy helps answer the questions that follow...
 
> But there are some interesting questions to work out: What is the
> behaviour if a RADIUS client receives a policy attributes but the
> vacmSecurityToGroupTable has already a (different) entry for the
> (securityModel, securityName) tuple? Who wins in this situation - or
> does this even cause the authentication of the incoming request to
> fail? 

If the row for  (securityModel, securityName) already exists,
then if the value of vacmSecurityToGroupStorageType is "readOnly",
then the "policy attribute" would have to be ignored.  For any other
value of vacmSecurityToGroupStorageType, the "policy attribute"
would result in an update of vacmGroupName, and (potentially)
vacmSecurityToGroupStatus set to "active".

> What happens if no new entries can be created anymore due to
> resource limitations?

Then no entry is created.  This is no different from the case where a
security administrator tries to create a new entry.

> These are examples of new error situations
> that we have to deal with.

Yup.  Fortunately, none of them so far seems very complicated or scary,
as long as we don't try to change the fundamental design.

Randy