June 2010 - occi-wg - lists.ogf.org

Cloud Demo call today
by Mark Carlson 07 Jul '10

07 Jul '10

What: Cloud Demo coordination planning When: Wednesdays: 8amPT/9amMT/11amET Where: Audio conference information: Toll Free: (866) 682-4770 International: +1 (408) 774-4073 Conference Code: 1212488 Security Code: 1212 Agenda: Planning for next demo - SNIA summer symposium: http://www.snia.org/events/summersymp2010 Other venues? SDC OGF 30 What do we want to add to the demo functionality? Google Group for Cloud Demo http://groups.google.com/group/cloud-demo

1 1

Reminder: concall in one hour - 10am EDT, 4pm CET, 3pm BST
by Thijs Metsch 30 Jun '10

30 Jun '10

Hi, Just a quick reminder: our concall starts in one hour... Audio conference information: Toll Free: (866) 682-4770 <tel:(866)%20682-4770> International: +1 (408) 774-4073 <tel:+1%20(408)%20774-4073> Conference Code: 1212488 Security Code: 1212 Other international toll free numbers: http://www.intercall.com/oracle/access_numbers.htm Cheers, -Thijs

1 0

[occi] push by tmetsch - fixed issue 41 on 2010-06-01 10:26 GMT
by occi＠googlecode.com 30 Jun '10

30 Jun '10

Revision: e3d1f0d2c2 Author: tmetsch Date: Tue Jun 1 03:24:17 2010 Log: fixed issue 41 http://code.google.com/p/occi/source/detail?r=e3d1f0d2c2 Modified: /docs/occi-infrastructure.xml /docs/occi-infrastructure_book.xml /docs/ogf_template.xsl ======================================= --- /docs/occi-infrastructure.xml Tue Jan 12 01:29:18 2010 +++ /docs/occi-infrastructure.xml Tue Jun 1 03:24:17 2010 @@ -179,7 +179,7 @@ <entry>Float (10^9 bytes)</entry> - <entry>RAM in megabytes (e.g. 16, 0.512)</entry> + <entry>RAM in gigabytes (e.g. 1, 0.512)</entry> </row> <row> @@ -416,7 +416,14 @@ <title>Storage</title> <para>A storage resource is capable of mass storage of data (e.g. a - virtual hard drive).</para> + virtual hard drive). </para> + + <note> + <para>The actions defined here should trigger operations on e.g. + virtual images. The implementation of these operations is left to + Cloud Storage APIs and the corresponding Storage backend + solutions.</para> + </note> <section> <title>Attributes</title> ======================================= --- /docs/occi-infrastructure_book.xml Tue Jan 12 04:29:36 2010 +++ /docs/occi-infrastructure_book.xml Tue Jun 1 03:24:17 2010 @@ -46,11 +46,14 @@ </listitem> <listitem> - <para>OCCI XHTML5 rendering</para> + <para>OCCI HTTP Header rendering</para> </listitem> <listitem> - <para>OCCI HTTP Header rendering</para> + <para>(OCCI XHTML5 rendering)<footnote> + <para>The OCCI XHTML5 rendering will be released in near + future.</para> + </footnote></para> </listitem> </itemizedlist> @@ -74,10 +77,10 @@ <section> <title>Contributors</title> - <para>The following people have contributed to this document.</para> + <para>The following people edited this document.</para> <table> - <title>List of contributors</title> + <title>List of editors</title> <tgroup cols="3"> <thead> @@ -102,7 +105,7 @@ <row> <entry>Sam Johnston</entry> - <entry>Australian Online Solutions</entry> + <entry>Google</entry> <entry>samj(a)samj.net</entry> </row> @@ -110,11 +113,32 @@ <row> <entry>Thijs Metsch</entry> - <entry>Sun Microsystems - RESERVOIR project</entry> - - <entry>thijs.metsch(a)sun.com</entry> + <entry>Sun Microsystems - RESERVOIR project, Platform + Computing</entry> + + <entry>tmetsch(a)platform.com</entry> </row> - + </tbody> + </tgroup> + </table> + + <para>The editors would like to thank the following contributors:</para> + + <table> + <title>List of contributors</title> + + <tgroup cols="3"> + <thead> + <row> + <entry align="center">Name</entry> + + <entry align="center">Affiliation</entry> + + <entry align="center">Contact</entry> + </row> + </thead> + + <tbody> <row> <entry>Gary Mazzaferro</entry> @@ -122,6 +146,22 @@ <entry>garymazzaferro(a)gmail.com</entry> </row> + + <row> + <entry>Shlomo Swidler</entry> + + <entry>Orchestratus</entry> + + <entry>shlomo.swidler(a)orchestratus.com</entry> + </row> + + <row> + <entry>Michael Behrens</entry> + + <entry>R2AD</entry> + + <entry>michael.behrens(a)r2ad.com</entry> + </row> </tbody> </tgroup> </table> @@ -161,7 +201,8 @@ <section> <title>Full Copyright Notice</title> - <para>Copyright (C) Open Grid Forum (2009,2010). All Rights Reserved.</para> + <para>Copyright (C) Open Grid Forum (2009,2010). All Rights + Reserved.</para> <para>This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or ======================================= --- /docs/ogf_template.xsl Thu Jan 14 05:30:01 2010 +++ /docs/ogf_template.xsl Tue Jun 1 03:24:17 2010 @@ -20,28 +20,34 @@ <xsl:param name="chapter.autolabel"> 1 </xsl:param> <xsl:param name="section.autolabel.max.depth"> 4 </xsl:param> - - <xsl:param name="shade.verbatim" select="1"></xsl:param> + + <xsl:param name="shade.verbatim" select="1" /> <xsl:attribute-set name="xref.properties"> <xsl:attribute name="font-family">serif</xsl:attribute> + <xsl:attribute name="font-size">8pt</xsl:attribute> + <xsl:attribute name="font-style">italic</xsl:attribute> </xsl:attribute-set> - +  + <xsl:attribute-set name="monospace.verbatim.properties"> <xsl:attribute name="wrap-option">wrap</xsl:attribute> + <xsl:attribute name="hyphenation-character">\</xsl:attribute> </xsl:attribute-set>  + <xsl:attribute-set name="admonition.properties"> <xsl:attribute name="border">0.5pt solid black</xsl:attribute> + <xsl:attribute name="padding">0.1in</xsl:attribute> </xsl:attribute-set> -  +  <xsl:attribute-set name="root.properties"> <xsl:attribute name="font-family">sans-serif</xsl:attribute> @@ -103,7 +109,8 @@ </xsl:attribute-set>  -<!-- + + <!-- <xsl:template match="para[parent::section or parent::chapter]"> <fo:block xsl:use-attribute-sets="normal.para.spacing"> <xsl:call-template name="anchor" /> @@ -147,7 +154,7 @@ </fo:block> <fo:block> - <xsl:text>Jan. 12, 2010</xsl:text> + <xsl:text>Jun. 1, 2010</xsl:text> </fo:block> </xsl:when> </xsl:choose>

