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.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.