I'm pretty good with networking, but there exists a culture of spec-writing that speaks a unique and unrelated language, and this is a great example. I read this article and the linked whitepaper, and while it clearly uses English words in conventional grammar, it makes absolutely no sense.
What, exactly, is NFV supposed to do? It's really, really easy to understand networking because it all ties down to tangible behavior: ARP, MAC tables, routing, etc. This seems to be totally unmoored from what is normally meant by "networking" - it doesn't even seem to have anything to do with higher-level ideas like BGP or OpenFlow.
Perhaps this calls for a "why should anyone care about NFV" article, or "three ways NFV will change your life".
NFV group is creating specifications, and not standards. The specifictions will point to standards developed by various standards organizations. In addition, NFV will identify gaps that are not covered by any standards today, and will advocate addressing such gaps. The specifications process is going well, but it is under a tight time line. The risk here is to end up with incomplete specification or one that is not aligned between one domain and other domains (infrastrucutre, software, management). Extra focus is needed on joint domains activities can make this process more complete.
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.