Re: [auth48] AUTH48: RFC-to-be 9543 <draft-ietf-teas-ietf-network-slices-25> for your review
Adrian Farrel <adrian@olddog.co.uk> Sat, 17 February 2024 21:19 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E131C14F5EE; Sat, 17 Feb 2024 13:19:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.807
X-Spam-Level:
X-Spam-Status: No, score=-2.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=olddog.co.uk
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frSBjVYdRPfM; Sat, 17 Feb 2024 13:19:38 -0800 (PST)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13E10C14F5EF; Sat, 17 Feb 2024 13:19:35 -0800 (PST)
Received: from vs4.iomartmail.com (vs4.iomartmail.com [10.12.10.122]) by mta7.iomartmail.com (8.14.7/8.14.7) with ESMTP id 41HLJ7lK027634; Sat, 17 Feb 2024 21:19:07 GMT
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C45404604A; Sat, 17 Feb 2024 21:19:06 +0000 (GMT)
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A2CA246043; Sat, 17 Feb 2024 21:19:06 +0000 (GMT)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs4.iomartmail.com (Postfix) with ESMTPS; Sat, 17 Feb 2024 21:19:06 +0000 (GMT)
Received: from LAPTOPK7AS653V ([85.255.233.62]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.7/8.14.7) with ESMTP id 41HLJ3JZ027792 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 17 Feb 2024 21:19:04 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: rfc-editor@rfc-editor.org, je_drake@yahoo.com, rrokui@ciena.com, shunsuke.homma.ietf@gmail.com, kiranm@futurewei.com, luismiguel.contrerasmurillo@telefonica.com, jefftant.ietf@gmail.com
Cc: teas-ads@ietf.org, teas-chairs@ietf.org, vbeeram@juniper.net, jgs@juniper.net, auth48archive@rfc-editor.org
References: <20240215030234.C74EE1F18516@rfcpa.amsl.com>
In-Reply-To: <20240215030234.C74EE1F18516@rfcpa.amsl.com>
Date: Sat, 17 Feb 2024 21:19:04 -0000
Organization: Old Dog Consulting
Message-ID: <0d8601da61e6$f0de8c20$d29ba460$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQI07yEdqkQQRkz/0NaCnAubVifJHrBZ20hw
Content-Language: en-gb
X-Originating-IP: 85.255.233.62
X-Thinkmail-Auth: adrian@olddog.co.uk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding; s= 20221128; bh=2/I5o8MB4iL9lIXw60r2Dd6ywcorIK+L2VWQO7E/tOk=; b=qjr iHVH0jmdZ70eY6ycTG1TtWnwRfwMkhyOuyyW166YNPR2Qm4p0lmkjm0whEy+v/Jt qanUFEHWSb4kaFjP0Sc7E90PZVfHNWOCbk6mSyl76GUJ+b+wk/4xxmVyxgTadNVy ji0scTcAvbQ72sKzBesdu11IY6DwZfa4e7zGiYMKmIE5R1oYs7PNXBN9DfskYzJQ TKFlpsKIh9vMcUaGscoEncz5mb6jZRUCM4DcgGjgPhxRKID337scCRFoaCfF0yKE x2COx3iGeTycUPQLkLkWGP40A5m/phHzMHHBqAVbw+3rn2apjB2kCIgUFaR+Nc0i Dw7cYHb/FuJE6TzCx4A==
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-28198.002
X-TM-AS-Result: No--35.685-10.0-31-10
X-imss-scan-details: No--35.685-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-28198.002
X-TMASE-Result: 10--35.685500-10.000000
X-TMASE-MatchedRID: vvufNx6lgHktjw5zGtj91AgKAWhuC2oj2yRRYb9bsVjtjvycnMT4HXQ4 CU9HBITiLoD4tn9vWJJxdc03m/jJgybZZYAQu9H58Jb881FGn9nataep3h++VPATbqqjZhhy2d8 mtRIRsUMPQevRroCMwFpOuW7XA7hBnPecQ/hKOMBBDn6Fjq77jtMn2YVmYqoxkswibtx8Dje8dU Jl644GKfWCC3csVMWAwT80+l9O/+5Cq8vJMuEXxRIRh9wkXSlFbG5kq/x3d5gwAYdq1VTXo29os yT7YPNK371UTvxX45uy7ec+ITUwMykm5PRe6fZWqLiIn4tHBVxPnKxAOPp4WQrkj7klVufurNPm U6ODWjaHPBjOboNyt39zra8MQqOL4Wpws93aRaeG1fOcPnYTSplbFnOlTWpvRkICFa5gS+RBs1O wil9bHWAQPhBplYgOn1myEDSM+6zNsQYjonsoJGG/OR9TL3/u0NnUUVMlTKYdlueN5rObNdO82l WRIPgztQwJv6nTX8pQbvMnfrTzf1Z8MmR+Mj88zheIfBVh2UcR5c83KIxTTrBm7KRKfr78OFu5p RApemz68qduCW2JnEScp8fzU2ytktLC8CnFmf3ZJrfdkZdZ1p772C5QhryR31GNm6M+JKRnqDvg i8nF5A1RxwBNHJ3UkMczweR24/U6/ds7u+t8TU4Yf9ifkMrF9oDlvpGLeE28/Gbbp+KDL7406k3 go6mn0x2XUSBP88s7VA/0i0WaMiguPXQ1gjj793bduyx/IZwVIGDYnO3neuQydRUvl3QTb4rAnT 6P9PKgDT8CZuHM8BbdaW5MiUrtQLBrHsp/dPNANB89sV0bJ30tCKdnhB581B0Hk1Q1KyLQKyrOt yKkTaelEOEbDOPbrSFs54Y4wbX6C0ePs7A07QKmARN5PTKc
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/toDIm5wQYeB1G2AVj9bPElEf5hM>
Subject: Re: [auth48] AUTH48: RFC-to-be 9543 <draft-ietf-teas-ietf-network-slices-25> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Feb 2024 21:19:43 -0000
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: jari.arkko@piuha.net 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: jari.arkko@piuha.net --> 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!
- [auth48] AUTH48: RFC-to-be 9543 <draft-ietf-teas-… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9543 <draft-ietf-t… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9543 <draft-ietf-t… Shunsuke Homma
- Re: [auth48] AUTH48: RFC-to-be 9543 <draft-ietf-t… Adrian Farrel
- Re: [auth48] AUTH48: RFC-to-be 9543 <draft-ietf-t… Shunsuke Homma
- Re: [auth48] AUTH48: RFC-to-be 9543 <draft-ietf-t… Adrian Farrel
- Re: [auth48] AUTH48: RFC-to-be 9543 <draft-ietf-t… Shunsuke Homma
- [auth48] [*AD] Re: AUTH48: RFC-to-be 9543 <draft-… Sarah Tarrant
- Re: [auth48] [*AD] Re: AUTH48: RFC-to-be 9543 <dr… Adrian Farrel
- Re: [auth48] [*AD] AUTH48: RFC-to-be 9543 <draft-… Sarah Tarrant
- Re: [auth48] [*AD] AUTH48: RFC-to-be 9543 <draft-… Shunsuke Homma
- Re: [auth48] [*AD] AUTH48: RFC-to-be 9543 <draft-… Shunsuke Homma
- Re: [auth48] AUTH48: RFC-to-be 9543 <draft-ietf-t… Sarah Tarrant
- Re: [auth48] AUTH48: RFC-to-be 9543 <draft-ietf-t… Shunsuke Homma
- Re: [auth48] AUTH48: RFC-to-be 9543 <draft-ietf-t… Sarah Tarrant
- Re: [auth48] AUTH48: RFC-to-be 9543 <draft-ietf-t… Jeff Tantsura
- Re: [auth48] AUTH48: RFC-to-be 9543 <draft-ietf-t… John Drake
- Re: [auth48] [**EXTERNAL**] Re: AUTH48: RFC-to-be… Rokui, Reza
- Re: [auth48] AUTH48: RFC-to-be 9543 <draft-ietf-t… Sarah Tarrant
- Re: [auth48] AUTH48: RFC-to-be 9543 <draft-ietf-t… Sarah Tarrant
- Re: [auth48] [**EXTERNAL**] Re: AUTH48: RFC-to-be… Rokui, Reza
- Re: [auth48] [**EXTERNAL**] Re: AUTH48: RFC-to-be… LUIS MIGUEL CONTRERAS MURILLO
- [auth48] [AD]* AUTH48: RFC-to-be 9543 <draft-ietf… Sarah Tarrant
- Re: [auth48] [AD]* AUTH48: RFC-to-be 9543 <draft-… Sarah Tarrant
- Re: [auth48] [AD]* AUTH48: RFC-to-be 9543 <draft-… Adrian Farrel
- Re: [auth48] [AD]* AUTH48: RFC-to-be 9543 <draft-… John Scudder
- Re: [auth48] [AD]* AUTH48: RFC-to-be 9543 <draft-… John Scudder
- Re: [auth48] AUTH48: RFC-to-be 9543 <draft-ietf-t… Sarah Tarrant
- Re: [auth48] AUTH48: RFC-to-be 9543 <draft-ietf-t… Sarah Tarrant