Reviewer: Yoshifumi Nishida
Review result: Almost Ready
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.
When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@xxxxxxxx if you reply to or forward this review.
Summary:
This document is almost ready for publication, but as a standard track
document, I have the following comments on this draft.
1: "Having a limit and a corresponding telemetry source creates an unambiguous
definition understood by both parties."
-> It might be good to show a simple example here to solve unambiguous
definitions with the proposed usage.
2: "Limits that are communicated from the dCDN to the uCDN should be considered
valid based on the TTL (Time To Live) provided by a mechanism of the underlying
transport, e.g., an HTTP Cache-Control header."
-> Is this a requirement for the underlying transport protocols? What will
happen if the protocols don't provide such features?
3: "Lack of a data-percentile will mean that the data is the average over the
time representation."
-> Don't we need "SHOULD" or "MUST" here rather than 'will'? Or, do we
allow other interpretations here?
4: "Property: latency"
-> Just out of curiosity, I am wondering why this is property is relative
value from realtime.
Using absolute timestamp might be easier to handle especially when we
have multiple sources?
5: "The limits specified by the dCDN should be considered Not To Exceed (NTE)
limits."
-> 'SHOULD' might be better or is there any reasons for this?
6: "Limits will be considered using a logical "AND": a uCDN will need to ensure
that all limits are considered rather than choosing only the most specific."
-> I think 'SHOULD' or 'MUST" will be preferable here to avoid ambiguity.
Thanks,
--
Yoshi
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
