Subject: [mif] MIF charter update LC

From: Hui Deng <[email-masked]>
Date: Thu, 7 Nov 2013 15:50:20 -0800

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.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 08 Nov 2013 00:59:14 +0100

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.
> 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.
> scenario / involved parties, leading to connectivity failure and / or
> other undesired consequences.
> 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.
> 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.
> 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.
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>

---

From: Hui Deng <[email-masked]>
Date: Fri, 8 Nov 2013 09:59:02 -0800

Hello all

This last call ends on November 20.
thanks a lot

Cochairs.

2013/11/7 Hui Deng <[email-masked]>

> The MIF problem statement document [RFC6418] enumerates the problems into
> 3 categories:
> configuration objects by hosts, attached to multiple networks, which enable
> hosts to improve network connectivity for the host's applications and users.
>
>

---

From: Dmitry Anipko <[email-masked]>
Date: Sat, 9 Nov 2013 23:01:18 +0000

I support the update proposed below.

________________________________
From: [email-masked] <[email-masked]> on behalf of Hui Deng <[email-masked]>
Sent: Friday, November 08, 2013 9:59 AM
To: MIF Mailing List; Margaret Wasserman
Subject: Re: [mif] MIF charter update LC

Hello all

Cochairs.
[https://mail.google.com/mail/images/cleardot.gif]

2013/11/7 Hui Deng <[email-masked]<mailto:[email-masked]>>
Hello all.

>From the working group discussion, we have a quite concensus on the charter update, here we conform again in the list.

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.

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.