[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


At 03:36 PM 9/3/2005, Tschofenig, Hannes wrote:
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/>


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