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

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Mon, 2 Mar 2020 12:06:36 +0000

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 <[email-masked]>
Sent: Saturday, February 29, 2020 1:37 PM
To: Schönwälder, Jürgen <[email-masked]>
Cc: IETF ALTO <[email-masked]>; Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[email-masked]>; The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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 <
> [email-masked]<mailto:[email-masked]>> 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

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Mon, 2 Mar 2020 13:18:21 +0000

Dear Sabine,

this version looks good to me.

/js

---

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Mon, 2 Mar 2020 13:30:37 +0000

Hello Jürgen,

Thanks a lot,
Best regards,
Sabine

-----Original Message-----
From: Schönwälder, Jürgen <[email-masked]> 
Sent: Monday, March 2, 2020 2:18 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[email-masked]>
Cc: Y. Richard Yang <[email-masked]>; IETF ALTO <[email-masked]>; The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [OPS-DIR] FW: [alto] I-D Action: draft-ietf-alto-cost-calendar-18.txt

Dear Sabine,

/js

On Mon, Mar 02, 2020 at 12:06:36PM +0000, Randriamasy, Sabine (Nokia - FR/Paris-Saclay) wrote:
> Cc: IETF ALTO <[email-masked]>; Randriamasy, Sabine (Nokia - 
> FR/Paris-Saclay) <[email-masked]>; The IESG 
> <[email-masked]>; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> > > 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:
> > >
> > > I do not really understand what this MUST tries to achieve or what 
> > > you expect an implementer to do exactly.
> > >
> > > 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
> > >
> > 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.
> >
>