[OPS-DIR]draft-ietf-cdni-edge-control-metadata-11 ietf last call Opsdir review

[Sue Hares via Datatracker <[e-mail]>]

Document: draft-ietf-cdni-edge-control-metadata
Title: CDNI Edge Control Metadata
Reviewer: Sue Hares
Review result: Has Nits

Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this
Internet-Draft.

The Operational Directorate reviews all operational and management-related
Internet-Drafts to ensure alignment with operational best practices and that
adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in
IETF Specifications"_ can be found at
https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.

While these comments are primarily for the Operations and Management Area
Directors (Ops ADs), the authors should consider them alongside other feedback
received.

- Document: draft-ietf-cdni-edge-control-metadat-11
- Reviewer: Susan Hares
- Review Date: 4/8/2026
- Intended Status: Proposed Standard
## Summary
Choose one: Has 3 Issues, No Major issues (AFIK)
a) No real operations considerations in content
b) The document deals with critical information for CND, but does not identify
the critical information. c) Incorrect IANA format. There are also NITS denoted
as Editorial issues.

Caveat for Review: Not an HTTP or CDNI expert.

## General Operational Comments Alignment with RFC 5706bis
1) This document lacks an indication on deployment path.  This may be in
[WHATWG-FETCH] document, but it is not mentioned. 2) This document defines a
mechanism for dCDN and uCDN but lacks operational discussion on how to track
when the dCDN configuration for MT changes.CrossoriginPolicy is broken. An
Operational Considerations section (Section X) should be expanded to address
what happens if this breaks. The operational considerations may simply state -
it is the responsibility of the dCDN to correctly configure the state. Is there
something that tracks errors?

## Security section
The information passed in the MT.CrossoriginPolicy is critical information. How
is the operator protecting these values?

## IANA section - now requires both registry and group.  Please change section
7.1 to indicate both registry and gorup.

Optional Editorial considerations:
E-issiue-1) dCDN and uCDN should be expanded before the first use.
E-issue 2)  section 3.2
old text:/

   *  Validation of the Origin request header - If MI.CrossoriginPolicy
      (Section 3.3) defines a list of domains to validate, if the Origin
      request header does not match, the CORS response headers MUST NOT
      be included in the dCDN response.  UA compliance with Section 3.3
      of [WHATWG-FETCH] with "same-origin" restrictions will prevent
      access to the resource./
issue: it seems that "to validate and if the Origin" is the right meaning.  Is
it?

old text:/
   *  Wildcard usage - If the Origin request header is valid, depending
      on the configuration, the value of the CORS response header to
      include in the response will be the same as the Origin request
      header, or a wildcard./
issue: It would seems that "the configuration the value" is the correct grammar.

old text:/
   *  uCDN is able to configure a list of default values for CORS
      response headers in MI.CrossoriginPolicy (Section 3.3) Generic
      Metadata object that dCDN MUST add if present independent of the
      value of the Origin request header./

issues: It would seem that "that dCDN MUST" should be "That the dCDN MUST".

old text:/
   When an uCDN configures one or more of the expose-headers, allow-
   methods, allow-headers, allow-credentials and max-age properties the
   dCDN MUST generate synthetic responses to any CORS preflight request
   without contacting the uCDN servers.  In this case the dCDN will add
   the corresponding CORS response headers to every non-empty parameter./
New text (suggested:/
   When an uCDN configures one or more of the following: expose-headers, allow-
   methods, allow-headers, allow-credentials and max-age properties the
   dCDN MUST generate synthetic responses to any CORS preflight request
   without contacting the uCDN servers.  In this case the dCDN will add
   the corresponding CORS response headers to every non-empty parameter./

E-issue-3:  section 3.3 - grammar.

replace /section 5.1 [RFC9011]/
with /section 5.1 of [RFC9011]

Summary of issues based on: OPS-DIR references

Explicitly evaluate compliance with operational guidelines (optional but
recommended):

For example the check list:

- Fault Management: Are failure detection/recovery mechanisms specified? No
- Configuration Management: Are configuration changes to enable/disable the
feature clearly defined? somewhat (section 3.1-3.3) - Performance Monitoring:
Are metrics (e.g., latency, resource usage) clearly identified? - This
specification is trying to reduce latency, but the specific latency issues in
the processing is not specified (AFIK).

| Review Item                    | RFC 5706 Considerations
|-------------------------------
|-------------------------------------------------------------------------------------------------------
| Deployment                     | Does the document include a description of
how this protocol or technology is going to be deployed and managed?  No |
Installation and Initial Setup | Are configuration parameters clearly
identified and do they have reasonable default values?  Yes, section 3.1-3.3 |
Migration Path                 | Is a path to migrate existing configuration
clearly articualted? Are there any backward compatibility issues? |
Requirements on Other Protocols| What other protocol operations are expected to
be performed relative to the new protocol or technology?   The informational
specification [WHATWG-FETCH] may have details on other requirements. This
documents seems to the naiive to have the necessary information. | Impact on
Network Operation    | Will the new protocol significantly increase traffic
load on existing networks or affect the control plane?  No | Verifying Correct
Operation    | For example, how can one test end-to-end connectivity and
throughput?  Not clear.

## Major Issues - none found.
## Minor Issues - I think my issues are non-block, but need to be adjust to
have correct specification. ## Nits - see editorial NITS above