Subject: [Geopriv] AW: Review of draft-ietf-geopriv-radius-lo-04.txt

From: "Tschofenig, Hannes" <[email-masked]>
Date: Sat, 3 Sep 2005 21:36:40 +0200

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 [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 03 Sep 2005 22:00:14 -0400

I certainly felt (and still feel) that this issue had been resolved in a 
fair and clear fashion.
Yours,
Joel

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 4 Sep 2005 00:56:48 -0700 (PDT)

> not been fixed 9 months later. 

The document does now support the notion of entities, so it is possible 
for the NAS to send user or NAS location.  What is missing is a way for 
the RADIUS server to request a particular type of location (or state that 
it doesn't care).  

Other standards in this area (such as IEEE 802.11k) do explicitly support 
both NAS and user location, and differentiate between the two, so this is 
a well accepted concept. 

Aside from the carrier scenarios described in the document, there are 
other uses for location information.  For example, there are factories 
keeping track of parts; defense facilities that track the location of 
users accessing the network; AAA products that support "location-aware 
access control".