On 31 Oct 2011, at 13:49, Bill Roome wrote: > I don't have complaints, but I do have an observation: A client cannot > distinguish between "pids are invalid" and "pids are valid but this server > doesn't have reliable cost data for that pair."
Can this not be achieved by looking at the network map - if the pair of PIDs are in the version of the network map indicated by map-vtag but not in the cost map it is a valid PID but the server doesn't have reliable cost data for that pair. If the pair of PIDs are not in the version of the network map indicated by map-vtag they're not valid. ? Ben > > Does that bother anyone? > > - Bill Roome > > > On 10/27/2011 15:00, "[email protected]" <[email protected]> wrote: > >> Date: Thu, 27 Oct 2011 10:22:16 -0700 >> From: Richard Alimi <[email protected]> >> Subject: Re: [alto] Authoritative status of costs >> >> On Thu, Oct 27, 2011 at 9:22 AM, Vijay K. Gurbani <[email protected]> >> wrote: >>> On 10/25/2011 05:30 PM, Richard Alimi wrote: >>>> >>>> The intent would be that it just isn't there. So, something like this: >>>> >>>> ? ?{ >>>> ? ? ?"meta" : {}, >>>> ? ? ?"data" : { >>>> ? ? ? ?"cost-mode" : "numerical", >>>> ? ? ? ?"cost-type" : "routingcost", >>>> ? ? ? ?"map-vtag" ?: "1266506139", >>>> ? ? ? ?"map" : { >>>> ? ? ? ? ?"PID1": { "PID1": 1, ?"PID2": 5 }, >>>> ? ? ? ? ?"PID2": { "PID1": 5, ?"PID2": 1, ?"PID3": 15 }, >>>> ? ? ? ? ?"PID3": { "PID2": 15, "PID3": 1 ?} >>>> ? ? ? ?} >>>> ? ? ?} >>>> ? ?} >>> >>> Rich: The above is fine when the answer contains multiple PIDs >>> and one PID is omitted from the response. >>> >>> However, consider a query involving a singleton destination PID, i.e., >>> what happens if a client asked for the cost between a source PID >>> representing a transit network (say PID1) to a destination >>> PID representing the Internet (say PID5)? >>> >>> Is the right answer: >>> >>> (a) "PID1:" {} >>> (b) "PID1:" { "PID5" : NaN } >>> >>> where "NaN" is essentially an infinite cost (replace NaN by your >>> favorite token). >> >> I think I would opt for (a), since it should convey the same >> information and avoids us having to define a special identifier. >> Along the same lines, I could imagine just omitting the entire entry >> for the source PID in this case too. The end result is the same - the >> entry just doesn't exist when reconstructing the matrix. >> >> To keep the specification simple, perhaps it would be more clear to >> state it in the affirmative -- something to the effect of "the ALTO >> Server need only include source/destination pairs that exist" (and we >> can ensure that the existing rules are in line with this). Then ALTO >> Clients can just iterate through the returned JSON and fill in the >> entries in the matrix that they find (and just not complain about >> missing ones). The actual syntax of the JSON matters less then - >> servers could either omit the entire row for the source PID, or have >> the row empty, whatever. >> >> Any complaints with that? >> Rich > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
