Re: [mif] Request for review - updated charter of MIF

[Lorenzo Colitti <[e-mail]>]

Hui,

in general this seems fine to me, though I think it's a bit long and
perhaps overspecified.

One issue I have is that the charter explicitly lists the "MIF happy
eyeballs document". I don't think the charter should list specific
solutions; it should list the work that the group wants to do, but not
explore solution space, because that's for the working group to decide
during the course of the work. For example, what do we do if the multiple
PVD architecture conflicts with the happy eyeballs extension document, or
makes it obsolete? We'd need to approve a charter change in order to fix
the problem.

So I think the charter should not mention this specific solution. We can
still keep that work on the charter without calling it out by name. All we
need to do is reword the bullet point as a problem statement rather than a
specific solution. For example: "4) Explore the use of heuristic mechanisms
to improve interface selection".

Another minor issue: where you say "with the exception of support for
additional DHCP options in DHCP servers, group shall not assume any
software beyond basic IP protocol support on its peers or in network nodes"
you should at least list RA options as well.

Cheers,
Lorenzo


On Mon, Oct 7, 2013 at 11:55 PM, Hui Deng <[e-mail]> wrote:

> Hello all,
>
> Based on last IETF MIF meeting and regular teleconf of MIF design team,
> below charter has been proposed, please feel free to comment on it
>
> Many thanks
>
> -cochairs,
>
> ---------------------------------------------
>
> Charter for Working Group
>
>  Nodes attached to multiple networks may encounter problems due to
>  conflict of the networks configuration  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] enumerate 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.
>
>  A number of operating systems have implemented various techniques
>  ([RFC6419])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. In many cases the issues may still appear.
>
>  The purpose of the MIF working group is to describe the architecture
>  attaching to multiple provisioning domains.  The group shall also analyze
>  that applications will 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), address selection
>  (RFC 3484), ICE and other mechanisms higher layers can use for address
>  selection, DHCP mechanisms, Router Advertisement mechanisms, and DNS
>  recommendations.
>
>  1) Handling sets of network configuration objects by nodes, attached to
>  multiple networks: a solution could include a set of requirements for
>  changes to protocols used to provide configuration information. For
>  example:
>  - requirements for DHCPv6 options, Neighbor Discovery options etc. to
>    communicate association of the objects with particular
>    provisioning domains
>  - best practices for nodes how to group the configuration objects
>    into sets and use them for network connectivity
>  - APIs to expose the sets to the applications which require that
>    information
>  2) 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 provisioning
>  domains. For instance, these services could assist advanced
>  applications in having greater control over first-hop, source address
>  and/or DNS selection, interface selection, and PVD selection issues.
>  This API will be defined as an abstract interface specification,
>  i.e., specific details about mapping to operating system primitives
>  or programming language will be left out.
>  3) MIF API Session Continuity: There are several classes of
>  applications that would desire session continuity in the presence of
>  changing connectivity and multiple attachments. An informational
>  document will recommend some basic steps that applications can follow in
>  order to maintain session continuity to improve user experience by using
>  the aforementioned MIF API interfaces.
>  4) MIF Happyeyeball: Sometime host prefer to use only one interface
>  for the sesson, a mechanism to make the interface selection process
>  smoother by using some heuristical information.
>
>  Network discovery and selection on lower layers as defined by RFC 5113
>  is out of scope. With the exception of support for additional DHCP
>  options in DHCP servers, 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.
>  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.
>
>  Milestones
>
> Jan 2011
> Analysis draft submitted to the IESG for publication as an Informational
> RFC
>
> Mar 2011
> Submit MIF API extension solution to IESG for publication as an
> Informational RFC
>
> Nov 2011
> Submit advanced DNS server selection solution to IESG for publication as a
> Proposed Standard RFC
>
> Nov 2013
> Architecture draft adopted as the working group document
> Nov 2013
> session continuity adopted as the working group document
> Dec 2013
> Working group last call for MIF API document
> Dec 2013
> working group last call for MIF Happy eyeball document.
>
> _______________________________________________
> mif mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mif
>
>