Section 2, paragraph 0
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].

This section cites only RFC 2119 for the BCP 14 keywords boilerplate. 
Per current IETF practice, RFC 8174 must also be cited. The standard 
boilerplate reads: "...described in BCP 14 [RFC2119] [RFC8174] when, 
and only when, they appear in all capitals..."

Section 3, paragraph 0
> 3.  MI.CrossoriginPolicy

The document references the Origin HTTP request header extensively 
in this section but never cites RFC 6454 ("The Web Origin Concept"), 
which is the IETF-standards-track definition of the Origin header. 
Regardless of how the WHATWG-FETCH dependency is resolved, RFC 6454 
should be cited when the Origin header is introduced. The GENART 
reviewer (Elwyn Davies, thanks, Elwyn) made this recommendation.

Section 4, paragraph 5
>    *  Description: If set to "true", the dCDN SHOULD try to compress the
>       response to the client based on the Accept-Encoding request header
>       and its available capabilities.  In case is not able to do the
>       compression, the content will be delivered uncompressed.

The normative SHOULD implies that a dCDN may choose not to compress even when 
instructed. But the fallback text says compression failure still delivers 
the content. This creates an ambiguity: is the SHOULD a soft recommendation 
that a dCDN can always ignore (rendering the flag meaningless), or does 
it mean "try compression, but failure is permissible"? If the intent is the 
latter, the language should be "the dCDN MUST attempt to compress the 
response... and MUST deliver the content uncompressed if compression is 
not possible." The grammar error (s/In case is not able/In case it is not able) 
should also be corrected.

Section 5, paragraph 0
>    Configuration metadata is required to define how connections to a
>    client are maintained by a dCDN.  In some use cases, like video
>    streaming or other critical object delivery, UA applications'
>    connection to the cache server must be managed to ensure the best
>    possible user experience.  This metadata allows a uCDN to accommodate
>    device-specific constraints and performance optimization.  A dCDN can
>    also benefit from this configuration metadata to meet its security
>    and resource consumption requirements.

The section's description says it is about "how connections to a client 
are maintained, and mentions "connection setup" in Section 5.1 
example caption, yet the only property defined is a keep-alive timeout. 
If the scope was intentionally limited to just this one property, 
a brief note explaining what was out of scope would prevent implementers 
from assuming other connection parameters (e.g., initial connection 
timeout, maximum connections) are implicitly configurable.

# Extensions: Need and Integration in the CDNI System

I hesitated to list this as as DISCUSS because I do think this is important to assess the technical contribution and help understanding how the extensions can be integrated in an existing CDNI system.

There current introduction and section 3 are short in explaining how the new extension graft to existing CNDI component. Also, an explanation about the reasoning behind the set of required capabilities and how these capabilities are mapped to individual objects would strengthen the specification.

# Maybe cite rfc6454 in the following

CURRENT:
   While this transition is necessary for delivery, many User
   Agents apply strict 'same-origin' security restrictions to these
   network requests, which can block the content unless specific access
   rules are defined.


# More than two situations can occur: e.g., target resource may not exist at the first place

I suggest: 

OLD:
   Two situations can occur when
   one or more CDNs are involved in processing these requests:

NEW:
   At least, two situations can occur when
   one or more CDNs are involved in processing these requests:


# out of context

CURRENT:
   The dynamic generation of CORS headers is typical in modern HTTP
   request processing and avoids forwarding CORS headers to the uCDN,
   thereby reducing the load between dCDN and uCDN when the content to
   be delivered is already cached in the dCDN.

uCDN and dCDN are mentioned here while I don’t think it is true to say that there is always more than one CDN involved in the processing. The assumptions should be stated clearly.

Also, these are introduced while CDNI arch is not introduced first. 

# Inadequate use of normative language: s/MUST/must

CURRENT:
   The CDN Interconnection (CDNI) metadata model requires extensions to
   permit a uCDN to declare how a dCDN MUST evaluate and dynamically
   generate the necessary CORS response headers, avoiding the forwarding
   of CORS requests and/or preflight requests to the uCDN.

# (Lack of) Clarity again

CURRENT:
   Required capabilities:

Capabilities of which entities? Which system components?

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/ops-dir/oKvfnrMJAU6Bn49ufTLmPa7Yj6g/