Hi Dawn, Thanks so much for your additional review. For short, there are indeed a number of typos and inconsistencies to be solved.
As for your point 2: the sentence means “However, Calendars can also represent any metric ++ with values ++ considered as time-varying by an ALTO Server”. The sentence is really about metrics here. For point 6, indeed, the Server may omit member “cost-type-names” if only one metric is requested. And a “legacy” ALTO client by the way will not request a calendar. I will respond inline in detail after the WG session. Cheers, Sabine From: Dawn Chan [mailto:[email protected]] Sent: Wednesday, July 12, 2017 10:37 AM To: [email protected] Cc: [email protected] Subject: Review of draft-ietf-alto-cost-calendar-02 Hi authors of cost calendar and all, I’ve just reviewed the new version of cost calendar and here are some feedbacks. 1. In Section 1 Introduction, “In case the ALTO Cost value changes are predicable over a certain period of time and …”, here the “predicable” should be “predictable”. 2. In Section 2.2.1 ALTO Cost Calendar for all cost modes, “However,Calendars can also represent any metric considered as time-varying by an ALTO Server”. I think this paragraph is discussing about cost mode rather than cost metric, so it might be better is we change the “metric” into “mode”. 3. In Section 3.1 Calendar attributes in the IRD resources capabilities, when explaining “cost-type-name”, I think it should be “cost-type-names”, it might be a typo. 4. In Section 3.3 Example IRD with ALTO Cost Calendars, "http://custom.alto.example.com/calendar/endpointcost/lookup": an endpoint cost map in which in which calendar capabilities are indicated for cost type names: "num-routingcost", "num-latency","num-pathbandwidth", "string-service-status”. Here one of the “in which” is a typo and should be deleted. 5. In Section 3.3 Example IRD with ALTO Cost Calendars, in the example of IRD, when specifying capabilities of resource "filtered-cost-map-calendar”, the “calendar-attributes” is the following: "calendar-attributes" : [ {"cost-type-names" : [ "num-routingcost", "num-pathbandwidth" ], "time-interval-size" : "1 hour”, "number-of-intervals" : 24 }, {"cost-type-names" : "string-service-status”, "time-interval-size" : "30 minute”, "number-of-intervals" : 48 } ] // end calendar-attributes Here the “cost-type-names”: “string-service-status” should be “cost-type-names”: [“string-service-status”] because “cost-type-names” is a JSONArray object. The same to the “cost-type-names” specified in resource “endpoint-cost-calendar-map” in this example. Another problem for resource “endpoint-cost-calendar-map” is that "endpoint-cost-calendar-map" : { "uri" : "http://custom.alto.example.com/calendar/endpointcost/lookup”, "media-types" : [ "application/alto-endpointcost+json" ], "accepts" : [ "application/alto-endpointcostparams+json" ], … “uses” : [“my-default-network-map"] } Here, the “media-types” and “accepts” are not JSONArray objects, so it should be "endpoint-cost-calendar-map" : { "uri" : "http://custom.alto.example.com/calendar/endpointcost/lookup”, "media-types" : "application/alto-endpointcost+json", "accepts" : "application/alto-endpointcostparams+json", … } And an endpoint cost map do not need the dependent network map. 6. Here are some inconsistency between the definition and example displayed. In Section 4.1.2 Calendar extension in Filtered Cost map responses, it extends the response format with an field CalendarResponseAttributes calendar-response-attributes <1..*>; The definition of CalendarResponseAttributes is: object{ JSONString cost-type-names; JSONString calendar-start-time; JSONString time-interval-size; JSONNumber number-of-intervals; [JSONNumber repeated;] [OPTIONAL] } CalendarResponseAttributes; But in the example in Section 4.1.3 “num-intervals” is used instead of “number-of-intervals”. The same typos happened in Section 4.2.3 and Section 4.2.4 (the examples of endpoint cost maps). Another point is that, the "cost-type-names” is NOT optional, but the examples in Section 4.1.3 and 4.2.3 doesn’t provide this information. My suggestion is that “cost-type-names” is an OPTIONAL field, for legacy ALTO requests (request which contains only one cost type), the “cost-type-names” is not necessary. But for multi-cost ALTO request, the “cost-type-names” MUST be provided. And since “cost-type-names” only contains a single value, maybe the name can be changed to “cost-type-name”. Above are some of my ideas, if there is some misunderstanding, please correct. Wish to here your reply. Best Regards, Dawn
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
