Re: [alto] Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-20: (with COMMENT)

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

Hello Benjamin,

Thanks again for your review. A version v21 is under edition to finish addressing all the review comments. 
Please see inline for my responses to your comments. 
Best regards,
Sabine

>-----Original Message-----
>From: Benjamin Kaduk via Datatracker <[e-mail]>
>Sent: Tuesday, March 10, 2020 1:21 AM
>To: The IESG <[e-mail]>
>Cc: [e-mail]; [e-mail]; [e-mail];
>Vijay Gurbani <[e-mail]>; [e-mail]
>Subject: Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-20:
>(with COMMENT)
>
>Benjamin Kaduk has entered the following ballot position for
>draft-ietf-alto-cost-calendar-20: 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:
>----------------------------------------------------------------------
>
>Thanks for adding text about the incompatibility of constraints with the
>calendar functionality.  I would suggest further clarifying that this reflects a
>limitation of this method or reduction in functionality when compared to RFC
>7285 (and 8189), but do not insist upon it.
>
>[comments from -19 preserved for posterity]
>
>Section 1
>
>   In this document, an "ALTO Cost Calendar" is specified in terms of
>   information resources capabilities that are applicable to time-
>
>nit: "information resources capabilities" has two plurals.  Either make
>"resources" possessive ("resources'") or just use "resource".
[     [SR]   ] done thanks
>
>Section 1.1
>
>I'm not sure how much *archival* value there is in the current discussion of
>SENSE and Unicorn.
[     [SR]   ] Text changed to be less project-centric ans instead focusing on the motivating use-case. 
Reference [I-D.xiang-alto-multidomain-analytics] was changed to an archived journal paper.
>
>Section 3.1
>
>   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.
>
>nit(?): faster than what?
[     [SR]   ] the text has been changed as follows in v20:
NEW 
The "ALTO Incremental Updates
   Using Server-Sent Events (SSE)" Service
   [I-D.ietf-alto-incr-update-sse] can be used to directly update the
   Calendar upon value changes, if supported by both the Server and the
   Client. END
>
>Section 3.3
>
>   The present document extends the definition of a legacy cost map
>   given in [RFC7285] to allow a cost entry to be an array of values,
>   with one value one per time interval, instead of being just one
>   number.  Therefore the implementor of this extension MUST consider
>   that a cost entry is an array of values.  Specifically, an
>
>nit: this is not quite true, strictly speaking -- the cost entry is only an array
>when the cost calendar functionality is active, which is not a subset of when
>the extension is implemented.
>Also, if the cost entry is definitively an array, then this would be replacing the
>definition, not extending it.
[ [SR]   ] Would the following text be better?
NEW 
The present document extends the
   definition of a legacy cost map given in <xref target="RFC7285"/> to allow a cost
   entry to be an array of values, with one value one per time interval, instead of
   being just one number, when the Cost Calendar functionality is activated on this cost.
   Therefore the implementor of this extension MUST consider that a cost entry is an array of values
   if this cost has been queried as a Calendar. END

>
>   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.
>
>Is it a protocol error if the cost entry is a scalar or an array of different size
>than expected?  Where do we specify error handling for those cases?
>
>   To realize an ALTO Calendar, this document extends: the IRD and the
>   ALTO requests and responses for Cost Calendars.
>
>nit: no colon needed.
[ [SR]   ] done, thanks
>
>   o  it allows an ALTO Server to offer Calendar capabilities on a cost
>      type, with attributes values adapted to each information resource.
>
>I'm not entirely sure what this is intending to say.  Is the idea that this is a
>general mechanism that could be applied to capabilities of all cost types (as
>opposed to, e.g., making a new cost mode for "calendar of numerical" that
>would need many new types to support different types of calendar)?
>
>Section 3.3.2
>
>   The ALTO protocol extensions for Cost Calendars have been defined so
>   as to ensure that Calendar capable ALTO Servers can provide legacy
>
>nit: hyphenate "Calendar-capable" (and similarly throughout).  I see that
>"calendar-aware" is already hyphenated, which is good.
[ [SR]   ] done in v20 thanks

>
>   ALTO Clients with legacy information resources as well.  That is, a
>   legacy ALTO Client can request resources and receive responses as
>   specified in [RFC7285].
>
>Should we say anything about Calendar-aware ALTO Clients being able to get
>useful responses from legacy Servers as well?
[ [SR]   ] Agree. The following sentence has been added after paragraph 2:
NEW
   A Calendar-aware ALTO Client MUST implement the base protocol
   specified in <xref target="RFC7285"/>.
END

