[occi-wg] confusion about status of link / headers

[Alexis Richardson]

Gary

Thanks.  That strikes me as a fairly complex process.

Does anyone have any alternative suggestions?  We need a simple model
for reaching consensus here, that grows the community and adoption.

alexis




On Mon, Oct 19, 2009 at 5:10 PM, Gary Mazz <garymazzaferro at gmail.com> wrote:
> 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 at 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 at ogf.org
>>>> http://www.ogf.org/mailman/listinfo/occi-wg
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>