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

[[e-mail]]

Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.


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


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


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


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).
-->


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


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


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


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


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].
-->


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


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


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


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


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


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


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


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


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


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/>.
-->


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


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).  
-->


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


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


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
   network controller vs. Network Controller
   orchestrator vs. Orchestrator
   "Mapping Functions" vs. mapping functions
   "stitched together" vs. 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.


c) FYI - We capitalized a few instances of "IETF network slice" based on the
definition in the abstract.


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


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


Thank you.

RFC Editor/st/rv



On Feb 14, 2024, at 6:58 PM, [e-mail] wrote:

*****IMPORTANT*****

Updated 2024/02/14

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

  *  [e-mail] (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).

  *  [e-mail], 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, 
       [e-mail] 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/rfc9543.xml
  https://www.rfc-editor.org/authors/rfc9543.html
  https://www.rfc-editor.org/authors/rfc9543.pdf
  https://www.rfc-editor.org/authors/rfc9543.txt

Diff file of the text:
  https://www.rfc-editor.org/authors/rfc9543-diff.html
  https://www.rfc-editor.org/authors/rfc9543-rfcdiff.html (side by side)

Alt-diff of the text (allows you to more easily view changes 
where text has been deleted or moved): 
  https://www.rfc-editor.org/authors/rfc9543-alt-diff.html

Diff of the XML: 
  https://www.rfc-editor.org/authors/rfc9543-xmldiff1.html


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
  https://www.rfc-editor.org/auth48/rfc9543

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9543 (draft-ietf-teas-ietf-network-slices-25)

Title            : A Framework for Network Slices in Networks Built from IETF Technologies
Author(s)        : A. Farrel, Ed., J. Drake, Ed., R. Rokui, S. Homma, K. Makhijani, L. Contreras, J. Tantsura
WG Chair(s)      : Oscar Gonzalez de Dios, Vishnu Pavan Beeram, Lou Berger

Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston