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

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/

Thanks for addressing my comments from the previous IESG evaluation. Please expand "ALTO" in the title. See https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

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.palombini@ericsson.com>.
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)

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

[Thank you for addressing my DISCUSS.]

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.

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.

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?

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