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

["Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[e-mail]>]

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

>-----Original Message-----
>From: Alexey Melnikov via Datatracker <[e-mail]>
>Sent: Thursday, March 5, 2020 2:03 PM
>To: The IESG <[e-mail]>
>Cc: [e-mail]; [e-mail]; [e-mail];
>Vijay Gurbani <[e-mail]>; [e-mail];
>[e-mail]
>Subject: Alexey Melnikov's No Objection on draft-ietf-alto-cost-calendar-19:
>(with COMMENT)
>
>Alexey Melnikov has entered the following ballot position for
>draft-ietf-alto-cost-calendar-19: No Objection
>
>----------------------------------------------------------------------
>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.
>
[ [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

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

>* "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.
>
[ [SR] ] the expression is now "Calendar attributes", as introduced in Section 3.2


>* "Calendared" is used in the text. I would either rephrase or explain in the
>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

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

>* "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.
>
[[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

>* "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?
>
[[SR]] If a cost type name appears 0 times, it means that it is not supported as a Calendar for this resource. 

>*"   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")
>
[ [SR] ] done, thanks. Expression was changed in 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?
>
[ [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

>* 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.
>
[[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 

>* "[JSONString cost-type-names <1..*>];"
>; 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

>* "   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.
>
[[SR]] done, thanks, your proposed text was added.

>* 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.
>
[[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

>* "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
>
[ [SR] ] Agreed, they now are

>*  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)
>
[ [SR] ] Yes, it is
>