7 8

RDF, RDFa and HTML
by Edmonds, AndrewX 25 Jun '10

25 Jun '10

Hi all, I've been looking into how OCCI can expose itself through a HTML serialization and to demarcate machine readable, semantic content. To demarcate that content we already decided that we would use RDFa [1]. In order to truly and correctly use RDFa we need to be able to point to the ontology (model) in which subject, predicate and object triplets are defined. Defining the ontology is somewhat easy, we have it already with the OCCI model; it's just a matter of expressing it in RDF. With an ontology in hand, we can define semantically marked-up HTML with the ontology's vocabulary using the facilities of RDFa. I've worked on 2 ways of expressing the OCCI model in RDF. 1. Using python [2]. 2. Using a modeling tool (Protégé) [3][4][5]. Note these owl files may need their imports modified in Protégé. The only difference in the two is that occi.owl (core spec), occi-infrastructure.owl (infrastructure spec) and occi-sla-at-soi.owl (SLA@SOI extensions) are defined in separate files with the Protégé approach. This should give folks an idea of how extensions for OCCI can be introduced. However in both examples, occi-core, occi-infrastructure and slasoi-infrastructure are separated by namespace. As RDFa does not explicitly define a rigorous structure for HTML documents, and it shouldn't, we need to be able to express 2 basics forms: 1. A concrete OCCI Kind instance (Compute, Storage, Network). I have an example here [6]. 2. A collection of OCCI Kind instances. I have an example here [7]. In this example values of objects are exposed using the 'content' RDFa attribute [8]. Each example may not be 100% perfect but what's most interesting is when you run the each HTML rendering through a RDFa parser [9] (examples here [10] [11]). The RDF extracted is quite along the lines of what some might expect an OCCI POX format to be. Note, I'm not advocating POX, just pointing to the flexibility of RDFa. There are still some aspects to be worked out but I will follow up on these in a separate mail (this one is long enough!). If you want to see how all of this visually looks then see here: ontology only [12], ontology and graph instance [13]. I'd really appreciate and love to hear people's comments, opinions on this! :-) Andy [1] http://www.w3.org/TR/rdfa-in-html/ [2] http://dl.dropbox.com/u/165239/occi-rdf.py [3] http://dl.dropbox.com/u/165239/occi.owl [4] http://dl.dropbox.com/u/165239/occi-infrastructure.owl [5] http://dl.dropbox.com/u/165239/occi-sla-at-soi.owl [6] http://home.edmonds.be/occi-html5-rdfa-one.html [7] http://home.edmonds.be/occi-html5-rdfa-list.html [8] http://www.w3.org/TR/2010/WD-rdfa-core-20100422/#s_syntax [9] http://www.w3.org/2007/08/pyRdfa [10] http://www.w3.org/2007/08/pyRdfa/extract?uri=http%3A%2F%2Fhome.edmonds.be%2… [11] http://www.w3.org/2007/08/pyRdfa/extract?uri=http%3A%2F%2Fhome.edmonds.be%2… [12] http://dl.dropbox.com/u/165239/occi-rdf-graph-rev2.png [13] http://dl.dropbox.com/u/165239/occi-rdf-graph-inst-rev2.png ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

