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

["Y. Richard Yang" <[e-mail]>]

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