Hey Augusto, Thanks for the input, it’s very valuable :-) /snip The document is extremely interesting, and stimulating. I guess that if you'd organize a "hands-on" seminar on this way at some OGF you would fill-up the plenary room. Here following a few issues: "It should be noted that aspects such as authorisation and authentication are not dealt with in this document as these issues are orthogonal ones dealt with by other technologies" - (Executive Summary) Security aspects are not so orthogonal as one might want: a design that does not take into account from the beginning security aspects hardly succeeds to add them later on as a feature. In my opinion your document takes care of security aspects, but simply does not unfolds all the details. This needs to be qualified a little more. The statement is issued from the context of HTTP technologies. We leverage the design considerations in the HTTP protocol suite with respect security. If OCCI was exposed over a different transport then certainly considerations related to security would loom larger. "To support a live migration where there is little or no down-time of the service, the relevant capabilities (e.g. live migration across sub-nets) would need to be supported by the provider rather than the specifications." - (Service migration and redeployment) Obscure, but challenging. Would you mean that this requires internal operation (agreement) between providers more than the provision of uniform APIs? By obscure, do you mean that it is an edge use case? For a live-migration across service provider boundaries then yes agreement would be required. You could imagine this to be something similar to peering agreements between ISPs. Offline migration can be accomplished without such agreement but with support for the APIs discussed in the document. About Craig's e.mail One problem concerning virtual networks, and markedly VLANs, is the degree of control and monitoring the final user may have on the virtual networking infrastructure. I'm thinking to legacy Grid infrastructures re-deployed on IaaS, for instance. Indeed and it’s a growing nascent area in the context of “virtualization”. I know there are members of the FP7 SAIL project on the list with interests in possibly extending the current OCCI networking model – perhaps they may have further comment? Overall, I appreciate the document as is. Thank you for the effort in connecting so many relevant topics. And thanks for contributing! :-) Augusto 2011/6/21 Thijs Metsch <tmetsch@platform.com> Dear all, The DMTF APTS meeting in Boulder, CO last month has been a great a success [1]. And as one of the outcomes some of the OCCI-wg members wrote a document which describe how today's Cloud standards (CDMI, OVF and OCCI) can be used together to create a open Cloud. This document is now finally ready (Sorry for the delay) and by this email I would ask for your comments and thoughts on this documents. Many thanks, -Thijs [1] http://occi-wg.org/2011/05/25/occi-at-dmtf-apts/ _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg -- Augusto Ciuffoletti Dipartimento di Informatica Università di Pisa 56100 - Pisa (Italy) ------------------------------------------------------------- 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.