On Tuesday, June 2, 2015, Hans Seidel <[email protected]> wrote: > Richard > > On 29.05.2015 20:24, Y. Richard Yang wrote: > > > On Saturday, May 30, 2015, Wendy Roome <[email protected] > <javascript:_e(%7B%7D,'cvml','[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. >
This proposal makes sense to me. I support it. Richard > > > 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]> >> Date: Fri, May 29, 2015 at 12:24 >> To: Wendy Roome <[email protected]> >> Cc: "[email protected]" <[email protected]>, "Bertz, Lyle T [CTO]" < >> [email protected]>, Hans Seidel <[email protected]>, " >> [email protected]" <[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 > > > -- Richard
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
