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

Discussion:

Mirja Kuehlewind (IETF)

2018-08-06 14:11:33 UTC

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

Randriamasy, Sabine (Nokia - FR/Paris-Saclay)

2018-08-06 14:44:06 UTC

Permalink

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:***@kuehlewind.net]
Sent: Monday, August 06, 2018 4:12 PM
To: draft-ietf-alto-cost-***@ietf.org
Cc: ***@ietf.org
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).

Randriamasy, Sabine (Nokia - FR/Paris-Saclay)

2018-08-14 17:03:50 UTC

Permalink

Hello Mirja,

Thank you so much for your thorough review and suggestions. The authors will discuss open points such as those relating with metrics and your they will be integrated in a next version.

Best regards,
Sabine and co-authors

-----Original Message-----
From: Mirja Kuehlewind (IETF) [mailto:***@kuehlewind.net]
Sent: Monday, August 06, 2018 4:12 PM
To: draft-ietf-alto-cost-***@ietf.org
Cc: ***@ietf.org
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."
[[SR]] [[SR]] OK, will do and will remove previous sentence on section 5 that is no longer applicable.

2) Please fix everywhere in the doc:
"Content-Length: TODO“
[[SR]] the value "TODO" was left on purpose, in case we would be asked to change the names of the metrics. The plan was to fill them up when all the example metrics will be approved by the reviewers.

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

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.
[[SR]] Would the following re-phrasing be fine?
"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 value "1 hour", the "number-of-intervals" member has value "24" and the value of member "repeated" is equal to 4. This means that the calendar values are the same on Monday, Tuesday, Wednesday and Thursday on a period of 24 hours starting at 00:00:00 GMT.
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."

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?
[[SR]] Parsing 2 separate fields would avoid ambiguities indeed, the idea with this proposed format was to spare one member to convey in the responses. We took inspiration from the encoding format of constraints by an ALTO Client in 11.3.2.3 of RFC 7285 that follows a similar pattern, e.g. "le 15". Would it help if we rephrase the format specification of the "time-interval-size“ value in section 3.1 to avoid parsing errors ?

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)?
[[SR]] We propose to revise the related parts in section 3.3 as follows:
- only reference [draft-ietf-alto-performance-metrics] in section 2.2.1 that explains how Calendars support all kinds of metrics and modes and remove it from section 3.3,
- keep the "routingcost" metric,
- define example illustrative costs and metrics in section 3.3, that have names such as "num-owdelay", "num-throughput", "string-service-status". If we are asked to replace them by cost types with nonsensical metric names such as "shoesize" or "cattle-head-count", we will do so.

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
[[SR]] Thanks a lot for your guidance and suggestions
Sabine

————————————————
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.“
[[SR]] OK will do

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…?
[[SR]] OK will do

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…“
[[SR]] OK will do

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.“
[[SR]] OK will do

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…“
[[SR]] OK will do

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.“ ?
[[SR]] OK will do

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…“ ?
[[SR]] OK will do

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];“
[[SR]] OK will do

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.
[[SR]] OK will do

9) Probably RFC5246 does not need to be a normative reference for this doc (as it is already normative for RFC7285).
[[SR]] OK, will move it to Informative

Mirja Kühlewind

2018-08-15 08:34:25 UTC

Permalink

Hi Sabine,

please see inline.

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
Hello Mirja,
Thank you so much for your thorough review and suggestions. The authors will discuss open points such as those relating with metrics and your they will be integrated in a next version.
Best regards,
Sabine and co-authors
-----Original Message-----
Sent: Monday, August 06, 2018 4:12 PM
Subject: AD review of draft-ietf-alto-cost-calendar-07
Hi all,
„IANA considerations and security considerations will be completed in
further versions."
[[SR]] [[SR]] OK, will do and will remove previous sentence on section 5 that is no longer applicable.
"Content-Length: TODO“
[[SR]] the value "TODO" was left on purpose, in case we would be asked to change the names of the metrics. The plan was to fill them up when all the example metrics will be approved by the reviewers.

Which reviewers? I think the should be filled before we go to IETF last
call, so please do it now.

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
3) Also please make all occurrences of RFC7285 an actually reference ("[RFC7285]" instead of only „RFC7285“).
[[SR]] OK, will do
"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.
[[SR]] Would the following re-phrasing be fine?
"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 value "1 hour", the "number-of-intervals" member has value "24" and the value of member "repeated" is equal to 4. This means that the calendar values are the same on Monday, Tuesday, Wednesday and Thursday on a period of 24 hours starting at 00:00:00 GMT.
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."

