Re: [mif] MIF API - Access Network Selection

Ted Lemon <Ted.Lemon@nominum.com> Thu, 02 August 2012 16:21 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAEA11E80E9 for <mif@ietfa.amsl.com>; Thu, 2 Aug 2012 09:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.554
X-Spam-Level:
X-Spam-Status: No, score=-106.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2p5Ncrtg1OQ3 for <mif@ietfa.amsl.com>; Thu, 2 Aug 2012 09:21:51 -0700 (PDT)
Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8FF11E808E for <mif@ietf.org>; Thu, 2 Aug 2012 09:21:50 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUBqpHSW3j/+4XHDsnc2ehtYDW7SpJ8ce@postini.com; Thu, 02 Aug 2012 09:21:50 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 33D2F1B8303 for <mif@ietf.org>; Thu, 2 Aug 2012 09:21:49 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2A77D190060 for <mif@ietf.org>; Thu, 2 Aug 2012 09:21:49 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 2 Aug 2012 09:21:49 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: List List <mif@ietf.org>
Thread-Topic: MIF API - Access Network Selection
Thread-Index: AQHNcCpCx3vi/hqDfku3VfHWCfpMfZdF6s2AgAADtACAAAk5gIAAuCoAgAB69YA=
Date: Thu, 02 Aug 2012 16:21:48 +0000
Message-ID: <49B86DE2-4CDB-42D0-9AF9-25E56F89E0D4@nominum.com>
References: <CAC8QAccpQTO2u2z00r-s_hc_bA+usFKnHN-zfMOMvnbnc3kE6g@mail.gmail.com> <086FCD42-FC16-4F24-8032-7F763731BB2B@nominum.com> <CAC8QAcdG2cZiWPmrELP5Jm4DYXME2ZxC1cS_LA8txKubsMayeg@mail.gmail.com> <037E6537-B7EF-449A-8581-864C798171A2@nominum.com> <2970_1343898105_501A41F9_2970_1111_1_81C77F07008CA24F9783A98CFD706F7102F8B0@PEXCVZYM12.corporate.adroot.infra.ftgroup>
In-Reply-To: <2970_1343898105_501A41F9_2970_1111_1_81C77F07008CA24F9783A98CFD706F7102F8B0@PEXCVZYM12.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_49B86DE24CDB42D09AF925E56F89E0D4nominumcom_"
MIME-Version: 1.0
Subject: Re: [mif] MIF API - Access Network Selection
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 02 Aug 2012 16:21:52 -0000

On Aug 2, 2012, at 2:01 AM, <pierrick.seite@orange.com<mailto:pierrick.seite@orange.com>> <pierrick.seite@orange.com<mailto:pierrick.seite@orange.com>> wrote:
Full specification of a Connection manager is out of the IETF scope,  but it is expected from the MIF API to provide information and functionalities that a connection manager may need. On the other hand,  I think that ongoing work in MIF ( implementation guideline or specification of the high-level API) may provide guidance on how a connection manager should use the MIF API .

In fact, the current work on the MIF API is assuming that the connection manager may use, and indeed _require_ features of the operating system which are not exposed in the MIF API.   The reason for this division is that it's expected that the vendor of a device or operating system will almost certainly have a single connection manager that controls the connections of the machine, and that there is no way to anticipate the context in which this connection manager will operate.   So its deliverables are fairly clear, but its requirements are clear as mud.

If this is not in fact the consensus of the working group, then people who know more about how connection managers work (if there are any who can participate) should be proposing additional API messages.

For my part, I think that we have a pretty clear and manageable job to do if we just solve the problem of providing the minimal functionality that a high-level API or smart application would need.