Subject: [mif] Updated charter

From: Hui Deng <[email-masked]>
Date: Wed, 9 Oct 2013 23:54:44 +0800

Hello all,

We will not make big change this time, basically DHCP and DNS items will be
removed, only architecture work item will be added, thanks for your comment,

Best regards,

-Hui

Charter for Working Group

Many hosts have the ability to attach to multiple networks
 simultaneously. 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.
 A host attached to multiple networks has to make decisions about default
 router selection, address selection, DNS server selection, choice of
 interface for packet transmission, and the treatment of configuration
 information received from the various networks. Some configuration
 objects are global to the node, some are local to the interface, and
 some are related to a particular prefix. Various issues arise when
 contradictory configuration objects that are global to the node are
 received on different interfaces. At best, decisions about these matters
 have an efficiency effect. At worst, they have more significant effects
 such as security impacts, or even lead to communication not being
 possible at all.
 A number of operating systems have implemented various techniques 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.
 The purpose of the MIF working group is to describe the issues of
 attaching to multiple networks on hosts and document existing practice.
 The group shall also analyze the impacts and effectiveness of 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. 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. After completing some of its initial goals in 2010 the
 group is also developing three specific extensions:
 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.

 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.

Nov 2013
Architecture draft adopted as the working group document

Dec 2013
Working group last call for MIF API document

---

From: Hui Deng <[email-masked]>
Date: Thu, 10 Oct 2013 00:02:25 +0800

excuse me for adding some space lines between paragraphs
thanks for your comments,

-Hui

Nov 2013

Dec 2013

---

From: Hui Deng <[email-masked]>
Date: Thu, 10 Oct 2013 00:04:39 +0800

It seems my browser gmail has some issue on this, redo , double space line
hope it works this time,
sorry,

-Hui

Nov 2013

Dec 2013

2013/10/10 Hui Deng <[email-masked]>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 10 Oct 2013 05:27:00 +0200 (CEST)

> removed, only architecture work item will be added, thanks for your comment,

Hi,

I read this proposed new charter. It contains DHCP and DNS items as it is 
right now, so I have a bit hard time understanding "will be removed"? I 
read the charter as it is posted on 
http://datatracker.ietf.org/wg/mif/charter/ and that one has a "1. dns 
server selection solution" that seems to have been removed, is that was 
the "will be removed" refers to?

I have a question:

"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."

I don't really understand this sentence. MIF could recommend new DHCP 
options, but nothing else? What if we feel a new RA option (for RFC6106 to 
work properly) or different behaviour of RA is warranted, is that out of 
scope? I feel this is quite a big limitation to put on ourselves. Perhaps 
wording such as "should try its hardest to find solutions that do not 
require changes to basic IP protocols" or something along those lines 
could steer work but not limit it? Or we just re-charter if we run into a 
dead-end and can't make it out unless we change something?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Oct 2013 09:05:46 -0400

On Oct 9, 2013, at 11:27 PM, Mikael Abrahamsson <[email-masked]> wrote:
> I read this proposed new charter. It contains DHCP and DNS items as it is right now, so I have a bit hard time understanding "will be removed"? I read the charter as it is posted on http://datatracker.ietf.org/wg/mif/charter/ and that one has a "1. dns server selection solution" that seems to have been removed, is that was the "will be removed" refers to?

The server selection document has been an RFC for a year or two now, and the router option really shouldn't have been a MIF work item to begin with, and caused a lot of trouble in the MIF working group before you arrived.   If we left it in in order to minimize changes, it would probably create more problems than it would avoid.

> I don't really understand this sentence. MIF could recommend new DHCP options, but nothing else? What if we feel a new RA option (for RFC6106 to work properly) or different behaviour of RA is warranted, is that out of scope? I feel this is quite a big limitation to put on ourselves. Perhaps wording such as "should try its hardest to find solutions that do not require changes to basic IP protocols" or something along those lines could steer work but not limit it? Or we just re-charter if we run into a dead-end and can't make it out unless we change something?

It should indeed mention RAs.   The point is that we don't assume that the host already has some way of dealing with the MIF problem, like a connection manager or something of that sort.   At least, I _think_ that's the point—Dmitry actually wrote that text, so he can probably explain better than I can.

---

From: Dmitry Anipko <[email-masked]>
Date: Fri, 11 Oct 2013 03:37:37 +0000

>> At least, I _think_ that's the point-Dmitry actually wrote that text, so he can probably explain better than I can.

My understanding is the text Mikael is referring to 

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

that is in the current MIF charter. The proposal Hui sent out most recently has not updated it, and it is now in some contradiction with the added text about PVD. So I'd agree that this sentence could be replaced e.g. with 

<text>
With the exception of support for additional DHCP and/or ND options as well as possible related changes in these protocols, group shall not assume any software beyond basic IP protocol support on its peers or in network nodes.
</text>

