[mif] AD review of draft-ietf-mif-current-practices
Jari Arkko <jari.arkko@piuha.net> Fri, 01 October 2010 18:44 UTC
Return-Path: <jari.arkko@piuha.net>
X-Original-To: mif@core3.amsl.com
Delivered-To: mif@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E75EE3A6D51 for <mif@core3.amsl.com>; Fri, 1 Oct 2010 11:44:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.444
X-Spam-Level:
X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GF-dGqjblmoo for <mif@core3.amsl.com>; Fri, 1 Oct 2010 11:44:40 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id C3F503A6DF2 for <mif@ietf.org>; Fri, 1 Oct 2010 11:44:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6A4CE2CC43; Fri, 1 Oct 2010 21:45:26 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS0WRqyU8kEg; Fri, 1 Oct 2010 21:45:25 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 556552CC30; Fri, 1 Oct 2010 21:45:25 +0300 (EEST)
Message-ID: <4CA62C43.5080105@piuha.net>
Date: Fri, 01 Oct 2010 21:45:23 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: mif <mif@ietf.org>, draft-ietf-mif-current-practices@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [mif] AD review of draft-ietf-mif-current-practices
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Oct 2010 18:44:43 -0000
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
- [mif] AD review of draft-ietf-mif-current-practic… Jari Arkko
- Re: [mif] AD review of draft-ietf-mif-current-pra… pierrick.seite
- Re: [mif] AD review of draft-ietf-mif-current-pra… pierrick.seite
- Re: [mif] AD review of draft-ietf-mif-current-pra… Stefano Faccin
- Re: [mif] AD review of draft-ietf-mif-current-pra… stefano faccin
- Re: [mif] AD review of draft-ietf-mif-current-pra… pierrick.seite
- Re: [mif] AD review of draft-ietf-mif-current-pra… pierrick.seite
- Re: [mif] AD review of draft-ietf-mif-current-pra… Stefano Faccin
- Re: [mif] AD review of draft-ietf-mif-current-pra… pierrick.seite
- Re: [mif] AD review of draft-ietf-mif-current-pra… Stefano Faccin
- Re: [mif] AD review of draft-ietf-mif-current-pra… pierrick.seite
- Re: [mif] AD review of draft-ietf-mif-current-pra… pierrick.seite
- Re: [mif] AD review of draft-ietf-mif-current-pra… pierrick.seite
- [mif] AD review of draft-ietf-mif-current-practic… Jari Arkko
- Re: [mif] AD review of draft-ietf-mif-current-pra… Ted Lemon
- Re: [mif] AD review of draft-ietf-mif-current-pra… teemu.savolainen
- Re: [mif] AD review of draft-ietf-mif-current-pra… pierrick.seite
- Re: [mif] AD review of draft-ietf-mif-current-pra… Ted Lemon
- [mif] prblem statement: DNS/captive portals - was… pierrick.seite
- Re: [mif] prblem statement: DNS/captive portals -… Hui Deng
- Re: [mif] prblem statement: DNS/captive portals -… pierrick.seite
- Re: [mif] prblem statement: DNS/captive portals -… Julien Laganier
- Re: [mif] prblem statement: DNS/captive portals -… Ted Lemon
- Re: [mif] prblem statement: DNS/captive portals -… pierrick.seite