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