Hi Med, Krzysztof, and Richard, Thank you for your responses. We have updated the document accordingly (the list of updated files is below).
We have some followup questions/comments: a) > There is some additional comment. Some of the authors recently changed the > affiliation: > > Krzysztof Grzegorz Szarkowicz: HPE (instead of Juniper Networks) Krzysztof, we updated your affiliation to HPE. Would you also like to include an updated email address? The document currently lists [email protected]. b) > Julian Lucek: HPE (instead of Juniper Networks) Julian, please confirm that you would like to update your affiliation to HPE. If so, would you also like to update your email address (or any other part of your entry in the Authors’ Addresses section). c) > Richard Roberts: Nokia (instead of Juniper Networks). Richard, we updated your affiliation to Nokia and your email address to [email protected]. Let us know if any further updates are needed. d) > 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 > —> We will wait to hear from Luis about this. e) >> 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 We updated as follows. Let us know if you prefer otherwise. Updated: Examples of ACs are VLAN ACs configured on a physical interface (bearer) or Overlay VXLAN EVI ACs configured on an IP underlay (bearer). f) > 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: > [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. Krzysztof: > [Krzysztof] RFC2475, Section 2.3 describes most basic policer, without naming > it 1r2c (as, at that time, this is was the only policer defined, so didn’t > deserved any special name, to distinguish from other policers defined later, > e.g. 1r3c: RFC 2697, 2r3c: RFC 2698, or 2r3c: RFC 4115). However, the term > 1r2c for this basic policer described ins RFC2475, Section 2.3 is widely used > in the industry. So, might be we could use: > > “ * basic (often referred to as 1r2c: single-rate two-color) rate limiter” Thank you for the explanation. It seems that readers will understand this, so perhaps no updates are needed? We could also either update as indicated above by Krzysztof or update as shown below. Let us know your thoughts. Perhaps: * 1r2c (single-rate two-color) rate limiter This is the most basic rate limiter, described in Section 2.3 of [RFC2475] (though not termed “1r2c” in that document). g) >> 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. We updated as above but will wait for a confirmation from Julian. h) >> 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. >> >> Current: >> [TS-23.501] >> 3GPP, "System architecture for the 5G System (5GS)", 3GPP >> TS 23.501, >> <https://portal.3gpp.org/desktopmodules/Specifications/ >> SpecificationDetails.aspx?specificationId=3144>. >> ... >> >> [TS-28.530] >> 3GPP, "Management and orchestration; Concepts, use cases >> and requirements", 3GPP TS 28.530, >> <https://portal.3gpp.org/desktopmodules/Specifications/ >> SpecificationDetails.aspx?specificationId=3273>. >> --> >> > [Med] These are stable. We can use the latest version. We updated these reference entries to use the latest versions (Release 19 of both). However, we see that Release 17 is mentioned in the following sentence. Should this be updated to Release 19? Original: In current SDO progress of 3GPP (Release 17) and O-RAN, the mapping of 5QI to DSCP is not expected to be in a per-slice fashion, where 5QI-to-DSCP mapping may vary from 3GPP slice to 3GPP slice; i) >> 32) <!-- [rfced] The current URL for this reference >> (https://www.o-ran.org/specifications) goes to a page titled "O-RAN >> Specifications". We were able to find a list of O-RAN specifications here: >> https://specifications.o-ran.org/specifications. >> >> 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. There is now a new Version 09.00, published October 2025. We updated to point to this version, but let us know if you prefer otherwise. j) >> 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 For the above, we can make the changes in the ascii-art but not the SVG. Would you like to provide updated ascii-art and SVG for these? Other options would be to add to these expansions to the Abbreviations section or incorporate the expansions into the text describing the figures (if choosing the latter, please provide OLD/NEW). k) >> 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 We updated as indicated above. Note, however, that we did not make these changes in Figures 1, 6, 8, 9 and 10 because we can update the ascii-art but not the SVG. Please send along updated ascii-art and SVG if you’d like the changes to appear in these figures. l) >> d) Figures 12, 15, and 16: >> >> - In the SVG, the lines do not extend all the way to the boxes >> labeled "PE". > > Med: We can tweak these as follows: > > Figure 12: > https://github.com/boucadair/5g-slice-realization/blob/main/drawings/vlan-hand-off.txt > Figure 12 with svg rendering: > https://boucadair.github.io/5g-slice-realization/draft-ietf-teas-5g-ns-ip-mpls.html#figure-12 In the new SVG, the legend doesn’t match the diagram — “*” appears in the legend but a black disk appears in the diagram. Would you like to further update this? m) > Figure 15: > https://github.com/boucadair/5g-slice-realization/blob/main/drawings/mpls-10b-hand-off.txt > Figure 15 with svg rendering: > https://boucadair.github.io/5g-slice-realization/draft-ietf-teas-5g-ns-ip-mpls.html#figure-15 > > Figure 16: > https://github.com/boucadair/5g-slice-realization/blob/main/drawings/mpls-10c-handoff.txt > Figure 16 with svg rendering: > https://boucadair.github.io/5g-slice-realization/draft-ietf-teas-5g-ns-ip-mpls.html#figure-16 In the new SVG for Figures 15 and 16, the line for the Provider Network box connects to the black disks inside the PE boxes rather than stopping at the border. Is this okay? FILES (please refresh) Updated XML file: https://www.rfc-editor.org/authors/rfc9889.xml Updated output files: https://www.rfc-editor.org/authors/rfc9889.txt https://www.rfc-editor.org/authors/rfc9889.pdf https://www.rfc-editor.org/authors/rfc9889.html Diff file showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9889-auth48diff.html https://www.rfc-editor.org/authors/rfc9889-auth48rfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9889-diff.html https://www.rfc-editor.org/authors/rfc9889-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9889-alt-diff.html (diff showing changes where text is moved or deleted) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9889 Thank you, Rebecca VanRheenen RFC Production Center > On Oct 29, 2025, at 12:57 PM, Richard Roberts (Nokia) > <[email protected]> wrote: > > Confirmed. > > RFrom: Krzysztof Szarkowicz <[email protected]> > Sent: Wednesday, October 29, 2025 5:44 PM > To: Rebecca VanRheenen <[email protected]> > Cc: Richard Roberts (Nokia) <[email protected]>; Julian Lucek > <[email protected]>; Mr. Mohamed Boucadair <[email protected]>; > Luis Miguel Contreras Murillo <[email protected]>; > RFC Editor <[email protected]>; [email protected] > <[email protected]>; [email protected] <[email protected]>; Vishnu > Pavan Kumar Beeram <[email protected]>; James Guichard > <[email protected]>; [email protected] > <[email protected]> > Subject: Re: AUTH48: RFC-to-be 9889 <draft-ietf-teas-5g-ns-ip-mpls-18> for > your review > You don't often get email from [email protected]. Learn why this is > important > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > Dear Rebecca, > > There is some additional comment. Some of the authors recently changed the > affiliation: > > Krzysztof Grzegorz Szarkowicz: HPE (instead of Juniper Networks) > Julian Lucek: HPE (instead of Juniper Networks) > Richard Roberts: Nokia (instead of Juniper Networks). > > > Julian, Richard -> please confirm. > > Best regards, > -- > Krzysztof Grzegorz Szarkowicz, HPE Networking, Routing Infrastructure > Solutions | PLM, Solutions Architect | Phone: +49 89 203 012 127 > Please consider my current time zone, when calling: CDT (UTC-05:00) > >> On 2025 Oct 28, at 01:39, Rebecca VanRheenen >> <[email protected]> wrote: >> >> [External Email. Be cautious of content] >> >> >> Hi Med and Krzysztof, >> >> Thank you for responding to our questions. We are working on updating the >> document and will post updated files within the next day or two. >> >> Best regards, >> >> Rebecca VanRheenen >> RFC Production Center >> >> >> >>> On Oct 27, 2025, at 4:44 AM, Krzysztof Szarkowicz >>> <[email protected]> wrote: >>> >>> Dear RFC Editors, >>> >>> Thank you for detailed review. I agree with comments made by Med, and >>> adding additional comment (inline) regarding 1r2c. >>> >>> Best regards, >>> -- >>> Krzysztof Grzegorz Szarkowicz, HPE Networking, Routing Infrastructure >>> Solutions | PLM, Solutions Architect | Phone: +49 89 203 012 127 >>> Please consider my current time zone, when calling: CEST (UTC+02:00) >>> >>>> On 2025 Oct 27, at 09:26, [email protected] wrote: >>>> >>>> [External Email. Be cautious of content] >>>> >>>> >>>> Hi all, >>>> >>>> +Adding Richard new email address >>>> >>>> Focusing on the revie of the figures: >>>> >>>>> 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). >>>>> >>>>> 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. >>>>> >>>> >>>> Med: Please s/"===" in Figures 4 and 5/"=" in Figures 4 and 5 >>>> >>>>> >>>>> b) Figure 4: Do the boxes labeled "SW" and "PE" appear correctly >>>>> in the SVG? >>>> >>>> Med: Yes, they look as intended. >>>> >>>>> >>>>> >>>>> c) Figure 5: Do the boxes labeled "CE", "Mngd CE", and "DC GW" >>>>> appear correctly in the SVG? >>>>> >>>> >>>> Med: Yes, they look as intended. >>>> >>>>> >>>>> d) Figures 12, 15, and 16: >>>>> >>>>> - In the SVG, the lines do not extend all the way to the boxes >>>>> labeled "PE". >>>> >>>> Med: We can tweak these as follows: >>>> >>>> Figure 12: >>>> https://urldefense.com/v3/__https://github.com/boucadair/5g-slice-realization/blob/main/drawings/vlan-hand-off.txt__;!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8pVHkjYk$ >>>> Figure 12 with svg rendering: >>>> https://urldefense.com/v3/__https://boucadair.github.io/5g-slice-realization/draft-ietf-teas-5g-ns-ip-mpls.html*figure-12__;Iw!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8tts-IUw$ >>>> >>>> Figure 12: >>>> https://urldefense.com/v3/__https://github.com/boucadair/5g-slice-realization/blob/main/drawings/mpls-10b-hand-off.txt__;!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8qcvmQ1w$ >>>> Figure 15 with svg rendering: >>>> https://urldefense.com/v3/__https://boucadair.github.io/5g-slice-realization/draft-ietf-teas-5g-ns-ip-mpls.html*figure-15__;Iw!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8hnQOiTW$ >>>> >>>> Figure 16: >>>> https://urldefense.com/v3/__https://github.com/boucadair/5g-slice-realization/blob/main/drawings/mpls-10c-handoff.txt__;!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8qdcfJu-$ >>>> Figure 16 with svg rendering: >>>> https://urldefense.com/v3/__https://boucadair.github.io/5g-slice-realization/draft-ietf-teas-5g-ns-ip-mpls.html*figure-16__;Iw!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8qZEoKEs$ >>>> >>>>> >>>>> - 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 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. >>>>> >>>> >>>> Med: Please use this updated version: >>>> >>>> Figure 23: >>>> https://urldefense.com/v3/__https://github.com/boucadair/5g-slice-realization/blob/main/drawings/QoS-5QI-mapping-example.txt__;!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8lN-PbFo$ >>>> >>>> Figure 23 with svg rendering: >>>> https://urldefense.com/v3/__https://boucadair.github.io/5g-slice-realization/draft-ietf-teas-5g-ns-ip-mpls.html*figure-23__;Iw!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8hVqMZcq$ >>>> >>>> >>>>> >>>>> 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. >>>>> >>>> >>>> Med: Yes, these look as intended. >>>> >>>>> - Do the boxes under "Slice Policer" in Figure 25 look as expected >>>>> in the SVG? >>>>> >>>> >>>> Med: ACK >>>> >>>>> >>>>> 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. >>>>> >>>> >>>> Med: Please use this updated version >>>> >>>> Figure 26: >>>> https://urldefense.com/v3/__https://github.com/boucadair/5g-slice-realization/blob/main/drawings/egress-slice-admission-Control-5QI-aware.txt__;!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8ioVFVbI$ >>>> Figure 26 rendered SVG: >>>> https://urldefense.com/v3/__https://boucadair.github.io/5g-slice-realization/draft-ietf-teas-5g-ns-ip-mpls.html*figure-26__;Iw!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8nhHp4ag$ >>>> >>>>> >>>>> h) Figure 27: Does the ">>" in the ascii-art appear as expected in >>>>> the SVG? >>>>> >>>> >>>> Med: Yes. >>>> >>>>> >>>>> 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. >>>> >>>> Med: Please use this updated version: >>>> >>>> Figure 30: >>>> https://urldefense.com/v3/__https://github.com/boucadair/5g-slice-realization/blob/main/drawings/multi-DC.txt__;!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8scQ7VUC$ >>>> Figure 30 with SVG rendering: >>>> https://urldefense.com/v3/__https://boucadair.github.io/5g-slice-realization/draft-ietf-teas-5g-ns-ip-mpls.html*figure-30__;Iw!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8sjqUZHK$ >>>> >>>> >>>>> >>>>> j) Figure 32: >>>>> >>>>> - Does the arrow "v" above the "^" above "MIot (SST=3)" look as >>>>> expected in the SVG? >>>> >>>> Med: Please use this updated version >>>> >>>> Figure 32: >>>> https://urldefense.com/v3/__https://github.com/boucadair/5g-slice-realization/blob/main/drawings/S-NSSAI-deployment.txt__;!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8uRKUvDF$ >>>> Figure 32 with SVG rendering: >>>> https://urldefense.com/v3/__https://boucadair.github.io/5g-slice-realization/draft-ietf-teas-5g-ns-ip-mpls.html*figure-32__;Iw!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8jRzWHfw$ >>>> >>>>> >>>>> - Do the PE and NF boxes look okay in the SVG? >>>> >>>> Med: Yes. >>>> >>>> >>>>> --> >>>> >>>> Cheers, >>>> Med >>>> >>>> >>>>> -----Message d'origine----- >>>>> De : BOUCADAIR Mohamed INNOV/NET >>>>> Envoyé : vendredi 24 octobre 2025 08:34 >>>>> À : '[email protected]' <[email protected]>; >>>>> [email protected]; [email protected]; [email protected]; >>>>> [email protected] >>>>> Cc : [email protected]; [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 >>>>> >>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2F__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8giGIbbx$ >>>>>> 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. >>> >>> [Krzysztof] RFC2475, Section 2.3 describes most basic policer, without >>> naming it 1r2c (as, at that time, this is was the only policer defined, so >>> didn’t deserved any special name, to distinguish from other policers >>> defined later, e.g. 1r3c: RFC 2697, 2r3c: RFC 2698, or 2r3c: RFC 4115). >>> However, the term 1r2c for this basic policer described ins RFC2475, >>> Section 2.3 is widely used in the industry. So, might be we could use: >>> >>> “ * basic (often referred to as 1r2c: single-rate two-color) rate limiter” >>> >>> >>>>>> >>>>>> >>>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8g83r1pD$ >>>>>> >>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8g83r1pD$ >>>>>> >>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8g83r1pD$ >>>>>> >>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8g83r1pD$ >>>>>> >>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8g83r1pD$ >>>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2F__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8giGIbbx$ >>>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8g83r1pD$ >>>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8g83r1pD$ >>>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2F__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8giGIbbx$ >>>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8g83r1pD$ >>>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8g83r1pD$ >>>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8g83r1pD$ >>>>>> >>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8g83r1pD$ >>>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2F__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8giGIbbx$ >>>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8g83r1pD$ >>>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2F__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8giGIbbx$ >>>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2F__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8giGIbbx$ >>>>>> >>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2F__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8giGIbbx$ >>>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2F__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8giGIbbx$ >>>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2F__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8giGIbbx$ >>>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2F__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8giGIbbx$ >>>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2F__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8giGIbbx$ >>>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2F__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8giGIbbx$ >>>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2F__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8giGIbbx$ >>>>>> 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://urldefense.com/v3/__https://fra01.safelinks.protection.outlook.com/?url=https*3A*2F*2F__;JSUl!!NEt6yMaO-gk!CG6ya-IdZJoAAk8w9Nvl-cpyuQvYAS2sG2HGotOxXmBdWs34ROHMYbDhqu_3ggXMzbERvJzRt9PxOy6yFtpUmOkd8giGIbbx$ >>>>>> 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]
