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

[Jari Arkko (jari.arkko]

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