Re: [mif] Adoption of API document as the MIF WG document

[Ted Lemon <[e-mail]>]

Are we on the same page?

The high-level API probably shouldn't expose interfaces—it should simply attempt to make a connection when you hand it a name.   Two proposals for a high-level interface that have been discussed are the MIF Happy Eyeballs API, and the connect_to_name API.   With both APIs, you basically hand the API a name and it hands you back a socket connected to the host addressed by that name.   It does all the fiddling under the covers to figure out which interface to use and which DNS servers to use and which protocol to use.

What you described is more like the low-level API.   One distinction that you didn't mention in your description is that we intend have a lower level of granularity than the interface.   Because it's possible for more than one address family to be attached to an interface, and because it's possible for an interface to be attached to a multi-homed network, we've defined a "provisioning domain" which is the place where things like DNS server configuration happen.   There can be more than one provisioning domain per interface; provisioning domains never span interfaces.

You mention an additional concept in your summary: a routing table per type of traffic.   We have not talked about this, and I don't know that it's in scope.   I would very much like to know what other participants think about this, and how it might be used.   It's not really on my radar, but this is good: I'm by no means an expert on this problem space, and my hope was that people would read the MIF API doc and notice what's missing and bring it up here on the mailing list.