Last Call Review of draft-ietf-cdni-request-routing-extensions-05

Request Review of draft-ietf-cdni-request-routing-extensions
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2019-08-28
Requested 2019-08-14
Authors Ori Finkelman, Sanjay Mishra
Draft last updated 2019-08-20
Completed reviews Secdir Last Call review of -05 by Linda Dunbar (diff)
Genart Last Call review of -05 by Dan Romascanu (diff)
Tsvart Last Call review of -05 by Michael Tüxen (diff)
Opsdir Last Call review of -05 by Zitao Wang (diff)
Opsdir Last Call review of -07 by Zitao Wang (diff)
Assignment Reviewer Zitao Wang
State Completed
Review review-ietf-cdni-request-routing-extensions-05-opsdir-lc-wang-2019-08-20
Posted at
Reviewed rev. 05 (document currently at 08)
Review result Has Issues
Review completed: 2019-08-20


I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

The Open Caching working group of the Streaming Video Alliance is focused on the delegation of video delivery requests from commercial CDNs to a caching layer at the ISP.  In that aspect, Open Caching is a specific use case of CDNI, where the commercial CDN is the upstream CDN (uCDN) and the ISP caching layer is the downstream CDN (dCDN). The extensions specified in this document to the CDNI Metadata and FCI interfaces are derived from requirements raised by Open Caching but are applicable to CDNI use cases in general.

The document is well written, easy to read, and technically I have no issues. However, as shown below, I do have some questions for clarifications.

Major issues: None

Minor issues:
#1: There are a lot of abbreviations that are not provided with explanations or citations, such as uCDN, dCDN, CFI, etc.

#2: The example of of a Redirect Target capability object serialization, is it encoded as json? Please present its encoding format.

#3: In section 2.1, the "Mandatory-to-Specify" attributes of dns-target and http-target, it describes that "No, but at least one of dns-target or http-target MUST be present and non-empty." 
I wonder whether there should be a detection mechanism. For example, if the requirements are not met, an error message will be returned. And if there are existing mechanisms, please briefly introduce them. 

Best Regards!