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 teliasonera.com
[mailto:jouni.korhonenteliasonera.com]
> Sent: Sunday, September 10, 2006 1:40 PM
> To: Bari, Farooq; jari.arkkopiuha.net
> Cc: bernard_abobahotmail.com; eapfrascone.com
> Subject: RE: [eap] Issue 376: Overall Comments
ondraft-ietf-eap-netsel-problem-
> 04.txt
>
> See inline.
>
> > -----Original Message-----
> > From: Bari, Farooq [mailto:farooq.baricingular.com]
> > Sent: 8. syyskuuta 2006 18:18
> > To: Jari Arkko
> > Cc: Bernard Aboba; eapfrascone.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.arkkopiuha.net]
> > > Sent: Friday, September 08, 2006 3:35 AM
> > > To: Bari, Farooq
> > > Cc: Bernard Aboba; eapfrascone.com;
jouni.korhonenteliasonera.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
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > > >
> >
> >
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|