Re: [alto] Roman Danyliw's No Objection on draft-ietf-alto-cost-calendar-19: (with COMMENT)

["Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[e-mail]>]

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 <[e-mail]>
Sent: Tuesday, March 3, 2020 5:58 AM
To: Roman Danyliw <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; IETF ALTO <[e-mail]>; Vijay Gurbani <[e-mail]>; Gurbani, Vijay (Nokia - US) <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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