AW: Review of draft-ietf-geopriv-radius-lo-04.txt

["Tschofenig, Hannes" <hannes.tschofenig@siemens.com>]

hi bernard, 

i guess there is a misunderstand here with regard to the functionality
of the radius-geopriv draft. 
joel raised this issue and we discussed it. 

we always supported the idea of providing location for the end host. we
had a very, very long discussion about this topic when we merged the two
radius-geopriv drafts.

what has been changed as part of joel's issue was
- the name of the avp (since it was misleading) and
- the description to address joel's comments

this issue has been resolved on the mailing list and i also had further
off-list discussions with joel.

i think you do not treat me fair with your statement that this issue has
not been fixed 9 months later. 

ciao
hannes

> > > > Am I missing something, or is the problem really this simple? 
> > > 
> > >   It would appear so.
> 
> The "server-driven" approach also provides a mechanism to 
> address RADEXT 
> Issue 27 (Who's Location). 
> 
> One of the major problems with the RADIUS-GEOPRIV document is that it 
> does not support user location determination, only  NAS location. 
> 
> This is a problem for vendors who are shipping APs with built-in 
> location support that enables APs to pinpint the location of 
> associated 
> stations.  At least one RADIUS server implementation now supports 
> "location-based access control".  Why can't the RADIUS-GEOPRIV 
> specification be used to send user as well as NAS location? 
> 
> This basic problem with the document was pointed out in 
> November 2004, but 
> has still not been fixed in August 2005, 9 months later.  
> 
> However, using the "server-driven" approach, the problem would  
> not be hard to address.  In the "send location" attribute 
> included by the 
> server, the server can specify what type of location data it 
> is looking 
> for - user or NAS.  
> 
> Note that layer 2 standards such as IEEE 802.11k already enable this 
> distinction.  In IEEE 802.11k a station can ask either for its own 
> location or the location of the AP.  
> 
> --
> 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/>
> 

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