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

[Dawn Chan <[e-mail]>]

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