Hello Jürgen, Thanks a lot, Best regards, Sabine
-----Original Message----- From: Schönwälder, Jürgen <j.schoenwael...@jacobs-university.de> Sent: Monday, March 2, 2020 2:18 PM To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <sabine.randriam...@nokia-bell-labs.com> Cc: Y. Richard Yang <y...@cs.yale.edu>; IETF ALTO <alto@ietf.org>; 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 Dear Sabine, this version looks good to me. /js On Mon, Mar 02, 2020 at 12:06:36PM +0000, Randriamasy, Sabine (Nokia - FR/Paris-Saclay) wrote: > 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 -- 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/> _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
