I was on Wednesday's call, but here are the points that I made written out as well. They are mostly the same as I made on 18th August in my post http://www.ogf.org/pipermail/occi-wg/2009-August/001113.html There was some discussion at that point, but not much seems to have been integrated. Page 4-5, paragraphs 13-24 Page 8, paragraph 29 We define 3 OCCI formats in page 12, paragraph 61: text/occi, application/occi+atom, application/occi+json. As described, Create is form-encoded, Retrieve is in application/occi+X, Update is in application/occi+X(?), Delete doesn't need a format, and Requests are form-encoded. I'd like us to also support application/occi+X for Create and Requests so that it's possible to write a client which only knows about a single format rather than having to implement at least two (form + one occi+X). Page 8, paragraph 43 Page 18, paragraph 78 I can't find any actual actions listed anywhere in this document. Are they defined yet? We need things like stop and start for servers, etc. as discussed when we used to call these verbs in a state machine. Page 10, paragraph 52 "Where an operation returns multiple resources ..." to be replaced with "Where an operation COULD return multiple resources..." to make it clear that a collection is always returned, even if there is a single result. Page 10, paragraph 56-57 Page 18, paragraph 79 I'd like to see a more detail in one of these places on specifying the details of a link between compute and network - e.g. which interface does the network appear on (eth0, eth1, etc?), which static IPs are available to a customer and which will be used on this interface? Will we specify canonical interface names for OCCI or allow each cloud to chose its own (eth0 vs. Local Area Network, etc.)? Page 10, paragraph 56-57 Page 18, paragraph 80 Similarly, I'd like to see more detail in one of these places on specifying the details of a link between compute and storage - e.g. which interface does the storage appear on (sda, sda, etc?), which of multiple storage resources is the boot device? Will we specify canonical interface names for OCCI or allow each cloud to chose its own (sda vs hda vs C:, etc.)? Page 17, paragraph 76 In my use cases, I don't see much value for raw hostnames of network or storage resources. Perhaps make this optional or for compute only? Or perhaps generalize it from just a hostname to a full URL - I can imagine having some kind of web interface for directly accessing a network or storage resource? Page 18, paragraph 78 Page 19, paragraph 80 Compute and storage resources need better status and support for being transient or persistent (a cloud could support both models, so needs to be told which a given resource will be, since the semantics are different when a server shuts down). I'd suggest: - Compute: add a 'status', which is 'active', 'stopped', etc. - Compute: add a 'compute.type'? which is Enum(transient, persistent). - Storage: add a 'status' which is 'mounted', 'inactive', etc. - Storage: reliability isn't the same as transient/persistent. A persistent storage is one which isn't destroyed when the compute shuts down. It could still be on RAID, local disk, SAN, etc. So split out 'storage.type'? which is Enum(transient, persistent) from storage.reliability Page 19, table 7 You'll need to make storage.size a Float, like compute.memory.size to allow drives below 1 GB (e.g. CD images). Alternatively (and better in my view), you could turn all of Floats into integers and describe them in the basic units - bytes, hertz, etc. To take Gary's suggestion of supporting SI suffixes. Page 18, paragraph 78 Page 19, paragraph 80 I definitely feel that the compute.memory.speed, compute.memory.reliability and storage.reliability are less important than the other attributes described.