eap Mailing List: Re: Issue 376: Overall Comments ondraft-ietf-eap-netsel-problem-04.txt

[Bari, Farooq (farooq.bari]

I have not seen any discussion so far on the issue. One possibility
could be revert back to terms "Network selection" and "Network
discovery" in the draft (keeping the term realm only in places where it
makes sense). New definition of "realm selection" as below could be
added as below. Also definitions of "Network selection" could be updated
to show the relationship between the two terms as below. 

Network Selection
This refers to selection of the operator/ISP in order to access the
network.  The process of Network Selection can occur either at the
beginning of a new session or during a handoff in case the user is
mobile.  The selection is dependent upon for example the selection of
realm for the operator, authentication credentials for the user / device
and the roaming agreements.  Network Selection can in turn also depend
upon Access Technology Selection and/or Bearer Selection.

Realm Selection
This refers to selection of the realm of the operator/ISP used to access
the network.


> -----Original Message-----
> From: jouni.korhonen [at] teliasonera.com
[mailto:jouni.korhonen [at] teliasonera.com]
> Sent: Sunday, September 10, 2006 1:40 PM
> To: Bari, Farooq; jari.arkko [at] piuha.net
> Cc: bernard_aboba [at] hotmail.com; eap [at] frascone.com
> Subject: RE: [eap] Issue 376: Overall Comments
ondraft-ietf-eap-netsel-problem-
> 04.txt
> 
> See inline.
> 
> > -----Original Message-----
> > From: Bari, Farooq [mailto:farooq.bari [at] cingular.com]
> > Sent: 8. syyskuuta 2006 18:18
> > To: Jari Arkko
> > Cc: Bernard Aboba; eap [at] frascone.com; Korhonen, Jouni
> > /TeliaSonera Finland Oyj
> > Subject: RE: [eap] Issue 376: Overall Comments
> > ondraft-ietf-eap-netsel-problem-04.txt
> >
> > Yes I see your point. I agree. I think the problem is arising
> > because at
> > some stage during the last couple of updates it was agreed to
replace
> > the term "network" with "realm" and now we are seeing that
> > they may not
> > be entirely interchangeable in all instances of their use of
> > the draft.
> > Initially I thought that maybe adding a sentence in Section 1
> > clarifying
> > that the two terms can be used interchangeably would be sufficient
but
> > it looks like that is not the case. I think use of "realm" can cause
> > similar confusion in other places e.g. the current section 2.5 which
> > will now be called "Capability Discovery" is more inline with
> > discussion
> > on network selection than realm selection. Maybe what we need
> > is a clear
> > definition of "network selection" and "realm selection" with some
> > explanation of how the two are related. This can help
> > identify the right
> > term to be used in different parts of the draft.
> 
> Proper explanations would be useful. We did try to do this during
> -04 revision and ended up to bearer & access tech. selection
> terminology.
> These are not, however, used outside the termonilogy section... so it
> seems
> there is room for terminology that is actually usable ;-)
> 
> Cheers,
>       Jouni
> 
> >
> > BR,
> >
> > Farooq
> > > -----Original Message-----
> > > From: Jari Arkko [mailto:jari.arkko [at] piuha.net]
> > > Sent: Friday, September 08, 2006 3:35 AM
> > > To: Bari, Farooq
> > > Cc: Bernard Aboba; eap [at] frascone.com;
jouni.korhonen [at] teliasonera.com
> > > Subject: Re: [eap] Issue 376: Overall Comments
> > ondraft-ietf-eap-netsel-problem-
> > > 04.txt
> > >
> > > Bari, Farooq wrote:
> > >
> > > >>This document has some organizational issues.   Section 1
> > describes
> > > >>
> > > >>
> > > >when
> > > >
> > > >
> > > >>the realm selection problem becomes relevant but since the
problem
> > is
> > > >>defined in Section 2, the reader is left without an
> > understanding of
> > > >>
> > > >>
> > > >how
> > > >
> > > >
> > > >>the problem manifests itself in those situations.  To provide
some
> > > >>context, I think that some text is needed in Section 1 for each
of
> > the
> > > >>first two bullets, describing the issues that can occur.
> > The third
> > > >>
> > > >>
> > > >bullet
> > > >
> > > >
> > > >>does include discussion of issues.
> > > >>
> > > >>
> > > >>
> > > >[Bari, Farooq] Propose to update first two bullets of section 1
as
> > > >follows
> > > >
> > > >There is more than one available network attachment point, and
the
> > > >different attachment points may have different characteristics or
> > belong
> > > >to different operators.  In the case of virtual operators, access
> > > >network infrastructure including e.g. the access points
> > can be shared
> > by
> > > >multiple operators. In order to choose between the network
> > attachment
> > > >points, it may be helpful to determine which realms are
> > supported and
> > > >what the capabilities of those realms are.
> > > >
> > > >The user has multiple sets of credentials.  For instance, the
user
> > could
> > > >have one set of credentials from a public service provider and
set
> > from
> > > >the user's employer. In this case it may be helpful to provide
> > > >additional information to enable the correct credential set to be
> > > >determined.
> > > >
> > > >
> > > If the preceding paragraph still says "The realm discovery and
..."
> > then
> > > I don't think the first paragraph above fixes the issue that I
had.
> > > Specifically, the fact that you have different access points even
> > > with, say, different capacity does not imply that you need to
> > > do realm selection. Obviously you need to do the access point
> > > selection, but that's not the same as realm selection.
> > Realm selection
> > > becomes relevant when you have multiple operators or multiple
> > > higher level "networks" available.
> > >
> > > --Jari
> > >
> > > >>In order to parallel the problems listed in Section 2, I was
> > expecting
> > > >>
> > > >>
> > > >a
> > > >
> > > >
> > > >>section on "Payload routing" as well as one on "realm capability
> > > >>discovery".  Instead, I found found Sections 2.4 and 2.5 which
do
> > not
> > > >>
> > > >>
> > > >seem
> > > >
> > > >
> > > >>to correspond to one of the listed problems.  I think Section
2.5
> > does
> > > >>relate to the "capability discovery" problem so that perhaps it
> > should
> > > >>
> > > >>
> > > >be
> > > >
> > > >
> > > >>renamed.  I am not clear why Section 2.4 belongs where it is;
I'd
> > > >>
> > > >>
> > > >suggest
> > > >
> > > >
> > > >>it be moved out of Section 2.
> > > >>
> > > >>
> > > >>
> > > >
> > > >[Bari, Farooq] My understanding was that Payload Routing was
> > considered
> > > >out of scope right from the earlier versions of the draft and
this
> > > >decision is captured in the beginning of the section 2.
> > > >
> > > >Agree to change the title for section for capability discovery
> > > >
> > > >Propose to delete section 2.4 from the draft.
> > > >
> > > >
> > > >
> > > >>Section 2.3.1 seems to end just as it got started.  This section
> > seems
> > > >>
> > > >>
> > > >to
> > > >
> > > >
> > > >>be going somewhere important so I think it needs to be
> > fleshed out.
> > > >>
> > > >>
> > > >For
> > > >
> > > >
> > > >>example, it could talk about how "default" versus "default free"
> > > >>
> > > >>
> > > >proxies
> > > >
> > > >
> > > >>in AAA routing.
> > > >>
> > > >>
> > > >>
> > > >[Bari, Farooq] will get back to you on it (or if you have any
> > proposed
> > > >text pls post).
> > > >
> > > >
> > > >
> > > >>Section 3 interrupts the flow of the document, and so I think it
> > might
> > > >>
> > > >>
> > > >be
> > > >
> > > >
> > > >>best moved to an Appendix.
> > > >>
> > > >>
> > > >>
> > > >[Bari, Farooq] Agree to move it to an Annex
> > > >
> > > >
> > > >
> > > >>Section 4 is actually quite important, since one of the goals of
> > this
> > > >>effort was to address architectural problems with existing
> > solutions.
> > > >>However, this section does not talk much about scalability
issues.
> > > >>
> > > >>
> > > >>
> > > >[Bari, Farooq] Agree to add a new subsection on scalablity with
the
> > > >following proposed text
> > > >
> > > >Scalability
> > > >Depending upon deployment scenarios and business agreements
amongst
> > the
> > > >network operators, the number of networks to be advertised
> > can range
> > > >from a few to a very large number. The solution should therefore
be
> > > >scalable so that it can handle from a small to a very
> > large number of
> > > >networks without violating the efficiency constraints described
in
> > > >section 4.3.
> > > >
> > > >
> > > >
> > > >>Terminology
> > > >>
> > > >>The abstract refers to the "realm discovery and selection
> > problem",
> > as
> > > >>do sections 1 and 2. However, the title of the document is still
> > > >>
> > > >>
> > > >"Network
> > > >
> > > >
> > > >>Discovery and Selection Problem".  Also Section 3 uses other
terms
> > > >>
> > > >>
> > > >such as
> > > >
> > > >
> > > >>"access network discovery", "network discovery process",
"network
> > > >>selection", without defining them.  If you are going to use
these
> > > >>
> > > >>
> > > >terms
> > > >
> > > >
> > > >>later on, I think that either new definitions are needed
> > in Section
> > > >>
> > > >>
> > > >1.1,
> > > >
> > > >
> > > >>or the terminology should be harmonized with the existing
> > definitions.
> > > >>Currently the terms "Access Technology Selection" and "Bearer
> > > >>
> > > >>
> > > >Selection"
> > > >
> > > >
> > > >>do not appear to be referenced outside Section 1.1.
> > > >>
> > > >>
> > > >>
> > > >[Bari, Farooq] Agree to change the terminology from "network
> > discovery"
> > > >to "realm discovery". Propose to add a sentence in Section1 to
> > clarify
> > > >that the term "network discovery" has been used
> > interchangeably with
> > > >"realm discovery" by some to describe the same process.
> > > >
> > > >
> > > >
> > > >>References
> > > >>
> > > >>Two reference styles are used.  Most of the time the
> > straight number
> > > >>
> > > >>
> > > >style
> > > >
> > > >
> > > >>is used (e.g. [34]).  However, in Section 3.3, the author name
is
> > also
> > > >>given (e.g. "Ahmavaara, Haverinen and Pichna [34]").  I would
> > suggest
> > > >>using a consistent style.  Personally, I am not very fond of the
> > > >>
> > > >>
> > > >number
> > > >
> > > >
> > > >>style of referencing, particularly when RFCs are being
referenced.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >[Bari, Farooq] agree to use same format
> > > >
> > > >
> > >
> >>________________________________________________________________
> > > _
> > > >>To unsubscribe or modify your subscription options, please
visit:
> > > >>http://lists.frascone.com/mailman/listinfo/eap
> > > >>
> > > >>Arhives: http://lists.frascone.com/pipermail/eap
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > > >
> >
> >