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
