On Saturday, May 30, 2015, Wendy Roome <[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. 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
