Re: [mif] Request for review - updated charter of MIF

Hui Deng <> Wed, 09 October 2013 15:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9A6B11E80F6 for <>; Wed, 9 Oct 2013 08:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mgravShIpxsD for <>; Wed, 9 Oct 2013 08:51:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c00::22e]) by (Postfix) with ESMTP id 4C4BA11E81AC for <>; Wed, 9 Oct 2013 08:51:14 -0700 (PDT)
Received: by with SMTP id j15so1079508qaq.19 for <>; Wed, 09 Oct 2013 08:51:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wPI4Hw0vlpOzlVTHO7nEOrjOdBC6KM7NtpKjRVYYTLI=; b=Mu7jvOAfWlEzWGRQ7RKjzqAV4Uxft7TFoe639VWHWU4uGDKMDx6PwnmZRFUdbBC1Dc FNkCHygdr/ODTyCRcdE3PDdDW4ABJ3XCn01kIuWEq4DKh5T6j9ls9UCGipc/fqUK5Bj5 sqA8F+CvU4S4/Rz0eyfqwO1U7l7uEEwOhr3If53QgTfSbm0nJjcOEHiCZ5i7m/4sdFh1 //a90jsefTTZHfr7KVw64kCoh2FPcijj15Rs7j/G56H1a7kgh6lje4p2SM7/COdtvvET MNF6aYLh3A5ihy2rKXiQae4lSOTT/k82OkFf91HBO5tLT05k7FoQFJYzYi8Qv5R64i9l 4kog==
MIME-Version: 1.0
X-Received: by with SMTP id w2mr10408557qeg.32.1381333873103; Wed, 09 Oct 2013 08:51:13 -0700 (PDT)
Received: by with HTTP; Wed, 9 Oct 2013 08:51:13 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 9 Oct 2013 23:51:13 +0800
Message-ID: <>
From: Hui Deng <>
To: Lorenzo Colitti <>
Content-Type: multipart/alternative; boundary=047d7bdc0c72d29b3b04e850da21
Cc: Margaret Wasserman <>, MIF Mailing List <>
Subject: Re: [mif] Request for review - updated charter of MIF
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Oct 2013 15:51:17 -0000


Let's speed up the architecture work, not discussing happy eyeball at this
only one work item will be added, I will post the latest one shortly,


2013/10/8 Lorenzo Colitti <>

> Hui,
> in general this seems fine to me, though I think it's a bit long and
> perhaps overspecified.
> One issue I have is that the charter explicitly lists the "MIF happy
> eyeballs document". I don't think the charter should list specific
> solutions; it should list the work that the group wants to do, but not
> explore solution space, because that's for the working group to decide
> during the course of the work. For example, what do we do if the multiple
> PVD architecture conflicts with the happy eyeballs extension document, or
> makes it obsolete? We'd need to approve a charter change in order to fix
> the problem.
> So I think the charter should not mention this specific solution. We can
> still keep that work on the charter without calling it out by name. All we
> need to do is reword the bullet point as a problem statement rather than a
> specific solution. For example: "4) Explore the use of heuristic mechanisms
> to improve interface selection".
> Another minor issue: where you say "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"
> you should at least list RA options as well.
> Cheers,
> Lorenzo
> On Mon, Oct 7, 2013 at 11:55 PM, Hui Deng <> wrote:
>> 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
>> -cochairs,
>> ---------------------------------------------
>> 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
>>  recommendations.
>>  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
>>  example:
>>  - 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
>>    information
>>  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.
>>  Milestones
>> 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.
>> _______________________________________________
>> mif mailing list