Hi all, Thank you for the careful edits.
Please see inline. I let my co-authors further comment as needed. Cheers, Med (as author) PS: We will need to update Richard's contact info as he changed affiliation but I don't have yet his new @ address. > -----Message d'origine----- > De : [email protected] <[email protected]> > Envoyé : vendredi 24 octobre 2025 02:03 > À : [email protected]; [email protected]; > [email protected]; BOUCADAIR Mohamed INNOV/NET > <[email protected]>; > [email protected] > Cc : [email protected]; [email protected]; teas- > [email protected]; [email protected]; > [email protected]; [email protected] > Objet : Re: AUTH48: RFC-to-be 9889 <draft-ietf-teas-5g-ns-ip-mpls- > 18> for your review > > Authors, > > While reviewing this document during AUTH48, please resolve (as > necessary) the following questions, which are also in the source > file. > > 1) <!-- [rfced] We updated the abbreviated title (only appears in > the running header in the PDF output) as follows to more closely > align with the document title. Please let us know if you prefer > otherwise. > > Original: > Implementing 5G Transport Slices > > Updated: > Realization of Network Slices for 5G Networks > --> [Med] OK > > > 2) <!-- [rfced] This is a question for Luis. How would you like > for your initials to appear in the first-page header? For now, we > have updated to "L. Contreras" per the format used in the most > recent documents you have authored, but we see that some documents > use "LM. Contreras" in the first-page header. > > L. Contreras - RFCs 9543, 9439, 9013 > LM. Contreras - RFCs 8597, 8568, 8432, 7161, 7028 > --> > > > 3) <!-- [rfced] How may we update these sentences to improve > readability of "5G slicing connectivity service objectives" and > "currently commonly"? > > Original: > This document describes a Network Slice realization model for > IP/MPLS > networks with a focus on the Transport Network fulfilling 5G > slicing > connectivity service objectives. The realization model reuses > many > building blocks currently commonly used in service provider > networks. > > Perhaps: > This document describes a Network Slice realization model for > IP/MPLS > networks with a focus on the Transport Network fulfilling the > connectivity > service objectives for 5G slicing. The realization model > reuses many > building blocks commonly used in service provider networks at > the current time. > --> > [Med] The proposed one works for me. Thanks. > > 4) <!-- [rfced] Section 1 of RFC 9543 notes the following: > > It is intended that the terms "IETF Network Slice" and "IETF > Network > Slice Service" be used only in this document. Other documents > that > need to indicate the type of network slice or network slice > service > described in this document can use the terms "RFC 9543 Network > Slice" > and "RFC 9543 Network Slice Service". > > Based on this, should "IETF Network Slice Service" and "IETF > Network Slice" in the sentences below be updated to "RFC 9543 > Network Slice Service" and "RFC > 9543 Network Slice", respectively? > [Med] Yes, please. > Original: > Mapping > considerations between 3GPP and IETF Network Slice Service > (e.g., > mapping of service parameters) are discussed, e.g., in > [I-D.ietf-teas-5g-network-slice-application]. > ... > Data Confidentiality and Integrity of an IETF Network Slice: > As desc > ribed in Section 5.1.2.1 of [RFC9543], the customer might > request > a Service Level Expectation (SLE) that mandates encryption. > --> > > > 5) <!-- [rfced] We have a few questions about the sentence below > (which is also mentioned in the question above). > > a) How may we revise "Mapping considerations between 3GPP and IETF > Network Slice Service" to improve clarity? > > b) Is the second "e.g." needed? [Med] Yes, this is to highlight that [NS-APP] is just an example of documents where that is discussed. > > Original: > Mapping > considerations between 3GPP and IETF Network Slice Service > (e.g., > mapping of service parameters) are discussed, e.g., in > [I-D.ietf-teas-5g-network-slice-application]. > > Perhaps: > Considerations regarding the mapping between the 5G Network > Slice Service > and RFC 9543 Network Slice Service (e.g., mapping of service > parameters) > are discussed in [NS-APP]. > --> [Med] The OLD is accurate. We may: s/ are discussed, e.g., in/ are discussed in documents such as > > > 6) <!-- [rfced] Figure 4 contains "SW" and "RTR", which are not > used elsewhere in the document. We believe these stand for > "switch" and "router", respectively. > May we update this sentence in one of the following ways to make > this clear? > > Original: > An example of distributed CE is the > realization of an interconnection using a L3VPN service based > on a > distributed CE composed of a switch (Layer 2) and a router > (Layer 3) > (Figure 4). > > Perhaps: > An example of distributed CE is the > realization of an interconnection using an L3VPN service based > on a > distributed CE composed of a switch (SW) in Layer 2 and a > router (RTR) > in Layer 3, as shown in Figure 4. [Med] This one is better. thanks > > Or: > An example of distributed CE is the > realization of an interconnection using an L3VPN service based > on a > distributed CE composed of a switch (Layer 2) and a router > (Layer 3); > see SW and RTR in Figure 4. > --> > > > 7) <!-- [rfced] Are the two instances of "(AC)" needed here? > > Original: > Examples of ACs are Virtual Local Area > Networks (VLANs) (AC) configured on a physical interface > (bearer) or > an Overlay VXLAN EVI (AC) configured on an IP underlay > (bearer). > > Perhaps: > Examples of ACs are Virtual Local Area > Networks (VLANs) configured on a physical interface (bearer) or > an Overlay VXLAN EVI configured on an IP underlay (bearer). [Med] AC mentions are needed. Maybe s/(AC)/AC > --> > > > 8) <!-- [rfced] Is "End-to-End" intended to be part of the > expansion for "5G NSO"? > > Original: > In reference to Figure 6, a 5G End-to-End Network Slice > Orchestrator > (5G NSO) is responsible for orchestrating 5G Network Slices > end-to- > end. [Med] This is accurate. This term is also used to ensure consistency with other docs > > Perhaps: > In Figure 6, a 5G Network Slice Orchestrator > (5G NSO) is responsible for orchestrating 5G Network Slices > end-to- > end. > --> > > > 9) <!-- [rfced] Should "various orchestration" in this sentence be > updated to either "various orchestration domains" or "various > orchestrations"? Also, is "e.g." needed in the sentence? > [Med] Idem for a similar "e.g." comment above. That is to insist this is simply an example where that component can be found. > Original: > The various orchestration depicted in Figure 6 encompass the > 3GPP's > Network Slice Subnet Management Function (NSSMF) mentioned, > e.g., in > Figure 5 of [I-D.ietf-teas-5g-network-slice-application]. > > Perhaps: > The various orchestration domains depicted in Figure 6 > encompass the 3GPP's > Network Slice Subnet Management Function (NSSMF) mentioned in > Figure 5 of [NS-APP]. > > Or: > The various orchestrations depicted in Figure 6 encompass the > 3GPP's > Network Slice Subnet Management Function (NSSMF) mentioned in > Figure 5 of [NS-APP]. [Med] What about NEW: The various orchestrations depicted in Figure 6 encompass the 3GPP's Network Slice Subnet Management Function (NSSMF) mentioned for instance in Figure 5 of [NS-APP]. > --> > > > 10) <!-- [rfced] Will readers understand the ">>" notation here? > We see it defined as "bitwise right shift", "logical right shift", > and "arithmetic right shift of the two's complement integer > representation of M by N binary digits" in various RFCs. > > Original: > In practice, for operational and scaling reasons, typically > M to N > would be used, with M >> N. > --> [Med] This means "much greater than". We can say it explicitly in the text./ > > > 11) <!-- [rfced] Titles of figures > > a) Should "Site" be plural in this title as Figure 3 shows two > sites? > > Original: > Figure 3: Reference Design with Customer Site and Provider > Network > > Perhaps: > Figure 3: Reference Design with Customer Sites and Provider > Network [Med] The proposed one is OK. > > > b) Should the title of Figure 9 use "M" rather than "N"? We ask > because "N to 1" is not included in the list above the figure. The > list only includes > "1 to N", "M to 1", and "M to N". Also, may revise the titles of > Figures 8 and 9 in one of the following ways to improve > readability? > > Original: > Figure 8: 1 (5G Slice) to N (TN Slice) Mapping > Figure 9: N (5G Slice) to 1 (TN Slice) Mapping > > Perhaps: > Figure 8: 1-to-N Mapping > Figure 9: M-to-1 Mapping > > Or: > Figure 8: 1-to-N Mapping (Single 5G Slice to Multiple TN Slices) > Figure 9: M-to-1 Mapping (Multiple 5G Slices to Single TN Slice) [Med] This one is better. > > > c) FYI - We added "Example of" to the title of Figure 16 to align > with the title of Figure 15. > > Original: > Figure 15: Example of MPLS Hand-off with Option B > > Figure 16: MPLS Hand-off with Option C > > Updated: > Figure 15: Example of MPLS Handoff with Option B > > Figure 16: Example of MPLS Handoff with Option C > [Med] ACK > > d) Is "Ingress" correct in the title of Figure 21, or should it be > updated to "Egress"? [Med] Ingress is correct here Also, is "Output" needed? [Med] It is needed as this is about the output of the admission control at ingress We included the > title of Figure 20 below for comparison. > Original: > Figure 20: Ingress Slice Admission Control (5QI-unaware Model) > > Figure 21: Ingress Slice Admission control (5QI-unaware Model) > - Output > > Perhaps: > Figure 20: Ingress Slice Admission Control (5QI-Unaware Model) > > Figure 21: Egress Slice Admission Control (5QI-Unaware Model) > [Med] I don't think a change is needed. > > e) FYI - We included "Model" to the parenthetical in these figure > titles. > > Original: > Figure 25: Ingress Slice Admission Control (5QI-Aware) - > Hierarchical > > Figure 26: Egress Slice Admission Control (5QI-Aware) > > Perhaps: > Figure 25: Ingress Slice Admission Control (5QI-Aware Model) - > Hierarchical > > Figure 26: Egress Slice Admission Control (5QI-Aware Model) > [Med] OK > > f) We revised the figure titles below as follows to avoid awkward > hyphenation with "Mapping". For Figure 28, we also removed "PEs" > for consistency with the title of Figure 29. > > For the title of Figure 17, should "Slice" be updated to "Network > Slice", or is the current okay? > > Original: > Figure 17: Slice to TN QoS Mapping (5QI-Unaware Model) > Figure 22: Slice 5Q QoS to TN QoS Mapping (5QI-Aware Model) > Figure 28: Network Slice to PEs Underlay Transport Mapping (5QI- > Unaware Model) > Figure 29: Network Slice to Underlay Transport Mapping (5QI- > Aware Model) > > Updated: > Figure 17: Mapping of Slice to TN QoS (5QI-Unaware Model) > Figure 22: Mapping of Slice 5Q QoS to TN QoS (5QI-Aware Model) > Figure 28: Mapping of Network Slice to Underlay Transport (5QI- > Unaware Model) > Figure 29: Mapping of Network Slice to Underlay Transport (5QI- > Aware Model) [Med] ACK > --> > > > 12) <!-- [rfced] Is "to instruct" the correct word choice here? Or > would "to determine" or something else be an improvement? > > Original: > TN slice mapping policies can be enforced by an operator (e.g., > provided to a TN Orchestration or 5G NSO) to instruct whether > existing TN slices can be reused for handling a new slice > service > creation request. > > Perhaps: > TN slice mapping policies can be enforced by an operator (e.g., > provided to a TN Orchestration or 5G NSO) to determine whether > existing TN slices can be reused for handling a new slice > service > creation request. [Med] WFM. Thanks. > --> > > > 13) <!-- [rfced] This sentence may be difficult for readers to > follow because of the many "to.." phrases. How may we update? > > Original: > The methods used here can range from careful network > planning, to > ensure a more or less equal traffic distribution (i.e., > equal cost > load balancing), to advanced TE techniques, with or without > bandwidth reservations, to force more consistent load > distribution > even in non-ECMP friendly network topologies. > > Perhaps: > The methods used here can range from careful network > planning that > ensures a more or less equal traffic distribution (i.e., > equal-cost > load balancing) to advanced TE techniques, with or without > bandwidth reservations, that force more consistent load > distribution, > even in non-ECMP-friendly network topologies. > --> [Med] This is better. Thanks./ > > > 14) <!-- [rfced] We do not see "F2" used elsewhere in the > document. Will readers understand what this refers to? > > Original: > Since the 5G > interfaces are IP-based interfaces (with an exception of the F2 > fronthaul-interface, where eCPRI with Ethernet encapsulation is > used), this VLAN is typically not transported across the > provider > network. > --> [Med] That's a well known RAN interface. > > > 15) <!-- [rfced] Please confirm that "compute" (noun) is the > correct word choice here. [Med] I ocnfirm. > > Original: > These L3VPN service instances are instantiated in > the customer site which could be, for example, either on the > compute > that hosts mobile NFs (Figure 15, left-hand side) or within the > DC/ > cloud infrastructure itself (e.g., on the top of the rack or > leaf > switch within cloud IP fabric (Figure 15, right-hand side)). > --> > > > 16) <!-- [rfced] Should "COM-1" here be updated to "COM=1" to > match the usage in Figure 15? [Med] Good catch. > > Original: > For example, in Figure 15, for the slice identified with > COM-1, the PE advertises a dynamically allocated label A". > > Perhaps: > For example, in Figure 15, for the slice identified with > COM=1, the PE advertises a dynamically allocated label A". [Med] OK. > --> > > > 17) <!--[rfced] Please clarify "label swap forwarding entries" in > this sentence. > > Original: > Appropriate label swap forwarding entries > for IPv4/IPv6 labeled unicast labels are programmed in the data > plane. > > Perhaps: > Appropriate label swaps of forwarding entries > for IPv4/IPv6 labeled unicast labels are programmed in the data > plane. > > Or: > Appropriate forwarding entries for label swaps > for IPv4/IPv6 labeled unicast labels are programmed in the data > plane. [Med] This one is better. > --> > > > 18) <!-- [rfced] How does the text starting with "used as > NEXT_HOP..." connect to the rest of the sentence? > > Original: > This significantly lowers the scaling pressure on > PEs, as PEs need to program forwarding entries only for > IPv4/IPv6 > labeled unicast host routes, used as NEXT_HOP for service > prefixes. > > Perhaps: > This significantly lowers the scaling pressure on > PEs, as PEs need to program forwarding entries only for > IPv4/IPv6 > labeled unicast host routes, which are used as NEXT_HOP for > service prefixes. [Med] OK > --> > > > 19) <!-- [rfced] The sentence below uses "SRv6 encapsulation" > while the title of Figure 19 uses "IPv6 Encapsulation". Should > these be consistent? [Med] SRv6 is an IPv6 encap, but agree we need to be consistent here. Can update the figure to use SRv6. Thanks If so, which form should be used? > > Original: > This model is outlined in Figure 18 for MPLS > encapsulation, and in Figure 19 for SRv6 encapsulation. > ... > Figure 19: QoS with IPv6 Encapsulation > --> > > > 20) <!-- [rfced] Is the citation [I-D.ietf-teas-ietf-network- > slice-nbi-yang] > correct here? We ask because we do not see "slice rate", "CIR", or > "PIR" > in that document. > > Link to document: > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > datatracker.ietf.org%2Fdoc%2Fdraft-ietf-teas-ietf-network-slice- > nbi- > yang%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cbdee292e79 > 1a47780b3808de12919ff3%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0% > 7C638968614111720449%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd > WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ% > 3D%3D%7C0%7C%7C%7C&sdata=6QEFo1%2FRuaxdWJCqJ4gUZVGxUxM8E8YtYmoUbol > QiFM%3D&reserved=0 > > Original: > The slice rates can be characterized with following parameters > [I-D.ietf-teas-ietf-network-slice-nbi-yang]: > > * CIR: Committed Information Rate (i.e., guaranteed bandwidth) > > * PIR: Peak Information Rate (i.e., maximum bandwidth) > --> [Med] I ocnfirm. Please see | +--rw incoming-qos-policy | | +--rw qos-policy-name? string | | +--rw rate-limits <============================== | | +--rw cir? uint64 <======================= | | +--rw cbs? uint64 | | +--rw eir? uint64 | | +--rw ebs? uint64 | | +--rw pir? uint64 <======================= | | +--rw pbs? uint64 | | +--rw classes | | +--rw cos* [cos-id] | | +--rw cos-id uint8 | | +--rw cir? uint64 | | +--rw cbs? uint64 | | +--rw eir? uint64 | | +--rw ebs? uint64 | | +--rw pir? uint64 | | +--rw pbs? uint64 > > > 21) <!-- [rfced] Please confirm that Section 2.3 of [RFC2475] is > correct here. We do not see "1r2c", "color", or "single rate" in > [RFC2475]. > > Original: > * 1r2c (single-rate two-color) rate limiter > > This is the most basic rate limiter, described in Section > 2.3 of > [RFC2475]. > --> [Med] There is no RFC that uses 1r2c per se, but basic are defined in that Section. I let my coauthor further comment on this as appropriate. > > > 22) <!-- [rfced] We updated "provider" to "provider network" in > the parenthetical in this sentence. Let us know if this is > incorrect. > > Original: > Inbound provider network edge enforcement model for 5QI-unaware > model, where all packets belonging to the slice are treated the > same > way in the provider network (no 5Q QoS Class differentiation in > the > provider) is outlined in Figure 20. > > Perhaps: > Inbound provider network edge enforcement for the 5QI-unaware > model, where all packets belonging to the slice are treated the > same > way in the provider network (no 5Q QoS Class differentiation in > the > provider network), is outlined in Figure 20. > --> [Med] OK > > > 23) <!-- [rfced] Please clarify "most commonly up 4 or 8 traffic > classes". > (Also, we suggest removing "granular" as it's redundant with > "fine-grained".) > > Original: > In the 5QI-aware model, compared to the 5QI-unaware model, > provider > network edge resources are controlled in an even more granular, > fine- > grained manner, with dedicated resource allocation for each RFC > 9543 > Network Slice and dedicated resource allocation for number of > traffic > classes (most commonly up 4 or 8 traffic classes, depending on > the > Hardware capability of the equipment) within each RFC 9543 > Network > Slice. > > Perhaps: > In the 5QI-aware model, compared to the 5QI-unaware model, > provider > network edge resources are controlled in an even more fine- > grained > manner, with dedicated resource allocation for each RFC 9543 > Network Slice and for a number of traffic > classes (most commonly, 4 or 8 traffic classes, depending on > the > hardware capability of the equipment) within each RFC 9543 > Network > Slice. > > Or: > In the 5QI-aware model, compared to the 5QI-unaware model, > provider > network edge resources are controlled in an even more fine- > grained > manner, with dedicated resource allocation for each RFC 9543 > Network Slice and for a number of traffic > classes (most commonly, up to 4 or 8 traffic classes, depending > on the > hardware capability of the equipment) within each RFC 9543 > Network > Slice. > --> [Med] I like the second one. > > > 24) <!-- [rfced] May we update "2024" as follows in these > sentences? > > Original: > However, such an approach is left out of the scope given the > current > state of the technology (2024). > ... > it is not necessary (or indeed possible for > current SR-TE technology in 2024) to reserve bandwidth at the > network > layer. > > Perhaps: > However, such an approach is out of the scope given the current > state of the technology at the time of writing this document. > ... > it is not necessary (or indeed possible for > current SR-TE technology at the time of writing this document) > to reserve > bandwidth at the network layer. [Med] ACK. > --> > > > 25) <!-- [rfced] We updated "[I-D.ietf-teas-ietf-network-slice- > nbi-yang]" in these sentences to "the YANG data model defined in > [NSSM]" for clarity. Let us know any concerns. > > Original: > [I-D.ietf-teas-ietf-network-slice-nbi-yang] can be used to > convey all > of the information in the traffic matrix to an NSC. > ... > ...could be used instead of > [I-D.ietf-teas-ietf-network-slice-nbi-yang], as they support > conveying the bandwidth information in the right-most column of > the > traffic matrix. > ... > The 5G NSO can > use [I-D.ietf-teas-ietf-network-slice-nbi-yang] to request low- > latency transport for a given slice if required. > ... > For example, > [I-D.ietf-teas-ietf-network-slice-nbi-yang] exposes a set of > statistics per SDP, connectivity construct, and connection > group. > > Updated: > The YANG data model defined in [NSSM] can be used to convey all > of > the information in the traffic matrix to an NSC. > ... > ...could be used instead of the YANG > data model defined in [NSSM], as they support conveying the > bandwidth > information in the right-most column of the traffic matrix. > ... > The 5G NSO can > use the YANG data model defined in [NSSM] to request low- > latency > transport for a given slice if required. > ... > For example, the YANG data model defined > in [NSSM] exposes a set of statistics per SDP, connectivity > construct, and connection group. > --> [Med] OK > > > 26) <!-- [rfced] Please confirm that "the paths of one or more > paths" is correct here. > > Original: > In this > approach, when the actual traffic volume in the data plane on > given > link exceeds a threshold, the controller, knowing how much > actual > data plane traffic is currently traveling along each RSVP or > SR-TE > path, can tune the paths of one or more paths using the link > such > that they avoid that link. This approach is similar to that > described in Section 4.3.1 of [RFC9522]. > > Perhaps: > In this > approach, when the actual traffic volume in the data plane on > given > link exceeds a threshold, the controller, knowing how much > actual > data plane traffic is currently traveling along each RSVP or > SR-TE > path, can tune one or more paths using the link such > that they avoid that link. This approach is similar to that > described in Section 4.3.1 of [RFC9522]. [Med] WFM. I let Julin further comment as needed. > --> > > > 27) <!-- [rfced] FYI - We updated this sentence as follows. Let us > know any concerns. > > Original: > For example, [RFC9375] can be used to report links' one-way > delay, > one-way delay variation, etc. > > Perhaps: > For example, the YANG data model in [RFC9375] can be used to > report > the one-way delay and one-way delay variation of links. > --> > [Med] ACK > > 28) <!-- [rfced] The top-level bullets in the list in Section 8 > are all complete sentences except for the items below. How may we > revise these to create complete sentences? > > Original: > * Means to report a set of network performance metrics to > assess > whether the agreed slice service objectives are honored. > ... > * Means to report and expose observed performance metrics and > other > OAM state to customer. > > Perhaps: > * Providers should provide the means to report a set of > network > performance metrics to assess whether the agreed slice > service objectives are honored. > ... > * Providers should have the means to report and expose > observed performance > metrics and other OAM state to customer. > --> > [Med] Agree, for consistency. > > 29) <!-- [rfced] The last two sentences mention 1-to-1 mapping and > N-to-1 mapping, but these are not listed in Section 3.5 (which > only lists 1 to N, M to 1, and M to N). Please review and let us > know if any updates are needed. (The first two sentences are > included for context.) > > Original: > The mapping between 5G slice to TN slices (see Section 3.5) is > a > design choice of service operators that may be a function of, > e.g., > the number of instantiated slices, requested services, or local > engineering capabilities and guidelines. However, operators > should > carefully consider means to ease slice migration strategies. > For > example, a provider may initially adopt a 1-to-1 mapping if it > has to > instantiate just a few Network Slices and accommodate the need > of > only a few customers. That provider may decide to move to an > N-to-1 > mapping for aggregation/scalability purposes if sustained > increased > slice demand is observed. > --> [Med] 1-to-1 is correct as that is when M=1. No change is needed for that one. We can s/N-to-1/M-to-1 for consistency. > > > 30) <!-- [rfced] FYI, we updated the title for this reference to > match the title at the URL. Please let us know if you prefer > otherwise. [Med] OK. Thanks/ > > Original: > [Book-5G] Peterson, L., Sunay, O., and B. Davie, "5G Mobile > Networks: A Systems Approach", 2022, > > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > F5g.systemsapproach.org%2F&data=05%7C02%7Cmohamed.boucadair%40oran > ge.com%7Cbdee292e791a47780b3808de12919ff3%7C90c7a20af34b40bfbc48b9 > 253b6f5d20%7C0%7C0%7C638968614111746835%7CUnknown%7CTWFpbGZsb3d8ey > JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2vt1KkaQdmgAQvCvAUqafN > 9LIRYDS0LZyjSzZUD0NhE%3D&reserved=0>. > > Current: > [Book-5G] Peterson, L., Sunay, O., and B. Davie, "Private 5G: > A > Systems Approach", 2023, > > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > F5g.systemsapproach.org%2F&data=05%7C02%7Cmohamed.boucadair%40oran > ge.com%7Cbdee292e791a47780b3808de12919ff3%7C90c7a20af34b40bfbc48b9 > 253b6f5d20%7C0%7C0%7C638968614111761091%7CUnknown%7CTWFpbGZsb3d8ey > JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FTiPN6gray5gJP%2FoxcB2 > dvaiqIkzgJLwnMmgGTQeJ%2B0%3D&reserved=0>. > --> > > > 31) <!-- [rfced] Would it be helpful to point to specific versions > of [TS-23.501] and [TS-28.530]? The original date for both > references was 2024, but there are multiple versions across > multiple releases from that year, and both also have new 2025 > versions. > > Note that specific sections and figures in [TS-28.530] are > mentioned in the text. We are not sure if these will be stable > across versions. [Med] These are stable. We can use the latest version. > > Current: > [TS-23.501] > 3GPP, "System architecture for the 5G System (5GS)", > 3GPP > TS 23.501, > > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fportal.3gpp.org%2Fdesktopmodules%2FSpecifications%2F&data=05%7C02 > %7Cmohamed.boucadair%40orange.com%7Cbdee292e791a47780b3808de12919f > f3%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638968614111774898 > %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwM > CIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s > data=S4974p94h%2FSUJddE8seGot%2B01k81IUbE3HNX3dY96A8%3D&reserved=0 > SpecificationDetails.aspx?specificationId=3144>. > ... > > [TS-28.530] > 3GPP, "Management and orchestration; Concepts, use > cases > and requirements", 3GPP TS 28.530, > > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fportal.3gpp.org%2Fdesktopmodules%2FSpecifications%2F&data=05%7C02 > %7Cmohamed.boucadair%40orange.com%7Cbdee292e791a47780b3808de12919f > f3%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638968614111789256 > %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwM > CIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s > data=0pB3%2FfLqJux%2Bk6Ga9wnLs5hFrPKSAN1VMtnSdwf%2BriQ%3D&reserved > =0 > SpecificationDetails.aspx?specificationId=3273>. > --> > > > 32) <!-- [rfced] The current URL for this reference > (https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.o- > ran.org%2Fspecifications&data=05%7C02%7Cmohamed.boucadair%40orange > .com%7Cbdee292e791a47780b3808de12919ff3%7C90c7a20af34b40bfbc48b925 > 3b6f5d20%7C0%7C0%7C638968614111802916%7CUnknown%7CTWFpbGZsb3d8eyJF > bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW > FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=k6rrGZv2X6%2Fkj96YzGOcpy > xwwNzMYAfAsFxJM%2BJtyuw%3D&reserved=0) goes to a page titled "O- > RAN Specifications". We were able to find a list of O-RAN > specifications here: > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > specifications.o- > ran.org%2Fspecifications&data=05%7C02%7Cmohamed.boucadair%40orange > .com%7Cbdee292e791a47780b3808de12919ff3%7C90c7a20af34b40bfbc48b925 > 3b6f5d20%7C0%7C0%7C638968614111816661%7CUnknown%7CTWFpbGZsb3d8eyJF > bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW > FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ANRkUOKc0zSE1yWl%2BVf9mr > FHfSx8QcXuskdnad2NfAA%3D&reserved=0. > > We were unable to find Version 04.00 of the O-RAN specification. > It appears that this page only has the most recent version - > Version > 08.00 - published in June 2024. May we update this reference > accordingly to point to this version? [Med] Yes, please. > > Original: > [O-RAN.WG9.XPSAAS] > O-RAN Alliance, "O-RAN.WG9.XPSAAS: O-RAN WG9 Xhaul > Packet > Switched Architectures and Solutions Version 04.00", > March > 2023, > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.o- > ran.org%2Fspecifications&data=05%7C02%7Cmohamed.boucadair%40orange > .com%7Cbdee292e791a47780b3808de12919ff3%7C90c7a20af34b40bfbc48b925 > 3b6f5d20%7C0%7C0%7C638968614111831186%7CUnknown%7CTWFpbGZsb3d8eyJF > bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW > FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ohScqBntKHF%2FTbjUQL4jmQ > CRoTM71JYrWSNswutf%2BC4%3D&reserved=0>. > > Perhaps: > [O-RAN.WG9.XPSAAS] > O-RAN Alliance, "Xhaul Packet Switched Architectures > and > Solutions", O-RAN.WG9.XPSAAS, Version 08.00, June > 2024, > > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fspecifications.o- > ran.org%2Fspecifications&data=05%7C02%7Cmohamed.boucadair%40orange > .com%7Cbdee292e791a47780b3808de12919ff3%7C90c7a20af34b40bfbc48b925 > 3b6f5d20%7C0%7C0%7C638968614111844409%7CUnknown%7CTWFpbGZsb3d8eyJF > bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW > FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=iLAFI3%2FZKvMqovzIytRabR > lE%2B%2BgV6BDi8BKF61egAd0%3D&reserved=0>. > --> > > > 33) <!-- [rfced] Will readers understand what "the above approach" > is in this sentence? Does this refer to the approach described in > Section 4.2 or in this document in general? > > Original: > Different IPv6 address allocation schemes following the above > approach may be used, with one example allocation shown in > Figure 31. > > Perhaps: > Different IPv6 address allocation schemes following the > approach in this document may be used, with one example > allocation shown > in Figure 31. > > Or: > Different IPv6 address allocation schemes following the > approach in Section 4.2 may be used, with one example > allocation shown > in Figure 31. [Med] This one is better. > --> > > > 34) <!-- [rfced] We see some differences in the terms below in > text in Appendix A and Figure 32. Please review and let us know if > updates are needed. > > 2001:db8:b:0::/96 [Med] Please change this one to 2001:db8:b::/96 > 2001:db8:b::/96 > > 2001:db8:a:0::/96 [Med] Please change this one to 2001:db8:a::/96 > 2001:db8:a::/96 > > SST-01 > SST=1 [Med] We can use SST=1 > > SST-03 > SST=3 [Med] SST=3 > --> > > > 35) <!-- [rfced] Abbreviations. (To view the updates to this > section, which was moved to Section 2.2, we suggest using the > alternative diff file: > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9889-alt- > diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cbdee292e > 791a47780b3808de12919ff3%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > 0%7C638968614111857703%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > Q%3D%3D%7C0%7C%7C%7C&sdata=ZtRL0Of3lJ8n4NqIRVAScs2Q4oP5Ua5SHUQneSa > iBsg%3D&reserved=0) > [Med] OK > a) FYI, we updated the expansion of GPRS to use "General" rather > than "Generic". > > Original: > Generic Packet Radio Service > > Updated: > General Packet Radio Service > [Med] Thanks. This is indeed what is used by 3GPP > > b) FYI, this entry appeared in the original, but it was not used > elsewhere in the document, so it has been removed. > > UE: User Equipment > [Med] Please delete it. > > c) The abbreviation "DM" appears in Figure 7 but not elsewhere in > the document. Will readers know this abbreviation (perhaps "data > model")? May we add the expansion to the list of abbreviations in > Section 2.2? [Med] We can add Data Model (DM) as legend to the figure. > > > d) "AMF" appears in Figure 8 but not elsewhere in the document. > How should this be expanded? [Med] We can mention "Access & Mobility Management Function (AMF)" as a legend to the figure > > > e) Will readers understand "LxVPN"? It only appears once in the > document. May we update for clarity as follows? > > Original: > The correlation between an LxVPN instance > and a Network Slice Service is maintained using "parent- > service- > id" attribute (Section 7.3 of [RFC9182]). > > Perhaps: > The correlation between an L3VPN/L2VPN instance > and a Network Slice Service is maintained using "parent- > service- > id" attribute (Section 7.3 of [RFC9182]). > [Med] OK > > f) FYI, we have added expansions for the following abbreviations > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review > each expansion in the document carefully to ensure correctness. > > MACsec: Media Access Control Security > MNO: Mobile Network Operator > --> [Med] OK > > > 36) <!-- [rfced] Terminology > > a) "DC1" and "DC2" (no space) are used in the text in Section 7, > but "DC 1" and "DC 2" (with space) are used in Figure 30 and > Tables 1 and 2. Should these be consistent? If so, let us know > which form is preferred. [Med] We can use "DC 1" and "DC 2". > > > b) Please review the names of domains and let us know if any > updates are needed for consistency. Some examples: > > Provider Orchestration Domain (Figure 3) > provider orchestration domain > Provider Network Orchestration domain [Med] I suggest we mention Provider Network Orchestration Domain (simply referred to as Provider Orchestration Domain). And then use "Provider Orchestration Domain". > > Customer Orchestration Domain (Figure 3) > Customer Site Orchestration domain > [Med] Customer Site Orchestration Domain (simply referred to as Customer Orchestration Domain). > 3GPP orchestration domain [Med] Can change that occurrences to "3GPP orchestration" > 3GPP domains Orchestration (Figure 6) [Med] We can keep this one. > > provider and customer TN domains > customer and provider orchestration domains [Med] We can keep both > > > c) We note capitalization inconsistencies in the terms below > throughout the text. Should these be uniform? If so, please let us > know which form is preferred. > > transport network > Transport Network [Med] I suggest to use "Transport Network" > > mobile network > Mobile Network [Med] We can use Mobile Network > > > d) We see a few instances of "5Q QoS". Should these be updated to > "5G QoS"? [Med] Yes, please. > > > e) Should "Slice Services" (uppercase) in these sentences be > updated to "slice services" (lowercase)? It seems that "slice > service" is lowercase in general text and capitalized in the terms > "Network Slice Service" and "5G Slice Service". [Med] Only capitlize in these terms. > > Original: > The objective of Transport Network Slicing is to isolate, > guarantee, > or prioritize Transport Network resources for Slice Services. > ... > Putting in place adequate automation means to realize Network > Slices > (including the adjustment of Slice Services to Network Slices > mapping) would ease slice migration operations. > > > f) Should "slice" be lowercase or uppercase in these contexts? > > Transport Network Slice > TN slice [Med] We can use Transport Network Slice > > 5G Network Slice > 5G slice [Med] We can use 5G Network Slice > > > g) In general text, we see both "Network Slice" (uppercase) and > "network slice" (lowercase). We suggest using the lowercase form > when used on its own (the capitalized form is used consistently in > the terms "RFC 9543 Network Slice", "Network Slice Service", and > "5G Network Slice"). [Med] Agree. This seems to follow the usage in RFC 9543. > Let us know your thoughts. Some examples are below. > > Examples of uppercase "Network Slice": > A TN slice might be considered as a variant of horizontal > composition > of Network Slices mentioned in Appendix A.6 of [RFC9543]. > ... > The use of VPNs for realizing Network Slices is briefly > described > in Appendix A.4 of [RFC9543]. > > Examples of lowercase "network slice": > The document is not > intended to be a BCP and does not claim to specify mandatory > mechanisms to realize network slices. > ... > * Providers may want to enable differentiated failure detect > and > repair features for a subset of network slices. > --> > > > 37) <!-- [rfced] Please review the "Inclusive Language" portion of > the online Style Guide > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.rfc- > editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C > 02%7Cmohamed.boucadair%40orange.com%7Cbdee292e791a47780b3808de1291 > 9ff3%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6389686141118709 > 24%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > &sdata=WylpPfQ%2FlTppZbn6L0BHYVVhLTT0ADOqHPhe48s4w94%3D&reserved=0 > > > and let us know if any changes are needed. Updates of this nature > typically result in more precise language, which is helpful for > readers. > > Note that our script did not flag any words in particular, but > this should still be reviewed as a best practice. [Med] None from our side as well. We > --> > > > 38) <!-- [rfced] We made the following changes regarding the > <aside> element. > The <aside> element is defined as "a container for content that is > semantically less important or tangential to the content that > surrounds it" > (https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fauthors.ietf.org%2Fen%2Frfcxml- > vocabulary%23aside&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 > Cbdee292e791a47780b3808de12919ff3%7C90c7a20af34b40bfbc48b9253b6f5d > 20%7C0%7C0%7C638968614111884374%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=pFORth2IAr2DVlxLkY8WA7%2BMvPAK > SZhv%2F%2Fmhg1YHZQo%3D&reserved=0). > > a) We placed the following note in Section 5.2.2 in the <aside> > element. > > Original: > Note: The numbers indicated in Figure 23 (S-NSSAI, 5QI, DSCP, > queue, > etc.) are provided for illustration purposes only and should > not > be considered as deployment guidance. > > Updated: > | Note: The numbers indicated in Figure 23 (S-NSSAI, 5QI, > DSCP, > | queue, etc.) are provided for illustration purposes only > and > | should not be considered as deployment guidance. > > > b) The following text in Section 3.3.5 appears in the <aside> > element. We added "Note:". > > Original: > | In order to keep the figures simple, only one AC and > single- > | homed CEs are represented. Also, the underlying bearers > are > | not represented in most of the figures. However, this > document > | does not exclude the instantiation of multiple ACs > between a CE > | and a PE nor the presence of CEs that are attached to > more than > | one PE. > > Updated: > | Note: In order to keep the figures simple, only one AC > and single- > | homed CEs are represented. Also, the underlying bearers > are > | not represented in most of the figures. However, this > document > | does not exclude the instantiation of multiple ACs > between a CE > | and a PE nor the presence of CEs that are attached to > more than > | one PE. > --> [Med] WFM > > > 39) <!-- [rfced] Please review all the SVG figures in the HTML/PDF > outputs to ensure that they convey the same information as the > ascii-art in the TXT output. We have included some notes below > about particular figures. > If changes are needed, please either update the SVG in the XML > file directly or provide updated SVG for the affected figure(s). > [Med] Will double check those and will come back to you if any issue is found. > a) Note that "===" appears as a solid double line in the SVG in > the HTML and PDF outputs. Are any updates needed for this sentence > in Section 3.3.5? > > Original: > For example, > the bearer is illustrated with "===" in Figures 4 and 5. > > > b) Figure 4: Do the boxes labeled "SW" and "PE" appear correctly > in the SVG? > > > c) Figure 5: Do the boxes labeled "CE", "Mngd CE", and "DC GW" > appear correctly in the SVG? > > > d) Figures 12, 15, and 16: > > - In the SVG, the lines do not extend all the way to the boxes > labeled "PE". > > - The "+" signs that appear in the ascii-art do not appear in the > SVG. Note that Figure 12 has a legend that includes "+", but "+" > does not appear in the SVG. > > - Figure 12: Please consider changing each asterisk to a different > character and running aasvg again to get new SVG. It seems "+*" > together does not appear as you intended in the SVG. Please see > issue #20 for aasvg > (https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fgithub.com%2Fmartinthomson%2Faasvg%2Fissues%2F20&data=05%7C02%7Cm > ohamed.boucadair%40orange.com%7Cbdee292e791a47780b3808de12919ff3%7 > C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638968614111897834%7CU > nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI > lAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata > =VIMPoNQ2huSGOpNo9SJfuDiMGcU4EVnSh7wpEfjNW4Q%3D&reserved=0) where > using a Unicode character is a suggested workaround. > > > e) Figure 23: > > - The boxes in the SVG that contain "5QI=", "DSCP=", and "TN QoS > Class" are not closed in the SVG. Will these be confusing for > readers? > > - In the "NF-A" box, a pipe character is spaced over. We can fix > it in the ascii-art, but we are unable to fix it in the SVG. > > > f) Figures 24 and 25: > > - Do the boxes for Slice 1, Slice 2, and Slice 3 look okay in the > SVG? They are missing some corners. > > - Do the boxes under "Slice Policer" in Figure 25 look as expected > in the SVG? > > > g) Figure 26: > > - The bottom right of the figure looks off, i.e., "/|\" in the txt > output. Should it be moved over one space to the left? We can fix > this in the ascii-art if needed, but we are unable to fix the SVG. > > - The "..." in the txt output does not seem to be reflected in the > SVG output. There is a solid line with ".." in the SVG. > > > h) Figure 27: Does the ">>" in the ascii-art appear as expected in > the SVG? > > > i) Figure 30: The filled-in dot in the SVG overlaps letters in the > PE boxes. > This should be updated. Please see the note above regarding Figure > 12 for more information, assuming this SVG was created using > aasvg. > > j) Figure 32: > > - Does the arrow "v" above the "^" above "MIot (SST=3)" look as > expected in the SVG? > > - Do the PE and NF boxes look okay in the SVG? > --> > > > Thank you. > > Rebecca VanRheenen and Alice Russo > RFC Production Center > > On Oct 23, 2025, [email protected] wrote: > > *****IMPORTANT***** > > Updated 2025/10/23 > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.rfc- > editor.org%2Ffaq%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com% > 7Cbdee292e791a47780b3808de12919ff3%7C90c7a20af34b40bfbc48b9253b6f5 > d20%7C0%7C0%7C638968614111911056%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e > U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI > sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lL8K5iw8Q3hCD9RS6HAImIrj%2BbJ > AJ2TYjV2w75%2FlvNE%3D&reserved=0). > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > trustee.ietf.org%2Flicense- > info&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cbdee292e791a4 > 7780b3808de12919ff3%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6 > 38968614111924031%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > 3D%7C0%7C%7C%7C&sdata=FrBCrg8WZ7HrJyJNr6fZNlwvDo5VL3kf3lnlCLAoE%2B > 4%3D&reserved=0). > > * 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fauthors.ietf.org%2Frfcxml- > vocabulary&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cbdee292 > e791a47780b3808de12919ff3%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C638968614111937496%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=1Lozca3Bd7dBd6mdjlQ6by%2FmmCuxINavAihL > b7QMQGI%3D&reserved=0>. > > * 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 > > * [email protected] (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). > > * [email protected], which is a new archival mailing > list > to preserve AUTH48 conversations; it is not an active > discussion > list: > > * More info: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > mailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh- > 4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 > Cbdee292e791a47780b3808de12919ff3%7C90c7a20af34b40bfbc48b9253b6f5d > 20%7C0%7C0%7C638968614111950660%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MhCYdXDTMOzsLr2t1cRgqKL%2Fp7JL > pmOtx1J%2BZZHzEpg%3D&reserved=0 > > * The archive itself: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > mailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C > 02%7Cmohamed.boucadair%40orange.com%7Cbdee292e791a47780b3808de1291 > 9ff3%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6389686141119639 > 36%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > &sdata=ZS84Hm4KKcKpLWzL09r79GAyTCq7RNUqw3QJY9ThTv4%3D&reserved=0 > > * 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, > [email protected] 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9889.xml&data=05%7C02%7Cmohamed.boucadai > r%40orange.com%7Cbdee292e791a47780b3808de12919ff3%7C90c7a20af34b40 > bfbc48b9253b6f5d20%7C0%7C0%7C638968614111978462%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ybiv30L5%2F6ht > ANfiOiVR1TXbGFmwJkIH%2FXcmdxU9zc8%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9889.html&data=05%7C02%7Cmohamed.boucada > ir%40orange.com%7Cbdee292e791a47780b3808de12919ff3%7C90c7a20af34b4 > 0bfbc48b9253b6f5d20%7C0%7C0%7C638968614111992109%7CUnknown%7CTWFpb > GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI > sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=uvfl5OQ3dJCmS > iOMiD517rrtCxvqRpTs0WSKWsFvyug%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9889.pdf&data=05%7C02%7Cmohamed.boucadai > r%40orange.com%7Cbdee292e791a47780b3808de12919ff3%7C90c7a20af34b40 > bfbc48b9253b6f5d20%7C0%7C0%7C638968614112005532%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ax%2F9J3IzvLat > Kmu6GoYo3XBqm64XyPzH30Ja%2BWXI1bY%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9889.txt&data=05%7C02%7Cmohamed.boucadai > r%40orange.com%7Cbdee292e791a47780b3808de12919ff3%7C90c7a20af34b40 > bfbc48b9253b6f5d20%7C0%7C0%7C638968614112018881%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=8y192N8m3caKhr > X9lqFPQDKqvdOzn729Nuush80oEa4%3D&reserved=0 > > Diff file of the text: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9889- > diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cbdee292e > 791a47780b3808de12919ff3%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > 0%7C638968614112032279%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > Q%3D%3D%7C0%7C%7C%7C&sdata=qyTNU5zp39YnNOGoh5o4d4eUiMHNtgNAUmeUfmk > mpA4%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9889- > rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cbdee2 > 92e791a47780b3808de12919ff3%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0 > %7C0%7C638968614112045556%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki > OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj > oyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2BzZCblMl0RW6txeRUf%2B3e6kek3Z9z43S > 6rLClHUVzaY%3D&reserved=0 (side by side) > > Diff of the XML: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9889- > xmldiff1.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cbdee > 292e791a47780b3808de12919ff3%7C90c7a20af34b40bfbc48b9253b6f5d20%7C > 0%7C0%7C638968614112059002%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk > iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI > joyfQ%3D%3D%7C0%7C%7C%7C&sdata=Vv%2FRQUI5CbMCTq1yKVh%2Bw8WUeDL3gCU > B18zgwDSb%2BBQ%3D&reserved=0 > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauth48%2Frfc9889&data=05%7C02%7Cmohamed.boucadair%40o > range.com%7Cbdee292e791a47780b3808de12919ff3%7C90c7a20af34b40bfbc4 > 8b9253b6f5d20%7C0%7C0%7C638968614112072264%7CUnknown%7CTWFpbGZsb3d > 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI > joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fenbh%2BMcr9z3u%2Bv > eacFYKtRKVnCeHumYEt1a%2FPrjLzc%3D&reserved=0 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9889 (draft-ietf-teas-5g-ns-ip-mpls-18) > > Title : A Realization of Network Slices for 5G Networks > Using Current IP/MPLS Technologies > Author(s) : K. Szarkowicz, Ed., R. Roberts, Ed., J. Lucek, > M. Boucadair, Ed., L. Contreras > WG Chair(s) : Oscar Gonzalez de Dios, Vishnu Pavan Beeram > Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de > Velde ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
