From Dmitry.Anipko@microsoft.com Mon Nov 4 20:08:14 2013 Return-Path: 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 990AD21E80A1; Mon, 4 Nov 2013 20:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Ecipa3KdNCKw; Mon, 4 Nov 2013 20:08:10 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0154.outbound.protection.outlook.com [207.46.163.154]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4E811E80E9; Mon, 4 Nov 2013 20:08:04 -0800 (PST) Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB080.namprd03.prod.outlook.com (10.255.175.156) with Microsoft SMTP Server (TLS) id 15.0.815.6; Tue, 5 Nov 2013 04:08:03 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.119]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.119]) with mapi id 15.00.0815.000; Tue, 5 Nov 2013 04:08:02 +0000 From: Dmitry Anipko To: "mif-arch-dt@ietf.org" , "mif@ietf.org" Thread-Topic: New Version Notification for draft-anipko-mif-mpvd-arch-05.txt Thread-Index: AQHO2dxnq5SyfQx/T06W71OEUfP5lZoWBR/j Date: Tue, 5 Nov 2013 04:08:01 +0000 Message-ID: References: <20131105040622.10133.16800.idtracker@ietfa.amsl.com> In-Reply-To: <20131105040622.10133.16800.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] x-forefront-prvs: 0021920B5A x-forefront-antispam-report: SFV:NSPM; SFS:(69234005)(189002)(199002)(377424004)(377454003)(69226001)(2656002)(81342001)(81542001)(33646001)(85306002)(74876001)(74706001)(51856001)(46102001)(54316002)(50986001)(47976001)(47736001)(49866001)(56776001)(4396001)(15975445006)(54356001)(53806001)(15202345003)(74316001)(31966008)(87266001)(74502001)(74662001)(47446002)(79102001)(80022001)(83072001)(65816001)(77096001)(19580405001)(19580395003)(81816001)(83322001)(74366001)(80976001)(59766001)(76576001)(77982001)(63696002)(76482001)(81686001)(56816003)(76786001)(76796001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB080; H:SN2PR03MB077.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::3; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [mif] FW: New Version Notification for draft-anipko-mif-mpvd-arch-05.txt X-BeenThere: mif@ietf.org 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: Tue, 05 Nov 2013 04:08:14 -0000 FYI, I've posted new arch draft revision with the contributions from the de= sign team on security considerations and DHCP/ND considerations.=0A= =0A= -Dmitry=0A= ________________________________________=0A= From: internet-drafts@ietf.org =0A= Sent: Monday, November 04, 2013 8:06 PM=0A= To: Dmitry Anipko=0A= Subject: New Version Notification for draft-anipko-mif-mpvd-arch-05.txt=0A= =0A= A new version of I-D, draft-anipko-mif-mpvd-arch-05.txt=0A= has been successfully submitted by Dmitry Anipko and posted to the=0A= IETF repository.=0A= =0A= Filename: draft-anipko-mif-mpvd-arch=0A= Revision: 05=0A= Title: Multiple Provisioning Domain Architecture=0A= Creation date: 2013-11-04=0A= Group: Individual Submission=0A= Number of pages: 16=0A= URL: http://www.ietf.org/internet-drafts/draft-anipko-mif-mpvd-= arch-05.txt=0A= Status: http://datatracker.ietf.org/doc/draft-anipko-mif-mpvd-arch= =0A= Htmlized: http://tools.ietf.org/html/draft-anipko-mif-mpvd-arch-05= =0A= Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-anipko-mif-mpvd-a= rch-05=0A= =0A= Abstract:=0A= This document is a product of the work of MIF architecture design=0A= team. It outlines a solution framework for some of the issues,=0A= experienced by nodes that can be attached to multiple networks. The=0A= framework defines the notion of a Provisioning Domain (PVD) - a=0A= consistent set of network configuration information, and PVD-aware=0A= nodes - nodes which learn PVDs from the attached network(s) and/or=0A= other sources and manage and use multiple PVDs for connectivity=0A= separately and consistently.=0A= =0A= =0A= =0A= =0A= Please note that it may take a couple of minutes from the time of submissio= n=0A= until the htmlized version and diff are available at tools.ietf.org.=0A= =0A= The IETF Secretariat=0A= =0A= From brian.e.carpenter@gmail.com Thu Nov 7 13:58:28 2013 Return-Path: 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 D5FE111E82A4 for ; Thu, 7 Nov 2013 13:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, 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 eOVkeO3bmbmP for ; Thu, 7 Nov 2013 13:58:28 -0800 (PST) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C2DAD11E82A6 for ; Thu, 7 Nov 2013 13:54:55 -0800 (PST) Received: by mail-bk0-f45.google.com with SMTP id r7so474327bkg.32 for ; Thu, 07 Nov 2013 13:54:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=FwaOwxe22vBYiIhRjQajjJC9LFWhuBrslpKpq0NDZJU=; b=eJJ4DGWYJftpyjbL1a+U1f27H7Viyve1Vl8bNt3sTaFxaLCXOQugbSZfXZB0PAfzhn yxW+x4o16K5xC47vqvbudcS/mTW4k3sbOSmnie/1X5lxUZfKTlvTvHBaDiqisLCUZ0zs 4/e76b0Oz5/nSbOcwe8H1flJ/mqt5n9l6HpGNlI0BMjZRpdP6Xbntga7KHibLnJVAsm9 5Wz1mifSbd1dGe+pinoLKTwxuK+4i24biYZ7XRDsmOuvMolg0ik+aAX+o+o19LHFceP7 YvCRFxSbbWnTfKTYLbmCy1wTtSmQaW6dvq/yNyZ73FjtciGgXjl2Z3zwNmVT0ufApjIT 2VwA== X-Received: by 10.204.105.198 with SMTP id u6mr8028952bko.19.1383861294809; Thu, 07 Nov 2013 13:54:54 -0800 (PST) Received: from [31.133.165.38] (dhcp-a526.meeting.ietf.org. [31.133.165.38]) by mx.google.com with ESMTPSA id l9sm3674036bkg.0.2013.11.07.13.54.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 13:54:54 -0800 (PST) Message-ID: <527C0C36.1050008@gmail.com> Date: Fri, 08 Nov 2013 10:55:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: mif@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [mif] Generalising PVD IDs X-BeenThere: mif@ietf.org 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: Thu, 07 Nov 2013 21:58:29 -0000 I suggested that PVD IDs are a subset of a more general need, which is IDs for a reachable address scope. The notion of address scope that I have in mind was discussed in a couple of expired drafts: http://tools.ietf.org/html/draft-carpenter-grobj-reqts-00#section-2 A much older draft actually proposed a specific format for a ScopeID, namely an imaginary IPv6 address under a ULA prefix. I don't stand by that, but you can find it in http://tools.ietf.org/html/draft-carpenter-behave-referral-object-00#section-4.10. Regards Brian From denghui02@gmail.com Thu Nov 7 15:50:25 2013 Return-Path: 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 5D06121E80DB for ; Thu, 7 Nov 2013 15:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.32 X-Spam-Level: X-Spam-Status: No, score=-102.32 tagged_above=-999 required=5 tests=[AWL=0.279, 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 w07SXOXY5gFI for ; Thu, 7 Nov 2013 15:50:24 -0800 (PST) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 714F111E817A for ; Thu, 7 Nov 2013 15:50:23 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id ie18so902859vcb.37 for ; Thu, 07 Nov 2013 15:50:20 -0800 (PST) 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=JlKVnsYkKsKs7H0db27ql6guMgRwSeBCpEh56aHkN6A=; b=IyTXJWxA/MCCcbUBDfd4Fv52b5OQpnsq7YFwRhMOukEmuTo+s+wo1w7qT8JUM+BMPl 6O/lhE9ib8y9SPKwAp31NsqSyhkDlE4wcjLZ/JQZEcyxfrb4zs7gi78FkaD2U26JR/VM nJ1RsECJpb8HF8CUJx6mqiawegtxFaRlGjproNv6arIzPqU0TpkZAjjyfEjM3UjYFG3Q nTbUVvVjygYLtwz9m+QZZc7R8XjQAgXKK+QibQIeStGRiLCbYjou4J7D7enVkmO1TxfA h/Qpq1vNrtejLs2cR6ys3MUYDfqzyo4G6kQFnIr1A7SyS5sw+PF7Kik3r+cKsy1o6UsE emTA== MIME-Version: 1.0 X-Received: by 10.221.64.17 with SMTP id xg17mr8966349vcb.5.1383868220750; Thu, 07 Nov 2013 15:50:20 -0800 (PST) Received: by 10.220.69.13 with HTTP; Thu, 7 Nov 2013 15:50:20 -0800 (PST) Date: Thu, 7 Nov 2013 15:50:20 -0800 Message-ID: From: Hui Deng To: MIF Mailing List , Margaret Wasserman Content-Type: multipart/alternative; boundary=001a1133158eb6c21704ea9eedbb Subject: [mif] MIF charter update LC X-BeenThere: mif@ietf.org 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: Thu, 07 Nov 2013 23:50:25 -0000 --001a1133158eb6c21704ea9eedbb Content-Type: text/plain; charset=ISO-8859-1 Hello all. >From the working group discussion, we have a quite concensus on the charter update, here we conform again in the list. thanks a lot for your help Cochairs -------------------------------------------------------------- Nodes attached to multiple networks may encounter problems due to conflict of network configuration information 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] enumerates 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. The purpose of the MIF working group is to describe the architecture detailing how devices attach to and operate in multiple networks. The group shall also analyze how applications can 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), default address selection (RFC 6724), ICE and other mechanisms higher layers can use for address selection, DHCP mechanisms, Router Advertisement mechanisms, and DNS recommendations. The focus of the working group should be on documenting the system level effects to host IP stacks and identification of gaps between the existing IETF recommendations and existing practice. Having completed some of its initial goals the group is also developing the following: 1. An incrementally deployable architecture, defining a consistent approach and recommended practices for handling sets of network configuration objects by hosts, attached to multiple networks, which enable hosts to improve network connectivity for the host's applications and users. 2. A set of requirements for changes to or the uses of protocols, that provide network configuration information, to enable improved handling of multiple sets of network configuration in networks and hosts. For example, requirements for DHCPv6 options, Neighbor Discovery options etc. to communicate association of the configuration information with particular networks. 3. In cooperation with other working groups, uses of existing protocols in accordance with the requirements produced under item 2. Any changes of function of protocols are out of scope. 4. A 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 networks. For instance, these services could assist advanced applications in having greater control over first-hop, source address and/or DNS resolver, interface and other network configuration element selection. This API will be defined as an abstract interface specification, i.e., specific details about mapping to operating system primitives or programming languages will be left out. In addition to the new API, the behavior of existing APIs may be changed to improve the behavior of unmodified applications. 5. Guidelines to applications, to provide an improved connectivity experience when the host is attached to multiple networks or there is a change in the set of networks the host is attached to, e.g., via MIF API usage. 6. A specification for the format, generation and usage of PVD IDs. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. With the exception of identifying requirements for additional DHCPv6 and/or ND options, as well as requirements for possible related changes in these protocols, the group shall not assume any software beyond basic IP protocol support on its peers or in network hosts. 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. --001a1133158eb6c21704ea9eedbb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all.
=A0
From the working g= roup discussion, we have a quite concensus on the charter update, here we c= onform again in the list.
=A0
thanks a lot for your he= lp
=A0
Cochairs
=A0
-----------------------= ---------------------------------------
=A0
Nodes attac= hed to multiple networks may encounter problems due to conflict of network = configuration information and/or simultaneous use of the multiple available= networks. This can happen over multiple physical network interfaces, a com= bination of physical and virtual interfaces (VPNs or tunnels), or even indi= rectly through multiple default routers being on the same link. For instanc= e, current laptops and smartphones typically have multiple access network i= nterfaces.
=A0
=A0
The MIF problem statement document [RFC641= 8] enumerates 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 diffe= rent networks, in the course of a particular network activity / connection.=
3. Use of a particular network, not consistent with the intent of the s= cenario / involved parties, leading to connectivity failure and / or other = undesired consequences.
=A0
=A0
The purpose of the MIF working group is to= describe the architecture detailing how devices attach to and operate in m= ultiple networks. The group shall also analyze how applications can be infl= uenced by these existing mechanisms. The WG shall employ and refer to exist= ing IETF work in this area, including, for instance, strong/weak models (RF= C 1122), default address selection (RFC 6724), ICE and other mechanisms hig= her layers can use for address selection, DHCP mechanisms, Router Advertise= ment mechanisms, and DNS recommendations. The focus of the working group sh= ould be on documenting the system level effects to host IP stacks and ident= ification of gaps between the existing IETF recommendations and existing pr= actice. Having completed some of its initial goals the group is also develo= ping the following:
=A0
=A0
1. An incrementally deployable architectur= e, defining a consistent approach and recommended practices for handling se= ts of network configuration objects by hosts, attached to multiple networks= , which enable hosts to improve network connectivity for the host's app= lications and users.
=A0
=A0
2. A set of requirements for changes=A0 to= or the uses of protocols, that provide network configuration=A0 informatio= n, to enable improved handling of multiple sets of network configuration in= networks and hosts. For example, requirements for DHCPv6 options, Neighbor= Discovery options etc. to communicate association of the configuration inf= ormation with particular networks.
=A0
=A0
3. In cooperation with other working group= s, uses of existing protocols in accordance with the requirements produced = under item 2. Any changes of function of protocols are out of scope.
<= div> =A0
=A0
4. A MIF API: While no changes are required for= applications to run on multiple interface hosts, a new API could provide a= dditional services to applications running on hosts attached to multiple ne= tworks. For instance, these services could assist advanced applications in = having greater control over first-hop, source address and/or DNS resolver, = interface and other network configuration element selection. This API will = be defined as an abstract interface specification, i.e., specific details a= bout mapping to operating system primitives or programming languages will b= e left out. In addition to the new API, the behavior of existing APIs may b= e changed to improve the behavior of unmodified applications.
=A0
=A0
5. Guidelines to applications, to provide = an improved connectivity experience when the host is attached to multiple n= etworks or there is a change in the set of networks the host is attached to= , e.g., via MIF API usage.
=A0
=A0
6. A specification for the format, generat= ion and usage of PVD IDs.
=A0
=A0
Network di= scovery and selection on lower layers as defined by RFC 5113 is out of scop= e. With the exception of identifying requirements for additional DHCPv6 and= /or ND options, as well as requirements for possible related changes in the= se protocols, the group shall not assume any software beyond basic IP proto= col support on its peers or in network hosts. No work will be done to enabl= e traffic flows to move from one interface to another. The group recognizes= existing work on mechanisms that require peer or network support for movin= g 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 mechan= isms.=A0 Future work in this area requires rechartering the working group o= r asking other, specialized working groups (such as DHC or 6MAN) to deal wi= th specific issues.
=A0
--001a1133158eb6c21704ea9eedbb-- From alexandru.petrescu@gmail.com Thu Nov 7 15:59:27 2013 Return-Path: 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 D1BAF11E814F for ; Thu, 7 Nov 2013 15:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.254 X-Spam-Level: X-Spam-Status: No, score=-10.254 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, WEIRD_PORT=0.001] 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 T54N0chWtT-H for ; Thu, 7 Nov 2013 15:59:22 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8C621F9D09 for ; Thu, 7 Nov 2013 15:59:21 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rA7NxK59009545 for ; Fri, 8 Nov 2013 00:59:20 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 736642051B5 for ; Fri, 8 Nov 2013 00:59:25 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6ACF1205183 for ; Fri, 8 Nov 2013 00:59:25 +0100 (CET) Received: from [127.0.0.1] ([132.166.86.1]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rA7NxEUr008556 for ; Fri, 8 Nov 2013 00:59:19 +0100 Message-ID: <527C2952.5020705@gmail.com> Date: Fri, 08 Nov 2013 00:59:14 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: mif@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] MIF charter update LC X-BeenThere: mif@ietf.org 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: Thu, 07 Nov 2013 23:59:28 -0000 Hi, thanks, Following suggestion about the use of Etherpad I pasted it and it's there: http://etherpad.tools.ietf.org:9000/p/notes-ietf-88-mif?useMonospaceFont=true Alex Le 08/11/2013 00:50, Hui Deng a écrit : > Hello all. > From the working group discussion, we have a quite concensus on the > charter update, here we conform again in the list. > thanks a lot for your help > Cochairs > -------------------------------------------------------------- > Nodes attached to multiple networks may encounter problems due to > conflict of network configuration information 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] enumerates 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. > The purpose of the MIF working group is to describe the architecture > detailing how devices attach to and operate in multiple networks. The > group shall also analyze how applications can 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), > default address selection (RFC 6724), ICE and other mechanisms higher > layers can use for address selection, DHCP mechanisms, Router > Advertisement mechanisms, and DNS recommendations. The focus of the > working group should be on documenting the system level effects to host > IP stacks and identification of gaps between the existing IETF > recommendations and existing practice. Having completed some of its > initial goals the group is also developing the following: > 1. An incrementally deployable architecture, defining a consistent > approach and recommended practices for handling sets of network > configuration objects by hosts, attached to multiple networks, which > enable hosts to improve network connectivity for the host's applications > and users. > 2. A set of requirements for changes to or the uses of protocols, that > provide network configuration information, to enable improved handling > of multiple sets of network configuration in networks and hosts. For > example, requirements for DHCPv6 options, Neighbor Discovery options > etc. to communicate association of the configuration information with > particular networks. > 3. In cooperation with other working groups, uses of existing protocols > in accordance with the requirements produced under item 2. Any changes > of function of protocols are out of scope. > 4. A 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 networks. For > instance, these services could assist advanced applications in having > greater control over first-hop, source address and/or DNS resolver, > interface and other network configuration element selection. This API > will be defined as an abstract interface specification, i.e., specific > details about mapping to operating system primitives or programming > languages will be left out. In addition to the new API, the behavior of > existing APIs may be changed to improve the behavior of unmodified > applications. > 5. Guidelines to applications, to provide an improved connectivity > experience when the host is attached to multiple networks or there is a > change in the set of networks the host is attached to, e.g., via MIF API > usage. > 6. A specification for the format, generation and usage of PVD IDs. > Network discovery and selection on lower layers as defined by RFC 5113 > is out of scope. With the exception of identifying requirements for > additional DHCPv6 and/or ND options, as well as requirements for > possible related changes in these protocols, the group shall not assume > any software beyond basic IP protocol support on its peers or in network > hosts. 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. > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From Ted.Lemon@nominum.com Thu Nov 7 18:01:37 2013 Return-Path: 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 EBB9521E8178 for ; Thu, 7 Nov 2013 18:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.588 X-Spam-Level: X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, 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 v1b3IdSmVk+w for ; Thu, 7 Nov 2013 18:01:31 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id E257021E814C for ; Thu, 7 Nov 2013 18:01:20 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUnxFs3d2a8z59uQsIKFrdAx9Tv3vDEVf@postini.com; Thu, 07 Nov 2013 18:01:25 PST 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 290081B82E6 for ; Thu, 7 Nov 2013 18:00:19 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-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 EBBBB190043; Thu, 7 Nov 2013 18:00:16 -0800 (PST) (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.03.0158.001; Thu, 7 Nov 2013 18:00:17 -0800 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [mif] Generalising PVD IDs Thread-Index: AQHO3ASBM83RfGWE70+Hf84rir8GaJobGpuA Date: Fri, 8 Nov 2013 02:00:16 +0000 Message-ID: References: <527C0C36.1050008@gmail.com> In-Reply-To: <527C0C36.1050008@gmail.com> 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: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: MIF Mailing List Subject: Re: [mif] Generalising PVD IDs X-BeenThere: mif@ietf.org 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: Fri, 08 Nov 2013 02:01:38 -0000 PVD IDs should be something that can somehow be displayed in a menu, like S= SIDs. It may be that that works by having a text version and a machine ve= rsion, but there abide dragons. From brian.e.carpenter@gmail.com Thu Nov 7 18:15:37 2013 Return-Path: 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 9822921E812A for ; Thu, 7 Nov 2013 18:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, 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 GmZmDc7L0+k1 for ; Thu, 7 Nov 2013 18:15:35 -0800 (PST) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 72BD321E80A5 for ; Thu, 7 Nov 2013 18:15:35 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id mx11so538757bkb.31 for ; Thu, 07 Nov 2013 18:15:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tZj+6JapFvs7gFHnS2Nf/lYmYWfT8JLvrUCM90z/0lI=; b=RKtmjsjf0XRVfdy5wwyk/Ez5+vhXGDqZDCL/2NDBAPuj9aMz5eBV1tgYvn6o06nNWU tOuoe9iTbbauX/ocmNtglZBwO/7aandlHpc0LJLNA7RWVIfOoUlHBcRDwkgXbP0RaGy6 g/2ZKzssKMzXJidtX3k8XBRYjHi0iiTWiW8QAXfagA7uSs37/pqitTZswXv79RWm758B KSrkKPFNr1EKuLfRsLmUvJrZ6UC1AXs81Pe1BsNlIjsiFf4pPnRUF3K1ZktdxDhXPb/4 ZGO3fZ9+Hy3VtMtz3yklP4h9icuu23sEw1RaipnfA995ADjanpCIpEUC8HowPpGc4nJR 1qWg== X-Received: by 10.204.247.71 with SMTP id mb7mr8854260bkb.7.1383876934474; Thu, 07 Nov 2013 18:15:34 -0800 (PST) Received: from [31.133.165.38] (dhcp-a526.meeting.ietf.org. [31.133.165.38]) by mx.google.com with ESMTPSA id b6sm4124426bko.16.2013.11.07.18.15.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 18:15:33 -0800 (PST) Message-ID: <527C494A.50804@gmail.com> Date: Fri, 08 Nov 2013 15:15:38 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <527C0C36.1050008@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: MIF Mailing List Subject: Re: [mif] Generalising PVD IDs X-BeenThere: mif@ietf.org 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: Fri, 08 Nov 2013 02:15:37 -0000 On 08/11/2013 15:00, Ted Lemon wrote: > PVD IDs should be something that can somehow be displayed in a menu, like SSIDs. It may be that that works by having a text version and a machine version, but there abide dragons. Display is one thing, mnemonic is another. Are you thinking of something like My_ISP_Lemon or (say) FD37:3467:3170:160:28cc:dc4c:9705:6681 Brian From Ted.Lemon@nominum.com Thu Nov 7 21:04:36 2013 Return-Path: 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 EFA6511E8202 for ; Thu, 7 Nov 2013 21:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.588 X-Spam-Level: X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, 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 untET0t9pSGk for ; Thu, 7 Nov 2013 21:04:30 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 35A7211E8105 for ; Thu, 7 Nov 2013 21:04:30 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUnxw3ZQ7i+uLQfA2jWPtPeNM9h+q9Z7a@postini.com; Thu, 07 Nov 2013 21:04:30 PST 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 777D91B82CB for ; Thu, 7 Nov 2013 21:04:29 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-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 59196190043; Thu, 7 Nov 2013 21:04:29 -0800 (PST) (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.03.0158.001; Thu, 7 Nov 2013 21:04:29 -0800 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [mif] Generalising PVD IDs Thread-Index: AQHO3ASBM83RfGWE70+Hf84rir8GaJobGpuAgAAETACAAC8rgA== Date: Fri, 8 Nov 2013 05:04:28 +0000 Message-ID: <8D074B6B-17B2-42DB-8768-8310553A2D76@nominum.com> References: <527C0C36.1050008@gmail.com> <527C494A.50804@gmail.com> In-Reply-To: <527C494A.50804@gmail.com> 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: text/plain; charset="Windows-1252" Content-ID: <7C999FD75276C84289C25F5A11905B8F@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: MIF Mailing List Subject: Re: [mif] Generalising PVD IDs X-BeenThere: mif@ietf.org 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: Fri, 08 Nov 2013 05:04:37 -0000 On Nov 7, 2013, at 6:15 PM, Brian E Carpenter = wrote: > My_ISP_Lemon Possibly something like "Example WiFi". OTOH, it would be good if the ide= ntifier also looked like this: wifi.example.com. If it did, we could hang= a DANE cert off the name and use it to validate the key for leap-of-faith = associations. So maybe what I'd like to see in the UI is "Example WiFi (w= ifi.example.com)". Or maybe that's too much to ask of the end user=97I do= n't know. Do we have the right expertise on this mailing list to answer t= his question, or should we be looking for additional advice? From denghui02@gmail.com Fri Nov 8 09:59:04 2013 Return-Path: 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 B869611E8200 for ; Fri, 8 Nov 2013 09:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.348 X-Spam-Level: X-Spam-Status: No, score=-102.348 tagged_above=-999 required=5 tests=[AWL=0.251, 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 7XUjr+lA5Ac1 for ; Fri, 8 Nov 2013 09:59:03 -0800 (PST) Received: from mail-vb0-x22b.google.com (mail-vb0-x22b.google.com [IPv6:2607:f8b0:400c:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 636CF11E820B for ; Fri, 8 Nov 2013 09:59:03 -0800 (PST) Received: by mail-vb0-f43.google.com with SMTP id g10so1621989vbg.16 for ; Fri, 08 Nov 2013 09:59:02 -0800 (PST) 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 :content-type; bh=haQ1SffQD/gA1aT2b1PumoY49peDwniaR/TlNBLanAk=; b=SFyb/6U58LJTo2yHBpftVRFy1RDk1rWsKWaMROhEGlsz2clBVRmgJCsKqAUd7R+/GQ 1XOFDL7Me103j07A7J/J0coWYkp9kNzZVRKjWOlu7AC0vdmN8D/8SArJcahVJ8TF6LSf sRDvumCUPct35BZPPaIt40+YqQ620dmiYZSkDS8D5BMqkxHPCed0JY9Bqh6MsPYcTya5 QwKhItlOWcQn+iORLheVYG3pzKQmUuj0DtBN07+EhWMF2xzksOFr70gYCYtCGonJc99x zvOqBDKzPA0yomrQdsPphlXvTti8C7wKgqiGMDFrRPX4Q/yd0bR3s0zVB0RE72VT+4Vj oolA== MIME-Version: 1.0 X-Received: by 10.58.100.244 with SMTP id fb20mr12955080veb.6.1383933542623; Fri, 08 Nov 2013 09:59:02 -0800 (PST) Received: by 10.220.69.13 with HTTP; Fri, 8 Nov 2013 09:59:02 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Nov 2013 09:59:02 -0800 Message-ID: From: Hui Deng To: MIF Mailing List , Margaret Wasserman Content-Type: multipart/alternative; boundary=089e013a27083372a704eaae23d2 Subject: Re: [mif] MIF charter update LC X-BeenThere: mif@ietf.org 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: Fri, 08 Nov 2013 17:59:04 -0000 --089e013a27083372a704eaae23d2 Content-Type: text/plain; charset=ISO-8859-1 Hello all This last call ends on November 20. thanks a lot Cochairs. 2013/11/7 Hui Deng > Hello all. > > From the working group discussion, we have a quite concensus on the > charter update, here we conform again in the list. > > thanks a lot for your help > > Cochairs > > -------------------------------------------------------------- > > Nodes attached to multiple networks may encounter problems due to conflict > of network configuration information 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] enumerates 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. > > > The purpose of the MIF working group is to describe the architecture > detailing how devices attach to and operate in multiple networks. The group > shall also analyze how applications can 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), default > address selection (RFC 6724), ICE and other mechanisms higher layers can > use for address selection, DHCP mechanisms, Router Advertisement > mechanisms, and DNS recommendations. The focus of the working group should > be on documenting the system level effects to host IP stacks and > identification of gaps between the existing IETF recommendations and > existing practice. Having completed some of its initial goals the group is > also developing the following: > > > 1. An incrementally deployable architecture, defining a consistent > approach and recommended practices for handling sets of network > configuration objects by hosts, attached to multiple networks, which enable > hosts to improve network connectivity for the host's applications and users. > > > 2. A set of requirements for changes to or the uses of protocols, that > provide network configuration information, to enable improved handling of > multiple sets of network configuration in networks and hosts. For example, > requirements for DHCPv6 options, Neighbor Discovery options etc. to > communicate association of the configuration information with particular > networks. > > > 3. In cooperation with other working groups, uses of existing protocols in > accordance with the requirements produced under item 2. Any changes of > function of protocols are out of scope. > > > 4. A 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 networks. For instance, > these services could assist advanced applications in having greater control > over first-hop, source address and/or DNS resolver, interface and other > network configuration element selection. This API will be defined as an > abstract interface specification, i.e., specific details about mapping to > operating system primitives or programming languages will be left out. In > addition to the new API, the behavior of existing APIs may be changed to > improve the behavior of unmodified applications. > > > 5. Guidelines to applications, to provide an improved connectivity > experience when the host is attached to multiple networks or there is a > change in the set of networks the host is attached to, e.g., via MIF API > usage. > > > 6. A specification for the format, generation and usage of PVD IDs. > > > Network discovery and selection on lower layers as defined by RFC 5113 is > out of scope. With the exception of identifying requirements for additional > DHCPv6 and/or ND options, as well as requirements for possible related > changes in these protocols, the group shall not assume any software beyond > basic IP protocol support on its peers or in network hosts. 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. > > --089e013a27083372a704eaae23d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all
=A0
This last call ends= on November 20.
thanks a lot
=A0
Cochairs.


2013/11/7 Hui Deng <denghui02@gmail.com>
Hello all.
=A0
From the working g= roup discussion, we have a quite concensus on the charter update, here we c= onform again in the list.
=A0
thanks a lot for your he= lp
=A0
Cochairs
=A0
-----------------------= ---------------------------------------
=A0
Nodes attac= hed to multiple networks may encounter problems due to conflict of network = configuration information and/or simultaneous use of the multiple available= networks. This can happen over multiple physical network interfaces, a com= bination of physical and virtual interfaces (VPNs or tunnels), or even indi= rectly through multiple default routers being on the same link. For instanc= e, current laptops and smartphones typically have multiple access network i= nterfaces.
=A0
=A0
The MIF problem statement document [RFC641= 8] enumerates 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 diffe= rent networks, in the course of a particular network activity / connection.=
3. Use of a particular network, not consistent with the intent of the s= cenario / involved parties, leading to connectivity failure and / or other = undesired consequences.
=A0
=A0
The purpose of the MIF working group is to= describe the architecture detailing how devices attach to and operate in m= ultiple networks. The group shall also analyze how applications can be infl= uenced by these existing mechanisms. The WG shall employ and refer to exist= ing IETF work in this area, including, for instance, strong/weak models (RF= C 1122), default address selection (RFC 6724), ICE and other mechanisms hig= her layers can use for address selection, DHCP mechanisms, Router Advertise= ment mechanisms, and DNS recommendations. The focus of the working group sh= ould be on documenting the system level effects to host IP stacks and ident= ification of gaps between the existing IETF recommendations and existing pr= actice. Having completed some of its initial goals the group is also develo= ping the following:
=A0
=A0
1. An incrementally deployable architectur= e, defining a consistent approach and recommended practices for handling se= ts of network configuration objects by hosts, attached to multiple networks= , which enable hosts to improve network connectivity for the host's app= lications and users.
=A0
=A0
2. A set of requirements for changes=A0 to= or the uses of protocols, that provide network configuration=A0 informatio= n, to enable improved handling of multiple sets of network configuration in= networks and hosts. For example, requirements for DHCPv6 options, Neighbor= Discovery options etc. to communicate association of the configuration inf= ormation with particular networks.
=A0
=A0
3. In cooperation with other working group= s, uses of existing protocols in accordance with the requirements produced = under item 2. Any changes of function of protocols are out of scope.
=A0
=A0
4. A MIF API: While no changes are required for= applications to run on multiple interface hosts, a new API could provide a= dditional services to applications running on hosts attached to multiple ne= tworks. For instance, these services could assist advanced applications in = having greater control over first-hop, source address and/or DNS resolver, = interface and other network configuration element selection. This API will = be defined as an abstract interface specification, i.e., specific details a= bout mapping to operating system primitives or programming languages will b= e left out. In addition to the new API, the behavior of existing APIs may b= e changed to improve the behavior of unmodified applications.
=A0
=A0
5. Guidelines to applications, to provide = an improved connectivity experience when the host is attached to multiple n= etworks or there is a change in the set of networks the host is attached to= , e.g., via MIF API usage.
=A0
=A0
6. A specification for the format, generat= ion and usage of PVD IDs.
=A0
=A0
Network di= scovery and selection on lower layers as defined by RFC 5113 is out of scop= e. With the exception of identifying requirements for additional DHCPv6 and= /or ND options, as well as requirements for possible related changes in the= se protocols, the group shall not assume any software beyond basic IP proto= col support on its peers or in network hosts. No work will be done to enabl= e traffic flows to move from one interface to another. The group recognizes= existing work on mechanisms that require peer or network support for movin= g 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 mechan= isms.=A0 Future work in this area requires rechartering the working group o= r asking other, specialized working groups (such as DHC or 6MAN) to deal wi= th specific issues.
=A0

--089e013a27083372a704eaae23d2-- From Dmitry.Anipko@microsoft.com Sat Nov 9 15:01:27 2013 Return-Path: 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 E877421F8547 for ; Sat, 9 Nov 2013 15:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 o3RekShERR47 for ; Sat, 9 Nov 2013 15:01:22 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id 6D78A21F8F61 for ; Sat, 9 Nov 2013 15:01:21 -0800 (PST) Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) with Microsoft SMTP Server (TLS) id 15.0.815.6; Sat, 9 Nov 2013 23:01:18 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.119]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.207]) with mapi id 15.00.0815.000; Sat, 9 Nov 2013 23:01:18 +0000 From: Dmitry Anipko To: Hui Deng , MIF Mailing List , "Margaret Wasserman" Thread-Topic: [mif] MIF charter update LC Thread-Index: AQHO3BQvdofYqrYyOUS4fJgTNIfTpZoboEEAgAHmhFM= Date: Sat, 9 Nov 2013 23:01:18 +0000 Message-ID: <0b4be69f8b0b45febdec150a4e371768@SN2PR03MB077.namprd03.prod.outlook.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.134.140.50] x-forefront-prvs: 0025434D2D x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(479174003)(53754006)(199002)(189002)(15975445006)(18206015023)(74876001)(87266001)(65816001)(54356001)(76482001)(80022001)(53806001)(66066001)(85306002)(19580405001)(87936001)(69226001)(2656002)(83072001)(33646001)(81816001)(83322001)(80976001)(19580395003)(81686001)(16236675002)(63696002)(74706001)(47976001)(31966008)(47446002)(74662001)(74502001)(46102001)(81342001)(77096001)(77982001)(74366001)(50986001)(47736001)(74316001)(51856001)(59766001)(76576001)(4396001)(49866001)(79102001)(81542001)(54316002)(56776001)(56816003)(76796001)(76786001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB077; H:SN2PR03MB077.namprd03.prod.outlook.com; CLIP:64.134.140.50; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_0b4be69f8b0b45febdec150a4e371768SN2PR03MB077namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [mif] MIF charter update LC X-BeenThere: mif@ietf.org 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: Sat, 09 Nov 2013 23:01:28 -0000 --_000_0b4be69f8b0b45febdec150a4e371768SN2PR03MB077namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support the update proposed below. ________________________________ From: mif-bounces@ietf.org on behalf of Hui Deng Sent: Friday, November 08, 2013 9:59 AM To: MIF Mailing List; Margaret Wasserman Subject: Re: [mif] MIF charter update LC Hello all This last call ends on November 20. thanks a lot Cochairs. [https://mail.google.com/mail/images/cleardot.gif] 2013/11/7 Hui Deng > Hello all. >From the working group discussion, we have a quite concensus on the charter= update, here we conform again in the list. thanks a lot for your help Cochairs -------------------------------------------------------------- Nodes attached to multiple networks may encounter problems due to conflict = of network configuration information and/or simultaneous use of the multipl= e available networks. This can happen over multiple physical network interf= aces, a combination of physical and virtual interfaces (VPNs or tunnels), o= r even indirectly through multiple default routers being on the same link. = For instance, current laptops and smartphones typically have multiple acces= s network interfaces. The MIF problem statement document [RFC6418] enumerates 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 diffe= rent networks, in the course of a particular network activity / connection. 3. Use of a particular network, not consistent with the intent of the scena= rio / involved parties, leading to connectivity failure and / or other unde= sired consequences. The purpose of the MIF working group is to describe the architecture detail= ing how devices attach to and operate in multiple networks. The group shall= also analyze how applications can be influenced by these existing mechanis= ms. The WG shall employ and refer to existing IETF work in this area, inclu= ding, for instance, strong/weak models (RFC 1122), default address selectio= n (RFC 6724), ICE and other mechanisms higher layers can use for address se= lection, DHCP mechanisms, Router Advertisement mechanisms, and DNS recommen= dations. The focus of the working group should be on documenting the system= level effects to host IP stacks and identification of gaps between the exi= sting IETF recommendations and existing practice. Having completed some of = its initial goals the group is also developing the following: 1. An incrementally deployable architecture, defining a consistent approach= and recommended practices for handling sets of network configuration objec= ts by hosts, attached to multiple networks, which enable hosts to improve n= etwork connectivity for the host's applications and users. 2. A set of requirements for changes to or the uses of protocols, that pro= vide network configuration information, to enable improved handling of mul= tiple sets of network configuration in networks and hosts. For example, req= uirements for DHCPv6 options, Neighbor Discovery options etc. to communicat= e association of the configuration information with particular networks. 3. In cooperation with other working groups, uses of existing protocols in = accordance with the requirements produced under item 2. Any changes of func= tion of protocols are out of scope. 4. A MIF API: While no changes are required for applications to run on mult= iple interface hosts, a new API could provide additional services to applic= ations running on hosts attached to multiple networks. For instance, these = services could assist advanced applications in having greater control over = first-hop, source address and/or DNS resolver, interface and other network = configuration element selection. This API will be defined as an abstract in= terface specification, i.e., specific details about mapping to operating sy= stem primitives or programming languages will be left out. In addition to t= he new API, the behavior of existing APIs may be changed to improve the beh= avior of unmodified applications. 5. Guidelines to applications, to provide an improved connectivity experien= ce when the host is attached to multiple networks or there is a change in t= he set of networks the host is attached to, e.g., via MIF API usage. 6. A specification for the format, generation and usage of PVD IDs. Network discovery and selection on lower layers as defined by RFC 5113 is o= ut of scope. With the exception of identifying requirements for additional = DHCPv6 and/or ND options, as well as requirements for possible related chan= ges in these protocols, the group shall not assume any software beyond basi= c IP protocol support on its peers or in network hosts. No work will be don= e 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 multipl= e care-of addresses in Mobile IPv6. This group does not work on or impact s= uch 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. --_000_0b4be69f8b0b45febdec150a4e371768SN2PR03MB077namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support the update proposed below.


From: mif-bounces@ietf.org = <mif-bounces@ietf.org> on behalf of Hui Deng <denghui02@gmail.com&= gt;
Sent: Friday, November 08, 2013 9:59 AM
To: MIF Mailing List; Margaret Wasserman
Subject: Re: [mif] MIF charter update LC
 
Hello all
 
This last call ends on November 20.
thanks a lot
 
Cochairs.


2013/11/7 Hui Deng <denghui02@gmail.com&g= t;
Hello all.
 
From the working group discussion, we have a quite concensus on the ch= arter update, here we conform again in the list.
 
thanks a lot for your help
 
Cochairs
 
--------------------------------------------------------------
 
Nodes attached to multiple networks may encounter problems due to conf= lict of network configuration information and/or simultaneous use of the mu= ltiple available networks. This can happen over multiple physical network i= nterfaces, a combination of physical and virtual interfaces (VPNs or tunnels), or even indirectly through multi= ple default routers being on the same link. For instance, current laptops a= nd smartphones typically have multiple access network interfaces.
 
 
The MIF problem statement document [RFC6418] enumerates the problems i= nto 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 diffe= rent networks, in the course of a particular network activity / connection.=
3. Use of a particular network, not consistent with the intent of the scena= rio / involved parties, leading to connectivity failure and / or other unde= sired consequences.
 
 
The purpose of the MIF working group is to describe the architecture d= etailing how devices attach to and operate in multiple networks. The group = shall also analyze how applications can be influenced by these existing mec= hanisms. The WG shall employ and refer to existing IETF work in this area, including, for instance, strong/= weak models (RFC 1122), default address selection (RFC 6724), ICE and other= mechanisms higher layers can use for address selection, DHCP mechanisms, R= outer Advertisement mechanisms, and DNS recommendations. The focus of the working group should be on docum= enting the system level effects to host IP stacks and identification of gap= s between the existing IETF recommendations and existing practice. Having c= ompleted some of its initial goals the group is also developing the following:
 
 
1. An incrementally deployable architecture, defining a consistent app= roach and recommended practices for handling sets of network configuration = objects by hosts, attached to multiple networks, which enable hosts to impr= ove network connectivity for the host's applications and users.
 
 
2. A set of requirements for changes  to or the uses of protocols= , that provide network configuration  information, to enable improved = handling of multiple sets of network configuration in networks and hosts. F= or example, requirements for DHCPv6 options, Neighbor Discovery options etc. to communicate association of the configur= ation information with particular networks.
 
 
3. In cooperation with other working groups, uses of existing protocol= s in accordance with the requirements produced under item 2. Any changes of= function of protocols are out of scope.
 
 
4. A MIF API: While no changes are required for applications to run on= multiple interface hosts, a new API could provide additional services to a= pplications running on hosts attached to multiple networks. For instance, t= hese services could assist advanced applications in having greater control over first-hop, source address and/= or DNS resolver, interface and other network configuration element selectio= n. This API will be defined as an abstract interface specification, i.e., s= pecific details about mapping to operating system primitives or programming languages will be left out. In = addition to the new API, the behavior of existing APIs may be changed to im= prove the behavior of unmodified applications.
 
 
5. Guidelines to applications, to provide an improved connectivity exp= erience when the host is attached to multiple networks or there is a change= in the set of networks the host is attached to, e.g., via MIF API usage.
 
 
6. A specification for the format, generation and usage of PVD IDs.
 
 
Network discovery and selection on lower layers as defined by RFC 5113= is out of scope. With the exception of identifying requirements for additi= onal DHCPv6 and/or ND options, as well as requirements for possible related= changes in these protocols, the group shall not assume any software beyond basic IP protocol support on it= s peers or in network hosts. No work will be done to enable traffic flows t= o 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 th= e use of multiple care-of addresses in Mobile IPv6. This group does not wor= k on or impact such mechanisms.  Future work in this area requires rec= hartering the working group or asking other, specialized working groups (such as DHC or 6MAN) to deal with speci= fic issues.
 

--_000_0b4be69f8b0b45febdec150a4e371768SN2PR03MB077namprd03pro_-- From denghui02@gmail.com Tue Nov 12 19:34:41 2013 Return-Path: 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 2F9B711E816D for ; Tue, 12 Nov 2013 19:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.295 X-Spam-Level: X-Spam-Status: No, score=-102.295 tagged_above=-999 required=5 tests=[AWL=0.304, 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 wGho32qHatf6 for ; Tue, 12 Nov 2013 19:34:40 -0800 (PST) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 68BE111E8163 for ; Tue, 12 Nov 2013 19:34:40 -0800 (PST) Received: by mail-ve0-f179.google.com with SMTP id oz11so4051201veb.10 for ; Tue, 12 Nov 2013 19:34:39 -0800 (PST) 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=bkZd6NlqE4ir4632axeTBgrmkLivUgMfR9T4eQ2RXbY=; b=1FZHU7MP3nOIgdQRXQEeJeI2Y0Mr4AdZ6E6/AJlMF0BpXGdppstEKX52zCwmsxNEUn w/vPNzSJOFKf4KPuU7iklhC+4jl8BA5bz1mJKV7Zm7L7OW9I/2G1BGF1MyAfBmjLwhGw vL1cJhOhfl1KUpE8XdH9wjqjcORtCruW3nZ4D6OALTr1qTBLQ3HEzEf4VAwF9ymB34nW gh4mgss5e/q4DpvP71Bk5PsYvjSn+rXwFHbAS/qA/ujoXseJoY4lr3BcARTCee+2CATR mDaEtgMiTH4JlcHV5A4MyIuzkkftbhR3M0ixaRFm6PLf23M3kkV6e6+ZSKbER7QKGsGq hhig== MIME-Version: 1.0 X-Received: by 10.58.216.74 with SMTP id oo10mr31996471vec.0.1384313679765; Tue, 12 Nov 2013 19:34:39 -0800 (PST) Received: by 10.220.110.7 with HTTP; Tue, 12 Nov 2013 19:34:39 -0800 (PST) Date: Wed, 13 Nov 2013 11:34:39 +0800 Message-ID: From: Hui Deng To: MIF Mailing List Content-Type: multipart/alternative; boundary=047d7b86e3d823e6e404eb06a589 Subject: [mif] 88th MIF minutes upload X-BeenThere: mif@ietf.org 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, 13 Nov 2013 03:34:41 -0000 --047d7b86e3d823e6e404eb06a589 Content-Type: text/plain; charset=ISO-8859-1 Hello all Great thanks Ian Farrer's kind help for taking meeting minutes, also thanks Peer, Dave, and Behcet for jabber http://www.ietf.org/proceedings/88/minutes/minutes-88-mif Feel free to let chair know if you have any comments on it. Best regards, DENG Hui --047d7b86e3d823e6e404eb06a589 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all
=A0
Great thanks Ian Fa= rrer's kind help for taking meeting minutes,
also thanks Peer= , Dave, and Behcet for jabber
=A0
=A0
Feel free to let chair know if you have any comments on = it.
=A0
Best regards,
=A0
DENG Hui<= /div>
--047d7b86e3d823e6e404eb06a589--