Re: [altoext] altoext: Call for participation

Ben,

Quick question:
> - 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.
Why would you need that?

 - Jan

> -----Original Message-----
> From: altoext-bounces@ietf.org [mailto:altoext-bounces@ietf.org] On
> Behalf Of Ben Niven-Jenkins
> Sent: Tuesday, February 07, 2012 8:43 PM
> To: Vijay K. Gurbani
> Cc: altoext@ietf.org
> Subject: 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
> 
> _______________________________________________
> altoext mailing list
> altoext@ietf.org
> https://www.ietf.org/mailman/listinfo/altoext