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