Re: [altoext] altoext: Call for participation

Hi Vijay,

On 7 Feb 2012, at 16:58, Vijay K. Gurbani wrote:

> Folks: Enrico and I have put together a short draft that explores the
> evolution and extension of ALTO as a protocol [1].  At the Taipei
> IETF, there was a discussion on the ALTO evolution towards the tail end
> of the session.

<snip>

> It will be great if we can foster discussions towards extending
> ALTO in new domains culminating in a BoF in Paris.  Your views
> on [1] are solicited as part of a larger discussions on extending
> ALTO.  We need to form a "community of interest" to identify a
> possible problem statement and the work to be done.

Firstly I have to say I'm a little confused as to what is driving this level of "formal" structure as I think many of the items listed in your draft could be considered as relatively incremental changes that could be handled in the normal way within the ALTO WG today by folks writing drafts etc.

However there is at least one thing your draft touches on that I think is more architectural in nature which is extending ALTO to carry large amounts of application data, e.g. what content is on a cache, what applications are installed in a server etc. and I think we need to consider whether ALTO is really the best mechanism for conveying that information and if it's decided that ALTO is a good fit then whether the use cases are best served by overloading existing ALTO semantics (e.g. end point properties) or by extending ALTO with additional information services to deliver that data.

>  Folks who would
> like to produce drafts on their positions are encouraged to do so as
> part identifying the problem statement and outlining the work to be
> done.

I have a couple of use cases I'm thinking about that aren't very well baked yet and I won't have time to write any drafts before Paris but in brief are:

- The ability to "name" cost maps so that a single Information Resource Directory can link multiple cost maps with the same cost type & cost mode to a single network map.

- The ability to have a static PID identifier/property as today an ALTO server can change PID names at will and if an ALTO client needs to tie PIDs to something else it can't rely on the PID name to maintain the mapping it requires. 

Ben

> 
> Thanks,
> 
> [1] http://tools.ietf.org/html/draft-marocco-alto-next-00
> 
> - vijay
> -- 
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
> Web:   http://ect.bell-labs.com/who/vkg/
> _______________________________________________
> altoext mailing list
> altoext@ietf.org
> https://www.ietf.org/mailman/listinfo/altoext