Application-Layer Traffic Optimization (ALTO) Cost Calendar
draft-ietf-alto-cost-calendar-21

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

[Ballot comment]
This version is an improvement over the one I reviewed earlier.

**********************************************************************
* Note, that I am conducting an experiment when people aspiring to be*
* Area Directors get exposed to AD work ("AD shadowing experiment"). *
* As a part of this experiment they get to review documents on IESG  *
* telechats according to IESG Discuss criteria document and their    *
* comments get relayed pretty much verbatim to relevant editors/WGs. *
* As an AD I retain responsibility in defending their position when  *
* I agree with it.                                                  *
* Recipients of these reviews are encouraged to reply to me directly *
* about perceived successes or failures of this experiment.          *
**********************************************************************

The following comments were provided by Francesca Palombini .
My comments are marked with [[Alexey:]] below.

Francesca would have balloted *DISCUSS* on this document. She wrote:

DISCUSS

* "The encoding format for object CalendarAttributes, using JSON
  [RFC8259], is as follows:"
JSON is used, right. I know 7285 is normatively reference but the draft is missing either here or in the introduction part of the spec (e.g. terminology) to explicitly point to Section 8.2 of 7285 Notation, as that is used here.

COMMENT

* "However, like for any schedule, unexpected network
  incidents may require the current ALTO Calendar to be updated and re-
  sent to the ALTO Clients needing it.  The "ALTO Incremental Updates
  Using Server-Sent Events (SSE)" Service
  [I-D.ietf-alto-incr-update-sse] can be used to update the calendar
  faster if supported by both the Server and the Client."

  If the "ALTO Incremental Updates Using Server-Sent Events (SSE)" Service is not used, and updates are required, what should be used instead? (draft-ietf-alto-incr-update-sse is indeed informational reference)

* "with one value one per time interval," remove second "one"

* "Specifically, an
  implementation of this extension MUST parse the "number-of-intervals"
  attribute of the "calendar-attributes" in an IRD entry announcing a
  service providing Cost Calendar."
  Please ref to where "calendar-attrinutes" is defined.

* "Calendared" is used in the text. I would either rephrase or explain in the terminology what this is supposed to mean.

* Section 3 - "This section gives a non-normative overview of the design. " That is not true, as 3.3.2 at least contains normative text (as it should).

* "multiple
  appearances of a cost type name in the CalendarAttributes object of
  the "calendar-attributes" member MUST cause the ALTO Client to ignore
  any occurrences of this name beyond the first encountered occurrence."
  This worries me as occurrences can be re-ordered (by  intermediaries) I am not sure ignoring further occurrences and keep the processing is the best idea... This should at least have some security considerations.

* "A cost type name MUST NOT appear more than once in the
  "calendar-attributes" member of a resource entry;"
  Sounds to me like this should say MUST appear only once. What if it appears 0 times?

*"  o  "cost-type-names":

      *  An array of one or more elements indicating the cost-type-names
        in the IRD entry to which the capabilities apply."
  Please do not use the parameter "cost-type-names" to describe the parameter itself  ("indicating the cost-type-names")

* "This field is an array of 1 to N boolean values, where N is the
  number of requested metrics."
  I could not find in 7285 that more than one metric can be requested. Could you confirm and point to a ref?

* In the Filtered Map Response:
"object{
    [JSONString cost-type-names <1..*>];
    "
    Why is this array of one or more attributes optional? Also this is non explicitly stated in the text below.

* "[JSONString cost-type-names <1..*>];"
; should be inside the bracket

* "JSONString calendar-start-time;" please repeat or ref the section that states that the string contain an IMF-fixdate value

* "  o  the calendared costs are JSONArrays instead of the JSONNumbers
      format used by legacy ALTO implementations.  All arrays have a
      number of values equal to 'number-of-intervals'."
    Please explicitly state that each value correspond to the cost in that interval.

* Section 5.2 references to sections be fixed

* "The extensions to the requests for calendared Endpoint Cost Maps are
  the same as for the Filtered Cost Map Service, specified in section
  Section 5.1.1 of this draft."
  Not only, also the request method is the same, please explicitely state that.

* Section 5.2.1 - Compared to ReqEndpointCostMap of 7285 the object described here has optional cost-type. Why is that changed from 7285?

* ""calendared" : [true];" ; should be inside the bracket

* Please give a pointer to where "TypedEndpointAddr" is defined

* "ALTO Clients and Servers SHOULD support
  both TLS 1.3 [RFC8446] and TLS 1.2 [RFC5246]," why both?

* I believe TLS and JSON should be normative references of this document

*  ID Nits gives the following warnings:
-- Obsolete informational reference (is this intentional?): RFC 5246
    (Obsoleted by RFC 8446)

[[Alexey:]] This one is Ok if requirement to support TLS 1.2 is intended

  -- Obsolete informational reference (is this intentional?): RFC 7159
    (Obsoleted by RFC 8259)

[Ballot comment]
This version is an improvement over the one I reviewed earlier.

**********************************************************************
* Note, that I am conducting an experiment when people aspiring to be*
* Area Directors get exposed to AD work ("AD shadowing experiment"). *
* As a part of this experiment they get to review documents on IESG  *
* telechats according to IESG Discuss criteria document and their    *
* comments get relayed pretty much verbatim to relevant editors/WGs. *
* As an AD I retain responsibility in defending their position when  *
* I agree with it.                                                  *
* Recipients of these reviews are encouraged to reply to me directly *
* about perceived successes or failures of this experiment.          *
**********************************************************************

The following comments were provided by Francesca Palombini :

Francesca would have balloted *DISCUSS* on this document. She wrote:

