| Re: Re: comments on draft-groeting-eap-netselection-results-00. txt | <– Date –> <– Thread –> |
|
From: Bari, Farooq (farooq.bari |
|
| Date: Wed, 21 Jul 2004 17:31:00 -0400 (EDT) | |
|
Hi Hannes, Wolfgang et al,
This is an interesting draft. I had a somewhat different use model than what your draft seems to imply. Here is what my use case scenario looks like
1) User selects the serving network based on roaming agreements 2) The serving network authenticating the user (i.e. its AAA proxy/server), as part of AAA message flows informs the home network (i.e. subscriber’s home AAA server) about the serving network capabilities (and maybe other information e.g. hotspot location). 3) Based on the information provided by the serving network in AAA messages to the home network, the home network authenticates the user and then authorizes him for certain home services that can work on the serving network (e.g. VoIP, streaming etc.) that the user has subscribed to. The home network can do a bunch of other things (e.g. intelligent billing) as well with this extra bit of information from the serving network’s AAA proxy/server.
In other words, the communication of this type of information is between serving and home network AAA entities after the serving network has been selected by the Wireless Client. We do have a couple of drafts in RADEXT which deal with bandwidth and location attributes. I believe they will be able to solve the use case scenario I described where the communication is between RADIUS/DIAMETER entities and Wireless Client is not involved in them (i.e. no EAP communication although it will be part of AAA message flows). BTW thanks for the implementation of the draft. We will have any errors identified corrected in the next version.
BR,
Farooq |
- (no other messages in thread)
Results generated by Tiger Technologies using MHonArc.