[occi-wg] Reminder: Important weekly concall today - 07:00 PDT, 10:00 EDT, 15:00 BST, 16:00 CEST
Andre Merzky
andre at merzky.net
Wed Sep 23 09:41:14 CDT 2009
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 at Sun.COM>
> To: occi-wg at 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.
More information about the occi-wg
mailing list