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

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

On Sat, Feb 29, 2020 at 3:21 AM Schönwälder, Jürgen <
[e-mail]> 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 <
> > [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.
> >
>
> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
>
-- 
Richard