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,

All right, thanks for your suggestion. I will insert such a text.
Best regards,
Sabine


>-----Original Message-----
>From: Benjamin Kaduk <[e-mail]>
>Sent: Wednesday, March 11, 2020 2:24 AM
>To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <sabine.randriamasy@nokia-
>bell-labs.com>
>Cc: The IESG <[e-mail]>; [e-mail]; alto-
>[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)
>
>Hi Sabine,
>
>On Tue, Mar 10, 2020 at 09:40:13AM +0000, Randriamasy, Sabine (Nokia -
>FR/Paris-Saclay) wrote:
>> Hello Benjamin,
>>
>> Thank you for your review and feedback. As you saw, in draft-ietf-alto-cost-
>calendar-20, there are still comments from v19 that will be addressed in the
>next update.
>
>I'm happy to hear that :)
>
>> I would have a question : in your sentence " 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.", what does "this
>method" refer to? Is the idea that using constraints is less efficient with
>Calendars that with RFC 7285 and 8189? If yes I will propose a sentence to
>reflect this idea.
>
>"This method" is ALTO Cost Calendars in general.  So, I was thinking something
>like adding a sentence at the end of Section 3.3 to say "The absence of
>constraints on filtered cost map and endpoint cost map calendars reflects a
>divergence from the non-calendared functionality defined in RFC
>7285 and updated by RFC 8189; providing the constraint functionality in
>conjunction with calendar functionality is not feasible for the reasons described
>above, so the two features are mutually exclusive."
>
>I am sure you can come up with a more elegant phrasing than I just wrote on
>the fly.
>
>Thanks,
>
>Ben
>
>> 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".
>>
>> Section 1.1
>>
>> I'm not sure how much *archival* value there is in the current discussion of
>SENSE and Unicorn.
>>
>> 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?
>>
>> 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.
>>
>>    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.
>>
>>    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.
>>
>>    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?
>>
>> 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?
>>
>> 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.
>>
>>    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?
>>
>>       *  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").
>>
>>    - 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).
>>
>> 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/
>>
>> Sectgion 5
>>
>> I'd consider using a more recent Date in the example.
>>
>> 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.
>>
>>
>>