Magic Quadrant for Enterprise Backup/Recovery
HD-PLC and HomePlug submitted their joint proposal in September 2007. It won an initial vote the following month, but that verdict wasn't ratified by gaining a clear, 75 per cent majority at subsequent ballots. That happened many times last year, until the various parties finally chose to agree on the HD-PLC/HomePlug technology on 22 December 2008, when the P1910 working group finally ended up with a baseline specification from which the technology can evolve and proceed eventually through the IEEE ratification process to become a standard.
Interestingly, to get to that stage, the group had to agree to include compatibility with G.hn, which had reached a similar stage earlier that month. G.hn compatibility was mandated by the UPA crowd and, as we'll see, it could well prove a canny move that effectively renders P1901 irrelevant.
On first impressions, though, the move to support G.hn would appear to favour P1901 in a new, broader standards race - it has the broadest array of technology on board. However, P1901 is arguably a flawed design since it incorporates multiple, incompatible PHY specifications. That would be fine if vendors will be obliged to include all of the standard's PHYs, but they're not, they can pick and choose.

G.hn: different cabling types - but one network
The upshot is that if manufacturer A uses one PHY, and manufacturer B uses another, their products will not work together - despite both being compliant with P1901 and sporting whatever Wi-Fi-style brand products based on the standard end up being sold under.
And it's not like 802.11a, 802.11b and 802.11g where there are clear differences - speed and backwards compatibility - between them.
It gets worse. P1901 also takes in multiple MACs rather than a single specification that can operate with all of the PHYs. This only increases the opportunity for interoperability problems.
P1901 has long had this dual-PHY, dual-MAC approach, but the decision to incorporate G.hn compatibility has only complicated matters, by including the need for a third PHY and MAC pairing.
Contrast that with G.hn, which incorporates just a single PHY for all three transport systems it operates over and, in turn, one MAC.
It's telling that Wi-Fi didn't gain mass industry support until the specification's four initial PHYs had been whittled down to one. And it's that simplicity that has turned many a vendor on to G.hn, along with its support for all three key home wiring systems.
The way around P1901's PHY and MAC incompatibilities is for manufacturers to build devices that support them all, but this requires more components, increasing the cost of the final products. G.hn holds open the prospect that a single chip will be able to manage whichever ports a device contains, making it cheaper from the outset and easier to integrate into devices from PCs to set-top boxes. The way chip production processes shrink over time means a single-chip P1901 implementation will one day be possible, but G.hn will have one heck of a lead.
Most likely, it won't need it. The inclusion of G.hn support in P1901 means that its backers have a way out of a standards war. Build a device that's G.hn compatible and - thanks to that single PHY - it'll be physically interoperable with all the others. But even if said device lacks P1901's other PHYs, the vendor will still be able to claim IEEE 1901 compatibility.
COMMENTS
@Tony Smith, Notches
On the face of it, notches sound like a good idea but it's really just a convenient word. In their current form they only cover ham radio and even that is not perfect.
The shortwave band is used for many other things, including broadcast radio, and if all the required notches were in place (http://www.mikeandsniffy.co.uk/UKQRM/if.htm) then there's not sufficient bandwidth remaining!
The current thinking seems to be that because PLT equipment is not classed as a radio transmitter, it can get around all sorts of regulations. IMHO it's only a matter of time before it is realised that these devices are in fact simply radio transceivers which use mains wiring for their transmission medium.
In any case, it has been demonstrated time and time again (see articles in RadCom, RSGB for example) that these devices all fail against current standards regarding EMC so I don't understand why they are on the market.
The regulator should do their job and enforce the standards, even if that means admitting failure to do so in the first instance. It's not their job to decide what's in the public greater interest.
I understand how people get confused by this stuff.
I consider myself pretty damn technical, but my eyes glazed over at this article. Gave me a new appreciation for gobbledygook and inconsequential details!
IEEE and networking are basically incompatible
The less the IEEE have to do with networking standards the better it is for all of us -- they invariably make a pigs' ear of everything they touch. (Wireless, anyone?) This is no exception, especially as its tied the rather quaint notion that everything is bolted to the wall and plugged into something. While it is true that we're unlikely to buy cordless refrigerators any time soon the majority of our information consuming devices are portable these days and are only likely to get more so over time.
The problem with wireless and bandwidth is just technical, an iffy standard and data transmission crammed into a tiny sliver that nobody else wanted because it was deemed useless. Open the R/F window just a little more and we'll have as much bandwidth as we need, especially if we're only talking about limited range.
One of the reasons why I still use wired networking - and would have used coaxial cable if was still viable -- is that I care about standing power consumption. Unlike an office a home network isn't being used that much so leaving equipment on 24/7 is wasteful. Intelligent wireless can be made low powered. Powerline networking cannot -- its a crock, and an antisocial one at that.

IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Steps to Take Before Choosing a Business Continuity Partner
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud