Re: New version of charter text

[Kurt Erik Lindqvist <kurtis@kurtis.pp.se>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 2005-01-26, at 21.04, Erik Nordmark wrote:

> 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.

Ok, I think I misunderstood Marcelo then. However, I would assume that 
at least some text on application layer 'events'  should be included in 
either the architecture or the protocol document?

- - kurtis -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBQfixtaarNKXTPFCVEQK9mwCfStQYy4PD+JpXBfO6QwxzlOOxnBIAn05f
pZnwlH0NYFdvbjJ0mpz53V36
=jTLi
-----END PGP SIGNATURE-----