Hi Mahesh, Thank you for the quick reply. 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) Thank you, RFC Editor/ap > On Aug 13, 2025, at 1:45 PM, Mahesh Jethanandani <mjethanand...@gmail.com> > wrote: > > Hi Alanna, > >> On Aug 13, 2025, at 12:01 PM, Alanna Paloma <apal...@staff.rfc-editor.org> >> wrote: >> >> Hi Mahesh, >> >> We have slightly updated your suggested text; see below. >> >> Additionally, we have a clarifying question. Should the section citation be >> updated to match the template (Section 3.7 vs. Section 3.7.1)? >> >> Current: >> The remainder of this section is modeled after the template described >> in Section 3.7 of [YANG-GUIDELINES]. >> >> Template (https://wiki.ietf.org/group/ops/yang-security-guidelines): >> This section is modeled after the template described in Section 3.7.1 >> of [RFC-to-be draft-ietf-netmod-rfc8407bis]. > > Reference should be to Section 3.7.1. Thanks for catching it. > > I am not sure of the first line though that starts with “Template > (https://…)”. That would be odd, as we have the reference to the template in > rfc8407bis already. Giving another reference, this time to the wiki would be > a duplicate reference. Please drop that line. > > Cheers. > >> >> 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) >> >> Thank you, >> RFC Editor/ap >> >>> On Aug 13, 2025, at 10:35 AM, Mahesh Jethanandani <mjethanand...@gmail.com> >>> wrote: >>> >>> Hi Alanna, >>> >>> Thanks for making the changes. Just one nit. Can we say? >>> >>> OLD: >>> This section is modeled after the template described ... >>> >>> NEW: >>> The remaining section is modeled after the template described … >>> >>> Thanks. >>> >>> >>>> On Aug 13, 2025, at 9:27 AM, Alanna Paloma <apal...@staff.rfc-editor.org> >>>> wrote: >>>> >>>> Hi Mahesh, >>>> >>>> Thank you for your reply. We have updated the Security Considerations >>>> section accordingly; see the files below. >>>> >>>> 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) >>>> >>>> For the AUTH48 status of this document, please see: >>>> https://www.rfc-editor.org/auth48/rfc9834 >>>> >>>> Thank you, >>>> RFC Editor/ap >>>> >>>>> On Aug 12, 2025, at 10:00 PM, Mahesh Jethanandani >>>>> <mjethanand...@gmail.com> wrote: >>>>> >>>>> Hi Alice, >>>>> >>>>>> On Aug 11, 2025, at 10:48 PM, rfc-edi...@rfc-editor.org wrote: >>>>>> >>>>>> 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) >>>>>> --> >>>>>> >>>>>> >>>>>> 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]. >>>>>> --> >>>>>> >>>>>> >>>>>> 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. >>>>>> --> >>>>>> >>>>>> >>>>>> 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. >>>>>> --> >>>>>> >>>>>> >>>>>> 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). >>>>>> --> >>>>>> >>>>>> >>>>>> 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. >>>>>> --> >>>>>> >>>>>> >>>>>> 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. >>>>>> --> >>>>>> >>>>>> >>>>>> 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. >>>>>> --> >>>>>> >>>>>> >>>>>> 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. >>>>>> --> >>>>>> >>>>>> >>>>>> 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. >>>>>> --> >>>>>> >>>>>> >>>>>> 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://www.rfc-editor.org/info/rfc4271>. >>>>>> --> >>>>>> >>>>>> >>>>>> 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://wiki.ietf.org/group/ops/yang-security-guidelines>. >>>>>> 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." >>>>> >>>>> That is ok to add, while maintaining the rest of the statements from the >>>>> template. >>>>> >>>>>> >>>>>> - 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? >>>>> >>>>> Yes, it should be added to 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. >>>>>> --> >>>>> >>>>> >>>>> These two paragraphs can be moved to the beginning of the Security >>>>> Considerations section before the statement that says “This section is >>>>> modeled after the template …”, just to be clear that it is not part of >>>>> the template. Alternatively, they could be moved into a sub-section. >>>>> >>>>> Thanks. >>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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? >>>>>> >>>>>> 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://authors.ietf.org/en/rfcxml-vocabulary#aside). >>>>>> >>>>>> 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]. >>>>>> --> >>>>>> >>>>>> >>>>>> 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. >>>>>> --> >>>>>> >>>>>> >>>>>> 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://authors.ietf.org/en/rfcxml-vocabulary#sourcecode). >>>>>> >>>>>> 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://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. >>>>>> 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. >>>>>> --> >>>>>> >>>>>> >>>>>> 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) >>>>>> >>>>>> >>>>>> 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) >>>>>> --> >>>>>> >>>>>> >>>>>> 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 >>>>>> >>>>>> 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. >>>>>> --> >>>>>> >>>>>> >>>>>> 20) <!-- [rfced] Please review the "Inclusive Language" portion of the >>>>>> online >>>>>> Style Guide >>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>>>>> 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 >>>>>> --> >>>>>> >>>>>> >>>>>> 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://www.rfc-editor.org/faq/). >>>>>> >>>>>> 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://trustee.ietf.org/license-info). >>>>>> >>>>>> * 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://authors.ietf.org/rfcxml-vocabulary>. >>>>>> >>>>>> * 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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>>>>> >>>>>> * The archive itself: >>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>>>> >>>>>> * 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://www.rfc-editor.org/authors/rfc9834.xml >>>>>> https://www.rfc-editor.org/authors/rfc9834.html >>>>>> https://www.rfc-editor.org/authors/rfc9834.pdf >>>>>> https://www.rfc-editor.org/authors/rfc9834.txt >>>>>> >>>>>> Diff file of the text: >>>>>> https://www.rfc-editor.org/authors/rfc9834-diff.html >>>>>> https://www.rfc-editor.org/authors/rfc9834-rfcdiff.html (side by side) >>>>>> >>>>>> Diff of the XML: >>>>>> https://www.rfc-editor.org/authors/rfc9834-xmldiff1.html >>>>>> >>>>>> >>>>>> Tracking progress >>>>>> ----------------- >>>>>> >>>>>> The details of the AUTH48 status of your document are here: >>>>>> https://www.rfc-editor.org/auth48/rfc9834 >>>>>> >>>>>> 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 >>>>>> >>>>> >>>>> >>>>> Mahesh Jethanandani >>>>> mjethanand...@gmail.com >>>> >>>> >>> >>> >>> Mahesh Jethanandani >>> mjethanand...@gmail.com >>> >>> >>> >>> >>> >>> >> > > > Mahesh Jethanandani > mjethanand...@gmail.com -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