3 6

OCCI documents and IPR
by Joel Replogle 24 Jun '10

24 Jun '10

Dear OCCI Working Group, Following recent emails, I would like to assure the OCCI Working Group and all contributors that the documents that have been produced by OCCI in accordance with OGF policies do indeed retain the OGF IPR. OGF IPR Policy protects every contributor by ensuring that all contributions have been made in good faith in the spirit of open collaboration with up-front disclosure of any licensing encumbrances. It also protects implementors so that implementations may be made with confidence based on persistent specifications which will have neither content nor licensing changed retroactively. These protections are clearly identified in OGF's IPR Policy, and are explicitly agreed to whenever someone contributes to OGF work by opening a GridForge account, joining an OGF mailing list, or attending an OGF working group session by phone or in person. The full policy may be found here: http://www.ogf.org/merger_docs/OGFIPRPolicy.pdf If anyone has patent claims or other encumbrances to their individually contributed portions that were not disclosed at the time of contribution, please contact me, the OGF Executive Director. Note that I have received no such communications to date, nor were any objections raised during the open Public Comment period of the group's documents. Additionally, I would like to congratulate the OCCI-WG on the very well-received demo at OGF29 and look forward to your continued success in support of the OGF mission. Well done! Thanks, Joel -------------------------------------------------------------------- Joel Replogle Executive Director, OGF replogle(a)ogf.org http://www.ogf.org PO Box 1738 T: +1-765-228-9068 Muncie, IN 47308 USA F: +1-815-927-6284 Upcoming Events: OGF29 * June 20-22, 2010 * Chicago * www.ogf.org/OGF29 OGF30 * October 25-29, 2010 * Brussels * www.ogf.org/OGF30

1 0

OCCI-POX experiment a concept
by Csom Gyula 24 Jun '10

24 Jun '10

