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

Hui Deng <denghui02@gmail.com> Wed, 09 October 2013 15:51 UTC

Return-Path: <denghui02@gmail.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 D9A6B11E80F6 for <mif@ietfa.amsl.com>; Wed, 9 Oct 2013 08:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgravShIpxsD for <mif@ietfa.amsl.com>; Wed, 9 Oct 2013 08:51:15 -0700 (PDT)
Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4BA11E81AC for <mif@ietf.org>; Wed, 9 Oct 2013 08:51:14 -0700 (PDT)
Received: by mail-qa0-f46.google.com with SMTP id j15so1079508qaq.19 for <mif@ietf.org>; Wed, 09 Oct 2013 08:51:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.49.27.226 with SMTP id w2mr10408557qeg.32.1381333873103; Wed, 09 Oct 2013 08:51:13 -0700 (PDT)
Received: by 10.49.16.41 with HTTP; Wed, 9 Oct 2013 08:51:13 -0700 (PDT)
In-Reply-To: <CAKD1Yr26ufOxDcUric21-XASCb8pZLhX7-uw1VCc_wPDDNBJQA@mail.gmail.com>
References: <CANF0JMCW1A7hrytd15qgK0hEe3PnY6hosBc2pTYMhto9MyEogA@mail.gmail.com> <CAKD1Yr26ufOxDcUric21-XASCb8pZLhX7-uw1VCc_wPDDNBJQA@mail.gmail.com>
Date: Wed, 9 Oct 2013 23:51:13 +0800
Message-ID: <CANF0JMDLPjhoCj5sXw2X1FoUCEMrJUy6EpG1ZEsb9jCYAwFB1w@mail.gmail.com>
From: Hui Deng <denghui02@gmail.com>
To: Lorenzo Colitti <lorenzo@google.com>
Content-Type: multipart/alternative; boundary=047d7bdc0c72d29b3b04e850da21
Cc: Margaret Wasserman <margaretw42@gmail.com>, MIF Mailing List <mif@ietf.org>
Subject: Re: [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: Wed, 09 Oct 2013 15:51:17 -0000

Lorenzo,

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

-Hui


2013/10/8 Lorenzo Colitti <lorenzo@google.com>

> 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 <denghui02@gmail.com> 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
>> mif@ietf.org
>> https://www.ietf.org/mailman/listinfo/mif
>>
>>
>