Hi Yoshifumi,
Thank you for your review. Responses to your comments are inline below.
Ben
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.
Section 2 includes examples showing limit value with their corresponding
bound metrics. Do you feel that we need something beyond that?
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?
This is resolved in revision 07. Language was added to section 1.3.
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?
This is resolved in revision 07.
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?
In the case where the latency value reported in the advertisement is
separate from the reported metrics (due to an external Telemetry source
rather than the in-band 'current' property), an absolute timestamp would
not correspond to the specific metrics returned as the two operations
are asynchronous.
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?
This is resolved in revision 07.
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.
This is resolved in revision 07. This has been changed to 'MUST'.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
