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

From: <[email-masked]>
Date: Tue, 1 Feb 2011 15:41:41 +0100

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
> À : [email-masked]; [email-masked]
> 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 : [email-masked] [mailto:[email-masked]] De la part de
> Jari
> > Arkko
> > Envoyé : vendredi 1 octobre 2010 20:45
> > À : mif; [email-masked]
> > 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mif

---

From: "Stefano Faccin" <[email-masked]>
Date: Fri, 4 Feb 2011 13:32:00 -0600

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, <[email-masked]> wrote:

Hello Jari,

BR,
Pierrick

-- 
Stefano M. Faccin
==================
May the Force be with you

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

---

From: stefano faccin <[email-masked]>
Date: Fri, 4 Feb 2011 11:30:44 -0800

Hello all,

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, <[email-masked]> 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
>

---

From: <[email-masked]>
Date: Mon, 7 Feb 2011 09:39:45 +0100

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 : [email-masked] [mailto:[email-masked]] De la part de stefano faccin
Envoyé : vendredi 4 février 2011 20:31
À : [email-masked]; [email-masked]
Objet : Re: [mif] AD review of draft-ietf-mif-current-practices

Hello all,

Cheers,

Stefano

Hello Jari,

BR,
Pierrick

---

From: <[email-masked]>
Date: Mon, 7 Feb 2011 12:07:43 +0100

I forgot a clarifying question to you, Stefano:

You wrote:

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

But what happen if the user defined list of preferred SSID is empty? Does the blackberry build its own list of preferred SSIDs? If yes, how? According to our test, when the Blackberry manages to attach to SSID1, then SSID2, then SSID3 it seems that the preferred access is SSID1. Is it correct? 

Pierrick

De : SEITE Pierrick RD-RESA-REN 
Envoyé : lundi 7 février 2011 09:40
À : 'stefano faccin'; [email-masked]; [email-masked]
Objet : RE: [mif] AD review of draft-ietf-mif-current-practices

Hi Stefano,

BR,

Pierrick

Hello all,

Cheers,

Stefano

Hello Jari,

BR,
Pierrick

---

From: "Stefano Faccin" <[email-masked]>
Date: Mon, 7 Feb 2011 10:41:27 -0600

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: (972) 910 3451  

Internal: 820.63451

 : (510) 230 8422

www.rim.com <outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.rim.com> ; www.blackberry.com <outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.blackberry.com>  

  <http://www.blackberry.com/> 

P Consider the environment before printing.

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, February 07, 2011 12:40 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mif] AD review of draft-ietf-mif-current-practices

Hi Stefano,

BR,

Pierrick

Hello all,

Cheers,

Stefano

Hello Jari,

BR,
Pierrick

---

From: <[email-masked]>
Date: Mon, 7 Feb 2011 18:07:39 +0100

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:[email-masked]] 
Envoyé : lundi 7 février 2011 17:41
À : SEITE Pierrick RD-RESA-REN; [email-masked]; [email-masked]; [email-masked]
Objet : RE: [mif] AD review of draft-ietf-mif-current-practices

Pierrick,

Cheers,

Stefano Faccin

Standards Manager

Irving, Texas 75039 USA 
Office: (972) 910 3451  

Internal: 820.63451

 : (510) 230 8422

Hi Stefano,

BR,

Pierrick

Hello all,

Cheers,

Stefano

Hello Jari,

BR,
Pierrick

---

From: "Stefano Faccin" <[email-masked]>
Date: Mon, 7 Feb 2011 11:12:57 -0600

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: +1 972 910 3451 
BlackBerry: +1 510 230 8422 
[email-masked] 
Time zone: PST (GMT -8)

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 07, 2011 11:07 AM
To: Stefano Faccin; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]> 
Subject: RE: [mif] AD review of draft-ietf-mif-current-practices 

Pierrick 

Pierrick,

Cheers,

Stefano Faccin

Standards Manager

Irving, Texas 75039 USA 
Office: (972) 910 3451  

Internal: 820.63451

: (510) 230 8422

Hi Stefano,

Thanks for your comments, I’ll update the draft accordingly. BTW, do you have information on the following points for RIM blackberry:

BR,

Pierrick

Hello all,

Cheers,

Stefano

Hello Jari,

BR,
Pierrick

---

From: <[email-masked]>
Date: Mon, 7 Feb 2011 18:14:45 +0100

Thanks for clarification. I'll submitted the updated version soon.

Pierrick

De : Stefano Faccin [mailto:[email-masked]] 
Envoyé : lundi 7 février 2011 18:13
À : SEITE Pierrick RD-RESA-REN; [email-masked]; [email-masked]; [email-masked]
Objet : Re: [mif] AD review of draft-ietf-mif-current-practices

