Hi Bo, Thank you for your approval. We’ve noted it on the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9834
Best regards, Alanna Paloma RFC Production Center > On Sep 4, 2025, at 7:25 PM, Wubo (lana) > <[email protected]> wrote: > > Hi Alanna, > > Thank you for the updates. I approve the publication of this document. > > Regards, > Bo > > -----Original Message----- > From: Alanna Paloma <[email protected]> > Sent: Thursday, September 4, 2025 2:18 AM > To: mohamed.boucadair <[email protected]>; [email protected] > Cc: [email protected]; [email protected]; > [email protected]; [email protected]; Wubo > (lana) <[email protected]>; [email protected]; [email protected]; > [email protected]; [email protected] > Subject: Re: AUTH48: RFC-to-be 9834 > <draft-ietf-opsawg-teas-attachment-circuit-20> for your review > > Hi Med and Mahesh, > > Thank you for your replies. Your approvals have been noted on the AUTH48 > status page: > https://www.rfc-editor.org/auth48/rfc9834 > > And we have updated the files per Med’s additional requests. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9834.xml > https://www.rfc-editor.org/authors/rfc9834.txt > https://www.rfc-editor.org/authors/rfc9834.html > https://www.rfc-editor.org/authors/rfc9834.pdf > > The relevant diff files have been posted here: > https://www.rfc-editor.org/authors/rfc9834-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9834-auth48diff.html (AUTH48 changes) > https://www.rfc-editor.org/authors/rfc9834-auth48rfcdiff.html (AUTH48 changes > side by side) https://www.rfc-editor.org/authors/rfc9834-lastdiff.html > (htmlwdiff diff between last version and this) > https://www.rfc-editor.org/authors/rfc9834-lastrfcdiff.html (rfcdiff between > last version and this) > > Once we have received approvals from Richard, Oscar, Samier, and Bo, we will > move this document forward in the publication process. > > Thank you, > Alanna Paloma > RFC Production Center > >> On Sep 2, 2025, at 10:30 PM, [email protected] wrote: >> >> Hi Alanna, >> >> Thanks for taking care of the changes. I think there is one occurrence that >> you need to revert back in the introduction: >> >> CURRENT: >> The required >> setup is referred to in this document as an AC, while the underlying >> link is referred to as a "bearer". >> >> NEW: >> The required >> setup is referred to in this document as an attachment circuit (AC), while >> the underlying >> link is referred to as a "bearer". >> >> Also, please make these changes for consistency: >> >> CURRENT: "Child" ACs >> NEW: Child ACs >> >> CURRENT: "Child" AC >> NEW: Child AC >> >> Assuming these changes are made, I approve the publication of the document. >> >> Thank you. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Alanna Paloma <[email protected]> Envoyé : mercredi 3 >>> septembre 2025 00:16 À : BOUCADAIR Mohamed INNOV/NET >>> <[email protected]>; [email protected] Cc : >>> [email protected]; [email protected]; >>> [email protected]; >>> [email protected]; [email protected]; opsawg- >>> [email protected]; [email protected]; >>> [email protected]; auth48archive@rfc- >>> editor.org Objet : Re: [AD] AUTH48: RFC-to-be 9834 >>> <draft-ietf-opsawg-teas- >>> attachment-circuit-20> for your review >>> >>> >>> Hi Med and Mahesh*, >>> >>> *Mahesh - As the AD please review and approve of the following >>> updates: >>> >>> ) Section 2: Added sentences to the definitions of “network >>> controller” and “service orchestrator" >>> ) Section 9.1: Added RFC 4271 as a normative reference >>> ) Appendix A.10.1: Removed lines from the sourcecode in Figures 51 >>> and 52 >>> >>> See this diff file for the changes: >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>> www.rfc-editor.org%2Fauthors%2Frfc9834- >>> lastdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3b1c >>> 41b326d64c361ed208ddea6e6b72%7C90c7a20af34b40bfbc48b9253b6f5d20%7C >>> 0%7C0%7C638924482155178555%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk >>> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI >>> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=v5nY3%2FRKxjlsJynWH92xuI%2BqkYSQJ1p >>> %2B0KRtH34BgeQ%3D&reserved=0 >>> >>> >>> Med - Thank you for your replies. The files have been updated >>> accordingly. >>> >>> The files have been posted here (please refresh): >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>> www.rfc- >>> editor.org%2Fauthors%2Frfc9834.xml&data=05%7C02%7Cmohamed.boucadai >>> r%40orange.com%7C3b1c41b326d64c361ed208ddea6e6b72%7C90c7a20af34b40 >>> bfbc48b9253b6f5d20%7C0%7C0%7C638924482155205035%7CUnknown%7CTWFpbG >>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >>> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IwF6UcOUKljZOW >>> y8IS4xw7fHHuRgdGUjgrb%2BiLmQ%2FQI%3D&reserved=0 >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>> www.rfc- >>> editor.org%2Fauthors%2Frfc9834.txt&data=05%7C02%7Cmohamed.boucadai >>> r%40orange.com%7C3b1c41b326d64c361ed208ddea6e6b72%7C90c7a20af34b40 >>> bfbc48b9253b6f5d20%7C0%7C0%7C638924482155219658%7CUnknown%7CTWFpbG >>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >>> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2OULNe%2Fv5oxE >>> CpfRMQvCoh27BoB95wzkyQpST06EzOs%3D&reserved=0 >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>> www.rfc- >>> editor.org%2Fauthors%2Frfc9834.html&data=05%7C02%7Cmohamed.boucada >>> ir%40orange.com%7C3b1c41b326d64c361ed208ddea6e6b72%7C90c7a20af34b4 >>> 0bfbc48b9253b6f5d20%7C0%7C0%7C638924482155233207%7CUnknown%7CTWFpb >>> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI >>> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XTl97l5tn8TRH >>> 8xqOMGuMedARIQ7RzYU5NMYrC6vnv4%3D&reserved=0 >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>> www.rfc- >>> editor.org%2Fauthors%2Frfc9834.pdf&data=05%7C02%7Cmohamed.boucadai >>> r%40orange.com%7C3b1c41b326d64c361ed208ddea6e6b72%7C90c7a20af34b40 >>> bfbc48b9253b6f5d20%7C0%7C0%7C638924482155246874%7CUnknown%7CTWFpbG >>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >>> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Wdh432eQEXoC1K >>> DeDS2sZuzuZISiGyHKkeYxjU7Z0WY%3D&reserved=0 >>> >>> The relevant diff files have been posted here: >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>> www.rfc-editor.org%2Fauthors%2Frfc9834- >>> diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3b1c41b3 >>> 26d64c361ed208ddea6e6b72%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C >>> 0%7C638924482155261381%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR >>> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf >>> Q%3D%3D%7C0%7C%7C%7C&sdata=vFKtaRc9D41EME71YYOgWuWwEnunoiPFZg10qVL >>> uSg4%3D&reserved=0 (comprehensive diff) >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>> www.rfc-editor.org%2Fauthors%2Frfc9834- >>> auth48diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3b >>> 1c41b326d64c361ed208ddea6e6b72%7C90c7a20af34b40bfbc48b9253b6f5d20% >>> 7C0%7C0%7C638924482155275819%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc >>> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld >>> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=t0A3NnT9J%2BAG7u3%2BRD6l50TP%2FNo >>> tMZoEW34G2nsM2Ns%3D&reserved=0 (AUTH48 changes) >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>> www.rfc-editor.org%2Fauthors%2Frfc9834- >>> auth48rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 >>> C3b1c41b326d64c361ed208ddea6e6b72%7C90c7a20af34b40bfbc48b9253b6f5d >>> 20%7C0%7C0%7C638924482155289616%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU >>> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs >>> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EDq48Sy%2BnRv3MiVPWe1LSiNKDrcQ >>> Nsvqtk%2FQliYNE04%3D&reserved=0 (AUTH48 changes side by side) >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>> www.rfc-editor.org%2Fauthors%2Frfc9834- >>> lastdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3b1c >>> 41b326d64c361ed208ddea6e6b72%7C90c7a20af34b40bfbc48b9253b6f5d20%7C >>> 0%7C0%7C638924482155303017%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk >>> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI >>> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=XAlp%2Fawbap8uiCdjoffXrCOI2fOsp8Pmw >>> QU11lB5%2FOo%3D&reserved=0 (htmlwdiff diff between last version and >>> this) >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>> www.rfc-editor.org%2Fauthors%2Frfc9834- >>> lastrfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3 >>> b1c41b326d64c361ed208ddea6e6b72%7C90c7a20af34b40bfbc48b9253b6f5d20 >>> %7C0%7C0%7C638924482155316376%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1h >>> cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl >>> dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VdzFylUCyGXcUCFbDSTevqqt4Pu8rTqm >>> nc7PfdydDRs%3D&reserved=0 (rfcdiff between last version and this) >>> >>> We will await approvals from each author and *Mahesh prior to moving >>> this document forward in the publication process. >>> >>> For the AUTH48 status of this document, please see: >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>> www.rfc- >>> editor.org%2Fauth48%2Frfc9834&data=05%7C02%7Cmohamed.boucadair%40o >>> range.com%7C3b1c41b326d64c361ed208ddea6e6b72%7C90c7a20af34b40bfbc4 >>> 8b9253b6f5d20%7C0%7C0%7C638924482155329820%7CUnknown%7CTWFpbGZsb3d >>> 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI >>> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=QFZAi0tWZqZjnJ7%2Fq >>> TvlUW6uCbMpSTypWSJ0NCrambA%3D&reserved=0 >>> >>> Thank you, >>> Alanna Paloma >>> RFC Production Center >>> >>> >>>> On Sep 2, 2025, at 1:48 AM, [email protected] wrote: >>>> >>>> Hi Alanna, all, >>>> >>>> Please see inline. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : [email protected] <[email protected]> >>> Envoyé : >>>>> mardi 12 août 2025 07:48 À : BOUCADAIR Mohamed INNOV/NET >>>>> <[email protected]>; [email protected]; >>>>> [email protected]; >>>>> [email protected]; [email protected] Cc : >>>>> [email protected]; [email protected]; opsawg- >>>>> [email protected]; [email protected]; >>>>> [email protected]; [email protected] Objet : >>> [AD] >>>>> Re: AUTH48: RFC-to-be 9834 <draft-ietf-opsawg-teas- >>>>> attachment-circuit-20> for your review >>>>> >>>>> >>>>> Authors, AD, >>>>> >>>>> * Mahesh (as AD), please reply to #13. >>>>> >>>>> While reviewing this document during AUTH48, please resolve (as >>>>> necessary) the following questions, which are also in the XML >>> file. >>>>> >>>>> 1) <!--[rfced] In the RFC's title, we suggest removing the >>> single >>>>> quotes and hyphens. Other expansions of "ACaaS" in the document >>> and >>>>> the related documents would be updated accordingly. Is the >>> suggested >>>>> title acceptable? (This is similar to how "Software as a >>> Service >>>>> (SaaS)" >>>>> typically does not appear with hyphens when used as a noun.) >>>>> >>>>> Original: >>>>> YANG Data Models for Bearers and 'Attachment Circuits'-as-a- >>>>> Service (ACaaS) >>>>> >>>>> Suggested: >>>>> YANG Data Models for Bearers and Attachment Circuits as a >>> Service >>>>> (ACaaS) >>>>> --> >>>> >>>> [Med] ACK. >>>> >>>>> >>>>> >>>>> 2) <!--[rfced] In the second sentence below, does the customer >>>>> retrieve "a reference" or "an indication" or something else? >>>>> >>>>> Original: >>>>> The customers can then retrieve a provider-assigned bearer >>>>> reference that they will include in their AC service requests. >>>>> Likewise, a customer may retrieve whether their bearers support a >>>>> synchronization mechanism such as Sync Ethernet (SyncE) >>>>> [ITU-T-G.781]. >>>>> >>>>> Perhaps: >>>>> The customers can then retrieve a provider-assigned bearer >>>>> reference that they will include in their AC service requests. >>>>> Likewise, a customer may retrieve a reference if their bearers >>>>> support a >>> synchronization >>>>> mechanism such as Sync Ethernet (SyncE) [ITU-T-G.781]. >>>>> --> >>>> >>>> [Med] Please change to: >>>> >>>> NEW: >>>> >>>> The >>>> customers can then retrieve a provider-assigned bearer >>> reference that >>>> they will include in their AC service requests. Likewise, a >>> customer >>>> may learn whether their bearers support a synchronization >>>> mechanism such as Sync Ethernet (SyncE) [ITU-T-G.781]. >>>> >>>>> >>>>> >>>>> 3) <!--[rfced] FYI, we have reformatted some of the definitions >>> in >>>>> the "Conventions and Definitions" section to reflect what >>> appears in >>>>> RFCs-to-be 9833 and 9835. Please review and let us know any >>> changes. >>>>> --> >>>> >>>> [Med] Maybe intervert LxNM and LxVPN lines as L2VPN/L3VPN are >>> expanded under the LxVPN entry. >>>> >>>>> >>>>> >>>>> 4) <!--[rfced] We note that the definitions for "Network >>> controller" >>>>> and "Service orchestrator" in RFC-to-be 9835 each have an >>> additional >>>>> sentence that does not appear in the definition in this >>> document. >>>>> Should this sentence be added? (Specifically, "One or >>> multiple..." >>>>> and "A service orchestrator may interact..." are the additional >>>>> sentences.) >>>>> >>>>> This document (current): >>>>> Network controller: Denotes a functional entity responsible >>> for >>>>> the >>>>> management of the service provider network. >>>>> ... >>>>> Service orchestrator: Refers to a functional entity that >>> interacts >>>>> with the customer of a network service. >>>>> >>>>> A service orchestrator is typically responsible for the >>>>> attachment >>>>> circuits, the PE selection, and requesting the activation >>> of the >>>>> requested service to a network controller. >>>>> >>>>> RFC-to-be 9835: >>>>> Network controller: Denotes a functional entity responsible >>> for >>>>> the >>>>> management of the service provider network. One or >>> multiple >>>>> network controllers can be deployed in a service provider >>>>> network. >>>>> ... >>>>> Service orchestrator: Refers to a functional entity that >>> interacts >>>>> with the customer of a network service. >>>>> >>>>> A service orchestrator is typically responsible for the >>>>> attachment >>>>> circuits, the Provider Edge (PE) selection, and requesting >>> the >>>>> activation of the requested services to a network >>> controller. >>>>> >>>>> A service orchestrator may interact with one or more >>> network >>>>> controllers. >>>>> --> >>>> >>>> [Med] Please add these sentences in RFC9833 as well. Thanks. >>>> >>>>> >>>>> >>>>> 5) <!--[rfced] Since "L2VPN" and "L3VPN" are defined prior to >>> these >>>>> terms listed and to make the definitions more concise, may we >>> update >>>>> to "LxVPN"? Note that this would also match the text in RFC-to- >>> be >>>>> 9835. >>>>> >>>>> Original: >>>>> Service provider network: A network that is able to provide >>>>> network >>>>> services (e.g., Layer 2 VPN, Layer 3 VPN, or Network Slice >>>>> Services). >>>>> >>>>> Service provider: An entity that offers network services >>> (e.g., >>>>> Layer 2 VPN, Layer 3 VPN, or Network Slice Services). >>>>> >>>>> Perhaps: >>>>> Service provider network: A network that is able to provide >>>>> network >>>>> services (e.g., LxVPN or Network Slice Services). >>>>> >>>>> Service provider: An entity that offers network services >>> (e.g., >>>>> LxVPN or Network Slice Services). >>>>> --> >>>> >>>> [Med] I like this proposed change. >>>> >>>>> >>>>> >>>>> 6) <!--[rfced] Figure 5 uses "CE#1" and "CE#2", while other figures >>>>> in the document use "CE1" and "CE2". May we update the CEs in >>>>> Figure 5 >>> to >>>>> match >>>>> the other figures in the document? >>>>> >>>>> If so, both artworks (svg and ascii-art) will be updated >>>>> accordingly. >>>>> --> >>>> >>>> [Med] Agree with the proposed change. >>>> >>>>> >>>>> >>>>> 7) <!--[rfced] To avoid repetition of "future", may we remove >>> "in >>>>> the >>>>> future" from this sentence? >>>>> >>>>> Original: >>>>> Future placement criteria >>>>> ('constraint-type') may be defined in the future to >>> accommodate >>>>> specific deployment contexts. >>>>> >>>>> Perhaps: >>>>> Future placement criteria >>>>> ('constraint-type') may be defined to accommodate specific >>>>> deployment contexts. >>>>> --> >>>> >>>> [Med] WFM. >>>> >>>>> >>>>> >>>>> 8) <!--[rfced] To avoid redundancy, may we remove "when >>> requesting >>>>> a bearer"? >>>>> >>>>> Original: >>>>> A bearer request can indicate a device, a site, a combination >>>>> thereof, or a custom information when requesting >>> a >>>>> bearer. >>>>> >>>>> Perhaps: >>>>> A bearer request can indicate a device, a site, a combination >>>>> thereof, or custom information. >>>>> --> >>>>> >>>> >>>> [Med] OK. >>>> >>>>> >>>>> 9) <!--[rfced] To avoid redundancy, may we remove "actually"? >>> Note >>>>> that there >>>>> are a number of other places throughout the document with >>> similar >>>>> phrasing, >>>>> which would also be updated. >>>>> >>>>> Original: >>>>> 'actual-start': Reports the actual date and time when the bearer >>>>> actually was enabled. >>>>> >>>>> Perhaps: >>>>> >>>>> 'actual-start': Reports the actual date and time when the bearer >>>>> was enabled. >>>>> --> >>>> >>>> [Med] OK. >>>> >>>>> >>>>> >>>>> 10) <!--[rfced] For clarity, may we update "by an identifier" >>> to >>>>> "of an identifier"? >>>>> >>>>> Original: >>>>> All the above mentioned profiles are uniquely identified by >>> the >>>>> provider server by an identifier. >>>>> >>>>> Perhaps: >>>>> All the above mentioned profiles are uniquely identified by >>> the >>>>> provider server of an identifier. >>>>> --> >>>> >>>> [Med] What about? >>>> >>>> NEW: >>>> All the above mentioned profiles are uniquely identified by >>> the >>>> provider server. >>>> >>>>> >>>>> >>>>> 11) <!--[rfced] We note that RFC 4271 is only cited in the >>> "ietf- >>>>> ac-svc" YANG >>>>> module. In order to have a 1:1 matchup between the references >>>>> section >>>>> and the text, may we add it to the RFCs listed prior to the >>> YANG >>>>> module >>>>> and add a normative reference for it? >>>>> >>>>> Original: >>>>> This module uses types defined in [RFC6991], [RFC9181], >>>>> [RFC8177], >>>>> and [I-D.ietf-opsawg-teas-common-ac]. >>>>> >>>>> Perhaps:: >>>>> This module uses types defined in [RFC4271], [RFC6991], >>>>> [RFC9181], [RFC8177], >>>>> and [RFC9833]. >>>>> ... >>>>> [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., >>> "A >>>>> Border Gateway Protocol 4 (BGP-4)", RFC 4271, >>>>> DOI 10.17487/RFC4271, January 2006, >>>>> >>>>> >>> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>>> Fwww.rfc- >>>>> >>> editor.org%2Finfo%2Frfc4271&data=05%7C02%7Cmohamed.boucadair%40ora >>>>> >>> nge.com%7Cea709b5a707c491f3a7708ddd963dbcf%7C90c7a20af34b40bfbc48b >>>>> >>> 9253b6f5d20%7C0%7C0%7C638905745264598416%7CUnknown%7CTWFpbGZsb3d8e >>>>> >>> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo >>>>> >>> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cx6IQ6OaZMLvmqmHwGd5C >>>>> vjuIt50wxgfB3KshFD5zKw%3D&reserved=0>. >>>>> --> >>>> >>>> [Med] There are not yang types defined in 4271. I suggest to >>> make this change in 5.2.5.3.2 >>>> >>>> OLD: >>>> An AC service activation with BGP routing SHOULD include at >>> least the >>>> customer's AS Number (ASN) and the provider's ASN. >>>> >>>> NEW: >>>> An AC service activation with BGP routing [RFC4271] SHOULD >>> include at least the >>>> customer's AS Number (ASN) and the provider's ASN. >>>> >>>> >>>>> >>>>> >>>>> 12) <!--[rfced] FYI, the YANG module "ietf-ac-svc" has been >>>>> updated per the >>>>> formatting option of pyang. Please let us know any concerns. >>>>> (No changes were needed for "ietf-bearer-svc".) >>>>> --> >>>>> >>>>> >>>>> 13) <!--[rfced] *AD - We note that there is some text in the >>>>> Security Considerations section that differs from the template >>> on >>>>> >>> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>>> Fwiki.ietf.org%2Fgroup%2Fops%2Fyang-security- >>>>> >>> guidelines&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cea709b5 >>>>> >>> a707c491f3a7708ddd963dbcf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 >>>>> >>> C0%7C638905745264620450%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn >>>>> >>> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy >>>>> >>> fQ%3D%3D%7C0%7C%7C%7C&sdata=69L%2F86vy9UkR0tFteHgL5cM6A33WW%2FKM5M >>>>> a4%2B2vxRD4%3D&reserved=0>. >>>>> Please review and let us know if the text is acceptable. >>>>> >>>>> For example: >>>>> - Paragraph 3, the first 2 sentences are not from the template: >>>>> >>>>> "Servers MUST verify that requesting clients are entitled to >>>>> access >>>>> and manipulate a given bearer or AC. For example, a given >>>>> customer >>>>> must not have access to bearers/ACs of other customers." >>>>> >>>>> - This sentence is not present: >>>>> "There are no particularly sensitive RPC or action >>> operations." >>>>> If it should be added, should it be at the end of the section? >>>>> >>>>> From the guidelines page: >>>>> If the data model contains any particularly sensitive RPC or >>>>> action >>>>> operations, then those operations must be listed here, along >>>>> with an >>>>> explanation of the associated specific sensitivity or >>>>> vulnerability >>>>> concerns. Otherwise, state: "There are no particularly >>> sensitive >>>>> RPC or >>>>> action operations." >>>>> >>>>> - The last two paragraphs (after the readable nodes section) do >>>>> not seem to be within a section of the template. >>>> >>>> [Med] This falls under >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>> wiki.ietf.org%2Fgroup%2Fops%2Fyang-security-guidelines%23reusable- >>> groupings-from-other-modules- >>> section&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3b1c41b326 >>> d64c361ed208ddea6e6b72%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0% >>> 7C638924482155352321%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd >>> WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ% >>> 3D%3D%7C0%7C%7C%7C&sdata=rvVU4M1pDl0TCfVTFKk7f85Tn1cO8y89yNWdGSgsw >>> JU%3D&reserved=0. >>>> >>>>> --> >>>>> >>>>> >>>>> 14) <!--[rfced] "Step (3)" does not seem accurate here. Does it >>>>> refer to item 3 >>>>> in the list of assumptions, i.e., "3. The customer provisions >>> the >>>>> networking >>>>> logic..."? If so, may it be updated as follows? >>>> >>>> [Med] Yes. >>>> >>>>> >>>>> Original: >>>>> * The Cloud Provider for the configuration per Step (3) >>> above. >>>>> >>>>> Perhaps: >>>>> * The Cloud Provider for the configuration per item 3 above. >>>>> --> >>>>> >>>>> >>>>> 15) <!--[rfced] We note that this text was indented. As it is >>>>> unclear to us why >>>>> it was indented, we have removed the indentation. Was the >>> intent >>>>> for this >>>>> to be a "Note"? If yes, would you like this text to be in an >>>>> <aside> element, >>>>> which is defined as "a container for content that is >>> semantically >>>>> less important >>>>> or tangential to the content that surrounds it" >>>>> >>> (https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>>> Fauthors.ietf.org%2Fen%2Frfcxml- >>>>> >>> vocabulary%23aside&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 >>>>> >>> Cea709b5a707c491f3a7708ddd963dbcf%7C90c7a20af34b40bfbc48b9253b6f5d >>>>> >>> 20%7C0%7C0%7C638905745264633975%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU >>>>> >>> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs >>>>> >>> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=m6P3pykRPnilWKbVPfbzjqL%2B0p86 >>>>> mKF2uw8lOGPsnio%3D&reserved=0). >>>>> >>>>> Original: >>>>> The module supports MD5 to basically accommodate the >>>>> installed BGP >>>>> base (including by some Cloud Providers). Note that MD5 >>>>> suffers >>>>> from the security weaknesses discussed in Section 2 of >>>>> [RFC6151] >>>>> and Section 2.1 of [RFC6952]. >>>>> >>>>> Perhaps: >>>>> | Note: The module supports MD5 to basically accommodate the >>>>> installed >>>>> | BGP base (including by some Cloud Providers). Note that >>> MD5 >>>>> suffers >>>>> | from the security weaknesses discussed in Section 2 of >>>>> [RFC6151] >>>>> | and Section 2.1 of [RFC6952]. >>>>> --> >>>>> >>>> >>>> [Med] The use of aside element is what was intended. Thanks. >>>> >>>>> >>>>> 16) <!--[rfced] To clarify the citation of I-D.ietf-opsawg-ac- >>>>> lxsm-lxnm-glue >>>>> (RFC-to-be 9836), we have added "AC Glue" preceding it. Please >>>>> review >>>>> and let us know if further updates are needed. >>>>> >>>>> Original: >>>>> In any case, the parent >>>>> AC is a stable identifier, which can be consumed as a >>> reference >>>>> by >>>>> end-to-end service models for VPN configuration such as >>>>> [I-D.ietf-opsawg-ac-lxsm-lxnm-glue], Slice Service >>>>> [I-D.ietf-teas-ietf-network-slice-nbi-yang], etc. >>>>> >>>>> Current: >>>>> In any case, the parent >>>>> AC is a stable identifier, which can be consumed as a >>> reference >>>>> by >>>>> end-to-end service models for VPN configuration such as >>>>> AC Glue [RFC9836], Slice Service [NSSM], etc. >>>>> --> >>>> >>>> [Med] ACK. >>>> >>>> >>>>> >>>>> >>>>> 17) <!-- [rfced] FYI - We updated artwork to sourcecode in >>>>> Sections 5.1, 5.2.1, >>>>> 5.2.2.1, 5.2.4, 5.2.5, 5.2.5.1, 5.2.5.2, 5.2.5.3, 5.2.5.3.1, >>>>> 5.2.5.3.2, >>>>> 5.2.5.3.3, 5.2.5.3.4, 5.2.5.3.5, 5.2.5.3.6, 5.2.5.4, 5.2.5.5, >>> and >>>>> 5.2.5.6 >>>>> and Appendix B. Please review whether this is correct. We note >>>>> that a >>>>> YANG tree diagram is typically held in a sourcecode element >>>>> >>> (https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>>> Fauthors.ietf.org%2Fen%2Frfcxml- >>>>> >>> vocabulary%23sourcecode&data=05%7C02%7Cmohamed.boucadair%40orange. >>>>> >>> com%7Cea709b5a707c491f3a7708ddd963dbcf%7C90c7a20af34b40bfbc48b9253 >>>>> >>> b6f5d20%7C0%7C0%7C638905745264646990%7CUnknown%7CTWFpbGZsb3d8eyJFb >>>>> >>> XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF >>>>> >>> pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IHOD%2B8YtJXxoipfVBswaiPE >>>>> CR1gzEPEzBDMKXKNJENY%3D&reserved=0). >>>>> >>>>> In addition, please review the "type" attribute of each >>> sourcecode >>>>> element >>>>> in the XML file to ensure correctness. >>>>> >>>>> The current list of preferred values for "type" is available at >>>>> >>> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>>> Fwww.rfc-editor.org%2Frpc%2Fwiki%2Fdoku.php%3Fid%3Dsourcecode- >>>>> >>> types&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cea709b5a707c >>>>> >>> 491f3a7708ddd963dbcf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C >>>>> >>> 638905745264658689%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU >>>>> >>> sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D >>>>> >>> %3D%7C0%7C%7C%7C&sdata=%2F8vPI5iRoTIjKZC8fjLg7Ajcg%2F6eK1oTok5nB2i >>>>> viHk%3D&reserved=0>. >>>>> If the current list does not contain an applicable type, feel >>> free >>>>> to >>>>> suggest additions for consideration. Note that it is also >>>>> acceptable >>>>> to leave the "type" attribute not set. >>>>> --> >>>> >>>> [Med] ACK >>>> >>>>> >>>>> >>>>> 18) <!--[rfced] Abbreviations >>>>> >>>>> a) Both the expansion and the acronym for the following terms >>> are >>>>> used >>>>> throughout the document. Would you like to update to using the >>>>> expansion upon >>>>> first usage and the acronym for the rest of the document? >>>>> >>>>> attachment circuit (AC) >>>>> Customer Edge (CE) >>>>> Layer 2 VPN (L2VPN) >>>>> Layer 3 VPN (L3VPN) >>>>> Service Function (SF) >>>> >>>> [Med] Yes, please. >>>> >>>>> >>>>> >>>>> b) FYI - We have added expansions for the following >>> abbreviations >>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review >>>>> each >>>>> expansion in the document carefully to ensure correctness. >>>>> >>>>> Customer VLAN (CVLAN) >>>>> IP Address Management (IPAM) >>>>> Layer 2 VPN (L2VPN) >>>>> Layer 3 VPN (L3VPN) >>>>> Network Configuration Protocol (NETCONF) >>>>> --> >>>>> >>>> >>>> [Med] OK. >>>> >>>>> >>>>> 19) <!-- [rfced] Terminology >>>>> >>>>> a) Throughout the text, the following terminology appears to be >>>>> used >>>>> inconsistently. Please review these occurrences and let us know >>>>> if/how they >>>>> may be made consistent. >>>>> >>>>> Network Slice Service vs. Slice Service vs. IETF Network Slice >>>>> Service >>>> >>>> [Med] Bo replied to this one. >>>> >>>>> >>>>> b) To reflect how "parent AC" is consistently lowercase, may we >>>>> update >>>>> instances of "Child AC" to "child AC"? Note that there is mixed >>>>> usage >>>>> throughout the document. >>>> >>>> [Med] I have a preference for "Child AC" and "Parent AC". >>>> >>>>> --> >>>>> >>>>> >>>>> 20) <!-- [rfced] Please review the "Inclusive Language" portion >>> of >>>>> the online >>>>> Style Guide >>>>> >>> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>>> Fwww.rfc- >>>>> >>> editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C >>>>> >>> 02%7Cmohamed.boucadair%40orange.com%7Cea709b5a707c491f3a7708ddd963 >>>>> >>> dbcf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6389057452646702 >>>>> >>> 33%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA >>>>> >>> wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C >>>>> >>> &sdata=ZZ6E%2B8ki5ig%2BrdNZLJZWw7CfM7p5kxCaCYxjmnmhwg4%3D&reserved >>>>> =0> >>>>> and let us know if any changes are needed. Updates of this >>> nature >>>>> typically >>>>> result in more precise language, which is helpful for readers. >>>>> >>>>> For example, please consider whether the following should be >>>>> updated: >>>>> natively >>>> >>>> [Med] We can update this one to "do not have built-in ..." >>>> >>>>> --> >>>>> >>>>> >>>>> Thank you. >>>>> >>>>> RFC Editor/ap/ar >>>>> >>>>> >>>>> On Aug 11, 2025, [email protected] wrote: >>>>> >>>>> *****IMPORTANT***** >>>>> >>>>> Updated 2025/08/11 >>>>> >>>>> RFC Author(s): >>>>> -------------- >>>>> >>>>> Instructions for Completing AUTH48 >>>>> >>>>> Your document has now entered AUTH48. Once it has been >>> reviewed >>>>> and >>>>> approved by you and all coauthors, it will be published as an >>> RFC. >>>>> If an author is no longer available, there are several remedies >>>>> available as listed in the FAQ >>>>> >>> (https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>>> Fwww.rfc- >>>>> >>> editor.org%2Ffaq%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com% >>>>> >>> 7Cea709b5a707c491f3a7708ddd963dbcf%7C90c7a20af34b40bfbc48b9253b6f5 >>>>> >>> d20%7C0%7C0%7C638905745264682324%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e >>>>> >>> U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI >>>>> >>> sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=T2Bl3yPvWeCztumARviiHTX8FhTuo >>>>> sjBazaQvLWG%2FhM%3D&reserved=0). >>>>> >>>>> You and you coauthors are responsible for engaging other >>> parties >>>>> (e.g., Contributors or Working Group) as necessary before >>>>> providing >>>>> your approval. >>>>> >>>>> Planning your review >>>>> --------------------- >>>>> >>>>> Please review the following aspects of your document: >>>>> >>>>> * RFC Editor questions >>>>> >>>>> Please review and resolve any questions raised by the RFC >>> Editor >>>>> that have been included in the XML file as comments marked as >>>>> follows: >>>>> >>>>> <!-- [rfced] ... --> >>>>> >>>>> These questions will also be sent in a subsequent email. >>>>> >>>>> * Changes submitted by coauthors >>>>> >>>>> Please ensure that you review any changes submitted by your >>>>> coauthors. We assume that if you do not speak up that you >>>>> agree to changes submitted by your coauthors. >>>>> >>>>> * Content >>>>> >>>>> Please review the full content of the document, as this cannot >>>>> change once the RFC is published. Please pay particular >>>>> attention to: >>>>> - IANA considerations updates (if applicable) >>>>> - contact information >>>>> - references >>>>> >>>>> * Copyright notices and legends >>>>> >>>>> Please review the copyright notice and legends as defined in >>>>> RFC 5378 and the Trust Legal Provisions >>>>> (TLP - >>>>> >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>> trustee.ietf.org%2Flicense- >>>>> >>> info&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cea709b5a707c4 >>>>> >>> 91f3a7708ddd963dbcf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6 >>>>> >>> 38905745264694233%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs >>>>> >>> IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% >>>>> >>> 3D%7C0%7C%7C%7C&sdata=CWVt8m%2F4dwVATSJakUJQPtmZkK9DzBpUmSWA5z307K >>>>> M%3D&reserved=0). >>>>> >>>>> * Semantic markup >>>>> >>>>> Please review the markup in the XML file to ensure that >>> elements >>>>> of >>>>> content are correctly tagged. For example, ensure that >>>>> <sourcecode> >>>>> and <artwork> are set correctly. See details at >>>>> >>>>> >>> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>>> Fauthors.ietf.org%2Frfcxml- >>>>> >>> vocabulary&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cea709b5 >>>>> >>> a707c491f3a7708ddd963dbcf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 >>>>> >>> C0%7C638905745264705959%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn >>>>> >>> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy >>>>> >>> fQ%3D%3D%7C0%7C%7C%7C&sdata=0E4WQv3AfVKCZ9TIE5DF0mgnGlU9Dm0vzRC5SN >>>>> fuKLM%3D&reserved=0>. >>>>> >>>>> * Formatted output >>>>> >>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>> formatted output, as generated from the markup in the XML >>> file, >>>>> is >>>>> reasonable. Please note that the TXT will have formatting >>>>> limitations compared to the PDF and HTML. >>>>> >>>>> >>>>> Submitting changes >>>>> ------------------ >>>>> >>>>> To submit changes, please reply to this email using 'REPLY ALL' >>> as >>>>> all >>>>> the parties CCed on this message need to see your changes. The >>>>> parties >>>>> include: >>>>> >>>>> * your coauthors >>>>> >>>>> * [email protected] (the RPC team) >>>>> >>>>> * other document participants, depending on the stream (e.g., >>>>> IETF Stream participants are your working group chairs, the >>>>> responsible ADs, and the document shepherd). >>>>> >>>>> * [email protected], which is a new archival >>> mailing >>>>> list >>>>> to preserve AUTH48 conversations; it is not an active >>>>> discussion >>>>> list: >>>>> >>>>> * More info: >>>>> >>>>> >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>> mailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh- >>>>> >>> 4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 >>>>> >>> Cea709b5a707c491f3a7708ddd963dbcf%7C90c7a20af34b40bfbc48b9253b6f5d >>>>> >>> 20%7C0%7C0%7C638905745264717353%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU >>>>> >>> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs >>>>> >>> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bRymJrVkc%2FS3sVrNamHNJDojjmfM >>>>> MRLttkhKSfCKcIc%3D&reserved=0 >>>>> >>>>> * The archive itself: >>>>> >>>>> >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>> >>> mailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C >>>>> >>> 02%7Cmohamed.boucadair%40orange.com%7Cea709b5a707c491f3a7708ddd963 >>>>> >>> dbcf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6389057452647291 >>>>> >>> 71%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA >>>>> >>> wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C >>>>> >>> &sdata=P7d9k0SuE6%2FvbdDbLRFvsGd4G5BS3zwUXlcIs9DTXno%3D&reserved=0 >>>>> >>>>> * Note: If only absolutely necessary, you may temporarily >>> opt >>>>> out >>>>> of the archiving of messages (e.g., to discuss a >>> sensitive >>>>> matter). >>>>> If needed, please add a note at the top of the message >>> that >>>>> you >>>>> have dropped the address. When the discussion is >>> concluded, >>>>> [email protected] will be re-added to the CC >>>>> list and >>>>> its addition will be noted at the top of the message. >>>>> >>>>> You may submit your changes in one of two ways: >>>>> >>>>> An update to the provided XML file >>>>> - OR - >>>>> An explicit list of changes in this format >>>>> >>>>> Section # (or indicate Global) >>>>> >>>>> OLD: >>>>> old text >>>>> >>>>> NEW: >>>>> new text >>>>> >>>>> You do not need to reply with both an updated XML file and an >>>>> explicit >>>>> list of changes, as either form is sufficient. >>>>> >>>>> We will ask a stream manager to review and approve any changes >>>>> that seem >>>>> beyond editorial in nature, e.g., addition of new text, >>> deletion >>>>> of text, >>>>> and technical changes. Information about stream managers can >>> be >>>>> found in >>>>> the FAQ. Editorial changes do not require approval from a >>> stream >>>>> manager. >>>>> >>>>> >>>>> Approving for publication >>>>> -------------------------- >>>>> >>>>> To approve your RFC for publication, please reply to this email >>>>> stating >>>>> that you approve this RFC for publication. Please use 'REPLY >>>>> ALL', >>>>> as all the parties CCed on this message need to see your >>> approval. >>>>> >>>>> >>>>> Files >>>>> ----- >>>>> >>>>> The files are available here: >>>>> >>>>> >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>> >>> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw >>> ww.rfc- >>> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3b1c41b326d64c >>> 361ed208ddea6e6b72%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63 >>> 8924482155409766%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI >>> lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3 >>> D%7C0%7C%7C%7C&sdata=Jf9%2FnOpr5gEovu4pmrhBUvrie5P%2Bmmf9OOpL%2BLH >>> Po%2Bw%3D&reserved=0 >>>>> >>> editor.org%2Fauthors%2Frfc9834.xml&data=05%7C02%7Cmohamed.boucadai >>>>> >>> r%40orange.com%7Cea709b5a707c491f3a7708ddd963dbcf%7C90c7a20af34b40 >>>>> >>> bfbc48b9253b6f5d20%7C0%7C0%7C638905745264742057%7CUnknown%7CTWFpbG >>>>> >>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >>>>> >>> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=8544qgVDrcQPdo >>>>> c2XOLWOBZKSDkgB1TZ82cE%2FX4HC0I%3D&reserved=0 >>>>> >>>>> >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>> >>> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw >>> ww.rfc- >>> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3b1c41b326d64c >>> 361ed208ddea6e6b72%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63 >>> 8924482155431720%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI >>> lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3 >>> D%7C0%7C%7C%7C&sdata=DpnWsUHXLRHZ2YuNnuRYAKPraXzQWujrcXw3h1zIH0Q%3 >>> D&reserved=0 >>>>> >>> editor.org%2Fauthors%2Frfc9834.html&data=05%7C02%7Cmohamed.boucada >>>>> >>> ir%40orange.com%7Cea709b5a707c491f3a7708ddd963dbcf%7C90c7a20af34b4 >>>>> >>> 0bfbc48b9253b6f5d20%7C0%7C0%7C638905745264754010%7CUnknown%7CTWFpb >>>>> >>> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI >>>>> >>> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jAHr6ZnNuX6j8 >>>>> eL%2FEtePDVv2yyD%2Bhu%2BTGWzR88%2Btl9U%3D&reserved=0 >>>>> >>>>> >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>> >>> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw >>> ww.rfc- >>> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3b1c41b326d64c >>> 361ed208ddea6e6b72%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63 >>> 8924482155449887%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI >>> lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3 >>> D%7C0%7C%7C%7C&sdata=4U%2FMl1gL3ifQw1Sd2tRZ2xkpebMfICDG8mQ1zbmASE8 >>> %3D&reserved=0 >>>>> >>> editor.org%2Fauthors%2Frfc9834.pdf&data=05%7C02%7Cmohamed.boucadai >>>>> >>> r%40orange.com%7Cea709b5a707c491f3a7708ddd963dbcf%7C90c7a20af34b40 >>>>> >>> bfbc48b9253b6f5d20%7C0%7C0%7C638905745264768591%7CUnknown%7CTWFpbG >>>>> >>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >>>>> >>> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=tZkZfGJtByc%2B >>>>> bbLHgAHZK2pgk%2B7pg9amR3MSV4UyiI0%3D&reserved=0 >>>>> >>>>> >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>> >>> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw >>> ww.rfc- >>> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3b1c41b326d64c >>> 361ed208ddea6e6b72%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63 >>> 8924482155467905%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI >>> lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3 >>> D%7C0%7C%7C%7C&sdata=N3ioKmzOxNh9g8y2lqgS1YiSvFVHcxeduVF4pTCDFIg%3 >>> D&reserved=0 >>>>> >>> editor.org%2Fauthors%2Frfc9834.txt&data=05%7C02%7Cmohamed.boucadai >>>>> >>> r%40orange.com%7Cea709b5a707c491f3a7708ddd963dbcf%7C90c7a20af34b40 >>>>> >>> bfbc48b9253b6f5d20%7C0%7C0%7C638905745264781464%7CUnknown%7CTWFpbG >>>>> >>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >>>>> >>> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=YJF53pVZEGNOAs >>>>> YEfChLYwHwBHktzXfCp9t8ZcTQWCY%3D&reserved=0 >>>>> >>>>> Diff file of the text: >>>>> >>>>> >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>> >>> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw >>> ww.rfc- >>> editor.org%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3b1c >>> 41b326d64c361ed208ddea6e6b72%7C90c7a20af34b40bfbc48b9253b6f5d20%7C >>> 0%7C0%7C638924482155485841%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk >>> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI >>> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=vnIXsO4V6TLXZNhO%2FTs2sGZR6KTbGsTB7 >>> cBSG%2FPsnHM%3D&reserved=0%2Fauthors%2Frfc9834- >>>>> >>> diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cea709b5a >>>>> >>> 707c491f3a7708ddd963dbcf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C >>>>> >>> 0%7C638905745264794196%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR >>>>> >>> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf >>>>> >>> Q%3D%3D%7C0%7C%7C%7C&sdata=qSLHYSAce7hdepUC78GS7mqNqSkMP%2FIMJzuDv >>>>> tCr5ls%3D&reserved=0 >>>>> >>>>> >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>> >>> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw >>> ww.rfc- >>> editor.org%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3b1c >>> 41b326d64c361ed208ddea6e6b72%7C90c7a20af34b40bfbc48b9253b6f5d20%7C >>> 0%7C0%7C638924482155503751%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk >>> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI >>> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=t7dqlUF0ZdHK4slQ0z%2FiYwYM7LRtpIGaW >>> 6uSRGTJmes%3D&reserved=0%2Fauthors%2Frfc9834- >>>>> >>> rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cea709 >>>>> >>> b5a707c491f3a7708ddd963dbcf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0 >>>>> >>> %7C0%7C638905745264807618%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki >>>>> >>> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj >>>>> >>> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=xNHgHUz4g%2BLUWjXAPmedJUS2Z6Kt8%2BT6 >>>>> 0zgbtqG0kXU%3D&reserved=0 (side by side) >>>>> >>>>> Diff of the XML: >>>>> >>>>> >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>> >>> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw >>> ww.rfc- >>> editor.org%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3b1c >>> 41b326d64c361ed208ddea6e6b72%7C90c7a20af34b40bfbc48b9253b6f5d20%7C >>> 0%7C0%7C638924482155521458%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk >>> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI >>> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=29AknUcFZsep8T8lKExaXhuM62lsE5QA7n1 >>> 0B9FTRnc%3D&reserved=0%2Fauthors%2Frfc9834- >>>>> >>> xmldiff1.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cea70 >>>>> >>> 9b5a707c491f3a7708ddd963dbcf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C >>>>> >>> 0%7C0%7C638905745264821169%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk >>>>> >>> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI >>>>> >>> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=hfY0SRFqsA0qjXbuy5v%2FIeXY2yyQF1iJC >>>>> UceOHtIj7s%3D&reserved=0 >>>>> >>>>> >>>>> Tracking progress >>>>> ----------------- >>>>> >>>>> The details of the AUTH48 status of your document are here: >>>>> >>>>> >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>> >>> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw >>> ww.rfc- >>> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3b1c41b326d64c >>> 361ed208ddea6e6b72%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63 >>> 8924482155539378%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI >>> lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3 >>> D%7C0%7C%7C%7C&sdata=GbWCPBsBlCop8iXjD3%2Bho%2FfWF1NVAyB5Wv7wXmtQl >>> 7E%3D&reserved=0 >>>>> >>> editor.org%2Fauth48%2Frfc9834&data=05%7C02%7Cmohamed.boucadair%40o >>>>> >>> range.com%7Cea709b5a707c491f3a7708ddd963dbcf%7C90c7a20af34b40bfbc4 >>>>> >>> 8b9253b6f5d20%7C0%7C0%7C638905745264834196%7CUnknown%7CTWFpbGZsb3d >>>>> >>> 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI >>>>> >>> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZMwVWjAs59gLIcj2zDB >>>>> DpCHgaD147af2ArZke%2FcnVsk%3D&reserved=0 >>>>> >>>>> Please let us know if you have any questions. >>>>> >>>>> Thank you for your cooperation, >>>>> >>>>> RFC Editor >>>>> >>>>> -------------------------------------- >>>>> RFC9834 (draft-ietf-opsawg-teas-attachment-circuit-20) >>>>> >>>>> Title : YANG Data Models for Bearers and 'Attachment >>>>> Circuits'-as-a-Service (ACaaS) >>>>> Author(s) : M. Boucadair, R. Roberts, O. Gonzalez de >>> Dios, >>>>> S. Barguil Giraldo, B. Wu >>>>> WG Chair(s) : Joe Clarke, Benoît Claise >>>>> Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani >>>> >>>> >>> __________________________________________________________________ >>> __________________________________________ >>>> 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. >>> >> >> ____________________________________________________________________________________________________________ >> 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. > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
