Re: [auth48] AUTH48: RFC-to-be 9543 <draft-ietf-teas-ietf-network-slices-25> for your review

[Shunsuke Homma <[e-mail]>]

Hi Adrian,

Thank you for your reply. I got it.
As a point which I'm just a bit concerned about, the latest TS23.501 v18
has many updates from v16 on the "Network Slicing" part.  Although I assume
that it has no impact on this RFC because IETF Network Slice is decoupled/
loosely-coupled from 5G Network Slicing, I'm reading the latest TS23.501
just to be sure. I'll report if I find some problems.

Regarding ORAN web site, I assume you forget to click the "APPLY FILTER"
button after clearing the check box. (Sorry if it does not work fine.)

Regards,

Shunsuke

On Mon, Feb 19, 2024 at 12:30 AM Adrian Farrel <[e-mail]> wrote:

> Thanks Shunsuke,
>
>
>
> I’ll take advice from the RFC Editor on both these points.
>
>
>
> 3GPP: I think we can point to a specific version, and we should use those
> that are in force at the time the RFC is published
>
>
>
> ORAN: The “show latest” didn’t work on my browser (cookies?), but if it
> works for Shunsuke it probably works for others. If this is the case, we
> should:
>
>    - Point to the version in force at the time the RFC is published
>    - Include the link to the page with the box checked
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Shunsuke Homma <[e-mail]>
> *Sent:* 18 February 2024 04:28
> *To:* [e-mail]
> *Cc:* [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> *Subject:* Re: AUTH48: RFC-to-be 9543
> <draft-ietf-teas-ietf-network-slices-25> for your review
>
>
>
> Hi Adrian,
>
> Thank you for your work on this. All of your replies make sense to me.
>
> I have a question on references of 3GPP documents. They have several major
> versions and they seem to be continuously updated. So, should it be
> indicated which version is referred to in this RFC?
>
>
> By the way, regarding ORAN documents, you can find past documents by
> clearing the check box for  "show latest". (But I'm OK to remove the
> version number and date because it is updated frequently.)
>
>
>
> Regards,
>
>
>
> Shunsuke
>
>
>
> On Sun, Feb 18, 2024 at 6:19 AM Adrian Farrel <[e-mail]> wrote:
>
> Hey!
>
> Thanks for this work. I'm responding here without having read Shunsuke's
> email.
>
> I'll get to that "soon".
>
> In line...
>
> Cheers,
> Adrian
>
> 1) <!-- [rfced] FYI - In this sentence, we updated the last item in the
> series
> (i.e., "how abstract requests...") to create parallel structure. Please
> review and let us know any objections.
>
> Original:
>    The document discusses the general framework for requesting and
>    operating IETF Network Slices, the characteristics of an IETF Network
>    Slice, the necessary system components and interfaces, and how
>    abstract requests can be mapped to more specific technologies.
>
> Current:
>    The document discusses the general framework for requesting and
>    operating IETF Network Slices, the characteristics of an IETF Network
>    Slice, the necessary system components and interfaces, and the
>    mapping of abstract requests to more specific technologies.
> -->
>
> Sure.
>
> 2) <!-- [rfced] Please review "described...described". Would you like to
> replace
> one of these with another word?
>
> Original:
>    ...the qualifying term "IETF" is used in this document to limit the
> scope of
>    the network slices described to network technologies described and
>    standardized by the IETF.
>
> Perhaps (change one instance of "described" to "defined"):
>    ...the qualifying term "IETF" is used in this document to limit the
> scope of
>    the network slices described to network technologies defined and
> standardized
>    by the IETF.
>
> Or (remove first "described"):
>    ...the qualifying term "IETF" is used in this document to limit the
> scope of
>    network slices to network technologies described and standardized
>    by the IETF.
> -->
>
> Yeah, I prefer the 2nd 'described' over 'defined' for various reasons of
> fact.
> So the second option (remove the first 'described') is better.
>
> 3) <!-- [rfced] May we update "per {IETF Network Slice Service,
> connectivity
> construct, and SLOs/SLEs} basis" as follows?
>
> Original:
>    The customer and provider may
>    agree on a per {IETF Network Slice Service, connectivity
>    construct, and SLOs/SLEs} basis to police or shape traffic on the
>    AC in both the ingress (CE to PE) direction and egress (PE to CE)
>    direction.
>
> Perhaps:
>    The customer and provider may agree to police or shape traffic (based on
>    the specific IETF Network Slice Service, connectivity construct, and
>    SLOs/SLEs) on the AC in both the ingress (CE to PE) direction and egress
>    (PE to CE) direction.
> -->
>
> Yours is better, but still splits 'police or shape' from 'on the AC' which
> is lumpy.
> How about...
>    The customer and provider may agree to police or shape traffic on the AC
>    in both the ingress (CE to PE) direction and egress (PE to CE)
> direction. This
>    policing and shaping is based on the specific IETF Network Slice
> Service,
>    connectivity construct, and SLOs/SLEs)
>
> 4) <!-- [rfced] Would updating as follows improve readability of this long
> sentence?
>
> Original:
>    A clear distinction should be made between the "IETF Network Slice
>    Service" which is the function delivered to the customer (see
>    Section 4.2) and which is agnostic to the technologies and mechanisms
>    used by the service provider, and the "IETF Network Slice" which is
>    the realization of the service in the provider's network achieved by
>    partitioning network resources and by applying certain tools and
>    techniques within the network (see Section 4.1 and Section 7).
>
> Perhaps:
>   A clear distinction should be made between the IETF Network Slice
>   Service and the IETF Network Slice:
>
>   IETF Network Slice Service: The function delivered to the customer
>      (see Section 4.2). It is agnostic to the technologies and
>      mechanisms used by the service provider.
>
>   IETF Network Slice: The realization of the service in the provider's
>      network achieved by partitioning network resources and by applying
>      certain tools and techniques within the network (see Sections 4.1
>      and 7).
> -->
>
> Yes
>
> 5) <!-- [rfced] Would using bullets make this text easier to read? Or do
> you
> prefer the current?
>
> Original:
>    That is, in a given IETF
>    Network Slice Service there may be one or more connectivity
>    constructs of the same or different type, each connectivity construct
>    may be between a different subset of SDPs, for a given connectivity
>    construct each sending SDP has its own set of SLOs and SLEs, and the
>    SLOs and SLEs in each set may be different.
>
> Perhaps:
>    That is, in a given IETF Network Slice Service:
>
>    *  There may be one or more connectivity constructs of the same
>       or different type.
>
>    *  Each connectivity construct may be between a different subset of
>       SDPs
>
>    *  For a given connectivity construct, each sending SDP has its own
>       set of SLOs and SLEs.
>
>    *  The SLOs and SLEs in each set may be different.
> -->
>
> Almost.
> I think the 'set' in the last bullet has lost context. So make it:
>     * The SLOs and SLEs in each set of SDPs may be different.
>
> 6) <!-- [rfced] Please review "That is, and in particular" in the second
> sentence
> below (first sentence is included for context). Should this read simply
> "That is" or "In particular"?
>
> Original:
>    From the above, it can be seen that the SLOs of the senders define
>    the SLOs for the receivers on any connectivity construct.  That is,
>    and in particular, the network may be expected to handle the traffic
>    volume from a sender to all destinations.  This extends to all
>    connectivity constructs in an IETF Network Slice Service.
>
> Perhaps:
>    From the above, it can be seen that the SLOs of the senders define
>    the SLOs for the receivers on any connectivity construct.  That is,
>    the network may be expected to handle the traffic
>    volume from a sender to all destinations.  This extends to all
>    connectivity constructs in an IETF Network Slice Service.
>
> Or:
>    From the above, it can be seen that the SLOs of the senders define
>    the SLOs for the receivers on any connectivity construct.
>    In particular, the network may be expected to handle the traffic
>    volume from a sender to all destinations.  This extends to all
>    connectivity constructs in an IETF Network Slice Service.
> -->
>
> Mutter, mutter. Authors who want to stress things when it is enough to
> just say them :-)
>
> Your first option ('That is')
>
> 7) <!-- [rfced] Please clarify the text starting with "and commercial
> terms...". Also, may we split up this long sentence to improve
> readability?
>
> Original:
>       The SLA is expressed in terms of a set
>       of SLOs and SLEs that are to be applied for a given connectivity
>       construct between a sending SDP and the set of receiving SDPs, and
>       may describe the extent to which divergence from individual SLOs
>       and SLEs can be tolerated, and commercial terms as well as any
>       consequences for violating these SLOs and SLEs.
>
> Perhaps:
>       The SLA is expressed in terms of a set
>       of SLOs and SLEs that are to be applied for a given connectivity
>       construct between a sending SDP and the set of receiving SDPs.
>       The SLA may describe the extent to which divergence from individual
> SLOs
>       and SLEs can be tolerated, commercial terms, and any
>       consequences for violating these SLOs and SLEs.
> -->
>
> New...
>       The SLA is expressed in terms of a set
>       of SLOs and SLEs that are to be applied for a given connectivity
>       construct between a sending SDP and the set of receiving SDPs.
>       The SLA may also describe the extent to which divergence from
> individual
>       SLOs and SLEs can be tolerated, the commercial terms, and any
>       consequences for violating these SLOs and SLEs.
>
> 8) <!-- [rfced] Please clarify how the phrase "and specifying..." connects
> to the
> rest of the sentence.
>
> Original:
>       Availability will often be expressed along with the time period
>       over which the availability is measured, and specifying the
>       maximum allowed single period of downtime.
>
> Perhaps:
>       Availability will often be expressed along with the time period
>       over which the availability is measured and the
>       maximum allowed single period of downtime.
>
> Or:
>       Availability will often be expressed along with the time period
>       over which the availability is measured and will specify the
>       maximum allowed single period of downtime.
> -->
>
> New...
>       Availability will often be expressed along with the time period
>       over which the availability is measured. The expression of
>       availability may also include the specification of the
>       maximum allowed single period of downtime.
>
> 9) <!-- [rfced] Would it be helpful to clarify "e.g., [RFC4303]" by
> including the
> name of the mechanism in RFC 4303 as shown below? Similarly, would it
> helpful to also clarify "for compliance with [HIPAA] or [PCI]" as shown
> below?
>
> Original:
>    This SLE may include a request for encryption (e.g., [RFC4303])
>    between the two SDPs explicitly to meet the architectural
>    recommendations in [TS33.210] or for compliance with [HIPAA] or
>    [PCI].
>
> Perhaps:
>    This SLE may include a request for encryption (e.g., the Encapsulating
>    Security Payload (ESP) protocol [RFC4303])
>    between the two SDPs explicitly to meet the architectural
>    recommendations in [TS33.210] or for compliance with the HIPAA Security
> Rule [HIPAA] or
>    the PCI Data Security Standard (PCI DSS) [PCI].
> -->
>
> Sure
>
> 10) <!-- [rfced] We updated "gRPC/GNMI [I-D.openconfig-rtgwg-gnmi-spec]
> uses" in
> the first sentence below as follows.  Please review to ensure
> correctness.
>
> Also, would it be helpful to update "ProtoBufs" to "Protocol Buffers" in
> the
> second sentence? Or do you prefer the current?
>
> Original:
>    *  gRPC/GNMI [I-D.openconfig-rtgwg-gnmi-spec] uses a binary encoded
>       programmable interface.  ProtoBufs can be used to model gRPC and
>       GNMI data.
>
> Current:
>    *  gRPC and gRPC Network Management Interface (gNMI) [GNMI] use a
>       binary encoded programmable interface.  ProtoBufs can be used to
>       model gRPC and gNMI data.
> -->
>
> Hmmm, I think most people say protobuf even if the formal name is still
> Protocol Buffer.
> Apparently, it is a small 'b'
> So (note additional definite article)...
>
>    *  gRPC and the gRPC Network Management Interface (gNMI) [GNMI] use a
>       binary encoded programmable interface.  Protobufs can be used to
>       model gRPC and gNMI data.
>
> 11) <!-- [rfced] We do not see "Network Model" in RFC 8309, though we do
> see
> "Service Model", "Network Service Model", and "Network Element Model".
> Please review and let us know if any updates are needed.
>
> Original:
>    These interfaces can be considered in the context of the Service
>    Model and Network Model described in [RFC8309] and, together with the
>    Device Configuration Interface used by the Network Controllers,
>    provides a consistent view of service delivery and realization.
> -->
>
> <Red face>
> s/Network Model/Network Configuration Model/
>
> 12) <!-- [rfced] How may we update the "/" here?
>
> Original:
>    Recall that an IETF Network Slice is a service requested by /
>    provided for the customer.
>
> Perhaps:
>    Recall that an IETF Network Slice is a service requested by and/or
>    provided for the customer.
> -->
>
> Hmm. OK, if it must be replaced, please use a simple 'and', as...
>
>    Recall that an IETF Network Slice is a service requested by and
>    provided for the customer.
>
> 13) <!-- [rfced] FYI - We see that draft-ietf-teas-enhanced-vpn no longer
> uses the
> abbreviation "VPN+" (looks like it was removed in version -16). We have
> thus removed "VPN+" in the following sentences.
>
> See https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/.
>
> Original:
>    An enhanced VPN (VPN+) is designed to support the needs of new
>    applications, particularly applications that are associated with 5G
>    services.
>    . . . . . . .
>    [I-D.ietf-teas-enhanced-vpn] describes the framework for Enhanced
>    Virtual Private Network (VPN+) services.
>
> Current:
>    An enhanced VPN is designed to support the needs of new
>    applications, particularly applications that are associated with 5G
>    services.
>    . . . . . . .
>    [ENHANCED-VPN] describes the framework for Enhanced Virtual Private
>    Network services.
> -->
>
> Good catch, thanks. This was supposed to reach you as an RFC Editor Note,
> but the poor baby got lost in the woods.
>
> Your change is good.
>
> 14) <!-- [rfced] Please review the parentheses in "(part of)". Should the
> parentheses be removed, or should the phrase be moved and revised as
> shown below?
>
> Current:
>       Generate SFC classification rules to identify (part of) the slice
>       traffic that will be bound to an SFC.
>
> Perhaps (remove parentheses):
>      Generate SFC classification rules to identify part of the slice
>      traffic that will be bound to an SFC.
>
> Or (move and revise parenthetical):
>      Generate SFC classification rules to identify the slice
>      traffic (or part of it) that will be bound to an SFC.
> -->
>
> I prefer the current, but I can live with your second option (move and
> revise)
>
> 15) <!-- [rfced] May we update the text starting with "a robust..." as
> follows?
>
> Current:
>       Furthermore, both the
>       IETF Network Slice Service Interface and the Network Configuration
>       Interface need to be secured with a robust authentication and
>       authorization; and associated auditing mechanism.
>
> Perhaps:
>      Furthermore, both the
>      IETF Network Slice Service Interface and the Network Configuration
>      Interface need to be secured with a robust authentication and
>      authorizations mechanism and an associated auditing mechanism.
> -->
>
> Hmmm,
> New...
>      Furthermore, both the
>      IETF Network Slice Service Interface and the Network Configuration
>      Interface need to be secured with robust authentication and
>      authorization mechanisms, and with an associated auditing mechanism.
>
> 16) <!-- [rfced] Please review whether this "Note:" should be in the
> <aside>
> element. It 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).
>
> Current:
>    Note: See [NGMN_SEC] on 5G network slice security for discussion
>    relevant to this section.
> -->
>
> Sure, I am still reading the XML2RFC v3 manual :-)
>
> 17) <!-- [rfced] Please review the URL for the following reference. It
> returns the
> error: "Sorry, the post you are looking for is not available". May we
> update to use one of these URLs below instead?
>
>
> https://www.ngmn.org/publications/description-of-network-slicing-concept.html
> https://ngmn.org/wp-content/uploads/160113_NGMN_Network_Slicing_v1_0.pdf
>
> Original:
>    [NGMN-NS-Concept]
>               NGMN Alliance, "Description of Network Slicing Concept",
>               https://www.ngmn.org/uploads/
>               media/161010_NGMN_Network_Slicing_framework_v1.0.8.pdf ,
>               2016.
> -->
>
> I'll take
> https://ngmn.org/wp-content/uploads/160113_NGMN_Network_Slicing_v1_0.pdf
>
> 18) <!-- [rfced] New versions are available for the following 3GPP
> references. Would you like to cite the latest version, or would do you
> prefer the current?
>
> a) Latest version is 18.4.0 with date of 2023:
>
> https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144
>
> Original:
>    [TS23501]  3GPP, "System architecture for the 5G System (5GS)", 3GPP
>               TS 23.501, 2019.
>
> Perhaps:
>    [TS23.501]  3GPP, "System architecture for the 5G System (5GS)", 3GPP
>                TS 23.501, 2023.
>
> b) Latest version is 18.0.0 with date of 2024:
>
> https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3273
>
> Original:
>    [TS28530]   3GPP, "Management and orchestration; Concepts, use cases
>                and requirements", 3GPP TS 28.530, 2019.
>
> Perhaps:
>    [TS28.530]  3GPP, "Management and orchestration; Concepts, use cases
>                and requirements", 3GPP TS 28.530, 2024.
> -->
>
> Take the latest in both cases
>
> 19) <!-- [rfced] The URL below does not go directly to PCI DSS, though
> readers can
> use the search feature to find it. Would it be helpful to include the
> following link instead? Also, we see that the latest version of PCI DSS is
> dated March 2022. Would you like to update the date accordingly?
>
> Original:
>    [PCI]      PCI Security Standards Council, "PCI DSS", May 2018,
>               <https://www.pcisecuritystandards.org>.
>
> Perhaps:
>    [PCI]      PCI Security Standards Council, "PCI DSS", March 2022,
>               <https://www.pcisecuritystandards.org/document_library/>.
> -->
>
> We should go all the way to...
> https://www.pcisecuritystandards.org/document_library/?document=pci_dss
> (but no further because the documents all require a license agreement)
>
> 20) <!-- [rfced] We see that the O-RAN Slicing Architecture has a newer
> version
> than the one listed in the following reference entry. Would you like to
> cite the more recent version (version 11.0 with date of October 2023)?
>
> Also, we're having trouble determining what title is correct here. Would
> the
> following be better, or do you prefer the current?
>
> Current:
>    [ORAN]     O-RAN, "O-RAN Working Group 1 Slicing Architecture",
>               O-RAN.WG1 v06.00, 2022,
>               <https://orandownloadsweb.azurewebsites.net/
>               specifications>.
>
> Perhaps:
>    [ORAN]     O-RAN, "O-RAN Work Group 1 (Use Cases and Overall
>               Architecture): Slicing Architecture",
>               O-RAN.WG1.Slicing-Architecture-R003-v11.00, October 2023,
>               <https://orandownloadsweb.azurewebsites.net/
>               specifications>.
> -->
>
> Ah, the document title is "Slicing Architecture" the source is "O-RAN Work
> Group 1 (Use Cases and Overall Architecture)"
> And we just can't keep up! I find v12.0 came out earlier this month.
> The trouble with the ORAN site is that it will keep updating to the latest
> revision and the old ones will go away.
> That is highly annoying because it means they can change the content under
> our feet, and we cannot safely reference a version of the document.
> The use we make of the document, however, and the content of their
> architecture suggest that we should simply leave out the version number
> *and* date, as...
>
>    [ORAN]     O-RAN Working Group 1 (Use Cases and Overall Architecture),
>               "Slicing Architecture", O-RAN.WG1.Slicing-Architecture-R003
>               <https://orandownloadsweb.azurewebsites.net/
>               specifications>.
>
> 21) <!-- [rfced] Would it be helpful to add a colon after "constructs" and
> move
> the open parentheses to appear before "represented"?
>
> Original:
>    To achieve this, the customer may request
>    an IETF Network Slice Service comprising two P2P connectivity
>    constructs (CE1-CE2 and CE2-CE3 represented as *** in the figure).
>    ...
>    This service contains two P2P connectivity
>    constructs (CE1-ACE1 and ACE1-CE3 represented as ooo in the figure).
>    ...
>    In this
>    case, the IETF Network Slice Service request contains two P2P
>    connectivity constructs (CE1-ServiceFunction and ServiceFunction-CE3
>    represented as xxx in the figure).
>
> Perhaps:
>    To achieve this, the customer may request
>    an IETF Network Slice Service comprising two P2P connectivity
>    constructs: CE1-CE2 and CE2-CE3 (represented with "*" in
>    Figure 6).
>    ...
>    This service contains two P2P connectivity
>    constructs: CE1-ACE1 and ACE1-CE3 (represented with "o" in
>    Figure 6).
>    ...
>    In this case, the IETF Network Slice Service request contains two P2P
>    connectivity constructs: CE1-ServiceFunction and ServiceFunction-CE3
>    (represented with "x" in Figure 6).
> -->
>
> Don't mind the colon and parentheses. Slightly prefer using the multiple
> symbols (xxx etc.) in particular because the character 'o' has a habit of
> turning up in text and so causing confusion.
>
> 22) <!-- [rfced] Please review the quotation marks with "stacking" here.
> Are the
> quotation marks necessary?
>
> Original:
>    This "stacking" of IETF Network Slice constructs is not different to
>    the way virtual networks may be arranged.
> -->
>
> Not absolutely necessary.
>
> 23) <!-- [rfced] In the Contributors section, we updated <artwork> to
> <contact>. The parenthetical with Eric Gray's entry looks odd in the txt
> output because it appears closer to Jari's name than to Eric's name. The
> html and pdf outputs look better. To avoid any possible confusion, we
> suggest moving the parenthetical to the introductory text as
> follows. Please review and let us know your thoughts.
>
> Current:
>    The following authors contributed significantly to this document:
>
>    Eric Gray
>    Retired
>
>
>    (The original editor of the foundation documents)
>
>    Jari Arkko
>    Ericsson
>    Email: [e-mail]
>
> Perhaps:
>    The following people contributed substantially to the content of this
>    document and should be considered coauthors. Eric Gray was the original
>    editor of the foundation documents.
>
>    Eric Gray
>    Retired
>
>    Jari Arkko
>    Ericsson
>    Email: [e-mail]
> -->
>
> Yes, if the tools won't let you do it, and if artwork is not allowed, you
> have the right solution.
>
> 24) <!-- [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.
>
>    IETF network slicing vs. IETF Network Slicing
> IETF network slicing
>    network controller vs. Network Controller
> network controller (except, of course, in the hangText in 6.1)
>    orchestrator vs. Orchestrator
> orchestrator
>    "Mapping Functions" vs. mapping functions
> I believe the current text is fine
>    "stitched together" vs. stitched together
> I think you are asking:
>    "stitched" together vs. stitched together
> stitched together
>
> b) Please review "hub and spoke" and "hub-and-spoke" in the following. May
> we
> update these to "hub-and-spoke topology"? Other options include
> "hub-and-spoke
> configuration" (one instance in document) and "hub-and-spoke
> architecture" (one instance in document).
>
> Original:
>    A.3.  Hub and Spoke
>    ...
>    Hub and spoke is a popular way to realize any-to-any connectivity in
>    support of multiple P2P traffic flows ...
>    ...
>    In many cases, it is the network operator's choice
>    whether to use hub and spoke to realize a mesh of P2P connectivity
>    constructs or P2MP connectivity constructs:
>    ...
>    Figure 7: Example Hub and Spoke Under Customer Control
>    ...
>       With a P2MP or A2A connectivity construct, it is the operator's
>       choice whether to realize the construct with ingress replication,
>       multicast in the core, P2MP tunnels, or hub-and-spoke.
>
> Perhaps:
>    A.3.  Hub-and-Spoke Topology
>    ...
>    A hub-and-spoke topology is a popular way to realize any-to-any
> connectivity in
>    support of multiple P2P traffic flows ...
>    ...
>    In many cases, it is the network operator's choice
>    whether to use a hub-and-spoke topology to realize a mesh of P2P
> connectivity
>    constructs or P2MP connectivity constructs:
>    ...
>    Figure 7: Example Hub-and-Spoke Topology under Customer Control
>    ...
>       With a P2MP or A2A connectivity construct, it is the operator's
>       choice whether to realize the construct with ingress replication,
>       multicast in the core, P2MP tunnels, or a hub-and-spoke topology.
>
> Yes, that's good
>
> c) FYI - We capitalized a few instances of "IETF network slice" based on
> the
> definition in the abstract.
>
> Oh wow, thank you. Notwithstanding me having checked for this specific
> issue twice!
>
> d) FYI - We added expansions for the following abbreviations. Please
> review and
> let us know if there are any objections.
>
>    eMBB - enhanced Mobile Broadband
>    gNMI - gRPC Network Management Interface
>    mMTC - massive Machine Type Communications
>    MAC - Media Access Control
>    MACsec - Media Access Control Security
>    URLLC - Ultra-Reliable and Low Latency Communications
>    OAM - Operations, Administration, and Maintenance
>
> All good, thanks
>
> -->
>
> 25) <!-- [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.
>
> Note that our script did not flag any words in particular, but this should
> still be reviewed as a best practice.
>
> -->
>
> Are you allowed to use 'to flag'?
> I'm pretty careful with the language these days, which is possibly why
> your script finds nothing.
>
> Thank you.
>
> No! Thank you!
>
>