Issue 376: Overall Comments on draft-ietf-eap-netsel-problem-04.txt

Issue 376: Overall Comments
Submitter name: Bernard Aboba
Submitter email address: abobainternaut.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.

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.

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.

Section 3 interrupts the flow of the document, and so I
think it might be
best moved to an Appendix.

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.

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.

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.


____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

See responses inline

BR,

Farooq

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_abobahotmail.com]
> Sent: Tuesday, August 08, 2006 2:53 PM
> To: eapfrascone.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: abobainternaut.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
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

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

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