Hello Roman, Thanks again for your review. Your comments have been addressed as proposed in our responses inline. A new version has been posted and is available here and we hope it meets your expectations. https://tools.ietf.org/html/draft-ietf-alto-cost-calendar-21
Best regards, Sabine and Richard From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <sabine.randriam...@nokia-bell-labs.com> Sent: Tuesday, March 3, 2020 2:40 PM To: Y. Richard Yang <y...@cs.yale.edu>; Roman Danyliw <r...@cert.org> Cc: The IESG <i...@ietf.org>; draft-ietf-alto-cost-calen...@ietf.org; alto-cha...@ietf.org; IETF ALTO <alto@ietf.org>; Vijay Gurbani <vijay.gurb...@gmail.com>; Gurbani, Vijay (Nokia - US) <vijay.gurb...@nokia.com> Subject: RE: Roman Danyliw's No Objection on draft-ietf-alto-cost-calendar-19: (with COMMENT) Hello Roman, Thanks a lot for your review. Please see inline for the text in section 4.1 Best regards, Sabine From: Y. Richard Yang <y...@cs.yale.edu<mailto:y...@cs.yale.edu>> Sent: Tuesday, March 3, 2020 5:58 AM To: Roman Danyliw <r...@cert.org<mailto:r...@cert.org>> Cc: The IESG <i...@ietf.org<mailto:i...@ietf.org>>; draft-ietf-alto-cost-calen...@ietf.org<mailto:draft-ietf-alto-cost-calen...@ietf.org>; alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; IETF ALTO <alto@ietf.org<mailto:alto@ietf.org>>; Vijay Gurbani <vijay.gurb...@gmail.com<mailto:vijay.gurb...@gmail.com>>; Gurbani, Vijay (Nokia - US) <vijay.gurb...@nokia.com<mailto:vijay.gurb...@nokia.com>> Subject: Re: Roman Danyliw's No Objection on draft-ietf-alto-cost-calendar-19: (with COMMENT) Dear Roman, Thank you so much for the review. Please see below. On Mon, Mar 2, 2020 at 6:16 PM Roman Danyliw via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> wrote: Roman Danyliw has entered the following ballot position for draft-ietf-alto-cost-calendar-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few minor comments: Section 1.1. The role of the text describing the SENSE project isn’t clear. I’m not sure it will age will when in an RFC Good suggestion. To make the description aging slightly better, here is a revision. OLD: A potential use case is the SENSE project, see [SENSE-sdn-e2e-net], who is implementing smart network services to dynamically build end- to-end virtual guaranteed networks across administrative domains, with no manual intervention. The initial SENSE services include informing applications on the availability of bandwidth resources or feasibility of some requested Time-Bandwidth-Product (TBP) during a specific time period. ALTO Calendars can support these services if the Calendar start date and duration cover the period of interest of the requesting applications. The need of future scheduling of large scale traffic that can be addressed by the ALTO protocol is also motivated by Unicorn, a unified resource orchestration framework for multi-domain, geo- distributed data analytics, see [I-D.xiang-alto-multidomain-analytics]. New (instead of project centric, switch to use centric, also some small rewording): A potential use case is implementing smart network services that allow applications to dynamically build end-to-end, virtual networks, to satisfy given demands, with no manual intervention. For example, data-transfer automation applications may need a network service to determine on the availability of bandwidth resources, to decide when to transfer their data sets. The SENSE project [SENSE-sdn-e2e-net] supports such applications by requiring that a network provides services such as the Time-Bandwidth-Product (TBP) service, which informs applications of bandwidth availability during a specific time period. ALTO Calendars can support this service if the Calendar start date and duration cover the period of interest of the requesting application. The need of future scheduling of large scale traffic that can be addressed by the ALTO protocol is also motivated by Unicorn, a unified resource orchestration framework for multi-domain, geo- distributed data analytics, see [I-D.xiang-alto-multidomain-analytics]. -> Change I-D.xiang-alto-multidomain-analytics to an archived journal paper. Section 3. Thanks for providing an overview with the section. Given that this section is non-normative, how should the implementers use the text with RFC2119 words -- is it there just for emphasis? Very good catch. How about the following revision of the first paragraph of Section 3: OLD: This section gives a non-normative overview of the design. It assumes the reader is familiar with the ALTO protocol [RFC7285]. Normative specifications are given in the following sections. New: This section gives a high-level overview of the design. It assumes the reader is familiar with the ALTO protocol [RFC7285]. Section 4.1. Per ‘Attribute "cost-type-names" provides a better readability to the Calendar attributes specified …”, could you please clarify “a better readability”. How about the following: OLD: - Providing attribute "cost-type-names" together with "time-interval- size" and "number-of-intervals" improves the readability of the Calendar attributes specified for an IRD resource and avoids confusion with Calendar attributes of other cost types. New: - A resource announced by an IRD can include multiple cost types each supporting Cost Calendar. One approach to specifying their Calendar attributes ("time-interval-size" and "number-of-intervals") is to specify the attributes of each cost type individually. However, multiple cost types may have the same Calendar attributes (i.e., the same "time-interval-size" and "number-of-intervals"), and specifying them individually introduces redundancy and may lead to potential consistency issues (e.g., two cost types should have the same Calendar attributes, but are given different values in their respective entries). Given this observation, the specification of the Calendar attributes of an IRD resouce with multiple cost types is specified by groups: for each group, "cost-type-names" specifies the cost types in the group; "time-interval-size" and "number-of-intervals" specify the common values for the group of cost types. Does this change clarify? Sabine : it seems that the OLD paragraph, already updated from v17 because it was found unclear, still adds confusion since easy readability is indeed not the main reason. So borrowing from Richard’s proposal, would the following text with an example be clearer? NEW Attribute "cost-type-names" is associated with "time-interval-size" and "number-of-intervals", because multiple cost types may share the same values for attributes "time-interval-size" and "number-of-intervals". To avoid redundancies, cost type names sharing the same values for "time-interval-size" and "number-of-intervals" are grouped in the "cost-type-names" attribute. In the example IRD provided in section 4.3, the information resource “filtered-cost-map-calendar” provides a Calendar for cost type names "num-routingcost", "num-throughputrating" and "string-servicestatus". Cost type names "num-routingcost" and "num-throughputrating" are grouped in the "cost-type-names" attribute because they share the same values for "time-interval-size" and "number-of-intervals", which are respectively 7200 and 12. END Section 4.3. Nit. s/mode,to/mode, to/ OK. Thank you so much! Richard
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto