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]. 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 > > > > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
