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."
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
