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://www.rfc-editor.org/authors/rfc9834-lastdiff.html Med - Thank you for your replies. The files have been updated accordingly. 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) 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://www.rfc-editor.org/auth48/rfc9834 Thank you, Alanna Paloma RFC Production Center > On Sep 2, 2025, at 1:48 AM, mohamed.boucad...@orange.com wrote: > > Hi Alanna, all, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> >> Envoyé : mardi 12 août 2025 07:48 >> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; >> rrobe...@juniper.net; oscar.gonzalezded...@telefonica.com; >> samier.barguil_gira...@nokia.com; lana.w...@huawei.com >> Cc : rfc-edi...@rfc-editor.org; opsawg-...@ietf.org; opsawg- >> cha...@ietf.org; luismiguel.contrerasmuri...@telefonica.com; >> mjethanand...@gmail.com; auth48archive@rfc-editor.org >> 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://wiki.ietf.org/group/ops/yang-security-guidelines#reusable-groupings-from-other-modules-section. > > >> --> >> >> >> 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, rfc-edi...@rfc-editor.org 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 >> >> * rfc-edi...@rfc-editor.org (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). >> >> * auth48archive@rfc-editor.org, 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, >> auth48archive@rfc-editor.org 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 >> www.rfc- >> 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 >> www.rfc- >> 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 >> www.rfc- >> 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 >> www.rfc- >> 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 >> www.rfc-editor.org%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 >> www.rfc-editor.org%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 >> www.rfc-editor.org%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 >> www.rfc- >> 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. -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
