Re: [altoext] altoext: Call for participation

[Jan Seedorf <[e-mail]>]

Hi ben,

Thanks, I understand better now. Seems useful, but indeed (as you point out yourself), your enhancement could be achieved by having cost-types named accordingly, e.g. with an extension / suffix. But I got the point.

Jan

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Ben Niven-Jenkins
> Sent: Thursday, March 08, 2012 6:11 PM
> To: Jan Seedorf
> Cc: [e-mail]; Vijay K. Gurbani
> Subject: 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: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Ben Niven-Jenkins
> >> Sent: Tuesday, February 07, 2012 8:43 PM
> >> To: Vijay K. Gurbani
> >> Cc: [e-mail]
> >> 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} / [e-mail]
> >>> Web:   http://ect.bell-labs.com/who/vkg/
> >>> _______________________________________________
> >>> altoext mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/altoext
> >>
> >> _______________________________________________
> >> altoext mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/altoext
> 
> _______________________________________________
> altoext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/altoext