Re: [mif] The formation of the design team

[Margaret Wasserman <[e-mail]>]

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

On Apr 4, 2013, at 9:11 AM, Margaret Wasserman <[e-mail]> wrote:

> 
> Hi Brian,
> 
> On Apr 4, 2013, at 3:12 AM, Brian E Carpenter <[e-mail]> wrote:
>> 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.
> 
> 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
> 
> 
>