>
>Section 4
>
>   The Calendar attributes in the IRD information resources capabilities
>   carry constant dateless values.  A Calendar is associated with an
>
>"constant" in what sense?
[ [SR]   ] Agree, the main idea is that the attribute values are dateless. So "constant" has been removed:
NEW
The Calendar attributes in the IRD information resources capabilities carry dateless values.
END
>
>Section 4.1
>
>   types.  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.
>
>It seems that this is most important in that the given resource entry has an
>array of calendar-attributes, and we need to know which element of that
>array to use when processing calendars for that cost type.
>Indicating the extra layer of structure in the description around this
>requirement would help the reader.
>
>   An ALTO Server SHOULD specify the "time-interval-size" in the IRD as
>   the smallest it is able to provide.  A Client that needs a longer
>   interval can aggregate multiple cost values to obtain it.
>
>nit: we haven't defined "time-interval-size" yet, so either moving this later or
>giving a bit more explanation might be useful.
[ [SR]   ] Agree. This text was moved right after the definition of CalendarAttributes
>
>   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.
>
>Which capabilities?
[ [SR]   ] The text was clarified as follows:
NEW
An array of one or more elements indicating the cost-type-names
         in the IRD entry to which the values of "time-interval-size" and 
         "number-of-intervals" apply.
END
>
>      *  is the duration of an ALTO Calendar time interval in a unit of
>         seconds.  A "time-interval-size" value contains a non-negative
>         JSONNumber.  Example values are: 300 and 7200, meaning that
>         each Calendar value applies on a time interval that lasts 5
>         minutes and 2 hours, respectively.  Since an interval size
>         (e.g., 100 ms) can be smaller than the unit, the value
>         specified may be a floating point (e.g., 0.1).  Both ALTO
>         Clients and Servers should be aware of potential precision
>         issues caused by using floating point numbers; for example, the
>         floating number 0.1 cannot be represented precisely using a
>         finite number of binary bits.  To improve interoperability and
>         be consistent with [RFC7285] on the use of float point numbers,
>         the Server and the Client SHOULD use IEEE 754 double-precision
>         floating point [IEEE.754.2008] to store this value.
>
>nit: please be consistent about using "floating-point number" (vs., e.g.,
>"floating point" or "float point").
[ [SR]   ] thanks, used "floating" everywhere
>
>   - Providing attribute "cost-type-names" together with "time-interval-
>   size" and "number-of-intervals" improves the readability of the
>   Calendar attributes specified for an IRD resource and avoids
>   confusion with Calendar attributes of other cost types.
>
>I'm not sure I understand either of these points (how readability is helped and
>how confusion is avoided).
[ [SR]   ] Indeed the text was clarified as follows in v20, as readability was not the main point
NEW
- Attribute "cost-type-names" is associated with "time-interval-size" and 
   "number-of-intervals", because multiple cost types may share the same 
   values for attributes "time-interval-size" and "number-of-intervals". 
   To avoid redundancies, cost type names sharing the same values for "time-interval-size" 
   and "number-of-intervals" are grouped in the "cost-type-names" attribute. 
   In the example IRD provided in <xref target="sect-4.3"/>, the information resource 
   “filtered-cost-map-calendar” provides a Calendar for cost type names 
   "num-routingcost", "num-throughputrating" and "string-servicestatus".  
   Cost type names "num-routingcost" and "num-throughputrating" are 
   grouped in the "cost-type-names" attribute because they share the 
   same values for "time-interval-size" and "number-of-intervals", 
   which are respectively 7200 and 12.
END
>
>Section 4.2
>
>   It may be useful to distinguish IRD resources supported by the base
>   ALTO protocol from resources supported by its extensions.  To achieve
>   this, one option, is that a "root" ALTO Server implementing base
>   protocol resources and running at a given domain, delegates
>   "specialized" information resources such as the ones providing Cost
>   Calendars, to another ALTO Server running in a subdomain.  The "root"
>
>How would a Client know that this mechanism is in use?
>
>   This document provides an example, where a "root" ALTO Server runs in
>   a domain called "alto.example.com".  It delegates the announcement of
>   Calendars capabilities to an ALTO Server running in a subdomain
>   called "custom.alto.example.com".  The location of the "delegate
>   Calendar IRD" is assumed to be indicated in the "root" IRD by the
>   resource entry: "custom-calendared-resources".
>
>This is "assumed" only for the purpose of the example, and not as a general
>protocol mechanism, right?
>
>   Another benefit of delegation is that some cost types for some
>   resources may be more advantageous as Cost Calendars and it makes few
>   sense to get them as a single value.  For example, if a cost type has
>   predictable and frequently changing values, calendared in short time
>   intervals such as a minute, it saves time and network resources to
>   track the cost values via a focused delegate Server rather than the
>   more general "root" Server.
>
>Is the idea just that you compartmentalize the fast-changing stuff from the
>slow-changing stuff, so that your listing of what is changing quickly only
>includes the things actually changing on that timescale, so you don't end up
>also listing the calendar for the slowly-changing things in the same response?
>Also, nit: s/few/little/
>
>
>Is there a reason for "map" and "calendar" to be in different orders in
>"filtered-cost-map-calendar" and "endpoint-cost-calendar-map"?
>
>   o  the Calendar for "owdelay": is an array of 12 values each provided
>      on a time interval lasting 300 seconds (5 minutes).
>
>nit: s/owdelay/num-owdelay/
[[SR]] Done, thanks