[Ballot comment]
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.

[Ballot comment]
A few minor comments:

Section 1.1.  The role of the text describing the SENSE project isn’t clear. I’m not sure it will age will when in an RFC

Section 3.  Thanks for providing an overview with the section.  Given that this section is non-normative, how should the implementers use the text with RFC2119 words -- is it there just for emphasis?

Section 4.1.  Per ‘Attribute "cost-type-names" provides a better readability to the Calendar attributes specified …”, could you please clarify “a better readability”.

Section 4.3.  Nit. s/mode,to/mode, to/

[Ballot comment]
Thanks, Sabine, for addressing my comments!

There's just one minor thing still outstanding.  It's not a big deal, but the RFC Editor will raise it and it will save time later if you deal with it now:

The terminology section makes a point of citing the significance of the capitalization of "Client" and "Server", so it would be good to check the document for consistent usage of the capitalized terms, as I see quite a number of other such cases.  You did fix the one I called out specifically (in Section 3.1), but I still see a bunch of cases of "client" and "server" that are not capitalized, and that I think should be.  Please do check and correct the consistency.

[Ballot discuss]
Very easy-to-fix issue with date format specification:

— Section 5 —

  Both extensions need to return calendar start time (calendar-start-
  time, a point in time), which MUST be specified using the HTTP header
  fields format specified in [RFC7231] where, however, timestamps are
  still displayed with the acronym "GMT" rather than "UTC":

                    Date: Tue, 15 Nov 2014 08:12:31 GMT

The problem with this text is that 7231 specifies three formats and you don’t make it clear which one you want, other than by example.  The lack of a section reference doesn’t help (7231 is not small), but that wouldn’t be sufficient anyway.  I suggest this:

NEW
Both extensions return calendar start time (calendar-start-time, a point in time), which MUST be specified as an HTTP “Date” header field using the IMF-fixdate format specified in Section 7.1.1.1 of [RFC7231].  Note that the IMF-fixdate format uses “GMT”, not “UTC”, to designate the time zone, as in this example:

                    Date: Tue, 15 Nov 2014 08:12:31 GMT
END

— Section 5.1.2 —

  For example: suppose the "calendar-start-time" member has value "Mon,
  30 Jun 2014 at 00:00:00 GMT", the "time-interval-size" member has

That isn’t a valid calendar-start-time value unless you remove “ at”.

[Ballot comment]
Non-blocking comments, but some are important for clarity:

— Section 1 —

  applicable to any Cost Mode and they ensure backwards compatibility
  with legacy ALTO Clients.

What, exactly, are legacy ALTO Clients?  Are you referring to ALTO clients that don’t support this spec, or do you mean something else?  It would be worth saying here, as, “with legacy ALTO Clients — those that [whatever].”

  In the rest of this document, Section 2 provides the design
  characteristics.  Sections 3 and 4 define the formal specifications
  for the IRD and the information resources.  IANA, security and
  operational considerations are addressed respectively in sections
  Section 6, Section 7 and Section 8.

It’s a tiny thing, but I’ve never seen the value of paragraphs such as this, when there’s a table of contents two pages earlier.  And it’s wrong anyway (check it if you doubt me).  I would prefer that you just take this paragraph out.  But this is really just a rant: do as you think best.

— Section 3.1 —

  faster if supported by both the server and the client.

Do you mean, here, “both the Server and the Client.”?  The terminology section makes a point of citing the significance of the capitalization, so it would be good to check he document for consistent usage of the capitalized terms, as I see quite a number of other such cases.

— Section 3.3.2 —

  In the base protocol [RFC7285] section 11.2.3.6, an ALTO cost is
  specified as a generic JSONValue, allow extensions.

I can’t parse this and don’t understand what it’s trying to say.

— Section 4.1 —

  A Cost Calendar for a given Cost Type MUST be indicated in the IRD by
  an object of type CalendarAttributes.  A CalendarAttribute object is

“A CalendarAttributes object is” (the final “s” is missing)

  A Cost Type name MUST appear no more than once in the
  "calendar-attributes" member of a resource entry

Using “MUST” with a negative is usually, as here, more confusing than using “MUST NOT”.  I strongly recommend this instead:

NEW
  A given Cost Type name MUST NOT appear more than once in
  the "calendar-attributes" member of a resource entry
END

  multiple
  appearances of a Cost Type name in CalendarAttributes object of the
  "calendar-attributes" member MUST cause the ALTO Client to ignore

You’re missing an article before “CalendarAttributes”: should it be “the” or “a”?  You might consider rewording that sentence to be clearer.

  It is RECOMMENDED for an ALTO Server that the time interval size
  specified in the IRD is the smallest possible one that it can
  provide.  The Client can aggregate cost values on its own if it needs
  a larger granularity.

The English in the first sentence feels awkward (because you’re straining to make it passive).  In the second sentence, “larger” doesn’t really go with “granularity”, and it’s probably clearer to use “interval”.  So:

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

        and servers should be aware of potential issues caused by the
        precision issues caused by using floating point numbers.

“potential issues caused by the precision issues” is really awkward; I suggest rephrasing.

      *  is the positive integer number, at least equal to 1, to
        indicate of number of values of the Cost Calendar array.

Are there integers that are not numbers?  Is it possible to have a positive integer that is not at least equal to 1?  So is there a reason not to just say, “is a positive integer that specifies the number of values in the Cost Calendar array.” (which also fixes the “of...of...of” error)?

  - Attribute "cost-type-names" provides a better readability to the
  Calendar attributes specified in the IRD and avoids confusion with
  Calendar attributes of other cost-types.

I don’t understand what this means.  I can’t figure out “provides a better readability to”.  Can you rephrase?

