[alto] Alexey Melnikov's No Objection on draft-ietf-alto-cost-calendar-19: (with COMMENT)

[Alexey Melnikov via Datatracker <[e-mail]>]

Alexey Melnikov has entered the following ballot position for
draft-ietf-alto-cost-calendar-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This version is an improvement over the one I reviewed earlier.

**********************************************************************
* Note, that I am conducting an experiment when people aspiring to be*
* Area Directors get exposed to AD work ("AD shadowing experiment"). *
* As a part of this experiment they get to review documents on IESG  *
* telechats according to IESG Discuss criteria document and their    *
* comments get relayed pretty much verbatim to relevant editors/WGs. *
* As an AD I retain responsibility in defending their position when  *
* I agree with it.                                                   *
* Recipients of these reviews are encouraged to reply to me directly *
* about perceived successes or failures of this experiment.          *
**********************************************************************

The following comments were provided by Francesca Palombini
<[e-mail]>. My comments are marked with [[Alexey:]]
below.

Francesca would have balloted *DISCUSS* on this document. She wrote:

DISCUSS

* "The encoding format for object CalendarAttributes, using JSON
   [RFC8259], is as follows:"
JSON is used, right. I know 7285 is normatively reference but the draft is
missing either here or in the introduction part of the spec (e.g. terminology)
to explicitly point to Section 8.2 of 7285 Notation, as that is used here.

COMMENT

* "However, like for any schedule, unexpected network
   incidents may require the current ALTO Calendar to be updated and re-
   sent to the ALTO Clients needing it.  The "ALTO Incremental Updates
   Using Server-Sent Events (SSE)" Service
   [I-D.ietf-alto-incr-update-sse] can be used to update the calendar
   faster if supported by both the Server and the Client."

   If the "ALTO Incremental Updates Using Server-Sent Events (SSE)" Service is
   not used, and updates are required, what should be used instead?
   (draft-ietf-alto-incr-update-sse is indeed informational reference)

* "with one value one per time interval," remove second "one"

* "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."
   Please ref to where "calendar-attrinutes" is defined.

* "Calendared" is used in the text. I would either rephrase or explain in the
terminology what this is supposed to mean.

* Section 3 - "This section gives a non-normative overview of the design. "
That is not true, as 3.3.2 at least contains normative text (as it should).

* "multiple
   appearances of a cost type name in the CalendarAttributes object of
   the "calendar-attributes" member MUST cause the ALTO Client to ignore
   any occurrences of this name beyond the first encountered occurrence."
   This worries me as occurrences can be re-ordered (by  intermediaries) I am
   not sure ignoring further occurrences and keep the processing is the best
   idea... This should at least have some security considerations.

* "A cost type name MUST NOT appear more than once in the
   "calendar-attributes" member of a resource entry;"
   Sounds to me like this should say MUST appear only once. What if it appears
   0 times?

*"   o  "cost-type-names":

      *  An array of one or more elements indicating the cost-type-names
         in the IRD entry to which the capabilities apply."
  Please do not use the parameter "cost-type-names" to describe the parameter
  itself  ("indicating the cost-type-names")

* "This field is an array of 1 to N boolean values, where N is the
   number of requested metrics."
   I could not find in 7285 that more than one metric can be requested. Could
   you confirm and point to a ref?

* In the Filtered Map Response:
"object{
     [JSONString cost-type-names <1..*>];
     "
     Why is this array of one or more attributes optional? Also this is non
     explicitly stated in the text below.

* "[JSONString cost-type-names <1..*>];"
; should be inside the bracket

* "JSONString calendar-start-time;" please repeat or ref the section that
states that the string contain an IMF-fixdate value

* "   o  the calendared costs are JSONArrays instead of the JSONNumbers
      format used by legacy ALTO implementations.  All arrays have a
      number of values equal to 'number-of-intervals'."
    Please explicitly state that each value correspond to the cost in that
    interval.

* Section 5.2 references to sections be fixed

* "The extensions to the requests for calendared Endpoint Cost Maps are
   the same as for the Filtered Cost Map Service, specified in section
   Section 5.1.1 of this draft."
   Not only, also the request method is the same, please explicitely state that.

* Section 5.2.1 - Compared to ReqEndpointCostMap of 7285 the object described
here has optional cost-type. Why is that changed from 7285?

* ""calendared" : [true];" ; should be inside the bracket

* Please give a pointer to where "TypedEndpointAddr" is defined

* "ALTO Clients and Servers SHOULD support
   both TLS 1.3 [RFC8446] and TLS 1.2 [RFC5246]," why both?

* I believe TLS and JSON should be normative references of this document

*  ID Nits gives the following warnings:
 -- Obsolete informational reference (is this intentional?): RFC 5246
     (Obsoleted by RFC 8446)

[[Alexey:]] This one is Ok if requirement to support TLS 1.2 is intended

  -- Obsolete informational reference (is this intentional?): RFC 7159
     (Obsoleted by RFC 8259)