Re: Issue 378: Network Selection Comments
From: Bari, Farooq (farooq.baricingular.com)
Date: Fri, 8 Sep 2006 07:59:16 -0700 (PDT)
See responses inline.

BR,

Farooq

> -----Original Message-----
> From: Bernard Aboba [mailto:Bernard_Aboba [at] hotmail.com]
> Sent: Thursday, September 07, 2006 9:40 PM
> To: Bari, Farooq; eap [at] frascone.com
> Cc: 'Jari Arkko'; jouni.korhonen [at] teliasonera.com
> Subject: RE: [eap] Issue 378: Network Selection Comments
> 
>  [Bari, Farooq] Propose to change the first sentence as follows
> 
> This refers to selection of the realm of an operator/ISP in order to
> access the network.
> 
> [BA] The problem is that the realm need not necessarily be provided by
the
> operator/ISP.  It could be a corporate realm, for example.   So you
might
> just say either "selection of the realm used to access the network" or
> "selection of the operator/ISP used for network access".  The problem
is
> that I don't know which is meant here -- and they are different.
> 
> 
[Bari, Farooq] I meant the first of the two. If others have the same
understanding we can change it to "selection of the realm used to access
the network".

> [Bari, Farooq] In issue 376 response we agreed to add a new section on
> scalability in current section 4. I am not sure if this needs to be
> added in section 2. The comment about RFC 4284 behavior does not seem
to
> be correct - my understanding is that the realms are not always
> advertised to the client.
> 
> [BA] Right -- realms may not always be advertised.  But the issue
occurs
> when they need to be.  Glen's point was that RFC 4284 dumps the realm
table,
> most of which the client won't be able to use.  In contrast, a
> request/response protocol would only return those realms that the
client
> indicates that it can access.  This is not only more efficient, but
also
> potentially addresses security concerns about exposing the realm table
to
> non-authorized users.
> 
> 
[Bari, Farooq] I do not think RFC 4284 mandated a behavior on the part
of the network that would imply that the client always gets the entire
list of roaming partners of the e.g. the hotspot operator. For example
it is possible that hotspot operator decides to advertise only top three
roaming partners etc. But such logic is not something that gets
standardized.

Results generated by Tiger Technologies using MHonArc.