Subject: [mif] The formation of the design team

From: Hui Deng <[email-masked]>
Date: Wed, 3 Apr 2013 20:03:54 +0800

Hello all,

MIF working group has formed a design team to work on the architecture
issue.
Below are the list of contributors:

Alper Yegin
Aaron Yi DING
Cao Zhen
Dan York [security related only]
Dapeng Liu
Dave Thaler
Fred baker [I'm willing to do that]
Jouni Korhonen
JuanCarlos.Zuniga
Konstantinos Pentikousis
Lorenzo Colitti
Marc Blanchet
pierrick.seite
suresh krishnan
Tim Chown  [identity or other perspectives]
Teemu Savolainen
WG Chair: Margaret Wasserman, Hui Deng
AD: Ted Lemon

thank you

-chairs

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Apr 2013 12:02:36 -0400

>>>>> "Hui" == Hui Deng <[email-masked]> writes:
    Hui> Hello all,

    Hui> MIF working group has formed a design team to work on the architecture
    Hui> issue.
    Hui> Below are the list of contributors:

It's a rather big design team. 
Almost seems like a cmte of the whole :-)

I'm wondering what is the "architecture issue".

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Apr 2013 17:26:44 +0100

> I'm wondering what is the "architecture issue".

I think the real question is whether the architecture issue
that underlies MIF can actually be solved within the limits
of an IETF WG. But certainly the first stage is to produce a
clear statement of what the issue is, and I would press the
design team to bring that statement back to the WG *before*
considering possible solutions.

BTW, it's normal for a design team to have a sort of mini-charter
that consists of more than two words.

    Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 3 Apr 2013 13:34:53 -0400

Hi Brian,

> considering possible solutions.

There are already two sources of information about "the problem" available:

(1) The problem statement we published last year.
(2) The slides Ted Lemon presented in Orlando.

I don't see how we would benefit from going through another multi-year effort to identify "the problem".  Maybe it is true that when we start looking at the solution space, we will decide that there is no tractable way to solve the problem, but we'll never figure that out if we don't look at the solution space at some point…

There are already solutions out there that solve (parts of) the problem, too, and we attempted to document those, as well.

> that consists of more than two words.

In my experience, design teams have varied a lot both in formality and organization.  During the first call, we will talk to the design team about how we want to organize ourselves.

Like all design teams, of course, anything the team produces will just be input to the WG…  We would need WG consensus to adopt it or publish it.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 3 Apr 2013 13:40:45 -0400

> Almost seems like a cmte of the whole :-)

We made a call at the meeting and on the list for participants, and we took everyone who volunteered.  I suspect that not everyone who volunteered for (or was drafted for :-)) the design team will actively participate, and the number of volunteers wasn't so large that it made sense to exclude anyone.

> I'm wondering what is the "architecture issue".

This design team is going to look at the "Multiple Provisioning Domain" problem, and work on an architectural approach (or approaches?) to addressing that issue.  It will be interesting to see if we can get any consensus, even within the team, about what the problem is at an architectural level and how to address it.   I think we have a lot of different ideas, and it will be interesting to see if we can find some common ground.

Margaret

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Apr 2013 13:47:23 -0400

>>>>> "Margaret" == Margaret Wasserman <[email-masked]> writes:

    Margaret> There are already two sources of information about "the problem" available:

    Margaret> (1) The problem statement we published last year.
    Margaret> (2) The slides Ted Lemon presented in Orlando.

I actually did look at the WG datatracker page to try and see if I could
find such a document before I asked.... I guess I missed finding it
as I was looking for "architecture", not "problem statement"
RFC6418.

I guess "Ted Lemon presented" slides are:
  http://tools.ietf.org/agenda/86/slides/slides-86-mif-1.pdf

  "The	solution requires fundamental changes in	
  the default architecture of IP stacks"

I think that this is the "architecture" problem then?

The question is I think, how to architect the IP stack such that the bag
of things that make up a provisioning domain can be collected together
properly, and expressed in a concise enough way that an application can
actually say "use this provisioning domain".

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Apr 2013 23:37:12 +0000

> I'm wondering what is the "architecture issue".

