[mif] Request for review - updated charter of MIF

Hui Deng <denghui02@gmail.com> Mon, 07 October 2013 14:55 UTC

Return-Path: <denghui02@gmail.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E254321E80AF for <mif@ietfa.amsl.com>; Mon, 7 Oct 2013 07:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id FGKrR95HygIj for <mif@ietfa.amsl.com>; Mon, 7 Oct 2013 07:55:57 -0700 (PDT)
Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id B8C8311E80EC for <mif@ietf.org>; Mon, 7 Oct 2013 07:55:52 -0700 (PDT)
Received: by mail-qe0-f49.google.com with SMTP id s14so5257785qeb.8 for <mif@ietf.org>; Mon, 07 Oct 2013 07:55:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HT2hr2PZP4EuFV8qMt6eJo9cKqT6KNuHe+FfQQj+B48=; b=IAq6cLiSiI46rGsULLZBluyoM1YWwE1z/yFeP/eLMKZqFVkGmeSwnoSwuAZGIdYOsK q86KltsqrvwI6QZU6Iih4UNBwKdrGZ4evi5yzZzVm/uD3q1Y7uijw/toDLmwyfM7jxVT n4z9ND2d7lL6jcvV4n7TbDhEUSIr/1Z9s9bKZMoTSMTdlHxahn4TeNbNsSYOBCz4ZnT6 vbADFXdCIsHd116A+Iaj4Xbjvuy6FYCoKExRgfPmcGoDnV9IPO+sB3LRMQ+YTGkzq8Jd Iqo78pFdrsE1CQPfnRscb8QqvwSTQG+krgxK2fh5nzojySCJ06zh9trvQIVQ4hV4eiXS W1Tw==
MIME-Version: 1.0
X-Received: by with SMTP id c12mr2926308qaw.94.1381157752162; Mon, 07 Oct 2013 07:55:52 -0700 (PDT)
Received: by with HTTP; Mon, 7 Oct 2013 07:55:52 -0700 (PDT)
Date: Mon, 7 Oct 2013 22:55:52 +0800
Message-ID: <CANF0JMCW1A7hrytd15qgK0hEe3PnY6hosBc2pTYMhto9MyEogA@mail.gmail.com>
From: Hui Deng <denghui02@gmail.com>
To: MIF Mailing List <mif@ietf.org>, Margaret Wasserman <margaretw42@gmail.com>, Ted Lemon <Ted.Lemon@nominum.com>
Content-Type: multipart/alternative; boundary=089e014938ec324f6504e827d933
Subject: [mif] Request for review - updated charter of MIF
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: Mon, 07 Oct 2013 14:55:59 -0000

Hello all,

Based on last IETF MIF meeting and regular teleconf of MIF design team,
below charter has been proposed, please feel free to comment on it

Many thanks



Charter for Working Group

 Nodes attached to multiple networks may encounter problems due to
 conflict of the networks configuration  and/or simultaneous use of
 the multiple available networks. This can happen over multiple
 physical network interfaces, a combination of physical and virtual
 interfaces (VPNs or tunnels), or even indirectly through multiple
 default routers being on the same link. For instance, current laptops
 and smartphones typically have multiple access network interfaces.

 The MIF problem statement document [RFC6418] enumerate the problems
 into 3 categories
 1.  Lack of consistent and distinctive management of configuration
     elements, associated with different networks.
 2.  Inappropriate mixed use of configuration elements, associated
     with different networks, in the course of a particular network
     activity / connection.
 3.  Use of a particular network, not consistent with the intent of
     the scenario / involved parties, leading to connectivity failure
     and / or other undesired consequences.

 A number of operating systems have implemented various techniques
 ([RFC6419])to deal with attachments to multiple networks. Some devices
 employ only one interface at a time and some allow per-host
 configuration of preferences between the interfaces but still use just
 one at a time. Other systems allow per-application preferences or
 implement sophisticated policy managers that can be configured by users
 or controlled externally. In many cases the issues may still appear.

 The purpose of the MIF working group is to describe the architecture
 attaching to multiple provisioning domains.  The group shall also analyze
 that applications will be influenced by these existing mechanisms.
 The WG shall employ and refer to existing IETF work in this area,
 including, for instance, strong/weak models (RFC 1122), address selection
 (RFC 3484), ICE and other mechanisms higher layers can use for address
 selection, DHCP mechanisms, Router Advertisement mechanisms, and DNS

 1) Handling sets of network configuration objects by nodes, attached to
 multiple networks: a solution could include a set of requirements for
 changes to protocols used to provide configuration information. For
 - requirements for DHCPv6 options, Neighbor Discovery options etc. to
   communicate association of the objects with particular
   provisioning domains
 - best practices for nodes how to group the configuration objects
   into sets and use them for network connectivity
 - APIs to expose the sets to the applications which require that
 2) MIF API: While no changes are required for applications to run on
 multiple interface hosts, a new API could provide additional services
 to applications running on hosts attached to multiple provisioning
 domains. For instance, these services could assist advanced
 applications in having greater control over first-hop, source address
 and/or DNS selection, interface selection, and PVD selection issues.
 This API will be defined as an abstract interface specification,
 i.e., specific details about mapping to operating system primitives
 or programming language will be left out.
 3) MIF API Session Continuity: There are several classes of
 applications that would desire session continuity in the presence of
 changing connectivity and multiple attachments. An informational
 document will recommend some basic steps that applications can follow in
 order to maintain session continuity to improve user experience by using
 the aforementioned MIF API interfaces.
 4) MIF Happyeyeball: Sometime host prefer to use only one interface
 for the sesson, a mechanism to make the interface selection process
 smoother by using some heuristical information.

 Network discovery and selection on lower layers as defined by RFC 5113
 is out of scope. With the exception of support for additional DHCP
 options in DHCP servers, group shall not assume any software beyond
 basic IP protocol support on its peers or in network nodes. No work
 will be done to enable traffic flows to move from one interface to
 another. The group recognizes existing work on mechanisms that require
 peer or network support for moving traffic flows such as RFC 5206, RFC
 4980 and the use of multiple care-of addresses in Mobile IPv6. This
 group does not work on or impact such mechanisms.
 Future work in this area requires rechartering the working group or
 asking other, specialized working groups (such as DHC or 6MAN) to deal
 with specific issues.


Jan 2011
Analysis draft submitted to the IESG for publication as an Informational RFC

Mar 2011
Submit MIF API extension solution to IESG for publication as an
Informational RFC

Nov 2011
Submit advanced DNS server selection solution to IESG for publication as a
Proposed Standard RFC

Nov 2013
Architecture draft adopted as the working group document
Nov 2013
session continuity adopted as the working group document
Dec 2013
Working group last call for MIF API document
Dec 2013
working group last call for MIF Happy eyeball document.