Re: [mif] AD review of draft-ietf-mif-current-practices

[<[e-mail]>]

Hi Dan,

Thanks for the comments.

The new version is now available: http://www.ietf.org/internet-drafts/draft-ietf-mif-current-practices-08.txt 

Pierrick

> -----Message d'origine-----
> De : Dan Wing [mailto:[e-mail]] 
> Envoyé : jeudi 24 février 2011 00:55
> À : SEITE Pierrick RD-RESA-REN
> Objet : RE: [mif] AD review of draft-ietf-mif-current-practices
> 
> Nit:
> 
> Could section 3 please name the company for each?  It can 
> help with searching.  
> 
>        3.1.1.  Nokia S60 3rd Edition, Feature Pack 2  . . . . 
> . . . .  7
>        3.1.2.  Microsoft Windows Mobile and Windows Phone 7 . 
> . . . .  9
>        3.1.3.  BlackBerry . . . . . . . . . . . . . . . . . . 
> . . . . 10
> 
> should be "RIM BlackBerry" or "Research in Motion BlackBerry"
> 
>        3.1.4.  Google Android . . . . . . . . . . . . . . . . 
> . . . . 11
>        3.1.5.  Qualcomm Brew  . . . . . . . . . . . . . . . . 
> . . . . 12
>        3.1.6.  Arena Connection Manager . . . . . . . . . . . 
> . . . . 13
> 
> maybe should be "Linux Arena Connection Manager"
> 
>        3.1.7.  Current practices for network selection in 
> handsets  . 13
> 
> 3.1.7 seems out of place.  Was it supposed to be the next 
> section, and there is a mis-placed "</section>", perhaps?
> 
> 
> There is long-standing confusion that the iPhone has IPv6 on 
> the cellular interface because it has IPv6 on WiFi.  Perhaps 
> mention that, as a one paragraph thing, like:
> 
>   3.1.x Apple iPhone
> 
>   Apple iPhone supports IPv6 on its WiFi interface, but not on
>   the cellular interface.  Its interaction on WiFi has not been
>   analyzed and is out of scope of this paper.
> 
> ?
> 
> 
> -d
> 
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of 
> > [e-mail]
> > Sent: Monday, February 14, 2011 6:26 AM
> > To: [e-mail]; [e-mail]; 
> > [e-mail]; [e-mail]; [e-mail]
> > Subject: Re: [mif] AD review of draft-ietf-mif-current-practices
> > 
> > Hi,
> > 
> > 
> > 
> > A new version of "current practices" is available :
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-mif-current-practices-
> > 07.txt <http://www.ietf.org/internet-drafts/draft-ietf-mif-current-
> > practices-07.txt>
> > 
> > 
> > 
> > 
> > 
> > The Diff from previous version is on:
> > 
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-mif-current-practices-07
> > 
> <http://tools.ietf.org/rfcdiff?url2=draft-ietf-mif-current-practices-
> > 07>
> > 
> > 
> > 
> > modifications of releases -06 and -07 are summarized below:
> > 
> > 
> > 
> > -06: update Nokia S60,  Androïd and Linux sections with information 
> > regarding DNS configuration, RFC3484 support and address 
> overlapping 
> > issue. Section "Apple" has been removed.
> > 
> > 
> > 
> > -07: address Stefano's comments and updates RIM section 
> regarding DNS 
> > configuration, RFC3484 support and address overlapping issue.  This 
> > version also adds considerations on RFC3484 support for 
> Windows Mobile 
> > and windows phone.
> > 
> > 
> > 
> > 
> > 
> > Regards,
> > 
> > Pierrick Seite
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > ________________________________
> > 
> > De : Stefano Faccin [mailto:[e-mail]] Envoyé : lundi 
> 7 février 
> > 2011 18:13 À : SEITE Pierrick RD-RESA-REN; [e-mail]; 
> > [e-mail]; [e-mail] Objet : Re: [mif] AD review of 
> > draft-ietf-mif-current-practices
> > 
> > 
> > 
> > Pierrick,
> > I believe the statement as you phrased captures the concept 
> very well.
> > Thanks,
> > Stefano
> > 
> > Stefano M. Faccin
> > 
> > Standards Manager
> > Research In Motion
> > 122 West John Carpenter Parkway
> > Irving, TX 75039
> > Internal: 820 63451
> > Desk: [phone]
> > BlackBerry: [phone]
> > [e-mail]
> > Time zone: PST (GMT -8)
> > 
> > 
> > From: [e-mail] 
> [mailto:pierrick.seite@orange- 
> > ftgroup.com]
> > Sent: Monday, February 07, 2011 11:07 AM
> > To: Stefano Faccin; [e-mail] <[e-mail]>; 
> > [e-mail] <[e-mail]>; [e-mail] 
> > <[e-mail]>
> > Subject: RE: [mif] AD review of draft-ietf-mif-current-practices
> > 
> > 
> > If I refer to the current text on RIM, I understand that Address 
> > overlapping is supported because the OS can manage multiple 
> IP stacks 
> > associated to multiple interface. Right?
> > 
> > 
> > 
> > Pierrick
> > 
> > 
> > 
> > ________________________________
> > 
> > De : Stefano Faccin [mailto:[e-mail]] Envoyé : lundi 
> 7 février 
> > 2011 17:41 À : SEITE Pierrick RD-RESA-REN; [e-mail]; 
> > [e-mail]; [e-mail] Objet : RE: [mif] AD review of 
> > draft-ietf-mif-current-practices
> > 
> > 
> > 
> > Pierrick,
> > 
> > The BlackBerry uses per-interface DNS and applications use the DNS 
> > bound to a specific interface. Address overlapping is 
> supported and is 
> > managed by OS mechanisms. I hope this suffices.
> > 
> > Cheers,
> > 
> > 
> > 
> > Stefano Faccin
> > 
> > 
> > 
> > Standards Manager
> > 
> > Research In Motion Corporation
> > 5000 Riverside Drive
> > Building 6, Brazos East, Ste. 100
> > 
> > Irving, Texas 75039 USA
> > Office: [phone]
> > 
> > Internal: 820.63451
> > 
> > Untitled-1: [phone]
> > 
> > www.rim.com <outbind://28-
> > 
> 00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA3
> > 0 
> > 
> 259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/
> > w ww.rim.com> ; www.blackberry.com <outbind://28- 
> > 
> 00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA3
> > 0 
> > 
> 259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/
> > w
> > ww.blackberry.com>
> > 
> > 
> > 
> > cid:image004.png@01CB49EA.87D92140 <http://www.blackberry.com/>
> > 
> > 
> > 
> > P Consider the environment before printing.
> > 
> > 
> > 
> > From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of 
> > [e-mail]
> > Sent: Monday, February 07, 2011 12:40 AM
> > To: [e-mail]; [e-mail]; [e-mail]
> > Subject: Re: [mif] AD review of draft-ietf-mif-current-practices
> > 
> > 
> > 
> > Hi Stefano,
> > 
> > 
> > 
> > Thanks for your comments, I'll update the draft 
> accordingly. BTW, do 
> > you have information on the following points for RIM blackberry:
> > 
> > 
> > 
> > - How the RIM blackberry manage Address selection: e.g. is RFC 3484 
> > supported?
> > 
> > 
> > 
> > - DNS resolution issue on RIM blackberry: is DNS configuration 
> > per-node or per-interface? If an application is bound to an 
> interface, 
> > does it always use the DNS settings for exactly that 
> interface or the 
> > per-node settings.
> > 
> > 
> > 
> > - address space overlapping: When the RIM blackberry is 
> simultaneously 
> > attached to several interfaces, is the OS manage address space 
> > overlapping? If yes, how does it work?
> > 
> > 
> > 
> > BR,
> > 
> > Pierrick
> > 
> > 
> > 
> > 
> > 
> > ________________________________
> > 
> > De : [e-mail] [mailto:[e-mail]] De 
> la part de 
> > stefano faccin Envoyé : vendredi 4 février 2011 20:31 À : 
> > [e-mail]; [e-mail] Objet : Re: [mif] AD review of 
> > draft-ietf-mif-current-practices
> > 
> > 
> > 
> > Hello all,
> > I have reviewed version 06 of the draft and I have a few comments.
> > 
> > Under section 3.1.3 on the BlackBerry, I would modify "Java 
> > applications" to just "applications", since I believe we want to 
> > capture the most generic case of BlackBerry, independently 
> of the OS.
> > 
> > Under section 3.1.3 on the BlackBerry, it says "An application 
> > connecting to the Internet, can use either the BlackBerry Internet 
> > Service or the Internet gateway of the wireless server provider to 
> > manage connections". Can we modify this to "... can use either the 
> > BlackBerry Internet Service or the Internet gateway of the wireless 
> > server provider or direct Internet connectivity over WLAN 
> to ..." for 
> > correctness/completeness?
> > 
> > In section 3.1.7 there is an incorrect statement "The RIM 
> Blackberry 
> > behaves differently, the connection manager selects the 
> first SSID on 
> > which it has managed to attach in the past." Please replace this 
> > statement with "The RIM Blackberry behaves differently: the 
> user (e.g.
> > the enterprise owning the device) is allowed to define its 
> preferred 
> > access. The connection manager selects the first SSID of 
> the preferred 
> > list of SSIDs configured in the device and that is 
> available based on 
> > the WLAN scan the device has performed", since it is not 
> true that the 
> > BlackBerry always tries first the last SSID it has managed 
> to attach 
> > in the past.
> > 
> > The section also contain a statement that does not apply to all 
> > devices, i.e. "When the IP stack fails to obtain an IP address, the 
> > handset, excepted the iPhone, restarts WLAN attachment 
> selecting the 
> > second SSID in the list. " The BlackBerry, when it fails to 
> obtain an 
> > IP address after successful WLAN attachment, performs a new 
> WLAN scan 
> > and, among the networks available, it selects the next SSID in the 
> > preferred list, which means that the approach is different from the 
> > one the original sentence tries to capture.
> > 
> > Cheers,
> > 
> > Stefano
> > 
> > On Tue, Feb 1, 2011 at 6:41 AM, <[e-mail]>
> > wrote:
> > 
> > Hello Jari,
> > 
> > I've submitted a new version of draft-ietf-mif-current-practices
> > 
> (http://www.ietf.org/internet-drafts/draft-ietf-mif-current-practices-
> > 06.txt). According to your comments, Nokia (thanks again Teemu), 
> > Androïd and Linux sections have been updated with information 
> > regarding DNS configuration, RFC3484 support, RFC1122 status and 
> > address overlapping issue. Section "Apple" has been removed.
> > 
> > BR,
> > Pierrick
> > 
> > > -----Message d'origine-----
> > > De : SEITE Pierrick RD-RESA-REN
> > > Envoyé : samedi 23 octobre 2010 12:01 À : [e-mail]; 
> > > [e-mail] Objet : RE: [mif] AD review of 
> > > draft-ietf-mif-current-practices
> > 
> > >
> > > Hi Jari, all,
> > >
> > > We've submitted a new version of the 
> > > draft-ietf-mif-current-practices (More details inline). However, 
> > > there is a pending issue: we still
> > need
> > > additional information, especially from manufacturers, to address
> > your
> > > concern with section 3.1.
> > >
> > > So, we request the support from the WG, especially from folks who
> > have
> > > provided per-OS initial information, to address Jari's concerns.
> > Interface
> > > selection is, generally, well documented but we need more 
> details on 
> > > following topics:
> > >
> > > - Address selection: is RFC 3484 supported? Linux and windows
> > implement
> > > RFC3484 (I've just noticed that only the windows section refers to
> > RFC3484,
> > > I'll align the linux section in the next version), but what about 
> > > the others (nokia, blackberry, windows mobile, android)?
> > >
> > > - DNS resolution issues: Windows and Linux section are well
> > documented.
> > > But others sections must be developed. Reflecting Jari's 
> comment: is
> > DNS
> > 
> > > configuration per-node or per-interface? If an 
> application is bound
> > to an
> > 
> > > interface, does it always use the DNS settings for exactly that
> > interface
> > 
> > > or the per-node settings.
> > 
> > >
> > > - address space overlapping: we do not have information on these
> > issues
> > > and we'd appreciate feedback from the WG (especially from
> > manufacturers
> > > involved in MIF). When the terminal is simultaneously attached to
> > several
> > > interfaces, is the OS manage address space overlapping? 
> If yes, how
> > does
> > > it work?
> > >
> > >
> > > - The section "Apple Mac OS X" is poor in comparison to 
> windows and
> > Linux
> > > section. If we do not have more information for apple mac 
> os, we'll
> > remove
> > > the section.
> > >
> > > - Android: can we consider that basic android kernel (excluding
> > vendors
> > > specific implementations) manages multiple interfaces 
> issues in the
> > same
> > > way than the current Linux OS?
> > >
> > >
> > > Regards,
> > > Pierrick
> > >
> > > > -----Message d'origine-----
> > > > De : [e-mail] [mailto:[e-mail]] 
> De la part
> > de
> > > Jari
> > > > Arkko
> > > > Envoyé : vendredi 1 octobre 2010 20:45 À : mif; 
> > > > [e-mail]
> > > > Objet : [mif] AD review of draft-ietf-mif-current-practices
> > > >
> > 
> > > > I have reviewed this document. Overall, this is a good document,
> > but
> > > > some work still remains. My biggest issues were the following:
> > > >
> > > > The document is quite focused on the access network selection
> > problem,
> > > > which has already been discussed extensively in RFC 5113. It is
> > fine to
> > > > include discussion of the access network selection problem as 
> > > > well, because it is all part of the same problem space. But I 
> > > > would have expected the document discuss in more detail 
> what the 
> > > > various implementations do at layer 3. For instance, do 
> they use 
> > > > RFC 3484,
> > are
> > > > DNS settings per-node or per-interface, if an 
> application is bound
> > to an
> > > > interface does it always use the DNS settings for exactly that
> > interface
> > > > or the per-node settings, what happens with overlapping address
> > space,
> > > etc.
> > > >
> > > > The document is somewhat imbalanced, there's very little (too
> > little)
> > > > information about some devices and operating systems whereas the
> > Windows
> > > > description is detailed and informative. I would 
> suggest that some
> > of
> > > > the devices for which there is very little information 
> are either 
> > > > removed from the document or some more information is inserted
> > about
> > > them.
> > > >
> > > > Detailed comments:
> > > >
> > > > Section 3.1.3 s/in a MIF context/here/ (the MIF context 
> is a fine
> > term
> > > > to use in WG discussion, but will look odd in a published RFC by
> > the
> > > > time the WG has concluded).
> > > >
> > >
> > 
> > > NEW TEXT:
> > >
> > > In comparison to Windows Mobile 2003 SE, Windows phone 7 brings
> > update of
> > > the routing functionality in the case where the terminal can be
> > attached
> > > simultaneously to several interfaces.
> > >
> > 
> > > > On Section 3.1.4 (BlackBerry) it was unclear to me what type of
> > gateways
> > > > the text refers to. Default router, web proxy, 
> application proxy, 
> > > > something else?
> > >
> > 
> > > I agree that the original text was unclear. I've revised 
> the section
> > but
> > > Giyeong, please check we kept ideas from your original text.
> > >
> > 
> > > On the second paragraph of the same section it is
> > > > unclear what "device" refers to. The entire device can use 
> > > > multiple networks simultaneously? Does that mean that one 
> > > > application can
> > use
> > > > multiple networks simultaneously, to the same 
> destinations (like 
> > > > in
> > > > mp-tcp) or to different destinations? Or just that multiple
> > applications
> > > > can use different networks simultaneously?`Please be 
> more precise
> > about
> > > > what is actually happening, as opposed to claiming a general
> > capability.
> > > >
> > >
> > 
> > > Ok, text has been revised.
> > >
> > 
> > > > Section 3.1.7 says very little about the hard issues around MIF,
> > such as
> > > > whether overlapping address space is tolerated, whether 
> there is a 
> > > > possibility of some policy being sent from the network, whether 
> > > > DNS
> > info
> > > > is per node or per interface, etc.
> > > >
> > > > But also other sections under 3.1 seem thin. I realize that its
> > hard to
> > > > get information, but at least some of these devices are open 
> > > > source
> > and
> > > > run on top of standard kernels such as Linux, so it should be
> > possible
> > > > to find out a bit more.
> > >
> > 
> > > I guess you are referencing to android terminals; I was also 
> > > thinking
> > that
> > > the behaviour of an android could be deduced from current Linux 
> > > functionalities but it seems that the situation is more complex. 
> > > It's
> > true
> > > that Android is based on a Linux kernel but some functions are
> > sometimes
> > > customized by vendors. So we sometimes experience different 
> > > behaviour between different android terminals. For instance, some 
> > > android
> > terminal
> > > cannot run IPv6 only, they need getting an IPv4 address first, and
> > then,
> > > even with IPv6 support some android cannot manage multiple IPv6
> > prefixes
> > > on a single interface; some others inhibit the 3G/WLAN
> > multihoming....
> > > while all these functions are well supported on a Linux 
> laptop. Note
> > that
> > > it is not just a matter of configuration since and the 
> only way to 
> > > overcome these limitations is to change the android platform.
> > >
> > > I've added in the text that behaviour of an android terminal can
> > depends
> > > on the vendors implementation.
> > >
> > 
> > > Or we can ask for further information from the
> > > > people who gave us the original data, I suppose at least some of
> > them
> > > > work for the manufacturers.
> > > >
> > >
> > 
> > > Yep, we need additional information from vendors....
> > >
> > > > > iPhone
> > > > >
> > > > > Iphone
> > > > Inconsistent capitalization.
> > > >
> > >
> > > Fixed
> > >
> > 
> > > > >       Whatever is the handset, fallback on L3 
> attachment failure
> > is
> > > not
> > > > >       supported for motionless terminals.  Actually, the
> > connection
> > > > >       manager always selects the most powerful signal strength
> > without
> > > > >       considering IP configuration results.  In other 
> words, if
> > the
> > > > >       terminal is unable to set up the IP connectivity on one
> > wifi
> > > > >       access, the connection manager will not try to 
> attach to an
> > > > >       alternative point of attachment (or SSID) as long as the
> > signal
> > > > >       strength of the first radio link is the most powerful.
> > > >
> > > > What is "motionless terminal"? All devices that you mention are
> > mobile.
> > > >
> > >
> > 
> > > We meant: a terminal which remains under coverage of the same AP.
> > >
> > > The test has been revised.
> > >
> > 
> > > > Besides, I'm fairly certain that the above does not apply to
> > Android.
> > > > The device that I have does seem to switch away from a strong-
> > signal
> > > > SSID to another SSID, if L3 attachment fails.
> > > >
> > >
> > 
> > > Actually, we can have different behaviour with different Android
> > platforms
> > > (see above). The text in the doc applies only to the "HTC majic".
> > >
> > 
> > > > > in the scope of MIF.
> > > > >
> > > >
> > > > ... in the scope of this document.
> > > >
> > >
> > 
> > > Ok, fixed
> > 
> > >
> > > > Jari
> > > >
> > > > _______________________________________________
> > > > mif mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/mif
> > _______________________________________________
> > mif mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mif
> > 
> > 
> > 
> > 
> > --
> > Stefano M. Faccin
> > ==================
> > May the Force be with you
> > 
> > 
> ---------------------------------------------------------------------
> > This transmission (including any attachments) may contain 
> confidential 
> > information, privileged material (including material 
> protected by the 
> > solicitor-client or other applicable privileges), or 
> constitute non- 
> > public information. Any use of this information by anyone 
> other than 
> > the intended recipient is prohibited. If you have received this 
> > transmission in error, please immediately reply to the sender and 
> > delete this information from your system. Use, dissemination, 
> > distribution, or reproduction of this transmission by unintended 
> > recipients is not authorized and may be unlawful.
> > 
> > 
> ---------------------------------------------------------------------
> > This transmission (including any attachments) may contain 
> confidential 
> > information, privileged material (including material 
> protected by the 
> > solicitor-client or other applicable privileges), or 
> constitute non- 
> > public information. Any use of this information by anyone 
> other than 
> > the intended recipient is prohibited. If you have received this 
> > transmission in error, please immediately reply to the sender and 
> > delete this information from your system. Use, dissemination, 
> > distribution, or reproduction of this transmission by unintended 
> > recipients is not authorized and may be unlawful.
> 
> 
>