There was a detailed presentation on this in Orlando.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Apr 2013 23:48:46 +0000

> considering possible solutions.

Work that the IETF does has to be done in working groups, or as individual submissions, or by the IAB or the IESG.   Are you proposing that this work should be done in one of those other ways, rather than by the MIF working group, which was chartered to do this work and has already written a problem statement?   I don't think you were at the MIF meeting, so you may not have heard my presentation on this, but the slides are available, and I think the session was recorded.

Ultimately, we definitely need something for the rest of the IETF, not just MIF, to review, but we have to have something for the IETF *to* review; that is the point.

Michael did raise the question of whether this is really a design team, or the entire working group.   This is something that I discussed with the MIF chairs as well.   It's difficult to say; if everybody on the list winds up being an active participant, then maybe Michael is correct.   I personally doubt that's so.

However, it may be that you or Michael are concerned that process isn't being followed.   It could be argued that the meeting Hui announced is really an interim working group meeting and not a design team meeting.   If that's the case, then the two week notice requirement applies.

I don't have a strong preference for keeping this as a design team thing if people object.   I doubt the chairs do either.   It's certainly easier to schedule meetings if it's just a design team, and I think it's legitimate to claim that it's a design team.   But, frankly, you have more experience with this sort of thing than I do; if in your expert opinion this is an interim working group meeting and not a design team meeting, I think we ought to take that seriously.

But as for the question of where to do the work, I think at least for the moment, unless you have some serious proposal to make, MIF is in fact the right place.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Apr 2013 20:51:15 -0400

>>>>> "Ted" == Ted Lemon <[email-masked]> writes:
    Ted> Michael did raise the question of whether this is really a
    Ted> design team, or the entire working group.   This is something
    Ted> that I discussed with the MIF chairs as well.   It's difficult
    Ted> to say; if everybody on the list winds up being an active
    Ted> participant, then maybe Michael is correct.   I personally
    Ted> doubt that's so. 

I have recent poor experiences with large "design" teams that didn't
keep enough records, and did not communicate with the WG.  

I don't have a problem with a three person design team that has the
ability to schedule multiple afternoon work sessions a week and actually
get things done.  I don't see how this long list of people can actually
do this.  

    Ted> However, it may be that you or Michael are concerned that
    Ted> process isn't being followed.   It could be argued that the
    Ted> meeting Hui announced is really an interim working group
    Ted> meeting and not a design team meeting.   If that's the case,
    Ted> then the two week notice requirement applies. 

I'd rather that it wasn't an interim working group meeting.
I don't feel that the process isn't being followed: it hadn't even
occured to me that a cmte of the whole is effectively an interim
meeting.

I'm just concerned that such a large design team will be ineffective,
but let's go ahead, and see what turns up.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Apr 2013 08:12:42 +0100

Margaret,

> (1) The problem statement we published last year.

Meaning RFC 6418, I assume. Well yes, that is what the WG is supposed to
be doing - I assumed from Hui's message that this was a design team for
some specific subset of MIF's problem set.

> (2) The slides Ted Lemon presented in Orlando.

Again, I would have expected a reference to that it the announcement.
It was by no means obvious to people who did not attend.

As a matter of fact I very much like those slides, especially slide 9.

Unfortunately I believe what I said above: the scope of the underlying
problem is very broad and very hard to solve. It would take a lot more than
one email to really justify that statement, but I think the design team will
have to scope their work very narrowly to focus on partial solutions.

> In my experience, design teams have varied a lot both in formality and organization. 

Yes, but a few more words of explanation would have made things a *lot* clearer.

> During the first call, we will talk to the design team about how we want to organize ourselves.
> 

Thanks.

> However, it may be that you or Michael are concerned that process isn't being followed.   It could be argued that the meeting Hui announced is really an interim working group meeting and not a desi…

No, I have no problem with concept of a design team; a smaller group can often
do a better job on a multi-faceted problem than a big group.

      Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 4 Apr 2013 07:41:06 -0400

Hi Michael,

> keep enough records, and did not communicate with the WG.  

