Hi Ben, On Tue, Jun 28, 2011 at 8:47 AM, Ben Niven-Jenkins <[email protected]> wrote: > Rich, > > On 28 Jun 2011, at 07:33, Richard Alimi wrote: >> On Mon, Jun 27, 2011 at 1:43 PM, Ben Niven-Jenkins >>> For example, if my client uses the network map service to obtain the >>> complete network map and discovers that a particular IP address exists in >>> two PIDs (i.e. a longest prefix match would return two PIDs), how is my >>> client supposed to interpret the network map: >>> >>> a) Does it mean the entire network map is invalid and I should throw it all >>> away? >>> b) Does it mean those PIDs containing the duplicate IP address are invalid >>> and I must disregard their complete contents but the rest of the map is >>> useable? >>> c) Does it mean that those PIDs containing the duplicate IP address are >>> valid (along with the rest of the network map) provided I disregard the >>> duplicate IP addresses? >>> d) Does it mean I am allowed to make a local decision as to which PID is >>> the correct PID for that IP address? >>> >>> IMO (a) & (b) require a client to fully validate the network map looking >>> for duplicate IP addresses before using any portion of it can be considered >>> useable. (c) & (d) allow a client to discover & recover from an >>> inconsistency at "run time". >>> >>> Validating the entire network map before using it may not have a >>> significant performance impact for an ALTO client in some P2P software >>> where the number of PIDs and IP prefixes in the network map is likely to be >>> small, however for some CDN use cases it could well be the case that there >>> are thousands of PIDs and millions of individual prefixes in a single >>> network map. A simple example would be if one wanted to represent in an >>> ALTO network map a geo-location database containing the entire global >>> routing table. >>> >> >> If I were implementing a client, I would choose (d) in the interest of >> Postel's Law. I would also send an email to the ALTO Server's >> provider or implementer notifying them that it is not compliant and >> that they should stop it :) >> >> Saying something in the protocol is okay with me, but a concern is >> getting into the habit of trying to find and suggest possible >> behaviors in case any of the MUST / MUST NOT's in the document are >> violated. > > IMO it's not about trying to find & suggest possible behaviours in case of > all MUST/MUST NOTs being violated, it's about providing guidance on what > constitutes an invalid ALTO response and whether a violation of the > specification in a response means the entire response should be treated as > invalid or not. > > I'd suggest that the fact the original question was raised as part of > documenting a set of interoperability test cases would suggest the current > draft could benefit from guidance on what does/does not constitute and > invalid response, however if the WG's preference is that clients should "just > apply Postel's law" and define for themselves what constitutes an invalid > response I'll accept that. >
For the purposes of the interop test, i think such responses should be considered invalid, but I wouldn't fault an ALTO Client implementation for not doing the validation. I'm just not convinced we should be attempting to give such advice for real-world deployments in the draft though. But, as I mentioned, adding something in the draft if the WG wishes. Thanks, Rich > Ben > > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
