Subject: [secdir] FW: [alto] I-D Action: draft-ietf-alto-cost-calendar-18.txt

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Fri, 28 Feb 2020 15:00:31 +0000

Dear IESG reviewers, Jürgen, Brian, Barry, 

Thank you very much for your review and suggestions. Upon your feedback, we have posted a new version 18, that hopefully addresses your comments. 
Besides, some lower/upper case typo harmonization has been done on expressions such as "Client", "Server", "cost type". 
We look forward to having your feedback,

Best regards,
Sabine and co-authors

-----Original Message-----
From: alto <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, February 28, 2020 3:44 PM
To: [email-masked]
Cc: [email-masked]
Subject: [alto] I-D Action: draft-ietf-alto-cost-calendar-18.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Application-Layer Traffic Optimization WG of the IETF.

        Title           : Application-Layer Traffic Optimization (ALTO) Cost Calendar
        Authors         : Sabine Randriamasy
                          Richard Yang
                          Qin Wu
                          Lingli Deng
                          Nico Schwan
	Filename        : draft-ietf-alto-cost-calendar-18.txt
	Pages           : 32
	Date            : 2020-02-28

Abstract:
   This document is an extension to the base Application-Layer Traffic
   Optimization (ALTO) protocol.  It extends the ALTO cost information
   service so that applications decide not only 'where' to connect, but
   also 'when'.  This is useful for applications that need to perform
   bulk data transfer and would like to schedule these transfers during
   an off-peak hour, for example.  This extension introduces ALTO Cost
   Calendar, with which an ALTO Server exposes ALTO cost values in JSON
   arrays where each value corresponds to a given time interval.  The
   time intervals as well as other Calendar attributes, are specified in
   the Information Resources Directory and ALTO Server responses.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-alto-cost-calendar-18
https://datatracker.ietf.org/doc/html/draft-ietf-alto-cost-calendar-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-cost-calendar-18

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
alto mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/alto

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Fri, 28 Feb 2020 18:17:50 +0000

> We look forward to having your feedback,

Thanks for the changes. All looks good but I am still struggling a bit
with the type change of the cost field. Revision -18 has this new
text:

   [...] Therefore the implementor of this extension MUST consider
   that a cost entry is an array of values.

I do not really understand what this MUST tries to achieve or what you
expect an implementer to do exactly.

RFC 7285 section 11.2.3.6 says:

   [...] An implementation of the protocol in this document
   SHOULD assume that the cost is a JSONNumber and fail to parse if it
   is not, unless the implementation is using an extension to this
   document that indicates when and how costs of other data types are
   signaled.

It may help to spell out 'when and how costs of other data types are
signaled' instead of writing "the implementor [...] MUST consider". If
the idea is that the usage of an array is signaled by the usage of an
array, then say so, if there is some other way to signal this before I
try to parse, then say so as well. We should not rely on implementers
to consider and find their own solutions.

/js

PS: I do not know much about ALTO but out of curiosity: has it been
    considered to allocate new "cost-mode" values "numerical*" and
    "ordinal*" that signal that the cost field is a vector of
    numerical/ordinal values and not just a scalar?

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 28 Feb 2020 16:26:01 -0500

Dear Jürgen,

Always excellent comments. Please see below.

On Fri, Feb 28, 2020 at 1:18 PM Schönwälder, Jürgen <
[email-masked]> wrote:

> > Thank you very much for your review and suggestions. Upon your feedback,
> we have posted a new version 18, that hopefully addresses your comments.
> > Besides, some lower/upper case typo harmonization has been done on
> expressions such as "Client", "Server", "cost type".
It indeed can help a lot if we could introduce a new cost mode, but the
change would be
more substantial.

Looking at your proposal on spelling out "when and how costs of other data
types are
signaled," which is an excellent suggestion. How does the following look:

"... Therefore the implementor of this extension MUST consider that a cost
entry is an
array of values. Specifically, an implementation of this extension MUST
parse
the "number-of-intervals" attribute of the "calendar-attributes" in an IRD
entry
announcing a service providing Cost Calendar. The implementation then will
know that a cost entry of the service will be an array of values, and the
expected
size of the array is that specified by the "number-of-intervals" attribute.

Richard

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Sat, 29 Feb 2020 08:21:40 +0000

> size of the array is that specified by the "number-of-intervals" attribute.

So the signal is the "number-of-intervals" attribute, this works for
me. I think it helps to spell this out.

/js

---

From: "Y. Richard Yang" <[email-masked]>
Date: Sat, 29 Feb 2020 07:37:22 -0500

> me. I think it helps to spell this out.

Yes. Exactly. Thanks a lot for the help!

Richard

-- 
Richard