Hi Sebastian, On Wed, Jul 24, 2013 at 2:48 PM, Sebastian Kiesel <[email protected]>wrote:
> Hi Richard, > > On Wed, Jul 24, 2013 at 01:57:31PM -0400, Y. Richard Yang wrote: > > Hi Sebastian, > > > > On Wed, Jul 24, 2013 at 11:33 AM, Sebastian Kiesel <[email protected] > >wrote: > > > > > I don't think we need an extension to the discovery procedure for that. > > > As I said, I think it would just shift the problem, not solve it. > > > > > > In a deployment scenario where a network operator actually can clearly > > > decide that some group of hosts "A" should use map_A as default > > > (unless they know better and want to override it) and group "B" should > > > use map_B, they can configure two IRDs, e.g. > > > altoserver.isp.example/A/ird and altoserver.isp.example/B/ird > > > and let the discovery procedure return the right URI for the each > > > group member. > > > > > > Then, the altoserver.isp.example/A/ird must express that map_A is > > > the default map for all clients that have discovered this IRD. > > > The ALTO protocol must provide the possibility to express that. > > > > > > > > I see two ways to express this in the ALTO protocol (not through another > > configuration channel): > > > > (1) prune: delete map_B from the IRD given to hosts "A", and delete map_A > > from the IRD given to hosts "B". This assumes that each hosts group needs > > only one map, e.g., a fish-eye map for each of the two coasts. > > > > (2) mark one as the default, which I believe that we will add as a > > consensus on the mailing list. In other words, the IRD page is still > > dynamic, depending on the receiver. > > > > Which approach to take will then be a deployment's decision. > > I support adding the neccessary protocol elements needed to > support (2). > > Great. It appears that we have good support for adding (2) now. > Speaking of dynamically generated IRDs: how would the ALTO server > identify the client in order to generate an IRD specifically for it? > > This could be done based on the source IP address of the HTTP > connection, or based on an X-Forwarded-For header in HTTP. For requests originated from end users, the preceding can serve as the customization parameter. > But how > would we do that in the third-party use case, e.g., if a P2P tracker > issues ALTO queries on behalf of (topologically distant) resource > consumers? Is there a way to explicitly tell the resource consumer's > ID/IPaddress when requesting an IRD? > Third party is a more challenging case. It is interesting that you appear to suggest that the requestor of the IRD can indicate the end user that the request is for, say in X-Forwarded-For. This will require that the ALTO Server check the field, and the (third-party) requestor set the field. Interesting idea. I am not sure if we want to take on this in the base protocol. But it is quite interesting, and I never thought about this possibility. Thanks! Richard > > Sebastian >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
