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

From: Jari Arkko <[email-masked]>
Date: Fri, 01 Oct 2010 21:45:23 +0300

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

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

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

> iPhone
> Iphone
Inconsistent capitalization.

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

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.

> in the scope of MIF.

... in the scope of this document.

Jari

---

From: <[email-masked]>
Date: Sat, 23 Oct 2010 12:00:57 +0200

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
> 

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.    

> 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
> what is actually happening, as opposed to claiming a general capability.

Ok, text has been revised.

> 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
> work for the manufacturers.

Yep, we need additional information from vendors.... 

> Inconsistent capitalization.

Fixed

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

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

Ok, fixed

> Jari
> 
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif