Re: [mif] The formation of the design team

[Margaret Wasserman <[e-mail]>]

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