Hi Alanna, These changes look good to me. Thanks for working on them.
Cheers. > On Aug 13, 2025, at 2:22 PM, Alanna Paloma <apal...@staff.rfc-editor.org> > wrote: > > 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 > > Mahesh Jethanandani mjethanand...@gmail.com
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
