[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
lionel has asked for a few clarifications within the draft.
Wireless LAN (WLAN) Access Networks (AN) are being deployed in public
places such as airports, hotels, shopping malls, and coffee shops by
a diverse set of incumbent operators such as cellular carriers (GSM
and CDMA), Wireless Internet Service Providers (WISP), and fixed
[skip] Although the proposed attributes in this draft are intended for
wireless LAN deployments, they can also be used in other wireless and
wired networks where location-aware services are required.
==> the need goes beyond location-based services for these networks. The
location information may be needed in any roaming situation, to enable the
home network to authorize/deny access based on the user's location (network
and/or geographical location), whatever the access network technology.
Proposal: replace "where location-aware services are required" by "whenever
location information is necessary"
[hannes] sounds ok to me.
4.1 Use Case 1 - Use of Location Information in AAA
The RADIUS server authenticates and authroizes the session. If the
user's location policies are available to the RADIUS server, the
RADIUS server may deliver those policies in an Access Accept. This
information may be needed if intermediaries or other elements want to
act as Location Servers (see Section 4.2). In the absence of
receiving the policies intermediaries MUST NOT divulge the location
==> (1) the attributes that convey the policies in the Access-Accept are not
==> (2) As stated in the section 6 (Policy-Information attribute), policies
can also be put by the access network and propagated with Access-Request or
[hannes] we have updated a new of places in the draft to clarify the
==> Do the user's location policies received in the Access-Accept (in the
authorization phase) also apply to Accounting messages?
4.2 Scenario 2 - Use of Location Information for other Services
Location Servers are entities that receive the user's location
information and transmit it to other entities. For the purpose of
this scenario Location servers are the NAS, and RADIUS servers. The
RADIUS servers are in the home network, in the visited network, or in
Unless otherwise specified, excluding the proxy chain from the NAS to
the Home RADIUS, the Location Server may not transmit the location
information to other parties.
==> I think you mean: "Unless otherwise specified, the location servers MUST
NOT transmit the location information to other parties outside the proxy
chain between the NAS and the Home RADIUS server".
[hannes] your proposal sounds good. i will like a small modification:
"Unless otherwise specified, location information MUST NOT be transmitted to
other parties outside the proxy chain between the NAS and the Home RADIUS
Upon authentication and authorization, the Home RADIUS may transmit
the Rule set in an Access-Accept to the other Location Server
allowing them to transmit location information. Then and only then
they are allowed to share the information.
==> Is it possible to discriminate parties allowed to distribute the
location information to third parties e.g. only the local access network is
allowed and not intermediary networks (e.g. brokers)?
[hannes] this is possible with the full set of policies. however, i think,
that it is not particularly likely.
6. Policy-Information Attribute
In some environments it is possible for the user to attach
information about its privacy preferences. These preferences allow
the visited network, intermediate RADIUS proxies and the home network
to authorize the distribution of the user's location information.
==> How do these privacy preferences distributed by the Policy-Information
attribute in the Access-Request interact with the policies being delivered
by the Home RADIUS server in the Access-Accept?
[hannes] the policy information carried in the accesss request is only used
when the end host was able to submit them to the access network. since this
is (today) quite unlikely we will only see policies in the access-accept.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.