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

[Shunsuke Homma <[e-mail]>]

Dear RFC Editor, coauthors,

Thank you for your reviewing and polishing the draft. Most of your points
seem reasonable to me.

I reflected the proposals on the. draft, excluding (24) Terminology part,
and I attached the modified xml, txt and diff files on this email. My
replies are described in the xml file with [SH] tags.

If other coauthors have different thoughts on the changes, I'd like to
respect his/her proposals.

Please let me know if there are further things which I can contribute.

Best regards,

Shunsuke



On Thu, Feb 15, 2024 at 12:02 PM <[e-mail]> wrote:

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