Re: [Isms] Moving into some design /architectureissuesofExtendedVACM

[Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de>]

On Thu, Jun 11, 2009 at 06:23:40PM +0200, David Harrington wrote:
 
> 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?

The table has a RowStatus and a StorageType column and thus there are
quite a number of possible failure modes...
 
> > 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.

My point is that have to define what the RADIUS client does in case
the attempt to push something into the vacmSecurityToGroupTable fails
- and depending on how long we want to work on this, we might go into
all the details of distinguishing different failure modes. It will
sure get complicated if we make it complicated.

But the minimum we have to do is to specify what the RADIUS client
does if the creation fails. And I think we should avoid making this
really more complicated.

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