Alexis, I do not believe we can set aside the OGF27 unapproved unilateral change to the document. It is a fundamental problem in operation. These are my suggestions: 1) Place the document in a format where each interface can have its own life cycle. 2) Create a template for adjunct documents 3) Limit check-in to the repository to two people and one backup. 4) Recruit an editor and a backup editor. This spec isn't that big. 5) Provide an incubator for emerging technologies and proposals for inclusion in the specification. 6) Form a public mailing list purposed for emerging technologies, proposal discussions and voting 7) Provide a proposal document number for each submitted document 8) Before the document can be considered for review, it must be in the adjunct documents template -gary Alexis Richardson wrote:
Leaving aside the when and how in relation to OGF 27 specifically, we cannot claim that unilateral changes are supported by the group if they are not supported by the group. I am very concerned about this. We of course don't want to ignore innovative proposals, but we need to build consensus around them before inclusion in the spec.
Suggestions for a good way forward are solicited..
alexis
On Mon, Oct 19, 2009 at 4:19 PM, Gary Mazz <garymazzaferro@gmail.com> wrote:
That is a good point, a better question would be how did it get into the spec presented like it was the preferred method. Probably because there is no single editor and anyone can change the documents anyway they feel fit.
I don't think what Sam is working on is out of scope for OCCI, it was unintended to support multiple interfaces. Sam seems to be running with this one, driving OCCI to the lowest level of the HTTP protocols, essentially creating a new technology, untried on multiple levels in the internet infrastructure.
My issue with it is it was placed in the spec at the last second before OGF 27, other implementations were remove in lieu of this one, it was placed in the spec irrespective of a group consensus and SNIA, a strategic partner, publicly announcing they would NOT support this interface. However, this does not preclude the rest of this group to continue with the original concept of OCCI information in HTTP entities (content body). For maintainability, this does force the document to take on a new format of separating the implementations from reference model (we need one first). Interface implementations should fall into adjunct documents. This specification model has been successfully executed by numerous standards bodies.
cheers,
Gary
Alexis Richardson wrote:
Sam & group,
I just saw this tweet: http://twitter.com/samj/statuses/4991958514
You say that "HTTP has an out-of-band metadata channel in the form of headers. #occi's using Link: as a flexible, lightweight RDF alternative".
I'm a bit confused here.... I thought this was still under discussion. What am I missing?
alexis _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg