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 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!
>
>