Hi! We've made some progress with our OCCI-POX experiment I'd like to share here. Please find attached an early draft that outlines the goals and detailed scope of our effort. Note also that we are pleased to see the progress of the XHTML/RDFa rendering format [1]. Though we understand that POX is not an accepted rendering solution we are very interested in the possible convergence of the 2 formats. We've found the RDF(a) direction so promising that we've decided to drop our original idea in favour of that. Instead of working on a 100% clean, domain-specific OCCI-POX schema, we will try to create a RDF/XML one that is compatible with the upcomming XHTML/RDFa format. See the attached document for more. Since the working draft is just an early version we will likely refine it. As always any feedback including critiques is more than welcome. Kind regards, Gyula Csom --- [1] RDF, RDFa and HTML by Edmonds, Andrew: http://www.ogf.org/pipermail/occi-wg/2010-June/003758.html ________________________________________ Feladó: Alexis Richardson [alexis.richardson(a)gmail.com] Küldve: 2010. május 24. 22:17 Címzett: Csom Gyula Másolatot kap: occi-wg(a)ogf.org Tárgy: Re: [occi-wg] Request for POX representation a refined proposal I would be very interested in seeing reference implementations of this proposal, even if they were experimental. alexis 2010/5/24 Csom Gyula <csom(a)interface.hu>: > Hi, > thank you for your response and especially thanks Gary for outlining the current RDFa directions. > > Based on your feedback we refined our request. First let me put some more details about our background and the > decision we made, then I'd like to introduce our refined proposal. > > > ## 1./ Background > As I've already outlined in my original email our customer's been interested in a long term solution. That has > basically meant reliability and maintanable development. Here I'd like to reveal some additional details on > our requirements. Though we will specify the detailed interface requirements at the next month, the basic > features are already outlined. > > * Users: The system should serve as a public cloud for the academic sector and as a private cloud for our > customer's own needs. The cloud interface should support both end users and administrators. > > * Functionality: The cloud management system's core should provide a programmatic interface that exposes > remote management functionality to the consuming client applications. We should deal with 2 types of > applications: one for the end users (which might mean Web GUI but others as well) and one for the system > administrators (which means CLI and administration scripts). > > * Architecture: In order to support both the above feature and ease of maintanance the core should provide > a solid server API and a layered client design that clearly separates presentation from logic, ie. the > client UI should be built on top of a clean client API. Besides ease of maintanance the latter should also > enable us to build different tpye of applications/UIs adhering to different type of end user needs and > should also provide us a scriptable interface for administration purposes. > > I attached a sample architecture diagram that illustrates the above concept [1]. > > > ## 2./ Decision > Basically we do not trust in XHTML + RDFa to serve as a general purpose remote management API in the above manner. > Especially we do not think that a general purpose robust and maintanable client driver could be built against > it. This is a general concern of us not specific to XHTML except for the fact that it is an UI format. Instead > we'd like to build our client-server architecture upon a clean and solid API. We consider the following as a > technical minimum in order to achieve our goals outlined above: > > * We are looking for an open client-server protocol that uses a common payload format, has no or little external > dependencies and especially is free from the UI. > > Note that though we prefer POX due to our platform selection this is not a strict requirement from us. The basic > point is not POX, but the clean programmatic interface outlined above. That is to say we prefer XML as the > payload format, but we could adapt to another reasonable format as well. > > > ## 3./ Proposal > Meanwhile we do understand that you're are bound to your working group charter and it might be impossible to > fulfill our request within the current specification session. Hence we refined our original concept and propose > the following: > > * Let's give our conservative approach a try. If accepted we would create a draft proposal and a reference > implementation around the POX format. Then OCCI could simply monitor our efforts and make its decision based > upon the results. > > We think it can be a win-win situation where OCCI has nothing to lose. If it turned out that our approach was a > niche then OCCI could simply ignore our efforts. Meanwhile if it turned out that there was a general community need > for such a format then OCCI backed by a draft proposal and working prototype would be in a good position to fulfill > this need. > > > I hope that here I could better expose our intentions and reasons and basically they are inline with your goals. I > also hope that our proposal meets your policies and will be accepted by the working group. > > Looking forward to your response, > > Kind regards, > Gyula Csom > > Ps.: Besides our general concern there's also a special issue related to XHTML that we do not want to deal with in > the core API. According to W3C XHTML has just entered a long term transitional period: XHTML v.1 [2] and v.2 [3] has > been recently dropped in favour of X/HTML5, meanwhile X/HTML5 is assumed to reach reccommendation stage only at 2022 > or later [4]. Generally we do not want to mix business logic with UI at all and especially not with an UI format that > is in the begining of such a long transitional period. > > --- > > [1] arch.png attached to this email is a simple diagram to illustrate the above architectural concept. > > [2] XHTML 1.x is dropped: "W3C does not at this time plan to allocate resources to the maintenance of XHTML 1.1, > XHTML 1.1 Basic, and XHTML Print beyond the current round of revisions. W3C does not plan to revise the XHTML 1.0 > Recommendation." http://www.w3.org/2009/06/xhtml-faq.html#deli > > [3] XHTML 2 is dropped: "Today the Director announces that when the XHTML 2 Working Group charter expires as > scheduled at the end of 2009, the charter will not be renewed. " http://www.w3.org/News/2009#item119 > > [4] When will HTML5 be finished? "It is estimated by the editor that HTML5 will reach the W3C Candidate > Recommendation stage during 2012. [..] It is estimated, again by the editor, that HTML5 will reach a W3C > recommendation in the year 2022 or later." http://wiki.whatwg.org/wiki/FAQ#When_will_HTML5_be_finished.3F > > _______________________________________________ > occi-wg mailing list > occi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/occi-wg > >

