oldcharter.txt | newcharter3.txt | |||
---|---|---|---|---|
skipping to change at line 39 | skipping to change at line 39 | |||
The purpose of the MIF working group is to describe the issues of | The purpose of the MIF working group is to describe the issues of | |||
attaching to multiple networks on hosts and document existing practice. | attaching to multiple networks on hosts and document existing practice. | |||
The group shall also analyze the impacts and effectiveness of these | The group shall also analyze the impacts and effectiveness of these | |||
existing mechanisms. The WG shall employ and refer to existing IETF work | existing mechanisms. The WG shall employ and refer to existing IETF work | |||
in this area, including, for instance, strong/weak models (RFC 1122), | in this area, including, for instance, strong/weak models (RFC 1122), | |||
address selection (RFC 3484), ICE and other mechanisms higher layers can | address selection (RFC 3484), ICE and other mechanisms higher layers can | |||
use for address selection, DHCP mechanisms, Router Advertisement | use for address selection, DHCP mechanisms, Router Advertisement | |||
mechanisms, and DNS recommendations. The focus of the working group | mechanisms, and DNS recommendations. The focus of the working group | |||
should be on documenting the system level effects to host IP stacks and | should be on documenting the system level effects to host IP stacks and | |||
identification of gaps between the existing IETF recommendations and | identification of gaps between the existing IETF recommendations and | |||
existing practice. The working group shall address both IPv4 and IPv6 as | existing practice. After completing some of its initial goals in 2010 the | |||
well as stateless and stateful configuration. | group is also developing three specific extensions: | |||
1) DNS server selection solution: a specification for describing a way | ||||
for a network to communicate to nodes information required to perform | ||||
advanced DNS server selection at name resolution request granularity | ||||
in scenarios involving multiple namespaces. The specification shall | ||||
describe the information to be delivered for nodes and the protocol to | ||||
be used for delivery. | ||||
2) DHCPv6 routing configuration: DHCPv6 routing configuration: a | ||||
specification of DHCPv6 options allowing to provision client nodes | ||||
with small amount of static routing information (e.g. regarding | ||||
first-hop selection). This is an additional mechanism to the one | ||||
already defined in RFC 4191 to enable per-host configuration in a | ||||
managed network environment. The development of dynamic routing | ||||
capabilities or ability to send more than a few specific routes are | ||||
explicitly outside the scope of work in this , and require the use of either existing | ||||
or new routing protocols. | ||||
3) MIF API: While no changes are needed 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 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. | ||||
Network discovery and selection on lower layers as defined by RFC 5113 | 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 | is out of scope. With the exception of support for additional DHCP | |||
policy mechanisms; recommendations and gap analysis from the group are | options in DHCP servers, group shall not assume any software beyond | |||
solely based on existing solutions. The group shall not assume any | basic IP protocol support on its peers or in network nodes. No work | |||
software beyond basic IP protocol support on its peers or in network | will be done to enable traffic flows to move from one interface to | |||
nodes. No work will be done to enable traffic flows to move from one | another. The group recognizes existing work on mechanisms that require | |||
interface to another. The group recognizes existing work on mechanisms | peer or network support for moving traffic flows such as RFC 5206, RFC | |||
that require peer or network support for moving traffic flows such as | 4980 and the use of multiple care-of addresses in Mobile IPv6. This | |||
RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile | group does not work on or impact such mechanisms. | |||
IPv6. This group does not work on or impact such mechanisms. | ||||
Once the group has completed its work items, the IETF can make an | Future work in this area requires rechartering the working group or | |||
informed decision about rechartering the working group to define new | asking other, specialized working groups (such as DHC or 6MAN) to deal | |||
mechanisms or asking other, specialized working groups (such as DHC or | with specific issues. | |||
6MAN) to deal with specific issues. | ||||
Goals and Milestones | Goals and Milestones | |||
Done WG chartered | Done WG chartered | |||
Done Initial draft on problem statement adopted by the WG | Done Initial draft on problem statement adopted by the WG | |||
Done Initial draft on existing practices adopted by the WG | Done Initial draft on existing practices adopted by the WG | |||
Dec 2009 Initial draft on analysis of existing practices adopted by the WG | Done Initial draft on analysis of existing practices adopted by the WG | |||
Mar 2010 Problem statement draft submitted to the IESG for publication as an Informational RFC | Done Problem statement draft submitted to the IESG for publication as an Informational RFC | |||
Jul 2010 Existing practices draft submitted to the IESG for publication as an Informational RFC | Done Existing practices draft submitted to the IESG for publication as an Informational RFC | |||
Sep 2010 Analysis draft submitted to the IESG for publication as an Informational RFC | Dec 2010 Initial WG draft on DHCPv6 option for routing configuration | |||
Oct 2010 Recharter or close | Jan 2011 Analysis draft submitted to the IESG for publication as an Informational RFC | |||
Jan 2011 Initial WG draft on advanced DNS server selection solution | ||||
Jan 2011 Initial WG draft on MIF API extension. | ||||
Jun 2011 Submit DHCPv6 routing configuration option to IESG for publication as a Proposed Standard RFC | ||||
Nov 2011 Submit advanced DNS server selection solution to IESG for publication as a Proposed Standard RFC | ||||
Nov 2011 Submit MIF API extension solution to IESG for publication as an Informational RFC | ||||
End of changes. 4 change blocks. | ||||
15 lines changed or deleted | 39 lines changed or added | |||
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |