[alto] AD review of draft-ietf-alto-performance-metrics-15

[Martin Duke <[e-mail]>]

Hello authors,

Thank you very much for writing this draft. It is clearly a useful
extension to ALTO and is quite clearly written, even to someone who is not
a practitioner. I have numerous comments/questions and a few nits.

These points are all invitations to discussion, rather than commands about
what to change, as I've missed much of the WG deliberations that led to
this text.

COMMENTS:
- There are six authors. Having more than 5 editors/authors listed on the
front page requires strong justification and chair/AD approval. See the RFC
Editor statement [1]. You are encouraged to designate a few editors for the
front page and list as many authors as desired at the end.

- Sec 2.1. The cost-source model is conceptually sound, but the
justification for it seems underexplained. What exactly is a client going
to do with this information? What different behaviors would a client
execute if the context was e.g. "sla" instead of "nominal?" To the extent
the parameters are not machine readable, like links to webpages, are we
really expecting this information to be presented to the humans behind ALTO
clients?

- Sec 2.1 I am confused about the meaning of the "sla" cost-source. Does
this refer to an SLA the ALTO client has with the network? Between the
target IP and the network? Or something else? If the first, does this link
to client authentication in some way? If the second, what are the privacy
implications of exposing these SLAs?

- Sec 2.1. Related to the above, the text suggests that any cost-source
expressed as "import" could also be expressed as "estimation". Why would
the server do this? The text should say, or perhaps it would be
conceptually cleaner if "estimation" and "import" were mutually exclusive
sources by definition.

- Sec 3. I would prefer it if the parameters field in each of these
definitions was a bit more strict. This relates to my confusion about
machine-readable vs. human readable data; if this is meant to be
machine-readable, then e.g. Sec 3.4.4 should be more specific in spelling
out that the IGP protocols should be in a format with the RFC number, for
instance. If it's to be human readable for a purpose I don't understand,
then these looser definitions are probably OK.

- Sec 3.4 Unlike the other metrics, I have no idea what a client is to do
with the hop count metric, since clients don't care about hop count. Hops
only affect users through delay and loss rate, which is present in other
metrics. Is the intent here to provide a proxy for delay when direct delay
information is not available? If so, we should say so.

- Sec 5.3. I suggest a reword.

OLD:
To address this issue, the only defined "routingcost" metric can be
   only "estimation".

NEW:
To address this issue, if the "routingcost" metric contains a cost-context
field, it MUST be "estimation."

What should clients do if it's not "estimation?" Can they use it or reject
the metric
as malformed?

- Sec 5.4.1: "...the ALTO server may provide the client with the validity
period of the exposed metric values."

Shouldn't there be a standard format for this? Or are you implying the use
of cost-calendar?

- Sec 5.4.2: I don't understand what this section is saying. Can the server
provide new metrics not in the spec? Or is it saying that the server can
take singletons about link one-way delays and compose path one-way and
two-way delays, for example?

NITS:
- Sec 1. An initial sentence introducing ALTO at the beginning would be
helpful, e.g.

"ALTO [RFC 7285] provides a means for client to identify the most efficient
information source when multiple copies of such information exist, by
quering path information from an HTTP server."

- Sec 2. The second paragraph is a little hard to read. Suggestion:

OLD:

On the other hand, to be able to use coarse-grained information such
   as routing system information (e.g., [RFC8571
<https://datatracker.ietf.org/doc/html/rfc8571>]), which may not
   provide fine-grained information such as (iii) Method of Measurement
   or Calculation and (vi) Measurement Timing, this document provides
   context information to indicate the source of information and hence
   available metric details.

NEW:

  This document specifies context information to indicate the metric
source, which can allow clients to obtain fine-grained information like
(ii) Method of Measurement or Calculation and (vi) Measurement Timing."

- Sec 2.1 In Fig. 1, please expand "NBI" on first use.

- Sec 3.1.3 Expand "PID" on first use.

- Sec 3.1.4 s/recommended/RECOMMENDED

- Sec 3.4 s/metric hopcount/hopcount metric

- Sec 4.1.3 would this be correct: s/give the throughput/give the maximum
throughput

- Sec 6. s/is a highly sensitive/is highly sensitive

Thanks
Martin

[1] https://www.rfc-editor.org/pipermail/rfc-interest/2015-May/008869.html