Re: [altoext] altoext: Call for participation

Jan,

On 8 Mar 2012, at 15:58, Jan Seedorf wrote:

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

I am thinking through a use case where certain policies could be expressed as ALTO cost maps. 

There has always been the implicit assumption in ALTO that the ALTO server could provide different maps to different applications. This is an extension of that concept but where a single application needs to retrieve multiple cost maps (for the same network map) depending on circumstance but the ALTO server won't know the circumstance so cannot determine from the application's ALTO request which cost map to serve.

I could achieve something similar by minting a different cost-type per cost map (linked to a the same network map) but that seems ugly compared to incorporating something like a name/title property in an IRD entry.

Ben

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