Re: New version of charter text

[Erik Nordmark <erik.nordmark@sun.com>]

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