Re: [alto] AD review of draft-ietf-alto-cost-calendar-07

["Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[e-mail]>]

Hello Mirja,

Thanks a lot for your review. We will address the comments and get back to you asap.
Best regards,
Sabine


-----Original Message-----
From: Mirja Kuehlewind (IETF) [mailto:[e-mail]] 
Sent: Monday, August 06, 2018 4:12 PM
To: [e-mail]
Cc: [e-mail]
Subject: AD review of draft-ietf-alto-cost-calendar-07

Hi all,

I reviewed this draft and there are a few minor fixes that we need before we can start IETF last call:

1) Please remove the following sentence, or refer to the respective sections instead:
„IANA considerations and security considerations will be completed in
   further versions."

2) Please fix everywhere in the doc:
"Content-Length: TODO“

3) Also please make all occurrences of RFC7285 an actually reference ("[RFC7285]" instead of only „RFC7285“).

4) Then I also have a question about this example in Sec 4.1.2:
"For example: if the "calendar-start-time" member has value "Mon, 30
   Jun 2014 at 00:00:00 GMT" and if the value of member "repeated" is
   equal to 4, it means that the calendar values are the same values on
   Monday, Tuesday, Wednesday and Thursday.  The ALTO Client thus may
   use the same calendar for the next 4 duration periods following
   "calendar-start-time“.“
I think this example only makes sense if also the duration period based on "time-interval-size“ and "number-of-intervals“ with „1 hour“ and „24“ respectively is given, right? Can you please add this here.

And one minor (technical) comment/question that I would like to discuss before we go into IETF last call:
Why is "time-interval-size“ combining the value and unit in one element, instead of e.g. using "time-interval-unit“ and "time-interval-value“? Would that not make the implementation of the parsing much simpler?  

And finally, you use the cost type names "num-routingcost", "num-latency", "num-pathbandwidth" and "string-quality-status“ as well as metrics "routingcost", "latency" and "bandwidthscore" in the examples and say that "The cost types in this example are either specified in the base ALTO
   protocol or may be specified in other drafts see
   [draft-ietf-alto-performance-metrics] or defined in this draft for
   illustrative purposes.“
However, non of these metrics are actually defined in [draft-ietf-alto-performance-metrics], nor are they „defined“ in this doc. Would it maybe make sense to actually use cost types and metrics from [draft-ietf-alto-performance-metrics] in these examples (or remove the reference and provide some kind of definition)?

Given I reviewed the whole doc, also a couple of editorial comments/proposals below (however, I fully leave it to the authors' judgement to apply these or not).

Thanks!
Mirja


————————————————
Other editorial comments:

1) The abstract is quite long. I think if it could be formulated more crisp, it would be easier to read, e.g. see the text in the shepherd write-up

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

2) I know that IRD is on the known abbreviation list, maybe still spell it out at first occurrence for the ease of the reader…?

3) As the alto base spec is already published for a while, maybe:
OLD
"IETF is currently standardizing the ALTO protocol which aims at
   providing guidance to overlay applications…“ NEW "The ALTO protocol provides guidance to overlay applications…“

4) Maybe:
OLD
“...for example by deferring backup to night
   during traffic trough.“
NEW
"for example by deferring backups or other background traffic to off-peak hours.“

5) To be inline with previously used wording, maybe OLD „...we expect to further
   gain on storage and on the wire data exchange…“ NEW "we expect to further save network and storage resources…“

6) sec 2.2 "The protocol extension placeholders for an ALTO Calendar are: the
   IRD, the ALTO requests and responses for Cost calendars.“ Not sure I fully understand the word „placeholder“ here, maybe:
„To realize an ALTO Calendar, this document extends the
   IRD, the ALTO requests and responses for Cost calendars.“ ?

Also further
"Extensions are designed to be light and ensure backwards
   compatibility with base protocol ALTO Clients and with other
   extensions.  It uses section 8.3.7...“ What is „it“ here?
Maybe:
„This extension is designed to be light and ensure backwards
   compatibility with base protocol ALTO Clients and with other
   extensions. As recommended, it relies on section 8.3.7…“ ?

7) Sec 4.1.1:
"A Calendar-aware ALTO client supporting single cost type values, as
   specified in RFC7285, MUST provide an array of 1 element:

                          "calendared" : [true];“ This could be stated more clearly e.g.
"A Calendar-aware ALTO client only supporting single cost type values, as
   specified in RFC7285, that aims to request a Calendar MUST provide 
   an array of 1 element:

                          "calendared" : [true];“

8) 4.2.2
"If the value of member "calendared" is equal to 'false' for a given
   requested Cost Type, the ALTO Server must return, for these Cost
   Types, a single cost value as specified in RFC 7285.“ Probably use normative MUST here instead.

9) Probably RFC5246 does not need to be a normative reference for this doc (as it is already normative for RFC7285).