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

[ALFONSO DE SILONIZ SANDINO <[e-mail]>]

Good morning,

As coauthor of the draft. We are gathering different reviews to prepare a
new version addressing the different issues raised. I think a new version
could be upload in a couple of days.

Thank your for the patience.

Regards,

Alfonso Silóniz


El sáb, 25 abr 2026 a las 11:24, <[e-mail]> escribió:

> 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.
>
>