Re: [Isms] Moving into some design /architectureissuesofExtendedVACM

["David Harrington" <ietfdbh at comcast.net>]

Hi, 


> No, the behaviour is already defined in VACM. Just be happy with
what
> it does and the lets move on. ;-)
> 
[...]
> 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.

agreed.

> 
> 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? 

If we tried to do this with a SET what would happen? If it would fail
as a SET, then it should fail as a dynamic creation. You might want to
use a different counter for the dynamic creation failure.

> Who wins in this situation - or
> does this even cause the authentication of the incoming request to
> fail? 

If the row contains a RowStatus, would that make a difference?


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

If we tried to do this with a SET, what would happen? we should be
consistent, although we have no way of sending back an error RESPONSE
message.

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

agreed.

> 
> /js
> 
> -- 
> 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/>
> _______________________________________________
> Isms mailing list
> Isms at ietf.org
> https://www.ietf.org/mailman/listinfo/isms
>