- occi-wg - lists.ogf.org

Nouns and Verbs (was: Syntax of OCCI API)
by Sam Johnston 21 Apr '09

21 Apr '09

Ok so moving right along... I like the "resource" approach (thanks Andy) and it fits well with the single entry point w/ search style (which in turn allows for arbitrarily simple and complex environments ranging from 1 to many millions of resources). These have a category/type (e.g. server, network, storage) and content depending on that. You can of course ask for just one type or another (e.g. query "servers" but not networks or storage) and we can do a simple optimisation to bring this into line with existing APIs: http://example.com/servers -> http://example.com/-/server http://example.com/networks -> http://example.com/-/network http://example.com/storage -> http://example.com/-/storage I specifically don't like the idea of differentiating between physical and virtual resources (the whole point is that you can't, or at least don't need to, know the difference), but that's ok because I don't think it's necessary. If I'm dealing with a "server" I don't care if it's delivered as a slice, a VM or a physical machine so long as it meets my service level agreement.... this is details for the implementor and one of the areas where we need to allow them to innovate. Ok so nouns and verbs (ignoring CRUD which is common anyway): server: - start - stop - restart - deploy/undeploy? (comes back to persistent vs ephemeral etc.) - clone/snapshot? network: - start (aka up) - stop (aka down) storage: - start (aka online) - stop (aka offline) - snapshot? - backup? others? Sam ---------- Forwarded message ---------- From: Edmonds, AndrewX <andrewx.edmonds(a)intel.com> Date: Fri, Apr 17, 2009 at 11:10 AM Subject: Re: [occi-wg] Syntax of OCCI API To: Andre Merzky <andre(a)merzky.net>, Chris Webb <chris.webb(a)elastichosts.com > Cc: "occi-wg(a)ogf.org" <occi-wg(a)ogf.org> Exactly my point in my last mail, Andre. If we can even begin to suggest on the nouns that'll be a big help. In the wiki we have the central entity to be a "Resource" (in fact we could name this as Noun to focus discussion - thoughts? Sam?. That "Resource"/"Noun" can be abstractly sub-classed as virtual or physical and beneath that concrete entities could be "Server", "VM" and in the case of extension (re: Randy), "Loadbalancer". Andy -----Original Message----- From: occi-wg-bounces(a)ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Andre Merzky Sent: 17 April 2009 10:03 To: Chris Webb Cc: occi-wg(a)ogf.org Subject: Re: [occi-wg] Syntax of OCCI API Once we get the noun/verb/attribute part settled, there is no harm in doing an ini and a key/val binding. In fact, a translator would be trivial... You can argue endlessly about the better format: there are too many PROs and CONs for both of them to come to an conclusive answer, IMHO. My $0.02, Andre.

15 69

ElasticHosts introduction
by Chris Webb 21 Apr '09

21 Apr '09

Quick intro: I'm Chris Webb, CTO of ElasticHosts, and I designed the ElasticHosts API (see http://www.elastichosts.com/products/api for docs) which has been well-received by users and integrators for its clarity and simplicity. See for example Ignacio's comments on ElasticHosts integration with OpenNebula: http://www.ogf.org/OGF25/materials/1567/OpenNebula.pdf We've been discussing API standardisation with Randy Bias from GoGrid for a little while, and Alexis and Sam have been encouraging us to get involved now the OCCI group is properly underway. One of our key design goals was that it be possible to describe our complete API in a couple of pages, and interface to it in a couple of lines of shell script without proprietary tools. I strongly believe that producing an heavyweight, overengineered API which doesn't satisfy this aim completely fails end users. We wrote some thoughts on this on our website in a New Year's blog posting: http://www.elastichosts.com/blog/2009/01/01/designing-a-great-http-api/ and some more general points in a submission to the working group for cloud infrastructure API standardization at OGF25: http://www.elastichosts.com/blog/2009/03/03/cloud-api-standardization-at-og… We're looking forward to discussing these issues with the newly formed group, and I'm about to follow up on some of work the group has done to date and some of the major issues. Cheers, Chris.

10 50

[Invitation] OCCI-WG Conference Call @ Wed 22 Apr 16:00 – 17:00 (occi-wg@ogf.org)
by Sam Johnston 21 Apr '09

21 Apr '09

