Hi Richard,

> The redistributed ALTO information should indicate the ALTO Server from
> which
> it originated, and the parameters that were supplied to request that
> information.  
Right, this is important to prevent misinterpretation of redistributed ALTO 
information.

> For example, when looking at a listing of the available
> ALTO
> information, an peer can look for the ALTO server it would have
> contacted
> otherwise (perhaps, hostname:port of the ALTO server), and grab the
> ALTO
> information pertaining to that server.
> 
> This "listing of available ALTO information" could be posted on a
> public
> website (available as direct downloads, torrent files, etc).  Another
> option
> would be to distribute via a DHT (a la Vuze's Distributed Tracker)
> where the
> key is hash("alto:<hostname>:<port>:networkmap").  Something similar
> could be
> used to request the full cost map:
> hash("alto:<hostname>:<port>:costmap:<costtype>")
> 
> To redistribute only a portion of the cost map (e.g., a row of the
> matrix from
> the perspective of a single PID), then the map could be stored at
> hash("alto:<hostname>:<port>:costmap:<costtype>:<pidname>").

Sorry, I am not completely following you: are you saying that such a "listing 
of available ALTO information" is redistributed ALTO information posted on a 
website? So someone could program an ALTO-grab-all-crawl-bot and post all 
information retrieved on a website, right? Clearly nobody can prevent something 
like that, that is why it is important that ALTO information is not only 
authenticated and its integrity protected (i.e., signed), but also that the 
digital signature contains an expiration time and the complete input variables 
for the generated ALTO information. Still, what if an ALTO server realizes it 
was misconfigured or something changes unexpectedly, than the ALTO server has 
no way of controlling its already redistributed, now "wrong" information. What 
do you think?

 - Jan


> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Richard Alimi
> Sent: Mittwoch, 12. August 2009 17:43
> To: [email protected]
> Cc: Jan Seedorf
> Subject: Re: [alto] [ALTO] Comments on[draft-stiemerling-alto-info-
> redist-00]
> 
> Hi Jan,
> 
> > > --  "However, there is no mean for the peers to verify whether the
> > > information provided is actually intended
> > >    for their usage nor if the information is actually accurate at
> their
> > > current topological position in the Internet "
> > >
> > > Surely, it's very important to verify the usage and the origination
> of
> > > the
> > > redistributed information.
> > > I don't think accurate information needs to be redistributed.
> > > Actually, there are kinds of general information that are suitable
> and
> > > helpful to be redistributed.
> > > E.g. kinds of cost between a particular PID and other PIDs is
> useful to
> > > all
> > > the peers in the particular PID.
> > > What we should do is to guarantee that general information is
> > > redistributed
> > > within the PID area(maybe multicast) or to guarantee that peer only
> > > request
> > > its PID general information.
> >
> > Agreed, there may be certain use-cases where redistribution may not
> be
> > problematic. But consider the case where certain information provided
> by an
> > ALTO-server is _relative_ to that ALTO-server's location in the
> network. If
> > such information gets redistributed, an ALTO-client not being aware
> of the
> > original ALTO-server's location may misinterpret this information. In
> other
> > words, by redistributing guidance information, its original semantic
> might
> > be disguised. I think this is the problem being addressed in Martin's
> draft
> > and specifically in the quote above.
> 
> The redistributed ALTO information should indicate the ALTO Server from
> which
> it originated, and the parameters that were supplied to request that
> information.  For example, when looking at a listing of the available
> ALTO
> information, an peer can look for the ALTO server it would have
> contacted
> otherwise (perhaps, hostname:port of the ALTO server), and grab the
> ALTO
> information pertaining to that server.
> 
> This "listing of available ALTO information" could be posted on a
> public
> website (available as direct downloads, torrent files, etc).  Another
> option
> would be to distribute via a DHT (a la Vuze's Distributed Tracker)
> where the
> key is hash("alto:<hostname>:<port>:networkmap").  Something similar
> could be
> used to request the full cost map:
> hash("alto:<hostname>:<port>:costmap:<costtype>")
> 
> To redistribute only a portion of the cost map (e.g., a row of the
> matrix from
> the perspective of a single PID), then the map could be stored at
> hash("alto:<hostname>:<port>:costmap:<costtype>:<pidname>").
> 
> --
> Richard Alimi
> Department of Computer Science
> Yale University
> _______________________________________________
> alto mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to