[occi-wg] Standards Matter: The Battle For Interoperability Goes On

[Sam Johnston]

Apologies - nimble fingers and force of habit sent this to the wrong
group... fortunately it's not too far OT :)

Enjoy your weekends. For those of you staying inside and avoiding miserable
european weather you're not alone - I'll be here working on the spec so you
can reach me on or off-list.

Sam

On Sat, Apr 18, 2009 at 11:21 AM, Sam Johnston <samj at samj.net> wrote:

> [image: InformationWeek] <http://www.informationweek.com/>
>
> Standards Matter: The Battle For Interoperability Goes On
>
> We all say we want our gear to work together, but are you willing to hold
> vendors accountable for breaking faith?
>
> By Mike Fratto,  InformationWeek
> <http://www.informationweek.com/;jsessionid=E3F03D5UIKJXEQSNDLRSKH0CJUNN2JVN>
> April 18, 2009
> URL: http://www.informationweek.com/story/showArticle.jhtml?articleID=216600011
>
>
>  Used to be, vendors didn't brazenly fracture standards. Sure, they sought
> lock-in opportunities, but most knew that if they played too fast and loose,
> the market would mete out punishment, as in the '90s when TCP/IP rule
> breakers lost sales.
>
> Times have changed, and not for the better. Take network access control.
> Cisco has all but abandoned its NAC framework and partner program. Microsoft
> threw some of its Network Access Protection specifications to the Trusted
> Computing Group, but Cisco consistently has refused to even acknowledge the
> TCG's legitimacy. So much for interoperability.
>
> Want more? First proposed in 2004, 802.11n<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=802.11n&x=&y=>was hung up as Wi-Fi Alliance members hashed through competing technical
> interests. The widely used 802.1X is being revised because critical features
> were missed the first time. In the realm of cloud computing, you can't get
> two people to agree to a definition, much less what should be standardized,
> as evidenced by the recent finger-pointing around the IBM-led Open Cloud
> Manifesto initiative.
>
> And this lack of interest in creating functional, universal standards seems
> to be accelerating. Cisco's EnergyWise, which proposes building-wide energy
> management, should have gone to the International Telecommunication Union
> three years ago. And how confident are you that Fibre Channel<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=Fibre%20Channel&x=&y=>over Ethernet will be more interoperable than Fibre Channel?
>
> If we're not careful, standards for nascent technologies could be so
> splintered as to be worse than none at all.
>
> There's plenty of blame to go around, starting with the big vendors that
> try to game the process. "The larger vendors know the 'flaws' in the current
> system," says David O'Berry, director of IT systems and services for the
> South Carolina Department of Probation, Parole, and Pardon Services. "They
> know it takes awhile for things to progress--especially when you *want* it
> to take awhile--and so they use that gap to create de facto lock-in at
> critical junctures."
>
> For their part, vendors counter that standards bodies have devolved to the
> point that they're almost immobilized by politics and squabbling. Consensus
> can take years, and the market won't wait that long. "Standards bodies tend
> to be more focused on the process than achieving the desired result in the
> shortest time possible," says Mike Healey, CTO of GreenPages Technology
> Solutions and an *InformationWeek Analytics *contributor.
>
>  [image: chart: What Matters: How important is it that your NAC system
> adheres to these frameworks?]
> Case in point, says Healey, is the 802.11n wireless standard. The a, b, and
> g iterations had hit a performance wall that was hindering business, but the
> new spec languished for a year in a draft format<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=format&x=&y=>that didn't significantly change from its final release. "Vendors that were
> willing to 'cheat' and release products based on the draft established a
> competitive advantage," he says. "Those that followed the rules were left
> behind. The IEEE<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=IEEE&x=&y=>delays were less about technical specifications or design issues but
> revolved around meeting schedules and documentation timelines."
>
> Healey says he asked Aruba Networks what it would do about its prerelease
> 802.11n product if the standard changed. "Two words: 'firmware upgrade.'"
>
> Another high-profile standards failure is browser support for HTML and
> Cascading Style Sheets. Designers who don't know--or care--about the
> implications of proprietary extensions to HTML<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=HTML&x=&y=>spew out Web sites that work only in Internet Explorer for Windows.
>
> IT organizations bear some of the blame as well. We state that standards
> compliance<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=compliance&x=&y=>is a nonnegotiable check box in purchasing decisions, yet we haven't been
> consistent in insisting on adherence. Storage networking<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=networking&x=&y=>is a prime example. Even though Fibre
> Channel<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=Fibre%20Channel&x=&y=>is an ANSI standard and, in theory, any FC device should communicate with
> any other FC device, the reality is that vendors competing for storage<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=storage&x=&y=>area network
> switch<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=switch&x=&y=>and director market share have little incentive to interoperate. Customers
> take the path of least resistance by purchasing from certified product lists
> rather than selecting components based on price or feature set.
>
> Is it a coincidence that high-end storage is about the most expensive
> technology that IT purchases--with the least number of competing products?
> We think not. So will we let the next big thing in storage, Fibre Channel
> over Ethernet, follow the same path? Why not insist on an FCoE Alliance with
> a logoed testing program?
>
>  DIG DEEPER
> State Of Storage
> Balky SANs aren't all we have to worry about.
> Download this
> Analytics Report <http://stateofstorage.informationweek.com/>
> See all
> *InformationWeek* Analytics Reports<http://www.informationweekanalytics.com/>
>  Of course, standards aren't magic pixie dust. IT organizations often
> can't get even supposedly compliant products to interoperate without hacks
> and workarounds. But that's no reason to throw up our hands and write off
> the process. We need to advocate for a smart, independent standards track.
>
> "The secret sauce to a successful 'working standard' isn't necessarily IETF
> or another longstanding body," says Jonathan Feldman, director of IT
> services for the city of Asheville, N.C., and an *InformationWeek
> Analytics* contributor. "Rather, an earnest and honest effort by a group
> that has governance outside of a single corporation's control is what's
> important."
>
> Along with vendor independence, interoperability testing is critical. We
> have interoperable 802.11 wireless products not just because there's a
> standard, but because vendors backed the Wi-Fi Alliance and decided to
> cooperate. As the Wi-Fi Alliance certification took hold, it started showing
> up as a requirement in requests for proposals, which motivated more vendors
> to participate and get certified. The result: Certified WLAN products
> interoperate--unlike SANs.
> *Hot-Button Issues*
> Cloud computing and green IT are two of the hottest IT areas and two
> hotbeds of standards angst. The cry for cloud computing standards in
> particular has reached a fever pitch in recent weeks since a group of
> vendors released the Open Cloud Manifesto, an outline of core principles
> intended to boost interoperability among various cloud computing
> technologies.
>
> Critics charged that IBM and other vendors developed the manifesto behind
> closed doors and then tried to foist it on the industry. Microsoft, which
> said it agreed in principle with most of the manifesto, was nonetheless
> disturbed by the lack of openness in the process (the irony isn't lost on
> us) and called for more open discussion. Amazon.com's response was more
> measured, noting that the company has offered Amazon Web Services APIs in
> various languages and formats based on customer demand.
>
> People should calm down. Frankly, the manifesto was simply a statement of
> intent with a diverse set of backers, including AT&T, F5 Networks, Hyperic,
> IBM, and SAP. What isn't clear to us is whether cloud computing standards
> are necessary.
>
> That's not to say we don't need specs for the technologies that keep clouds
> aloft. Some standards work for virtualization, for instance, already has
> been completed. The Distributed Management Task Force announced in March the
> Open Virtualization<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=Virtualization&x=&y=>format, which standardizes the virtual
> machine<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=virtual%20machine&x=&y=>
> file<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=file&x=&y=>format and
> schema<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=schema&x=&y=>description and is backed by VMware and Citrix Systems. Microsoft says it
> will support the spec in Hyper-V but hasn't provided a timeline.
>
> In the green IT market, Cisco came under fire for not taking
> EnergyWise--its program for monitoring, managing, and reducing power
> consumption that it says was three years in the making--to a standards
> group. The company counters that when it started on EnergyWise, the goal was
> simply to manage the power consumption of Power over Ethernet devices, but
> over time the scope broadened to include more devices, data gathering, and
> management.
>
> What Cisco ended up with wasn't what it started with, says Hugh Barrass, a
> Cisco technologist responsible for standards, who adds that the vendor has
> every intention of submitting the EnergyWise work to a standards body.
> "Digging in our heels isn't beneficial to anyone," Barrass says. "What we
> learn from EnergyWise implementations we will take to the standards bodies
> to create effective standards."
>
>  HOT OR NOT?
>  *HOT*
> Data Center Bridging Lossless, high-speed Ethernet with flow control? Good
> for storage. Good for data. Good for you.
> 802.1X-REV 801.1X becoming a more usable protocol. Finally.
> ODF/OOXML Standardized file formats for seamless import/export? Love it,
> and the death match to dominate is good TV.
> NAT66 Transport-agnostic IPv6-to-IPv6 translation. Apparently, new scheme
> won't solve old problems.
>  *NOT*
> Cloud Standards We know there's been a lot of chatter, but first define
> cloud, then we'll talk.
> 802.11v Wireless network management<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=network%20management&x=&y=>via Layer 2 seems like a good idea, but is it necessary?
> DNSSEC Yeah, we need it, but infrastructure<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=infrastructure&x=&y=>and operations aren't even close to ready.
> Common Event Expression A common event format and taxonomy should be hot,
> but no way is this getting into products.
>  Competitors counter that Cisco's aim was to get a jump on everyone
> else--there are few green IT standards on the table, outside of the IEEE
> 802.3az Energy Efficient Ethernet task group, which doesn't seem to be
> gaining much traction. And in fact, Cisco does benefit from being first out,
> if for nothing else than bragging rights if EnergyWise proves successful.
>
> *Gray Areas*
> Standards bodies aren't a panacea. Some specs designed from the ground up
> in these groups are still incomplete. 802.1X, which was ratified in 2001,
> defines host authentication<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=authentication&x=&y=>to authorize use of a port. Unfortunately, the spec defined
> port<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=port&x=&y=>use as all or nothing, either open or closed, which means those hosts unable
> to authenticate, such as guests or devices that don't support 802.1X,
> couldn't connect at all, at least according to the standard.
>
> To support guest access, Hewlett-Packard and other vendors added
> proprietary capabilities to their switches. Cisco went a step further,
> allowing its Cisco Discovery Protocol to pass through the port to discover a
> host, such as a voice-over-IP phone, before the port is authenticated. Both
> functions are necessary, and even though they don't comply with 802.1X, they
> don't break interoperability, either. The IEEE is now working on a revision
> to 802.1X that enhances the protocol<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=protocol&x=&y=>based on needs discovered in field deployments.
>
> That example just gives credence to vendors' favorite argument: Technology
> must be developed and deployed with live customers before functionality can
> be standardized.
>
> "As standards grow larger in scope and become more complex, it becomes
> difficult to make fundamental changes to the underlying architecture," says
> Paul Congdon, CTO of HP ProCurve and a longtime representative to several
> standards groups. "This is similar to the software<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=software&x=&y=>problem of adding new architectural constructs to mature operating systems."
> The answer, many industry players argue, is targeted industry consortia that
> can perform in-depth testing while maintaining compatibility.
> *Standards Equality*
> Veteran standards bodies such as the IEEE, International Telecommunication
> Union, and Internet Engineering Task Force have established procedures for
> taking a standard from a twinkle in an engineer's eye to publication.
> However, with the fast pace of technology innovation, work in these bodies
> can drag on to the point where the standards they're developing aren't
> delivered until long after demand has peaked.
>
> "The time to build standards is when knowledge is high, because you know
> what functions need to be worked on and politics are low, because no one has
> an entrenched stand to defend," says Steve Hanna, a distinguished engineer
> with Juniper Networks and another longtime member of various standards
> groups. That can be a narrow window that vendors often step through with
> proprietary functionality.
>
> One answer: small, targeted industry consortia, like the Trusted Computing
> Group and the Metro Ethernet Forum, that can move faster than the large
> standards bodies. Hanna, who's co-chair of the Trusted Network Connect and
> IETF Network Endpoint Assessment working groups, says the TNC completed
> initial work on its NAC spec in just about a year. Industry consortia are
> more nimble than the big bodies because their working groups are smaller and
> more focused. Also, they provide interoperability testing and certificate
> programs and coordinate work with other entities.
>
> The Metro Ethernet Forum<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=Forum&x=&y=>provides a good example of how to work with veteran standards bodies,
> vendors, and customers (in this case, carriers). The MEF decided early not
> to be a standards body, but to act as a liaison between its members and
> standards bodies and to communicate customer needs to the standards groups,
> says Craig Easley, VP of marketing at Matisse Networks and co-chair of the
> MEF North American Marketing Committee. The MEF recruited vendors and
> customers to become members. Carriers started making MEF certification a
> requirement in their requests for proposals, and now carriers are seeing MEF
> certification<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=certification&x=&y=>requirements showing up in RFPs from prospective enterprise customers. The
> result: a set of products that interoperate, reducing costs for all
> involved.
>
> *You Say Tomato ...*
> Standards bodies try to limit overlap and redundancy. Competing specs for
> the same functions benefit no one; proposals should be fought over in a
> single work group and a winner chosen based on technical merit. The IETF,
> IEEE, and others follow those guidelines and reuse each other's specs where
> it makes sense. They aren't in competition.
>
> Unfortunately, politics can get in the way when a vendor has such a large
> stake in a format that it simply won't budge. Case in point: The ITU's
> International Organization for Standardization (ISO) published the spec for
> the Open Document<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=Document&x=&y=>Format, or ODF, a file format developed by Sun Microsystems for its Star
> Office/OpenOffice. ODF is missing some critical components, like a
> definition for related apps such as spreadsheets and presentation files, but
> Oasis, the sponsoring organization, is working on those. Microsoft, with its
> huge investment in its own software, countered by submitting its own Office
> Open XML<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=XML&x=&y=>(OOXML) proposal to the Ecma International standards group, which in turn
> submitted it to the ISO, which published the standard in 2008 amid much
> controversy.
>
>  [image: Steve Hanna, engineer with Juniper Networks and longtime member
> of various standards groups.] Vendors have a narrow window, Hanna says
>  "Multiple standards coexist in many industries," says Jean Paoli, general
> manager of interoperability strategy for Microsoft. "Customers benefit from
> choice and functionality in their document formats, such as HTML, PDF, Open
> XML, and ODF. Standardization of Open XML by ISO<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=ISO&x=&y=>and IEC ensures access and opportunity to all." What Paoli fails to point
> out, however, is that HTML, PDF, and OOXML have very different use cases.
> OOXML and ODF directly compete, and having two competing, noninteroperable
> formats is no benefit.
>
> The ISO sidestepped the issue, stating that competing standards aren't
> unprecedented and that the market should decide. By that logic, since most
> of the world uses Microsoft Office<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=Microsoft%20Office&x=&y=>applications, Redmond's formats are the de facto standard.
>
> But critics take issue. "De facto standards are contradictory because they
> are held by one company and implemented only by those allowed to implement
> them, and the permission to do so can be changed," says Louis Suarez-Potts,
> community manager for Sun's OpenOffice.org.
>
> Microsoft won't fully implement ISO Office Open XML until its next version
> of Office, Office 14. The European Union is pressuring Microsoft to support
> ODF. OpenOffice<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=OpenOffice&x=&y=>already supports OOXML, and Microsoft wrote a module for Office 2007 to read
> and write ODF.
>
> Yeah, it's a mess.
>
> The takeaway: If you're guilty of relegating standards support to a "nice
> to have" feature rather than a requirement, you're part of the problem. If
> you want products to interoperate, be prepared to walk away if a vendor
> can't prove compliance. Don't be brushed off with promises of standards
> support "on the road map." The alternative is vendor lock-in and higher
> costs, including the cost of maintaining systems that don't work together.
> Standards bodies are imperfect and must do better. The alternative:
> splintered networks and broken promises.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090418/8ec9e39d/attachment.html