Hi, Jari, What I suggest is like the below: > Connections to Multiple Networks (mif) > ------------------------------------------------ > Last Modified: 2009-04-20 > > Current Status: Proposed Working Group > > Chair(s): > TBD thanks -Hui 2009/4/21 Jari Arkko <jari.arkko@xxxxxxxxx>: > 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. > > 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf