Return-Path: X-Original-To: ops-dir@mail2.ietf.org Delivered-To: ops-dir@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 1E7FBE3BF964 for ; Mon, 27 Apr 2026 00:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1777274798; bh=fe4bOLuUIK0OZH+1n1J2FyiDRTmWEDENmEmnr3tgpY4=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=JYgzTuWxcwpf+POKgM3g6yVVMx9TAf5O2WSTdgV60wK103R2k3APacXKUJmmAZjsd 3Gp7J/HUGaE4dzK+Ri9S9h91JpNvn6NkprySTSo+Q6muqhuysztLlP1MbkGHGs70/z reClovuuzu7r/24YBj/fBfXuvaJB6fl4gUNbBLlE= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAwFYJZyw6Bo for ; Mon, 27 Apr 2026 00:26:37 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 1F191E3BF952 for ; Mon, 27 Apr 2026 00:26:37 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-6634bb959a2so13269144a12.1 for ; Mon, 27 Apr 2026 00:26:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1777274790; cv=none; d=google.com; s=arc-20240605; b=bBpFeGOmhQNamfJtt/F1GJ36ezVW7q5ulKB/mnIgjy7korOdsXxH2QIaKqPnQEBwob PMdLZAneBC562vo9vo/eD30Zrl6T5LDQrZRkcdS1L5+7yfEGPLcEmQvjJSH2GYZKBwHO 8qqmKKZYE5zsJ06BVPRrjkVAbBksIbC5ATZBHl+HrElUdwBaBGcwTv/ploVAjWK6CSbj tJN5JWRcUqnMW9eEIUZwesCMbnEeVtBWFlvIvr0v0fOgtCzYLDqgUK7WobWwPyR2olgy Yuj6MJcXzsLjnML/mdza1xUIYR+cDU8TU/DbpEqsYFoyxvs6A5yH6Ku0z8vTh4zku2kR Uktw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=d9Y095yLoKl2mCa36zWZCKtiZmhfErDkT6DmAd2AVqc=; fh=iKE8sIKNZeLed81EQtId+xFpkWVXe1rR03zAX9O6sQ4=; b=BYF7Jx0FfjN5Xr5/9mYGxF+Z/b4hB6GrYJvww/t0lHUld/3rgG+kNkdUWQ8gmGXSjw GTiO4f0vvzJdtCAHbvPfan4UgEgZEMVeRBbcSV3YGRaFfbmlIe0CQa4zDzDz0XcNQnzQ o1RWsCyfh+yqXi/TYoDiELwrtJV9T7eMAvOMis+zKZ0FkMOwttQufFSIGDZAdhKaO60R wJxCIwueRYTQwInkVXb/lT6GtG2BKkzTc7GFDTNb8nhKVkrrSBgoalSySppfEN6s37kW ArIAhm+CC2or5qnItrcU2wpbqC11VGBSnU4rAq5VkRGlSzRcraHR6bUuy4h4U0AeuiGS vezg==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777274790; x=1777879590; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=d9Y095yLoKl2mCa36zWZCKtiZmhfErDkT6DmAd2AVqc=; b=P8goKB+xY3bR+ARTllFLF5P8H7di9vS2OwaohfbKVLpBqQkH1nC88z4PH3lHZNegkS Q4Yr8/nXz3lanFQsYeaLhgBNGbZ1aFCEX1gwryt7W6uHj6SnfG/mwrSRae8I9bFbEf5Z uzMHPBZ3ZRWvagkPajGqPPXBuEx+YMRqLJ4TsoUhgCTkWVppW637tRbGwWt6IseqRcQ/ +/VMXVBPkbpVGGxZ7513dscWqZZAtEhaY9uHwY/RwLZfZZtN4m+sih0dPxZd/kuJOaDo vThuS1V0LxcVaVj+AH13FRX7O/iAO24USqE64049MAD98Rh03qdbzewXIM0lg8UG+6LP X+tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777274790; x=1777879590; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=d9Y095yLoKl2mCa36zWZCKtiZmhfErDkT6DmAd2AVqc=; b=FLUxSeeXj+ijkSGGFonw0ybRsjuWs5ARhvnlgOm80h7LF/VtiVy0XQVqjcEBKWsj5m MJ+Q0EyeCMw8ePd1luLgV7RUZvVFcce0KCN3vEzbW6EhbzEdO783u+njC8sex5f7AnWz rdn43ta7L6zZIf/7hEfXRYtjT+EyPOfj97a+aDRp3TP9yAdZbWzrCQw5gRzSPnur/9oA 3tzHTt4r44WoOuUWg6svbXJjpID/DRrhzc4PvqrTemAxl/dXJ6xFBn86SBLdlttS+rZD x8eOK7o8D31q8Jk5YcrSaP9a1++EjLL2Ey2LVf+MLjmXgcEWdTRf4b0m7BV7xGNP4T6k upxQ== X-Forwarded-Encrypted: i=1; AFNElJ/hrIh2SVELTy0Uz1rYBVwTlATFNjYtRzw65XBhUKR6nxnN/sGvaC7DahoB6sU98QtFfTsxfZQD@ietf.org X-Gm-Message-State: AOJu0YykKX7ZsHRcF6QszAYCQZ2TyK0OhIVqKVTMT/5QAkbIeBbYAAuR F0lzAFngAmi7HS1+1PUd7MCznsMphQEPFo1M8/rLW5GpGKwznQ4SMkakDTGyMUMgI1xAxt+N3Qo fFWbyBoUgce8sjB0V2x1u6QgEMnyfZJy/KUYF X-Gm-Gg: AeBDietjX4jX/9PSHDc2NTQxDEpupKkGSmeKTC3hTVc3+IcbtZ0akSY3DtgXPiTQuic 2H/g7fDWhKwHvWuTqkG4xY5pjUniZCRlqsJ8wQJBRW9rlEkworHKM8FJSywXPWcHgoBoarhFNst 0Jr3o0dCyvSdmeO/oCKDlwuQq5yBWvaCaNqbmr1NTqUFJNK3AtYtaACMqS8fARF9XyStEik2/tb /a3iTShM2UHFQK8qt+Ke/c4vVpWuw5rXpJyyUB/+ntgk35iji4SEyQzHvd4zH3pEDPN+45IdtmE 4AsylHXQ6zEmtHpOp7DrNHnPl8syr3L2kg== X-Received: by 2002:a05:6402:28c4:b0:670:8b30:a897 with SMTP id 4fb4d7f45d1cf-672bfd82110mr17207151a12.1.1777274789562; Mon, 27 Apr 2026 00:26:29 -0700 (PDT) MIME-Version: 1.0 References: <177565294119.1261234.6193520329790611169@dt-datatracker-9dc8fdd9f-qcdj9> In-Reply-To: From: ALFONSO DE SILONIZ SANDINO Date: Mon, 27 Apr 2026 09:26:18 +0200 X-Gm-Features: AVHnY4IcfaSL8LdTCWRPc-PVkG49OHTKTCXPyEXiQoVJHQzFF9jJ2MLrN0GGdsk Message-ID: To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary="000000000000800c3b06506c08a0" Message-ID-Hash: APOCBJ7TQKOKQ2FCL3WFZD5OQJSMPFB4 X-Message-ID-Hash: APOCBJ7TQKOKQ2FCL3WFZD5OQJSMPFB4 X-MailFrom: alfonsosiloniz@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ops-dir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "ops-dir@ietf.org" , "draft-ietf-cdni-edge-control-metadata.all@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BOPS-DIR=5DRe=3A_draft-ietf-cdni-edge-control-metadata-11_ietf_l?= =?utf-8?q?ast_call_Opsdir_review?= List-Id: Ops Directorate Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000800c3b06506c08a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=C3=B3niz El s=C3=A1b, 25 abr 2026 a las 11:24, escrib= i=C3=B3: > 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 pla= n > my own balloting. > > Thank you. > > Cheers, > Med > > > -----Message d'origine----- > > De : Sue Hares via Datatracker > > Envoy=C3=A9 : mercredi 8 avril 2026 14:56 > > =C3=80 : ops-dir@ietf.org > > Cc : cdni@ietf.org; draft-ietf-cdni-edge-control- > > metadata.all@ietf.org; last-call@ietf.org > > 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=3Dhttps%3A%2F%2F > > datatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg- > > rfc5706bis%2F&data=3D05%7C02%7Cmohamed.boucadair%40orange.com%7Cc0b8 > > 72fd8276428e42a108de956e4e25%7C90c7a20af34b40bfbc48b9253b6f5d20%7C > > 0%7C0%7C639112498189035658%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk > > iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI > > joyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DO%2BYGtOCT6e9YpWi8GmnASzwquiMa7so46 > > E3qKtDAMpU%3D&reserved=3D0. > > > > 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 -- ops-dir@ietf.org To unsubscribe send an > > email to ops-dir-leave@ietf.org > > _________________________________________________________________________= ___________________________________ > 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 o= u > 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 bee= n > modified, changed or falsified. > Thank you. > > --000000000000800c3b06506c08a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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.
<= br>
Regards,

