Dear Carlos, thanks for your efforts and so sorry for my late review. I have no much to add to previous good reviews, just perhaps three comments:
1) It is not clear what is the underlying reasoning for selecting the points within Section 3 of Background (except 3.1 and 3.2, clear background concepts). Therefore, maybe just a small introductory paragraph may be helpful here. 2) Differently to other sections, Section 4.5 perhaps seems a bit inconclusive. It mostly describes facts instead of identifying concrete open issues related to virtualisation. Just to clarify what I mean, the following seems an assertion of capabilities rather than a description of an open issue: "virtualization techniques can allow tailoring the network resources on separate slices, specifically for each radio access network and use case, in an efficient manner." 2) As already pointed out, there exist research studies from academia that might be relevant to be listed here. They provide complementary views to standardisation viewpoint and potential practical solutions. Thanks, Ángeles >>> reason for why the OpenFlow protocol is mentioned in >>> the terminology section of the draft? It is used only in the SDN >>> section and expanded there as well. >> >> [Carlos] We just wanted to expand/explain on all the terms used in the >> document, but there is no additional reason. Do you think we should >> skip mentioning it the terminology section? >> > > [EH] Well, OpenFlow is an implementation choice mostly. There are a number of > other solutions for SDN related that people have used. So, imho I don't think > that it fits on the terminology section for such a type of document. > >>> >>> #2. Since you mention both ONF’s and IETF’s architectural view on >> SDN, >>> do you think it makes sense to include ITU’s view on it as well? >> >> [Carlos] That's a godo point. I personally don't know well the details >> about ITU's view. Is there any public available document that I can >> check? >> > > [EH] ITU's initial view was this reference: > ITU, "Framework of software-defined networking", ITU Recommendation Y.3300, > June 2014, <http://www.itu.int/rec/T-REC-Y.3300-201406-I/en>. > This is from 2014. I'm not sure if an updated or a new version exists. > > ... > >>> >>> Also, three general comments: >>> #A. I do agree with Kostas’s earlier mail about a few places where >> the >>> document is a bit gratuitous. >> >> [Carlos] We'll try to fix that. If you have additional parts where you >> think we should revise the text in that respect, please let us know. >> > > [EH] Well, this is really very minor, but in section 3.6, you mention only > Openstack for the open source cloud computing software. There are a couple > more. You could make that bullet more generic and reference more open source > activites like openstack, or add another bullet for an additional example. > Just so that you're not limited to one example per area. > >>> >>> #B. While this document includes a lot of references from the >>> standards’ bodies, it is very lacking in references from the >> academia. >>> In truth you have only two. While I agree that this draft shouldn’t >>> any exhaustive literacy review, I feel that the document would >> greatly >>> be improved by the inclusion of references to active research on the >>> challenge items you have enumerated. >> >> [Carlos] That is a good, but tricky point. We'll evaluate adding more >> research references in the next revision. >> > > [EH] You don't need to be thorough. Just point to a couple of other research > papers. > How about this one for a more generic reference to research challenges: > [1] Mijumbi, Rashid, Joan Serrat, Juan-Luis Gorricho, Niels Bouten, Filip De > Turck, and Raouf Boutaba. "Network function virtualization: State-of-the-art > and research challenges." IEEE Communications Surveys & Tutorials 18, no. 1 > (2016): 236-262. > > _______________________________________________ > Nfvrg mailing list > Nfvrg@irtf.org > https://www.irtf.org/mailman/listinfo/nfvrg
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Nfvrg mailing list Nfvrg@irtf.org https://www.irtf.org/mailman/listinfo/nfvrg
