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

[[e-mail]]

Hi all, 

Thank you Sue for the review. 

I failed to find a follow up to this review or a signal that a new revision in under preparation.

@authors, do you a plan to address these comments or that you will be releasing a new version before next week telechat? This would help me plan my own balloting.

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : Sue Hares via Datatracker <[e-mail]>
> Envoyé : mercredi 8 avril 2026 14:56
> À : [e-mail]
> Cc : [e-mail]; draft-ietf-cdni-edge-control-
> [e-mail]; [e-mail]
> Objet : [OPS-DIR]draft-ietf-cdni-edge-control-metadata-11 ietf
> last call Opsdir review
> 
> 
> 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> datatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-
> rfc5706bis%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cc0b8
> 72fd8276428e42a108de956e4e25%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
> 0%7C0%7C639112498189035658%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk
> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI
> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=O%2BYGtOCT6e9YpWi8GmnASzwquiMa7so46
> E3qKtDAMpU%3D&reserved=0.
> 
> 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
> 
> 
> 
> _______________________________________________
> OPS-DIR mailing list -- [e-mail] To unsubscribe send an
> email to [e-mail]
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.