Hi Martin, On Tue, Mar 30, 2021 at 2:24 PM Martin Duke <martin.h.d...@gmail.com> wrote:
> Sorry for the fragmented review, but there are a couple of more issues: > > - The authors should do a review of all lower-case occurrences of must, > should, may, and recommended. At least a few of them should be capitalized > to indicate normative requirements. > Yes. We are taking a pass and are almost done. > > - IMO, from a quick review, I-D.ietf-ippm-initial-registry as written is > normative and should be listed as such. However, I think it would be better > to simply refer to the actual registry ( > https://www.iana.org/assignments/performance-metrics/performance-metrics.xhtml) > rather than tie it to the initial entries. > > Agree that referring to the registry is a better design and we will do the normative reference in the update. Thanks! Richard > On Mon, Mar 29, 2021 at 5:30 PM Martin Duke <martin.h.d...@gmail.com> > wrote: > >> 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 <martin.h.d...@gmail.com> >> 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 > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