occi-wg(a)ogf.org, you are invited to Title: OCCI-WG Conference Call Time: Wed 22 Apr 16:00 – 17:00 (Time zone: Paris) Where: 203-418-3122 / 866-692-3163 (#9032568) Calendar: occi-wg(a)ogf.org Owner/Creator: samj(a)samj.net Other attendees: thijs.metsch(a)sun.com, llorente(a)dacya.ucm.es, alexis.richardson(a)gmail.com Description: Hi folks, This is a reminder for our concall tomorrow at 4pm CET, 9:00am CDT, 7:00am PST, 3:00pm BST. The dial-in options can be found below. All the best, -Thijs - Hide quoted text - -------- Forwarded Message -------- > From: Thijs Metsch > To: occi-wg(a)ogf.org > Subject: [occi-wg] OCCI concall Wednesday 4pm CET > Date: Wed, 15 Apr 2009 17:15:36 +0200 > > Hi @all, > > I'm pleased to announce our first (from now on) weekly concall. It will > take place next Wednesday @ 4pm CET. > > The agenda is currently set to: > > 1. Introduction > 2. Use cases and Requirements > 3. Technical API discussion. > > If you like more topics or have more ideas feel free to add them to our > issue tracker at our sourceforge page: > http://forge.ogf.org/sf/tracker/do/listTrackers/projects.occi-wg/tracker > > The passcode and the dial-in options are below. > > All the best, > > -Thijs > > Passcode: > Participant: 9032568 > > > Dial in numbers: > > Country Toll Numbers Freephone/Toll Free Number > > ARGENTINA 0800-777-0463 > AUSTRALIA ADELAIDE: 61-8-8121-4868 1-800-249-288 > AUSTRALIA BRISBANE: 61-7-3102-0970 1-800-249-288 > AUSTRALIA CANBERRA: 61-2-6100-1970 1-800-249-288 > AUSTRALIA MELBOURNE: 61-3-9010-7739 1-800-249-288 > AUSTRALIA PERTH: 61-8-9467-5249 1-800-249-288 > AUSTRALIA SYDNEY: 61-2-8205-8125 1-800-249-288 > AUSTRIA 43-1-92-86-506 0800-005-029 > BELGIUM 32-1-150-0314 0800-4-8680 > BRAZIL 0800-7610674 > CHILE 1230-020-2867 > CHINA* 86-400-810-4766 10800-712-1433 > 10800-120-1433 > COLOMBIA 01800-9-156430 > CZECH REPUBLIC 420-2-25-98-56-54 800-700-173 > DENMARK 45-7014-0280 8088-6132 > ESTONIA 800-011-1089 > FINLAND Land Line: 106-33-146 0-800-1-10100 > FINLAND Mobile: 09-106-33-146 0-800-1-10100 > FRANCE LYON: 33-4-26-69-12-81 080-563-9647 > FRANCE MARSEILLE: 33-4-86-06-00-81 080-563-9647 > FRANCE PARIS: 33-1-70-70-74-20 080-563-9647 > GERMANY 49-69-2222-2566 0800-000-3441 > GREECE 30-80-1-100-0683 00800-12-6973 > HONG KONG 852-2286-5731 800-930-705 > HUNGARY 06-800-18013 > INDIA 000-800-852-1266 > INDONESIA 001-803-011-3787 > IRELAND 353-1-247-5253 1800-932-145 > ISRAEL 1-80-9214916 > ITALY 39-02-3600-3642 800-986-570 > JAPAN OSAKA: 81-6-7739-4769 0034-800-400828 > JAPAN TOKYO: 81-3-5539-5189 0034-800-400828 > LATVIA 8000-3025 > LUXEMBOURG 352-27-000-1360 > MALAYSIA 1-800-80-2812 > MEXICO 001-866-627-0574 > NETHERLANDS 31-20-718-8533 0800-020-1392 > NEW ZEALAND 64-9-970-4769 0800-449-823 > NORWAY 47-21-59-00-59 800-15414 > PANAMA 011-001-800-5072129 > PERU 0800-53733 > PHILIPPINES 63-2-858-3715 > POLAND 00-800-1212021 > PORTUGAL 8008-14061 > RUSSIA 8-10-8002-9683011 > SINGAPORE 65-6883-9228 800-120-4662 > SLOVAK REPUBLIC 421-2-322-422-21 > SOUTH AFRICA 080-09-80416 > SOUTH KOREA 82-2-6744-1081 00798-14800-6860 > SPAIN 34-91-414-62-98 800-099-810 > SWEDEN 46-8-505-78-524 0200-890-106 > SWITZERLAND 41-44-580-4389 0800-001-523 > TAIWAN 886-2-2795-7377 00801-137-766 > THAILAND 001-800-1206-65656 > UNITED KINGDOM BIRMINGHAM: 44-121-210-9021 0808-238-6025 > UNITED KINGDOM GLASGOW: 44-141-202-3221 0808-238-6025 > UNITED KINGDOM LEEDS: 44-113-301-2121 0808-238-6025 > UNITED KINGDOM LONDON: 44-20-7075-3246 0808-238-6025 > UNITED KINGDOM MANCHESTER: 44-161-601-1421 0808-238-6025 > URUGUAY 000-413-598-3415 > USA 1-203-418-3122 866-692-3163 > VENEZUELA 0800-1-00-3733 > -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com _______________________________________________ occi-wg mailing list occi-wg(a)ogf.org http://www.ogf.org/mailman/listinfo/occi-wg You can view this event at http://www.google.com/calendar/event?action=VIEW&eid=MXNwOWMxa2FtY2RmYjdoMW… You are receiving this courtesy email at the account occi-wg(a)ogf.org because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively, you can sign up for a Google account at http://www.google.com/calendar/ and control your notification settings for your entire calendar.

1 0

Howdy
by Tim Bray 21 Apr '09

21 Apr '09

Thijs told me about this project and asked me to stick my head in. Since I know nothing about the discussion to date, I'll shut up and listen. My opinions on cloud APIs may be found at http://kenai.com/projects/suncloudapis but they're a moving target. - Tim Bray

3 2

Resource Types: Compute / Network / Storage
by Sam Johnston 20 Apr '09

20 Apr '09

Evening, So one thing I did see validated by the rm-wg document was the trend towards compute/network/storage that we're fast settling on ourselves. Our current terminology however is far more specific - we've picked up "Drive" and "Server" from ElasticHosts for example. While this does make sense a lot of the time there's nothing to say that OCCI can't be used for VDI for example, where the "servers" are in fact "clients". Take it a step further and you've got things like Dreamhost PS<http://dreamhost.com/hosting-vps.html>which kind of like a virtual provate server in that it behaves like one (it can be restarted via their API<http://wiki.dreamhost.com/API#dreamhost_ps-reboot>etc.), only it refers to resource allocations in a shared hosting environment or MySQL instances. Granted that's outside of our remit but ther'es no point stopping them from using it by choosing our terminology poorly. In fact a lot of these functions can apply equally to physical machines as they can to lightweight threads in an Apache process (and everything in between including, of course, virtual machines which are currently our primary target). I've been trying to think of other resources outside of these three main types but even strange things like ISDN interfaces (yes, this sort of thing does appear in enterprise data centers) can be handled via PCI passthrough parameters on a virtual machine. All in all, unless anyone has any concerns about this approach I'd like to adopt this terminology throughout. Sam

8 37

OCCI Week 2
by Alexis Richardson 19 Apr '09

19 Apr '09

Hi all, This coming week takes this working group into its second 'working week' and brings us to our first con call, which iirc is on Wednesday. It seems to me that we have already made some progress and I would like to understand what our top three 'to do' items are. Sam, As group secretary please could you summarise: * what we have *provisionally* agreed on thus far * what we are more or less agreeing on, that needs further discussion (eg #verbs) * what we have parked to come back to in the nearish term (eg Formats) * what we have not discussed that may be in scope for the OCCI pre-draft to be presented at the next OGF alexis

1 0

Re: [occi-wg] Resource Types: Compute / Network / Storage
by Sam Johnston 19 Apr '09

19 Apr '09

Chris, Good to see I'm not the only one working [early] Sunday mornings :) On Sun, Apr 19, 2009 at 10:39 AM, Chris Webb <chris(a)arachsys.com> wrote: > > I'm happy with any reasonable choices here, except that to avoid an ugly > API, whatever set of words we pick should be single shortish words (not > multiple words, and preferably not abbreviations) of a grammatically > equivalent type: > > compute, storage, networking > > work, as do > > {computers,guests,instances,servers,machines}, {stores,drives}, networks > > but mixing between the groups is less good---I can create 'a drive' or 'a > computer' but not 'a compute'. Whatever happens, we don't want to leave an > illiterate legacy like HTTP's ghastly 'Referer:' header! The *resources* themselves that we are managing are compute/storage/network, but if you take a look at the registries<http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Registries>you will see that I have sub-types: TypeSub-typeDescription computephysical-machinePhysical machine compute virtual-machineVirtual machine computesliceVirtual private server, container, zone, etc. networkphysical-networkPhysical network segment networkvirtual-networkVirtual network segment networkload-balancerLoad balancer device storagedriveHard disk drive storagesnapshotA snapshot of a storage resource at a point in time Hope that helps. Sam

1 0

Standards Matter: The Battle For Interoperability Goes On
by Sam Johnston 18 Apr '09

18 Apr '09

[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…>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…>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=…>format, which standardizes the virtual machine<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=virtual%20machine…> 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%20managem…>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=…>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=…>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=&…>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%20Offic…>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.

1 1

Acknowledgements
by Sam Johnston 17 Apr '09

17 Apr '09

Evening all, I have added an Acknowledgements section to the bottom the main APIDesign<http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/APIDesign>wiki page and added some arbitrary names to it. If yours wasn't one of them then be sure to add yourself when you next update the page (you have signed up <http://forge.ogf.org/sf/sfmain/do/createUser> and joined the project<http://forge.ogf.org/sf/sfmain/do/joinProject/projects.occi-wg>, right?) Good weekend, Sam

1 0

APIs for cloud computing
by Alexis Richardson 17 Apr '09

17 Apr '09

All, Please see the following matrix contributed by Patrick Kerpan from CohesiveFT. http://spreadsheets.google.com/ccc?key=pGccO5mv6yH8Y4wV1ZAJrbQ It lists operations that might appear in a cloud services API, and how some of the known APIs implement those operations (if at all). The idea is to be a reference point for understanding OCCI needs. It is not a substitute for work to create OCCI. If you wish to have write access to this document, please contact Pat directly. alexis

5 13