Yes, please.

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
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?
[[SR]] Parsing 2 separate fields would avoid ambiguities indeed, the idea with this proposed format was to spare one member to convey in the responses. We took inspiration from the encoding format of constraints by an ALTO Client in 11.3.2.3 of RFC 7285 that follows a similar pattern, e.g. "le 15". Would it help if we rephrase the format specification of the "time-interval-size“ value in section 3.1 to avoid parsing errors ?

I think the approach is fine. I was just wondering why it was chosen.

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
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)?
- only reference [draft-ietf-alto-performance-metrics] in section 2.2.1 that explains how Calendars support all kinds of metrics and modes and remove it from section 3.3,
- keep the "routingcost" metric,
- define example illustrative costs and metrics in section 3.3, that have names such as "num-owdelay", "num-throughput", "string-service-status". If we are asked to replace them by cost types with nonsensical metric names such as "shoesize" or "cattle-head-count", we will do so.

Yes, please define the metric accordingly. I'm okay to have metric that
actually make some sense. Just make sure that these metric are
understood as example metrics only and should not be used. Or would it
make more sense to "just" use some metrics from
[draft-ietf-alto-performance-metrics]?

Mirja

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
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
[[SR]] Thanks a lot for your guidance and suggestions
Sabine
————————————————
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.“
[[SR]] OK will do
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…?
[[SR]] OK will do
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…“
[[SR]] OK will do
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.“
[[SR]] OK will do
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…“
[[SR]] OK will do
6) sec 2.2 "The protocol extension placeholders for an ALTO Calendar are: the
„To realize an ALTO Calendar, this document extends the
IRD, the ALTO requests and responses for Cost calendars.“ ?
[[SR]] OK will do
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?
„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…“ ?
[[SR]] OK will do
"A Calendar-aware ALTO client supporting single cost type values, as
"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
"calendared" : [true];“
[[SR]] OK will do
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.
[[SR]] OK will do
9) Probably RFC5246 does not need to be a normative reference for this doc (as it is already normative for RFC7285).
[[SR]] OK, will move it to Informative

Randriamasy, Sabine (Nokia - FR/Paris-Saclay)

2018-09-21 17:46:54 UTC

Permalink

Hello Mirja,

draft-ietf-alto-cost-calendar-08.txt has just been uploaded and updated according to the conclusions in your e-mail of August 15th below. All comments have been addressed and your feedback would be welcome on some of the updates listed below.

Besides, the "dependent-vtags" fields were completed in example of section 4.1.3 and member "default-alto-network-map" was added in the example IRD capabilities.

For the Content-Length values, some text was added on the example number of characters used to encode metric values.

Thanks a lot and best regards,
Sabine

-------------------------- highlight on updates ---------------------------

----- First set of comments: last one on the cost type names:

As section 2.2.1 is about cost modes only, reference on [draft-ietf-alto-performance-metrics] has not been added and remains in section 3.3 (example IRD) instead. One sentence has been clarified as follows:

OLD: Actually, Calendars can also represent metrics in other modes
and having considered as time-varying values.
NEW: Actually, Calendars can also represent metrics in other modes
considered as compatible with time-varying values.

Section 3.3 has been updated as follows:

The 4 utilised cost types are listed: "num-routingcost", "num-owdelay", "num-throughputrating", "string-servicestatus", with a mention that:

- "routingcost" in the numerical mode is a must have according to RFC 7285,
- the 3 other ones are ficitious and one of them relates to a performance metric currently being defined in [draft-ietf-alto-performance-metrics].

These cost types and metric names have been updated accordingly in the examples of rest of the draft.

----- other editorial comments: 1) "The abstract is quite long... ":
The abstract has been shortened and a bit of the 2nd paragraph of the previous version has been left.

-----Original Message-----
From: Mirja Kühlewind <***@kuehlewind.net>
Sent: Wednesday, August 15, 2018 10:34 AM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <***@nokia-bell-labs.com>; draft-ietf-alto-cost-***@ietf.org
Cc: ***@ietf.org
Subject: Re: AD review of draft-ietf-alto-cost-calendar-07

Hi Sabine,

please see inline.

Which reviewers? I think the should be filled before we go to IETF last call, so please do it now.

Yes, please.

I think the approach is fine. I was just wondering why it was chosen.