Alfonso Sil=C3=B3niz
<= div>

El s=C3=A1b, 25 abr 2026 a las 11:24, &= lt;mohamed.boucadair@orange= .com> escribi=C3=B3:
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 relea= sing a new version before next week telechat? This would help me plan my ow= n balloting.

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De=C2=A0: Sue Hares via Datatracker <noreply@ietf.org>
> Envoy=C3=A9=C2=A0: mercredi 8 avril 2026 14:56
> =C3=80=C2=A0: op= s-dir@ietf.org
> Cc=C2=A0: cdni@ietf= .org; draft-ietf-cdni-edge-control-
> metadata.al= l@ietf.org; las= t-call@ietf.org
> Objet=C2=A0: [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.pro= tection.outlook.com/?url=3Dhttps%3A%2F%2F
> datatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-
> rfc5706bis%2F&data=3D05%7C02%7Cmohamed.boucadair%40orange.com%7Cc0b8=
> 72fd8276428e42a108de956e4e25%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
> 0%7C0%7C639112498189035658%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk
> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI
> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DO%2BYGtOCT6e9YpWi8GmnASzwquiMa7so= 46
> E3qKtDAMpU%3D&reserved=3D0.
>
> 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.=C2=A0 This ma= y
> 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.=C2=A0 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)=C2=A0 section 3.2
> old text:/
>
>=C2=A0 =C2=A0 *=C2=A0 Validation of the Origin request header - If
> MI.CrossoriginPolicy
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(Section 3.3) defines a list of domains to v= alidate, if the
> Origin
>=C2=A0 =C2=A0 =C2=A0 =C2=A0request header does not match, the CORS resp= onse headers
> MUST NOT
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be included in the dCDN response.=C2=A0 UA c= ompliance with
> Section 3.3
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of [WHATWG-FETCH] with "same-origin&quo= t; restrictions will
> prevent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0access to the resource./
> issue: it seems that "to validate and if the Origin" is the = right
> meaning.=C2=A0 Is it?
>
> old text:/
>=C2=A0 =C2=A0 *=C2=A0 Wildcard usage - If the Origin request header is = valid,
> depending
>=C2=A0 =C2=A0 =C2=A0 =C2=A0on the configuration, the value of the CORS = response header
> to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0include in the response will be the same as = the Origin
> request
>=C2=A0 =C2=A0 =C2=A0 =C2=A0header, or a wildcard./
> issue: It would seems that "the configuration the value" is = the
> correct grammar.
>
> old text:/
>=C2=A0 =C2=A0 *=C2=A0 uCDN is able to configure a list of default value= s for CORS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0response headers in MI.CrossoriginPolicy (Se= ction 3.3)
> Generic
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Metadata object that dCDN MUST add if presen= t independent of
> the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0value of the Origin request header./
>
> issues: It would seem that "that dCDN MUST" should be "= That the
> dCDN MUST".
>
> old text:/
>=C2=A0 =C2=A0 When an uCDN configures one or more of the expose-headers= ,
> allow-
>=C2=A0 =C2=A0 methods, allow-headers, allow-credentials and max-age
> properties the
>=C2=A0 =C2=A0 dCDN MUST generate synthetic responses to any CORS prefli= ght
> request
>=C2=A0 =C2=A0 without contacting the uCDN servers.=C2=A0 In this case t= he dCDN
> will add
>=C2=A0 =C2=A0 the corresponding CORS response headers to every non-empt= y
> parameter./ New text (suggested:/
>=C2=A0 =C2=A0 When an uCDN configures one or more of the following: exp= ose-
> headers, allow-
>=C2=A0 =C2=A0 methods, allow-headers, allow-credentials and max-age
> properties the
>=C2=A0 =C2=A0 dCDN MUST generate synthetic responses to any CORS prefli= ght
> request
>=C2=A0 =C2=A0 without contacting the uCDN servers.=C2=A0 In this case t= he dCDN
> will add
>=C2=A0 =C2=A0 the corresponding CORS response headers to every non-empt= y
> parameter./
>
> E-issue-3:=C2=A0 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=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | RFC 5706 Considerations
> |-------------------------------
> |-----------------------------------------------------------------
> --------------------------------------
> | Deployment=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| Does the document include a
> description of
> how this protocol or technology is going to be deployed and
> managed?=C2=A0 No | Installation and Initial Setup | Are configuration=
> parameters clearly identified and do they have reasonable default
> values?=C2=A0 Yes, section 3.1-3.3 |
> Migration Path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| 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?=C2=A0 =C2=A0T= he
> 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=C2=A0 =C2=A0 | Will the new protocol significantly > increase traffic
> load on existing networks or affect the control plane?=C2=A0 No |
> Verifying Correct
> Operation=C2=A0 =C2=A0 | For example, how can one test end-to-end
> connectivity and
> throughput?=C2=A0 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 -- ops-dir@ietf.org To unsubscribe send an
> email to o= ps-dir-leave@ietf.org
___________________________________________________________________________= _________________________________
Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 message= s 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 inf= ormation 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 dele= te 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.

--000000000000800c3b06506c08a0--