>
>Sectgion 5
>
>I'd consider using a more recent Date in the example.
[[SR]] agree, done thanks
>
>Section 5.1.1
>
>   The input parameters of a "legacy" request for a filtered cost map,
>   defined by object ReqFilteredCostMap in section 11.3.2 of [RFC7285],
>   are augmented with one additional member.
>
>There's probably some pedantic consideration here about "other extensions",
>such as the "multi-cost-types" member from RFC 8189.
>
>   This field is an array of 1 to N boolean values, where N is the
>   number of requested metrics.  Each entry corresponds to the requested
>
>Maybe reference RFC 8189 so the reader doesn't get confused by RFC 7285
>specifying only a single metric type?
>
>Section 5.1.2
>
>   The non Calendar specific "meta" fields of a calendared Filtered Cost
>   Map response MUST include at least:
>     [...]
>
>side note: this structure where we effectively repeat the requirements of all
>previous specifications is not going to scale well with future extensions.
>
>   o  each "CalendarResponseAttributes" object in the array is specified
>      for one or more cost types for which the value of member
>      "calendared" is equal to 'true' and for which a Calendar is
>      provided for the requested information resource.
>
>Member 'calendared' of what data structure?
>
>   o  "cost-type-names": is an array of one or more cost-type-names to
>      which the capabilities apply and for which a Calendar has been
>      requested.  The value of this member is a subset of the "cost-
>      type-names" array specified in the corresponding IRD Calendar
>      attributes.
>
>Just to check my understanding: in the IRD Calendar attributes, there's a
>"calendar-attributes" member whose value is an array of objects, and each of
>those objects has a "cost-type-names" member whose value is an array of
>cost-type names.  So what we're saying here is that the "cost-type-names" in a
>CalendarResponseAttributes entry are a subset of the union of the "cost-type-
>names" members in all of the entries in the "calendar-attributes" array of
>objects in the IRD calendar attribute, which is not exactly what the quoted text
>seems to be saying.
>
>   o  "time-interval-size": as specified in Section 4.1 and with the
>      same value.
>
>   o  "number-of-intervals": as specified in Section 4.1 and with the
>      same value.
>
>nit: "with the same value" could perhaps imply that there is a requirement to
>have actually published an IRD calendar for this resource and literally take the
>value from that existing calendar; "with the same semantics" should relax that
>(perceived) requirement.
>
>Section 5.1.3
>
>   An example of non-real time information that can be provisioned in a
>   Calendar is the expected path throughput.  While the transmission
>
>nit: "non-real time" and "non-real-time" have different meanings, and I think
>the latter is the intended one.
>
>   usage patterns.  In this example, we assume that an ALTO Client
>   requests a Calendar of network provider defined throughput ratings,
>
>nit: hyphenate "network-provider-defined".
>
>     Content-Length: 1013
>     Content-Type: application/alto-costmap+json
>
>Please double-check the content length (for all the examples) -- it's a bit
>annoying to do from the text rendering of the I-D that applies a left indent,
>but assuming that the initial '{' is supposed to be the first byte of the response
>body and the rest of the whitespace is part of the response, I get something
>more like 1043 octets of content.
>
>Section 5.2.1
>
>We should probably say that the interpretation of the various fields is the
>same as the RFC 7285/8189 ReqEndpointCostMap, and "calendared" the same
>as for ReqFilteredCostMap.
>
>Section 5.2.3
>
>   o  C1 for Monday, Tuesday, Wednesday, Thursday, (weekdays)
>
>   o  C2 for Saturday, Sunday, (weekend)
>
>   - C3 for Friday (maintenance outage on July 4, 2014 from 02:00:00 GMT
>   to 04:00:00 GMT, or big holiday such as New Year evening).
>
>I'd consider using a more recent date than 2014 throughout this example.
>Also, nit: please use a consistent character to represent the bullet point.
>
>  Host: alto.example.com
>
>Would it be more consistent with previous examples to use
>custom.alto.example.com here (and in other examples)?
>
>Section 7
>
>
>   [RFC8446] specifies TLS 1.3 and writes in its section 1: "While TLS
>   1.3 is not directly compatible with previous versions, all versions
>   of TLS incorporate a versioning mechanism which allows Clients and
>   Servers to interoperably negotiate a common version if one is
>   supported by both peers".  ALTO Clients and Servers SHOULD support
>   both TLS 1.3 [RFC8446] and TLS 1.2 [RFC5246], and MAY support and use
>   newer versions of TLS as long as the negotiation process succeeds.
>
>I know this document has been in the works for a long time and so there may
>be reluctance to make changes on this front, but I'll note that RFC
>8446 has been out for a year and half, so under normal conditions we'd just
>say "use TLS 1.3 or newer" without mentioning 1.2.
>
>   participate in a DDoS attack.  The Calendar information would be
>   valuable information for when to persecute a DDoS attack.  A
>
>nit: "persecute" is an unusual word here; "execute" or "perform" seem like
>better alternatives.
>
>   Hence, a more robust ALTO Client should adapt and extend protection
>   strategies specified in Section 15.2 of the base protocol.  For
>
>It's probably better to use the RFC number than just "the base protocol".
>
>Section 10.2
>
>I think [IEEE.754.2008] needs to be normative, as do RFCs 5246 and 8446, and
>draft-ietf-alto-incr-update-sse.
>
>