Hi Guys, I am really sorry, but I could not make it to the call today. Anyway, here is a list of feedback items for the version you discussed: - move table of contents after abstract - use MUST, SHOULD, MAY, CAN... should be uppercase - "Each implementation has a single OCCI end-point URL" should be 'each deployment' or 'each service'? - TIP, WARNING: are they normative? Like, the tip after Par. 54 contains a SHOULD. But I am asking about tips in general, not about this particular one. - "A simple peer review process is available for extending the registries" That process is not described, not referenced. - "This scalable approach..." not relevant, really - can go into footnote - sorry if this is a stupid question: why 'ETag' and not 'OCCI-ETag'? - "Category schemes and/or terms defined by this standard reside throughout the http:// purl.org/occi/" Why not using the ogf namespace? See http://www.ogf.org/documents/GFD.84.pdf and http://schemas.ogf.org/ Those items are additional to the items I sent before - honestly, I don't see many of those (old) issues resolved, yet (apart from the ones Sam clarified by mail, but even those should actually be clarified *in the document*. Anyway, the readability of the Core specification (section 3 in version circulated by Thijs) improved significantly - thats great. Or maybe its just me reading it again and again ;-) Hope that helps, Andre.

Hi guys,

below are a couple of notes on the specification document from my end, finally. They are based on revision 60 of http://forge.ogf.org/svn/repos/occi/docs. I hope that helps. Sorry for the bad English - did not find time to smoothen it up, and don't want to delay to send this out.

In general, I think the structure of the doc is fine (modulo what is in the remarks below). There are minor things which can easily filled just before submission to the OGF editor.

What I am most concerned about are the lack of semantic detail: the document lists all the words and terms and actions of OCCI, but what *exactly* happens when and where is mostly unspecified.

Anyway, more details below. Please let me know if anything is unclear, or if I misunderstood something.

Let me know if you think this mail should rather go to the list, or feel free to bounce/forward...

Best, Andre.

- use MUST, SHOULD, MAY, CAN... (http://www.ietf.org/rfc/rfc2119.txt). Make very clear what is normative, what is not.

- Walkthrough: - possibly make that a part of the 'introduction'

- clarify if walkthrough is normative (should at least support SSL/TLS?)

- shorten intro paragraph of 'representation'. Stick to the technical part ("For cloud infrastructure[s] ...")

- "... as at the time of writing." - what does that mean *blush*

- in Getting Started: Connecting, Authenticating, XXX, Representation, Descriptors, ...

At XXX I'd love to see a short statement on the operations, so that the motivation for the following sections become more clear (its 'getting started', not the 'spec'). Like

"Actions: Once a client securely connected to the endpoint, it is able to create, retrieve update, and delete (CRUD) resources, identified by various representations etc etc..."

- What is the relation between representations and descriptors? Can we have an example tying both together?

- It would be great to have the walkthrough accompanied by an example client-endpoint communication, as it goes over the wire. That is another reason to have actions/operations before representations and descriptors...

- Pick *one* format (e.g. atom *or* text) for examples and description, and just mention that formats can be converted, using possibly single example. Highlight examples with a frame or diffrerent color. Possibly mention shortly how server/client agree on a common format.

- Whenever referencing other technologies first, (HTTP, SSL/TLS, URL), reference the reepsctive RFC or standard, etc. This CAN be done in the Glossary, if you think you need one.

- There is an italic problem in the third paragraph of 'Retrieve'.

- Async requests: what are the identifiers to be used when querying for the state of an async request?

- After the walkthorugh, or before the OCCI core, define exactly what parts of the presented server/client communication are

- defined by OCCI - are not defined by OCCI, but left to the implementation

Things which are not defined by OCCI, but defined elsewhere, are covered by references already. Averything mentioned should clearly fall into one of these three categories.

- FAQ:

- leave out, or at least move into appendix

- OCCI Core

- Table 1 comes out of nowhere - no mention of 'common attributes' in 4.1. Why does it specifically mention atom in the description column?

- 4.1 should contain a overview of the structure of the chapter, like: 4.2 will define the basic OCCI Components and their semantics. 4.3 will define how those can be mapped into various formats (defining that mapping is *not* part of this specification - or is it? If it is, then there needs to be an extra extensive section on those. I'd rather suggest to do separate (possibly short) documents). 4.4 will define the OCCI extension mechanism, which will allow for vendor specific extensions of the OCCI scope presented in 4.2.

- 4.5 and 4.6 are unclear. 4.5 could possibly go if RFC are referenced where introduced in the text. 4.6 may be merged into the extensions?

- There is no harm whatsoever in sprinkling the spec part (section 4) with example communications, as long as it is made clear that the format used is illustrative, not normative.

- Everything which is somehow realted to OCCI semantics seems to be put under 'extensions' - does that mean everything is optional? It is not clear at this point what extension means. Maybe that should be clarified in the walkthough already, but *latest* in 4.1.

- each extension needs an intro, motivating it, and stating if the extentsion is mandatory/optional/depending on some other extension, etc. Also, it needs to be clarified if other extensions not specified here are allowed in implementations, under what cirumstances. How is interop between extensions ensured (always error on mismatch? Silent ignore? Warning? - possibly specifiy for each extension idividually).

- 4.1 should also clarify the relation of 4. to 5., i.e. that the operations etc defined in 4 apply to entities defined in 5. That is completely unclear, and up to 5, one wonders what the occi defined in 4 is doing at all, semantically.

- OCCI Infrastructure

- Intro is missing/too short - what is this about (table 7 comes out of nowhere)? What is connection to earlier text, etc

- lots of semantics missing (as in the 4.4.x extentions btw). Just an example:

compute.cpu.speed: Is that maximum speed? Average Speed? Is speed stepping allowed or not? Is that up to the implementation? Is rounding allowed? If OCCI does *not* specify these things, then state that, too!

Example (I am just making this up)

"OCCI does not specify further details of the speed attribute semantics, such as speed stepping, rounding, etc. The attribute MUST be present in compute resource descriptions received from the provider, and MAY be present in resource descriptions provided by the client. The provider MUST interpret the attribute as a minimal value, and MUST decline the operation if its resources do not match that attribute, with a XYZ failure code."

If occi is not defining that level of semantics, interop will be very difficult. In particular it will be difficult to obtain reproducible error conditions.

- 5.2 needs work, obviously. The comments to 'extensions' in 4 mostly also hold for extensions in '5': are the mandatory etc etc.

- what is 6 about? What is the relation to 4.6?

- What is table 11 about? Is that from some RFC? Why copied here instead of referenced? Move into appendix at least.

-- Nothing is ever easy.

Quoting [Thijs Metsch] (Sep 22 2009):

Date: Tue, 22 Sep 2009 14:13:27 +0200 From: Thijs Metsch <Thijs.Metsch@Sun.COM> To: occi-wg@ogf.org Subject: [occi-wg] Reminder: Important weekly concall today - 07:00 PDT, 10:00 EDT, 15:00 BST, 16:00 CEST

Hi @all,

Tomorrow it is time for our weekly concall. All dial-in details can be found below.

We'll do a complete walkthrough of our OCCI Specification. Please take the document which I send out yesterday for discussion base. It is dated Sep. 21, 2009 and reflects Changeset 47. And can be found here:

http://forge.ogf.org/sf/go/doc15731

If you want to state a comment or propose a change please provide section number and paragraph number so we can easily track the changes.

Next week we'll have some 'guests' from OpenNebula with we can discuss the OCCI implementation they made. So mark you calendars :-)

Cheers,

-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 -- Nothing is ever easy.