[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New version of charter text



Kurt Erik Lindqvist wrote:

what about a new shim API? I mean a new API that allows the apps to communicate with the shim and inform about failures or other stuff, would this be within scope?


Well, I added the transport layer "hints" as proposed by Erik, perhaps we should rewrite this into simply "shim layer API" ?

I think the charter is reasonably clear on the hints/interactions with failure detection.


I read Marcelo's comment as a more application layer thing, i.e. a question whether we should work on an abstract API (not a binding to a particular programming language) which applications can use to
- observe what is going on below (which locator pair is used now? what interface - GPRS or 802.11 - is being used?),
- express preferences (don't even try over GPRS type things) or some other way to control things


I think that area is interesting, but could be a rat hole. Those issues are more about interface selection and performance characteristics of the path, then about multihoming. That is, such approaches would be useful (or not) even in the absence of shim6 below. There might be some added motivation for addressing this in the multihoming context, if multihoming causes more dynamic variation in the paths that are being used over time than what we see in today's. However, in the case of site multihoming, I think the variation will not be much different than IPv4 single prefix multihoming today when routing selects different paths; it is the host multihoming case which potentially makes this a more pressing issue - see the GRPS vs. WLAN examples above.

I don't see a need to add anything about this to the charter though.

   Erik