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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 09 Mar 2020 17:21:06 -0700

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.

---

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Tue, 10 Mar 2020 09:40:13 +0000

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

Best regards,
Sabine

-----Original Message-----
From: Benjamin Kaduk via Datatracker <[email-masked]> 
Sent: Tuesday, March 10, 2020 1:21 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Vijay Gurbani <[email-masked]>; [email-masked]
Subject: Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-20: (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.)

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.

Section 1

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

Section 3.3

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.

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?

nit: no colon needed.

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

nit: hyphenate "Calendar-capable" (and similarly throughout).  I see that "calendar-aware" is already hyphenated, which is good.

Should we say anything about Calendar-aware ALTO Clients being able to get useful responses from legacy Servers as well?

Section 4

Section 4.1

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.

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":

Which capabilities?

nit: please be consistent about using "floating-point number" (vs., e.g., "floating point" or "float point").

I'm not sure I understand either of these points (how readability is helped and how confusion is avoided).

Section 4.2

This is "assumed" only for the purpose of the example, and not as a general protocol mechanism, right?

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"?

Sectgion 5

Section 5.1.1

There's probably some pedantic consideration here about "other extensions", such as the "multi-cost-types" member from RFC 8189.

Maybe reference RFC 8189 so the reader doesn't get confused by RFC 7285 specifying only a single metric type?

Section 5.1.2

side note: this structure where we effectively repeat the requirements of all previous specifications is not going to scale well with future extensions.

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.

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

nit: "non-real time" and "non-real-time" have different meanings, and I think the latter is the intended one.

     Content-Length: 1013

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

  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

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.

nit: "persecute" is an unusual word here; "execute" or "perform" seem like better alternatives.

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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 10 Mar 2020 18:23:31 -0700

Hi Sabine,

> 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), bu…

"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

---

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Wed, 11 Mar 2020 11:10:30 +0000

Hello Benjamin,

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

>From: Benjamin Kaduk <[email-masked]>
>Sent: Wednesday, March 11, 2020 2:24 AM
>To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <sabine.randriamasy@nokia-
>bell-labs.com>
>Cc: The IESG <[email-masked]>; [email-masked]; alto-
>[email-masked]; [email-masked]; Vijay Gurbani <[email-masked]>;
>[email-masked]
>Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-20:
>(with COMMENT)
>
>Hi Sabine,
>
>> 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 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
>conjunction with calendar functionality is not feasible for the reasons described
>above, so the two features are mutually exclusive."
>
>> Cc: [email-masked]; [email-masked];
>> [email-masked]; Vijay Gurbani <[email-masked]>;
>> [email-masked]
>> Subject: Benjamin Kaduk's No Objection on
>> draft-ietf-alto-cost-calendar-20: (with COMMENT)
>>
>> 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
>> 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.
>>
>> 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.
>> 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?
>>
>> 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
>>
>> nit: hyphenate "Calendar-capable" (and similarly throughout).  I see that
>"calendar-aware" is already hyphenated, which is good.
>>
>> Should we say anything about Calendar-aware ALTO Clients being able to get
>useful responses from legacy Servers as well?
>>
>> Section 4
>>
>> 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.
>> 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":
>>
>> 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/
>>
>>
>> There's probably some pedantic consideration here about "other extensions",
>such as the "multi-cost-types" member from RFC 8189.
>>
>> side note: this structure where we effectively repeat the requirements of all
>previous specifications is not going to scale well with future extensions.
>>
>> 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.
>>
>> 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
>>
>> 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
>>
>> 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.
>>

---

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Wed, 11 Mar 2020 18:17:30 +0000

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

