Hi,
yes, I think it is necessary to distiguish between both cases. For some
costs, information may be unavailable on some source/dest pairs where as
it is for others. So I propose a specific tag for unavailable
information such as "NAv" for "not available" or whatever other tag
signifying "not available".
Sabine
Bill Roome a écrit :
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
--
---------------------------------------------------------
Sabine RANDRIAMASY
Alcatel-Lucent Bell Labs France
Centre de Villarceau
Route de Villejust - 91620 NOZAY - FRANCE
E-MAIL : [email protected]
TEL: +33 (0)1 30 77 27 45
(On Net) 2 103 27 45
---------------------------------------------------------
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
