Re: [Isms] Moving into some design/architectureissuesofExtendedVACM

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

+1 

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:j.schoenwaelder at jacobs-university.de] 
> Sent: Thursday, June 11, 2009 1:14 PM
> To: David Harrington
> Cc: 'Dave Nelson'; isms at ietf.org
> Subject: Re: [Isms] Moving into some 
> design/architectureissuesofExtendedVACM
> 
> 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/>
>