Authors,
One additional note on https://www.rfc-editor.org/authors/rfc9834.html (and the
other formats).
20) FYI, we changed 'choosen' to 'chosen' here; please let us know if that was
not the intention. (There are 4 instances in this document; zero instances in
the other documents in this cluster.)
ORIGINAL:
"name": "a-name-choosen-by-client",
CURRENT:
"name": "a-name-chosen-by-client",
Thank you.
RFC Editor/ar
> 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."
>
> - This sentence is not present:
> "There are no particularly sensitive RPC or action operations."
> If it should be added, should it be at the end of the section?
>
>> From the guidelines page:
> If the data model contains any particularly sensitive RPC or action
> operations, then those operations must be listed here, along with an
> explanation of the associated specific sensitivity or vulnerability
> concerns. Otherwise, state: "There are no particularly sensitive RPC or
> action operations."
>
> - The last two paragraphs (after the readable nodes section) do
> not seem to be within a section of the template.
> -->
>
>
> 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:
>
> [...]
>
> 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
>
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