— Section 4.2 —

  To achieve
  this, one option, is that a "root" ALTO Server implementing base
  protocol resources delegates "specialized" information resources such
  as the ones providing Cost Calendars, to another ALTO Server running
  in a subdomain that is specified with its URI in the "root" ALTO
  Server.

This sentence also blows out my parsing circuit; please try rephrasing.

  Another advantage 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, Cost Types with predictable and
  frequently changing values, calendared in short time intervals such
  as a minute.

And this one.

I’m sorry to pick on these, but the RFC Editor will have to try to fix the wording when they get to it, and they’re likely to get it wrong if the sentences are sufficiently difficult to follow.  That will result in problems during the editing phase, at best, and errors in the published RFC, at worst.

— Section 4.3 —

  The cost type names used in the example IRD as thus as follows:

Change “as thus” to “are”.

— Section 5.2.2 —

  Server response is thus changed as follows, w.r.t [RFC7285] and

Please don’t abbreviate “with respect to”.

— Section 5.2.3 —

  Therefore, it needs to both schedule its
  resource-greedy networking activities and its ALTO transactions.

Make it “schedule both”.

— Section 7 —

  For confidentiality of ALTO information, an operator should be
  cognizant that this extension may introduce a new risk: an ALTO
  Client may get information for future events that are scheduled
  through Calendaring.  Possessing such information, the client may use
  it to achieve its goal: (1) initiating connections only at
  advantageous network costs, leading to unexpected network load; (2)
  generating massive connections to the network at times where its load
  is expected to be high.

I couldn’t make sense of this until I realized that I think you mean that “an attacker” (not “the client”) may use it to achieve its goal.  Am I correct?  The phrase “at advantageous network costs” also doesn’t make sense here.  Maybe you mean “at very large network costs”, or some such?

  So ALTO Clients and servers MAY use newer
  versions (e.g., 1.3) of TLS as long as the negotiation process
  succeeds.  To ensure backward compatibility with [RFC7285], it is
  RECOMMENDED for both Calendar-aware Clients and Servers to both
  support at least TLS 1.2, until it gets deprecated.

This seems a little confused, and I would suggest a different recommendation anyway.  Maybe this, or something like it?:

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

