Subject: [alto] Review of draft-ietf-alto-cost-calendar-01

From: Yichen Qian <[email-masked]>
Date: Fri, 30 Jun 2017 01:54:57 +0800

Dear authors,

I think it’s quit useful to provide cost calendar for the users. Here’s my review of this draft. 

1. One concern is that the query result of Cost Calendar is not only related to regular data changes, but also can be affected by some unexpected topology changes, say link failures. So some cost in Cost Calendar can be abnormal and may mislead the user to do the inappropriate choice.

2. In the current design, the ALTO client only chooses if it needs the calendar.  Is it possible that the ALTO server has several options of different combinations of “time-interval-size” and “number-of intervals” for ALTO client to choose for more fine-grained Cost Calendars?

Other detailed modification:

In the 3rd paragraph of section 2.2, “A calendar and its capabilities are associated to a given information resource”
- associated to -> associated with

In the 1st paragraph of section 3, “A calendar is associated to an information resource rather than a cost type.”
- associated to -> associated with

In the 1st paragraph of section 3.1, ”by an object of type 'CalendarAttributes', associated to this Cost Type and specified below.”
- associated to -> associated with

In the 3rd paragraph of section 3.1, ”on this "cost-type-name" for this ressource entry.”
- ressource -> resource

In the 1st paragraph of section 4.1.3, ”as specified in the IRD to shedule its bulk data transfers as described in the use cases.”
- shedule -> schedule

In section 4.2.2, “include the same addifional member "calendar-response-attributes" as …”
- addifional ->additional

In the 1st paragraph of section 4.2.3, “Let us assume an Application Client is located in an end sytem with limited resources and …” 
- sytem -> system

In the 2nd paragraph of section 4.2.3, “the 'routingcost' is assumed to be time sentitive with values provided as ALTO Calendars.”
- sentitive -> sensitive

In the 3rd paragraph of section 4.2.3, "The ALTO Client associated to the Application Client …”
- associated to -> associated with

In the 4th paragraph of section 4.2.3, “the sollicited ALTO Server has …”
- sollicited -> solicited

In the 2nd paragraph of section 4.3, “An ALTO Server aquiring cost values in limited time intervals …”
- aquiring -> acquiring

In the 6th paragraph of section 5.1, “a small topology with low density and low capacity that carries inpredictable”
- inpredictable -> unpredictable

In the 3rd paragraph of section 5.2, “the interaction with Endpoints can be orchestratrated and scheduled at the time slots …”			
- orchestratrated -> orchestrated

The subtitle of section 6.2, “Information for IANA on proposed Endpoint Propeeries”
- Propeeries -> Properties

Best wishes,
Eason

---

From: "Randriamasy, Sabine (Nokia - FR/Nozay)" <[email-masked]>
Date: Fri, 30 Jun 2017 18:23:05 +0000

Hi Qian,

Thanks for your feedback. Please see my answers inline
Thanks,
Sabine

>>-----Original Message-----
>>From: Yichen Qian [mailto:[email-masked]]
>>Sent: 29 June 2017 19:55
>>To: IETF ALTO <[email-masked]>; [email-masked]
>>Subject: Review of draft-ietf-alto-cost-calendar-01
>>
>>Dear authors,
>>
>>1. One concern is that the query result of Cost Calendar is not only related to
>>regular data changes, but also can be affected by some unexpected topology
>>changes, say link failures. So some cost in Cost Calendar can be abnormal and
>>may mislead the user to do the inappropriate choice.

[SR     ] Indeed, link and network failures are be essence not predicable and ALTO Clients 
should be notified as soon as possible. One option as I suggested to Geng is to define an appropriate 
service in draft-ietf-alto-incr-update-sse-05
>>
>>2. In the current design, the ALTO client only chooses if it needs the calendar.
>>Is it possible that the ALTO server has several options of different
>>combinations of “time-interval-size” and “number-of intervals” for ALTO
>>client to choose for more fine-grained Cost Calendars?
>>
[SR     ] This may indeed be an option. If the Server can afford it in terms of workload, 
it may propose different calendar attributes for a same Cost Type.  

>>In the 3rd paragraph of section 2.2, “A calendar and its capabilities are
>>associated to a given information resource”
>>In the 1st paragraph of section 3.1, ”by an object of type 'CalendarAttributes',
>>associated to this Cost Type and specified below.”
>>In the 1st paragraph of section 4.1.3, ”as specified in the IRD to shedule its
>>bulk data transfers as described in the use cases.”
>>- shedule -> schedule
>>
>>In the 1st paragraph of section 4.2.3, “Let us assume an Application Client is
>>located in an end sytem with limited resources and …”
>>- sytem -> system
>>
>>In the 2nd paragraph of section 4.2.3, “the 'routingcost' is assumed to be time
>>sentitive with values provided as ALTO Calendars.”
>>- sentitive -> sensitive
[SR     ] replaced by time-varying
>>limited time intervals …”
[SR     ] this sentence will be removed and the paragraph moved to section 2.2
>>In the 3rd paragraph of section 5.2, “the interaction with Endpoints can be
>>orchestratrated and scheduled at the time slots …”
[SR     ] Section 5 will be removed

>>- Propeeries -> Properties
[SR     ] Great thanks for catching all those nits