Hi, On Jan 21, 2025, at 11:07, mohamed.boucadair@xxxxxxxxxx wrote: >> ### "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. ah, I didn't know the backstory. (And idnits is unfortunately mostly useless these days.) >> ### "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. Thanks for the background. I think the word "current" is asked to do way too much work if it's supposed to express all that nuance. Whether you leave it in or not, if you think that is an important distinction to draft-ietf-teas-ns-ip-mpls, the I-D needs text to say this. >> ### 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. Right. So are you saying that no new security considerations arise when all these different technologies and components are combined in the ways explained in this document (other than what is said about Section 4.2)? I still find that hard to believe. But because Im'm not a security person, I'll leave it at that - you'll need to convince the SEC ADs that this is the case... Thanks, Lars -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx