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

[Bari, Farooq (farooq.bari]

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.

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
> >>
> >>
> >
> >
> >
> >