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> 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? > 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
