Hi Mahesh, Thank you for confirming. We have noted your approval on the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9834
Best regards, RFC Editor/ap > On Aug 13, 2025, at 3:08 PM, Mahesh Jethanandani <mjethanand...@gmail.com> > wrote: > > 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
