Subject: [eap] Issue 287: Roaming Model

From: Bernard Aboba <[email-masked]>
Date: Sun, 13 Feb 2005 12:13:04 -0800 (PST)

This issue, raised by Glen seems to relate to the roaming model implicitly
assumed by this document, and whether it is compatible with the IETF
roaming model as embodied in the products of the ROAMOPS WG.

Glen has put forward a basic ROAMOPS roaming scenario, and has questioned
whether this scenario is supported by the document.

Some questions raised by this issue include:

o Are the roaming model assumptions and limitations clearly articulated in
  the document?

o Is the document capable of supporting basic roaming scenarios, such as
  those articulated by Glen as well as other ROAMOPS documents?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Bari, Farooq" <[email-masked]>
Date: Sun, 13 Feb 2005 23:25:17 -0800

Pls see my comments below

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Sunday, February 13, 2005 7:27 PM
> To: Bari, Farooq
> Cc: [email-masked]
> Subject: RE: [eap] Issue 287: Roaming Model
> 
> > My response
> > 1.	Bigco can have its employee's handsets/laptops provisioned with
> > a list of its preferred roaming partners lists which in this case
would
> > include Consort.com.
> 
> I think the question is what assumptions this document makes about how
AAA
> proxy routing tables are transformed into EAP network announcements.
> Essentially, what is being defined here is a peer-AAA proxy routing
> protocol into which static AAA proxy routes are redistributed.  Once
the
> peer obtains the routing table, it uses it to form the "source routes"
> utilized within the NAI.
> 
> Multiple issues are brought up by Glen's comments:
> 
> a) Is the roaming model proposed by the document adequately specified
and
> analyzed?
I believe so. The draft however to my understanding is more for ABNF.
There were discussion on the roaming models etc. in the earlier versions
of draft and they were discussed in IETF as well as in other forums.
They were taken out on Chair's suggestion from later versions of the
draft.

> b) Does the proposed model scale?  What are its limitations?
> 
It will work well for what it is being aimed for - I think this issue
was brought and discussed quite thoroughly in the past IETF meetings but
maybe an applicability statement is needed so that people reading the
draft understand its intended applicability. It certainly can not solve
and is not designed to solve world hunger problem :-)).

> > One possible scenario is that:
> > The Bigco employee with her Bigco credentials tries to authenticate
> > herself. Megatel does not recognize her
> 
> It would be more clear if you described the scenario in terms of the
> entries present in the AAA proxy routing table and the ensuing
> announcements.  Are you saying that a bigco.com entry is present in
the
> routing table, but that this document specifies that a "filter" is to
be
> applied to that entry so that it is not announced?  Or are you saying
that
> the entry is not present at all, and therefore is not announced?
There is
> a considerable difference between these two scenarios.

What I am indicating is that based on a number of possible reasons, the
first message sent to the network from the client may already have a
decoration to indicate a preferred network. For example if I go to
Europe and BT is my preferred partner in Europe, I can change my client
settings  to by default try to use BT as the middle man. In that case my
initial message will be decorated with BT info. If the hotspot operator
has a relationship with BT, then there will be no advertisement.  But
this is all client behaviour and not something that needs to go into the
draft. Also please note these advertisement do not always happen but
only happen when the user message is not routable by the AAA proxy.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap