One small correction: I'm jumping the gun on the author policy; 6 is probably OK for now.
On Mon, Mar 29, 2021 at 11:33 AM Martin Duke <[email protected]> wrote: > 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
