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

[Bari, Farooq (farooq.bari]

See responses inline

BR,

Farooq

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com]
> Sent: Tuesday, August 08, 2006 2:53 PM
> To: eap [at] frascone.com
> Subject: [eap] Issue 376: Overall Comments
ondraft-ietf-eap-netsel-problem-04.txt
> 
> Issue 376: Overall Comments
> Submitter name: Bernard Aboba
> Submitter email address: aboba [at] internaut.com
> 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