I suggest a slightly different approach: we specify the numerical values for routingcost & hopcount. Then let each server decide whether it wants to present numerical or ordinal versions. The only requirement is that a server MUST provide a routingcost cost map, either numerical or ordinal. Servers can provide whatever additional resources they want, and clients can fetch & validate any resources they recognize.
We do not define ordinal values, but allow servers to assign whatever values they want as long as the ordering is consistent with the numerical values we specify. That is sufficient to allow a client to verify the ordinal values. - Wendy Roome From: Hans Seidel <[email protected]> Date: Tue, June 2, 2015 at 03:00 To: "Y. Richard Yang" <[email protected]> Cc: Wendy Roome <[email protected]>, "Bertz, Lyle T [CTO]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [alto] Interop test On 29.05.2015 20:24, Y. Richard Yang wrote: > 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. 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
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
