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@ietf.org 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