Hello Dawn, Thank you so much for your additional proof reading of the draft. Please find my answers inline and let me know if they address your comments. A revision is in progress and will integrate your feedback.
Thanks Sabine From: Dawn Chan [mailto:[email protected]] Sent: Wednesday, July 12, 2017 10:37 AM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[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”. [SR ] done, thanks 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”. [SR ] I see your point. How about re-phrasing as follows: “However, ALTO Calendars can also represent metrics in other modes and having time-varying values.” 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. [SR ] yes, thanks 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. [SR ] done, thanks 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. [SR ] Yes, thanks. 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", … } [SR ] Yes, thanks. And an endpoint cost map do not need the dependent network map. [SR ] Yes, thanks. 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). [SR ] Yes, thanks. Will harmonize with number-of-intervals 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), [SR ] a suggestion: if a calendar request is done for only one cost type it is preferable to refer to “single cost” requests, because the specification of a calendar for a single metric goes beyond the RFC7285. the “cost-type-names” is not necessary. But for multi-cost ALTO request, the “cost-type-names” MUST be provided. [SR ] Agree with your suggestion. Indeed in the examples, “cost-type-names” is only present for multi-cost requests. So let’s make it mandatory for multi-cost requests. And since “cost-type-names” only contains a single value, maybe the name can be changed to “cost-type-name”. [SR ] “cost-type-names” may contain several names if calendar attributes are the same several cost types. For instance, on IRD section 3.3, a multi-cost request for filtered cost-map may be placed for the cost-types named “num-routingcost” and “num-pathbandwidth”. Above are some of my ideas, if there is some misunderstanding, please correct. Wish to here your reply. [SR ] great thanks Dawn, cheers, Sabine Best Regards, Dawn
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
