Hi Qian,

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


>>-----Original Message-----
>>From: Yichen Qian [mailto:[email protected]]
>>Sent: 29 June 2017 19:55
>>To: IETF ALTO <[email protected]>; [email protected]
>>Subject: Review of draft-ietf-alto-cost-calendar-01
>>
>>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.

[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.  

>>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
[SR     ] replaced by time-varying
>>
>>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
[SR     ] this sentence will be removed and the paragraph moved to section 2.2
>>
>>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
>>
[SR     ] Section 5 will be removed

>>The subtitle of section 6.2, “Information for IANA on proposed Endpoint
>>Propeeries”
>>- Propeeries -> Properties
>>
[SR     ] Great thanks for catching all those nits 

>>Best wishes,
>>Eason
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to