| 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/ | ||||