Re: [mif] MIF charter update LC

[Alexandru Petrescu <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mif
>