At 1:14 PM -0700 4/20/09, Jari Arkko wrote: >Hui, > >I'm not sure if I understood your comment about the WG name correctly. >We cannot change it at this stage easily. So lets just keep it as is. Huh? Why on earth is it hard? Strings are cheap. Not that I care much about this, but having been in many a working group name change (hi, DRINKS folks!), I don't know what has changed to make this hard. Ted >Please find below the full charter proposal, with the suggested changes >folded in from you and others. > >Jari > >Multiple InterFaces (mif) >------------------------------------------------ >Last Modified: 2009-04-20 > >Current Status: Proposed Working Group > >Chair(s): >TBD > >Internet Area Director(s): >Ralph Droms <rdroms@xxxxxxxxx> >Jari Arkko <jari.arkko@xxxxxxxxx> > >Internet Area Advisor: >TBD > >Mailing Lists: >General Discussion: mif@xxxxxxxx >To Subscribe: https://www.ietf.org/mailman/listinfo/mif >Archive: http://www.ietf.org/mail-archive/web/mif > >Description of Working Group: > >Many hosts have the ability to attach to multiple networks >simultaneously. This can happen over multiple physical network >interfaces, a combination of physical and virtual interfaces (VPNs or >tunnels), or even through multiple default routers being on the same >link. For instance, current laptops and smartphones typically have >multiple access network interfaces. > >A host attached to multiple networks has to make decisions about default >router selection, address selection, DNS server selection, choice of >interface for packet transmission, and the treatment of configuration >information received from the various networks. Some configuration >objects are global to the node, some are local to the interface, and >some are related to a particular prefix. Various issues arise when >multiple configuration objects that are global to the node are received >on different interfaces. At best, decisions about these matters have an >efficiency effect. At worst, they have more significant effects such as >security impacts, or even lead to communication not being possible at all. > >A number of operating systems have implemented various techniques 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. > >The purpose of the MIF working group is to describe the issues of >attaching to multiple networks on hosts, document existing practice, and >make recommendations about best current practice. 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), 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. The working group >shall address both IPv4 and IPv6 as well as stateless and stateful >configuration. > >Network discovery and selection on lower layers as defined by RFC 5113 >is out of scope. Also, the group shall not develop new protocol or >policy mechanisms; recommendations and gap analysis from the group are >solely based on existing solutions. The 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. > >Once the group has completed its work items, the IETF can make an >informed decision about rechartering the working group to define new >mechanisms or asking other, specialized working groups (such as DHC or >6MAN) to deal with specific issues. > >Milestones: > >May 2009 WG chartered >July 2009 Initial draft on problem statement adopted by the WG >September 2009 Initial draft on existing practices adopted by the WG >Jan 2010 Initial best current practices draft adopted by the WG >March 2010 Problem statement draft submitted to the IESG for publication >as an Informational RFC >July 2010 Existing practices draft submitted to the IESG for publication >as an Informational RFC >September 2010 Best current practices draft submitted to the IESG for >publication as a BCP >October 2010 Recharter or close > >_______________________________________________ >Ietf mailing list >Ietf@xxxxxxxx >https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf