Subject: Re: [eap] Issue 376: Overall Comments ondraft-ietf-eap-netsel-problem-04.txt

From: "Bari, Farooq" <[email-masked]>
Date: Thu, 7 Sep 2006 14:04:31 -0700

See responses inline

BR,

Farooq

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Tuesday, August 08, 2006 2:53 PM
> To: [email-masked]
> Subject: [eap] Issue 376: Overall Comments
ondraft-ietf-eap-netsel-problem-04.txt
> 
> Issue 376: Overall Comments
> Submitter name: Bernard Aboba
> Submitter email address: [email-masked]
> Date Submitted: August 8, 2006
> Reference:
> Document: NETSEL-04
> Comment type: Editorial
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
> 
> Organizational Issues
> 
> 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.

> 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

---

From: Jari Arkko <[email-masked]>
Date: Fri, 08 Sep 2006 13:34:52 +0300

>additional information to enable the correct credential set to be
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

---

From: "Bari, Farooq" <[email-masked]>
Date: Fri, 8 Sep 2006 08:17:44 -0700

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
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Friday, September 08, 2006 3:35 AM
> To: Bari, Farooq
> Cc: Bernard Aboba; [email-masked]; [email-masked]
> Subject: Re: [eap] Issue 376: Overall Comments
ondraft-ietf-eap-netsel-problem-
> 04.txt