1 0

No Cloud Demo Call today
by Mark Carlson 22 Jun '10

22 Jun '10

Great job folks. A very successful demo this week at OGF. We'll keep churning on the demo leading up to our next showing in July at the SNIA Summer Symposium. We will start planning this at next week's meeting. -- mark

1 0

To all the members of the OCCI WG
by Steven Newhouse 18 Jun '10

18 Jun '10

This is perhaps one of the saddest days in the many years that OGF/GGF has acted as an umbrella for standards collaboration. As a community, we have never had to deal with a situation where an individual has repeatedly chosen to act in a divisive manner, ignoring the wishes and contributions of the majority of their colleagues in a working group, and ignoring the processes and rules that they themselves signed up to when they began contributing. This situation is not really about standards or about the rights and wrongs of IP policies, where cloud standards should evolve or whatever. It's about trust. It's about trusting your working group members to respect their colleagues and their colleagues' contributions and opinions, it's about trusting that someone will adhere to the express commitments they made when they joined the community. The chairs of the OCCI working group, and lots of members of the OGF community, have, on many occasions worked with Sam to try and achieve our shared goal of a well defined and implemented OCCI specification. This work is of fundamental importance to the OGF community and to the broader cloud community. Sam's contributions have been exceptional, but this specification is, and will be, the result of team work, of contributions ranging from active writing of the content, to debate about it that improves its quality, to implementation and so forth. This work is the result of the labours of many, no matter how great the contribution of one. It is the community that validates the work, that ensures its quality and that results in implementations. That community is the OCCI Working Group. It is not Sam Johnston. There are many imperfections in any and all communities or organisations, including OGF. But OGF remains one of the easiest within which to work, to collaborate, to validate and to implement. Sam has decided that it is not for him, which is his right, and which we respect. Regrettably the chairs of the group, with the unanimous approval and support of the community's elected leaders, have decided that Sam can no longer act as secretary of the working group. He has become impossible to work with. Nonetheless we thank him whole heartedly for his contributions, in spite of this situation. And, should he wish to continue to collaborate under the same set of rules that he and the rest of the working group signed up to when they joined, he will be most welcome. In the meantime the OCCI working group will continue, as will its work. We will do what is required to move our specification forward and we expect to reengage many past contributors who had found engagement difficult. The OGF community's leaders continue to stand in full support of the OCCI working group chairs, the working group they help lead and the work that this group undertakes. Let's move on! Steven Newhouse OGF Board Chairman

2 1

Fwd: How I tried to keep OCCI alive (and failed miserably)
by Sam Johnston 18 Jun '10

18 Jun '10

