Re: New version of charter text

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

Hi Pasi,

El 09/02/2005, a las 12:24, Pasi Sarolahti escribió:

> [I'm catching up a bit late... The discussion was about APIs]
>
> On Thu, 2005-01-27 at 11:17, ext Kurt Erik Lindqvist wrote:
>
> > On 2005-01-26, at 21.04, Erik Nordmark wrote:
> > > 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 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?
>
> There might be a bit more to this than just application layer events.
> I'd think that many systems might still want to use the conventional
> socket API for shim6 communication. Would the semantics of the
> traditional socket API functions be affected?
>
> Take bind(), for example? Would it still be possible to bind to a
> selected locator/IP address (and what would that mean), or would bind
> work on an ULID level, as one would expect if there was a new address
> family?

this is good point, but, imho , It is not very likely that we end up 
with ULID that are not locators. So i think that the bind will apply to 
any address available, which can be used both as a locator and as 
identifier.

I mean, as i understand it, ULID that are also locators provide a 
better support for refferals.
The remaining case where we end up with only locators, is the case 
where we use N-square addresses approach to perform demux of data 
packets, but my understanding is that this approach does not have much 
support (and in any case, i am not sure it would make much sense to 
allow a bind to one of the locators only addresses used in the n-square 
approach (this comment is not general about locators but just for the 
case of the locators resulting from the n-square approach))

> Even though APIs are not generally in the IETF scope, it might be worth
> it to discuss possible interactions with the traditionally used APIs,
> and what applications can expect from the behavior of the underlying
> shim6.

agree, but i guess that the charter leaves some space for this 
discussion

regards, marcelo


> Don't know if this would be a charter issue, though, or could it
> be included in the other planned documents, if considered useful.


> - Pasi