— Section 8 —

  result in congestion or result in a less optimal global outcome
  (e.g., the 's Paradox [Braess-paradox]).

There’s something missing in the second line.

  Second, Although there are theoretical analysis
  [Selfish-routing-Roughgarden-thesis] and Internet based evaluations
  [Selfish-routing-Internet-eval] showing that uncoordinated behaviors
  may not result in substantial sub-optimal results, when a network
  operator updates the cost calendar, and when an application reacts to
  the update, they should still consider the potential feedback
  effects.

I think I understand what you’re saying here, but it seems hard to follow.  Maybe it could do with some rephrasing.  Does this work?:

NEW
Second, when a network operator updates the cost calendar and when an application reacts to the update, they should consider the feedback effects.  This is the best approach even though there is theoretical analysis [Selfish-routing-Roughgarden-thesis] and Internet based evaluation [Selfish-routing-Internet-eval] showing that uncoordinated behaviors do not always cause substantial sub-optimal results.
END

  Clients and Servers supporting ALTO Calendars use [RFC8259].
  [RFC7285] encodes its requests and responses using the JSON Data
  Interchange Format specified in [RFC7159].  In the meantime,
  [RFC7159] has been obsoleted by [RFC8259], that among others makes
  UTF-8 mandatory for text encoding to improve interoperability.

Rather than making the reader look up the references to figure this out, maybe we can help?:

NEW
The newer JSON Data Interchange Format specification [RFC8259] used in ALTO Calendars replaces the older one [RFC7159] used in the base ALTO protocol [RFC7285].  The newer JSON mandates UTF-8 text encoding to improve interoperability.
END

[Ballot comment]
This is a returning item as initially an IPR declaration what missed to take over from the initial draft (as raised in Alvaro's discuss). Therefore we re-ran both wg last call as well as IETF last call. This version also addresses all review comments from the last IESG evaluation and hopefully should now be ready to go!

Update: Latest version now also addresses the OPSDIR review from the last IETF last call.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-alto-cost-calendar-16, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

[Ballot comment]
This is a returning item as initially an IPR declaration what missed to take over from the initial draft (as raised in Alvaro's discuss). Therefore we re-ran both wg last call as well as IETF last call. This version also addresses all review comments from the last IESG evaluation and hopefully should now be ready to go!

Update: Note the OPSDIR review will be addressed in the next update early next week (we are just waiting for the main author to return from holidays but changes has been proposed and agreed with the OPSDIR reviewer).

[Ballot comment]
This is a returning item as initially an IPR declaration what missed to take over from the initial draft. Therefore we re-ran both wg last call as well as IETF last call. This version also addresses all review comments from the last IESG evaluation and hopefully should now be ready to go!

Update: Note the OPSDIR review will be addressed in the next update early next week (we are just waiting for the main author to return from holidays but changes has been proposed and agreed with the OPSDIR reviewer).

[Ballot comment]
This is a returning item as initially an IPR declaration what missed to take over from the initial draft. Therefore we re-ran both wg last call as well as IETF last call. This version also addresses all review comments from the last IESG evaluation and hopefully should now be ready to go!

The following Last Call announcement was sent out (ends 2020-02-24):

From: The IESG
To: IETF-Announce
CC: vijay.gurbani@nokia.com, alto@ietf.org, draft-ietf-alto-cost-calendar@ietf.org, alto-chairs@ietf.org, Vijay Gurbani , ietf@kuehlewind.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (ALTO Cost Calendar) to Proposed Standard


The IESG has received a request from the Application-Layer Traffic
Optimization WG (alto) to consider the following document: - 'ALTO Cost
Calendar'
  as Proposed Standard

This is the second IETF last call for this document as an IPR declaration was
missed when the first call was performed about a year ago (see below).
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-02-24. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document is an extension to the base Application-Layer Traffic
  Optimization (ALTO) protocol.  It extends the ALTO cost information
  service so that applications decide not only 'where' to connect, but
  also 'when'.  This is useful for applications that need to perform
  bulk data transfer and would like to schedule these transfers during
  an off-peak hour, for example.  This extension introduces ALTO Cost
  Calendar, with which an ALTO Server exposes ALTO cost values in JSON
  arrays where each value corresponds to a given time interval.  The
  time intervals as well as other Calendar attributes, are specified in
  the Information Resources Directory and ALTO Server responses.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2392/

ALTO Cost Calendar
draft-ietf-alto-cost-calendar-15
Shepherd: Vijay K. Gurbani

1. Summary

The document shepherd is Vijay K. Gurbani. The responsible Area Director is
Mirja Kuehlewind.

This document is an extension to the base ALTO protocol (RFC 7785).  It
extends the ALTO cost information service such that applications decide
not only 'where' to connect, but also 'when'.  This is useful for applications
that need to perform bulk data transfer and would like to schedule these
transfers during an off-peak hour, for example.

This document is targeted as a Standards Track document (Proposed Standard).
This designation is appropriate as the document contains normative behaviour
and message formats that should be adhered to by the communicating entities
in order to realize the extension.

2. Review and Consensus

Cost calendar is a well-know extension within the working group, having been
first presented as an individual document on Jul 4, 2014 (individual -00
version).  It was subsequently adopted as WG item on Jul 28, 2016.

The work has been reviewed by at least four key WG members in the past.  Version
-01 was reviewed on Jun 29, 2017 by Yichen Qian and Li Geng; version -02 was
reviewed by Dawn Chen on Jul 12, 2017 and by Jensen Zhang on Dec 02, 2017.  A
WGLC was held on Feb 22, 2018.

Post WGLC, version -06 of the document added a beefed up Security Consideration
and a new Operations Consideration section to the draft.  Key members of the WG
(Dawn Chen and Jensen Zhang) reviewed these two sections of the draft.

The draft was presented to the IESG and balloted on 2018-12-04.  This balloting
resulted in a number of COMMENT and two DISCUSS that brought the draft back to
the WG [1].  The comments have all been addressed to the satisfaction of the
ADs, as have the DISCUSSes as part of a second WGLC.  During the second WGLC,
Kai Gao, and Jensen Zhang provided a WGLC review.  I did a shepherd's review as
well.  The WG considers the draft to be ready to move to IESG.

There is one known implementation, authored by the editor of the draft.
The work has been discussed extensively in the WG over the years, and the
WG feels that the document is ready to be moved out of the group and into
IESG.

3. Intellectual Property

The entire author team has confirmed conformance with BCP 78/79 with the
shepherd. 

4. Other Points
1. idnits reports two comments on obsolete references; the authors have been
notified and will prefer to fix that during AUTH48.
2. All of the JSON code in the draft has been checked for syntax by the author
team.

[1] https://mailarchive.ietf.org/arch/msg/alto/e__lHfY4j4tS6FTANp3Lr_R6vp0

ALTO Cost Calendar
draft-ietf-alto-cost-calendar-14
Shepherd: Vijay K. Gurbani

1. Summary

The document shepherd is Vijay K. Gurbani. The responsible Area Director is
Mirja Kuehlewind.

This document is an extension to the base ALTO protocol (RFC 7785).  It
extends the ALTO cost information service such that applications decide
not only 'where' to connect, but also 'when'.  This is useful for applications
that need to perform bulk data transfer and would like to schedule these
transfers during an off-peak hour, for example.

This document is targeted as a Standards Track document (Proposed Standard).
This designation is appropriate as the document contains normative behaviour
and message formats that should be adhered to by the communicating entities
in order to realize the extension.

2. Review and Consensus

Cost calendar is a well-know extension within the working group, having been
first presented as an individual document on Jul 4, 2014 (individual -00
version).  It was subsequently adopted as WG item on Jul 28, 2016.

The work has been reviewed by at least four key WG members in the past.
Version -01 was reviewed on Jun 29, 2017 by Yichen Qian and Li Geng; version
-02 was reviewed by Dawn Chen on Jul 12, 2017 and by Jensen Zhang on Dec 02,
2017.  A WGLC was held on Feb 22, 2018.

Post WGLC, version -06 of the document added a beefed up Security
Consideration and a new Operations Consideration section to the draft.
Key members of the WG (Dawn Chen and Jensen Zhang) reviewed these two
sections of the draft.

The draft was presented to the IESG and balloted on 2018-12-04.  This balloting
resulted in a number of COMMENT and two DISCUSS that brought the draft back
to the WG [1].  The comments have all been addressed to the satisfaction of the ADs,
as have the DISCUSSes as part of a second WGLC.  During the second WGLC, Kai Gao,
and Jensen Zhang provided a WGLC review.  I did a shepherd's review as well.  The
WG considers the draft to be ready to move to IESG.

There is one known implementation, authored by the editor of the draft.
The work has been discussed extensively in the WG over the years, and the
WG feels that the document is ready to be moved out of the group and into
IESG.

3. Intellectual Property

The entire author team has confirmed conformance with BCP 78/79 with the
shephered. 

4. Other Points
idnits reports one error in -14.  The authors have been notified and may push
out a -15 to correct it.  If not, this will be handled in AUTH48.

[1] https://mailarchive.ietf.org/arch/msg/alto/e__lHfY4j4tS6FTANp3Lr_R6vp0

ALTO Cost Calendar
draft-ietf-alto-cost-calendar-14
Shepherd: Vijay K. Gurbani

1. Summary

The document shepherd is Vijay K. Gurbani. The responsible Area Director is
Mirja Kuehlewind.

This document is an extension to the base ALTO protocol (RFC 7785).  It
extends the ALTO cost information service such that applications decide
not only 'where' to connect, but also 'when'.  This is useful for applications
that need to perform bulk data transfer and would like to schedule these
transfers during an off-peak hour, for example.

This document is targeted as a Standards Track document (Proposed Standard).
This designation is appropriate as the document contains normative behaviour
and message formats that should be adhered to by the communicating entities
in order to realize the extension.

2. Review and Consensus

Cost calendar is a well-know extension within the working group, having been
first presented as an individual document on Jul 4, 2014 (individual -00
version).  It was subsequently adopted as WG item on Jul 28, 2016.

The work has been reviewed by at least four key WG members in the past.
Version -01 was reviewed on Jun 29, 2017 by Yichen Qian and Li Geng; version
-02 was reviewed by Dawn Chen on Jul 12, 2017 and by Jensen Zhang on Dec 02,
2017.  A WGLC was held on Feb 22, 2018.

Post WGLC, version -06 of the document added a beefed up Security
Consideration and a new Operations Consideration section to the draft.
Key members of the WG (Dawn Chen and Jensen Zhang) reviewed these two
sections of the draft.

The draft was presented to the IESG and balloted on 2018-12-04.  This balloting
resulted in a number of COMMENT and two DISCUSS that brought the draft back
to the WG [1].  The comments have all been addressed to the satisfaction of the ADs,
as have the DISCUSSes as part of a second WGLC.  During the second WGLC, Kai Gao,
and Jensen Zhang provided a WGLC review.  I did a shepherd's review as well.  The
WG considers the draft to be ready to move to IESG.

There is one known implementation, authored by the editor of the draft.
The work has been discussed extensively in the WG over the years, and the
WG feels that the document is ready to be moved out of the group and into
IESG.

3. Intellectual Property

The entire author team has confirmed conformance with BCP 78/79 with the
shephered. 

4. Other Points
idnits reports one error in -14.  The authors have been notified and may push
out a -15 to correct it.  If not, this will be handled in AUTH48.

[1] https://mailarchive.ietf.org/arch/msg/alto/e__lHfY4j4tS6FTANp3Lr_R6vp0

During the first IESG review of the draft, issues were raised that a second WGLC is required; see [1].
So bringing the draft back into the WG.

[1] https://mailarchive.ietf.org/arch/msg/alto/CVrdXuniggnJMxJySJlwhbxQgyA

- vijay

[Ballot comment]
Section 3.1

  The capabilities of a Calendar-aware information resource entry have
  a member named "calendar-attributes" which is an array of objects of
  type CalendarAttributes.  It is necessary to use an array because of
  resources such as Filtered Cost Map and Endpoint Cost Map, for which
  the member "cost-type-names" is an array of 1 or more values.

I don't really follow this argument.  Why does the value for "cost-type-names"
affect the structure of the containing "calendar-attributes"?

  An ALTO Client should assume that the time interval size specified in
  the IRD is the smallest possible one that the ALTO Server can
  provide.  The Client can aggregate cost values on its own if it needs
  a larger granularity.

Where is the normative requirement on the server to behave in this fashion?

It's weird to use string packing for units instead of a separate
structured element in the language/structure.

Section 4.1.1

  This field is an array of 1 to N boolean values, where N is the
  number of requested metrics.  Each boolean value indicates whether or
  not the ALTO Server should provide the values for this Cost Type as a
  calendar.  The array MUST contain exactly N boolean values, otherwise
  the server returns an error.

Is it a MUST requirement for the server to check?

Section 4.2.2

  If the ALTO client provides member "calendared" in the input
  parameters with a value equal to 'true' for given requested Cost
  Types, the "meta" member of a Calendared Endpoint Cost response MUST
  include, for these Cost Types, the same additional member "calendar-
  response-attributes", as specified for the Filtered Cost Map Service.

On first reading I thought this was a requirement for data/value
consistency between endpoint icost and filtered cost map service
responses, but rereading it looks like it's just data structure reuse.
So maybe something like "the contents of which obey the same rules as
for the Filtered Cost Map Service (Section 4.1.2)".

Section 6

Thanks for these well-thought-out security considerations; it's a
pleasure to see.

With respect to the last paragraph's mention of how the provided future
guidance can be wrong, is this going to be a scenario where it would be
helpful for the client to be able to just ping the server to ask "you
gave me this data yesterday and I just want to double-check that it's
still fresh/correct"?  I don't see an obvious way in which this would be
helpful (unless the size of the JSON responses are getting to be
prohibitively large or something, I suppose), but I'm writing this on a
plane so the risk of me missing something is higher even than its usual
rate.

[Ballot discuss]
This is a process DISCUSS.

This document replaces draft-randriamasy-alto-cost-calendar, but this information is not reflected in the datatracker.  The individual draft has an IPR declaration attached to it [1], but the failure to link the two documents has resulted in the IPR indication not carrying over.  The direct effect is that the IETF Last Call [2] explicitly says that "No IPR declarations have been submitted directly on this I-D."

The Shepherd writeup says that "The entire author team has confirmed conformance with BCP 78/79 with the shephered." -- but that doesn't indicate whether IPR is present or not, just conformance.  In looking through the mailing list archive, I couldn't find mention of the IPR at adoption [3] [4] or at WGLC [5].

The declaration was made early in the process [6], and there was no discussion in the WG about it.  I can see how it would be easy to overlook.

Nonetheless, it is necessary for the WG (and the IETF as a whole) to explicitly consider the declaration before proceeding with the publication of this document.

[1] https://datatracker.ietf.org/ipr/2392/
[2] https://mailarchive.ietf.org/arch/msg/alto/LI01TfoTCnJRDImEUXA-9x8KsZ4
[3] https://mailarchive.ietf.org/arch/msg/alto/xFErWArHhpF-0ZVR_1BAhgzRj3k
[4] https://mailarchive.ietf.org/arch/msg/alto/-D7cj6qoD-Q3ye3rpuj8li2xWms
[5] https://mailarchive.ietf.org/arch/msg/alto/67W_XuMfu7JMXQEEZFLkulw_xBI
[6] https://mailarchive.ietf.org/arch/msg/ipr-announce/lnZ65z15_Dn3bylJp7h9rGHxZFk

[Ballot comment]
Please use HTTPS URIs in the examples.

Section 4: I think the correct description of the time zone is actually UTC, per RFC 7231, even though timestamps get displayed with the acronym "GMT."

[Ballot discuss]
Thanks for the work on this document. I see value, but have a couple of points I think need to be resolved prior to publication:

§3.1, definition of "time-interval-size": What is the reasoning behind using a string to define the unit? That requires text parsing/comparison to determine the interval. I assume this is intended more for machine use than for human use. Did the working group consider making this a multiple of some primitive time interval? E.g. number of seconds, or perhaps number of minutes? it seems like that would be easier (and therefore less error prone) to interpret.

If there is a reason to use a text field, is there an enumeration of legal unit values? Can I use "12 parsecs"?

§4.1.2, last paragraph: "The ALTO Client thus may use the same calendar for the next 4 days starting at "calendar-start-time" and will only need to request a new one for Friday July 4th at 00:00:00 GMT."

This implies that if an ALTO server delivers a calendar with a long duration, it cannot make changes to the metrics in that calendar, or if it does make them it cannot expect the client to learn about those changes. Is that the intent? If so, it seems to contradict language in the security considerations (§6) that future events may change and that the client should ensure information updates. (The operational considerations [§7] also say the client does not need to query again during the calendar duration.)

[Ballot comment]
I also have a number of substantive and editorial comments that do not rise to the level of a DISCUSS:

*** Substantive Comments ***

- General: (No action expected): For future reference, this is the sort of draft that I think should be referred to the ART area review team for review. It's effectively an application layer protocol, even if it affects transport layer decisions. (I note that none of the requested directorate reviews appear to have happened either, which is unfortunate.)

§2, 4th paragraph: "that can be historic": I don't see mention of how historic data would be used. Maybe I missed something?

§2.2.1, 2nd paragraph: Please elaborate on what is meant by "carefully managed". What specific things need to be considered?

§2.2.2, 3rd paragraph: This needs elaboration. I think it means that it must be possible to retrieve  the "now" version of the metric, but one could not retrieve a future value as a single value.

§3.1,
- 3rd paragraph: "A member "calendar-attributes" MUST appear only once": Does that mean exactly once? No more than once?

- note after definition of "number-of-intervals": Where is "cost-type-name" defined? Was this meant to be "cost-type-names"? If so, this paragraph makes it sound optional, but it was not shown as optional in the schema.

§4: It is not clear from the text if it saying the time zone is GMT in the example, or if it is always GMT. I assume the former, but the wording of the last paragraph suggests that the use of the HTTP header field format forces the time zone to always be GMT.

§4.1.1:

- Third paragraph:  I assume each entry corresponds to the requested metric at the same array position? If so, please say that explicitly.

4th paragraph: 'This field SHOULD NOT be specified if no member "calendar-attributes" is specified in this information resource.'
Why is the SHOULD NOT not a MUST NOT?  (Also, should "specified" be "included"?)

- 2nd to last paragraph: I don't understand the purpose of this paragraph. I assume "supporting single cost type values" means "only supporting" them. Why would the client request calendared values in the first place if it only supported single values?

- last paragraph: How is this different than the requirement in the 2nd paragraph?

§4.1.2
- first paragraph: "All arrays have a number of values equal to ’number-of-intervals’."

Which "number-of-intervals" does this talk about? The one in the capabilities or in "Calendar ResponseAttributes"?

Does that mean each element is valid for the time-interval that matches its array position? If so, please say that explicitly.

I'm surprised to see this require a metric entry for each individual time interval. It your want a high resolution of time intervals, you may end up with a large number of entries. Did the WG consider making it possible to have a single metric entry cover multiple time intervals? As this is currently defined, I think there needs to be guidance to implementors that they need to balance calendar length and granularity against the required number of metric entries.

- definition of "Calendar-start-time" Please elaborate on why the start time SHOULD be no later than the current date? (Also, consider "SHOULD NOT be later...")

§6: last paragraph:
- I'm not sure what it means for a repeat pattern to be "statistical".
- The guidance that future events can change and the client should ensure information updates seems to conflict with guidance elsewhere that the client does not need to requery until a calendar duration ends. (See DISCUSS point.)

*** Editorial Comments and Nits ***

- IDNits reports some issues; please check.

- Abstract: Please expand ALTO on first mention in the abstract and the body.

§1
- Please expand PID on first mention.

- 6th paragraph:
-- "specified by information
resources capabilities": should that be something to the effect of "specified in terms of resource capabilities"?
-- please expand IRD on first mention
-- "the proposed extensions": They will no longer be "proposed" once this is published as an RFC.

§2
- paragraph 4: "flash mobs" seems like an odd example of a predictable event, at least to anyone other than the event organizers and participants.

§2.1,
- first bullet: "attributes to interpret the time scope": I think the client does the interpreting. Perhaps "attributes to describe the time scope"?
- "repeated": I gather there is no option for unbounded repetition; it would be worth mentioning that up front.

§3.1, third paragraph: "If "calendarattributes"
are specified several times"
I assume this means "more than one" time. "Several" often connotes a number greater than a "few" but less than "many". That is, people may not think of "2" as "several".

- Please cite the json schema format you are using. I assume it is the one defined in the alto protocol RFC, but that should be mentioned explicitly.

- last paragraph: First sentence is hard to parse.

§3.2, first paragraph, first sentence: I'm not sure what "clarify" means in context; was that the correct word choice?

§3.3, first paragraph: "As [RFC7285] makes it mandatory, it uses metric
"routingcost" in the "numerical" mode."
The antecedents for both occurrences of "it" have unclear antecedents.

§4.1.2
- First paragraph: The first sentence is confusing.  I think it means "instead of the format used by legacy implementations", but it con be interpreted the say that arrays are used for legacy implementations.
- 2nd paragraph: "include at least" doesn't really fit the content of the list entries.
- first major bullet: I suspect "supports" should be "requested". (same for 2nd major bullet)

- paragraph starting with "- In addition, the "meta" field..." If this is required, why was it not included in the bullet list of required information?

- definition of "calendar-start-time" : I don't understand how "by default" interacts with SHOULD.

§5, last paragraph: "For potential undesirable guidance of ALTO information..."
That wording is confusing. I suggest something like "To avoid malicious or erroneous guidance from ALTO information..."

[Ballot comment]
Thanks for specifying this useful capability.

I did have one question - I didn't see anywhere in the document that

  An ALTO Cost calendar provided by the ALTO Server provides 2
  information items:

  o  an array of values for a given metric, where each value
      corresponds to a time interval, where the value array can
      sometimes be a cyclic pattern that repeats a certain number of
      times.

allowed a cyclic pattern to repeat indefinitely. Just for my background, that's an intentional omission, right?

[Ballot comment]
* Section 4.2.3. and 4.2.4.

This document uses addresses from the allocatable global unicast IPv6 space in 2000::/3 in the examples. Please use addresses from the 2001:db8::/32 documentation prefix instead for the examples as per RFC6890.

* Section 6

Any reason this document requires the use of TLS 1.2 instead of TLS 1.3?

[Ballot comment]

Thanks to everyone who worked on creating this extension. It seems useful, and
the document is easy to read. I have a handful of suggestions for improvement.

---------------------------------------------------------------------------

General:

I found a surprising number of JSON errors in this document by casual
examination.  Those errors I found are called out below, but it is extremely
likely that I have missed some issues. Please run the JSON examples in this
document through a formal validation prior to publication.

With a reasonably modern version of nodejs, validation can be as simple as
something like:


node -e 'console.log(JSON.stringify(JSON.parse(`
  {
    "meta" : {
      "cost-type" : {"cost-mode" : "numerical",
                    "cost-metric" : "routingcost"},
      "calendar-response-attributes" : [
        {"calendar-start-time" : Mon, 30 Jun 2014 00:00:00 GMT,
        "time-interval-size" : "1 hour",
        "number-of-intervals" : 24,
        "repeated": 4
        }
      ],
    }
    "endpoint-cost-map" : {
      "ipv4:192.0.2.2": {
        "ipv4:192.0.2.89"    : [v1, v2, ... v24],
        "ipv4:198.51.100.34" : [v1, v2, ... v24],
        "ipv4:203.0.113.45"  : [v1, v2, ... v24],
        "ipv6:2000::1:2345:6789:abcd" : [v1, v2, ... v24]
      }
    }
  }
`)));'

Running this example shows the first error in this example, involving the
date. After fixing that error, you will find the missing comma. And so on.

---------------------------------------------------------------------------

General:

Please expand "ALTO" in the title, in the Abstract, and on first use in the body
of the document.

---------------------------------------------------------------------------

§6:

>  [RFC7285] ensures the availability of such a solution in its
>  Section 8.3.5.  "Authentication and Encryption", which specifies that
>  "ALTO server implementations as well as ALTO client implementations
>  MUST support the "https" URI scheme [RFC2818] and Transport Layer
>  Security (TLS) [RFC5246]".

Based on this guidance, I would encourage updating all instances of "http://" in
this document to instead be "https://". I count four such instances.

---------------------------------------------------------------------------

§1:

>  In this draft an "ALTO Cost Calendar" is specified by information
>  resources capabilities that are applicable to time-sensitive ALTO
>  metrics.  An ALTO Cost Calendar exposes ALTO Cost Values in JSON

Please cite RFC 8259.

---------------------------------------------------------------------------

§4.1.3:

>        "calendar-response-attributes" : [
>          "calendar-start-time" : Tue, 1 Jul 2014 13:00:00 GMT,
>          "time-interval-size" : "2 hour",

Nit: The value for calendar-start-time needs to be enclosed in quotation marks.

      "cost-map" : {
        "PID1": { "PID1": [v1,v2, ... v12],
                  "PID2": [v1,v2, ... v12],
                  "PID3": [v1,v2, ... v12] },
        "PID2": { "PID1": [v1,v2, ... v12],
                  "PID2": [v1,v2, ... v12],
                  "PID3": [v1,v2, ... v12] }
      }

I don't quite follow this closely enough to understand what is intended here,
but the naked 'v1,v2' in the arrays are not valid JSON. Assuming these are
literal values, they need to each be enclosed in quotation marks.

Both of these comments apply to the examples given in §4.2.3 and §4.2.3 as
well.

---------------------------------------------------------------------------

§4.2.3:

>      "ipv6:2000::1:2345:6789:abcd"

Please use an address from the range reserved by RFC 3489.

This comment applies to the example given in §4.2.4 as well.

>  }
>  "endpoint-cost-map" : {

There is a missing comma after the closing brace.

---------------------------------------------------------------------------

§4.2.4:

>    "calendar-response-attributes" : [
>      {"cost-type-name : num-routingcost"

Nit: This line is missing two quotation marks and a comma. It should be:

        {"cost-type-name" : "num-routingcost",

ALTO Cost Calendar
draft-ietf-alto-cost-calendar-07
Shepherd: Vijay K. Gurbani

1. Summary

The document shepherd is Vijay K. Gurbani. The responsible Area Director is
Mirja Kuehlewind.

This document is an extension to the base ALTO protocol (RFC 7785).  It
extends the ALTO cost information service such that applications decide
not only 'where' to connect, but also 'when'.  This is useful for applications
that need to perform bulk data transfer and would like to schedule these
transfers during an off-peak hour, for example.

This document is targeted as a Standards Track document (Proposed Standard).
This designation is appropriate as the document contains normative behaviour
and message formats that should be adhered to by the communicating entities
in order to realize the extension.

2. Review and Consensus

Cost calendar is a well-know extension within the working group, having been
first presented as an individual document on Jul 4, 2014 (individual -00
version).  It was subsequently adopted as WG item on Jul 28, 2016.

The work has been reviewed by at least four key WG members in the past.
Version -01 was reviewed on Jun 29, 2017 by Yichen Qian and Li Geng; version
-02 was reviewed by Dawn Chen on Jul 12, 2017 and by Jensen Zhang on Dec 02,
2017.  A WGLC was held on Feb 22, 2018.

Post WGLC, version -06 of the document added a beefed up Security
Consideration and a new Operations Consideration section to the draft.
Key members of the WG (Dawn Chen and Jensen Zhang) reviewed these two
sections of the draft.

There is one known implementation, authored by the editor of the draft.
The work has been discussed extensively in the WG over the years, and the
WG feels that the document is ready to be moved out of the group and into
IESG.

3. Intellectual Property

The entire author team has confirmed conformance with BCP 78/79 with the
shephered. 

4. Other Points
idnits does not report any issues on -07.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-alto-cost-calendar-09, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-11-28):

From: The IESG
To: IETF-Announce
CC: Vijay Gurbani , vijay.gurbani@nokia.com, alto@ietf.org, draft-ietf-alto-cost-calendar@ietf.org, alto-chairs@ietf.org, ietf@kuehlewind.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (ALTO Cost Calendar) to Proposed Standard


The IESG has received a request from the Application-Layer Traffic
Optimization WG (alto) to consider the following document: - 'ALTO Cost
Calendar'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-11-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document is an extension to the base ALTO protocol [RFC7285].
  It extends the ALTO cost information service such that applications
  decide not only 'where' to connect, but also 'when'.  This is useful
  for applications that need to perform bulk data transfer and would
  like to schedule these transfers during an off-peak hour, for
  example.  This extension introduces ALTO Cost Calendars, with which
  an ALTO Server exposes ALTO cost values in JSON arrays where each
  value corresponds to a given time interval.  The time intervals as
  well as other Calendar attributes are specified in the Information
  Resources Directory and ALTO Server responses.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/ballot/


No IPR declarations have been submitted directly on this I-D.

ALTO Cost Calendar
draft-ietf-alto-cost-calendar-07
Shepherd: Vijay K. Gurbani

1. Summary

The document shepherd is Vijay K. Gurbani. The responsible Area Director is
Mirja Kuehlwind.

This document is an extension to the base ALTO protocol (RFC 7785).  It
extends the ALTO cost information service such that applications decide
not only 'where' to connect, but also 'when'.  This is useful for applications
that need to perform bulk data transfer and would like to schedule these
transfers during an off-peak hour, for example.

This document is targeted as a Standards Track document (Proposed Standard).
This designation is appropriate as the document contains normative behaviour
and message formats that should be adhered to by the communicating entities
in order to realize the extension.

2. Review and Consensus

Cost calendar is a well-know extension within the working group, having been
first presented as an individual document on Jul 4, 2014 (individual -00
version).  It was subsequently adopted as WG item on Jul 28, 2016.

The work has been reviewed by at least four key WG members in the past.
Version -01 was reviewed on Jun 29, 2017 by Yichen Qian and Li Geng; version
-02 was reviewed by Dawn Chen on Jul 12, 2017 and by Jensen Zhang on Dec 02,
2017.  A WGLC was held on Feb 22, 2018.

Post WGLC, version -06 of the document added a beefed up Security
Consideration and a new Operations Consideration section to the draft.
Key members of the WG (Dawn Chen and Jensen Zhang) reviewed these two
sections of the draft.

There is one known implementation, authored by the editor of the draft.
The work has been discussed extensively in the WG over the years, and the
WG feels that the document is ready to be moved out of the group and into
IESG.

3. Intellectual Property

The entire author team has confirmed conformance with BCP 78/79 with the
shephered. 

4. Other Points
idnits does not report any issues on -07.

The WGLC for this document ended on Mar 4, 2018 [1] and the WG has been notified of its forward movement.  I am proceeding to move the document forward.

[1] https://www.ietf.org/mail-archive/web/alto/current/msg03660.html