Re: [alto] Review of draft-ietf-alto-cost-calendar-02

["Randriamasy, Sabine (Nokia - FR/Nozay)" <[e-mail]>]

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:[e-mail]]
Sent: Wednesday, July 12, 2017 10:37 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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