I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-cdni-edge-control-metadata-11 Reviewer: Elwyn Davies Review Date: 2026-03-30 IETF LC End Date: 2026-03-29 IESG Telechat date: Not scheduled for a telechat Summary: Ready with issues. There are a couple of minor issues together with quite a few significant nuts. In particular the expected contents of many of the parameters are not well-exemplified. My main concern is that the Fetch specification and this document need to be absolutely clear as to whather the Origin HTTP header referred to in this document and Fetch are actually the HTTP Origin header specified in RFC 6454. The Fetch document is not totally clear and does not contain any explicit references to IETF RFC numbers- it can be read as applying semantic constraints to the Referer header. The draft doesn't make it crystal clear. Major issues: None Minor issues: s3.1, para 9 and s3.3.1: in this bullet the document refers to the Origin header which appears to be defined, at first reading, in the WHATWG Fetch document as a constrained version of the Referer (aka Referrer) header originally defined and misspelt in RFC 1945. The IETF already has an HTTP Origin header defined in RFC 6454. I am unclear whether the intention here is that Fetch uses the RFC 6454 Origin header or a semantically constrained version of a Referer header. It would help to be crystal clear about this and the wording here is not so. Referencing RFC 6454 would be helpful. s3.3.2: This section seems to have been passed over and IMO needs a complete rethink along with its use in no-origin-reponse-headers. s3.3: I think it would be appropriate and useful to include a sentence in each of the property descriptions of allow-origin, expose-headers. allow-methods and allow-headers to explain their effects in general terms on requests and responses once the link between a uCDN and the corresponding dCDN has been set up with a preflight request and response. The effect can be deduced from the examples but is not explicitly described. For example allow-methods constrains the allowed HTTP methods (GET, PUT, POST etc) the uCDN can send to the dCDN. Nits/editorial comments: s1: Best to expand CDN here as well. s1: GenericMetadata is defined in Section 4.1.7 of RFC 8006 and should be referenced here as this is a fundamental definition for this document. It would probably also be helpful to mention RFC 7336 which introduces the CDNI Metadata Interface and provide an (informative) reference. s1: The acronym MI (Metadata Interface) should be introduced here. s3.1, para 5, 1st sentence: s/CORS/the CORS/ d3.1, para 8: the use of 'modern' is not future proof. Suggest OLD: in modern HTTP request processing NEW: in HTTP request processing at the time of writing END s3 and s3.1: Editorial practice for RFCs frowns on empty sections such as we have here for s3. This can be readily and appropriately resolved in this case by making the contents of s3.1 into s3 and renumbering the rest of the sections in s3 up by one second level section (e.g., s3.2 -> s3.1). s3.1, para 8: The terms uCDN and dCDN need to be expanded. s3.2, para 1: says: The dCDN MUST implement the following behavior as determined by the GenericMetadata object MI.CrossoriginPolicy (Section 3.3) defined in this section: Either 'following behavior' and 'defined in this section' are not both required or 'defined in this section' should be 'defined in that section' and duplicates/reinforces '(Section 3.3)'. s3.3, paras 4 and 5: s/uCDN/The uCDN/ s3.3, para 6: s/properties/properties as a parameter of MI.CrossOriginPolicy/. s3.3, property max-age: A reference to Section 3.3.3 of [Fetch] for Access-Control-Max-Age and a note that the units of the item are seconds would be helpful. s3.3, last para re preflight-only: s/injected/executed/ s3.3.2, Title: The title of the section and the name of the object being defined as given in the first sentence do not match ('Allow' missing from title - I take it from s7.1 that the title is correct and 'Allow' needs to be removed from the body text.). s3.3.2, Purpose: I am unclear what sort of values I would expect or allow in this item and there is one example to assist - is this the only name I can put here?. I am also confused as to why the name is plural but there is only one value. s4, para 4 and s5, para 2: Delete 'new'. It won't be new very soon! s5. para 2: s/wants that the dCDN manages/wants the uCDN to manage/ s7: Needs an introductory paragraph as s7 is currently empty. This could usefully say that all these items are permanent and are 'items' unless otherwise stated. The items that may contain an array of values should probably be marked as lists aor dictionaries as appropriate in the registry. s9/s10: I think I could make a very good case for the Fetch protocol spec being normative.