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 and all,

Sorry, I mistakenly clicked the "Send" button and I still need to address a couple of comments.
In the meantime however, I'll be happy to have your feedback on the proposed updates.

Best regards,
Sabine
 

>-----Original Message-----
>From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
>Sent: Wednesday, March 11, 2020 7:18 PM
>To: Benjamin Kaduk <[e-mail]>; The IESG <[e-mail]>
>Cc: [e-mail]; [e-mail]; [e-mail];
>Vijay Gurbani <[e-mail]>; [e-mail]
>Subject: RE: Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-20:
>(with COMMENT)
>
>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.
>>
>>