RE: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )

["Avi Lior" <avi@bridgewatersystems.com>]

Hi Bernard,
 

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: Friday, September 09, 2005 4:09 PM
> To: Emile van Bergen
> Cc: Avi Lior; Nelson, David; radiusext@ops.ietf.org
> Subject: Re: Capabilities (was Re: AW: Review of 
> draft-ietf-geopriv-radius-lo-04.txt )
> 
> > In such deployments you simply send location in access request. The 
> > local AAA determines whether he trusts the path towards home AAA 
> > enough to forward location. End of story.
> 
> That is certainly one way to configure the system, and it 
> definitely simplifies things. 

Absolutely.

> The question is why GEOPRIV has decided not to send location 
> by default. 

Initially we did exactly that we sent the location information in the
Access-Request.  But Geopriv being about privacy, was concerned what if
the user did not want to have their location exposed.

So now we have the case where in some systems, the user's policy of
whether or not to expose location is stored in the a database and during
authentication the AAA learns that policy.


> > But that advertisement is also an extra transaction. What's 
> the home 
> > AAA supposed to do, keep state from separate pseudo-authentications 
> > that include the advertised information for later use? That doesn't 
> > sound like RADIUS, at all.
 
> Right. 

Wrong.

No the advertizement is not an extra transaction.  It comes in the
Access-Request.

And by the way, RADIUS does keep transactional state.  But even if it
didn't upon receiving the Adevertizement it can respond with a challenge
right away.

> 
> 

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>