An alternative, but somewhat more heavyweight/slower, and
thus only ustified when there is vested interest from
multiple sides:

* Extensible spec released, implementors have at it

* MacroHard wants to talk about RAID levels for their upcoming
BigDisk

* It's not in the spec so they propose an extension
package to us (aka OCCI-WG)
* we discuss it, think it's a good idea (or not), and
produce a formal specification document
* implementors hack at it, and interop if proven by
multiple implementations
* JuniperBerry see MacroHard's BigDisk eating their lunch and want to

add a similar feature to their LittleDisk

* it's already specified so nothing needs to be done - bingo,
interoperability

Yes, we would need both - registries primarily for change management of attributes, states, etc. and full-blown extensions for more advanced topics like adding new resource types/styles (e.g. load balancers).

I'd suggest breaking up the workload as follows:

Adopt AtomPub (+search, caching, etc.) as OCCI Core - lots of hard work already done (the alternative will almost certainly involve another OGF cycle, pushing the final delivery out to OGF 28 which is yet to be scheduled in 2010)
Specify compute, storage and network resources as separate extensions (probably in that order)
Specify state control as an extension <- at this point we have our implementable draft
Specify billing, performance monitoring, etc. as extensions
Flesh out over time based on demand for features

One huge advantage of this approach is that we don't have to wait until the end before we start implementations - people can start right now (as I have).

PS.: I am not sure if OGF would go into the space of
maintaining registries, or such. OGF's business is to
produce specification documents, and to host the
infrastructure for doing so. But I am sure that, if a
registry is the way to go, we'll find a host for that...

One non-technical point to consider when it comes to things like registries is that using neutral ground like IANA make the standard far more likely to be adopted by other SSOs.

Sam