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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 02 Mar 2020 15:16:27 -0800

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

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?

Section 4.1.  Per ‘Attribute "cost-type-names" provides a better readability to
the Calendar attributes specified …”, could you please clarify “a better
readability”.

Section 4.3.  Nit. s/mode,to/mode, to/

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 2 Mar 2020 23:58:00 -0500

Dear Roman,

Thank you so much for the review. Please see below.

> https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/
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.

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

> the Calendar attributes specified …”, could you please clarify “a better

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

---

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Tue, 3 Mar 2020 13:39:42 +0000

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 <[email-masked]>
Sent: Tuesday, March 3, 2020 5:58 AM
To: Roman Danyliw <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; IETF ALTO <[email-masked]>; Vijay Gurbani <[email-masked]>; Gurbani, Vijay (Nokia - US) <[email-masked]>
Subject: Re: Roman Danyliw's No Objection on draft-ietf-alto-cost-calendar-19: (with COMMENT)

Dear Roman,

On Mon, Mar 2, 2020 at 6:16 PM Roman Danyliw via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-alto-cost-calendar-19: No Objection

A few minor comments:

Good suggestion. To make the description aging slightly better, here is a revision.

OLD:

rewording):

   requesting application.

     -> Change I-D.xiang-alto-multidomain-analytics to an archived  journal paper.

Very good catch. How about the following revision of the first paragraph of Section 3:

OLD:

How about the following:

OLD:

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

OK.

Thank you so much!

Richard

---

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Tue, 17 Mar 2020 15:53:04 +0000

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) <[email-masked]>
Sent: Tuesday, March 3, 2020 2:40 PM
To: Y. Richard Yang <[email-masked]>; Roman Danyliw <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; IETF ALTO <[email-masked]>; Vijay Gurbani <[email-masked]>; Gurbani, Vijay (Nokia - US) <[email-masked]>
Subject: RE: Roman Danyliw's No Objection on draft-ietf-alto-cost-calendar-19: (with COMMENT)

Hello Roman,

From: Y. Richard Yang <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, March 3, 2020 5:58 AM
To: Roman Danyliw <[email-masked]<mailto:[email-masked]>>
Cc: The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; IETF ALTO <[email-masked]<mailto:[email-masked]>>; Vijay Gurbani <[email-masked]<mailto:[email-masked]>>; Gurbani, Vijay (Nokia - US) <[email-masked]<mailto:[email-masked]>>
Subject: Re: Roman Danyliw's No Objection on draft-ietf-alto-cost-calendar-19: (with COMMENT)

Dear Roman,

A few minor comments:

OLD:

rewording):

   requesting application.

OLD:

How about the following:

OLD:

NEW

END

OK.

Thank you so much!

Richard