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
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
