eap Mailing List: Re: review of netsel-05

[Bari, Farooq (farooq.bari]

For 377, I am attaching email from myself where we agreed to make all
the changes requested in issue 377. To my recollection all of them were
implemented in ver 5 of the draft.
 
Farooq Bari
 
farooq.bari [at] att.com
+1 425 580 5526
 
 

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com] 
> Sent: Wednesday, February 21, 2007 9:47 AM
> To: eap [at] frascone.com
> Subject: Re: [eap] review of netsel-05
> 
> I have resolved issues 330, 331, 332, 334, 335 and 336 as 
> fixed in NETSEL-05.  I am assuming that 333 will be resolved in -06.
> 
> That still leaves Issues 374, 375, 376, 377, and 378 open.
> 
> Can the submitters of those issues look over the document and 
> post whether their concerns have been resolved?
> 
> The document is available for inspection here:
> http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-prob
> lem-05.txt
> 
> >Jari Arkko said:
> 
> >First, there are some open issues in the issue tracker. I consider 
> >issues 330-336 now mostly closed, based on the revisions in the new 
> >drafts. Thanks. For issue 333 there is one small remaining 
> thing, noted 
> >below.
> >
> >What is the situation with the other issues? They have been made for 
> >previous revisions, have they been resolved in -05?
> >
> >I also re-read the document and noticed two small editorial issues, 
> >also noted below.
> >
> >But otherwise I think the document is ready. Ship it!
> >
> >Parts remaining from issue 333:
> >
> > >    Section 4 gives the conclusions
> > >    and some suggestions on how to proceed for the rest.
> >This should be: "Section 4 presents our conclusions."
> >
> >Editorial:
> >
> > >    discussion of the limitations of certain classes of solution,
> >
> >s/solution/solutions/
> >
> >
> > > The solution ...
> >
> >Multiple occurrences of this. I think the draft should not 
> assume that 
> >we have a single solution in this space.
> >Therefore, we should typically write "Solutions should 
> satisfy ... " as 
> >opposed to "The solution should satisfy ..."
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
> 
> --- Begin Message ---
> Agree to make all the changes listed in the issue.
>
> BR,
>
> Farooq
>
> > -----Original Message-----
> > From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com]
> > Sent: Tuesday, August 08, 2006 7:45 PM
> > To: eap [at] frascone.com
> > Subject: [eap] Issue 377: Netsel NITs
> > 
> > Issue 377: Netsel NITs
> > Submitter name: Bernard Aboba
> > Submitter email address: aboba [at] internaut.com
> > Date Submitted: August 8, 2006
> > Reference:
> > Document: NETSEL-04
> > Comment type: Editorial
> > Priority: 1
> > Section: Various
> > Rationale/Explanation of issue:
> > 
> > Section 1
> > 
> > "which particular roaming relationship variation is used"
> > 
> > suggest changing this to:
> > "the roaming relationship path in use."
> > 
> > Section 1.1
> > 
> > I think you need to add some definitions from RFC 4284:
> > 
> >    NAI             Network Access Identifier [RFC4282].
> > 
> >    Decorated NAI   An NAI specifying a source route.  See [RFC4282]
> >                    Section 2.7 for more information.
> > 
> >    Realm       Realm portion of an NAI [RFC4282].
> > 
> > And some from RFC 4282:
> > 
> >    Network Access Identifier
> > 
> >       The Network Access Identifier (NAI) is the user identity
> submitted
> >       by the client during network access authentication.  In roaming,
> >       the purpose of the NAI is to identify the user as well as to
> >       assist in the routing of the authentication request.  Please
> note
> >       that the NAI may not necessarily be the same as the user's
> e-mail
> >       address or the user identity submitted in an application layer
> >       authentication.
> > 
> >    Network Access Server
> > 
> >       The Network Access Server (NAS) is the device that clients
> connect
> >       to in order to get access to the network.  In PPTP terminology,
> >       this is referred to as the PPTP Access Concentrator (PAC), and
> in
> >       L2TP terminology, it is referred to as the L2TP Access
> >       Concentrator (LAC).  In IEEE 802.11, it is referred to as an
> >       Access Point.
> > 
> >    Roaming Capability
> > 
> >       Roaming capability can be loosely defined as the ability to use
> >       any one of multiple Internet Service Providers (ISPs), while
> >       maintaining a formal, customer-vendor relationship with only
> one.
> >       Examples of cases where roaming capability might be required
> >       include ISP "confederations" and ISP-provided corporate network
> >       access support.
> > 
> > And some more from 802.11 terminology:
> > 
> >    Station (STA): A device that contains an IEEE 802.11 conformant
> >    medium access control (MAC) and physical layer (PHY) interface to
> the
> >    wireless medium (WM).
> > 
> >    Access Point (AP): An entity that has station functionality and
> >    provides access to distribution services via the wireless medium
> (WM)
> >    for associated stations.
> > 
> >    Basic Service Set (BSS): A set of stations controlled by a single
> >    coordination function.
> > 
> >    Extended Service Set (ESS): A set of one or more interconnected
> basic
> >    service sets (BSSs) with the same Service Set Identifier (SSID) and
> >    integrated local area networks (LANs), which appears as a single
> BSS
> >    to the logical link control layer at any station associated with
> one
> >    of those BSSs.
> > 
> >       This refers to a mechanisms that a node uses to discover
> available
> >       realms prior the realm selection takes place.
> > 
> > I can't parse the last half of the sentence.  Can we shorten this to:
> > 
> > "      This refers to a mechanisms that a node uses to discover the
> realms
> >        that are reachable from a given network."
> > 
> >       The selection will be dependent upon for
> >       example the support for an access technology by the device and
> >       availability of such access technology based networks.
> > 
> > Recommend we change this to:
> > 
> > "     The selection will be dependent upon the access technologies
> supported
> >       by the device and the availability of networks supporting those
> >       technologies."
> > 
> > bearer type -> bearer types
> > 
> > Section 2.1
> > 
> > as proposed in IEEE 802.11k
> > 
> > Please include a reference:
> > 
> > [IEEE802.11k]
> >           Institute of Electrical and Electronics Engineers, "Draft
> >           Ammendment to Standard for Telecommunications and
> Information
> >           Exchange Between Systems - LAN/MAN Specific Requirements -
> >           Part 11: Wireless LAN Medium Access Control (MAC) and
> Physical
> >           Layer (PHY) Specifications: Radio Resource Management", IEEE
> >           802.11k, D4.1, July 2006.
> > 
> >           UAM
> > 
> > Please expand this (Universal Access Method).
> > 
> > Section 2.3
> > 
> >    Within the past IETF ROAMOPS WG, a number of additional approaches
> > 
> > Suggest changing to:
> > 
> >    Within the IETF ROAMOPS WG, additional approaches
> > 
> > Section 3.1
> > 
> > "The effects to handoff" -> "The effects on handoff"
> > 
> > Section 3.2
> > 
> > Recommend changing the title to "IEEE 802"
> > 
> > Section 3.3
> > 
> > "lets the user to choose the desired PLMN" -> "lets the user choose
> the
> > desired PLMN"
> > 
> > "or a Visited PLMN (VPLMN) is a roaming case" -> "or a Visited PLMN
> (VPLMN)
> > in the roaming case"
> > 
> > "both SSID- and EAP-based" -> "both SSID and EAP-based"
> > 
> > Section 4.1
> > 
> > "phone book approach hard." -> "phone book approach difficult."
> > 
> > Section 5
> > 
> > "seems hard given" -> "seems difficult given"
> > 
> > References
> > 
> >    [11]  Housley, R. and T. Moore, "Certificate Extensions and
> >          Attributes Supporting Authentication in Point-to-Point
> Protocol
> >          (PPP) and Wireless Local Area Networks (WLAN)", RFC 3770,
> >          May 2004.
> > 
> > this has been obsoleted by RFC 4334:
> > 
> >          Housley, R. and T. Moore, "Certificate Extensions and
> >          Attributes Supporting Authentication in Point-to-Point
> Protocol
> >          (PPP) and Wireless Local Area Networks (WLAN)", RFC 4334,
> >          February 2006.
> > 
> > 
> > _________________________________________________________________
> > 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
>
> --- End Message ---