---------- Forwarded message ---------- From: Sam Johnston <samj(a)samj.net> Date: Thu, Jun 17, 2010 at 9:25 PM Subject: [Sam Johnston] How I tried to keep OCCI alive (and failed miserably) I was going to let this one slide but following a calumniatory missive<http://www.ogf.org/pipermail/occi-wg/2010-June/001867.html>to his "followers" by the Open Cloud Computing Interface <http://www.occi-wg.org/>'s self-proclaimed "Founder & Chair", Sun refugee Thijs Metsch <http://twitter.com/befreax>, I have little choice but to respond in my defense (particularly as "The Chairs" were actively soliciting <http://twitter.com/dizz/status/16397788487>followup from others on-list in support). Basically a debate came to a head that has been brewing on- and off-list<http://www.ogf.org/pipermail/occi-wg/2010-March/001703.html>for months regarding the Open Grid Forum (OGF) <http://www.ogf.org/>'s attempts to prevent me from licensing *my own contributions* (essentially the entire normative specification) under a permissive Creative Commons<http://www.creativecommons.org/>license (as an additional option to the restrictive OGF license <http://www.ogf.org/About/abt_policies_copyright.php>) and/or submit them to the IETF as previously agreed and as required by the OGF's own policies <http://www.ogf.org/documents/GFD.1.pdf>. This was on the grounds that "*Most existing cloud computing specifications are available under CC licenses and I don't want to give anyone any excuses to choose another standard over ours*" and that the IETF has an excellent track record of producing high quality, interoperable, open specifications by way of a controlled yet open process. This should come as no surprise to those of you who know I am and will always be a huge supporter of open cloud, open source and open standards. The OGF process had failed to deliver after over 12 months of deadline extensions - the current spec is frozen in an incomplete state (lacking critical features like collections, search, billing, security, etc.) as a result of being prematurely pushed into public comment, nobody is happy with it (including myself), the community has all but dissipated (except for a few hard core supporters, previously including myself) and software purporting to implement it actually implements something completely different altogether (see for yourself<http://www.opennebula.org/documentation:rel1.4:occidd>). There was no light at the end of the tunnel and with both OGF29<http://www.gridforum.org/OGF29/>and IETF78 <http://www.ietf78.nl/home.html> just around the corner I yesterday took a desperate gamble to keep OCCI alive (as a CC-licensed spec, an IETF Internet-Draft or both). I confirmed that I was well within my rights to revoke any copyright, trademark and other rights previously granted (apparently it was amateur hour as OGF had failed to obtain an irrevocable license from me for my contributions) and volunteered to do so if restrictions on reuse by others weren't lifted and/or the specification submitted to the IETF process as agreed and required by their own policies. Thijs' colleague (and quite probably his boss at Platform Computing <http://www.platform.com/>), Christopher Smith (who doubles as OGF's outgoing VP of Standards) promptly responded, questioning my motives (which I can assure you are pure) and issuing a terse legal threat about how the "OGF will protect its rights" (against me over my own contributions no less). Thijs then followed up shortly after saying that they "see the secretary position as vacant from now on" and despite claims to the contrary<http://twitter.com/papaspyrou/status/16403013420>I really couldn't give a rats arse about a title bestowed upon me by a past-its-prime organisation struggling (and failing I might add) to maintain relevance. My only concern is that OCCI have a good home and if anything Platform have just captured the sort of control over it as VMware enjoy over DMTF/vCloud, with Thijs being the only remaining active editor. I thought that would be the end of it and had planned to let sleeping dogs lie until today's disgraceful, childish, coordinated and most of all completely unnecessary attack<http://www.ogf.org/pipermail/occi-wg/2010-June/001867.html>on an unpaid volunteer that rambled about "constructive technical debate" and "community driven consensus", thanking me for my "meaningful contributions" but then calling on others to take up the pitchforks by "welcom[ing] any comments on this statement" on- or off-list. The attacks then continued on Twitter with another OGF official<http://twitter.com/papaspyrou> claiming that this "*was a consensus decision within a group of, say, 20+ active and many many (300+) passive participants*" (despite this being the first any of us had heard of it) and then calling my claims of copyright ownership "*genuine bullshit*" and report of an implementor instantly pulling out because they (and I quote) "*can't implement something if things are not stable*" a "*damn lie*", claiming I was "*pissed*" and should "*get over it and stop crying*" (needless to say they were promptly blocked).* * Anyway as you can see there's more to it than Thijs' diatribe would have you believe and so far as I'm concerned OCCI, at least in it's current form, is long since dead. I'm undecided as to whether to revoke OGF's licenses at this time but it probably doesn't matter as they agree I retain the copyrights and I think their chance of success is negligible - nobody in their right mind would implement the product of such a dysfunctional group and those who already did have long since found<http://blog.opennebula.org/?p=185> alternatives <http://blog.opennebula.org/?p=528>. That's not to say the specification won't live on in another form but now the OGF have decided to go nuclear it's going to have to be in a more appropriate forum - one that furthers the standard rather than constantly holding it back. *Protip*: None of this has anything to do with my current employer so let's keep it that way. -- Posted By Sam Johnston to Sam Johnston<http://samj.net/2010/06/how-i-tried-to-keep-occi-alive-and.html>at 6/17/2010 09:25:00 PM

2 3

Revocation of licenses
by Sam Johnston 18 Jun '10

18 Jun '10

In consideration of the subsequent responses from two OGF officials and in the absence of any form of remorse or apology for earlier personal attacks by another, any and all copyright, patent and/or trademark licenses that may have been previously extended relating to OCCI (specification, logo, etc.) are hereby revoked. All contributions continue to be available under a Creative Commons Attribution Share Alike 3.0 <http://creativecommons.org/licenses/by-sa/3.0/>license which guarantees freedoms that the OGF copyright <http://www.ogf.org/About/abt_policies_copyright.php> deliberately and unjustifiably restricts, including but not limited to the right to reuse. I wish you the best of luck in putting the specification to good use under these terms, but publish under another license at your peril. Kind regards, Sam

2 1