Re: [Nfvrg] Research Group Preparation (a.k.a. "Last Call") for draft-irtf-nfvrg-gaps-network-virtualization

Dear Ángeles,

Thanks a lot for your review and comments. See inline below.

On Tue, 2017-06-06 at 02:18 +0200, Angeles Vazquez-Castro wrote:
> 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.

[Carlos] OK, we'll add that intro.

> 
> 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."

[Carlos] OK, we'll fix that.

> 
> 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.

[Carlos] As discussed with Evangelos, we'll add references to academic
papers as well.

Thanks,

Carlos

> 
> 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
> 
> 