Skip to main content

Last Call Review of draft-ietf-cdni-capacity-insights-extensions-06

Request Review of draft-ietf-cdni-capacity-insights-extensions
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2024-06-17
Requested 2024-06-03
Authors Andrew Ryan , Ben Rosenblum , Nir Baruch Sopher
I-D last updated 2024-06-15
Completed reviews Tsvart Last Call review of -06 by Yoshifumi Nishida (diff)
Secdir Last Call review of -06 by Wes Hardaker (diff)
Artart Last Call review of -06 by Carsten Bormann (diff)
Genart Last Call review of -06 by Peter E. Yee (diff)
Assignment Reviewer Yoshifumi Nishida
State Completed
Request Last Call review on draft-ietf-cdni-capacity-insights-extensions by Transport Area Review Team Assigned
Posted at
Reviewed revision 06 (document currently at 07)
Result Almost ready
Completed 2024-06-15
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 if you reply to or forward this review.

   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)
    ->  '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.