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

From: Alexey Melnikov via Datatracker <[email-masked]>
Date: Thu, 05 Mar 2020 05:03:25 -0800

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
<[email-masked]>. 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)

---

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Thu, 5 Mar 2020 16:51:48 +0000

Hello Alexey and Francesca,

Thanks a lot for your review and feedback. We will get back to you shortly with our proposals to address your comments.
Best regards,
Sabine

-----Original Message-----
From: Alexey Melnikov via Datatracker <[email-masked]> 
Sent: Thursday, March 5, 2020 2:03 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Vijay Gurbani <[email-masked]>; [email-masked]; [email-masked]
Subject: Alexey Melnikov's No Objection on draft-ietf-alto-cost-calendar-19: (with COMMENT)

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.)

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

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

* "Specifically, an

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

* "multiple

*"   o  "cost-type-names":

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

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

---

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Tue, 17 Mar 2020 16:02:12 +0000

Hi Alexey and Francesca,

Thanks again for your review and guidance. Your comments have been addressed as described in the responses inline. 
A new version v21 has been posted and is available here, hoping it meets your expectations.
https://tools.ietf.org/html/draft-ietf-alto-cost-calendar-21   

Best regards,
Sabine

>Cc: [email-masked]; [email-masked]; [email-masked];
>Vijay Gurbani <[email-masked]>; [email-masked];
>[email-masked]
><[email-masked]>. My comments are marked with
>[[Alexey:]] below.
>
>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.
>
[ [SR] ]  Yes, done. Section 3.3 now starts with:
----- NEW
The present document uses the notations defined in Section "8.2
   Notation" of [RFC7285].
----- END

>   (draft-ietf-alto-incr-update-sse is indeed informational reference)
[ [SR] ] draft-ietf-alto-incr-update-sse is now a normative reference, with RECOMMENDED use 

>* "with one value one per time interval," remove second "one"
[ [SR] ] Done, thanks

>   Please ref to where "calendar-attrinutes" is defined.
[ [SR] ] the expression is now "Calendar attributes", as introduced in Section 3.2

>terminology what this is supposed to mean.
[ [SR] ] the following definition was added in section 1.2 Terminology
----- NEW
<t>Calendared: this adjective qualifies information resources providing Cost Calendars 
      and information on costs that are provided in the form of a Cost Calendar.</t>
----- END

>That is not true, as 3.3.2 at least contains normative text (as it should).
[ [SR] ] Yes, indeed, the text was changed as follows:
----- NEW
This section gives a high-level overview of the design.  
It assumes the reader is familiar with the ALTO protocol [RFC7285] and 
its Multi-Cost ALTO extension [RFC8189].
----- END

>   idea... This should at least have some security considerations.
[[SR]] I agree there should be some guidance for the Client in this case. Two updates have been made:

1 - Paragraph 1 has been updated as follows: 
----- NEW
A Cost Calendar for a given cost type MUST be indicated in the IRD by
   an object of type CalendarAttributes.  A CalendarAttributes object is
   represented by the "calendar-attributes" member of a resource entry.
   Member "calendar-attributes" is an array of CalendarAttributes objects. 
   Each CalendarAttributes object lists a set of one or more cost
   types it applies to. A cost type name MUST NOT appear more than once in the
   "calendar-attributes" member of a resource entry; 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. 
   The Client SHOULD consider the CalendarAttributes object in the array 
   containing the first encountered occurrence of a cost type as the 
   valid one for this cost type. As an alternative, the Client may want to avoid the risks of 
   erroneous guidance associated to the use 
   of potentially invalid Calendar values. In this case, the Client MAY ignore
   the totality of occurences of CalendarAttributes objects containing the cost type name
   and query the cost type using <xref target="RFC7285"/>.
----- END

2- In Section 7 on Security considerations, the following text has been added to the last paragraph.

----- NEW 
Another risk of erroneous guidance appears when the Server exposes an occurrence of a same cost type name in different elements of the Calendar objects array associated to an information resource. In this case, there is no way for the Client to figure out which Calendar object in the array is valid. The specification in this document recommends, in this case, that the Client uses the first encountered Calendar object occurrence containing the cost type name. However, the Client may want to avoid the risks of erroneous guidance associated to the use  of potentially invalid Calendar values. To this end, as an alternative to the recommendation in this document,  the Client MAY ignore the totality of occurences of CalendarAttributes objects containing the cost type name and query this cost type using RFC7285.
----- END

>   Sounds to me like this should say MUST appear only once. What if it appears
[[SR]] If a cost type name appears 0 times, it means that it is not supported as a Calendar for this resource. 

>  itself  ("indicating the cost-type-names")
[ [SR] ] done, thanks. Expression was changed in cost type names

>   you confirm and point to a ref?
[ [SR] ] The following text was added after the sentence you quoted
----- NEW
N is greater than 1 when the Client and the Server also implement [RFC8189].
----- END

>     explicitly stated in the text below.
[[SR]] This array is optional if a Calendar for only 1 cost type is queried but MUST be present when Calendars are provided for multiple cost types. The following text was added to the bullet describing "cost-type-names":
----- NEW
This member MUST be present when Cost Calendars are provided for more than one cost types.
----- END 

>; should be inside the bracket
[ [SR] ] done, thanks

>* "JSONString calendar-start-time;" please repeat or ref the section that states
>that the string contain an IMF-fixdate value
>
[[SR]] the section 5 text has been partly repeated and referenced

>    Please explicitly state that each value correspond to the cost in that
[[SR]] done, thanks, your proposed text was added.

>   Not only, also the request method is the same, please explicitely state that.
[[SR]] Assuming "method" means the rules defined around the extensions to the FCM request, the
Following text has been added 
----- NEW
Likewise, the rules defined around
   the extensions to ECM requests are the same as those defined in
   Section 5.1.1 for FCM requests.
----- END

>* Section 5.2.1 - Compared to ReqEndpointCostMap of 7285 the object
>described here has optional cost-type. Why is that changed from 7285?
>
[ [SR] ] The following explanation was added after the format specification of ReqEndpointCostMap
----- NEW
Member "cost-type" is optional because, in the ReqEndpointCostMap object definition of this document, it is jointly present with member "multi-cost-types", to ensure compatibility with RFC 8189. In RFC8189, members "cost-type" and "multi-cost-types" are both optional and have to obey the rule specified in section 4.1.2 of 8189 staying that: "the Client MUST specify either "cost-type" or "multi-cost-types" but MUST NOT specify both".
----- END

>* ""calendared" : [true];" ; should be inside the bracket
[ [SR] ]  I am not sure I understood why the ";" should be inside the bracket. Actually, I am not sure this ";" should be here at all, since in the JSON input, it is rather a comma "," . So I replaced ";" with ",". 

>* Please give a pointer to where "TypedEndpointAddr" is defined
[[SR]]  In the explanation text following the ReqEndpointCostMap structure, 2nd paragraph the following sentence was added:
----- NEW
The type TypedEndpointAddr is defined in section 10.4.1 of [RFC7285].
----- END

>* I believe TLS and JSON should be normative references of this document
[ [SR] ] Agreed, they now are

>  -- Obsolete informational reference (is this intentional?): RFC 7159
[ [SR] ] Yes, it is