RE: [Isms] Re: modularity
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Isms] Re: modularity



So the ACM needs to know whether the data has finished being updated
for that user. Assuming something akin to rowstatus (for potentially
multiple rows, however) indexed by the securityname, the ACM can
determine that an update is in progress and can wait for completiton
or (after suitable time, aborts).

dbh

> -----Original Message-----
> From: isms-bounces at lists.ietf.org 
> [mailto:isms-bounces at lists.ietf.org] On Behalf Of Randy Presuhn
> Sent: Tuesday, August 02, 2005 8:03 AM
> To: isms at ietf.org
> Subject: RE: [Isms] Re: modularity
> 
> Hi -
> 
> > From: David B Harrington <ietfdbh at comcast.net>
> > Sent: Aug 2, 2005 6:50 AM
> > To: 'Randy Presuhn' <randy_presuhn at mindspring.com>, isms at ietf.org
> > Subject: RE: [Isms] Re: modularity
> ...
> > >There is, 
> > > unfortunately, a need for
> > > the SM to know when the triggered AAA exchanges have finished.
> >
> > Why does the SM need to know this? 
> ...
> 
> Not strictly the SM per se, but one wouldn't want to hand the 
> PDU to the
> application for processing before any necessary user/group 
> mapping updates
> have happened.  Otherwise there's a processing race 
> condition.  (If the user/group
> mapping arrives in the same PDU as the authentication-related 
> stuff, and if
> the implementation-specific internal API that hands this 
> information to the
> access control stuff is synchronous, there's no problem.  If, 
> for example,
> the mapping were to arrive later, then there could be a 
> problem if there is
> no mechanism internal to the implentations to serialize things.)
> 
> Randy
> 
> _______________________________________________
> Isms mailing list
> Isms at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 



_______________________________________________
Isms mailing list
Isms at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.