Hi Lars, Thank you for the review. A diff to track the changes can be seen at: https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/5g-slice-realization/draft-ietf-teas-5g-ns-ip-mpls.txt&url_2=https://boucadair.github.io/5g-slice-realization/Lars-Genart-review/draft-ietf-teas-5g-ns-ip-mpls.txt. Please see also inline for more context. Cheers, Med > -----Message d'origine----- > De : Lars Eggert via Datatracker <noreply@xxxxxxxx> > Envoyé : mardi 21 janvier 2025 09:17 > À : gen-art@xxxxxxxx > Cc : draft-ietf-teas-5g-ns-ip-mpls.all@xxxxxxxx; last- > call@xxxxxxxx; teas@xxxxxxxx > Objet : Genart last call review of draft-ietf-teas-5g-ns-ip-mpls- > 14 > > > Reviewer: Lars Eggert > Review result: Ready with Nits > > # genart-lc review of draft-ietf-teas-5g-ns-ip-mpls-14 > > > Document: draft-ietf-teas-5g-ns-ip-mpls-?? > Reviewer: Lars Eggert > Review Date: 2025-01-21 > IETF LC End Date: 2025-01-21 > IESG Telechat date: Not scheduled for a telechat > > ## Comments > > ### "TEAS", paragraph 1 > > Given the importance of the figure in this I-D, it'd be nice if > they weren't just ASCII art. [Med] We used to have svg figures in previous versions of the draft but we also had idnits complaints about Unicode characters, etc. (https://github.com/boucadair/5g-slice-realization/issues/65). We reported this issue but seems this will be fixed in idnitv3 per https://github.com/ietf-tools/idnits/issues/35. As a hack, we reverted and tweaked many figure manually since then. Anyway, "repassed" figure 1 to SVG. As you can seen in the html rendering at https://boucadair.github.io/5g-slice-realization/Lars-Genart-review/draft-ietf-teas-5g-ns-ip-mpls.html some tweaking is need as a box does not render well. Will fix that one. > > ### "TEAS", paragraph 1 > ``` > A Realization of Network Slices for 5G Networks Using Current > IP/MPLS > Technologies > draft-ietf-teas-5g-ns-ip-mpls-14 ``` > "Current" in the title of the doc won't age well, and doesn't > actually convey any information. Remove? [Med] We prefer to keep this mention as we are leveraging current tools. This differentiates this document vs. "Realizing Network Slices in IP/MPLS Networks" (https://datatracker.ietf.org/doc/draft-ietf-teas-ns-ip-mpls/) which requires extensions, new tools, etc. > > ### Section 11, paragraph 0 > ``` > 11. Security Considerations > ``` > This document describes a LOT of different schemes and > approaches. I can't believe that only Section 4.2 warrants > special discussion in this section? > (This is probably my main question mark about this I-D.) > [Med] We focuses on key considerations and have the following: Security considerations specific to each of the technologies and protocols listed in the document are discussed in the specification documents of each of these protocols. > ### Section 12.2, paragraph 52 > ``` > [_5G-Book] Peterson, L., Sunay, O., and B. Davie, "5G Mobile > Networks: A Systems Approach", 2022, > > ``` > Remove underscore from tag? [Med] Seems that underscore was generated kramdown-rfc. Fixed. > > ## Nits > > > ### Typos > > #### Section 5.2.1.1, paragraph 16 > ``` > - Figure 20: Ingress Slice Admission Control (5QI-unware > Model) > + Figure 20: Ingress Slice Admission Control (5QI-unaware > Model) > + + > ``` > > #### Section 5.2.2, paragraph 11 > ``` > - In the 5QI-aware model, compared to the 5QI-unware model, > provider > + In the 5QI-aware model, compared to the 5QI-unaware model, > provider > + + > ``` [Med] ACK > > #### Section 5.2.2.1, paragraph 1 > ``` > - Compared to the 5QI-unware model, admission control (traffic > + Compared to the 5QI-unaware model, admission control > (traffic > + + > ``` [Med] ACK > > #### Section 6.1, paragraph 1 > ``` > - As discussed in Section 5.2.1, in the 5QI-unware model, the > provider > + As discussed in Section 5.2.1, in the 5QI-unaware model, the > provider > + + > ``` > [Med] ACK > ### Outdated references > > Document references `draft-ietf-opsawg-ntw-attachment-circuit- > 14`, but `-15` is the latest available revision. > > Document references `draft-ietf-opsawg-teas-attachment-circuit- > 18`, but `-19` is the latest available revision. > [Med] ACK > ### URLs > > These URLs in the document can probably be converted to HTTPS: > > * > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2F > lmcontreras.com%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com% > 7C8d56014008ed4c322dbe08dd39f40f5e%7C90c7a20af34b40bfbc48b9253b6f > 5d20%7C0%7C0%7C638730442593485737%7CUnknown%7CTWFpbGZsb3d8eyJFbXB > 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp > bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bRK8zLkaXO34v2whzf6Wkk0Bj > JGeAMNAWINuGBtdsrw%3D&reserved=0 > * > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2F > www.cpri.info%2Fdownloads%2FeCPRI_v_2.0_2019_05_10c.pdf&data=05%7 > C02%7Cmohamed.boucadair%40orange.com%7C8d56014008ed4c322dbe08dd39 > f40f5e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6387304425934 > 93658%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjA > uMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C% > 7C%7C&sdata=qUfcmb9qSqO9HrQnIbkfishFRROOePa8L6vfOGwIJ60%3D&reserv > ed=0 [Med] Checked that these are available using https. Fixed > > ### Grammar/style > > #### Section 3.3.5, paragraph 1 > ``` > tion of the TN is split into two sub-domains in conformance with > the referenc > ^^^^^^^^^^^ ``` This word is > normally spelled as one. [Med] ACK > > #### Section 4.2, paragraph 4 > ``` > could be, for example, either on the compute that hosts mobile > NFs (Figure 15 > ^^^^^^^^^^^ ``` The verb > "compute" does not usually follow articles like "the". Check that > "compute" is spelled correctly; using "compute" as a noun may be > non-standard. [Med] This one is correct. > > #### Section 4.2, paragraph 5 > ``` > that hosts mobile NFs (Figure 15, left hand side) or within the > DC/cloud infr > ^^^^^^^^^ ``` Did you mean the > adjective "left-hand"? > [Med] ACK > #### Section 4.2, paragraph 6 > ``` > ithin cloud IP fabric (Figure 15, right hand side)). On the AC > connected to a > ^^^^^^^^^^ ``` Did you mean the > adjective "right-hand"? > [Med] ACK > #### Section 4.3.2, paragraph 2 > ``` > d in details in Section 3.7, the PE need to determine which label > in the pac > ^^^^ ``` "PE" is a singular > noun. It appears that the verb form is incorrect. > [Med] ACK > #### Section 4.3.2, paragraph 5 > ``` > hat differentiated treatment can implemented in the provider > network as well > ^^^^^^^^^^^ ``` The modal verb > "can" requires the verb's base form. > [Med] "be" is missing. FixeD. > #### Section 4.3.3, paragraph 4 > ``` > n the provider network. With a small number of deployed 5G slices > (for examp > ^^^^^^^^^^^^^^^^^ ``` Specify a > number, remove phrase, use "a few", or use "some". > [Med] Changed to "a few" > #### Section 7.1, paragraph 7 > ``` > That provider may decide to move to a N-to-1 mapping for > aggregation/scalab > ^ > ``` > Use "an" instead of "a" if the following word starts with a vowel > sound, e.g. > "an article", "an hour". [Med] OK > > #### Section 11, paragraph 13 > ``` > b::300:3/128 o Tunnel (IPsec, GTP-U, etc) termination point * SDP > Figure 32: > ^^^ ``` In American English, > abbreviations like "etc." require a period. > [Med] Fixed. ____________________________________________________________________________________________________________ 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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
