Richard
On 29.05.2015 20:24, Y. Richard Yang wrote:
On Saturday, May 30, 2015, Wendy Roome <[email protected]
<mailto:[email protected]>> wrote:
I thought RFC 7285 required order-consistency between numerical &
ordinal modes for the same metric. But I cannot find that
requirement. Too bad! I would have added that if I realized it
wasn't there.
I remembered that the removal of the consistency requirement was a
conscious decision, not an omission, to reduce the load of consistency
checking. I buy your point below of a server supporting only one, in
the sense of providing the maximum allowed by the privacy concern.
Regarding supporting both in the interop, I will be happy to wait a
bit to hear others' opinions.
I agree that providing both numerical and ordinal mode for the same cost
metric makes little sense from a real world perspective. For the
interop, I think both should be covered. Since Wendy already proposed
cost maps for routingcost and hopcount in her initial mail, I suggest
providing a numerical cost map for one metric and an ordinal for the other.
Hans
Richard
But if we take off our lawyer hats, and look at RFC 7285 as an
agreement between friends, rather than a formal contract between
adversaries, then I think it is reasonable to say that if the
ordinal mode costs do not preserve the order of the numerical
costs, then that server is wrong.
Similarly, a router is allowed to drop packets, and I do not think
there is any formal requirement that it cannot drop *every*
packet. So theoretically you could glue eight jacks to a block of
hardwood and market it as a router. Maybe you could avoid getting
charged for fraud. Just don't expect anyone to buy more than one! :-)
And looking at it from a real-world perspective, the whole concept
is irrelevant. The only reason for defining ordinal mode is to
allow a server to hide the numerical costs. For example, if the
numerical costs to three PIDs are 10, 11 and 100, a client can
deduce that the middle pid is close. If the costs are 10, 99 and
100, a client can deduce that the middle pid is distant. If the
ordinal costs are 1,2,3, a client cannot deduce anything other
than 1 is better than 2 is better than 3.
So if a server offers numerical costs, there is no advantage for
it to also offer ordinal mode costs.
And if numerical costs are available, there is no advantage to a
client to use ordinal costs. Maybe if the client could assume the
ordinal costs are 1,2,3,… -- but the client cannot.
So in practice, no server will offer both numerical & ordinal mode
for the same metric.
That means a formal compliance test should only require one mode
or the other, but not both. However, keep the interop simple,
unless someone objects, I suggest we require both modes.
- Wendy
From: "Y. Richard Yang" <[email protected]
<javascript:_e(%7B%7D,'cvml','[email protected]');>>
Date: Fri, May 29, 2015 at 12:24
To: Wendy Roome <[email protected]
<javascript:_e(%7B%7D,'cvml','[email protected]');>>
Cc: "[email protected]
<javascript:_e(%7B%7D,'cvml','[email protected]');>" <[email protected]
<javascript:_e(%7B%7D,'cvml','[email protected]');>>, "Bertz, Lyle T
[CTO]" <[email protected]
<javascript:_e(%7B%7D,'cvml','[email protected]');>>, Hans
Seidel <[email protected]
<javascript:_e(%7B%7D,'cvml','[email protected]');>>,
"[email protected]
<javascript:_e(%7B%7D,'cvml','[email protected]');>"
<[email protected]
<javascript:_e(%7B%7D,'cvml','[email protected]');>>
Subject: Re: [alto] Interop test
and it can verify that ordinal cost values are consistent with
the order of the known numerical values.
This is a reasonable validation. An issue is that RFC7285
specifies only that "An ALTO server MUST support at least one of
the following modes: numerical and ordinal." I believe that
RFC7285 chose to not specify the consistency between the two
modes. Hence, this is beyond compliance, right? Hence, I feel that
separating RFC7285-conforming and beyond can be helpful.
--
Richard
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
