Wendy, Great work! Here are some early comments.
- Page 4: "If a server provides a numerical-mode cost map, ..." => "If a server provides a numerical-mode cost map for the "routingcost" metric.," The reason is to make clear that Figure 2 is for the only routingcost metric only. - Page 4: "If a server provides an ordinal-mode cost map, the server may use whatever values it wants, provided the ordinal values preserve the order of the numerical values. " I see that there are duplicate values in Figure 2 (e.g., 75.0). A question is to define the meaning of "preserve", as RFC7285 does not define it, I believe. Here is an attempt in defining it precisely. First, for non-equal case, we should have num[x] > num[y] => ord[x] < ord[y]. An issue is if we define the case for num equal, e.g., num[x] == num[y] => ord[x] == ord[y]. I assume that we have it? - Page 4: Can a server provide both a numerical and an ordinal cost map? - Page 5: "a numerical-mode cost map MUST use these values, and an ordinal-mode cost map may use any values consistent with this ordering." Page 4 used the word preserve and here it is consistent. How about the draft uses one word, say consistent, and the draft defines the meaning consistent as above? Similar small consistent use for the alternate map. - When I read Page 7: "A server MAY provide whatever additional resources it desires, as long as they are consistent with the network maps, cost maps and endpoint properties defined in Section 2. ", a question of 3 network maps came to mind. I liked that you clarified on page 8. - Page 7: "Cost Map resources for the "routingcost" and/or "hopcount" metrics, in either "numerical" or "ordinal" modes, using the values defined above." How about clarify that it is for the alternate network map? - Page 9: "However, each client MUST be able to verify the default network map and the associated "routingcost" cost map." Does this handle the case of both modes, if provided? Overall, a great design, and I am looking forward to seeing the ECS test cases as well :-) Richard On Thu, Jun 4, 2015 at 3:34 PM, Wendy Roome <[email protected]> wrote: > To get the ball rolling on an ALTO interop test, I have submitted > draft-roome-interop-ietf93-00. Please, please, someone else please read it. > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Droome-2Dinterop-2Dietf93_&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=bqET3V84WZLd20R9K89VK4Hm0aQzcWdZF7f9JgZZ42Q&s=xMKyCEnwH7PvUBYG16p4mpynr8QXYjHQakn4U8R_mK4&e= > > It specifies quite a lot: two network maps, two cost metrics, and a custom > property. However, only *required* resources are the default network map, > one routingcost cost map (numerical or ordinal), and an EPS for the > default network's pid property. Everything else is optional. > > - Wendy Roome > > > > _______________________________________________ > alto mailing list > [email protected] > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=bqET3V84WZLd20R9K89VK4Hm0aQzcWdZF7f9JgZZ42Q&s=0CuB6ojyak7XxLmBQ2liCZzG5JiQaSfxqSPnBloJLX4&e=
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
