On Wed, Sep 21, 2011 at 11:15 AM, Bill Roome <[email protected]> wrote:
>
>
> On 09/21/2011 13:36, "Richard Alimi" <[email protected]> wrote:
>
>>(1) In the model you propose, this is basically turning what is today
>>a "soft failure" condition where the client gets partial and perhaps
>>older information back (and is given the opportunity to immediately
>>detect it and correct it) into a "hard failure" condition, where the
>>client gets no information at all.
>
> Ah! But I claim that the returned information could be utterly useless --
> and the client can't tell unless the client re-gets the network map.
>
> Specific example: A client asks for the costs from PID1 to PID2 and PID3,
> because the client's IP address is in PID1. Now suppose the map changes
> and the client is no longer in PID1. Sure, the client gets information
> back, but it's irrelevant and misleading.
Right - so as a client, I could immediately detect that case, store
the retrieved information, and then update the network map. That would
be in comparison to getting an error, going to get a new network map,
then repeating the request.
>
>
>>(2) Maybe its a philosophical difference, but I sort of assume that
>>clients parsing maps understand what the version tag means (since it
>>is communicated as a sibling to the cost map and cost type, and not
>>hidden anywhere). Do you think this is a matter of protecting clients
>>from not obeying the protocol? Or something else?
>
> Yup, it's philosophy -- I think the server should protect the client from
> a class of potential errors.
>
> The alternative is to say in {7.7.3.2} that the client must verify that
> the vtag in the response matches the vtag in the map it used to select
> those PIDs. If not, the client must re-get the map (or at least those
> PIDs) and verify that they haven't changed.
Yes - at a minimum we can add cautionary text, but it'd be interesting
to see what others say here too.
Thanks!
Rich
>
> - Bill Roome
>
>
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