I am not sure how a design team could accomplish anything without communicating with the WG, since a design team is (from an IETF process standpoint) just  group of individuals who are working together to produce an IETF contribution.  It is up to the WG (1) whether to adopt that contribution as a WG work item, and (2) whether to publish it as an RFC…  

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 4 Apr 2013 09:11:05 -0400

Hi Brian,

> have to scope their work very narrowly to focus on partial solutions.

I think of the design team effort as an interim step between the problem statement and "solutions" actually…  I guess I'd describe it as better defining, in architectural terms, what we're talking about when we say "provisioning domain".  I'd expect the design team to write a document (or documents?), as contributions to be considered by the MIF WG that cover things like:

- What is a "provisioning domain"?  

- What sorts of information are configured on a per-provisioning domain basis (vs. per interface, per prefix or per-stack)?

- How does a provisioning domain relate to currently well-understood architectural entities in a TCP/IP stack (like physical interfaces, logical interfaces, address prefixes, etc.)?  

- How does a provisioning domain relate to currently well-understood processes in a TCP/IP stack, like DNS lookups (and split DNS), application-level destination address selection, selection of "referral pools" for things like SCTP, source address selection in the stack, interface selection in the stack, etc.?  

- What are the interesting properties of provisioning domains?  Are there different types of provisioning domains that it would be interesting to distinguish between from an architectural perspective (i.e. behind a NAT or not, walled garden or not, IPv4 or IPv6, etc.)?  

- Are there security issues specific to being attached to more than one provisioning domain?  Is there a useful notion around the idea that one provisioning domain may be more "trusted" than another?  What would the practical implications of that?

- How (conceptually) should transport layers or applications (i.e. anything above IP) usefully communicate with the IP stack about provisioning domains?  What information (at a conceptual level) can the IP stack provide that would be useful to upper layers, and what do the upper layers want to say to the stack about provisioning domains?  For example, should upper layers be able to force selection of a particular provisioning domain, like they can currently force selection of a source IP address, destination IP address or interface? If so, how does the application find out what provisioning domains are available and usefully select between them?  To what extent can applications benefit from being aware of provisioning domains?

- Is there a provisioning domain configuration problem at the application layer, too? (I think there is.)  i.e. Do applications have problems when they get DHCP configuration options from more than one provisioning domain, and if so what can/should they do about it?  Is there a need for the applications and stacks to have a common notion of what provisioning domains exist and how to refer to them, so that applications can use the configuration corresponding to the domain or their outgoing connections, etc?

I could go on, but I'd be surprised if we could reach consensus on the answer to all of those questions.

Thoughts?

Margaret

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 4 Apr 2013 11:21:44 -0500

Hi Ted,

I support the process. Yes the design team is very big, but that's what
happens in most cases.

What I see missing is who is going to lead the DT?

Regards,

Behcet

On Wed, Apr 3, 2013 at 6:48 PM, Ted Lemon <[email-masked]> wrote:

> Work that the IETF does has to be done in working groups, or as individual
> submissions, or by the IAB or the IESG.   Are you proposing that this work
> should be done in one of those other ways, rather than by the MIF working
> group, which was chartered to do this work and has already written a
> problem statement?   I don't think you were at the MIF meeting, so you may
> not have heard my presentation on this, but the slides are available, and I
> think the session was recorded.
>
> Ultimately, we definitely need something for the rest of the IETF, not
> just MIF, to review, but we have to have something for the IETF *to*
> review; that is the point.
>
> Michael did raise the question of whether this is really a design team, or
> the entire working group.   This is something that I discussed with the MIF
> chairs as well.   It's difficult to say; if everybody on the list winds up
> being an active participant, then maybe Michael is correct.   I personally
> doubt that's so.
>
> However, it may be that you or Michael are concerned that process isn't
> being followed.   It could be argued that the meeting Hui announced is
> really an interim working group meeting and not a design team meeting.   If
> that's the case, then the two week notice requirement applies.
>
> I don't have a strong preference for keeping this as a design team thing
> if people object.   I doubt the chairs do either.   It's certainly easier
> to schedule meetings if it's just a design team, and I think it's
> legitimate to claim that it's a design team.   But, frankly, you have more
> experience with this sort of thing than I do; if in your expert opinion
> this is an interim working group meeting and not a design team meeting, I
> think we ought to take that seriously.
>
> But as for the question of where to do the work, I think at least for the
> moment, unless you have some serious proposal to make, MIF is in fact the
> right place.
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Apr 2013 16:34:04 +0000