Pierrick,

Stefano M. Faccin 

Standards Manager 
Research In Motion 

Pierrick 

Pierrick,

Cheers,

Stefano Faccin

Standards Manager

Irving, Texas 75039 USA 
Office: (972) 910 3451  

Internal: 820.63451

 : (510) 230 8422

Hi Stefano,

BR,

Pierrick

Hello all,

Cheers,

Stefano

Hello Jari,

BR,
Pierrick

---

From: <[email-masked]>
Date: Mon, 14 Feb 2011 15:26:05 +0100

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

Pierrick,

Stefano M. Faccin 

Standards Manager 
Research In Motion 

Pierrick 

Pierrick,

Cheers,

Stefano Faccin

Standards Manager

Irving, Texas 75039 USA 
Office: (972) 910 3451  

Internal: 820.63451

 : (510) 230 8422

Hi Stefano,

BR,

Pierrick

Hello all,

Cheers,

Stefano

Hello Jari,

BR,
Pierrick

---

From: <[email-masked]>
Date: Mon, 28 Feb 2011 15:48:40 +0100

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

> De : Dan Wing [mailto:[email-masked]] 
> Envoyé : jeudi 24 février 2011 00:55
> À : SEITE Pierrick RD-RESA-REN
> 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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of 
> > [email-masked]
> > Sent: Monday, February 14, 2011 6:26 AM
> > To: [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]; [email-masked]
> > 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>
> > 
> > 
> > 
> > -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:[email-masked]] Envoyé : lundi 
> 7 février 
> > 2011 18:13 À : SEITE Pierrick RD-RESA-REN; [email-masked]; 
> > [email-masked]; [email-masked] Objet : Re: [mif] AD review of 
> > draft-ietf-mif-current-practices
> > 
> > 
> > 
> > Pierrick,
> > From: [email-masked] 
> [mailto:pierrick.seite@orange- 
> > ftgroup.com]
> > To: Stefano Faccin; [email-masked] <[email-masked]>; 
> > [email-masked] <[email-masked]>; [email-masked] 
> > <[email-masked]>
> > 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:[email-masked]] Envoyé : lundi 
> 7 février 
> > 2011 17:41 À : SEITE Pierrick RD-RESA-REN; [email-masked]; 
> > [email-masked]; [email-masked] 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
> > 
> > Untitled-1: (510) 230 8422
> > 
> > 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:[email-masked] <http://www.blackberry.com/>
> > 
> > 
> > 
> > From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of 
> > [email-masked]
> > Thanks for your comments, I'll update the draft 
> accordingly. BTW, do 
> > you have information on the following points for RIM blackberry:
> > 
> > 
> > 
> > - 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
> > 
> > 
> > 
> > 
> > 
> > stefano faccin Envoyé : vendredi 4 février 2011 20:31 À : 
> > [email-masked]; [email-masked] Objet : Re: [mif] AD review of 
> > draft-ietf-mif-current-practices
> > 
> > 
> > 
> > Hello all,
> > 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
> > 
> > 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
> > 
> > > Envoyé : samedi 23 octobre 2010 12:01 À : [email-masked]; 
> > > [email-masked] 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
> > > I'll align the linux section in the next version), but what about 
> > > the others (nokia, blackberry, windows mobile, android)?
> > >
> > > 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
> > 
> > > 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.
> > >
> > > specific implementations) manages multiple interfaces 
> issues in the
> > same
> > > > De : [email-masked] [mailto:[email-masked]] 
> De la part
> > de
> > > Jari
> > > > Arkko
> > > > Envoyé : vendredi 1 octobre 2010 20:45 À : mif; 
> > > > [email-masked]
> > > > 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
> > > > description is detailed and informative. I would 
> suggest that some
> > of
> > > > Section 3.1.3 s/in a MIF context/here/ (the MIF context 
> is a fine
> > term
> > > I agree that the original text was unclear. I've revised 
> the section
> > but
> > > > 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
> > > > can use different networks simultaneously?`Please be 
> more precise
> > about
> > > > possibility of some policy being sent from the network, whether 
> > > > DNS
> > info
> > > > get information, but at least some of these devices are open 
> > > > source
> > and
> > > I guess you are referencing to android terminals; I was also 
> > > thinking
> > that
> > > functionalities but it seems that the situation is more complex. 
> > > It's
> > true
> > > customized by vendors. So we sometimes experience different 
> > > behaviour between different android terminals. For instance, some 
> > > android
> > terminal
> > > while all these functions are well supported on a Linux 
> laptop. Note
> > that
> > > > >       Whatever is the handset, fallback on L3 
> attachment failure
> > is
> > > not
> > > > >       considering IP configuration results.  In other 
> words, if
> > the
> > 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.
> 
> 
>