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.
>(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.
- Bill Roome
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