On Apr 4, 2013, at 12:21 PM, Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> wrote:
What I see missing is who is going to lead the DT?

I presume that's something we will discuss on the call.   I expect to have an advisory role, but I don't have the time to actually lead the team, so I hope someone emerges who is willing to do it and who the group can agree will be a good choice.

---

From: Keith Moore <[email-masked]>
Date: Thu, 04 Apr 2013 13:44:36 -0400

A design team is a lousy way to develop an architecture.  You need two 
or three people, max.

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 4 Apr 2013 15:09:59 -0400

Keith,

We are attempting to do this work in a way that is open to all of the willing/interested participants.  It is highly unlikely that all of the members of the design team will write text or participate equally, so in the end it may come down to a much smaller group of people doing the writing.  Hopefully they will be informed by discussions of the larger group, though.

That said, this design team does not have any sort of monopoly on making contributions to the MIF WG.  Anyone who wants to make a contribution on this topic is welcome do so. So, if you would like to get together a smaller group of people to contribute on this topic, please do!

Margaret

On Apr 4, 2013, at 1:44 PM, Keith Moore <[email-masked]> wrote:

> A design team is a lousy way to develop an architecture.  You need two or three people, max.
> 
>> Hello all,
>>  
>> MIF working group has formed a design team to work on the architecture issue.

---

From: Keith Moore <[email-masked]>
Date: Thu, 04 Apr 2013 16:01:14 -0400

What I'd like to see happen in the context of MIF is a collaborative 
effort to identify limitations in the Internet architecture that are 
exposed by the existence of hosts with multiple active Internet interfaces.

But the community shouldn't rely on a committee to recommend changes to 
the architecture.   Nor should an effort to identify possible changes in 
the architecture be narrowly scoped in the way that IETF WGs tend to be 
scoped.   Architectural changes need to consider broad effects, be able 
to touch multiple protocols and levels, and be able to address multiple 
kinds of limitations at once - while still being designed to facilitate 
an orderly transition and to work well during that transition.

So I think that actual proposals for changes to the Internet 
architecture need to come from individual authors (or small groups of 
authors) who don't have any WG or other endorsement for their efforts.   
But those proposals need to be informed by input from several different 
WGs and/or areas.   So MIF isn't the only group that needs to be 
identifying lists of architectural limitations.

Keith

>
> Keith,
>
> We are attempting to do this work in a way that is open to all of the 
> willing/interested participants.  It is highly unlikely that all of 
> the members of the design team will write text or participate equally, 
> so in the end it may come down to a much smaller group of people doing 
> the writing.  Hopefully they will be informed by discussions of the 
> larger group, though.
>
> That said, this design team does not have any sort of monopoly on 
> making contributions to the MIF WG.  Anyone who wants to make a 
> contribution on this topic is welcome do so. So, if you would like to 
> get together a smaller group of people to contribute on this topic, 
> please do!
>
> Margaret
>
>
> On Apr 4, 2013, at 1:44 PM, Keith Moore <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> [email-masked] <mailto:[email-masked]>

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 4 Apr 2013 18:04:22 -0400

One thing I may not have made clear in this message, and that seems to be missing from other parts of this discussion…

We are _not_ breaking new ground here and/or proposing that we move IP stacks in a direction that they haven't already moved.  Virtually every TCP/IP stack on every operating system from desktops to cell phones to embedded systems is _already_ dealing with Multiple Provisioning Domains in one way or another, some more successfully than others.  Existing solutions range from stack changes to connection managers to point fixes in specific problem areas (like DHCP and DNS).

The idea is to try to come up with common set of terminology and a common understanding of the Multiple Provisioning Domain concept at an architectural level, so that we can engage in a useful conversation about whether the IETF can/should standardize anything in this area.

Margaret