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

["Y. Richard Yang" <[e-mail]>]

Dear Jürgen,

Always excellent comments. Please see below.

On Fri, Feb 28, 2020 at 1:18 PM Schönwälder, Jürgen <
[e-mail]> 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.

Richard








> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
>