I would like to thank Elwyn D. for his comprehensive GENART review.  Elwyn has good suggestions beyond the one I will make in my comments in ways to strengthen the document further.  I believe this one issue is worth calling out a second time:

* Please expand the acronym (or make positive reference to RFC8006) to explain `uCDN` and `dCDN`
> 140	   The dynamic generation of CORS headers is typical in modern HTTP
> 141	   request processing and avoids forwarding CORS headers to the uCDN,
> 142	   thereby reducing the load between dCDN and uCDN when the content to
> 143	   be delivered is already cached in the dCDN.

Thanks for the updates to address my discuss points.  And my comments too.

Thanks
chris

I support the discusses by Chris and Eric.

Thanks for the work done in this document and for addressing my previous blocking DISCUSS ballot: https://mailarchive.ietf.org/arch/msg/cdni/o4Gg3s217xP6KUGYPHI_o67Okpo/

the boilerplate template used seems outdated:

90	2.  Requirements

92	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
93	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
94	   document are to be interpreted as described in [RFC2119].

Should look something as follows:

"
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.
"

Thanks to the authors and the WG for their work on this document.

I find that Eric has already caught all the comments that I had and hence skipping the email out.

> I’ve also clarified about the ability to compress of a dCDN vs the received Accept-Encoding header, referencing to Section 5.3.4 of RFC7231

[mj] §4, allow-compress: appreciate the RFC 7231 §5.3.4 citation, but the added text talks about what "the origin server SHOULD" do — this document is about dCDN behavior, not origin-server behavior, so as written it doesn't actually constrain the dCDN. A sentence restating the RFC 7231 fallback in terms of the dCDN would close the gap. (Minor: "in in Section 5.3.4" also has a duplicated word.)

Hi Alfonso, all,

Thank you for the discussion and changes made to address the review. 

The clarifications you provided and the changes [1] made address all the points raised in my previous ballot [2]. 

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-cdni-edge-control-metadata-11&url2=draft-ietf-cdni-edge-control-metadata-13&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/cdni/aLSP6iXIuD8D9VwqA_S8Su8mSm4/

Thank you to Elwyn Davies for the GENART review.

I support the DISCUSS positions of Christopher Inacio, Mahesh Jethanandani, and Mohamed Boucadair on the how the [WHATWG-FETCH] reference is treated -- it needs to be normative and point to a specific reference.

In previous discussions on WHATWG references in documents, specific github commit messages with a date stamp were referenced.

I support the existing DISCUSSes but think this is ready to publish after those are addressed.