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

[Hui Deng <[e-mail]>]

Lorenzo,

Let's speed up the architecture work, not discussing happy eyeball at this
time,
only one work item will be added, I will post the latest one shortly,

-Hui


2013/10/8 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
>>
>>
>