Mikael - would that address your comment? For convenience, the complete would-be-updated text of the charter is in the end of this email.

Apart from that, Ted raised a point in a separate email thread, whether the 1) in the proposal covers the arch doc work. In my opinion, it is minimally sufficient to cover the arch work (specifically " Handling sets of network configuration objects by nodes, attached to multiple networks: *a solution*"), but if there is an agreement that it isn't sufficient to cover arch doc, suggestions on the specific text to be included are welcome.

-Dmitry

 Network discovery and selection on lower layers as defined by RFC 5113
 is out of scope. With the exception of support for additional DHCP and/or 
 ND options as well as possible related changes in these protocols, 
 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.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Thursday, October 10, 2013 6:06 AM
To: Mikael Abrahamsson
Cc: MIF Mailing List
Subject: Re: [mif] Updated charter

> I don't really understand this sentence. MIF could recommend new DHCP options, but nothing else? What if we feel a new RA option (for RFC6106 to work properly) or different behaviour of RA is warra…

It should indeed mention RAs.   The point is that we don't assume that the host already has some way of dealing with the MIF problem, like a connection manager or something of that sort.   At least, I _think_ that's the point-Dmitry actually wrote that text, so he can probably explain better than I can.
_______________________________________________
mif mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mif

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 11 Oct 2013 06:48:28 +0200 (CEST)

> Mikael - would that address your comment? For convenience, the complete would-be-updated text of the charter is in the end of this email.

Let me take a fresh look at it. I think I'll comment on the proposed text 
below.

> have multiple access network interfaces.

Here I'd also like to add that not only can we have multiple default 
routers on the same link, we can have multiple/identical prefixes on the 
same link from each/some of these default routers, and each prefix on-wire 
could have different PVD meaning.

> - APIs to expose the sets to the applications which require that

I'm fine with the above here.

> or programming language will be left out.

PVD is first mentioned in the text in the chapter above, but it's never 
explained before in the document, so this should probably be done.

> asking other, specialized working groups (such as DHC or 6MAN) to deal

Does the above writing preclude the group from stating that information 
could *also* arrive at the node by other means? So while the mechanism of 
this arrival isn't something MIF deals with, we still say what information 
needs to arrive and how it should be handled?

I'm thinking for instance if someone wants to provision this statically or 
it arrives by means of (for example) 3GPP "out of band" signaling?

---

From: Dmitry Anipko <[email-masked]>
Date: Sun, 13 Oct 2013 23:33:19 +0000

Thanks for the comments Mikael.

I've added mentioning of address prefixes, got rid of the use of undefined acronym PVD in this text, and per off-list AD guidance replaced the bullets detailing arch doc contents with the explicit item for arch doc as a deliverable (this has been the main motivator of the currently considered charter update, to allow for adoption of the arch draft; additional changes to the charter can be included later).

I believe the arch doc text is worded broadly enough to cover the "out of band" mechanisms at the arch level.  

The updated suggested charter text is below, please let me know if there are further comments.

-Dmitry

Many hosts have the ability to attach to multiple networks
 simultaneously. 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 and/or 
address prefixes being on the same link. For instance, current 
laptops and smartphones typically have multiple access network interfaces.

 1) Architecture document, defining consistent approach, recommended practices
and requirements for possible protocol changes to improve handling of multiple sets of network configuration objects in networks and nodes.

 and/or DNS selection, interface and other network configuration elements selection. 

 Network discovery and selection on lower layers as defined by RFC 5113
 is out of scope. With the exception of support for additional DHCP and/or 
 ND options as well as possible related changes in these protocols, 
 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.
________________________________________
From: Mikael Abrahamsson <[email-masked]>
Sent: Thursday, October 10, 2013 9:48 PM
To: Dmitry Anipko
Cc: Ted Lemon; MIF Mailing List
Subject: RE: [mif] Updated charter

---

From: Ted Lemon <[email-masked]>
Date: Sun, 13 Oct 2013 20:35:34 -0400

I made a small tweak to the version you sent, Dmitry, to reflect the fact that the working group is working on requirements for DHCP and ND options and possibly protocol changes, not actually making those changes.   I don't think the text is quite right, and would appreciate comments.   The wdiff output between the current (approved) charter and the proposed new charter can be seen here:

https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-mif%2Fwithmilestones-03.txt&difftype=--hwdiff&submit=Go%21&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-mif%2Fwithmilestones-03-00.txt

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 16 Oct 2013 17:02:33 +0900

LGTM.

On Mon, Oct 14, 2013 at 9:35 AM, Ted Lemon <[email-masked]> wrote:

> I made a small tweak to the version you sent, Dmitry, to reflect the fact
> that the working group is working on requirements for DHCP and ND options
> and possibly protocol changes, not actually making those changes.   I don't
> think the text is quite right, and would appreciate comments.   The wdiff
> output between the current (approved) charter and the proposed new charter
> can be seen here:
>
>