>Cc: [email-masked]; [email-masked]; [email-masked];
>Vijay Gurbani <[email-masked]>; [email-masked]
>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.)
>
>
[     [SR]   ] done thanks
>I'm not sure how much *archival* value there is in the current discussion of
[     [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.
>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
>when the cost calendar functionality is active, which is not a subset of when
>the extension is implemented.
[ [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

>   ALTO requests and responses for Cost Calendars.
[ [SR]   ] done, thanks
>"calendar-aware" is already hyphenated, which is good.
[ [SR]   ] done in v20 thanks

>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

>"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
>array of calendar-attributes, and we need to know which element of that
>array to use when processing calendars for that cost type.
[ [SR]   ] Agree. This text was moved right after the definition of CalendarAttributes
>         in the IRD entry to which the capabilities apply.
[ [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
>"floating point" or "float point").
[ [SR]   ] thanks, used "floating" everywhere
>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
>nit: s/owdelay/num-owdelay/
[[SR]] Done, thanks

>I'd consider using a more recent Date in the example.
[[SR]] agree, done thanks
>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
>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
>
>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

---

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Wed, 11 Mar 2020 18:21:23 +0000

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

>From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
>Sent: Wednesday, March 11, 2020 7:18 PM
>To: Benjamin Kaduk <[email-masked]>; The IESG <[email-masked]>
>Subject: RE: Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-20:
>(with COMMENT)
>
>Hello Benjamin,
>
>>the calendar functionality.  I would suggest further clarifying that
>>this reflects a limitation of this method or reduction in functionality
>>when compared to RFC
>>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.
>>different size than expected?  Where do we specify error handling for those
>cases?
>>
>>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
>>
>>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/
>>
>>
>>of all previous specifications is not going to scale well with future extensions.
>>
>>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.
>>
>>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
>>
>>I think [IEEE.754.2008] needs to be normative, as do RFCs 5246 and
>>8446, and draft-ietf-alto-incr-update-sse.
>>
>>

---

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

Hi Benjamin,

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

Hello Benjamin,

Best regards,
Sabine

>draft-ietf-alto-cost-calendar-20: No Objection
[[SR]] Most of your text was used, thanks, and added to the text on constraints in section 3.3:
----- NEW
As providing the constraint functionality in conjunction 
   with the Calendar functionality is not feasible for the reasons described above, 
   the two features are mutually exclusive. The absence of constraints on 
   Filtered Cost Map and Endpoint Cost Map Calendars 
   reflects a divergence from the non-calendared information resources defined in 
   <xref target="RFC7285"/> and extended in <xref target="RFC8189"/>, 
that support optional constraints.
----- END

[ [SR] ] done thanks

>discussion of SENSE and Unicorn.
[ [SR] ] Text was changed to be less project-centric and instead focusing on the motivating use-case. 
Reference [I-D.xiang-alto-multidomain-analytics] was changed to an archived journal paper [Unicorn-fgcs].

   definition of a legacy cost map given in [RFC7285] to allow a cost

>different size than expected?  Where do we specify error handling for those cases?
>
[[SR]]
There is actually no way for a Client to notify a Server that the size of the received array is not as expected.
So, the text you quoted a paragraph has been adapted and augmented with rules attempting to address this case. 
It has been added after the text you quoted, as follows:
----- NEW
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  a Cost Calendar for a given
   cost type.  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.  The
   following rules attempt to ensure consistency between the array size
   announced by the Server and the actual size of the array received by
   the Client:

   o  The size of the array of values conveyed in a Cost Calendar and
      received by the Client MUST be equal to the value of attribute
      "number-of-intervals" indicated in the IRD for the requested cost
      type.

  o  When the size of the array received by the Client is different
      from the expected size, the Client SHOULD ignore the received
      array.
----- END

[ [SR] ] done, thanks

>"calendar of numerical" that would need many new types to support different types of calendar)?
>
[[SR]] The idea is that the attributes specifying the time granularity of a Calendar are not globally tied with 
a cost type but with a cost type within a resource. The text has been updated in 2 steps:

- Step 1: 3rd bullet you quoted was modified as follows:
----- NEW
it allows an ALTO Server to offer, for a cost type, different
      Calendars with attributes that are specific to the information
      resources providing a Calendar for this cost type, instead of
      being globally specific to the cost type.
----- END

- Step 2: after the 2 other bullets and the next paragraph, a new paragraph was added:
----- NEW
Since Calendar attributes are specific to an information resource, a
   Server may adapt the granularity of the calendared information so as
   to moderate the volume of exchanged data.  For example: suppose a
   Server provides a Calendar for cost type name "routingcost".  The
   Server may offer a Calendar in a Cost Map resource, which may be a
   voluminous resource, as an array of 6 intervals lasting each 4 hours. 
It may also offer a Calendar in an Endpoint Cost Map resource, 
   which is potentially less voluminous, as a finer-grained array of 24 intervals lasting 1 hour each.
----- END

----- NEW
----- END
>requirement would help the reader.
[[SR]] Hoping I understood your comment, 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
   [RFC7285].
----- END

Please note that to address a similar comment by Francesca Palombini, 
a paragraph providing guidance to Clients in such a case has been added at the end of the security section 7.

>helped and how confusion is avoided).
[ [SR] ] Indeed the text was clarified as follows in v20, as readability was not the main point:
NEW

>How would a Client know that this mechanism is in use?
[[SR]] would the following update clarify? 
----- NEW
..... Cost Calendars, to another ALTO Server running in a subdomain.  The "root" ALTO Server
can provide a Calendar-specific resource entry, that has a media-type 
   of "application/alto-directory+json" and that specifies the 
   URI allowing to retrieve the location of a Calendar-aware Server and 
   discover its resources.
----- END

>general protocol mechanism, right?
[[SR]] yes, right

>so you don't end up also listing the calendar for the slowly-changing things in the same response?
>
[[SR]] yes, it is

>Also, nit: s/few/little/
[[SR]] done, thanks
>"filtered-cost-map-calendar" and "endpoint-cost-calendar-map"?
[[SR]]  There is no reason indeed. Resource name "endpoint-cost-calendar-map" has been turned into "endpoint-cost-map-calendar" throughout the document. 

[[SR]] Done, thanks

>extensions", such as the "multi-cost-types" member from RFC 8189.
[ [SR]   ] A sentence on RFC 8189 has been added as follows:
----- NEW 
The input parameters of a "legacy" request for a filtered cost map,
   defined by object ReqFilteredCostMap in section 11.3.2 of <xref target="RFC7285"/>,
   are augmented with one additional member. The same augmentation applies to object ReqFilteredCostMap
   defined in section 4.1.2 of <xref target="RFC8189"/>. ----- END

>specifying only a single metric type?
[ [SR]   ] The text was updated as follows:
----- NEW
This field is an array of 1 to N boolean values, where N is the
   number of requested metrics.  N is greater than 1 when the Client and
   the Server also implement [RFC8189]. ----- END
>of all previous specifications is not going to scale well with future extensions.
[[SR]] Yes, special care on this aspect will be needed to moderate the data exchange volume. 

>Member 'calendared' of what data structure?
[[SR]] of data structure ReqFilteredCostMap. The text has been updated as follows:
----- NEW
each "CalendarResponseAttributes" object in the array is specified
      for one or more cost types for which the value of member
      "calendared", in object ReqFilteredCostMap provided in the Client request,
      is equal to 'true' and for which a Calendar is
      provided for the requested information resource. ----- END

>attribute, which is not exactly what the quoted text seems to be saying.

[[SR]] The text, indeed is unclear. The text meant to says it is subset of the "cost-type-names" member of the entry in the "calendar-attributes" array of objects in the IRD that includes the requested cost type name.  To address this question and the next 2 ones, two updates have been made: 

1 - the text, in the last of the 3 preceding bullets presenting the "CalendarResponseAttributes" object was updated as follows. 
 
----- NEW  
the "CalendarResponseAttributes" object that applies to a cost
      type name has a corresponding "CalendarAttributes" object defined
      for this cost type name in the IRD capabilities of the requested
      information resource.  This object is the entry, in the "calendar-
      attributes" array member of the IRD resource entry, that includes
      the name of the requested cost type.  This corresponding
      "CalendarAttributes" object has the same values as object
      "CalendarResponseAttributes" for members "time-interval-size" and
      "number-of-intervals".  The members of the
      "CalendarResponseAttributes" object include all the members of the
      corresponding "CalendarAttributes" object.
----- END

2 - The text you quoted, that specifies member "cost-type-names" of object CalendarResponseAttributes has been updated as follows:
----- NEW
"cost-type-names": is an array of one or more cost-type-names to
      which the value of the other members of CalendarResponseAttributes
      apply and for which a Calendar has been requested.  The value of
      this member is a subset of the "cost-type-names" member of the
      abovementioned corresponding "CalendarAttributes" object in the
      "calendar-attributes" array member in the IRD. This member MUST
      be present when Cost Calendars are provided for more than one cost
      type. 
----- END
(last sentence addresses another review comment)

>"with the same semantics" should relax that

[[SR]] It is actually the same value, not only semantically. 
To clarify this, 3 updates have been made: 
1 - the abovementioned update "1"
2- the text on member "time-interval-size" has been updated as follows:
----- NEW
"time-interval-size": as specified in Section 4.1 and with the
      same value as in the abovementioned corresponding
      "CalendarAttributes" object.
----- END
3 - the text on member "time-interval-size" has been updated as follows:
----- NEW
"number-of-intervals ": as specified in Section 4.1 and with the
      same value as in the abovementioned corresponding
      "CalendarAttributes" object.
----- END
>think the latter is the intended one.
[[SR]] thanks, expression is now "non-real-time" 
>nit: hyphenate "network-provider-defined".
[[SR]] done, thanks
>of the response, I get something more like 1043 octets of content.
[[SR]] Thanks, the content length has been verified and updated for all the examples

>same as for ReqFilteredCostMap.
[[SR]] text was added as follows :
----- NEW
The interpretation of member "calendared" is the same as for the
   ReqFilteredCostMap object defined in Section 5.1.1 of this draft.
   The interpretation of the other member is the same as for object
   ReqEndpointCostMap is definedin [RFC7285] and [RFC8189].
----- END

>Also, nit: please use a consistent character to represent the bullet point.
[[SR]] Done, thanks year was changed to 2019 and bullets are harmonized

>custom.alto.example.com here (and in other examples)?
[[SR]] Done, thanks, host is now "custom.alto.example.com" everywhere

>like better alternatives.
[[SR]] expression was changed to "perpetrate"

[[SR]]  Done, thanks
>8446, and draft-ietf-alto-incr-update-sse.
[[SR]] done thanks, these references are now normative