Dear Jürgen, Barry and all, A new version has been submitted that hopefully addresses Jürgen and Barry’s IESG review comments. Thanks again for your helpful suggestions.
There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-alto-cost-calendar-19 https://datatracker.ietf.org/doc/html/draft-ietf-alto-cost-calendar-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-cost-calendar-19 Best regards, Sabine and co-authors. From: Y. Richard Yang <y...@cs.yale.edu> Sent: Saturday, February 29, 2020 1:37 PM To: Schönwälder, Jürgen <j.schoenwael...@jacobs-university.de> Cc: IETF ALTO <alto@ietf.org>; Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <sabine.randriam...@nokia-bell-labs.com>; The IESG <i...@ietf.org>; alto-cha...@ietf.org; draft-ietf-alto-cost-calen...@ietf.org; ops-...@ietf.org; sec...@ietf.org Subject: Re: [OPS-DIR] FW: [alto] I-D Action: draft-ietf-alto-cost-calendar-18.txt On Sat, Feb 29, 2020 at 3:21 AM Schönwälder, Jürgen <j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>> wrote: On Fri, Feb 28, 2020 at 04:26:01PM -0500, Y. Richard Yang wrote: > Dear Jürgen, > > Always excellent comments. Please see below. > > On Fri, Feb 28, 2020 at 1:18 PM Schönwälder, Jürgen < > j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>> > wrote: > > > On Fri, Feb 28, 2020 at 03:00:31PM +0000, Randriamasy, Sabine (Nokia - > > FR/Paris-Saclay) wrote: > > > 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, > > > > > > > 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? > > > > > 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. > So the signal is the "number-of-intervals" attribute, this works for me. I think it helps to spell this out. Yes. Exactly. Thanks a lot for the help! Richard /js -- 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/> -- Richard
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
