ALTO Cost Calendar

Summary: Has a DISCUSS. Needs one more YES or NO OBJECTION position to pass.

(Ben Campbell) Discuss

Discuss (2018-12-04 for -09)
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.)
Comment (2018-12-04 for -09)
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.

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


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

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

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

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

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

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

Alvaro Retana Discuss

Discuss (2018-12-05 for -09)
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.


Mirja Kühlewind Yes

Ignas Bagdonas No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

Comment (2018-12-05 for -09)
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."

(Spencer Dawkins) No Objection

Comment (2018-12-04 for -09)
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

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

Benjamin Kaduk No Objection

Comment (2018-12-06 for -09)
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

Suresh Krishnan No Objection

Comment (2018-12-03 for -09)
* 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?

Alexey Melnikov No Objection

Comment (2018-11-29 for -09)
No email
send info
I agree that JSON issues found by Adam must be fixed before publication.

Adam Roach No Objection

Comment (2018-11-28 for -09)
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.



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:": {
        "ipv4:"    : [v1, v2, ... v24],
        "ipv4:" : [v1, v2, ... v24],
        "ipv4:"  : [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.



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



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



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



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



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



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

Martin Vigoureux No Objection

Roman Danyliw No Record

Warren Kumari No Record

Barry Leiba No Record

Éric Vyncke No Record

Magnus Westerlund No Record